平台篇-58 HBase 平台實踐和應用

HBase 是一個基于 Hadoop 的分布式、面向列的 Key-Value 存儲系統，可以對需 要實時讀寫、随機通路大規模資料集的場景提供高可靠、高性能的服務，在大數 據相關領域應用廣泛。HBase 可以對資料進行透明的切分，使得存儲和計算本身 具有良好的水準擴充性。

在 58 的業務場景中，HBase 扮演重要角色。例如文章資訊等公司基礎資料都是 通過 HBase 進行離線存儲，并為各個業務線提供随機查詢及更深層次的資料分 析。同時 HBase 在 58 還大量用于使用者畫像、搜尋、推薦、時序資料和圖資料等 場景的存儲和查詢分析。

HBase 在 58 的應用架構:

**

HBase 在 58 的應用架構如上圖所示，主要内容包括以下幾個部分:**

1. 多租戶支援:包括 SCF 限流、RSGroup、RPC 讀寫分離、HBase Quota 、ACL;
2. 資料讀寫接口:包括 SCF 代理 API、原生 Java API 以及跨語言通路 Thrift Server;

3. HBase 資料導入導出:包括資料批量導入工具 BulkLoad，資料批量導出工具

   SnapshotMR;

4. OLAP:多元分析查詢的 Kylin 平台;
5. 時序資料庫:時序資料存儲和查詢的時序資料庫 Opentsdb;
6. 圖資料庫:圖關系資料存儲和查詢的圖資料庫 JanusGraph;
7. SQL on HBase:支援二級索引和事務的 Phoenix，以及 Spark SQL 等;

8. HBase 在 58 的應用業務場景包括:全量文章資料、使用者畫像、搜尋、推薦、

   使用者行為、智能監控以及風控反欺詐等的資料存儲和分析;

9. 監控平台:HBase 平台的監控實作。

本文将從多租戶支援、資料讀寫接口、資料導入導出和平台優化四個方面來重點 講解 58HBase 平台的建設。

說明:下文中所有涉及到 RegionServer 的地方統一使用 RS 來代替。

1. HBase 多租戶支援

HBase 在 1.1.0 版本之前沒有多租戶的概念，同一個叢集上所有使用者、表都是同 等的，導緻各個業務之間幹擾比較大，特别是某些重要業務，需要在資源有限的 情況下保證優先正常運作，但是在之前的版本中是無法保證的。從 HBase 1.1.0 開始，HBase 的多租戶特性逐漸得到支援，我們的 HBase 版本是 1.0.0-cdh5.4.4， 該版本已經內建了多租戶特性。

以下是 58 使用者通路 HBase 的流程圖:

我們從多個層面對 HBase 多租戶進行了支援，主要分為以下兩個大的方面:

1. 資源限制:

   a) SCF Quota;

b) HBase Quota。

1. 資源隔離:

   a) RS RPC 讀寫分離;

b) HBase ACL 權限隔離;

c) RSGroup 實體隔離。

**1.1 資源限制

(1)SCF Quota**

SCF 是公司自研的 RPC 架構，我們基于 SCF 封裝了原生 HBase API，使用者根據應 用需要申請 HBase SCF 服務調用時，需要根據應用實際情況填寫 HBase 的每分 鐘調用量(請求次數)，在調用量超限時，SCF 管理平台可以實作應用級的限流， 這是全局限流。缺點是隻能對調用量進行限制，無法對讀寫資料量大小限制。

以下是使用者申請 HBase SCF 服務調用時需要填寫的調用量:

(2)HBase Quota

HBase 的 Quota 功能可以實作對使用者級、表級和命名空間級的資源進行限制。這 裡的資源包括請求資料量大小、請求次數兩個次元，這兩個次元基本涵蓋了常見 的資源限制。目前 HBase 的 Quota 功能隻能限制到 RS 這一級，不是針對整個集 群的。但是因為可以對請求的資料量大小進行限制，一定程度上可以彌補了 SCF Proxy 應用級限流隻能對請求次數進行限制的不足。

開啟 Quota 的配置如下:

在開啟了 HBase 的 Quota 後，Quota 相關的中繼資料會存儲到 HBase 的系統表 hbase:quota 中。

在我們的 HBase 叢集中之前遇到過個别使用者讀寫資料量過大導緻 RS 節點帶寬被 打滿，甚至觸發 RS 的 FGC，導緻服務不穩定，影響到了其他的業務，但是應用級的調用量并沒有超過申請 SCF 時設定的值，這個時候我們就可以通過設定 HBase Quota，限制讀寫表級資料量大小來解決這個問題。

以下是設定 HBase Quota 資訊，可以通過指令行進行設定和檢視:

1.2 資源隔離

(1)RS RPC 讀寫分離

