HBaseCon Asia 2019 Track 1 概要回顾

                                     HBaseCon 没来参加怎么办？

                              三个Track无法同时听，分身乏术怎么办？

                          不要紧~！“小米云技术”将用三期时间带你回顾

                                                   所有精华~！

                        往期回顾：Track 2 干货回顾

                       

                     Track 1：HBase Internal

Track1是专一于 HBase 内核的一个分会场，更可能是 HBase 开发者带来的分享。

• 小米在Track1作了两个分享，一个是介绍了 HBase 读路径上Offheap的优化和改进，主要是为了 HBase 的GC状况并下降 P99 延迟，另外一个则是基于Procedure V2 的 Split WAL/ACL 优化，新的实现不只保证了正确性，并且能够减小对于 ZooKeeper 的依赖，让将来部署 HBase 变得更加简单。

• Intel则主要介绍了如何把 Bucket Cache 放到新硬件 Persistent Memory 上，从价格和性能两方面综合考虑是一个不错的选择。

• Cloudera 主要是带来了关于 HBCK2 的分享，在 HBase 2.0版本以后，hbck1将只保留检查功能，必须使用 HBCK2 工具进行修复，因此 HBCK2 的完善对于 HBase 2.0 的稳定有着很重要的做用，目前社区也在继续完善中。

• Flipcart 介绍了他们关于数据一致性测试的工做，目前社区发版本，只会作ITBLL 的测试，对于 Replication 的数据一致性是缺少完善的检查的，Filpcart的工程师在 RoundTable 也提到了，后续计划把这部分工做贡献到社区。

• 阿里和华为的分享，更可能是介绍的公司内部在 HBase 上作的改进，期待能够早日贡献到开源社区。

一、HBCK2: Concepts, trends and recipes for fixing issues within HBase 2

PPT下载连接：http://t.cn/AijGUxMa

来自 Cloudera 的工程师 Wellington Chevreuil 给你们分享了 HBCK2 的最新进展。

HBCK1 实际上是一个相对成熟的工具了，能检查整个集群全部的 Region 是否健康，对各类常见的状况也能获得很好的修复。因为 HBase-2.x 根据 Procedure-V2 从新设计了几乎全部的操做流程，所以理论上发生状态不一致的几率会大大下降，但考虑到代码实现上可能会有 bug,因此设计了 HBCK2 来修复这些异常状态。

目前，HBCK2 已经变成了一个很是轻量级的修复工具，代码被单独放在一个叫hbase-operator-tools 的仓库中。首先须要编译拿到 JAR 包，而后经过 HBase 命令去执行修复操做。核心的几个修复操做有：

• assign 和 unassign region:

hbase hbck -j ../hbase-hbck2-1.0.0-SNAPSHOT.jar assigns 1588230740

• 发现 tableState 不一致时，能够用 setTableState 来实现修复。

• bypass 选项能够跳过某些卡住的 Procedure

除了修复操做以外，集群须要一个支持全局检查的工具，目前仍然能够经过 HBCK1来作全局的检查，但 HBCK1 的修复功能已经被 disabled 掉，若是须要可使用HBCK2 来修复。

二、Further GC optimization for HBase2.x: Reading HFileBlock into offheap directly

PPT下载连接：http://t.cn/AijGUQqC

这个议题由 Intel 的资深PMC成员 Anoop 和小米的工程师胡争合做分享。Anoop 主要介绍了 HBase2.0 的读写路径 offheap 的背景，根本目的在于指望最大限度的减小GC 对 p99 和 p999 延迟的影响，把核心的内存分配都挪到 GC 无关的 offheap 上了，请求延迟也就再也不受 STW 影响了。但小米 HBase 团队发现，即便在 HBase2.0上实现了 offheap 读写路径以后，在 cache 命中率不高的状况下，p999 依然受限于Young GC.后面调查发现，是由于 Cache Miss 以后，去 HDFS 文件读 block 时，仍然走的是 heap 申请，一个 block 64KB，因而就容易积累大量的 Young 区内存占用。

