云存储及云计算使用(运维).docx

Four short words sum up what has lifted most successful individuals above the crowd: a little bit more.-author-date云存储及云计算使用(运维)Windows 用户关于云存储使用情况的探讨和分析版本历史版本号修改日期修改人审批日期审批人版本说明/变更理由/变更内容V1.0.2013-4-1赵强首发变更说明：C：Create，初始创建；A：Add，增加内容；M：Mod，修改；D：Del，删除 一、Hadoop的介绍及优缺点分析：31、读写性能和数据安全32、易于扩展的集群架构33、有效分散集群压力44、高效的大数据分析4二、目前使用情况及反馈51、目前线上Hadoop使用情况52、针对目前线上环境的分析53、关于Hadoop集群服务器的选用74、关于nineCloud85、HBase86、监控10三、HBase和Oracle10四、HDFS作为分布式存储的使用可能性分析13五、成功案例分析14六、发展方向151、SaaS方向152、数据挖掘方向17一、Hadoop的介绍及优缺点分析：Hadoop一个分布式系统基础架构，由Apache基金会开发。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力高速运算和存储。Hadoop实现了一个分布式文件系统 File System），简称HDFS。Hadoop拥有功能丰富的子项目，其中包括HBase、Hive、ZooKeeper等功能各异的子项目，灵活的使用这些项目可以轻松的做到云计算平台的构建。1、读写性能和数据安全Hadoop都是基于HDFS文件系统，HDFS可以有效的提高系统的吞吐量，减少系统等待时间。HDFS是以磁盘为存储单位的，比如有三台服务器，每个服务器有三块硬盘，对于HDFS等于有九个写入单元，而传统的基于服务器的分布式存储等于只有三个写入单元。而且HDFS通过数据块进行备份的数据冗余机制，磁盘底层不需要而且不建议组建RAID，所以在可使用的磁盘空间上得到了更进一步的提升，而读写性能跟组建注重读写的RAID 0后的效果相同。HDFS对于磁盘读写速度的提升和对数据安全性的提升如下： 磁盘读写速度（RAID0=HDFS>RAID1+0>RAID5>RAID1）磁盘数据安全（RAID1=HDFS>RAID1+0>RAID5>RAID0）由此可见，HDFS可以达到RAID1的数据冗余和RAID0的高速读写。在最新版本（测试版本或者第三方的商业版本）的Hadoop中，Hadoop提出了一个新的Name NodeHA功能，利用该功能可以有效地规避老版本的Name Node节点单点问题。2、易于扩展的集群架构而且Hadoop中的Data Node方便扩展，可以在不停止服务的状态下动态的添加新的Data Node节点进入集群，而且加入后也不需要重启整个集群，只需要正常配置Data Node节点并启动该节点，Name Node可以自动将该节点加入集群。为了方便集群启动时可以正常启动新加入的Data Node需要对Name Node服务器上的hosts文件及slaves文件进行修改。3、有效分散集群压力Hadoop采用动态存储资源分配，可以将数据更平衡的分布于不同的Data Node节点，防止出现数据不平衡而造成部分Data Node节点请求过多，而其它Data Node节点没有请求的情况。就算有新的Data Node节点加入集群，Hadoop也可以通过一条命令简单的做到数据的重新平衡。当然这个操作最好在使用量低的夜间进行。Hadoop的数据的交换是不经过Name Node节点的，Name Node上保存的文件是直接从Data Node上收集而来，所以当用户使用Hadoop集群上的数据时，是直接从Data Node获取数据，这样做使得Name Node的压力得到缓解。而且最新版的Hadoop还支持在一个Hadoop集群中分别创建多个Name Node节点，每个Name Node节点分别管理整个HDFS空间的一部分。使HDFS中的数据做到有效的隔离，并且当一个Name Node节点出现问题，不至于影响到整个集群中数据的访问。4、高效的大数据分析HBase作为Hadoop的一个子项目，主要用于数据的存储。HBase适合于非结构化数据存储的数据库。与常用的数据库不同的是HBase基于列的而不是基于行的模式。由于HDFS的特点，所以HBase非常适合大数据量的数据分析。系统架构上和Hadoop相类似同样在进行架构的扩展上十分的方便，当出现存储空间不足的情况时，只需要添加进去新的Data Node节点就可以了。由于HBase是基于列的数据库，所以配合Hive可以发挥BI数据库的功能以达到数据分析的作用。加上HDFS分布式存储的底层支持，使得其在进行数据分析、数据挖掘上有一定的优势。但是Hive虽然提供了高级SQL的支持，但是对于专业的BI数据库上还略有不足针对BI/BO工程师不是十分友善。HBase于ZooKeeper等项目的组合应用，可以保证HBase的HMaster节点没有单点的问题出现。而HBase和Pig及Hive等项目一同使用时还能得到对高层SQL语言的支持。二、目前使用情况及反馈1、目前线上Hadoop使用情况HDFS总空间：10.74TB已经使用空间：251.07GBName Node负载：平均小于0.1Data Node负载：平均在0.1左右通过iostat命令查看三台Data Node数据节点信息，内容如下：CPU的使用情况：avg-cpu: %user %nice %sys %iowait %idle 0.55 0.00 0.43 1.03 97.99硬盘的使用情况：Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnsdb 5.85 120.85 90.12 779560090 581333808CPU的使用情况：avg-cpu: %user %nice %sys %iowait %idle 0.34 0.00 0.30 0.36 99.00硬盘的使用情况：Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnsdb 5.53 41.10 84.69 265108546 546324728CPU的使用情况：avg-cpu: %user %nice %sys %iowait %idle 0.62 0.00 0.60 0.74 98.04硬盘的使用情况：Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnsdb 6.55 224.87 115.69 1450531354 7462859842、针对目前线上环境的分析通过上面这些数值可以看出，目前Hadoop云平台的整体压力较小，Data Node数据节点的写操作相对比较平衡，读操作则slave3的读取数据远远大于其它两台设备。目前线上系统架构存在着一定的不合理性：Hadoop集群的服务器上尽可能的不部署其它应用，因为无论Name Node，还是Data Node其中Name Node负责镜像元数据的保存，随着业务量的增加这个文件的大小会越来越大，而且这个文件是全部加载进内存中的；而Data Node本身就是以进行计算和硬盘IO操作为主，而当有其它程序运行是势必会造成磁盘IO和CPU资源的抢占，降低效率，这样的结果会进一步的降低Hadoop集群的响应时间。Hadoop集群的逻辑架构为：而物理架构上，Data Node1和Data Node2兼做LD和LD（B）服务器的作用，Name Node服务器同时还是CAS统一认证的服务端，Data Node3为CAS统一认证的服务端的备份。用户访问云平台的流程图：用户 SISS平台（支持中心） LVS NineCloud Hadoop云计算平台|-à| Name Node Data Node | |-à| |-à| |-à| |ß-| |-à| |ß-|综上所述，由于目前集群的压力并不大，所以这些共用服务器的缺点还没有暴露出来。随着业务量的增加，服务器节点的访问量提高，每提升一倍的访问量，Name Node服务器和Data Node服务器的访问量将提高三倍甚至四倍。并且通过用户访问云平台的流程可以看出一个用户的一次请求在现在的架构上，由于Name Node和SISS平台登录使用的是同一台服务器，所以该服务器会建立4个连接，其中两个是链接到NineCloud，另外两个连接是连接到用户的，而正常的情况下只会建立2个连接。由于目前访问量的压力不大，所以这种架构下还没有出现问题，但是随着业务的专业和访问量的进一步增大，这个节点的问题将逐渐的凸显出来。解决这个问题的方法相对比较简单，这里最好能够做到“专机专用”。由于这两个应用都会逐渐变成访问量较大，压力较重的服务器，所以和其它应用共享一台服务器可能会出现问题，所以建议这两个应用分别在两台不同的应用上运行。而LVS和Data Node应用也同样存在着上面说到的问题。而且现在线上的云平台没有做安全方面的配置，加上Hadoop自身的安全控制非常简单，只包含简单的权限，即只根据客户端用户名，决定使用权限。它的设计原则是：“避免好人做错事，但不阻止坏人做坏事”。如果你知道某台Name Node的IP和端口，则可以很轻松获取HDFS目录结构，并通过修改本机机器用户名伪装成HDFS文件所属owner，对该文件进行删除操作。这一点尤其是在以后进一步进行异地机房备份时要注意，入侵者可以利用上面的安全问题伪装IP地址入侵到系统，对系统的安全性将产生很大的影响。这里在以后的工作中可以通过配置kerberos，可以实现身份验证。但很多管理员使用更简单有效的办法通过防火墙对访问IP进行控制或者异地机房通过路由器组建通讯隧道（路由间VPN）。3、关于Hadoop集群服务器的选用Hadoop集群主要分成两部分，既Name Node节点和Data Node节点。其中Name Node节点主要管理元数据的保存，而Data Node节点则是保存用户上传的数据。Hadoop不同的节点对于内存的需求量有着很大的差别，（修改内存占用可以通过文件bin/hadoop-evn.sh）主流节点内存配置为32GB，典型场景内存设置如下：Name Node15-25 GBJob Tracker2-4GBData Node1-4 GBTask Tracker1-2 GBChild VM1-2 GB 集群的使用场景不同相关设置也有不同，如果集群有大量小文件，则要求NN内存至少要20GB，DN内存至少2GB。根据以上可以看出，我们可以在服务器的选用上分成两部分：第一部分对内存的大小要求比较高，主要用来计算和分配的Name Node。第二部分对硬盘的IO和空间要求比较高，主要用来读写存储数据的Data Node节点。这部分甚至可以配一台配置较好的服务器之后利用虚拟化技术虚拟成多台服务器之后分别挂载硬盘的方式来节约成本。而大部分计算工作都是交给Data Node来完成的，所以Data Node服务器对于CPU配置要相对略高一些。4、关于nineCloudnineCloud是自行开发的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（hive superimposes structure on data inHDFS），并允许使用类似于SQL语法进行数据查询。与Pig一样，Hive的核心功能是可以扩展的。通过上面的介绍可以看出，Hive更适合数据仓库的任务，可以用于静态的结构以及需要经常分析的工作。而且Hive对于SQL的支持是其可以直接与其他BI工具相结合。而Pig则给开发人员提供了相当大的自由度，比直接只用Hadoop Java APIs相比大幅度的削减了代码量。结合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、 Cloudera Managera) 功能强大，为Hadoop Ecosystem定制b) 缺乏灵活的包版本管理，方便用官方发布包，不方便开发团队c) 按照成系统服务，单击无法部署多版本/多服务d) 商业软件，不开源，无法定制/改进3、 Apache Ambaria) Hortonworks主导的开源实现b) 特点类似，目前还不成熟4、 大厂通用方案a) MS Autopilot， Google Borg， Tencent Torca三、HBase和OracleHBase已经在上一个章节简单的介绍过了，这里就直接介绍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当文件大小增长到一定程度时，会自动将过大的文件分割成多个小文件（分割成小文件的数量和HBase Region server的数量有关），这个功能和普通关系型数据库的分割表功能类似，不过分割表功能除了Oracle的RAC功能外，依旧只是在同一台服务器上面进行操作。并将每一个小文件交付给对应的一个Region Server进行处理。当用户进行相关的操作时可以更迅速的找到用户所需要的数据。那么在什么情况下可以考虑使用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中读取数据要有优势，且目前线上系统的节点并不多（有三个Region server）。对于线上HBase系统在以后的使用上一方面要加强集群方面的扩展，可以说HBase属于节点越多对于数据的处理速度越快；另一方面目前线上HBase数据库里面的数据是从Oracle完全倒过去的线上HBase数据库里面的数据是从Oracle完全倒过去的，所以在数据结构上更类似Oracle的结构化数据，这点在以后的使用中要逐渐将结构化数据转型为半结构化数据，最终边卫非结构化数据。为什么要这么做：结构化数据即所有数据的格式相同，内容有相关性，这使得数据在传输的过程中会包含大量的空值信息，而这种空值信息在结构化数据中是占用空间的。这种情况直接影响的就是数据传输时，会有大量的带宽被这种没有实际意义的空值信息占用。当数据进入半结构化虽然空值信息不再占用空间，但是信息头依旧存在，这使得虽然在数据传输过程中带宽会降低，但是依旧不能摒弃掉没有用的信息对带宽的占用。而当数据最后进入非结构化时，那么数据传输已经基本做到了摒弃没有用的信息对带宽的占用，一方面加快了数据的传输速度，一方面节约了带宽。四、HDFS作为分布式存储的使用可能性分析以下三种环境，是最适合采用云存储。其实也正是这些实际需求，催生了云存储，也为云存储的发展提供了可能。首先，判定是否存在着这种相关性，就是软硬件升级的费用和系统"无限"的可扩展性密切关联。此时就要注意了：当系统的能力受到限制后，一些架构隐含着惊人的再次认证许可费用。例如：你是否受到软件许可费的困扰呢?当你不得不再次增加驱动器或存储阵列的数量，这种做法实际上已超出了边际的最优成本。其次，在系统维护过程中或软硬件重新配置时，确认存储环境是否在线、数据是否可用。包括软硬件，所有的存储系统有可能随时需要升级。当更新时，一定要知道在系统上会产生哪些影响。最后，如果选择数据和灾难备份产品，如自动让快照和复制。但要提醒的是，提防一些隐性成本，如带宽要求。它可能限制一些快照的次数或复制(即每次都要更改或整个复制的容量)。总结一下上面所说的三点就是表明了Hadoop具有的三种主要特性：1、 开源软件，没有使用限制；2、 扩展维护方便；3、 容灾体系简单明了。基于HDFS的原理，分布式存储，一写多读，可以利用大量廉价设备组建大规模存储等优势。但是HDFS从文件写入、同步文件到可以读取需要一定的时间（HDFS的后台寻址时间是每次搜索约20ms），所以并不适合对响应时间有很高的要求的应用。综上所述，适合存放于云存储的程序或文件包括：图片、网页、系统备份文件及已经归档的日志文件等。通过这个结论，我们可以将静态的页面文件，图片文件，应用和数据库的备份数据保存到Hadoop的云存储上，一方面目前HBase对于云存储的空间利用率较低，HDFS上有大量的剩余空间（如果按照目前的数据增量计算大概需要十多年才能使用完）。为什么不建议将常用的应用程序存到HDFS那？这是因为上面介绍过HDFS由于后台同步会造成响应时间的延后，而应用程序又是需要经常更新的，那么当对应用程序进行更新后，等待后台同步的时间很难把握，这段时间是不能对外提供服务的。鉴于此所以不建议将常用的应用程序存到HDFS。五、成功案例分析云作为目前最热门的概念之一已经被不少厂商所使用，其中不乏微软、阿里巴巴、google、facebook等重量级的企业，云和虚拟化的概念已经被更多的融合到了一起。目前公布了的云计算成功案例多数是基于日志分析的云计算平台，利用HDFS的分布式存储和大吞吐量的优势，对保存于HDFS上的日志文件进行日志分析，使日志分析的操作得到有效的速率上的提升，分析出来的日志信息可以提交给BI/BO人员进行进一步的数据挖掘，也可以提交给运维人员进行应用平台故障和潜在问题分析。淘宝在双十一期间利用HBase和MySQL等技术的案例及分析：Hadoop是离线计算平台，其中包括分布式文件系统（HDFS）和分布式计算（MapReduce），这本身是无法对响应时间做保证的。但是目前在Hadoop之上的生态系统越来越完善，其中HBase就是支持海量数据、高并发的在线数据库，应对这种场景就非常适合。HBase在这次双十一中与MySQL等在线数据库共同作为线上库使用，承担了重要的责任，并创下了并在全天高压力之下无故障的佳绩。另外非Hadoop生态圈的流式计算框架Storm、S4也同样可以为实时计算分担一定的压力。淘宝用HBase替换MySQL的一部分应用，这些应用自然是要符合HBase的应用场景（与MySQL对比），比如数据量大、对线性拓展有需求、对自动化运维（负载均衡）有要求而且应用模式简单。在支付宝中因其增长速度快，业务量大，造成了很多应用都是数据量庞大而且速度增长快，因此有一些应用迫切需要一个数据库能够支撑现在的业务而降低对关系型的需求，所以尝试了HBase的解决方案。在Hadoop的体系当中，支持实时的一条线，HBase，支持海量数据库初衷的时候，设计为了设计万亿级实时数据库，HBase这个东西经过这几年的发展，已经逐渐成为目前业界当中主要的实时数据库，分布式数据库，像支付宝直接上HBase系统，就是考虑到HBase的先进架构，能够帮助支付宝完成现在很多的海量数据的存储以及在线随机读写高性能的访问和存储。第一个是HBase本身在底层依赖的HDFS，加载了唯一一块数据，单台机器保证一致性，HDFS保持了冗余。第二点，恢复过程当中，Failover过程非常复杂，这个时间消耗越长，作为在线系统，这种时间越长可能会影响到在线访问用户体验。第三点它依赖的HDFS，HBase作为在线数据库依赖HDFS有故障的，经过几小时恢复提供生产业务，对业务方没有直接感受，作为在线系统如果挂掉，如果需要经过近小时恢复时间，恐怕就会直接收到自于支付宝外部的用户投诉了。HBase目前它自己的监控体系尚不完善，目前的监控力度非常得粗，只能监控到单台的Region Server的情况，看不到当前用户表有多少读写比例，看不到当前服务结点写作量多少，读出量多少。分析：整个案例的前半段给出了淘宝尝试HBase的几点前提，那就是：数据量大、数据增长量大这两点，其次就是自动化运维，应用模式简单等几个方面。后半段则是主要介绍了HBase的一些缺点和改进的地方：1、HBase过于依赖底层的HDFS的冗余2、数据恢复过程复杂且不透明。这里第一点主要表现了由于HBase很大程度上依赖于HDFS，所以当出现故障时要考虑是HBase的问题还是HDFS出现了问题，也就是间接的增加了问题点。而第二点则有因为恢复时间的过长很容易对用户的使用体验造成影响，甚至直接造成用户量的下降。所以淘宝在原生的HBase上进行了改进，完善了监控体系和单点故障。这里要强调一下，无论是阿里云、google还是百度等使用的Hadoop云计算平台都是经过他们内部开发部门通过二次开发过的，他们都有一个完整的Hadoop运维团队甚至是开发团队。因为Hadoop提供的并不是一个云平台的解决方案，而更像是一个云平台的框架。如果想要更好的使用Hadoop云计算平台，不仅需要对Hadoop提供的API接口进行研究，甚至还需要对MapReduce等程序进行二次开发来满足系统和业务的需求。六、发展方向1、SaaS方向首先先解释一下什么叫SaaS，SaaS是Software-as-a-service的简称，中文翻译有软件即服务、软件运营模式等多种称呼。SaaS主要目的是去掉了用户购买软件及相关硬件设备的成本，改成直接通过网络使用。减少了客户对于部分专用设备的购买和维护方面的成本，用户只需要购买使用权（先计费模式）或者通过其它的方式进行注册（后计费模式）后，通过某些认证方式登录到提供服务的网站就能使用相关的功能。用户可以利用认证方式登录到应用，在用户登录的同时，程序会根据用户的认证许可加载用户要使用的对应模块并加载用户自身的配置文件，这样可以比较方便的解决目前客户端模块和客户端本地设置上的差异问题。公司现有业务采用的是C/S架构，但是目前发现有可能存在着有的公司申报时可以申报，但是不会往报关数据统计服务器发送计费统计数据。这样就造成了计费信息不准确，甚至一直通过某些手段“免费”使用报关软件。SaaS架构的优势:1）服务的收费方式风险小：客户使用的客户端和服务器端其实都是在公司方，所有的用户操作都可以很好的保存在系统日志中，计费时也不需要用户提供相应的报文信息，而直接从服务的日志或者数据库中获取；2）产品更新速度加快：由于客户端在公司一侧，使得更新维护变得更加的方便，发布更新内容只需要一次对服务器的更新，所有用户都能直接使用最新版本的客户端；3）灵活启用和暂停，随时随地都可以使用：传统的C/S模式使得用户只有在固定的安装了软件的计算机上才能进行操作，很大的限制了用户的灵活性，比如：报关员在外出、请假的时候，如果需要报关，还需要回到单位利用单位的电脑才能进行报关的操作。而SaaS模式下业务人员甚至可以在家里通过认证模块（USB认证，口令认证，证书认证等）的信息认证就能登录服务器进行操作；4）大大降低客户的总体拥有成本：用户不用针对应用的需求购买特定配置的计算机或者是服务器，甚至不需要特定的IT管理人员。减少了用户身边的物理成本。甚至可以把用户在这部分原本应该投入的一部分转移到系统运营的收入中。可能存在的问题:1）发布更新不统一：往往都是按照地区单独发送。这样对于不同地区可能不能使用统一的客户端，不过这个问题可以通过CDN等IP识别技术或者直接在客户端内增加客户归属地选项列表进行解决；2）占用带宽的提升：对于服务器端的带宽压力会比现在有一定的提升，因为和C/S模式对比SaaS虽然不用再互联网上传递数据报文，但是在用户浏览器加载客户端是是需要消耗流量的。针对这个问题可以用目前Web游戏比较流行的伪客户端模式加以缓解。伪客户端模式就是将图片、模型、文字信息等占用流量比较大的内容做成客户端保存在用户的电脑上，用户运行客户端后，客户端需要连接服务器才能调用主程序。2、数据挖掘方向Hadoop这个应用本身的立足点就是离线数据库的数据分析和数据挖掘功能。基于目前线上业务的内容和方向，如果进行数据挖掘初期可以从业务覆盖范围着手，并可以从数据中提取出比较有商业价值的客户和申报频繁的类型、产地等数据。由于目前HBase中保存的数据是整个XML格式的文件，如果想要利用Pig或者Hive进行进一步的加工处理，首先需要对XML格式的文件进行解析。Hadoop自0.9X某个版本之后解除了对于XML文件读取和写入的支持，所以需要先利用Java程序对XML格式的文件进行分析处理（这里涉及到三种XML文件的解析方式：DOM、SAX、StAX）后在保存到Hive或者转存成标准格式的文件后用Pig进行提取分析。在完成XML文件的解析后就可以对报文进行进一步的数据挖掘了。除了可以对报文进行解析分析外还可以对应用程序（如：Tomcat、Resin和Apache）的日志（应用日志及访问日志等）利用一下两种工具进行分析：1、Pig应用程序日志数据的分析需要先用程序通过Pig调用MR（Map Reduce）将保存到HDFS文件系统中的日志文件加载到别名容器中，之后利用Pig调用MR对这个容器中的数据进行计算和统计，之后再合并返回出结果。然而MapReduce计算模型适合结构一致的海量数据，且要求计算简单。对于大量的数据密集型应用（如数据挖掘任务），往往涉及到数据降维、程序迭代、近似求解等等复杂的算法，计算非常困难。2、HiveHBase存储报文分析，因为HBase不支持SQL语句，虽然用NoSQL的数据分析方式也可以直接进行，但是这里可以和Hive合用，以达到对与高级SQL语言的支持。Hive主要的功能就是数据仓库，数据挖掘工程师可以直接使用BI工具对Hive中保存的静态数据进行数据分析。在分析完毕后，需要将结果传给关系型数据库以方便对结果进行展示。-