桔妹導讀：HBase作為Hadoop生態中表現較為突出的分布式在線資料存盤產品，在滴滴有著非常廣泛的應用，但同樣存在比較突出的短板問題——例如可用性較弱、毛刺嚴重等，一定程度上限制了它的業務邊界，本文主要介紹在此背景下，HBase團隊近期進行的一些探索作業，

1.

背景

HBase 是一個基于 HDFS 的低成本、分布式LSM結構資料庫，可以支持毫秒級別查詢；支持海量的PB級的大資料存盤，適用于高QPS的隨機讀寫和前綴范圍查詢等場景，此外，優秀的開源環境使得HBase還可以支持豐富的上下游生態與離線任務，

目前在滴滴內部，HBase基本覆寫了全部業務線，資料量PB規模，吞吐超千萬級別；業務包含司乘軌跡、訂單、特征工程、推薦引擎、IOT、APM等各種場景，基于HBase的多模生態諸如OLAP（Kylin）、時序（OpenTSDB）、時空（GeoMesa）、圖（JanusGraph）亦均有應用，

2020年下半年，HBase團隊逐漸將視野投向端上/類端上業務，希望能夠承載更加重要的流量，然而對于HBase自身架構和實作而言，主要存在兩方面痛點：

▍1.可用性問題

架構層面看，HBase在CAP定理中選擇了C，以較弱的可用性為代價換取強一致性，資料層面依賴HDFS保證資料安全，計算層面region無副本，

這樣當region遷移、分裂、合并、RS宕機等情況發生時，對應region都會有短時不可用；而作為高吞吐的資料服務，客戶端往往都會大量使用執行緒池，少量region不可用會迅速形成木桶短板，進而放大為整體TPS掉底，

而這種“預期內的”抖動、掉底，是無法滿足互聯網行業端上場景的可用性要求的，

社區提供的region replica功能一定程度上可以緩解這一問題，但一方面目前這個feature可靠性還不算高，社區仍在推進各種加固和改善，目測穩定的目標release版本可能要放到未發布的3.0了；另一方面端上服務需要雙機房，保證容災和降級，而replica是集群內的region副本，顯然也不能支持，

▍2.毛刺問題

HBase主要受Java GC和底層HDFS共用影響，HBase的毛刺相對突出，是進一步提升性能的瓶頸點，

基于以上兩個痛點問題，HBase團隊近半年進行了一些嘗試與探索，主要是基于 replication的客戶端多路讀功能 與 HBase-ZGC應用實踐，預期能夠優化HBase的可用性與毛刺問題，簡單分享給大家，

2.

基于replication的客戶端多路讀功

2020年來，為提升HBase可用性，我們大體經歷了兩個階段：

1. replication主備

replication是HBase的異步資料同步機制，和Mysql利用Binlog實作主從庫類似，HBase利用WAL實作主備集群的資料同步，大致流程為主集群記錄寫入的WAL，并將資料異步發送給備集群，備集群接收資料并將其轉換為put/delete操作，批量寫入備集群，提供最終一致性保證，

圖片來源：HBase官方檔案

detailed_information_about_cluster_replication

這一階段存在的問題：

• 故障時用戶有感知，需用戶側切讀；

• 備集群利用率較低，資源閑置存在浪費；

2. replication + failover

failover是滴滴HBase團隊基于replication自研的增強feature，架構如下圖：

• 相比第一階段，failover可以基于zk實作服務切換，不需用戶操作，但仍然存在用戶有感知、備集群無法充分利用的問題；

• 基于以上背景，我們又開發了基于replication的客戶端多路讀功能，預期解決以下問題：

• • 故障時用戶無感知；

  • 提升備集群利用率；

  • 打磨HBase毛刺；

▍1. 設計

整體設計參考HDFS的hedgedRead功能，客戶端首先向主集群發起讀請求，一定時間沒有回傳結果則并發向備集群發起請求，兩者取先完成者回傳，

實際上HBase的regionReplica也是類似的實作，

▍2.新增配置

▍3.性能測驗

3.1 用例設計

1. 兩個集群分別創建主備測驗表，構建replication

2. ycsb打入100w測驗資料

3. 測驗組打開多路讀，對照組關閉多路讀，各發起10w次scan

4. 客戶端統計max、P999、P99

3.2 測驗結論

max對比

P999對比

P99對比

多路讀對于max和P999有較佳優化效果，可以有效打磨毛刺，

▍4.未盡事項和思考

1. 多路讀功能基于replication實作，因此只能實作最終一致性，備集群讀到的資料有可能和主集群存在差異；

2. 目前此功能僅作用于查詢，主集群宕機時，最新資料無法同步，因此備集群查詢最新資料可能查詢不到；

3. HBase的scan操作可能分解為多次RPC，由于相關session資訊在不同集群間沒有同步，資料也不能保證完全一致，因此多路讀只在第一次RPC時生效，之后的請求會固定訪問第一次RPC時最終使用的集群，

多路讀本質上是多活建設，但CAP較難跨越，多活可以提供高可用能力，但強一致性很難得到保障，

但我們可以通過“讓用戶選擇”的方式來解決這一問題：

• 方案一：多活 + 最終一致性

• 方案二：主備 + 強一致性

對于方案一，當前的多路讀實作了讀鏈路的多活，寫鏈路仍有優化空間，例如提升replication效率、降低兩集群間資料lag等；

對于方案二，可以基于社區的同步replication實作，此外failover的功能仍需我們做更多作業，實作更加智能的自動切換，降低用戶感知，

3.

HBase-ZGC應用實踐

▍1.為什么要更換GC演算法？