預設場景下，HBase 隻提供一個 RPC 請求隊列，所有請求都會進入該隊列進行 優先級排序。這樣可能會出現由于讀問題阻塞所有 handler 線程導緻寫資料失敗， 或者由于寫問題阻塞所有 handler 線程導緻讀資料失敗，這兩種問題我們都遇到過，在後續篇幅中會提到，這裡不細述。

通過設定參數 hbase.ipc.server.callqueue.handler.factor 來設定多個隊列，隊列個數等于該參數 * handler 線程數，比如該參數設定為 0.1，總的 handler 線程數為200，則會産生 20 個獨立隊列。 獨立隊列産生之後，可以通過參數 hbase.ipc.server.callqueue.read.ratio 來設定讀寫隊列比例，比如設定 0.6，則表示會有 12 個隊列用于接收讀請求，8 個用于接收寫請求;另外，還可以進一步 通過參數 hbase.ipc.server.callqueue.scan.ratio 設定 get 和 scan 的隊列比例，比 如設定為 0.2，表示 2 個隊列用于 scan 請求，另外 10 個用于 get 請求，進一步還将 get 和 scan 請求分開。

RPC 讀寫分離設計思想總體來說實作了讀寫請求隊列資源的隔離，達到讀寫互不幹擾的目的，根據 HBase 叢集服務的業務類型，我們還可以進一步配置長時 scan 讀和短時 get 讀之間的隊列隔離，實作長時讀任務和短時讀任務互不幹擾。

(2)HBase ACL 權限隔離

HBase 叢集多租戶需要關注的一個核心問題是資料通路權限的問題，對于一些重 要的公共資料，或者要進行跨部門通路資料，我們隻開放給經過權限申請的使用者 通路，沒有權限的使用者是不能通路的，這就涉及到了 HBase 的資料權限隔離了， HBase 是通過 ACL 來實作權限隔離的。

基于 58 的實際應用情況，通路 HBase 的使用者都是 Hadoop 計算叢集的使用者，而 且 Hadoop 使用者是按部門配置設定的，是以 HBase 的使用者也是到部門而不是到個人， 這樣的好處是維護的使用者數少了，便于管理，缺點是有的部門下面不同子部門之 間如果也要進行資料權限隔離就比較麻煩，需要單獨申請開通子部門賬号。

要開啟 HBase 的 ACL，隻需要在配置檔案 hbase-site.xml 中關于 Master、 RegionServer 和 Region 的協處理器都加上 org.apache.hadoop.hbase.security.access.AccessController 類就可以了。

具體 HBase ACL 的配置項如下圖所示:

HBase 的通路級别有讀取(R)、寫入(W)、執行(X)、建立(C)、管理者(A)，而權限作 用域包括超級使用者、全局、命名空間、表、列族、列。通路級别和作用域的組合 建立了可授予使用者的可能通路級别的矩陣。在生産環境中，根據執行特定工作所 需的内容來考慮通路級别和作用域。

在 58 的實際應用中，我們将使用者和 HBase 的命名空間一一對應，建立新使用者時， 建立同名的命名空間，并賦予該使用者對同名命名空間的所有權限(RWCA)。以下 以新使用者 zhangsan 為例，建立同名命名空間并授權:

(3)RSGroup 實體隔離

雖然 SCF Quota 和 HBase Quota 功能可以做到對使用者的讀寫進行限制，一定程度上能降低各業務讀寫資料的互相幹擾，但是在我們的實際業務場景中，存在兩類特殊業務，一類是消耗資源非常大，但是不希望被限流，另外一類是非常重要， 需要高優先級保證服務的穩定。對于這兩種情況下，我們隻能對該業務進行實體隔離，實體隔離既能保證重要業務的穩定性，也避免了對其他業務的幹擾。我們使用的實體隔離方案是 RSGroup，也即 RegionServer Group。

RSGroup 整體架構:

RSGroup 有以下幾個特點:

1. 不同 RS 和表劃分到不同的 RSGroup;
2. 同一個 RS 隻能屬于一個 RSGroup;
3. 同一個表也隻能屬于一個 RSGroup;
4. 預設所有 RS 和表都屬于“default”這個 RSGroup。

RSGroup 實作細節:

從以上 RSGroup 實作細節中看出，RSGroup 的功能主要包含兩部分，RSGroup 中繼資料管理以及 Balance。

RSGroup 開啟的配置項:

1. 資料讀寫接口

   目前我們提供了三種 HBase 的資料讀寫接口以便于使用者使用，包括 SCF 代理、 Java 原生 API 和 Thrift Server。以下分别進行說明:

2.1 SCF Proxy

SCF 是 58 架構部自研的 RPC 架構，我們基于 SCF 封裝了原生的 Java API，以 SCF RPC 接口的方式暴露給使用者使用，其中以這種方式提供給使用者的接口多達 30 個。 由于 SCF 支援跨語言通路，很好的解決了使用非 Java 語言使用者想要通路 HBase 資料的問題，目前使用者使用最多的是通過 Java、Python 和 PHP 這三種語言來通路這些封裝的接口。

