云存储及云计算使用运维文档格式.docx
《云存储及云计算使用运维文档格式.docx》由会员分享，可在线阅读，更多相关《云存储及云计算使用运维文档格式.docx（15页珍藏版）》请在冰豆网上搜索。
2、易于扩展的集群架构3
3、有效分散集群压力4
4、高效的大数据分析4
二、目前使用情况及反馈5
1、目前线上Hadoop使用情况5
2、针对目前线上环境的分析5
3、关于Hadoop集群服务器的选用7
4、关于nineCloud8
5、HBase8
6、监控10
三、HBase和Oracle10
四、HDFS作为分布式存储的使用可能性分析13
五、成功案例分析14
六、发展方向15
1、SaaS方向15
2、数据挖掘方向17
Hadoop一个分布式系统基础架构，由Apache基金会开发。
用户可以在不了解分布式底层细节的情况下，开发分布式程序。
充分利用集群的威力高速运算和存储。
Hadoop实现了一个分布式文件系统FileSystem），简称HDFS。
Hadoop拥有功能丰富的子项目，其中包括HBase、Hive、ZooKeeper等功能各异的子项目，灵活的使用这些项目可以轻松的做到云计算平台的构建。
1、读写性能和数据安全
Hadoop都是基于HDFS文件系统，HDFS可以有效的提高系统的吞吐量，减少系统等待时间。
HDFS是以磁盘为存储单位的，比如有三台服务器，每个服务器有三块硬盘，对于HDFS等于有九个写入单元，而传统的基于服务器的分布式存储等于只有三个写入单元。
而且HDFS通过数据块进行备份的数据冗余机制，磁盘底层不需要而且不建议组建RAID，所以在可使用的磁盘空间上得到了更进一步的提升，而读写性能跟组建注重读写的RAID0后的效果相同。
HDFS对于磁盘读写速度的提升和对数据安全性的提升如下：
磁盘读写速度（RAID0=HDFS>
RAID[1+0]>
RAID5>
RAID1）
磁盘数据安全（RAID1=HDFS>
RAID0）
由此可见，HDFS可以达到RAID1的数据冗余和RAID0的高速读写。
在最新版本（测试版本或者第三方的商业版本）的Hadoop中，Hadoop提出了一个新的NameNodeHA功能，利用该功能可以有效地规避老版本的NameNode节点单点问题。
2、易于扩展的集群架构
而且Hadoop中的DataNode方便扩展，可以在不停止服务的状态下动态的添加新的DataNode节点进入集群，而且加入后也不需要重启整个集群，只需要正常配置DataNode节点并启动该节点，NameNode可以自动将该节点加入集群。
为了方便集群启动时可以正常启动新加入的DataNode需要对NameNode服务器上的hosts文件及slaves文件进行修改。
3、有效分散集群压力
Hadoop采用动态存储资源分配，可以将数据更平衡的分布于不同的DataNode节点，防止出现数据不平衡而造成部分DataNode节点请求过多，而其它DataNode节点没有请求的情况。
就算有新的DataNode节点加入集群，Hadoop也可以通过一条命令简单的做到数据的重新平衡。
当然这个操作最好在使用量低的夜间进行。
Hadoop的数据的交换是不经过NameNode节点的，NameNode上保存的文件是直接从DataNode上收集而来，所以当用户使用Hadoop集群上的数据时，是直接从DataNode获取数据，这样做使得NameNode的压力得到缓解。
而且最新版的Hadoop还支持在一个Hadoop集群中分别创建多个NameNode节点，每个NameNode节点分别管理整个HDFS空间的一部分。
使HDFS中的数据做到有效的隔离，并且当一个NameNode节点出现问题，不至于影响到整个集群中数据的访问。
4、高效的大数据分析
HBase作为Hadoop的一个子项目，主要用于数据的存储。
HBase适合于非结构化数据存储的数据库。
与常用的数据库不同的是HBase基于列的而不是基于行的模式。
由于HDFS的特点，所以HBase非常适合大数据量的数据分析。
系统架构上和Hadoop相类似同样在进行架构的扩展上十分的方便，当出现存储空间不足的情况时，只需要添加进去新的DataNode节点就可以了。
由于HBase是基于列的数据库，所以配合Hive可以发挥BI数据库的功能以达到数据分析的作用。
加上HDFS分布式存储的底层支持，使得其在进行数据分析、数据挖掘上有一定的优势。
但是Hive虽然提供了高级SQL的支持，但是对于专业的BI数据库上还略有不足针对BI/BO工程师不是十分友善。
HBase于ZooKeeper等项目的组合应用，可以保证HBase的HMaster节点没有单点的问题出现。
而HBase和Pig及Hive等项目一同使用时还能得到对高层SQL语言的支持。
二、目前使用情况及反馈
1、目前线上Hadoop使用情况
HDFS总空间：
10.74TB
已经使用空间：
251.07GB
NameNode负载：
平均小于0.1
DataNode负载：
平均在0.1左右
通过iostat命令查看三台DataNode数据节点信息，内容如下：
CPU的使用情况：
avg-cpu:
%user%nice%sys%iowait%idle
0.550.000.431.0397.99
硬盘的使用情况：
Device:
tpsBlk_read/sBlk_wrtn/sBlk_readBlk_wrtn
sdb5.85120.8590.12779560090581333808
0.340.000.300.3699.00
sdb5.5341.1084.69265108546546324728
0.620.000.600.7498.04
sdb6.55224.87115.691450531354746285984
2、针对目前线上环境的分析
通过上面这些数值可以看出，目前Hadoop云平台的整体压力较小，DataNode数据节点的写操作相对比较平衡，读操作则slave3的读取数据远远大于其它两台设备。
目前线上系统架构存在着一定的不合理性：
Hadoop集群的服务器上尽可能的不部署其它应用，因为无论NameNode，还是DataNode其中NameNode负责镜像元数据的保存，随着业务量的增加这个文件的大小会越来越大，而且这个文件是全部加载进内存中的；
而DataNode本身就是以进行计算和硬盘IO操作为主，而当有其它程序运行是势必会造成磁盘IO和CPU资源的抢占，降低效率，这样的结果会进一步的降低Hadoop集群的响应时间。
Hadoop集群的逻辑架构为：
而物理架构上，DataNode1和DataNode2兼做LD和LD（B）服务器的作用，NameNode服务器同时还是CAS统一认证的服务端，DataNode3为CAS统一认证的服务端的备份。
用户访问云平台的流程图：
用户SISS平台（支持中心）LVSNineCloudHadoop云计算平台
|------------|NameNodeDataNode
||-------|
||-------|
||-----------|
|---------------------------------------------------|
|---------------------------------------------------------------|
|---------------------------------------------------------------|
综上所述，由于目前集群的压力并不大，所以这些共用服务器的缺点还没有暴露出来。
随着业务量的增加，服务器节点的访问量提高，每提升一倍的访问量，NameNode服务器和DataNode服务器的访问量将提高三倍甚至四倍。
并且通过用户访问云平台的流程可以看出一个用户的一次请求在现在的架构上，由于NameNode和SISS平台登录使用的是同一台服务器，所以该服务器会建立4个连接，其中两个是链接到NineCloud，另外两个连接是连接到用户的，而正常的情况下只会建立2个连接。
由于目前访问量的压力不大，所以这种架构下还没有出现问题，但是随着业务的专业和访问量的进一步增大，这个节点的问题将逐渐的凸显出来。
解决这个问题的方法相对比较简单，这里最好能够做到“专机专用”。
由于这两个应用都会逐渐变成访问量较大，压力较重的服务器，所以和其它应用共享一台服务器可能会出现问题，所以建议这两个应用分别在两台不同的应用上运行。
而LVS和DataNode应用也同样存在着上面说到的问题。
而且现在线上的云平台没有做安全方面的配置，加上Hadoop自身的安全控制非常简单，只包含简单的权限，即只根据客户端用户名，决定使用权限。
它的设计原则是：
“避免好人做错事，但不阻止坏人做坏事”。
如果你知道某台NameNode的IP和端口，则可以很轻松获取HDFS目录结构，并通过修改本机机器用户名伪装成HDFS文件所属owner，对该文件进行删除操作。
这一点尤其是在以后进一步进行异地机房备份时要注意，入侵者可以利用上面的安全问题伪装IP地址入侵到系统，对系统的安全性将产生很大的影响。
这里在以后的工作中可以通过配置kerberos，可以实现身份验证。
但很多管理员使用更简单有效的办法——通过防火墙对访问IP进行控制或者异地机房通过路由器组建通讯隧道（路由间VPN）。
3、关于Hadoop集群服务器的选用
Hadoop集群主要分成两部分，既NameNode节点和DataNode节点。
其中NameNode节点主要管理元数据的保存，而DataNode节点则是保存用户上传的数据。
Hadoop不同的节点对于内存的需求量有着很大的差别，（修改内存占用可以通过文件bin/hadoop-evn.sh）主流节点内存配置为32GB，典型场景内存设置如下：
NameNode15-25GB
JobTracker2-4GB
DataNode1-4GB
TaskTracker1-2GB
ChildVM1-2GB
集群的使用场景不同相关设置也有不同，如果集群有大量小文件，则要求NN内存至少要20GB，DN内存至少2GB。
根据以上可以看出，我们可以在服务器的选用上分成两部分：
第一部分对内存的大小要求比较高，主要用来计算和分配的NameNode。
第二部分对硬盘的IO和空间要求比较高，主要用来读写存储数据的DataNode节点。
这部分甚至可以配一台配置较好的服务器之后利用虚拟化技术虚拟成多台服务器之后分别挂载硬盘的方式来节约成本。
而大部分计算工作都是交给DataNode来完成的，所以DataNode服务器对于CPU配置要相对略高一些。
4、关于nineCloud
nineCloud是自行开发的java程序连接HBase的接口程序，java程序通过调用HBase提供的API将数据保存到HBase中，目前是有两台服务器互为负载均衡。
这两台服务器的压力相对较低，在考虑到该程序的访问量压力的前提下可以进行在该服务器上部署其它应用。
由于HBase是线性工作模式，即完成一个任务才会进行下一个任务，只是在计算时使用的是并发计算。
所以同时交付给HBase过多的任务并不会缩短任务的完成时间。
这里可以考虑HBase和nineCloud应用之间采用通道连接（即nineCloud和HBase建立永久性连接，用户的请求直接从该链接内发送给HBase，不在单独建立连接。
可采用先到先出的内存管理模式。
）的模式进行，用来降低创建连接的时间间隔，又可以有效地保证HBase和nineCloud的连接。
同时还方便维护人员进行监控，即只要保证连接存在即可保证两个应用之间的是保持通讯的，如断开则表明一侧的应用出现了问题。
5、HBase
HBase是Apache基金会Hadoop开源项目中的基于Google提出的BigTable所产生的列数据库，HBase拥有Hadoop的方便部署，架构扩展容易，可以利用低配置的机器组建大规模的集群等优势，同时由于Regionserver的机制使得HBase在大数据量的操作上会更有优势。
HBase在读写上效率并不是很高一定意义上由于延时会造成系统运行相对较慢。
虽然HBase属于noSQL的列数据库，但是HBase并不是针对数据的高速读取的内存数据库，而是偏向海量存储下的运算效率而非Key-Value存储的效率。
从以上的描述可以看出，HBase作为线上库对于系统的要求相对苛刻：
1、由于HBase是noSQL数据库，所以不支持事务；
2、存储效率上与一般的noSQL对比没有优势；
3、系统对于响应时间没有过分的要求。
而从目前线上应用来看，是存在着直接从HBase读取数据的情况存在，当访问量放大后，这种直接从HBase进行搜索的操作势必会对整个系统造成一定的拖累。
所以对于线上系统要进行一定的改进用来创造要符合HBase的应用场景（与Oracle对比），比如数据量大、对线性拓展有需求、对自动化运维（负载均衡）有要求而且应用模式简单。
这里前面几个应用场景是使用HBase的适合环境，但是应用模式简单是使用HBase的必须要求，如上所述，HBase是不支持事务，且存储速度一般。
在复杂的应用模式下使用HBase将会非常的麻烦，甚至HBase根本就无法满足要求。
如果需要完成负载的操作那么就需要增加Pig和Hive功能，Hive和Pig都是基于Hadoop的大规模数据分析平台：
Pig简单说是一种编程语言，它简化了Hadoop常见的工作任务。
开发人员可以通过Pig直接加载数据，表达转换数据以及存储最总结果。
Pig内置的操作使得半结构化数据变得有意义（如日志文件）。
同时Pig课扩展使用Java中添加的自定义数据类型并支持数据转换。
Hive在Hadoop中扮演数据仓库的角色。
Hive添加数据的结构在HDFS（hivesuperimposesstructureondatainHDFS），并允许使用类似于SQL语法进行数据查询。
与Pig一样，Hive的核心功能是可以扩展的。
通过上面的介绍可以看出，Hive更适合数据仓库的任务，可以用于静态的结构以及需要经常分析的工作。
而且Hive对于SQL的支持是其可以直接与其他BI工具相结合。
而Pig则给开发人员提供了相当大的自由度，比直接只用HadoopJavaAPIs相比大幅度的削减了代码量。
结合Hive和Pig可以是线上的Hadoop云平台在功能上得到进一步的完善，但是对于HBase在存储和读取数据的实时性上仍需要进行一些改善，可以考虑的改善方案：
1、在HBase前加传统的Key-Value内存数据库，增加数据的读取速度：
在这种方案中，应用程序直接与内存数据库进行数据的交互，之后再通过程序将已经写入内存数据库的数据保存到HBase中，这里HBase的作用更多的是数据收集和固化存储。
完成以上操作后可以再利用Hive、Pig的Hadoop项目中的子项目对固话的数据进行分析和加工。
再将处理后的数据以缓存的方式通过固定模式加载到内存数据库中，并释放内存数据库中重复的数据；
2、HBase和Oracle、MySQL或者MSSQL协同使用：
基本原理和方案一类似，不过Oracle、MySQL或者MSSQL等数据库都是关系型数据库是是支持事务的，将处理完成的数据加载到这些数据库中，可以让应用进行相对负载的数据库查询操作。
但是鉴于都是磁盘存储的方式，需要定期对数据进行精简。
比如：
实时搜索只能通过关系型数据库搜索到当前一个月的数据，如果想要查看一个月前的数据则直接加载从HBase、Hive或者Pig处理完后缓存出的镜像列表。
6、监控
线上系统的监控由Hadoop及HBase提供的页面管理工具和Ganglia集群监控工具组成，虽然两个工具可以保证在Hadoop及HBase出现故障时直接的反映出来，但是对于故障的预估和后续的解决故障上却没有什么帮助。
在后续的工作中，需要继续完善Hadoop及HBase的监控系统，目前已知的监控参考方案有：
1、Hadoop原生脚本
a）大部分是进程级管理
b）需要较多手工工作，自动化不足，无监控
2、ClouderaManager
a）功能强大，为HadoopEcosystem定制
b）缺乏灵活的包版本管理，方便用官方发布包，不方便开发团队
c）按照成系统服务，单击无法部署多版本/多服务
d）商业软件，不开源，无法定制/改进
3、ApacheAmbari
a）Hortonworks主导的开源实现
b）特点类似，目前还不成熟
4、大厂通用方案
a）MSAutopilot，GoogleBorg，TencentTorca
三、HBase和Oracle
HBase已经在上一个章节简单的介绍过了，这里就直接介绍Oracle：
Oracle作为一款商用软件，在性能上确实有很强大的竞争力。
HBase作为一款开源的列数据库，在非大数据量（PB级别）的数据操作上与Oracle相比并没有优势，尤其在数据量在TB以下级别时。
HBase的优势是在大数据的数据操作，借助于HDFS的分部署云计算达到并发计算的效果。
又因为从HBase中获取数据的三种办法：
1、通过rowID直接访问；
2、通过设置rowID的范围访问；
3、全表扫描。
由此可知，HBase无法使用复杂的SQL语句来进行查询，如果不知道rowID相关的信息，那么只有通过全表扫面才能获取信息，也就是说HBase在条件查找上有一定的局限性。
而且HBase中所有表都是相互独立的，没有像Oracle等关系型数据库那样的外键的定义。
虽然通过Hive可以使的HBase可以兼容简单SQL语句，但是对于事务依旧没有支持，并且很多复杂的SQL条件搜索语句也是不支持的。
当数据量达到一定的数量级时，由于数据文件大小的增长会逐步拉低Oracle的搜索速率。
但是HBase当文件大小增长到一定程度时，会自动将过大的文件分割成多个小文件（分割成小文件的数量和HBaseRegionserver的数量有关），这个功能和普通关系型数据库的分割表功能类似，不过分割表功能除了Oracle的RAC功能外，依旧只是在同一台服务器上面进行操作。
并将每一个小文件交付给对应的一个RegionServer进行处理。
当用户进行相关的操作时可以更迅速的找到用户所需要的数据。
那么在什么情况下可以考虑使用HBase:
1、需要存储大量数据；
2、数据写入量大；
3、需要在大数据集内进行主键的随机查询；
4、需要存储非结构化或者半结构化的数据；
5、不需要RDBMS的一些功能（跨行事务，join等）。
综上所述，如果只是作为数据收集和分析的工具，HBase完全可以替换Oracle。
但是在数据的检索上Oracle还是有一定的优势的，当且仅当数据量过大对Oracle的计算速率造成影响时，HBase在数据的检索上会有一定的优势。
尤其在性价比方面则更为突出。
所以在使用HBase的时候，最好还是要用HBase和MySQL或者Oracle相互配合才能得到最好的效果。
这里面可以用HBase作为大数据量的存储、调用和分析，并利用MySQL或者Oracle对于事务和复杂SQL语句的良好支持完成外部应用程序对数据库数据的调用和查询。
关于数据量对于Oracle和HBase的影响可以粗略的看做下图：
虽然Oracle可以通过大规模的组建RAC来达到分布式的效果，使其性能在对付大数据量时与HBase相差无几，但是这种大规模的使用Oracle必然会受到Listen的限制，如果从Oracle购买必然会产生巨额的费用。
所以无论从效果还是从经济利益上考虑，对于大数据HBase都是要由于Oracle的，这也是HBase廉价的一个特点。
以目前线上HBase的数据量（150G左右的数据量，在数据等级上属于小数据量）来看，并不十分适合HBase的定义。
简单来说，就目前的数据量来看用HBase作为目前保存报文的分析工具（分析内容包括但不限于：
企业发送报文的时间统计，报文类型统计，发送报文的企业类型统计，申报内容统计等。
）是完全没有问题的，但是让应用直接从HBase中搜索数据的并没有比让应用直接从Oracle中读取数据要有优势，且目前线上系统的节点并不多（有三个Regionserver）。
对于线上HBase系统在以后的使用上一方面要加强集群方面的扩展，可以说HBase属于节点越多对于数据的处理速度越快；
另一方面目前线上HBase数据库里面的数据是从Oracle完全倒过去的线上HBase数据库里面的数据是从Oracle完全倒过去的，所以在数据结构上更类似Oracle的结构化数据，这点在以后的使用中要逐渐将结构化数据转型为半结构化数据，最终边卫非结构化数据。
为什么要这么做：
结构化数据即所有数据的格式相同，内容有相关性，这使得数据在传输的过程中会包含大量的空值信息，而这种空值信息在结构化数据中是占用空间的。
这种情况直接影响的就是数据传输时，会有大量的带宽被这种没有实际意义的空值信息占用。
当数据进入半结构化虽然空值信息不再占用空间，但是信息头依旧存在，这使得虽然在数据传输过程中带宽会降低，但是依旧不能摒弃掉没有用的信息对带宽的占用。
而当数据最后进入非结构化时，那么数据传输已经基本做到了摒弃没有用的信息对带宽的占用，一方面加快了数据的传输速度，一方面节约了带宽。
四、HDFS作为分布式存储的使用可能性分析
以下三种环境，是最适合采用云存储。
其实也正是这些实际需求，催生了云存储，也为云存储的发展提供了可能。
首先，判定是否存在着这种相关性，就是软硬件升级的费用和系统"
无限"
的可扩展性密切关联。
此时就要注意了：
当系统的能力受到限制后，一些架构隐含着惊人的再次认证许可费用。
例如：
你是否受到软件许可费的困扰呢?
当你不得不再次增加驱动器或存储阵列的数量，这种做法实际上已超出了边际的最优成本。
其次，在系统维护过程中或软硬件重新配置时，确认存储环境是否在线、数据是否可用。
包括软硬件，所有的存储系统有可能随时需要升级。
当更新时，一定要知道在系统上会产生哪些影响。
最后，如果选择数据和灾难备份产品，如自动让快照和复制。
但要提醒的是，提防一些隐性成本，如带宽要求。
它可能限制一些快照的次数或复制（即每次都要更改或
升级会员 