百度智能监控场景下的HBase实践

作者简介    张洋洋    百度高级研发工程师

负责百度智能运维产品(Noah)的分布式时序数据库和通用配额管理平台的设计研发工作,在分布式存储和配额管理方向有广泛的实践经验。

干货概览

通过百度大规模时序数据存储系列文章的介绍,想必读者对百度智能监控系统Noah的TSDB不再陌生,它主要用来存储Noah监控系统的时序指标数据,包括但不限于硬件和软件的可用性指标、资源使用率指标和性能指标等。如《百度大规模时序数据存储(二)|存储选型及数据模型设计》文章所述, Noah-TSDB是基于HBase为底层存储的基础上自主研发的,其优秀的性能离不开HBase的贡献。今天主要聊聊在百度智能监控场景下的HBase相关实践经验,先简单介绍一下HBase。

HBase架构简介

HBase是一个基于Java、开源的、非关系型的、面向列存储的分布式可扩展的大数据存储数据库。HBase的集群主要由HMater和RegionServer两种角色组成,底层以HDFS作为存储设施,集群由Zookeeper协助管理。其架构如下图所示:

图1  HBase架构图

简单介绍一下HBase中相关组件的作用:

  •   HMaster  

HMaster 是整个集群的大脑,负责数据表的操作、集群的负载均衡和故障恢复等集群管理工作。

  •   RegionServer  

HBase 将表以行为单位划分成许多片段,每个片段称为一个 Region。这些Region被分配到RegionServer进行管理。在读写流程中,定位到数据所在RegionServer后,Client与RegionServer直接交互进行数据的读写。

  •   Zookeeper  

HBase作为一个大规模的分布式系统,Zookeeper的作用是至关重要的。首先Zookeeper作为HMaster HA解决方案,保证了至少有一个HMaster处于工作状态。其次Zookeeper通过心跳机制探活RegionServer,当RegionServer故障时及时通知HMaster进行故障处理工作。最后Zookeeper保存了维护全局元信息的META表的路径,Client第一次与HBase集群交互时,需要通过META表来获取目标数据所在的RegionServer。

上面简单介绍了HBase的架构和各组件的基本信息,下面和大家分享一下在百度最大规模时序数据库的场景下使用HBase时遇到的几个典型问题和优化方案。

热点问题

大家都知道木桶效应,对于TSDB系统来说,热点Region所在的RegionServer就是影响整个”水桶”容量最短的那块木板。理想情况下HBase 中所有的请求应该均匀的分布在所有RgionServer的所有Region 上,当个别Region收到的读写请求数量大幅超过其它的Region,它所在的Region就有可能成为热点。

图2  RegionServer信息(此图来源网络非百度实际数据)

Noah-TSDB初期曾遇到监控元数据表设计不合理导致热点的问题。当时研发同学收到Noah-TSDB写入模块队列堵塞的业务报警,从Noah监控系统上看到同时间段访问HBase异常明显增长。HBase中的个别RegionServer频繁进行GC,网络 I/O 和磁盘 I/O 密集,操作队列中待执行的请求堆积严重,负载明显高于其它的RegionServer。查看异常RegionServer的日志发现大量请求访问的是同一个Region:”tsdb-meta,*** 1.”。初步定位是由于该Region负载过高,导致它所在的RegionServer成为热点,进而导致系统的吞吐量下降,上游写入模块请求堆积。

tsdb-meta是用来存储监控指标的名称、周期等元信息的表,表中红色填充的行代表其拥有数据量超过正常水平的,表结构如下:

表1  原始tsdb-meta表

分析上面的存储结构,我们可以知道:

  1. 同一个监控对象(namespace)的监控指标元信息将会存储在 HBase 表的同一行。
  2. 不同监控对象的指标数量不同,将导致行的大小不均匀。
  3. HBase中数据分片是以行为单位,每行的数据存储在同一个Region中,当某一行存储的监控指标数量远大于正常水平时,该行就有可能成为热点。

综上所述,当个别监控对象拥有的监控指标个数过多时,tsdb-meta可能会出现热点问题。同时经我们验证发现,成为热点的监控对象拥有的监控指标的数量大约是正常水平的20倍左右,进一步确认了故障原因。

定位到根因后,我们决定从两个方面来着手解决这个问题。一方面,定期统计监控对象拥有的指标个数,及时发现由于监控配置异常和不合理使用导致的个别监控对象拥有的监控指标过多的问题。第二方面,对tsdb-meta表结构改造,将原来按列分布的数据修改为按行展开平铺,充分打平数据,利用HBase按行自动分片的机制来达到负载均衡的状态。第一方面主要是从业务层面对不合理使用的情况进行人工干预。今天主要着重介绍第二方面。

  •   tsdb-meta表Schema改造  

