说好不哭，但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

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