hbase是否能取代mysql

    代志远早年就职网易研究院从事MapReduce与DFS系统的自主研发，后加入支付宝数据平台负责Hadoop与HBase体系的架构设计与二次研发，支付宝流计算与分布式搜索系统的设计和研发，后成为支付宝海量计算体系架构师兼支付宝三代架构成员。现就转战于阿里巴巴集团-CDO-海量数据部门，负责创新性项目的研究和跟进，目前专注于Google第二代数据库产品MegaStore的研究和在阿里的落地。

    在即将召开的HBTC大会中，我们有幸邀请到代志远作为我们的演讲嘉宾，请他分享下阿里巴巴在海量数据分布式数据库领域的探索。我们也对他提前做了邮件采访，让用户可以更快地了解阿里巴巴海量数据分布式数据库以及在Hadoop应用领域的实践。

阿里巴巴海量数据部门: 代志远

CSDN: Hadoop目前是大数据处理领域的王者，你认为中小企业应用Hadoop的瓶颈在哪里？

代志远：首先因为Hadoop本身机制复杂，所依赖的参数配置颇多，并且Hadoop需要像数据库一样稳定，满足性能的运行，就需要运维人员如同DBA一样要懂网络、磁盘、内核以及其他一些硬件知识，这对于运维人员的要求是比较高的。其次Hadoop社区蓬勃发展，生态圈不断扩大，用户不断增多，规模极限也不断突破，这就促使了Hadoop的架构和代码发展非常快而且变更也比较快，正因为如此，系统在快速发展的时候容易引入很多的Bug和一些缺陷（可能因为稍稍的使用不当或比较小的问题就引起整体性能和稳定性的波动）。更重要的是，Hadoop代码复杂，而且需要与社区接轨，能够找到对Hadoop源码熟悉并能优化升级和bugfix的人才是很难的，这对于一个公司的研发来说是个很大的挑战。最后一点是公司的认知，除了类似Cloudera、MapR之类的软件公司需要对软件技术负责，其他多数公司无论大中小都依赖于公司业务，尤其中小公司业务压力大、人员紧张，能够从业务研发人员中抽调或通过其他方式组建专有的Hadoop运维团队甚至是研发团队，从公司规划与发展上来说是比较困难的事情。

CSDN: Hadoop的本质是为全量而生，就是说它重吞吐量，响应时间完全没有保障，那么对于像淘宝、天猫在“双11”活动抢购的时候，需要实时处理数据（可能是毫秒级，秒级的响应），是如何进行实现的？

代志远：Hadoop是离线计算平台，其中包括分布式文件系统（HDFS）和分布式计算（MapReduce），这本身是无法对响应时间做保证的。但是目前在Hadoop之上的生态系统越来越完善，其中HBase就是支持海量数据、高并发的在线数据库，应对这种场景就非常适合。HBase在这次双十一中与MySQL等在线数据库共同作为线上库使用，承担了重要的责任，并创下了并在全天高压力之下无故障的佳绩。另外非Hadoop生态圈的流式计算框架Storm、S4也同样可以为实时计算分担一定的压力。

CSDN: 你在云计算大会时做的一场有关HBase的报告，主要讲如何用HBase替代MySQL，HBase对比MySQL的优势在哪里？

代志远：准确来说是HBase替换MySQL的一部分应用，这些应用自然是要符合HBase的应用场景（与MySQL对比），比如数据量大、对线性拓展有需求、对自动化运维（负载均衡）有要求而且应用模式简单。在支付宝中因其增长速度快，业务量大，造成了很多应用都是数据量庞大而且速度增长快，因此有一些应用迫切需要一个数据库能够支撑现在的业务而降低对关系型的需求，所以尝试了HBase的解决方案。

CSDN: 阿里巴巴在部署Hadoop的过程中有哪些比较好的经验可以跟技术人员分享？

代志远：最重要的是要有一个完善团队，健全的流程。

• 集群越来越大，要树立以集群稳定性和性能为要领的工作思路。
• 现在进入Hadoop应用开发领域的人变多，但本身知识因其入行早晚而积累不同，无法对集群的稳定性负责，常常会写出跑死集群的任务（数据库中SQL使用不善也常会如此）。因此要有一个较好的管理流程约束开发人员做到责任分明，以便促使应用开发不仅要对自己的任务负责还要对集群负责，不断学习和检查减少故障的产生。
• 要有一个好的运维团队，懂硬件、重流程、负责任。
• 公司在资源和战略上应有所倾斜，重视研发人员加强在研发的投入，毕竟分布式系统的入行门槛相比应用开发的技术门槛要高，当然有好的应用架构师能够取长补短规避大多数问题也是可行的，但单一系统的稳定性还是需要靠人来保证。

CSDN: 请您简要介绍一下本次HBTC2012大会上的议题的内容。

