代志远早年就职网易研究院从事MapReduce与DFS系统的自主研发，后增加支付宝数据平台负责Hadoop与HBase体系的架构设计与二次研发，支付宝流计算与分布式搜索系统的设计和研发，后成为支付宝海量计算体系架构师兼支付宝三代架构成员。现就转战于阿里巴巴集团-CDO-海量数据部门。负责创新性项目的研究和跟进，眼下专注于Google第二代数据库产品MegaStore的研究和在阿里的落地。
在即将召开的HBTC大会中。我们有幸邀请到代志远作为我们的演讲嘉宾，请他分享下阿里巴巴在海量数据分布式数据库领域的探索。我们也对他提前做了邮件採訪，让用户能够更快地了解阿里巴巴海量数据分布式数据库以及在Hadoop应用领域的实践。
阿里巴巴海量数据部门: 代志远
CSDN: Hadoop眼下是大数据处理领域的王者，你觉得中小企业应用Hadoop的瓶颈在哪里？
代志远：首先由于Hadoop本身机制复杂，所依赖的參数配置颇多。并且Hadoop须要像数据库一样稳定，满足性能的执行，就须要运维人员如同DBA一样要懂网络、磁盘、内核以及其它一些硬件知识。这对于运维人员的要求是比較高的。其次Hadoop社区蓬勃发展，生态圈不断扩大。用户不断增多，规模极限也不断突破。这就促使了Hadoop的架构和代码发展非常快并且变更也比較快。正由于如此，系统在高速发展的时候easy引入非常多的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语言实现了系统其中大内存管理本身存在问题，除非革新这门语言，否则别无他法。假设说在设计的參数不合理，就可能会导致一个问题。有可能这台server就会停止执行，发生这么一次情况就很可怕，几十G的内存这个过程须要几十秒甚至上分钟，通常情况下。我们会设置到3分钟，这就意味着，为了避免出现这样的问题，就会同一时候引入新的问题，宕机之后恢复等待时间须要三分钟。
第二个关键流程其中，当它感知到已经挂掉了，在线数据库协助WL数据又一次做到存储其中去，以保证实时更新是同步，否则这个数据库肯定要丢出去，重做数据过程其中。会有一个过程，Split Hlog。跟当前数据量有关系，Edit Log数据又比較多。大家在业余时间能够进行測试。数据不以支付宝的为准，以当前数据系统大小为准。
第三个关键流程。重做完数据之后，这部分又一次上线，上线之前进行数据进行二次扫描，告诉系统。Region怎么增加到Region Server其中去，扫描也存在问题。问题可能引发到两分钟到6分钟。这也跟当前系统数据有关。第四部分，这个过程称之为再次上线的过程，这个再次上线，上线时间跟当前这台机器的Region上线有关系。
支付宝面对消费记录查询，用户查不出来数据。15分钟之后才干查到，在面临在线问题上这是很可怕的事情。
针对Region Server这一关键流程。做了一些优化。这个优化正是提到关键流程第一点。在推断宕机超市的情况下，不强依赖于Zookeeper，支付宝又启动了监控进程Mirror Process。每一台，Region Server其中都会起到PID存不存在，这样的检查并不是全然可靠。当检查PID不存在。就有理由觉得已经挂掉了，要进行可靠检查，通常DBA在线推断数据库是否可用。一般会用PIng连续服务port，这就弥补了系动中的调用命令不可靠的事情。最后当发现服务port不可用时。有理由觉得当前进程已经死掉了，死掉了之后。那么就依照现有逻辑删除结点，这三分钟的时间就全然省略掉了。