最直接解决思路是：将 block 读到一个 offheap 的 ByteBuffer 池子内，但发现因为RAMCache 的存在，没法找到合适的释放时机。因此小米团队采用引用计数来解决内存回收的问题。

具体的设计如上图所示，RegionServer 认为 RAMCache 和读路径上的 RpcHandler分别是两条独立的引用路径，有任何一条路径引用则不允许释放，一旦没有任何路径引用则必须释放。这能够说是本次分享最重要的一个点。

在小米的大数据集测试场景下，发现开启这个功能后，Young GC 次数能减小15~20%左右，每次 Young GC 可回收的内存减小80%左右，吞吐和延迟也有不一样程度的提高。一般咱们的 Cache 命中率都达不到100%，所以这个功能实际上是一个很好的性能优化点。咱们将在将来的 HBase2.3.0 以及 HBase3.0.0 中发布这个功能。

三、BDS: A data synchronization platform for HBase

PPT下载连接：http://t.cn/AijGUg1X

这个议题由 Ali-HBase 的数据链路负责人熊嘉男分享。主要介绍云端的跨 HBase 集群数据迁移的设计。对社区 HBase 用户来讲，目前跨集群数据迁移最佳的解决方案必定是经过 snapshot 和 replication 配合，分别来完成全量数据和增量数据的迁移。

阿里的 BDS 采用相似的思想，经过多个 worker 来并发拷贝 HFile，实现全量数据的迁移。注意，这个过程是不依赖 Yarn 集群的，并且 BDS 能够经过动态调整 worker来控制整个流程的数据迁移速率，另外迁移时还会尽可能考虑目标集群的 locality,是一种对云上用户很是友好的解决方案。

对于导全量过程当中产生的增量数据，BDS 是直接去扫 HLog 日志，而后将增量的HLog 写入到对端集群的，整个过程直接访问 HDFS,跟源端的 HBase 集群解耦。

对于云端用户来讲，这种方案便可用来作数据迁移，又能够用来作数据备份。将这个功能单独作成一套系统，对用户来讲确实是很友好的一个体验。

四、The Procedure v2 Implementation of WAL Splitting and ACL

PPT下载连接：http://t.cn/AijG4w1R

该议题由来自小米的 HBase Committer 梅祎分享，她也是中国区惟一的女性Committer.

分享主要分为3个部分：

第一部分：主要介绍了 ProcedureV2 的核心原理，在 PPT 中，她对 ProcedureV2 各组件的介绍以及执行回滚流程的演示，应该是我见过的全部讲 ProcedureV2 的文档中最清晰易懂的了。很是推荐对 ProcedureV2 感兴趣的朋友去学习一下这个PPT。

第二部分：介绍了如何用 ProcedureV2 重构社区的 HBase Grant/Revoke ACL 流程。重构的目的主要有几个：

• 原始设计采用 Zookeeper 通知机制来实现各 RegionServer的ACL 更新，整个过程依赖 Zookeeper,并且流程至关因而异步的。一旦某些 RS 的 ACL 缓存更新失败（有可能但几率很低），则容易形成各节点之间的 ACL 权限不一致。而采用ProcedureV2 重写以后，整个流程变成同步流程，则再也不存在这个问题了，此外还去掉该功能了对 Zookeeper 服务的依赖。

• 重构的另外一个初衷在于，指望在执行 Grant 和 Revoke 时能暴露一些 Coprocessor 接口。例若有一个很是经典的场景就是，某些用户指望经过扫Snapshot 来跑离线任务，但因为扫 Snapshot 须要 HDFS 的权限，而 HBase 的权限管理跟 HDFS 的权限管理彻底是两套机制。这时候，就能够实现一个Coprocessor 在 Grant 和 Revoke 时完成 HBase 权限和 HDFS 权限的同步，从而让那些有表权限的用户能立马访问表的 Snapshot.这个功能将在 HBASE-18659中支持。