代志远：06年Google发表论文Bigtable，社区随之出现HBase，后Google 08年发表第二代数据库产品MegaStore至今未有社区同类产品出现，现今Google又出现新一代数据库理论Spanner和F1。 而最近几年随之Bigtable和NoSQL的兴起，社区产品HBase逐步走向NoSQL系统的主流产品，优势明显然而缺点也明显，大数据平台下的业务由SQL向NoSQL的迁移比较复杂而应用人员学习成本颇高，并且无法支持事务和多维索引，使得许多业务无法享用来自NoSQL系统中线性拓展能力。

Google内部MegaStore就作为Bigtable的一个补充而出现，在Bigtable的上层支持了SQL，事务、索引、跨机房灾备，并成为大名鼎鼎的Gmail、Google App Engine、Android Market的底层存储。因此我们决定以MegaStore为理论模型进行探索如何在HBase系统上不牺牲线性拓展能力，同时又能提供跨行事务、索引、SQL的功能。

HBase系统故障恢复的优化实践

    其实在第四届中国云计算大会上，当时还在支付宝数据平台的架构师代志远就为大家带来了题为“HBase系统故障恢复的优化实践分享”的精彩演讲，他分析了支付宝海量数据在线处理的现状，以HBase解决方案取代传统MySQL解决方案的技术历程，并详尽分享了Region Server的宕机恢复流程（阅读全文）。

    在Hadoop的体系当中，支持实时的一条线，HBase，支持海量数据库初衷的时候，设计为了设计万一级实时数据库，HBase这个东西经过这几年的发展，已经逐渐成为目前业界当中主要的实时数据库，分布式数据库，像支付宝直接上HBase系统，就是考虑到HBase的先进架构，能够帮助支付宝完成现在很多的海量数据的存储以及在线随机读写高性能的访问和存储。

    不过在HBase的系统当中，体现它的可用性有几个风险。第一个是HBase本身在底层依赖的HDFS，加载了唯一一块数据，单台机器保证一致性，HDFS保持了冗余。第二点，恢复过程当中，Failover过程非常复杂，这个时间消耗越长，作为在线系统，这种时间越长可能会影响到在线访问用户体验。第三点它依赖的HDFS，HBase作为在线数据库依赖HDFS有故障的，经过几小时恢复提供生产业务，对业务方没有直接感受，作为在线系统如果挂掉，如果需要经过近小时恢复时间，恐怕就会直接收到自于支付宝外部的用户投诉了。HBase目前它自己的监控体系尚不完善，目前的监控力度非常得粗，只能监控到单台的Region Server的情况，看不到当前用户表有多少读写比例，看不到当前服务结点写作量多少，读出量多少。

    Region Server在恢复过程当中有几个流程，这个流程很复杂，流程非常非常多，以当前的系统规模，它凸显出来的问题，这几个流程是影响到它的恢复速度的关键流程。等待时间周期非常长，周期之所以比较长，是因为现在的机器发展速度非常得快，每台机器从两个G到8个G，96G，140G的大层次的机器，Java语言实现了系统当中大内存管理本身存在问题，除非革新这门语言，否则别无他法。如果说在设计的参数不合理，就可能会导致一个问题，有可能这台服务器就会停止运行，发生这么一次情况就非常可怕，几十G的内存这个过程需要几十秒甚至上分钟，通常情况下，我们会设置到3分钟，这就意味着，为了避免出现这种问题，就会同时引入新的问题，宕机之后恢复等待时间需要三分钟。第二个关键流程当中，当它感知到已经挂掉了，在线数据库协助WL数据重新做到存储当中去，以保证实时更新是同步，否则这个数据库肯定要丢出去，重做数据过程当中，会有一个过程，Split Hlog，跟当前数据量有关系，Edit Log数据又比较多，大家在业余时间可以进行测试，数据不以支付宝的为准，以当前数据系统大小为准。

    第三个关键流程，重做完数据之后，这部分重新上线，上线之前进行数据进行二次扫描，告诉系统，Region怎么加入到Region Server当中去，扫描也存在问题，问题可能引发到两分钟到6分钟，这也跟当前系统数据有关。第四部分，这个过程称之为再次上线的过程，这个再次上线，上线时间跟当前这台机器的Region上线有关系。支付宝面对消费记录查询，用户查不出来数据，15分钟之后才能查到，在面临在线问题上这是非常可怕的事情。

    针对Region Server这一关键流程，做了一些优化。这个优化正是提到关键流程第一点，在判断宕机超市的情况下，不强依赖于Zookeeper，支付宝又启动了监控进程Mirror Process，每一台，Region Server当中都会起到PID存不存在，这种检查并非完全可靠，当检查PID不存在，就有理由认为已经挂掉了，要进行可靠检查，通常DBA在线判断数据库是否可用，通常会用PIng连续服务端口，这就弥补了系动中的调用命令不可靠的事情。最后当发现服务端口不可用时，有理由认为当前进程已经死掉了，死掉了之后，那么就按照现有逻辑删除结点，这三分钟的时间就完全省略掉了。

原文：http://blog.csdn.net/cqboy1991/article/details/26366781