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

开发者社区> 云原生多模数据库Lindorm> 正文
登录阅读全文

“十年磨一剑”--有赞的HBase平台实践和应用之路

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

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

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

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

一、 产品定位

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

1

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

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

2

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

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

3

二、 管控平台

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

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

4

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

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

5

业务管控系统

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

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

6

监控系统

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

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

7

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

8

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

9

告警

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

10

效率工具

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

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

11

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

12

三、改造与业务实践

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

改造-资源隔离

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

13

改造-异构存储

虽然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上,控制成本的同时,提升吞吐。

14

改造-资源隔离优化

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

15

改造-Bug修复

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

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

16

业务实践

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

17

业务实践-粉丝详情

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

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

18

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

19

业务实践-调用链

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

20

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

21

通过HBase实践,有赞使用更少的机器、更低的负载完成了对调用链的支持,解放了开发运维的时间,即使调用链流量翻倍,也可以较快的扩展,并且不会影响SLA。

22

四、未来规划

跟进社区,反馈社区

HBase 1.2.6在有赞已经使用了两年左右,目前不打算迁移到2.X版本,打算获取社区红利,将发现的问题、解决的bug、产出的patch反馈给社区。

服务更多的业务

未来将完善存储平台,开发更多的工具,接入更多的业务。

实时数仓

有赞计划在实时数仓方面发力,希望HBase不单纯做一个存储组件,而是与其他组件有机结合,成为实时数仓的重要组成部分。

23

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云原生多模数据库Lindorm
使用钉钉扫一扫加入圈子
+ 订阅

Lindorm是适用于任何规模、多种类型的云原生数据库服务,支持海量数据的低成本存储处理和弹性按需付费,兼容HBase、Solr、SQL、OpenTSDB等多种开源标准接口,是互联网、IoT、车联网、广告、社交、监控、游戏、风控等场景首选数据库,也是为阿里巴巴核心业务提供支撑的数据库之一。

官方博客
链接