前文大体介绍了表结构改造的思路,避免单行数据过大导致热点问题。我们将监控对象和监控指标的名称信息一起作为行键,只保留一列用于存储指标的其余信息,避免了因单行数据过大导致的热点问题。

表2  优化后的tsdb-meta表

  •   预分区  

tsdb-meta表优化后,我们发现生产环境存储数据的 tsdb-data表也存在热点问题。tsdb-data是用来存储监控指标数值的表,生产环境是按时间跨度进行分表,每两天的数据存储在一张表中。数据的行键由数据hash后的特征变量ts_uid和时间基准timestamp_base组成,利用HBase存储时按行键的字典顺序排序的特点,将不同的监控指标的数据散列到不同的Region,相同监控对象的指标数据顺序排列,达到优化查询的效果。由于tsdb-data表的日常访问量基数较大,当某个监控对象拥有的指标数量高于平均水平,那么该监控对象的监控指标很大概率会被分配到相同的Region,导致该Region过大,进成为热点,集群会分裂过大的Region来维持负载均衡的状态。频繁的分裂操作会占用大量资源,影响RegionServer的吞吐量。为解决因Region过大导致的热点,我们采用了对数据表进行预分区的方法。

在对tsdb-data表进行预分区时,我们发现只通过指定Region数量来实现预分区的效果并不理想,因为会出现实际写入量与槽位分配不均的问题。HBase数据表是按照行键的字节空间均匀划分而不是按照实际存储的数据量进行划分。如下图所示,图中红色方块代表实际存储的数据,白色的方块代表无实际数据的行。

图3  原始Region预分区

如上图,虽然数据表已经按照行键的字节空间划分成3个Region了,但是明显Region 3中实际存储的数据量远大于Region 1和Region 2。这种情况下Region 3有成为热点的可能性。为了改善这种情况,Noah-TSDB结合了生产环境中的tsdb-data表按等间隔时间跨度分表的特点,决定参照历史表的使用情况对新表进行预分区。根据生产环境实际产生的行键和预期的分区大小计算出Region分界值,然后根据分界值将表划分成实际水位相近的Region,这样虽然每个Region的槽位大小不一样,但是每个Region实际存储的数量是相当的,进一步降低产生热点的风险。

图4  优化后的Region预分区

如何合理的设置Region数量

在前文介绍的预分区策略中,除了需要参考生产环境的实际使用情况外还需要根据机器资源和分裂阈值等系统参数来预估合适的Region大小,Region大小确定后,我们可以预估出整体的Region数量。那么如何判断当前集群是否能够承载调整后的Region数量呢?如果Region的数量不合理有哪些危害呢?在讨论Region数量对集群的影响之前,我们先了解一些基础知识:

  1. 在HBase的数据写入流程中,数据是先写到Memstore(写缓存)排序,然后异步Flush追加到HFile中。一个Region中的多个列族对应多个Memstore,Memstore Flush的最小单位是Region。
  2. 当一个RegionServer中所有Memstore的大小总和达到阈值hbase.regionserver.global.memstore.upperLimit  *  hbase_heapsize会触发Memstore Flush。根据 Memstore从大到小依次Flush,直至MemStore内存使用量低于阈值 hbase_heapsize * hbase.regionserver.global.memstore.lowerLimit。
  3. HBase 会定期Flush Memstore来保障Memstore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行Flush导致的问题,定期的Flush操作有随机延时。

综上可知,一方面由于同一个RegionServer共享Memstore,Region数量过多会导致Memstore Flush的频率变快,产生的HFile变多,HBase持续的进行 Compaction,引发合并风暴。另一方面由于HBase定期Flush Memstore,每次执行 Flush需要将每个Region的每个列族对应的Memstore写入文件并存到HDFS, Region数量越多,每次需要一起处理的文件数量就越大,即使存在随机时延机制,短时间内文件的创建和数据的迁移较多也会加大集群负载,可能引起快照超时、客户端超时和批量加载超时,降低TSDB系统性能。因此Region数量过多会降低系统吞吐量。

Region数量过少也会降低系统性能。当数据量不变的情况下,由于Region数量过少导致单个Region过大,每个Region处理的写入请求数偏高,当Flush的速度慢慢被写入速度追上并赶超时,就会堵塞写入,影响RPC,进而影响HBase的整体写入和查询,降低系统的吞吐量。

