OpDB 存儲檔案跟蹤
CDP 營運資料庫 (COD)是由 Apache HBase 和 Apache Phoenix 提供支援的實時自動擴充營運資料庫。它是在 Cloudera 資料平台 (CDP) 公共雲上運作的主要資料服務之一。您可以從CDP 控制台通路 COD 。
基于雲的對象存儲的成本節約在業界廣為人知。通過将對象存儲用于持久層可以滿足延遲和性能要求的應用程式可以顯着降低雲中的操作成本。雖然可以模拟分層檔案系統 從對象存儲的角度來看，與 HDFS 相比的語義非常不同。克服這些警告必須由軟體架構的通路層（在本例中為 HBase）解決。從處理不同的提供者接口到特定供應商技術限制，Cloudera 和 Apache HBase 社群為內建 HBase 和對象存儲做出了巨大努力，但 Amazon S3 對象存儲的一個特殊特性一直是 HBase 的一個大問題：缺乏原子重命名。HBase 中的存儲檔案跟蹤項目解決了 HBase 在 S3 上缺失的原子重命名問題。這改善了 HBase 延遲并減少了 S3 上的 I/O 放大。
HBase on S3 回顧
HBase 内部操作最初是在臨時目錄中建立檔案，然後在送出操作中将檔案重命名為最終目錄。 這是一種将正在寫入 或過時的檔案 與準備讀取的檔案 分開的簡單友善的方法。在這種情況下，非原子重命名不僅會導緻用戶端讀取不一緻，甚至還會導緻資料丢失。這在 HDFS 上不是問題，因為 HDFS 提供了原子重命名。
第一次嘗試克服這個問題是在 2019 年推出的 HBOSS 項目。這種方法為檔案系統路徑建構了一個分布式鎖定層，以防止并發操作通路正在修改的檔案，例如目錄重命名。我們在之前的博文中介紹了 HBOSS 。
不幸的是，當針對跨越數千個區域和數十 TB 的更大工作負載和資料集運作 HBOSS 解決方案時，HBOSS 引發的鎖争用會嚴重影響叢集性能。為了解決這個問題，在HBASE-26067中提出了對 HBase 内部檔案寫入的更廣泛的重新設計，引入了一個單獨的層來處理關于應該首先在何處建立檔案以及如何在檔案寫入送出時進行的決定。這被标記為 StoreFile Tracking 功能。它允許可插入的實作，目前它提供了以下内置選項：
- DEFAULT ：顧名思義，這是預設選項，如果未明确設定則使用。它按照原始設計工作，使用臨時目錄并在送出時重命名檔案。
- FILE：本文的重點，因為這是在使用 Cloudera 操作資料庫 (COD) 部署 HBase 和 S3 時使用的檔案。我們将在本文的其餘部分更詳細地介紹它。
- MIGRATION：在 DEFAULT 和 FILE 實作之間轉換包含資料的現有表時使用的輔助實作。
HBase 中的使用者資料
在進入FILE StoreFile Tracking 實作的内部細節之前，讓我們回顧一下 HBase 的内部檔案結構及其涉及使用者資料檔案寫入的操作。HBase 中的使用者資料被寫入兩種不同類型的檔案：WAL 和存儲檔案（存儲檔案也稱為 HFiles）。WAL 檔案是短暫的臨時檔案，用于容錯，反映區域伺服器的記憶體緩存， memstore 。為了實作用戶端寫入的低延遲要求，WAL 檔案可以保持打開更長時間，并使用 fsync 樣式調用持久儲存資料。存儲檔案（Hfiles ）， 另一方面，是最終儲存使用者資料以服務于任何未來用戶端讀取的地方，并且考慮到 HBase 用于存儲資訊的分布式分片政策，Hfiles 通常分布在以下目錄結構中：
/rootdir/data/namespace/table/region/cf 這些目錄中的每一個都映射到區域伺服器的記憶體結構中，稱為 HStore ，這是 HBase 中最細粒度的資料分片。大多數情況下，隻要區域伺服器 memstore 使用率達到給定門檻值，就會建立存儲檔案，進而觸發 memstore 重新整理。新的存儲檔案也通過壓縮 和批量加載建立。此外，區域拆分/合并操作和快照恢複/克隆操作建立存儲檔案的連結 或引用 ，在存儲檔案跟蹤的上下文中，這 需要與存儲檔案相同的處理。
HBase on 雲存儲架構概述
由于雲對象存儲實作目前不提供任何類似于 fsync 的操作，HBase 仍然需要将 WAL 檔案放在 HDFS 叢集上。但是，由于這些是臨時的、短期檔案，是以在這種情況下所需的 HDFS 容量比将整個 HBase 資料存儲在 HDFS 叢集中的部署所需的容量小得多。
存儲檔案僅由區域伺服器讀取和修改。這意味着更高的寫入延遲不會直接影響用戶端寫入操作 (Puts) 的性能。存儲檔案也是整個 HBase 資料集持久化的地方，這與主要雲對象存儲供應商提供的降低存儲成本非常吻合。
總之，基于對象存儲的 HBase 部署基本上是用于其 WAL 檔案的短 HDFS 和用于存儲檔案的對象存儲的混合體。下圖描述了 HBase over Amazon S3 部署：
這将 StoreFile Tracking 重新設計的範圍限制在直接處理存儲檔案的元件。
HStore編寫高層設計
上面提到的 HStore 元件聚合了幾個與存儲維護相關的附加結構，包括 StoreEngine，它隔離存儲檔案處理特定邏輯。這意味着所有涉及 存儲檔案的操作最終都将在某個時候依賴于 StoreEngine。在HBASE-26067重新設計之前，所有與建立存儲檔案相關的邏輯以及如何區分最終檔案與正在編寫的檔案和過時檔案的邏輯都在存儲層中進行了編碼。下圖是在 StoreFile Tracking 功能之前參與存儲檔案操作的主要參與者的進階視圖：
從 HStore 的上下文來看，在HBASE-26067之前，memstore 重新整理的順序視圖如下所示：
StoreFile Tracking 将自己的層添加到該架構中，封裝檔案建立和跟蹤邏輯，這些邏輯以前是在存儲層本身中編碼的。為了幫助形象化，HBASE-26067之後的等效圖可以表示為：
帶有 StoreFile 跟蹤的 Memstore 重新整理序列：
基于檔案的存儲檔案跟蹤
基于檔案的跟蹤器直接在最終 存儲目錄中建立新檔案。它在存儲目錄中儲存的一對元檔案上保留送出的有效檔案清單，完全消除了使用臨時檔案和重命名操作的需要。從 CDP 7.2.14 版本開始，它預設為基于 S3 的 Cloudera Operational Database 叢集啟用，但從純 HBase 的角度來看，FILE 跟蹤器可以在全局或表級别配置：
- 要在全局級别啟用檔案跟蹤器，請在 hbase-site.xml 上設定以下屬性：
<property><name>hbase.store.file-tracker.impl</name><value>FILE</value></property> - 要在表或列族級别啟用 FILE 跟蹤器，隻需在建立或更改時定義以下屬性。此屬性可以在表或列族配置中定義：
{CONFIGURATION => {'hbase.store.file-tracker.impl' => 'FILE'}} 檔案跟蹤器實作細節
雖然存儲檔案建立和跟蹤邏輯是在上圖 StoreFile Tracking 層中的 FileBaseStoreFileTracker 類中定義的，但我們提到它必須将有效存儲檔案清單儲存在某種内部元檔案中。這些檔案的操作在 StoreFileListFile 類中被隔離。StoreFileListFile 最多保留兩個字首為 f1/f2 的檔案，後跟上次打開存儲時的時間戳值。這些檔案放在 .filelist 目錄中，而該目錄又是實際列族檔案夾的子目錄。以下是名為“tbl-sft”的啟用 FILE 跟蹤器的表的元檔案示例：
/data/default/tbl-sft/093fa06bf84b3b631007f951a14b8457/f/.filelist/f2.1655139542249 StoreFileListFile 根據以下模闆将檔案建立時間的時間戳與 protobuf 格式的存儲檔案清單一起編碼：
message StoreFileEntry {
required string name = 1;
required uint64 size = 2;
}
message StoreFileList {
required uint64 timestamp = 1;
repeated StoreFileEntry store_file = 2;
} 然後計算 protobuf 編碼内容的 CRC32 校驗和，并将内容和校驗和儲存到元檔案中。以下是 UTF 格式的元檔案負載示例：
^@^@^@U^H¥<91><87>ð<95>0^R%
fad4ce7529b9491a8605d2e0579a3763^Pû%^R%
4f105d23ff5e440fa1a5ba7d4d8dbeec^Pû%û8â^R 在此示例中，元檔案列出了兩個存儲檔案。請注意，仍然可以識别存儲檔案名，如紅色所示。
StoreFileListFile初始化
每當區域在區域伺服器上打開時，需要初始化其相關的 HStore 結構。當使用 FILE 跟蹤器時，StoreFileListFile 會經曆一些啟動步驟來加載/建立其元檔案并将有效檔案的視圖提供給 HStore。這個過程枚舉為：
- 列出目前在 .filelist 目錄下的所有元檔案
- 按時間戳字尾對找到的檔案進行分組，按降序排序
- 選擇具有最新時間戳的對并解析檔案的内容
- 從 .filelist 目錄中清除所有目前檔案
- 将目前時間戳定義為元檔案名稱的新字尾
- 檢查所選對中的哪個檔案在其有效負載中具有最新時間戳，并将此清單傳回給 FileBasedStoreFileTracking
以下是突出顯示這些步驟的序列圖：
StoreFileListFile更新
任何涉及建立新存儲檔案的操作都會導緻 HStore 觸發 StoreFileListFile 的更新，這反過來會輪換元檔案字首（從 f1 到 f2，或從 f2 到 f1），但保持相同的時間戳字尾。新檔案現在包含有效存儲檔案的最新清單。枚舉 StoreFileListFile 更新的操作順序：
- 查找下一個要使用的字首值（f1 或 f2）
- 使用選擇的字首和相同的時間戳字尾建立檔案
- 生成存儲檔案清單的protobuf内容和目前時間戳
- 計算内容的校驗和
- 将内容和校驗和儲存到新檔案
- 删除過時的檔案
StoreFile 跟蹤操作實用程式
快照克隆
除了可以在建立或更改時在表或列族配置中設定的hbase.store.file-tracker.impl屬性之外，還為clone_snapshot HBase shell 指令提供了一個附加選項。這在為未配置 FILE 跟蹤器的表克隆快照時至關重要，例如，将快照從沒有 FILE 跟蹤器的非基于 S3 的叢集導出到需要 FILE 跟蹤器才能正常工作的 S3 支援的叢集時。以下是克隆快照并為表正确設定 FILE 跟蹤器的示例指令：
clone_snapshot 'snapshotName' , 'namespace:tableName' , { CLONE_SFT => 'FILE' } 在此示例中，FILE 跟蹤器将在快照檔案加載期間使用相關跟蹤器元檔案初始化 StoreFileListFile。
存儲檔案跟蹤轉換器指令
可以使用兩個新的 HBase shell 指令來更改表或列族的存儲檔案跟蹤實作，并且可以用作轉換最初未配置 FILE 跟蹤器的導入表的替代方法：
- change_sft ：允許更改單個表或列族的存儲檔案跟蹤實作：
hbase> change_sft 't1','FILE'
hbase> change_sft 't2','cf1','FILE' - change_sft_all ：為給定正規表達式的所有表更改存儲檔案跟蹤實作：
hbase> change_sft_all 't.*','FILE'
hbase> change_sft_all 'ns:.*','FILE'
hbase> change_sft_all 'ns:t.*','FILE' HBCK2支援
還有一個新的 HBCK2 指令用于制作 FILE 跟蹤器元檔案，以防元檔案損壞或丢失。這是rebuildStoreFileListFiles指令，可以一次為整個 HBase 目錄樹、單個表或表中的特定區域重建元檔案。在其簡單的形式中，該指令僅建構并列印受影響檔案的報告：
HBCK2 rebuildStoreFileListFiles 上面的示例為整個目錄樹建構了一個報告。如果傳遞了 -f/–fix 選項，該指令會有效地建構元檔案，假設存儲目錄中的所有檔案都有效。
HBCK2 rebuildStoreFileListFiles -f my-sft-tbl 結論
StoreFile Tracking 及其内置的 FILE 實作避免了用于管理存儲檔案的内部檔案重命名，進而支援通過 S3 部署 HBase。它與公有雲中的 Cloudera Operational Database 完全內建，預設情況下在使用 S3 作為持久性存儲技術建立的每個新叢集上啟用。FILE 跟蹤器在不依賴臨時檔案或目錄的情況下成功地處理了存儲檔案，消除了 HBOSS 提出的附加鎖定層。FILE 跟蹤器和處理快照、配置和可支援性的其他工具成功地将資料集遷移到 S3，進而使 HBase 應用程式能夠利用 S3 提供的優勢。
我們非常高興為我們的使用者釋放了 HBase on S3 的潛力。今天在 CDP 的操作資料庫模闆中試用在 S3 上運作的 HBase！要了解有關 Apache HBase 分布式資料存儲的更多資訊，請通路我們這裡。
原文作者：Wellington Chevreuil
原文連結：https://blog.cloudera.com/unlocking-hbase-on-s3-with-the-new-store-file-tracking-feature/