HBase 優(yōu)化 | 移動云使用 JuiceFS 支持 Apache HBase 增效降本的探索

?? 作者簡介：

陳海峰，移動云數(shù)據(jù)庫 Apache HBase 開發(fā)人員，對 Apache HBase、RBF、Apache Spark 有濃厚興趣。

本文主要介紹了移動云使用?JuiceFS 接入對象存儲優(yōu)化?Apache?HBase?的方案選型思考、驗證，供大家參考。

背景

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

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

方案選型

經(jīng)過大量方案調(diào)研和社區(qū)問題跟蹤，目前移動云 HBase 數(shù)據(jù)接入對象存儲有三種方案。

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

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

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

權(quán)衡上述三個方案利弊，最終采用 JuiceFS 作為移動云 HBase 支持對象存儲的解決方案。下面著重討論 JuiceFS 在移動云 HBase 支持對象存儲中的實踐以及性能調(diào)優(yōu)。

方案介紹

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

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

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

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

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

• ??--storage：設(shè)置存儲類型，比如移動云 EOS；

• ??--bucket：設(shè)置對象存儲的 Endpoint 地址；

• ??--access-key：設(shè)置對象存儲 API 訪問密鑰 Access Key ID；

• ??--secret-key：設(shè)置對象存儲 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?NAM

方案驗證與優(yōu)化

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

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

為了提升隨機讀性能，兩個方向可以考慮。一個是盡可能提升緩存的整體容量，以期達到能幾乎完全緩存所需數(shù)據(jù)的效果，在海量數(shù)據(jù)的使用場景下，這個優(yōu)化方向不太可行。

另一個方向是深耕 JuiceFS 內(nèi)核，優(yōu)化讀數(shù)據(jù)邏輯。目前我們所做的優(yōu)化包括：1）關(guān)閉預讀機制和緩存功能，簡化讀數(shù)據(jù)邏輯；2）盡可能避免緩存整個塊數(shù)據(jù)，更多地使用 Range HTTP 請求數(shù)據(jù)；3）設(shè)置較小的 block 大小；4）盡可能提高對象存儲的讀取性能。經(jīng)研發(fā)環(huán)境測試，經(jīng)優(yōu)化后隨機讀性能提升大約 70%。

結(jié)合前期測試工作，移動云 HBase 在使用 JuiceFS 結(jié)合對象存儲的方案后，在獲得與數(shù)據(jù)存儲在 HDFS 差不多讀寫性能基礎(chǔ)上，用戶花費卻只有數(shù)據(jù)存儲在 HDFS 的一半以下，由此可以看出移動云 HBase 支持對象存儲是魚與熊掌兼得的一次研發(fā)實踐。

開源社區(qū)貢獻指南

JuiceFS 已于 2021 年 1 月開源，開源軟件的發(fā)展離不開每一個人的支持，一篇文章、一頁文檔、一個想法、一個建議、報告或修復一個 Bug，這些貢獻不論大小都是推動開源項目不斷發(fā)展的動力，歡迎來 JuiceFS 的社區(qū)參與以上貢獻。（https://github.com/juicedata/juicefs）

???掃碼加群???

???關(guān)注「Juicedata」，看更多技術(shù)干貨???