作者簡介：
陳海峰，移動云數據庫 Apache HBase 開發人員，對 Apache HBase、RBF、Apache Spark 有濃厚興趣。

背景

Apache HBase 是 Apache Hadoop 生態體系中的大規模、可擴展、分布式的數據存儲服務。同時它還是 NoSQL 數據庫。它的設計初衷是為包含了數百萬列的數十億行記錄提供隨機的、強一致性的實時查詢。默認情況下，HBase 的數據會保存在 HDFS 上，HBase 為 HDFS 做了很多優化來保證穩定性與性能。但是維護 HDFS 本身一點也不輕松，要不斷進行監控、運維、調優、擴容、災難恢復等一系列事情，而且在公有云上搭建 HDFS 的費用也是相當高的。為了節省費用、降低維護成本，一些用戶使用 S3（或其他對象存儲）存儲 HBase 的數據。使用 S3 省去了監控運維的麻煩，同時還實現了存儲計算分離，讓 HBase 的擴容縮容都變得更加容易。

然而，HBase 數據接入對象存儲卻不是一件容易的事兒。對象存儲一方面因為自身特性，功能和性能有限，一旦數據被寫入對象存儲后，數據對象即不可改變，另一方面使用文件系統語義訪問塊存儲有天然局限性。在使用 Hadoop 原生的 AWS 客戶端來訪問對象存儲時，目錄重命名操作會遍歷整個目錄下文件進行拷貝和刪除，性能非常低下。另外重命名操作也會導致原子性問題，即原本的重命名操作分解為拷貝和刪除兩個操作，在極端情況下易產生用戶數據視圖不一致情況。類似的還有查詢目錄所有文件的總大小，原理是通過遍歷迭代依次獲取某個目錄的所有文件信息。如果目錄下的子目錄和文件數量龐大的話，查詢目錄所有文件總大小復雜度更大，性能更差。

方案選型

經過大量方案調研和社區問題跟蹤，目前云 HBase 數據接入對象存儲有三種方案。

第一種是 HBase 使用 Hadoop 原生 AWS 客戶端來訪問對象存儲，即 S3AFileSystem。HBase 內核代碼只需要稍加改動即可使用 S3AFileSystem。這種 HBase 直接對接對象存儲的方案一個需要解決的痛點問題，即目錄的 rename。HBase 在 Hlog 文件管理、MemStore Flush、表創建、region compaction 和 region split 時都會涉及目錄的 rename。社區對 StoreFIle 進行了優化，解決了一部分的 rename 性能問題。完全解決目錄操作性能問題需要對 HBase 內核源碼進行大刀闊斧地變動。

第二個方案是引入 Alluxio 作為緩存加速，不僅大大提升讀寫性能，而且引入文件元數據管理，徹底解決了目錄操作性能低下問題。看似圓滿的結局，背后卻有很多限制條件。當 Alluxio 配置僅僅使用內存時，對目錄操作耗時才是 ms 級別。如果配置 Alluxio 的 UFS，Alluxio 中的元數據操作有兩個步驟：第一步是修改 Alluxio master 的狀態，第二步是向 UFS 發送請求。可以看到，元數據操作仍然不是原子的，當操作正在執行或發生任何故障時，其狀態是不可預測的。Alluxio 依賴 UFS 來實現元數據操作，比如重命名文件操作會變成復制和刪除操作。HBase 中數據必定是需要落盤的，Alluxio 解決不了目錄操作性能問題。

第三種方案是在 HBase 與對象存儲之間引入 JuiceFS 共享文件系統。使用 JuiceFS 存儲數據，數據本身會被持久化在對象存儲（例如，移動云 EOS），相對應的元數據可以按需持久化在 Redis、MySQL 等多種數據庫中。此方案中對目錄操作完成是在 Metadata Engine 中完成，與對象存儲無交互，操作耗時在 ms 級別，可以解決 HBase 數據接入對象存儲的痛點問題。但是由于 JuiceFS 內核采用 Go 語言編寫，對后期性能調優和日常維護帶來一定挑戰。

權衡上述三個方案利弊，最終采用 JuiceFS 作為云 HBase 支持對象存儲的解決方案。下面著重討論 JuiceFS 在云 HBase 支持對象存儲中的實踐以及性能調優。

方案介紹

首先介紹下 JuiceFS 的架構。JuiceFS 由兩個主要部分組成：JuiceFS 元數據（Metadata）服務和對象存儲。JuiceFS Java SDK 完全兼容 HDFS API，同時也提供基于 FUSE 的客戶端掛載，完全兼容 POSIX。作為文件系統，JuiceFS 會分別處理數據及其對應的元數據，數據會被存儲在對象存儲中，元數據會被存儲在元數據引擎中。在數據存儲方面，JuiceFS 支持幾乎所有的公有云對象存儲，同時也支持 OpenStack Swift、Ceph、MinIO 等支持私有化部署的開源對象存儲。在元數據存儲方面，JuiceFS 采用多引擎設計，目前已支持 Redis、TiKV、MySQL/MariaDB、PostgreSQL、SQLite 等作為元數據服務引擎。

