HBase实战 | 贝壳找房HBase 2.0在时序数据存储方向的应用

Posted 2021-04-18 HBase技术社区

作者牛魔（企业代号名），贝壳找房HBase负责人。

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上：

tsd.core.uid.random_metrics=true

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

tsd.core.meta.enable_realtime_uid=true
tsd.core.meta.enable_tsuid_tracking=true
tsd.core.meta.enable_realtime_ts=true

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

4）设置tag允许字符，解决非字符问题：

tsd.core.tag.allow_specialchars = ", ;[]:/@"

6关键配置

6.1 HBase相关配置

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

1）hbase-env.sh文件内配置：

#设置对外内存大小

export HBASE_OFFHEAPSIZE=30G

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

export 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 文件配置

<!-- Offheap Read Path Setting -->
<property>
   <name>hbase.bucketcache.ioengine</name>
   <value>offheap</value>
</property>

<property>
   <name>hbase.bucketcache.size</name>
   <value>17408</value>
   <description>堆外缓存(L2 Cache)大小，单位MB</description>
</property>

<property>
   <name>hfile.block.cache.size</name>
   <value>0.2</value>
   <description>堆上缓存(L1 Cache)大小，占堆大小的20%</description>
</property>

<!-- Offheap Write Path Setting -->
<property>
   <name>hbase.regionserver.offheap.global.memstore.size</name>
   <value>10240</value>
   <description>堆外memstore大小，单位MB</description> 
</property>

3）In-Memory Compaction 配置

有两种设置方式：

• 全局开启
  

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

<property>
   <name>hbase.hregion.compacting.memstore.type</name>
   <value>NONE|BASIC|EAGER|ADAPTIVE</value>
   <description></description> 
</property>

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

• 针对表开启

create '<tablename>', 
{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文件中配置

tsd.core.tag.allow_specialchars = ", ;[]:/@"
tsd.core.uid.random_metrics=true
tsd.core.meta.enable_realtime_uid=true
tsd.core.meta.enable_tsuid_tracking=true
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命令。

作   者：牛魔（企业代号名）

出品人：欧比旺、梅长苏（企业代号名）

---------- END ----------