Region数量设置不合理,会降低TSDB系统整体性能与可靠性,一般推荐的单个RegionServer管理的Region数量计算方法如下:

#{Region} = (RS memory)*(total memstore fraction)/((memstore size)*(# {column families}))

举个例子,如果RegionServer的参数如下:

  1. Java Heap Size of HBase RegionServer in Bytes设置的是20G
  2. hbase.regionserver.global.memstore.upperLimit是0.4
  3. hbase.hregion.memstore.flush.size是128M
  4. 多个表的列族个数共2个

那么 #{Region} = 20 * 1024 * 0.4/ (128 * 2) = 32。这个公式是在假设所有的Region都在以相同的速率写的前提下,如果实际只有部分Region在写入数据,结果可以根据比例、结合业务进行调整。例如Noah-TSDB的场景下,数据是按照时间分表,一般两天的数据存在一张数据表中,数据的写入都集中在最近的一张表,因此实际写入活跃的Region数量远小于Region的总数量,所以实际每个RegionServer管理的Region的数量大约是通过上述公式直接计算结果的3倍左右。

预估出整体的Region数量和单个RegionServer管理的Region数量后,就可以合理的进行容量规划,在集群调整的时候预估需要的机器资源。总  结

上面就是今天介绍的全部内容了,给大家简单分享了一些使用HBase的实践经验。其实在实际使用时我们也发现了HBase过重,运维成本较高等问题,也在持续的进行调研和架构升级,大家有什么好的建议欢迎不吝赐教。另外文中如果有理解不到位或者偏差的地方,欢迎大家指正。

Image placeholder
Benayoun
未设置
  100人点赞

没有讨论,发表一下自己的看法吧

推荐文章
小米Kylin平滑迁移HBase实践

根据美团等其他公司在Kylin社区的公开分享资料,跨HBase集群升级方案需要在新集群重新构建历史的Cube,或者有一段时间的服务停止。小米在Kylin生产环境的跨HBase集群迁移中实现了无中断的平

架构转型先行——金融业务场景下的新一代架构实践

  赵勇中国农业银行研发中心架构管理办公室主任工程师中国农业银行研发中心架构管理办公室主任工程师,十年以上金融行业信息化架构设计与管控经验。历经互联网金融、两地三中心、分布式核心银行等大型银行系统工程

HBase实战:记一次Safepoint导致长时间STW的踩坑之旅

本文记录了HBase中Safepoint导致长时间STW此问题的解决思路及办法。过程记录现象:小米有一个比较大的公共离线HBase集群,用户很多,每天有大量的MapReduce或Spark离线分析任务

滴滴大数据在汽车金融风控场景中的应用

桔妹导读:滴滴独有的出行场景大数据在金融领域有着非常广泛的应用前景,未来可与银行,保险,支付和理财等机构深入合作,帮助传统金融机构提升资源配置效率,降低获客和风险管理成本。出行场景大数据在交易欺诈识别

高并发业务场景下的秒杀解决方案 (初探)

文章简介 本文内容是对并发业务场景出现超卖情况而写的一片解决方案。主要是利用到了Redis中的队列技术。 超卖介绍 所谓的超卖,就是我们的售卖量大于了物品的库存量。该情况一般出现在电商系统中促销类的业

etcd 在超大规模数据场景下的性能优化

作者|阿里云智能事业部高级开发工程师 陈星宇(宇慕)划重点etcd优化背景问题分析优化方案展示实际优化效果本文被收录在5月9日cncf.io官方blog中,链接:https://www.cncf.io

在云、AI时代,传统应用性能监控方案过时了吗?

近年来,企业云对IT复杂性产生巨大影响,越来越多的企业需要能够解决云复杂性上升或加速数字化转型的有效方案,而人工智能正在成为解决这些问题的不二之选。在全球智能运维浪潮下,不少公司都选择重写代码,颠覆自

全球经济视野下的智能博弈:百度AI,冲向天穹

我们经常讨论AI技术对于一个企业、一个行业的价值。而如果我们把所有这些价值聚拢,或许会惊奇地发现,AI技术对于一个国际、一个时代来说,价值也是重逾万钧的。根据麦肯锡发布的《人工智能对全球经济影响的模拟

日志监控实践 – 监控Agent集成Lua引擎实现多维度日志采集

作者简介:董涵   百度资深研发工程师负责百度智能运维(Noah)服务管理和分布式监控架构研发工作,在分布式系统和大规模数据处理、可用性工程方向有广泛的实践经验。干货概览对于互联网行业来说,最有价值的

超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题?

