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 乾貨

                                                        還在等什麼？