“十年磨一剑”--有赞的HBase平台实践和应用之路-阿里云开发者社区

在中国HBase技术社区第十届meetup杭州站中，有赞数据开发工程师赵原向大家分享了HBase在有赞的产品定位，重点介绍了有赞HBase和相关管控平台的研发建设、以及在HBase 1.2.6版本之上所做的改造、改造原因以及给业务实践带来的价值。

以下内容根据演讲嘉宾视频分享以及PPT整理而成。

本次的分享主要围绕以下三个方面：
一、产品定位
二、管控平台建设
三、改造与业务实践
四、未来展望

一、产品定位

有赞目前拥有自己的大数据平台团队，主要负责维护基础设施所有的基础组件，整体分为两方面：计算和存储。计算分为实时计算和离线计算，其中离线计算部署了Hive和Spark等，实时计算分别维护了Spark Streaming和Flink。目前，有赞使用的存储产品主要是HBase。

HBase在有赞的产品定位是存储，主要分为四方面：

• 在线存储：HBase提供多集群云端存储和在线实时访问功能。
• 离线存储：支持离线数据批量导入导出，非敏感数据的实时读取以及线上重要数据的冷备。
• 监控数据存储：存储OpenTSDB组件获取的监控数据，监控数据源自有赞的日志系统“天网”。
• Kylin存储：存储Kylin的准实时数据。

下图展示了有赞基于HBase存储的集群规划，主要包括四个集群：

• 在线服务主、备集群：二者之间存在复制通路，互为主备；
• 离线集群：打通了与在线服务备集群之间的单项复制通路，可以做在线服务备集群重要数据的冷备；
• 日志业务独立集群：日志业务量大，为避免影响其他线上业务，将其作为独立集群，专为日志服务。

二、管控平台

有赞在应用HBase之初面临一系列痛点问题：

混布问题：应用HBase之前，只有一个离线大集群，该集群部署了所有组件（SparkSQL、Hive等），一旦跑离线任务无法保证SLA；
业务管控问题：一开始不知道有哪些业务、业务对接人以及哪些业务需要什么样的SLA，因此出现问题找不到对接人；
监控系统问题：有赞一开始有自己的监控系统，但不够灵活，告警配置单一；
人肉运维问题：随着业务的增多，对运维的诉求越来越多，尤其当数据需要迁移到HBase的时候，有赞缺乏成熟的工具支持，几乎靠人肉运维，因此时间成本高，难以复用。

为了解决上述的痛点问题，有赞开发了自己的管控平台。相应的，该平台包含以下四个模块：

业务管控系统：将业务、资源和人进行有机整合；
监控系统：负责全面收集基于HBase集群的信息，按照指标分组，为告警系统提供基础数据；
易用的查询工具：HBase表数据的检查需要机器的访问权限、启动HBase Shell、人工书写Scan和Filter，面对用户没有访问权限、同时需要查询某条数据的情况，有赞提供了易用的查询工具；
强大的迁移工具：通过将工具进行产品化，解决人肉运维问题，减少运维时间和成本

业务管控系统

业务管控系统主要分为三个模块：

工单：HBase并不适用于所有业务，每次接入时需要进行一系列评估，确定可以使用后需要提供工单，工单填写需要明确SLA需求等重要信息，工单提交后会进行备份，保证所有操作有迹可循；
权限：业务、项目与人关联的前提下，不同业务用户对不同项目的的权限不同，权限关联模块支持业务用户根据需求申请项目级别的权限，查看其它表的元信息与监控数据；
大盘：该模块主要记录一系列监控指标，如在线主备集群所有表的存储成本、吞吐等，使管理者对于监控指标情况一目了然。

监控系统

管控平台之下的监控系统主要有以下功能：

•操作系统级别、HBase级别数据监控：相对于之前产品，该功能的优势在于指标分组，如读、写、存储、以及RegionServer逻辑分组，每一分组的界面可以直观展示相应的指标数据；

•复制延迟监控：该功能主要监控集群间复制通存在的复制延迟，展示最大复制延迟和平均复制延迟，用于支持最终一致性下SLA的确定，并提供延迟告警的数据。

•表级别监控：HBase 1.2.6版本Slave在向Master发送心跳数据时，会相应发送一部分监控数据，有赞在此基础上做了二次开发，使其发送更多类型的监控数据，如读写的TPS和吞吐等，监控数据进行汇总后存储在OpenTSDB中，按表展示，一目了然。

告警

监控系统收集的数据使告警变得更加轻松，针对不同的告警问题，如RIT和最大延迟等，都可以动态调整阈值，实现定制化告警，更加灵活。

效率工具

效率工具主要解决的是异步迁移和集群迁移的问题，支持以下几种方式：

Hive -> HBase bulkoad方式：适用于比较大的表同步；
HBase集群间数据同步：支持主集群数据不停写迁移到备集群；
DataX方式：保证更好的本地化率，配置灵活，适合小表迁移，
在线查询工具：方便用户随机查询。