第三部分：介绍了基于 ProcedureV2 重写了 WAL Splitting 的流程。考虑的点跟 ACL相似，主要是异步流程重写成更可控的同步流程，同时去掉了对 Zookeeper 的依赖。更多细节请参考演讲 PPT 和视频。

五、HBase Bucket Cache On Persistent Memory

PPT下载连接：http://t.cn/AijG4MFz

由来自 Intel 的资深PMC成员 Anoop 和 Ramkrishna 分享，他们的 Intel 同事 XuKai有参与介绍。Persistent Memory 是 Intel 研发的一种新型持久化内存，和 Intel 的朋友交流，听说成本只有内存的1/3，可是性能能到内存的90%左右，同时还能保证持久性。这是一种性价比很高的新型存储介质。

以小米机器为例，HBase 的机器都是128GB的内存，外加12块900GB左右的SSD盘。单机能存放近10TB的数据，但内存却只有128GB，内存容量和磁盘容量占比为1.1%。而实际上，延迟敏感型业务方对 HBase 的 Cache 命中率是有更高要求的，那怎么办？Intel 的思路就是将 Cache 放到容量更大、性能损耗可控的 Persistent Memory 上来，例如在10TB的机器上用1TB的 Persistent Memory 作 BucketCache,那 Cache 命中率将大幅提高。

从他们的测试结果能够看出，也确实是有很大性能提高的。

固然，咱们内部讨论过，若是没有 Persistent Memory 这种特殊的硬件支持，也能够考虑将 BucketCache 混合存放在内存和 SSD 上。简单来讲，就是将最热的数据存内存，次热的数据存 SSD.至少次热的数据是直接读的本地 SSD,不管是走 HDFS 本地短路读，仍是 HDFS 远程读，都不可能比跳过 HDFS 协议读本地 SSD 更快。

六、Distributed Bitmap Index Solution & Lightweight SQL Engine – Lemon SQL

PPT下载连接：http://t.cn/AijG4pjC

这个议题由华为的工程师郝行军和刘志分享，实际上是两个相对独立的议题，一个是基于 HBase 实现 Bitmap 索引，另一个是基于 HBase 实现轻量级的 SQL 引擎。

首先华为提出在安全领域，会对用户打不少标签。而后业务层面经过指定各类标签组合（用AND,OR,NOT等）来点查用户集合。所以，华为设计了基于 HBase 的 bitmap索引，借助 Coproccessor 来同时更新主表和索引表。

第二部分，华为工程师刘志介绍他们基于 HBase 实现的一种轻量级 SQL 查询引擎，相比 Phoenix,他们的实现更加轻量级、性能更高、吞吐扩展也更强。感兴趣的朋友能够在PPT末尾扫描他们的微信，跟两位工程师直接交流。

七、Test-suite for Automating Data-consistency checks on HBase

PPT下载连接：http://t.cn/AijG4nma

这是 HBase Track 1 专场最后一个Talk,由 Flipkart 的工程师 Pradeep 来分享（Flipkart 是由亚马逊的两名前员工于2007年建立，是印度最大电子商务零售商） 。

因为 Flipkart 是电商场景，因此他们对分布式数据库的数据一致性要求很是高。所以他们设计了一系列的测试集，用来评估每个版本的 HBase 是否知足他们严苛的数据一致性要求。他们设计的一些典型测试集有：zookeeper 网络断开、组件间网络丢包、时钟漂移、磁盘忽然变只读等，这对为 HBase 提供可靠的数据保证颇有帮助。

将来，Flipkart 会考虑开源他们的测试集到 github,供其余 HBase 的用户参考和评估。

                                                    关注“小米云技术”

                                    三期更新带你吸取所有 HBaseCon 干货

                                                        还在等什么？