【51CTO专稿】随着市场规模的扩大，产品与技术的发展，业务数据量越来越大，对海量数据的高效写入和读取变得越来越重要。 HBase 是一个分布式的可扩展、非关系型开源数据库。它很好地用 JAVA 实现了 Google 的 Bigtable 系统大部分特性，因此在数据量猛增的阿里巴巴非常受欢迎。本文中，阿里巴巴数据库技术专家朱金清（穆公）给大家分享了阿里巴巴 HBase 性能优化及容灾方面的经验。
（阿里巴巴数据库技术专家 朱金清）
以下是采访实录：
第一部分：阿里巴巴 HBase 集群介绍
51CTO：朱老师您好！首先请您简单地做一下自我介绍。
穆公：我是朱金清，在阿里的花名叫穆公，这个花名是我师兄取的，后来由于我们阿里武侠的花名都被取光了，只能取以前的皇帝的名字，我这个是以前的秦穆公，发音跟水工、电工、木工中的“木工”一样。我主要是做数据库相关的工作，来阿里巴巴之前，我在百度做 MySQL 。2011年年初来阿里巴巴了，主要做 MySQL/ HBase 相关的。
51CTO：阿里巴巴 HBase 集群的规模大概是什么样儿？
穆公：现在我们总共在线加离线是有上千台的机器，相对来说我估计应该算是国内比较大的。据我所知，百度好像不怎么用这个 HBase （早期的时候有用过），腾讯好像还没怎么听过。我知道有用 HBase 可能有几家：小米、360和新浪，大概是这样。我们这边单独的最大的集群在搜索，一个集群有二三百台左右。
51CTO：阿里巴巴这边 HBase 主要是用在搜索这个领域？
穆公：搜索的集群比较大，因为全网的日志我们要抓下来。不过很多场景都用到了，包括 kv 型行数据、append型的数据、日志业务、还要所有的历史数据，我们现在也都是放在 HBase 上。如果你是全部作为备份分析的，那就放云梯那儿，如果你要实时查询数据，或者是要查询历史数据，比如说我们的以往的订单，都可以用 HBase 。
51CTO： HBase 典型的应用场景有哪些？
穆公：主要有几种：
1、对高吞吐的写入有要求的；
2、日志型的应用；
3、有全网的数据抓取的；
4、有消息类的；
5、分析类的（如离线分析用 HBase 也是很好的选择，不过要跟在线分开）；
6、结构易变类的。
51CTO：阿里巴巴对 HBase 的改进和扩展主要在哪些方面？
穆公：比如我报告里面说的容灾方案 iback ，实现了跨机房容灾和异常切换等。还有我们后端团队也开发了 Replication 方案，然后在二级索引上我们的后端研发团队也一起来做了一个二级索引的这个策略，这个二级索引现在在社区都还没有怎么用，以前好像就是听华为有一套二级索引，然后我们现在就是在这方面做，就相当于对它功能的一些完善。然后就是说 HBase 要走得更远的话，那可能跨机房容灾可能一定要做好，这一点我们也投入精力，现在看 Facebook 基本上也朝着这方面，基本上他们也是这么做，所以我觉得我们方向应该是比较对的。
51CTO：你们这边有借鉴 Facebook 的经验吗？
穆公：有， Facebook 在 HBase 上打的 Patch 也比较多，我们可以直接把Patch拿过来，可能有一些能用，有一些不能用，我们就根据自己公司的实际情况，进行改进。我们跟 Facebook 沟通还是比较多的，上上周我去美国跟他们一起交流了这个，收获还是很多的。
当然就 Facebook 来说，它是一个SNS的应用，应用可能相对单一一点。淘宝阿里这边，又有交易，又有买家、卖家，是一个多维度的，相对来说，需求比较复杂多样化。 Facebook 比较好，它的应用和产品没那么复杂，把产品优化做到极致。在这方面，我们可能需要更多的学习一下。
51CTO：阿里巴巴的 HBase 跟 Facebook 的 HBase 主要的相同点和不同点分别是什么？
穆公：相同点：我们对 HBase 做事上的风格比较类似，组织结构也都蛮像的，有开发的团队，有运维团队；
不同点：我们比 Facebook 多了一个角色，我们有设计评审，相当于有点DBA的角色在里面，而 Facebook 可能是没有太多这样的。
阿里和 Facebook 都非常注重高可用和性能， Facebook 也在高可用上投入了很多的精力，阿里也如此。但是在性能上，阿里投入精力还可能不见得有那么多，这一点上我们需要根据自己的情况来弥补。#p#
第二部分：阿里巴巴 HBase 性能优化和容灾经验
51CTO：阿里是如何做好 HBase 性能优化的呢？
穆公：我觉得主要有几部分，第一个就是说我们在一个业务上，因为性能优化不是说你上线了之后去优化，这是一种优化。还有一种优化就是说上线之前，我就帮它决定好，这个东西可能用什么样的存储更好，有可能比如说这个用了之后， HBase ，我们也注意了，以前可能不清楚 HBase 用了之后，可能性能还没有多好，换了一个其他还更好，其实这主要是在于选型阶段要做好。要确定好哪个是最合适的方案，这个我觉得是一个评审的优化，还有一个就是到底每一台机器的性能的优化，每一台机器性能优化，我们相当于算是上线之后的优化了，我们分为两个方面，一个就是有硬件的解决方案，我们现在也有上 SSD 这个硬件，然后来提高随机读的性能，因为 HBase 随机读性能相对来说是比较一般的，而 MySQL 我觉得达不到那么好。还有一个就是相当于我们在进程，在 HBase 这个代码上面进行优化，比如说我们现在也有后端的研发团队也有做了二级索引的方案，就是提高这个读查询的性能，然后在代码上面做了一些。刚才说了一个软件一个硬件，现在我们也有软硬件结合的方式，就是说这个代码改了，然后用了 SSD 或者 FusionIO 这种硬件，然后让它的读取，就相当于查询很好。
51CTO：有效地提高读取的速度？
穆公：对，因为 HBase 现在写性能很好，它需要更多做的是读的性能要做得更好，所以慢慢可能是相对来说一个性能优化的一个更主要的一个地方，可能在读取上。
51CTO：在做 HBase 性能优化的时候，主要注意事项有哪些？
穆公：一个就是说可能你对代码能不清楚的话，我们可能尽量建议简单的需求不要直接通过进入代码来搞定，如果说在外围或者配置参数能搞定的话，直接外围或者配置修改来搞定。因为这样的话，我可能升级代价也小，就是相当于如果能从外围和配置搞定的，不从 HBase 底层就能搞定，我们建议在外面直接搞定。所以现在有一个优先级，如果必须得通过代码改名，那就得这个代码进来以Patch的形式，在不同的版本上都可以用，大概是这样。性能优化还有一个就是说我们也希望说这个不是说什么场景我都去优化，就是对通用的，比如说这个东西做了一点就能很多集群都能提升，那这个产品我们更倾向通用问题的解决。
如果只是说对特殊产品的优化，我们可能会更倾向于推动应用一起来做优化，因为不然的话，可能会造成成本压力，我需要买那么多机器来搞定一个业务，那就代价太大了，所以我们需要更通用的，这个东西解决的是一个共性的东西，这样就比较好。
51CTO： HBase 在容灾方面的一些经验，您能否分享一下？
穆公： HBase 的容灾，因为从需要其实我们还没有容灾上线，因为 HBase 如果你做一个离线分析，它其实不用管容灾不容灾，因为离线一存一分钟两分钟没有问题。如果你要做一个在线存储，它就对这个可用性，服务持续性要求就很高了，所以我就觉得如果你要把这个东西做好，你容灾一定要做好，容灾现在有几种，内部可能国内我们现在有容灾，因为社区原来自带的容灾方案不好使，好像有一个限制是说储备机器要一样，这个不可能的，如果我这边扩了两台，那边也必须扩两台，代价太大了。所以后来我们用的时候，我们倾向于从外围来做，就是要做容灾的话，就像MySQL一样，如果MySQL有一个自带的Replication并不是容灾，因为容灾还有数据一致性，然后服务切换之后，就是说数据同步这是一部分，就是说如果你一层切换之后，数据一致性显得更重要，所以这个东西是从 HBase 内部做不好。所以我们现在有自己做了一个，还有 Facebook 他们也自己做，我们思路是一样的，我们并不知道他们具体产品叫什么，但是思路大概类似。
51CTO：在部署 HBase 时，哪个环节比较容易出故障？
穆公：因为它是一个分布式集群，所以单点故障率会比较高，就是一台机器一层，比如说一个分布是有十台机器，一台机器挂了，这个是正常的，因为它是一个分布式，它能自己恢复，但是这中间需要时间。还有一个就是因为 HBase 现在还是快速发展中，它代码等等有一些 Bug ，这个肯定我们以前也都遇到过，来了一个 Bug 又出现问题，所以这样就导致你需要去把这些方面都考虑到，所以就相对来说，这些都是需要我们去注意的一个地方。
51CTO：一般故障出现最多的情况是？
穆公：我们最多的情况还是单机的故障，因为现在还算是比较稳定了，基本上如果我们用最新版，有可能会有问题，但是我们用相对稳定的版本，基本上还好，但是相对稳定的就有另外的问题，它可能性能并不是那么佳，但是因为集群那么多，又不可能说对每个集群都做一个升级，升级代价也会比较大，我们倾向于说每年会推一个大版本，第二年之后就新的业务上来了，我们就用新的版本，原来有一些需求需要升级的话，我们就把它升级掉。
还有就是 HBase 现在因为它的这个升级时间也稍微代价有点大，并不是说每个马上就能升级，数据量也很大，然后一般现在在这个比如说我在升级过程中，有一些相应就会有波动，所以这些都需要导致我们不可能说所有的集群一下都升级了，我一直对这些重点的，有一些可能我觉得再加一两台机器能搞定，我们就倾向于这种方式来，就是这样，所以我觉得这个代价是在可控的，而且还相对来说，有一些时候往往用硬件能解决问题，它其实我觉得代价还算是比较小的，因为这个集群的升级，它其实牵动的能力，比如开发也要帮忙配合一起来做，其实耗费的整体也是非常大的。#p#
第三部分：如何加入阿里巴巴 HBase 团队？
51CTO： HBase 能否成为NoSQL领域的领导者？您是怎么看待这个问题的？
穆公：我觉得就目前来说，为什么我们选择 HBase ？一方面我觉得它比较通用，它基于Hadoop之上，本身它就有一个先天的优势，然后还有一个，它确实的写入的性能还是很好的，读取性能，你说现在说没有那么好，但是我觉得也还可以了，只不过说我们现在读业务，要求做到更极致的时候，不可能说机器成倍的长，我们所以需要做一些优化。然后现在的使用接口提供，或者功能各个方面，都是很完善的，所以在NoSQL上，特别是你要说持久化的NoSQL，就是 HBase 它是NoSQL，同时也支持持久化，就是不是NoSQL那种缓存系统，支持可以持久化的NoSQL，我觉得现在主流的，比如说像 cassandra ，还有MongoDB也算NoSQL，MongoDB确实量上亿了之后，基本上性能就不怎么样了， cassandra 之前有说，我觉得 cassandra 跟 HBase ，可能目前还是会是NoSQL里面，可能更大的两个。但是 cassandra 之前也说了，它有不同的特性，它可能对一致性做得不好，但是它对可靠性要做得好，所以这个需要权衡。有可能像我们阿里三淘的业务等等，可能一致性就很高了，可能有一些比如说我说是其他一些离线分析或者等等这些，它可能延迟那么一点点也没有问题，我觉得这种用 cassandra 也是很好的，我这次去国外一看，他们也有一些东西，还用的 cassandra ，对在线服务的一致性要求不高， cassandra 还是用得很好的。
现在就是说 Facebook 自己不用 cassandra ，这也说明释放出了一个信号，可能说这个东西可以用，但是可能它相比较来说， HBase 更好一些，因为社区也更活跃，就是 HBase 现在还一直在发展，但是 cassandra 现在版本迭得很慢了，之前我看的是0.8还是多少，现在可能版本就没有迭得那么快，因为开发 cassandra 的 Facebook ，他现在不怎么用这个东西， HBase 现在社区还是非常活跃的，然后去国外看的时候，Twitter也在用， Facebook 更不用说了， Facebook 应该是国外我估计用这个最大的，我们应该可能算是国内最大的，目前我还是不知道有哪个公司用得比我们更大，单说机器应该没有，然后容量等等之类的，然后 ebay 也有用 HBase ，ebay 好像搜索也是用 HBase ，然后 Twitter 具体我还真不知道，它那些消息还是什么，我不知道它具体存在哪里，但是 Twitter 他们说最近很紧急的需要招人， HBase 这方面也要招人，重点说了这两块，所以基本上就是 HBase ，我觉得前景还是非常好的，基本上我觉得还是可以在近几年还是会是最核心的一个 NoSQL ，我觉得近几年应该是这样，可能多年之后，会不会有一个新的 NoSQL 浪潮冲击一下，那也是有可能的。
就目前而言， HBase 应该是在 NoSQL 里面发展前景比较好的，我也比较看好它。
51CTO：如果想加入阿里 HBase 这个团队，需要具备哪些方面的素质，或者技术要领？
穆公：其实我们很缺 HBase 这方面的人才，如果大家有什么问题，可以私下聊，也可以联系我，我们现在这个要求说高也蛮高的。
如果应届生其实也还好，但是社招的话，我们一般要求就是说要有至少三年以上JAVA的一些开发能力，我们觉得这边做下来，可能更多的是开发的工作，运维也需要开发东西来做，所以我关注的是以开发来解决 HBase 这个整体运维或者大规模云计算，都是以开发来解决这个问题，所以我觉得我更看重 JAVA 一些开发能力，如果有 Hadoop 的一些基础，就是最好了。然后对网络 TCP 协议之类的，要有一定的理解，网络资源 RPC 的调用，还有其他就是最好也能写一些脚本这样子，要处理一些运维的事情。但是我觉得更关键的是好学，学习能力强，这个相对而言可能还更重要，如果 Hadoop 基础你没有，你够聪明也没有问题。
其次人比较踏实，有技术追求，我觉得就可以了，应届生应该主要以这种为主，因为应届生他可能不见得会有Hadoop跟 HBase 的经验，但是我觉得它只要有JAVA的开发能力，然后自己有这方面的追求，我们阿里可以培养，欢迎这样的优秀的应届毕业生加入我们。
好的，专访到此告一段落，非常感谢穆公的分享。