任何存入 JuiceFS 的文件都會被拆分成固定大小的 “Chunk”，默認的容量上限是 64 MiB。每個 Chunk 由一個或多個 “Slice” 組成，Slice 的長度不固定，取決于文件寫入的方式。每個 Slice 又會被進一步拆分成固定大小的 “Block”，默認為 4 MiB。最后，這些 Block 會被存儲到對象存儲。與此同時，JuiceFS 會將每個文件以及它的 Chunks、Slices、Blocks 等元數據信息存儲在元數據引擎中。

使用 JuiceFS，文件最終會被拆分成 Chunks、Slices 和 Blocks 存儲在對象存儲。因此，對象存儲平臺中找不到存入 JuiceFS 的源文件，存儲桶中只有一個 chunks 目錄和一堆數字編號的目錄和文件。

HBase 組件使用 JuiceFS 需要以下配置。首先將編譯好的客戶端 SDK 置于 HBase classpath 內。其次將 JuiceFS 相關配置寫入配置文件 core-site.xml，如下表所示。最后使用 juicefs 客戶端格式化文件系統。

配置項默認值描述

fs.jfs.impl	io.juicefs.JuiceFileSystem	指定要使用的存儲實現，默認使用 jfs://
fs.AbstractFileSystem.jfs.impl	io.juicefs.JuiceFS
juicefs.meta		指定預先創建好的 JuiceFS 文件系統的元數據引擎地址。

在元數據存儲方面，使用 MySQL 作為元數據存儲。格式化文件系統命令如下。可見，格式化文件系統需要提供以下信息：

• --storage：設置存儲類型，比如移動云 EOS；
• --bucket：設置對象存儲的 Endpoint 地址；
• --access-key：設置對象存儲 API 訪問密鑰 Access Key ID；
• --secret-key：設置對象存儲 API 訪問密鑰 Access Key Secret。

juicefs format --storage eos \ --bucket https://myjfs.eos-wuxi-1.cmecloud.cn \ --access-key ABCDEFGHIJKLMNopqXYZ \ --secret-key ZYXwvutsrqpoNMLkJiHgfeDCBA \ mysql://username:password@(ip:port)/database NAME

方案驗證與優化

介紹完 Juicefs 使用方法后，開始進行測試工作。測試環境中選用了一臺 48 核、187G 內存的服務器。在 HBase 集群中，分別有一個 HMaster、一個 RegionServer 和三個 zookeeper。在 Meta data engine 選用主從復制的三節點 MySQL。對象存儲則使用移動云對象存儲 EOS，網絡策略走公網。Juicefs 配置 chunk 大小為 64M，物理存儲塊大小為 4M，無 cache，MEM 使用 300M。我們搭建了兩套 HBase 集群，一套是 HBase 直接落盤到移動云對象存儲上，另一套是在 HBase 和移動云對象存儲之間引入 Juicefs。順序寫和隨機讀是 HBase 集群兩個關鍵性能指標，使用 PE 測試工具測試這兩個性能指標。測試讀寫性能如下表所示。

集群環境

集群環境 HBase-juicefs-EOS (row/s)集群環境 HBase-EOS (row/s)

順序寫	79465	33343
隨機讀	6698	6476

根據測試結果，采用 Juicefs 方案，集群順序寫性能提升非常明顯，隨機讀性能卻沒有提升。究其原因，寫請求寫入 Client 內存緩沖區即可返回，因此通常來說 JuiceFS 的 Write 時延非常低（幾十微秒級別）。JuiceFS 在處理讀請求時，一般會按照 4M Block 對齊的方式去對象存儲讀取，實現一定的預讀功能，同時，讀取到的數據會寫入本地 Cache 目錄，以備后用。在順序讀時，這些提前獲取的數據都會被后續的請求訪問到，Cache 命中率非常高，因此也能充分發揮出對象存儲的讀取性能。但是在隨機讀取時，JuiceFS 的預先緩存效率不高，反而會因為讀放大和本地 Cache 的頻繁寫入與驅逐使得系統資源的實際利用率降低。

為了提升隨機讀性能，兩個方向可以考慮。一個是盡可能提升緩存的整體容量，以期達到能幾乎完全緩存所需數據的效果，在海量數據的使用場景下，這個優化方向不太可行。另一個方向是深耕 JuiceFS 內核，優化讀數據邏輯。

目前我們所做的優化包括：1）關閉預讀機制和緩存功能，簡化讀數據邏輯；2）盡可能避免緩存整個塊數據，更多地使用 Range HTTP 請求數據；3）設置較小的 block 大小；4）盡可能提高對象存儲的讀取性能。經研發環境測試，經優化后隨機讀性能提升大約 70%。

結合前期測試工作，云 HBase 在使用對象存儲作為底層數據存儲系統后，在獲得與數據存儲在 HDFS 差不多讀寫性能基礎上，用戶花費卻只有數據存儲在 HDFS 的一半以下，由此可以看出云 HBase 支持對象存儲是魚與熊掌兼得的一次研發實踐。

如有幫助的話歡迎關注我們項目 Juicedata/JuiceFS 喲！ (0?0?)

總結

以上是生活随笔為你收集整理的移动云使用 JuiceFS 支持 Apache HBase 增效降本的探索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。