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

· jack · Created at · Last by kkmmi68 Replied at · 2383 hits
434 1549005614

升级背景

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


特性1:AssignmentManager V2

AMv1存在的问题及原因分析

AMV1存在的主要问题是Regoins in Transition(RIT)。深度使用HBase的人一般都被 RIT困扰过,长时间的RIT简直令人抓狂。一些RIT确实是由于Region无法被RegionServer open造成的,但大部分的RIT,都是AM本身的问题引起的。
引发RIT的原因主要有以下几点:
1. Region状态变化复杂
Region open 的过程有7 个组件参与并涉及20 多个步骤,但越复杂的逻辑意味着越容易出 bug。

2.region 状态多处缓存
Master 内存 、Meta 表、Zookeeper 都会保存 region 的状态,Hbase1.0要求三者要保持完全同步;

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

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


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

AMv2 的改进

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

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

特性2:In-memory Flush & Compaction

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

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 可以存储更多的数据。

特性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

<pre>
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.
</pre>

建议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,与大家共同探讨如何在生产环境中更好地对其进行使用。

共收到 28 条回复
1Floor Deleted
2Floor Deleted
3Floor Deleted
4Floor Deleted
5Floor Deleted
6Floor Deleted
9Floor Deleted
10Floor Deleted
11Floor Deleted
12Floor Deleted
13Floor Deleted
14Floor Deleted
15Floor Deleted
16Floor Deleted
17Floor Deleted
18Floor Deleted
19Floor Deleted
22Floor Deleted
19Floor Deleted
20Floor Deleted
21Floor Deleted
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up