说好不哭,但HBase2.0真的好用到哭

升级背景

个推作为专业的数据智能服务商,在业务开展过程中存在海量的数据存储与查询的需求,为此个推选用了高可靠、高性能、面向列、可伸缩的分布式数据存储系统——HBase。

然而,运行HBase老集群(使用HBase1.0版本)多年后,遇到了两大问题:各节点基础环境不一致;该集群的服务器运行多年已过保。而且随着个推业务量增长,性能方面也开始遇到瓶颈。经过综合评估,个推决定将老集群升级并迁移到HBase2.0新集群以解决HBase老集群存在的上述问题。

升级步骤
下面是个推升级并迁移的全步骤,供开发者参考。由于整个过程将涉及多个部门且用时长,建议各位在操作的过程中可以让各部门指定专人对接。
准备1:HBase表认领,找到所有表的读写应用与业务方;
准备2:HBase2.0新集群部署,并打通到所有读写应用服务器的网络;
调试3:测试环境调试应用,确认能正常使用HBase2.0集群;
调试4:开发数据校验工具,对迁移后新老集群数据进行完整性校验;
迁移5:所有表双写工程上线,并确认新老集群写入数据一致;
迁移6:所有读取应用变更,迁移到新集群,确认读取正常;
收尾7:老集群写入工程停止,表禁用半个月,无异常后老集群下线。

HBase2.0 新特性
2018年4月29日,HBase2.0发布,共包含了4551个Issues。HBase2.0的新特性非常多,本次只介绍主要的几个特性,更多内容见官网文档。
[https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12327188]

说好不哭,但HBase2.0真的好用到哭
特性1:AssignmentManager V2

AMv1存在的问题及原因分析
说好不哭,但HBase2.0真的好用到哭

AMV1存在的主要问题是Regoins in Transition(RIT)。深度使用HBase的人一般都被 RIT困扰过,长时间的RIT简直令人抓狂。一些RIT确实是由于Region无法被RegionServer open造成的,但大部分的RIT,都是AM本身的问题引起的。
引发RIT的原因主要有以下几点:

  1. Region状态变化复杂
    Region open 的过程有7 个组件参与并涉及20 多个步骤,但越复杂的逻辑意味着越容易出 bug。

说好不哭,但HBase2.0真的好用到哭
2.region 状态多处缓存
Master 内存 、Meta 表、Zookeeper 都会保存 region 的状态,Hbase1.0要求三者要保持完全同步;

Master 和 RegionServer 都会修改 Meta 表的状态和 Zookeeper 的状态,这将非常容易导致region状态出现混乱;

如果出现不一致,到底以哪里的状态为准?

说好不哭,但HBase2.0真的好用到哭
3.严重依赖 Zookeeper进行状态通知
Region 状态的通知完全通过 Zookeeper,这导致了 region 的上线/下线的速度存在着一定的瓶颈。特别是在 region 比较多的时候,Zookeeper的通知会出现严重的滞后现象。

说好不哭,但HBase2.0真的好用到哭

AMv2 的改进

主要的改进有以下四点:
1.region 每次状态变化,会先记录到 ProcedureWAL中,然后记录在 Meta 表;
2.region 状态信息只存放两个地方:meta 表、HMaster 的内存,不再存放Zookeeper;
3.只有 HMaster 才可以更新 meta 表中的信息;
4.HMaster与RS直接进行状态信息同步,去除Zookeeper依赖;
说好不哭,但HBase2.0真的好用到哭

整体上来看,AMv2去除了 Zookeeper 依赖,有清晰明了的 region transition 机制,代码的可读性更强,非常有效地解决了RIT现象。

特性2:In-memory Flush & Compaction

HBase写入流程中,数据会先写入Memstore(内存中),达到阈值后,会触发flush刷新,生成HFile文件落到磁盘中。需要注意的是MemStore的最小flush单元是‘HRegion’而不是单个MemStore,如果HRegion中Memstore过多,每次flush的IO开销会很大。

说好不哭,但HBase2.0真的好用到哭

HBase1.x 的问题
Memstore flush刷新的触发条件很多,不过大多数对业务影响小,开发者无需担心。但如果触发Region Server级别flush,将会导致整个 RS 执行 flush,阻塞所有落在该Region Server上的更新操作,而且阻塞时间很长,可能会达到分钟级别,对业务影响非常大。

HBase2.0的改进

在2.0版本中,MemStore中的数据先Flush成一个Immutable的Segment,多个Immutable Segments可以在内存中进行Compaction,当达到一定阈值以后才将内存中的数据持久化成HDFS中的HFile文件。这就是2.0的新特性:In-memory Flush and Compaction ,而且该特性在2.0版本中已被默认启用(系统表除外)。

好处1:减少数据量、降低磁盘 IO,很多表的列簇只保留1个版本;

好处2:Segment 来替代 ConcurrentSkipListMap数据结构存储索引,节省空间,同样的 MemStore 可以存储更多的数据。
说好不哭,但HBase2.0真的好用到哭

特性3:Offheaping of Read/Write Path

HBase 服务读写数据较多依赖堆内内存实现,JVM采用的是stop-the-world的方式进行垃圾回收,很容易造成 JVM 进程因为 GC 而停顿时间比较长。 而HBase 是一个低延迟、对响应性要求比较高的系统,GC 很容易造成HBase 服务抖动、延迟高。

HBase社区解决GC延迟的思路是尽量减少使用JVM 堆内内存,堆内内存使用减少了,GC也就随着减少了,社区为此支持了读写链路的offheap。

读链路的offheap主要包括以下几个优化 :

  1. 对BucketCache引用计数,避免读取时的拷贝;
  2. 使用ByteBuffer做为服务端KeyValue的实现,从而使KeyValue可以存储在offheap的内存中;
  3. 对BucketCache进行了一系列性能优化。

写链路的offheap包括以下几个优化:

  1. 在RPC层直接把网络流上的KeyValue读入offheap的bytebuffer中;
  2. 使用offheap的MSLAB pool;
  3. 使用支持offheap的Protobuf版本(3.0+)。

HBase2.0 的“坑”
V2.0.3之前版本不支持HBCK2


HBCK2 versions should be able to work across multiple hbase-2 releases. It will fail with a complaint if it is unable to run. There is no HbckService in versions of hbase before 2.0.3 and 2.1.1. HBCK2 will not work against these versions.

建议HBase升级到V2.0.3或V2.1.1,详情看HBCK2文档。
[https://github.com/apache/hbase-operator-tools/tree/master/hbase-hbck2]

重度依赖Procedure V2

AMv2之所以能保持简洁高效的一个重要原因就是其重度依赖了Procedure V2,把一些复杂的逻辑都转移到了Procedure V2中。但是这样做的问题是:一旦ProcedureWAL出现了损坏,这个后果就是灾难性的。当然,小编相信经过一段时间的bug修复和完善后,这些问题将不复存在。

HBase作为个推大数据一项重要的基础服务,性能的好坏影响重大。个推将HBase1.0升级到了HBase2.0版本后,在可靠性、安全性方面都有了很大提升,有效解决了1.0版本中的多种问题。未来,个推将会持续关注HBase 2.0,与大家共同探讨如何在生产环境中更好地对其进行使用。