隨著滴滴內部越來越多的端上和類端上業務使用HBase作為存盤引擎，用戶對HBase讀寫延遲穩定性的要求也越來越高，HBase的GC毛刺問題尤為突出，G1無法滿足性能需求，

好訊息是JDK15在9月15號正式發布，劃時代的ZGC正式轉正，我們決定嘗試用ZGC來解決GC毛刺問題，

ZGC（The Z Garbage Collector）：ZGC是JDK11之后發布的一款可伸縮的低延遲JVM垃圾收集器，

ZGC官方的設計目標如下：

• Max pause times of a few milliseconds(*)

• Pause times do not increase with the heap or live-set size (*)

• Handle heaps ranging from a 8MB to 16TB in size

ZGC 是一個并發的、單代的、基于區域的、NUMA 感知的壓縮收集器，Stop-the-world 階段僅限于根掃描，因此 GC 暫停時間不會隨堆或活動集（live set）的變大而增加，

ZGC 的核心設計原則是將Load barriers與染色物件指標結合使用，這使得 ZGC 能夠在 Java 應用程式執行緒運行時執行并發操作，例如物件重定向，從 Java 執行緒的角度來看，在 Java 物件中加載參考欄位的行為受到加載屏障的影響，除了物件地址之外，colored oops 還包含加載屏障使用的資訊，以確定在允許 Java 執行緒使用指標之前是否需要采取某些操作，

ZGC相比G1

• 更低延遲：GC停頓時間更短，不超過 10ms

• 更大記憶體：堆記憶體支持范圍更大（8MB-16TB）

SPECjbb 2015基準測驗，128G堆，ZGC的暫停時間遠低于G1

相較于G1只有寫屏障沒有讀屏障，復制移動的程序需要Stop the world，ZGC通過讀屏障、Remark標記和重定向表來并發拷貝非GC Roots物件，盡可能的減少了Stop the world，

官方的性能測驗對比可以參考JEP333，本文主要介紹HBase場景的ZGC應用實踐，對ZGC的原理不展開介紹，

▍2. HBase應用ZGC實踐

2.1 選擇JDK版本

由于需要在生產環境使用，而Orace JDK商業使用開始收費，所以我們需要一個免費版的JDK，經過對比，我們最終選取了AdoptOpenJDK的JDK15版本，

1）AdoptOpenJDK 是社區（倫敦JUG）維護版的OpenJDK，提供預構建的二進制檔案，主要維護LTS及最新版本；和OpenJDK一樣，AdoptOpenJDK 也支持 GPL 協議且免費，不同的是OpenJDK只會由Oracle提供6個月的安全更新，而AdoptOpenJDK則由社區提供至少4年的免費長期支持（LTS），

2）選擇JDK15的原因：

• JDK11存在小概率crash的問題

• ZGC在JDK15版本正式生產環境可用

2.2 編譯HBase（基于AdoptOpenJDK15）

滴滴內部使用的HBase版本是基于社區1.4.8基礎上開發的版本，不支持JDK11及以上版本的編譯，所以需要解決一些編譯問題，

社區3.x及2.3.x版本開始支持JDK11，參考 HBASE-22972，在1.4.8版本的編譯程序中，主要遇到了以下幾類編譯問題：

• 1. 部分類找不到或被洗掉，比如javax.xml.ws.http.HTTPException，解決辦法：找到替換類或依賴包；

• 2. 一些類不可讀，比如sun.nio.ch.DirectBuffer，解決辦法：運行時添加--add-exports=java.base/sun.nio.ch=ALL-UNNAMED；

• 3. 依賴的組件包不支持JDK15，如Jetty、Jruby等，解決辦法：升級對應的組件到高版本；

• 4. 編譯插件不支持JDK15，如maven-shade-plugin、extra-enforcer-rules等，解決辦法：升級對應的插件到高版本，

2.3 應用ZGC的效果：

1、順序讀場景ZGC和G1性能表現對比

Scan場景下，ZGC的P99延遲降低20%，P999降低40%，

2、壓力測驗場景對比ZGC和G1的性能表現

構造寫壓力測驗場景，RegionServer的全域Memstore寫滿，觸發Upper Limit，G1GC回收不過來，觸發Full GC，耗時超過40s（ZK會話的超時時間），RS服務會宕機，

對比同等寫入壓力下，ZGC 99.93%的回收時間都在10ms以內，只有2次在10~20ms之間，RS服務未宕機，

備注：如果記憶體分配過快，ZGC也可能會出現回收不過來的問題，這種情況下可以通過增大堆記憶體的方式緩解，

HBase使用ZGC可以有效的降低了服務端P99及P999的延時，非常適合對延遲較敏感的業務場景，

3.

總結

HBase在真正海量資料的離線應用場景下具備毋庸置疑的競爭力，但受其自身實作短板的限制，距離端上應用的標準還是存在一定距離的，滴滴HBase希望通過一系列優化手段，服務好離線業務的同時，未來可以接入更多的不涉及核心流程的線上/類線上業務，歡迎感興趣的同學一起交流，

本文作者

?

團隊招聘

?

滴滴大資料架構離線引擎&HBase 團隊主要負責滴滴集團大資料離線存盤、離線計算、NoSQL 等引擎的開發與運維作業，通過持續應用和研發新一代大資料技術，構建穩定可靠、低成本、高性能的大資料基礎設施，更多賦能業務，創造更多價值，

團隊持續招聘 HDFS、YARN，Spark，HBase 等領域專家，參與滴滴大資料架構的建設作業，歡迎加入，

可投遞簡歷到 diditech@didiglobal.com，郵件主題請命名為「姓名-應聘部門-應聘方向」，

掃碼了解更多崗位

延伸閱讀

?

內容編輯 | Teeo

聯系我們 | DiDiTech@didiglobal.com