HBase Bug知多少

发表于:2014-2-17 11:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:sara    来源:51Testing软件测试网采编

#
Bug
分享:
  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的多数都是小概率问题,因为容易出现的问题在用户使用时都已发现,往往也较容易修复。不少同学会认为,这些并不是大问题,几乎可以忽略。可是经验告诉我们恰恰相反,在线上应用并不多的时候,一些极端场景就已出现过,因为我们的请求每天均以亿计,而且线上一旦出现故障就是非常复杂的场景,甚至可能超过测试系统的预估。稳定性并不是一天做出来的,不放弃任何一个小问题才能保证真正的稳定,希望与各位同仁共同努力。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号