滴滴在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的客户端多路读功

2020年来，为提升HBase可用性，我们大体经历了两个阶段：

1. replication主备

replication是HBase的异步数据同步机制，和Mysql利用Binlog实现主从库类似，HBase利用WAL实现主备集群的数据同步。大致流程为主集群记录写入的WAL，并将数据异步发送给备集群，备集群接收数据并将其转换为put/delete操作，批量写入备集群。提供最终一致性保证。

图片来源：HBase官方文档

detailed_information_about_cluster_replication

这一阶段存在的问题：

• 故障时用户有感知ÿ