HBase性能 | 滴滴在HBase性能与可用性上的探索与实践

HBase性能 | 滴滴在HBase性能与可用性上的探索与实践

桔妹导读：HBase作为Hadoop生态中表现较为突出的分布式在线数据存储产品，在滴滴有着非常广泛的应用，但同样存在比较突出的短板问题——例如可用性较弱、毛刺严重等，一定程度上限制了它的业务边界。本文主要介绍在此背景下，HBase团队近期进行的一些探索工作。

1.

背景

HBase 是一个基于 HDFS 的低成本、分布式LSM结构数据库，可以支持毫秒级别查询；支持海量的PB级的大数据存储，适用于高QPS的随机读写和前缀范围查询等场景。此外，优秀的开源环境使得HBase还可以支持丰富的上下游生态与离线任务。

目前在滴滴内部，HBase基本覆盖了全部业务线，数据量PB规模，吞吐超千万级别；业务包含司乘轨迹、订单、特征工程、推荐引擎、IOT、APM等各种场景，基于HBase的多模生态诸如OLAP（Kylin）、时序（OpenTSDB）、时空（GeoMesa）、图（JanusGraph）亦均有应用。

2020年下半年，HBase团队逐渐将视野投向端上/类端上业务，希望能够承载更加重要的流量。然而对于HBase自身架构和实现而言，主要存在两方面痛点：

▍1.可用性问题

架构层面看，HBase在CAP定理中选择了C，以较弱的可用性为代价换取强一致性，数据层面依赖HDFS保证数据安全，计算层面region无副本。这样当region迁移、分裂、合并、RS宕机等情况发生时，对应region都会有短时不可用；而作为高吞吐的数据服务，客户端往往都会大量使用线程池，少量region不可用会迅速形成木桶短板，进而放大为整体TPS掉底。而这种“预期内的”抖动、掉底，是无法满足互联网行业端上场景的可用性要求的。社区提供的region replica功能一定程度上可以缓解这一问题，但一方面目前这个feature可靠性还不算高，社区仍在推进各种加固和改善，目测稳定的目标release版本可能要放到未发布的3.0了；另一方面端上服务需要双机房，保证容灾和降级，而replica是集群内的region副本，显然也不能支持。

▍2.毛刺问题

HBase主要受Java GC和底层HDFS共用影响，HBase的毛刺相对突出，是进一步提升性能的瓶颈点。 基于以上两个痛点问题，HBase团队近半年进行了一些尝试与探索，主要是基于 replication的客户端多路读功能 与 HBase-ZGC应用实践，预期能够优化HBase的可用性与毛刺问题，简单分享给大家。

2.

基于replication的客户端多路读功

▍1. 设计

整体设计参考HDFS的hedgedRead功能，客户端首先向主集群发起读请求，一定时间没有返回结果则并发向备集群发起请求，两者取先完成者返回。

实际上HBase的regionReplica也是类似的实现。

▍2.新增配置

▍3.性能测试

3.1 用例设计

Scan场景下，ZGC的P99延迟降低20%，P999降低40%。

2、压力测试场景对比ZGC和G1的性能表现

构造写压力测试场景，RegionServer的全局Memstore写满，触发Upper Limit，G1GC回收不过来，触发Full GC，耗时超过40s（ZK会话的超时时间），RS服务会宕机。

对比同等写入压力下，ZGC 99.93%的回收时间都在10ms以内，只有2次在10~20ms之间，RS服务未宕机。

备注：如果内存分配过快，ZGC也可能会出现回收不过来的问题，这种情况下可以通过增大堆内存的方式缓解。

HBase使用ZGC可以有效的降低了服务端P99及P999的延时，非常适合对延迟较敏感的业务场景。

3.

总结

HBase在真正海量数据的离线应用场景下具备毋庸置疑的竞争力，但受其自身实现短板的限制，距离端上应用的标准还是存在一定距离的。滴滴HBase希望通过一系列优化手段，服务好离线业务的同时，未来可以接入更多的不涉及核心流程的线上/类线上业务，欢迎感兴趣的同学一起交流。

本文作者

延伸阅读

▬

内容编辑 | Teeo

联系我们 | DiDiTech@didiglobal.com