`

全面解析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]

?

?

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

?

?

?

?

?

?

0
0
分享到:
评论
Global site tag (gtag.js) - Google Analytics 重庆时时彩怎么作弊的