写点什么

HBase 2.0 在时序数据存储方向的应用

  • 2019-09-25
  • 本文字数:3507 字

    阅读完需:约 12 分钟

HBase 2.0在时序数据存储方向的应用

1HBase 生态介绍

HBase 是基于 HDFS 存储的分布式 Nosql 数据库,具有易于线性拓展和高并发随机实时读写能力,目前已成为大部分公司基础存储架构中不可缺少的组成部分。经过多年发展,HBase 生态也日益丰富,目前 HBase 主要生态包括以下几个方向:

1.1 时序数据:

OpenTSDB 是基于 HBase 的时序数据库,具有海量数据实时读写能力和聚合计算能力。多被应用在实时监控领域和对业务趋势的实时分析;

1.2 Cube 分析:

Kylin 是 HBase 生态中 Cube 分析的项目,将数据进行预计算后存储在 HBase 中,对用户提供 SQL 接口,可为用户提供亚秒级多维度分析;

1.3 SQL On HBase:

Phoenix 是 HBase 上的 SQL 组件,支持标准 SQL 和 JDBC API,用户可像使用关系型数据库的操作方式操作 HBase 数据。同时支持二级索引功能,大大提升查询速度;

1.4 时空数据:

GeoMesa 是基于 HBase 的时空数据组件,可提供大规模分布式地理空间数据查询和分析。

2 贝壳 HBase 的生态介绍

在贝壳已经有基于 Kylin 的实时分析引擎;基于 OpenTSDB 的集群监控信息存储;基于 Phoenix 的 SQL 组件,支持标准 SQL 语法,可通过 JDBC 方式连接进行操作,可建立索引对查询加速。


1)基于 Kylin 的实时分析服务(已建立完成)


2)基于 Opentsdb 的集群监控信息存储(已建立完成)


3)基于 Phoenix 的 SQL 组件(已建立完成)


4)基于 GeoMesa 的时空数据(暂未建设,需求收集中)

3HBase 时序数据存储目前情况

从 2018 年 8 月份开始我们开始使用 OpenTSDB 来存储集群监控数据,目前已存储 Hadoop 和 HBase 集群 Metrics 数据以及集群各个节点基础信息数据。这套时序存储由 5 个节点的 HBase 集群和 3 个节点的 OpenTSDB 搭建而成,HBase 平均每秒处理 3W 请求,最大每秒处理 10W+请求。

4HBase 2.0 新特性介绍

2018 年 8 月份我们开始对 HBase2.0 版本进行调研,希望能够使用更少的资源,获得更高的性能,通过一系列尝试最终仅使用原来一半的内存达到了预期效果。那么为什么 HBase2.0 能够使用更少资源获得更高的性能呢?这得益于 2.0 版本的一些新特性,现在我来为大家介绍一下:

4.1 AssignmentManager V2(AM V2)

AM 负责维护 Region 分配过程中的状态,AM V2 基于 Procedure V2 存储状态,去除了对 Region 分配过程对 zookeeper 的依赖,Region 状态直接通过心跳汇报给 Master,降低了 RIT 的出现概率。改特性默认开启;

4.2 Offheapping of Read/Write Path

将数据缓存和 memstore 放到堆外,堆内只存储一级缓存中的索引和 bloom filter 数据;减少了 GC 次数提升了稳定降低延迟;

4.3 In-Memory Compaction

在 HBase1.x 版本中,memstore 达到 flush 阀值时,直接进行 flush 将数据写到磁盘;引入该功能后,memstore 中数据会在内存中进行多次 compaction 后再 flush,减少了写磁盘次数并能减少写放大问题;

4.4 NettyRpcServer

使用 Netty 的高并发能力,大大提升了 HBaseRPC 的吞吐能力,降低了延迟。该特性默认开启;

4.5 Async Client

Async Client 利用异步 RPC 机制,大大高 Client 端请求并发量,扩大吞吐;

4.6 RS Group

通过给 RegionServer 分组,很好地实现了资源隔离,也可以按需分配不同性能机器进行数据存储,例如冷数据存在 HDD 磁盘 RS 上,温数据存在 SDD 和 HDD 混布 RS 上,热数据存在全 SSD RS 上;

4.7 Support for MOB

MOB 特性使得 HBase 支持存储小于 10MB 的中等媒体对象数据,相比原有直接存储大对象,其读写效率更高。

5OpenTSDB 介绍

OpenTSDB 是一个基于 HBase 的可拓展时序数据读写服务,可通过 HTTP API 的方式对数据进行读写。我们使用的 OpenTSDB 版本是最新的 2.3.1,为了达到更好的读写性能,我们采用了读写分离的部署方案。接下来我给大家介绍一下值得注意的点和配置:


1)初始化表时,要对表进行预切分


默认初始化的表都只有一个分区,造成大量请求压到一个节点上造成宕机;


2)开启 uid 随机映射到 metrics,使得数据均匀分布到各 region 上:


1tsd.core.uid.random_metrics=true
复制代码


3)开启 mate 数据实时创建追踪,以便使用 tag_values 函数获取 metric 指定 tag 值集合:


1tsd.core.meta.enable_realtime_uid=true2tsd.core.meta.enable_tsuid_tracking=true3tsd.core.meta.enable_realtime_ts=true
复制代码


注意:开启该功能后,对 HBase 的访问量会激增。


4)设置 tag 允许字符,解决非字符问题:


1tsd.core.tag.allow_specialchars = ", ;[]:/@"
复制代码

6 关键配置

6.1 HBase 相关配置

前面介绍了很多特性,有些是默认开启的,有些需要额外配置。我们主要使用了 Offheapping of Read/Write Path 和 In-Memory Compaction 两个特性,下面是相关的配置:


1)hbase-env.sh 文件内配置:


设置对外内存大小


1export HBASE_OFFHEAPSIZE=30G
复制代码


regionserver JVM 参数设置,建议使用 G1 垃圾回收,可控制最长暂停时间


1export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -XX:+UseG1GC -Xms30g -Xmx30g -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=100 -XX:-ResizePLAB -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -XX:G1HeapWastePercent=3 -XX:InitiatingHeapOccupancyPercent=35  -XX:G1MixedGCLiveThresholdPercent=85 -XX:G1NewSizePercent=4  -XX:G1MaxNewSizePercent=10"
复制代码


2)hbase-site.xml 文件配置


 1<!-- Offheap Read Path Setting --> 2<property> 3  <name>hbase.bucketcache.ioengine</name> 4  <value>offheap</value> 5</property> 6 7<property> 8  <name>hbase.bucketcache.size</name> 9  <value>17408</value>10  <description>堆外缓存(L2 Cache)大小,单位MB</description>11</property>1213<property>14  <name>hfile.block.cache.size</name>15  <value>0.2</value>16  <description>堆上缓存(L1 Cache)大小,占堆大小的20%</description>17</property>1819<!-- Offheap Write Path Setting -->20<property>21  <name>hbase.regionserver.offheap.global.memstore.size</name>22  <value>10240</value>23  <description>堆外memstore大小,单位MB</description> 24</property>
复制代码


3)In-Memory Compaction 配置


有两种设置方式:


全局开启


在 hbase-site.xml 添加如下配置:


1<property>2  <name>hbase.hregion.compacting.memstore.type</name>3  <value>NONE|BASIC|EAGER|ADAPTIVE</value>4  <description></description> 5</property>
复制代码


注意:使用这种配置,会导致原有其他表的 region 无法使用,建议采用第二种配置


针对表开启


1create '<tablename>', 2{NAME => '<cfname>’, IN_MEMORY_COMPACTION =>'<NONE|BASIC|EAGER|ADAPTIVE>'}
复制代码

6.2 In-Memory Compaction 策略介绍

1)BASIC 策略


一个低开销方案,它将 pipline 中的所有 segment 索引合并到一个平坦索引中。他不会清理冗余,以避免 cell 数据拷贝


2)EAGER 策略


一个高成本/高回报方案,即可以平衡索引也可以消除冗余,并清理多余版本,需要拷贝数据会有额外开销,适用于写入较多场景


3)ADAPTIVE 策略


首先对待合并 segment 进行评估,方法是在已经统计过不重复 key 个数的 segment 中,找出 cell 个数最多的一个,然后用这个 segment 的 numUniqueKeys/getCellsCount 得到一个比例,如果比例小于设定的阀值则使用 EAGER 策略,否则使用 BASIC 策略

7OpenTSDB 相关配置

在 opentsdb.conf 文件中配置


1 tsd.core.tag.allow_specialchars = ", ;[]:/@"2 tsd.core.uid.random_metrics=true3 tsd.core.meta.enable_realtime_uid=true4 tsd.core.meta.enable_tsuid_tracking=true5 tsd.core.meta.enable_realtime_ts=true
复制代码

8 经验总结

经过一段时间的使用我们遇到过一些问题,在这里和大家分享下:


1)HBase 2.0 默认使用 NettyRpcServer,会由于客户端(OpenTSDB)处理结果速度慢造成 Netty buffer 堆积 ,导致 RegionServer 频繁 FullGC,然后宕机;