SCF proxy 接口整體架構:

資料讀寫流程:使用者通過 RPC 連接配接到 SCF 服務管理平台，通過 SCF 服務管理平 台做服務發現，找到 58 雲計算平台上部署的服務節點，服務節點最終通過通路 HBase 實作使用者資料的讀寫操作。

使用 SCF Proxy 接口的優勢:

1. 避免使用者直連 HBase 叢集，降低 zk 的壓力。之前經常遇到因為使用者代碼存 在 bug，導緻 zk 連接配接數暴漲的情況。
2. 針對大量一次性掃描資料的場景，提供單獨通路接口，并在接口中設定 scan 的 blockcache 熟悉為 false，避免了對後端讀緩存的幹擾。
3. 通過服務管理平台的服務發現和服務治理能力，結合業務的增長情況以及基 于 58 雲計算平台彈性特點，我們很容易對服務節點做自動擴容，而這一切對使用者是透明的。
4. 通過服務管理平台可以實作對使用者的通路做應用級限流，規範使用者的讀寫操作。
5. 服務管理平台提供了調用量、查詢耗時以及異常情況等豐富的圖表，使用者可以很友善檢視。

以下是我們的 SCF 服務在服務管理平台展示的調用量和查詢耗時圖表:

由于 SCF Proxy 接口的諸多優勢，我們對于新接的業務都要求通過申請這種方式 來通路 HBase。

2.2 Java API

由于曆史原因和個别特殊的新業務還采用 Java 原生的 API 外，其他新業務都通 SCF Proxy 接口來通路。

2.3 Thrift Server**

也是由于曆史原因，個别使用者想使用非 Java 語言來通路 HBase，才啟用了 Thrift Server，由于 SCF proxy 接口支援多語言，目前這種跨語言通路的問題都通過 SCF Proxy 來解決了。

3. 資料導入導出 3.1 BulkLoad

3.1 BulkLoad

HBase 相對于其他 KV 存儲系統來說比較大的一個優勢是提供了強大的批量導入 工具 BulkLoad，通過 BulkLoad，我們很容易将生成好的幾百 G，甚至上 T 的 HFile 檔案以毫秒級的速度導入 HBase，并能馬上進行查詢。是以對于曆史資料和非實 時寫入的資料，我們會建議使用者通過 BulkLoad 的方式導入資料。

3.2 SnapshotScanMR

針對全表掃描的應用場景，HBase 提供了兩種解決方案，一種是 TableScanMR， 另一種就是 SnapshotScanMR，這兩種方案都是采用 MR 來并行化對資料進行掃描，但是底層實作原理确是有很大差别，以下會進行對比分析。

TableScanMR 的實作原理圖:

TableScanMR 會将 scan 請求根據 HBase 表的 region 分界進行分解，分解成多個 sub-scan(一個 sub-scan 對應一個 map 任務)，每個 sub-scan 内部本質上就是一個 ScanAPI。假如 scan 是全表掃描，那這張表有多少 region，就會将這個 scan 分解成多個 sub-scan，每個 sub-scan 的 startkey 和 stopkey 就是 region 的 startkey 和 stopkey。這種方式隻是簡單的将 scan 操作并行化了，資料讀取鍊路 和直接 scan 沒有本質差別，都需要通過 RS 來讀取資料。

SnapshotScanMR 的實作原理圖:

SnapshotScanMR 總體來看和 TableScanMR 工作流程基本一緻，不過 SnapshotScanMR 的實作依賴于 HBase 的 snapshot，通過 shapshot 的中繼資料資訊，SnapshotScanMR 可以很容易知道目前全表掃描要通路那些 HFile以及這些 HFile 的 HDFS 路徑，是以 SnapshotScanMR 構造的 sub-scan 可以繞過 RS，直接 借用 Region 中的掃描機制直接掃描 HDFS 中資料。

SnapshotScanMR 優勢:

1. 避免對其他業務的幹擾:SnapshotScanMR 繞過了 RS，避免了全表掃描對其 他業務的幹擾。
2. 極大的提升了掃描效率:SnapshotScanMR 繞過了 RS，減少了一次網絡傳輸， 對應少了一次資料的序列化和反序列化操作;TableScanMR 掃描中 RS 很可 能會成為瓶頸，而 SnapshotScanMR 不需要擔心這一點。

基于以上的原因，在全部掃描，以及全部資料導出的應用場景中，我們選擇了 SnapshotScanMR，并對原生的 SnapshotScanMR 進行了進一步的封裝，作為一個通用工具提供給使用者。

4. 平台優化

在使用 HBase 的過程中，我們遇到了很多問題和挑戰，但最終都一一克服了，以下是我們遇到一部分典型問題及優化:

