Apache Hudi 社區(qū)一直在快速發(fā)展，各公司正在尋找方法來(lái)利用其強(qiáng)大的功能來(lái)有效地?cái)z取和管理大規(guī)模數(shù)據(jù)集。 每周社區(qū)都會(huì)收到一些常見(jiàn)問(wèn)題，最常見(jiàn)的問(wèn)題與 Hudi 如何執(zhí)行更新插入有關(guān)，以確保以低延遲訪問(wèn)最新數(shù)據(jù)。
選擇合適的存儲(chǔ)表類(lèi)型
快速更新插入的主要考慮因素之一是選擇正確的存儲(chǔ)表類(lèi)型。 Hudi 支持兩種不同的存儲(chǔ)表類(lèi)型——Copy-On-Write (COW) 和 Merge-On-Read (MOR)。 由于處理數(shù)據(jù)更新的方法不同，每種表類(lèi)型都會(huì)對(duì) upsert 性能產(chǎn)生不同的影響。
COW表
與 MOR 表相比，COW 表的操作更簡(jiǎn)單，因?yàn)樗懈露紝?xiě)入 Apache Parquet 格式的基礎(chǔ)文件。不需要運(yùn)行像壓縮這樣的單獨(dú)服務(wù)來(lái)管理任何日志文件以提高讀取或存儲(chǔ)效率。COW通過(guò)完全重寫(xiě)文件以生成新版本的基本文件來(lái)處理更新。 因此 COW 表表現(xiàn)出更高的寫(xiě)放大，因?yàn)閯?chuàng)建新的基本文件版本會(huì)進(jìn)行同步合并。 然而 COW 表的一個(gè)關(guān)鍵優(yōu)勢(shì)是它們的零讀取放大，因?yàn)樗袛?shù)據(jù)都在基礎(chǔ)文件中可用，隨時(shí)可以讀取。 查詢(xún)所需的磁盤(pán)讀取很少，因?yàn)樗鼈儾恍枰x取多個(gè)位置或合并數(shù)據(jù)。
MOR表
與 COW 表相比，MOR 表具有更高的操作復(fù)雜性。 MOR 不會(huì)重寫(xiě)整個(gè)文件，而是將更新寫(xiě)入單獨(dú)的日志文件，然后這些日志文件稍后與基本文件合并為一個(gè)新的文件版本，這是通過(guò)壓縮服務(wù)完成的。 需要壓縮來(lái)限制日志文件的增長(zhǎng)，這樣查詢(xún)性能就不會(huì)下降并優(yōu)化存儲(chǔ)。
直接寫(xiě)入日志文件避免了多次重寫(xiě)整個(gè)基本文件，從而降低了寫(xiě)入放大——如果正在處理流數(shù)據(jù)，這種差異就會(huì)變得很明顯，也就是說(shuō) MOR 表進(jìn)行了寫(xiě)入優(yōu)化。 但是由于需要讀取基本文件和日志文件并動(dòng)態(tài)合并數(shù)據(jù)，MOR 表在壓縮之間對(duì)快照查詢(xún)有更高的讀取放大。
COW 和 MOR 表的注意事項(xiàng)
如果更新插入比率很高并且對(duì)攝取延遲很敏感，那么更適合使用 MOR 表。 如流數(shù)據(jù)源——通常會(huì)希望更快地根據(jù)洞察采取行動(dòng)，以便為用戶提供相關(guān)和及時(shí)的信息。 但是如果工作負(fù)載更多地基于插入，并且可以容忍合理的攝取延遲，那么更適合使用 COW 表。
根據(jù)記錄鍵選擇正確的索引類(lèi)型
通過(guò)利用索引，Hudi 在更新插入期間查找記錄時(shí)避免全表掃描，這比較耗費(fèi)時(shí)間和資源。 Hudi 的索引層將記錄鍵映射到相應(yīng)的文件位置，索引層是可插拔的，有多種索引類(lèi)型可供選擇。 需要考慮的是索引延遲取決于多種因素，例如正在攝取多少數(shù)據(jù)、表中有多少數(shù)據(jù)、是否有分區(qū)表或非分區(qū)表、選擇的索引類(lèi)型、工作負(fù)載的更新程度和記錄鍵的時(shí)間特性。 根據(jù)所需的性能和唯一性保證，Hudi 提供了不同的開(kāi)箱即用的索引策略，可以分為全局或非全局索引。
全局與非全局索引
-
非全局索引：Hudi 確保一對(duì)分區(qū)路徑和記錄鍵在整個(gè)表中是唯一的。 索引查找性能與正在攝取的傳入記錄之間的匹配分區(qū)的大小成正比。 ?
-
全局索引：該索引策略在表的所有分區(qū)中強(qiáng)制執(zhí)行鍵的唯一性，即保證對(duì)于給定的記錄鍵，表中恰好存在一條記錄。 全局索引提供了更強(qiáng)的保證，但是更新/刪除成本隨著表的大小而增長(zhǎng)。
由于唯一性保證的差異，全局與非全局之間的主要考慮因素之一與索引查找延遲有關(guān)：
非全局索引僅查找匹配的分區(qū)：例如如果有 100 個(gè)分區(qū)并且傳入的批處理僅包含最后 2 個(gè)分區(qū)的記錄，則只會(huì)查找屬于這 2 個(gè)分區(qū)的文件組。 對(duì)于大規(guī)模的更新插入工作負(fù)載可能需要考慮非全局索引，例如非全局布隆、非全局簡(jiǎn)單索引和桶索引。
全局索引查看所有分區(qū)中的所有文件組：例如如果有 100 個(gè)分區(qū)并且傳入的記錄批次中有最后 2 個(gè)分區(qū)的記錄，則將查找所有 100 個(gè)分區(qū)中的所有文件組（因?yàn)?Hudi 必須保證整個(gè)表中只有一個(gè)版本的記錄鍵）。 這會(huì)增加大規(guī)模更新插入工作負(fù)載的延遲。
Hudi 提供開(kāi)箱即用的索引類(lèi)型
-
布隆索引：這是一種索引策略，可以有效地管理文件組中的更新插入和記錄查找。 該索引利用布隆過(guò)濾器，這是一種概率數(shù)據(jù)結(jié)構(gòu)，有助于確定給定記錄鍵是否存在于特定文件組中。適用于全局和非全局索引。
-
簡(jiǎn)單索引：這是一種索引策略，它提供了一種將記錄鍵映射到其相應(yīng)文件組的直接方法。它針對(duì)從存儲(chǔ)表中提取的鍵執(zhí)行傳入更新/刪除記錄的連接。適用于全局和非全局索引。
-
HBase索引：該索引策略使用HBase存儲(chǔ)索引來(lái)映射記錄鍵及其在文件組中對(duì)應(yīng)的文件位置。 適用于全局索引。
-
桶索引：這是一種索引策略，它使用散列將記錄路由到靜態(tài)分配的文件組。 適用于非全局索引。
-
一致性哈希桶索引：這是一種索引策略，是桶索引的高級(jí)版本。 雖然桶索引需要為每個(gè)分區(qū)預(yù)先分配文件組，但使用一致的哈希索引可以根據(jù)負(fù)載動(dòng)態(tài)地增加或收縮每個(gè)分區(qū)的文件組。 適用于非全局索引。
更新密集型工作負(fù)載要考慮的索引類(lèi)型
-
Bloom 索引：如果記錄鍵按某些標(biāo)準(zhǔn)（例如基于時(shí)間戳）排序并且更新與最近的數(shù)據(jù)集相關(guān)，那么這對(duì)于更新繁重的工作負(fù)載是一個(gè)很好的索引策略。 例如如果記錄鍵是根據(jù)時(shí)間戳排序的，并且我們?cè)谧罱鼛滋旄聰?shù)據(jù)。
- Bloom 索引用例：假設(shè)每 10 分鐘就會(huì)攝取一批新數(shù)據(jù)。 我們假設(shè)新批次包含最近 3 天內(nèi)的數(shù)據(jù)更新。 Hudi 根據(jù)布隆索引，識(shí)別出文件組中的候選更新記錄，并從基礎(chǔ)文件頁(yè)腳中獲取布隆過(guò)濾器，進(jìn)一步裁剪文件組中每個(gè)文件中要查找的記錄。 如果沒(méi)有找到記錄則被視為插入。?
-
簡(jiǎn)單索引：如果偶爾更新整個(gè)表范圍內(nèi)的文件并且記錄鍵是隨機(jī)的，即不基于時(shí)間戳，那么這對(duì)于更新繁重的工作負(fù)載是一個(gè)很好的索引策略。
- 簡(jiǎn)單索引用例：如果有一個(gè)維度表，其中記錄鍵是旅行 ID（隨機(jī) UUID）并且分區(qū)是按城市 ID。 如果我們要更新分布在一系列城市的 10000 條行程，Hudi 首先根據(jù)傳入的城市 ID 識(shí)別相關(guān)分區(qū)。 Hudi 通過(guò)執(zhí)行連接有效地找到包含記錄的文件。
-
桶索引：如果每個(gè)分區(qū)存儲(chǔ)的數(shù)據(jù)總量在所有分區(qū)中都相似，這是一個(gè)很好的索引策略。 每個(gè)分區(qū)的桶（或文件組）數(shù)量必須預(yù)先為給定的表定義。更多細(xì)節(jié)參考如下文檔。
- 桶索引用例：當(dāng)定義桶數(shù)量后，Hudi會(huì)對(duì)記錄鍵應(yīng)用一個(gè)哈希函數(shù)來(lái)將記錄均勻地分布在桶中。 哈希函數(shù)將每個(gè)記錄 ID 分配給一個(gè)桶號(hào)，當(dāng)更新時(shí) Hudi 將哈希函數(shù)應(yīng)用于記錄 ID 并確定相應(yīng)的桶，然后 Hudi 將寫(xiě)入委托給相應(yīng)的桶（文件組）。
分區(qū)路徑粒度
分區(qū)是一種技術(shù)，用于根據(jù)數(shù)據(jù)集中的某些屬性或列將大型數(shù)據(jù)集拆分為較小的、易于管理的部分。 這可以大大提高查詢(xún)性能，因?yàn)樵诓樵?xún)期間只需要掃描數(shù)據(jù)的一個(gè)子集。 然而分區(qū)的有效性在很大程度上取決于分區(qū)的粒度。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-452663.html
一個(gè)常見(jiàn)的誤區(qū)是將分區(qū)設(shè)置得過(guò)于精細(xì)，例如按 <city>/<day>/<hour> 劃分分區(qū)。 根據(jù)工作負(fù)載每小時(shí)粒度的數(shù)據(jù)可能不足，從而導(dǎo)致許多只有幾千字節(jié)的小文件。 如果小文件越多，磁盤(pán)尋道成本就越高，查詢(xún)性能就會(huì)下降。 其次在攝取方面，小文件也會(huì)影響索引查找，因?yàn)樾藜舨幌嚓P(guān)文件需要更長(zhǎng)的時(shí)間。 根據(jù)正在使用的索引策略，這可能會(huì)影響寫(xiě)入性能。因此建議用戶始終從較粗糙的分區(qū)方案開(kāi)始，如
到了這里，關(guān)于提升 Apache Hudi Upsert 性能的三個(gè)建議的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
