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)，以確保以低延遲訪(fǎng)問(wèn)最新數(shù)據(jù)。

快速更新插入的主要考慮因素之一是選擇正確的存儲(chǔ)表類(lèi)型。 Hudi 支持兩種不同的存儲(chǔ)表類(lèi)型——Copy-On-Write (COW) 和 Merge-On-Read (MOR)。 由于處理數(shù)據(jù)更新的方法不同，每種表類(lèi)型都會(huì)對(duì) upsert 性能產(chǎn)生不同的影響。

與 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ù)。

(資料圖片僅供參考)

與 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)有更高的讀取放大。

如果更新插入比率很高并且對(duì)攝取延遲很敏感，那么更適合使用 MOR 表。 如流數(shù)據(jù)源——通常會(huì)希望更快地根據(jù)洞察采取行動(dòng)，以便為用戶(hù)提供相關(guān)和及時(shí)的信息。 但是如果工作負(fù)載更多地基于插入，并且可以容忍合理的攝取延遲，那么更適合使用 COW 表。

通過(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ù)載的延遲。

布隆索引：這是一種索引策略，可以有效地管理文件組中的更新插入和記錄查找。 該索引利用布隆過(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ū)的文件組。 適用于非全局索引。

分區(qū)是一種技術(shù)，用于根據(jù)數(shù)據(jù)集中的某些屬性或列將大型數(shù)據(jù)集拆分為較小的、易于管理的部分。 這可以大大提高查詢(xún)性能，因?yàn)樵诓樵?xún)期間只需要掃描數(shù)據(jù)的一個(gè)子集。 然而分區(qū)的有效性在很大程度上取決于分區(qū)的粒度。

一個(gè)常見(jiàn)的誤區(qū)是將分區(qū)設(shè)置得過(guò)于精細(xì)，例如按 //劃分分區(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ě)入性能。因此建議用戶(hù)始終從較粗糙的分區(qū)方案開(kāi)始，如 /以避免小文件的問(wèn)題，如果仍然覺(jué)得需要粒度分區(qū)，可以根據(jù)查詢(xún)模式重新評(píng)估分區(qū)方案和/或可以潛在地利用Clustering服務(wù)來(lái)平衡攝取和查詢(xún)性能。