下图展示了数据迁移的具体流程，其中绿色代表数据通过前面介绍的几种方式进行异步迁移，粉色代表HBase之间通过Snapshot进行同步数据迁移，此外离线HBase与Hive之间已打通，二者之间的数据迁移更简单。

三、改造与业务实践

有赞在开始使用HBase的时候，2.0版本还不是很成熟，为了求稳，选择了1.2.6版本。该版本有很多功能不全，无法满足有赞当时的需求，因此有赞在应用HBase的过程中主要做了四部分改造：资源隔离、异构存储、资源隔离优化和Bug修复。

改造-资源隔离

该功能（参考HBASE-6721 patch）主要支持HBase层面的逻辑分组，将某些RegionServer划到一个分组，当表挂载在不同分组时，只在该分组做balance。这种方式从HBase层面上来讲相当于资源隔离，优点是降低管理成本，缺点是只是在HBase层面进行资源隔离，而非底层的HDFS层，实际在IO与网卡等层依然会相互影响。

改造-异构存储

虽然HDFS 2.6版本支持SSD存储介质，但是其成本相对较高，有赞通过改造异构存储功能（参考HBASE-14061 patch），实现指定重要的表存储到SSD中，具体策略是指定RegionServer存储HLog的格式（HOT，ONE_SSD或ALL_SSD）以及表格cf级别的存储方式。HLog的三种存储格式分别具备以下特点：
• HOT策略：将所有副本存储到SATA中，这种方式成本低，存储空间大，但吞吐较差；
• ALL_SSD策略：将所有副本存储到SSD上，这种方式吞吐量高，但成本高；
• ONE_SSD策略：兼容HOT策略和ALL_SSD策略，将本地副本存储在SSD，其余副本存储在SATA上，控制成本的同时，提升吞吐。

改造-资源隔离优化

这部分功能主要优化前面提到的资源隔离问题，通过利用RSGroup结合异构存储，完成HBase层和HDFS层的双重隔离。SSD和SATA存储的副本分别属于不同的分组，达到完全的资源隔离，在不同的分组上放置重要程度不等的业务，在资源隔离的基础上，满足不同的SLA。

改造-Bug修复

有赞在应用HBase过程中修复了三个比较重要的bug：

监控数据遗失：RSRpcServices 类实现监控不准，数据丢失；
Shell无法设置Split_policy：该问题修复后已反馈给社区，参考HBASE-19340 patch
缓存不生效问题：启动connection创建一个table的过程中会产生多次交互，时间较长，解决的方法是业务方在第一次访问时可以请求所有表的Region信息，从而避免后续的多次交互，然而该功能并不好用，通过分析源码后发现返回的信息只包括第一个Region数据，该问题修复后也已反馈给社区，参考HBASE-20697 patch。

业务实践

有赞已接入HBase的业务实践主要包括：粉丝详情，要求低延迟、高可用；调用链，要求重写低读，高吞吐

业务实践-粉丝详情

粉丝详情业务针对HBase的改造实践包括以下四个方面：

ShortCircuit Read：该方式主要涉及HDFS层，在读DataNode副本的时候，支持TCP协议通过domain.docket的方式读取本地文件，相对于之前的方式效率更高；
Hedged Read：当面临DadaNode三个副本磁盘抖动时，访问副本可能会超时，该方式支持同时访问两个副本，选用返回时间较短的结果，防止磁盘毛刺；
ALL_SSD：将所有的表存储到SSD，结合Hedged Read提高吞吐能力；
HA READ：该方式不容许集群宕机，宕机对表的读写可能会造成秒甚至分钟级别的影响。

针对宕机问题，有赞开发了自己SDK，ha-hbase-client，可以简单认为是一个前端代理。它配置了两个底层的HBase集群（如下图所示），支持单次请求路由到备集群，然后重新访问主集群并进行健康检查；另外还支持熔断，当主集群完全不可用时，会将请求直接路由到备集群，不再访问第一个集群及健康检查。Ha-hbase-client的开发对业务方友好，业务方对底层无感知，降低了开发成本，保证了高可用性。

业务实践-调用链

调用链的业务诉求是高吞吐，尤其是写吞吐量很高，在写不发生阻塞的前提下对读写延迟不敏感。调用链业务在改造前使用的是多台Cassandra SSD机型组成的集群，存在一系列的痛点问题，如运维成本高、集群负载高、服务不稳定等。

通过调研发现，HBase很适合上述的调用链业务场景，因为HBase的写功能很强。具体实践过程中，有赞首先根据调用链业务的数据量级进行了预分区；同时将HDFS的副本数设置为2，减少磁盘使用量；最重要的一点是为了避免Major Compaction，除了进行预分区之外，还将Region大小设为128，同时进行估算预测调整，避免达到Split的阈值。