4.1 CLOSE_WAIT 偏高優化

問題描述:在一次排查 HBase 問題的時候發現 RS 程序存在大量的 CLOSE_WAIT， 最多的達到了 6000+，這個問題雖然還沒有直接導緻 RS 挂掉，但是也确實是個 不小的隐患。

從 socket 的角度分析産生 CLOSE_WAIT 的原因:對方主動關閉連接配接或者網絡異 常導緻連接配接中斷，這時我方的狀态會變成 CLOSE_WAIT， 此時我方要調用 close() 來使得連接配接正确關閉，否則 CLOSE_WAIT 會一直存在。

對應到咱們這個問題，其實就是使用者通過 RS 通路 DataNode(端口 50010)的數 據，DataNode 端已經主動關閉 Socket 了，但是 RS 端沒有關閉，是以要解決的 問題就是 RS 關閉 Socket 連接配接的問題。

解決辦法:社群對該問題的讨論見 HBASE-9393。該問題的修複依賴 HDFS-7694， 我們的 Hadoop 版本是 hadoop2.6.0-cdh5.4.4，已經內建了 HDFS-7694 的内容。

HBASE-9393 的核心思想是通過 HDFS API 關閉 HBase 兩個地方打開的 Socket；

RS 打開 HFile 讀取中繼資料資訊(flush、bulkload、move、balance 時)後關閉 Socket;每次執行完成使用者 scan 操作後關閉 Socket。

優化效果:CLOSE_WAIT 數量降為 10 左右

4.2 DN 慢盤導緻 RS 阻塞優化

問題描述:由于叢集某個磁盤出現壞道(沒有完全壞，表現為讀寫慢，disk.io.util 為 100%)，導緻 RS 所有 handler 線程因為寫 WAL 失敗而被阻塞，無法對外提 供服務，嚴重影響了使用者讀寫資料體驗。

最後分析發現，RS 寫 WAL 時由于 DN 節點出現磁盤壞道(表現為 disk.io.util 為長時間處于 100%)，導緻寫 WAL 的 pipeline 抛出異常并誤将正常 DN 節點标記為 bad 節點，而恢複 pipeline 時使用 bad 節點進行資料塊 transfer，導緻 pipeline 恢複失敗，最終 RS 的所有寫請求都阻塞到 WAL 的 sync 線程上，RS 由于沒有可用的 handler 線程，也就無法對外提供服務了。

解決辦法:RS 配置 RPC 讀寫分離:避免由于寫阻塞所有 handler 線程，影響到讀請求;

pipeline 恢複失敗解決:社群已有該問題的讨論，見并 HDFS-9178，不過因為 HDFS 的 pipeline 過程非常複雜，HDFS-9178 能否解決該問題需要進一步驗證。

4.3 Compact 占用 Region 讀鎖優化

問題描述:某次有一個業務執行 BulkLoad 操作批量導入上 T 的資料到 HBase 表時，RS 端報 BulkLoad 操作擷取 Region 級寫鎖出現逾時異常:failed to get a lock in 60000 ms，當時該表并沒有進行讀寫操作，最終定位到是該時間段内這個業務 的表正在進行 compact 操作，在我們的 HBase 版本中，執行 compact 時會擷取 Region 級的讀鎖，而且會長時間占用，所有導緻 BulkLoad 擷取寫鎖逾時了。

解決辦法:Compact 時不持有 Region 讀鎖，社群對該問題的讨論見 HBASE-14575。

4.4 HTablePool 問題優化

問題描述:我們的 SCF 服務最初是基于 HTablePool API 開發的，SCF 服務在運 行一段時間後經常會出現 JVM 堆記憶體暴增而觸發 FGC 的情況，分析發現 HTablePool 已經是标記為已廢棄，原因是通過 HTablePool 的擷取 Table 對象，會建立單獨的線程池，而且線程個數沒有限制，導緻請求量大時，線程數會暴增。

解決辦法:最後我們換成了官方推薦的 API，通過 Connection 擷取 Table，這種方式 Connection 内部的線程池可以在在所有表中共享，而且線程數是可配置的。

4.5 其他優化

BlockCache 啟用 BuckCache;Compact 限流優化等。

5. 總結

Apache HBase 實戰技術總結 – 中國 HBase 技術社群

本文從多租戶支援、資料讀寫接口、資料導入導出和平台優化四個方面講解了 HBase 相關的平台建設工作。HBase 作為一個開源的平台，有着非常豐富的生态 系統。在 HBase 平台基礎之上，我們持續不斷地引入了各種新的能力，包括 OLAP、 圖資料庫、時序資料庫和 SQL on HBase 等，這些我們将在 58HBase 平台實踐和應用的後續篇章中進一步介紹。

轉載

文章作者：何良均/張祥——58 同城 資深研發工程師