说好不哭，但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/jir...]

特性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/hba...]

重度依赖Procedure V2

AMv2之因此能保持简洁高效的一个重要缘由就是其重度依赖了Procedure V2，把一些复杂的逻辑都转移到了Procedure V2中。可是这样作的问题是：一旦ProcedureWAL出现了损坏，这个后果就是灾难性的。固然，小编相信通过一段时间的bug修复和完善后，这些问题将不复存在。

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