最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

[Hbase] 有赞的HBase平台实践和应用之路

[复制链接]
发表于 2019-10-26 11:53:11 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
在中国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的阈值。
通过HBase实践,有赞使用更少的机器、更低的负载完成了对调用链的支持,解放了开发运维的时间,即使调用链流量翻倍,也可以较快的扩展,并且不会影响SLA。
四、未来规划
跟进社区,反馈社区
HBase 1.2.6在有赞已经使用了两年左右,目前不打算迁移到2.X版本,打算获取社区红利,将发现的问题、解决的bug、产出的patch反馈给社区。
服务更多的业务
未来将完善存储平台,开发更多的工具,接入更多的业务。
实时数仓
有赞计划在实时数仓方面发力,希望HBase不单纯做一个存储组件,而是与其他组件有机结合,成为实时数仓的重要组成部分。

楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 15:42

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表