13518219792
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 上做的改进，期待可以早日贡献到开源社区。
1、H BCK2: Concepts, t rends 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 来修复。
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 中发布这个功能。
PPT下载链接： http://t.cn/AijGUg1X
这个议题由 Ali-HBase 的数据链路负责人熊嘉男分享。主要介绍云端的跨 HBase 集群数据迁移的设计。对社区 HBase 用户来说，目前跨集群数据迁移最佳的解决方案一定是通过 snapshot 和 replication 配合，分别来完成全量数据和增量数据的迁移。
阿里的 BDS 采用类似的思想，通过多个 worker 来并发拷贝 HFile，实现全量数据的迁移。注意，这个过程是不依赖 Yarn 集群的，而且 BDS 可以通过动态调整 worker来控制整个流程的数据迁移速率，另外迁移时还会尽量考虑目标集群的 locality,是一种对云上用户非常友好的解决方案。
对于导全量过程中产生的增量数据，BDS 是直接去扫 HLog 日志，然后将增量的HLog 写入到对端集群的，整个过程直接访问 HDFS,跟源端的 HBase 集群解耦。
对于云端用户来说，这种方案即可用来做数据迁移，又可以用来做数据备份。将这个功能单独做成一套系统，对用户来说确实是很友好的一个体验。
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 和视频。
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 更快。
PPT下载链接： http://t.cn/AijG4pjC
这个议题由华为的工程师郝行军和刘志分享，其实是两个相对独立的议题，一个是基于 HBase 实现 Bitmap 索引，另外一个是基于 HBase 实现轻量级的 SQL 引擎。
首先华为提出在安全领域，会对用户打很多标签。然后业务层面通过指定各种标签组合（用AND,OR,NOT等）来点查用户集合。因此，华为设计了基于 HBase 的 bitmap索引，借助 Coproccessor 来同时更新主表和索引表。
第二部分，华为工程师刘志介绍他们基于 HBase 实现的一种轻量级 SQL 查询引擎，相比 Phoenix,他们的实现更加轻量级、性能更高、吞吐扩展也更强。感兴趣的朋友可以在PPT末尾扫描他们的微信，跟两位工程师直接交流。
PPT下载链接： http://t.cn/AijG4nma
这是 HBase Track 1 专场最后一个Talk,由 Flipkart 的工程师 Pradeep 来分享（Flipkart 是由亚马逊的两名前员工于2007年创建，是印度大电子商务零售商） 。
由于 Flipkart 是电商场景，所以他们对分布式数据库的数据一致性要求非常高。因此他们设计了一系列的测试集，用来评估每一个版本的 HBase 是否满足他们严苛的数据一致性要求。他们设计的一些典型测试集有：zookeeper 网络断开、组件间网络丢包、时钟漂移、磁盘突然变只读等，这对为 HBase 提供可靠的数据保证很有帮助。
未来，Flipkart 会考虑开源他们的测试集到 github,供其他 HBase 的用户参考和评估。
关注“小米云技术”
三期更新带你吸收全部 HBaseCon 干货
还在等什么？
