HBase在阿里集团大规模使用已经有一年多时间了，随着online应用越来越多，对HBase的稳定性、实时性、可维护性要求越来越高。在业界HBase的发展也越来越快，每次技术论坛无疑都成为主角，但很多同学都还有疑惑：HBase真的靠谱么？在核心应用能大规模使用么？下面我从测试的角度，分析下我们发现的bug，通过这些问题来了解HBase的发展现状和淘宝在稳定性上所做的一些工作。
　　HBase在阿里
　　目前阿里集团重点维护了2个版本：0.90和0.94。其中0.90为稳定版，适用于数据量并不太大（TB级），不是太关心coprocessor等新特性，对稳定性要求很高的应用。0.94为新特性版本，拥有更高的性能和社区新新特性，适合数据量巨大（PB级），需要尝试新特性的应用。通过0.94的维护，我们也为社区新代码提供了很多patch，推动社区发展。
　　HBase Bug 知多少
　　到目前为止，我们共发现bug 328个，其中Blocker 34个，Critical 41个，Major 205个， Minor 48个。提交官方社区patch 58个，其中其中Blocker 1个，Critical 9个，Major 44个， Minor 4个。从数字上看bug的确很多，但并不是说HBase不稳定，通过这么多bug的fix，我们解决了非常多极端小概率场景、异常场景的问题，预防了很多bug的上线，丰富了工具、日志、监控、运维工具等等，使得HBase稳定性提高到了新的高度。
　　HBase 哪里不靠谱
　　HBase的开发、测试、运维人员以及用户，恐怕关心的是HBase到底靠不靠谱，哪里问题多。好吧，我将发现300多个bug分了14类，通过下面的图表，可以清楚的看到风险大的模块，这些模块同样也是我们投入工作多的内容。
　　1、region assign：region分配相关，由于是分布式事务，在异常情况下出现bug的概率很高，也是发现bug多的部分，常见故障为region二次分配、长时间不分配、ROOT META表分配异常、master多个处理线程冲突等。可以导致region无法服务或者数据丢失。
　　2、compact：compact部分总体上看是相当稳定的，由于实现较简单并没有太多bug，淘宝在compact方面加入和很多策略（多线程、错峰）来适应线上系统的需求。
　　3、split：bug重灾区，原因也是由于他是个一个复杂的事务，并且需要回滚。在0.90中我们还无法完全弃用split，因此这些bug必须得到修复而不能通过运维来避免，目前已经相当稳定。
　　4、flush：实现较为简单，在控制部分有些bug。
　　5、correctness：读写行为的正确性，是HBase为核心的部分，目前官方0.90和0.94版本都有部分正确性问题的bug，尤其是0.90版本中读写原子性上还有问题，但是出现概率很低，场景也较为极端，一般应用很少会遇到。在后续版本也考虑进行彻底的fix。社区现在还没有打算在0.90上彻底修复。
　　6、wal：日志是HBase的核心功能之一。常见bug存在于分割日志和恢复日志两部分，导致数据恢复不正确及数据丢失。另外在线上日志分割速度也是故障影响时间的决定因素，在这方面也投入了不少精力进行测试和优化，目前已经有了非常理想的效果。
　　7、ddl：HBase中常用ddl操作是create table、disable、enable、alter。在进行这些ddl操作时如果系统发生异常很可能无法得到正确的处理，目前社区也没有修复完毕。
　　8、abort：HBase中有很多异常发生都会导致server abort，尽量缩减和避免这些场景发生也是保证系统稳定的一大手段。因此做了不少修改避免了不应该发生的abort行为，并且修复了abort行为发生后的一些bug。
　　9、zk：0.90版本中针对zk发生异常的处理很弱，基本可认为无抵抗力，在0.94社区已经做了较多改进。但是从我们测试情况来看，过度依赖zk还是会被zk的一些自身问题牵绊，导致系统不稳定。
　　10、client：总体上说client还好，使用0.90.6以后版本和0.94.2都能保证较高的稳定性。0.94前期版本含有较多致命bug，还需要慎重使用。
　　11、replication：HBase自带的replication部分不是很满足淘宝线上应用的需求，我们对这部分做了较多重构，目前还在准备上线中。
　　12、gc：gc的bug主要来自不适合的gc配置引起的fullgc或者gc频繁。出现fullgc后系统会有一些不稳定的地方，在代码上做了一些保障来防止发生fullgc对系统的致命影响。
　　13、testcase：接触HBase单元测试的同学肯定会发现其实官方提供的case很多并不稳定，我们做了一些排查和修正，避免了不合理的偶然失败出现。
　　14、tools&other：主要是一些运维工具和脚本、监控、日志等。为了加强HBase的可运维性，淘宝做了很多建设性的事情，比如建立了完善的监控体系，而且正在建立一套trace工具来跟踪一些可疑请求以及分析线上系统性能。
　　从线上看Bug
　　对于HBase这种存储系统来说，对外接口相对单一，但是内部实现较为复杂。这种特性决定了我们发现bug的多数都是小概率问题，因为容易出现的问题在用户使用时都已发现，往往也较容易修复。不少同学会认为，这些并不是大问题，几乎可以忽略。可是经验告诉我们恰恰相反，在线上应用并不多的时候，一些极端场景已出现过，因为我们的请求每天均以亿计，而且线上一旦出现故障是非常复杂的场景，甚至可能超过测试系统的预估。稳定性并不是做出来的，不放弃任何一个小问题才能保证真正的稳定，希望与各位同仁共同努力。