解决方案:引入社区 Patch,对缓冲区大小进行限制,缓冲区默认大小 2GB,我们最终设置 6GB


2)Hbase 2.0 中 hbck 只能进行检查不能进行修复,一旦出现 RIT 问题不易解决;


解决方案:出现 RIT 问题可通过以下两种方式进行解决:


  • 在 hbase shell 中使用 assign 命令重新分配指定 region,如果无效采用第二种方式;

  • 使用 hbck2 进行修复,有些修复后仍未解决时重启 Master,问题得到解决。


3)当 RegionServer 重启后,集群不会自动 balance,手动调用 balancer 命令也无效,即使其他节点每秒请求几万的情况下也不会进行 balance,且日志无异常。


解决方案:切换 HMaster 节点,再手动调用 balancer 命令。


作者介绍:


牛魔(企业代号名),贝壳找房 HBase 负责人。


本文转载自公众号贝壳产品技术(ID:gh_9afeb423f390)。


原文链接:


https://mp.weixin.qq.com/s/jNqT2rwd6yFl9A4yLACcZQ


2019-09-25 23:481899

评论

发布
暂无评论
发现更多内容

严管之下,还有谁在“挖矿”?

CECBC

如何真正学习Go 语言

宇宙之一粟

golang 学习方法 Go 语言 12月日更

深入浅出 OceanBase 运维之弹性扩缩容

OceanBase 数据库

直播 弹性扩容 OceanBase 开源

apacheunomi漏洞介绍及代码分析

网络安全学海

黑客 网络安全 信息安全 渗透测试 安全漏洞

农业与科技结合?快来看Amazon Rekognition自定义标签的作用吧

亚马逊云科技 (Amazon Web Services)

AI/ML

有向无环图在新增节点时的环状检测

waitmoon

DAG

53 K8S之资源监控与资源指标

穿过生命散发芬芳

k8s 28天写作 12月日更

谈数字人民币对我国金融系统的双重影响

CECBC

架构师实战营 - 模块7 - 作业

lucian

架构师实战营

在Amazon SageMaker中灵活使用多种存储服务

亚马逊云科技 (Amazon Web Services)

AI/ML

新能源当道,如何构建一个电动汽车电池告警预测平台?

亚马逊云科技 (Amazon Web Services)

AI/ML

动手训练属于自己的无人车,这个超强服务现已开源!

亚马逊云科技 (Amazon Web Services)

AI/ML

SageMaker Neo优化目标检测模型加速推理

亚马逊云科技 (Amazon Web Services)

AI/ML

低代码实现探索(九)后台模型 json定义

零道云-混合式低代码平台

微众七年营造,ABCD“四梁八柱”建构数字时代的信任底座

脑极体

Redis RDB 持久化详解

程序员历小冰

redis 持久化 28天写作 12月日更

即刻到位!快速落地 Amazon 智能工厂解决方案

亚马逊云科技 (Amazon Web Services)

AI/ML

王者荣耀商城异地多活架构设计

Steven

架构实战课

使用 Amazon IoT 和 Amazon SageMaker 进行设备实时预测性维护

亚马逊云科技 (Amazon Web Services)

AI/ML

重装上阵——Graviton2提升ElastiCache for Redis的性价比!

亚马逊云科技 (Amazon Web Services)

AI/ML

☕【Java实战系列】「技术盲区」Double与Float的坑与解决办法以及BigDecimal的取而代之!

码界西柚

BigDecimal Java 开发 12月日更 Double和Float

模块7作业

小何

「架构实战营」

编写代码最应该做好的事情是什么?

李子捌

Java 28天写作 21天挑战 12月日更

YB时代即将来临,三问数据存储

脑极体

巧用机器学习托管服务,自动化合约处理从此不在话下!

亚马逊云科技 (Amazon Web Services)

AI/ML

架构实战营模块七课后作业

Geek_99eefd

#架构实战营 「架构实战营」

销售易携手DataPipeline,推动“实时感知-主动决策-客户成功”的变革!

DataPipeline数见科技

大数据 中间件 数据融合 数据迁移 数据管理

模块七作业

心怀架构

LabVIEW读写各类格式图像的方法(基础篇—1)

不脱发的程序猿

机器视觉 图像处理 LabVIEW 读写各类格式图像的方法

释放协同价值——元宇宙中的区块链

CECBC

业界福音!快来使用Amazon Transcribe服务减轻添加字幕的繁琐工序负担吧

亚马逊云科技 (Amazon Web Services)

AI/ML

HBase 2.0在时序数据存储方向的应用_文化 & 方法_牛魔_InfoQ精选文章