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 來修復。

2、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 中發布這個功能。

3、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,是一種對云上用戶非常友好的解決方案。

對于云端用戶來說，這種方案即可用來做數據遷移，又可以用來做數據備份。將這個功能單獨做成一套系統，對用戶來說確實是很友好的一個體驗。

4、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 和視頻。

5、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 更快。

6、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末尾掃描他們的微信，跟兩位工程師直接交流。

7、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 干貨

還在等什么？