导读:资源利用率一直是很多平台管理和研发人员关心的话题。本文作者通过阿里巴巴容器平台团队在这一领域的工作实践,整理出了一套资源利用提升的方案,希望能够带给大家带来一些讨论和思考。引言不知道大家有没有过

分布式场景下Kafka消息顺序性的思考

在业务中使用kafka发送消息异步消费的场景,并且需要实现在消费时实现顺序消费,利用kafka在partition内消息有序的特点,实现消息消费时的有序性。1、在发送消息时,通过指定partition

清华大学教授马智亮:如何走向高度智慧建造?

什么是智慧建造?普遍意义上的智慧建造是指生物基于神经器官所具有的一种高级的综合能力,包括感知、知识、记忆、理解、联想、情感、逻辑、辨别、计算、分析、判断、文化等多种能力。显然,具备这种能力的生物,首当

软件定义一切,企业数字化背景下的新一代IT基础架构

 在数字经济飞速发展的背景下,企业数字化转型已经成为目标共识,企业需要建立更敏捷、智能、安全和可控的数字化转型平台,而云为这一切提供了便利条件。  软件定义作为云的一项重要技术,这几年的也变得越发火热

如何构建“小数据”驱动的泛场景智能应用体系?

张真百信银行首席技术架构师&AILab负责人目前负责基于自然语言的动态银行研究与落地,关注AI技术与金融,办公,生活场景的深度融入;开源软件UAVStack创始人,面向智能运维提供解决方案,AIOps

百度投资知乎,智能小程序是合作中枢

在最近,知乎完成了由百度和快手联合投资的最新一轮融资。这已经是知乎的F轮融资,额度达到了4.5亿美元,是知乎迄今为止金额最大的一轮融资。有趣的是,在这次投资后知乎问答内容将以智能小程序的形式接入百度A

使用vue实现一个电子签名组件

使用vue实现一个电子签名组件在生活中我们使用到电子签名最多的地方可能就是银行了,每次都会让你留下大名。今天我们就要用vue实现一个电子签名的面板想要绘制图形,第一步想到的就是使用canvas标签,在

外部JS 使用Vue实例

1、main.js导出Vue实例varvue=newVue({ router, store, render:h=>h(App) }).$mount('#app') exportdefaultvue2

使用vue实现一个电子签名组件

在生活中我们使用到电子签名最多的地方可能就是银行了,每次都会让你留下大名。今天我们就要用vue实现一个电子签名的面板想要绘制图形,第一步想到的就是使用canvas标签,在之前的文章里我们使用canva

electron+vue实现div contenteditable功能|截图

最近在学习基于electron+electron-vue开发聊天客户端项目时,需要用到编辑器插入表情功能。一般通过input或textarea也能实现,通过插入[笑脸]、(:12这些标签,展示的时候解

准独角兽雷鸟科技出席SACC2019,讲述AI在场景互联网下的创新革命

10月31日至11月2日,由IT168旗下ITPUB企业社区平台主办的第十一届中国系统架构师大会(SACC2019)在北京召开。作为国内最具价值的技术交流盛会,也少不了今年热门的智慧大屏话题。据了解,

一文读懂HBase多租户

本文从三个方面介绍了HBase的多租户实现。上篇文章回顾:HDFS短路读详解多租户(multi-tenancytechnology),参考维基百科定义,它是在探讨与实现如何于多用户的环境下共享相同的系

HBase 基本入门篇

无论是NoSQL,还是大数据领域,HBase都是非常”炙热”的一门数据库。本文将对HBase做一些基础性的介绍,旨在入门。一、简介HBase是一个开源的、面向列的非关系型分布式数据库,目前是Hadoo

一场HBase2.x的写入性能优化之旅

本文通过实战跑分来展示HBase2.x的写入性能首先,简单介绍一下我们的测试环境:集群由5个节点组成,每个节点有12块800GB的SSD盘、24核CPU、128GB内存;集群采用HBase和HDFS混

干货 | 阿里巴巴HBase高可用8年抗战回忆录

前言2011年毕玄和竹庄两位大神将HBase引入阿里技术体系,2014年接力棒转到东8区第一位HBasecommiter天梧手中,多年来与淘宝、旺旺、菜鸟、支付宝、高德、大文娱、阿里妈妈等几乎全BU合

披荆斩棘:论百万级服务器反入侵场景的混沌工程实践

在繁杂的业务和网络环境下,在公司百万级服务器面前,要做到入侵发生时的及时检测,那么反入侵系统的有效性,即系统质量,是至关重要的。洋葱系统是腾讯公司级的主机反入侵安全检测系统,它是实现了前端主机agen