Hudi系列:Hudi核心概念(版本1.0)

?Hudi架構(gòu)

?一. 時間軸(TimeLine)s

?1.1 時間軸(TimeLine)概念

?1.2 Hudi的時間線由組成

?1.3 時間線上的Instant action操作類型

?1.4 時間線上State狀態(tài)類型

?1.5 時間線官網(wǎng)實例

?二. 文件布局

?三. 索引

3.1 簡介

3.2 對比其它(Hive)沒有索引的區(qū)別

3.2 多態(tài)索引

布隆過濾器

記錄索引

表達(dá)索引

二級索引

3.3寫入端的索引類型

3.4 全局索引與非全局索引

四. 表類型

4.1 COW：(Copy on Write)寫時復(fù)制表

4.1.1概念

4.1.2 COW工作原理

4.1.3 COW表對表的管理方式改進(jìn)點

4.2 MOR：(Merge on Read)讀時復(fù)制表

4.2.1 概念

4.2.2 MOR表工作原理

4.3 總結(jié)了兩種表類型之間的權(quán)衡

五. 查詢類型

?

?

四、簡介

Hudi 表類型定義了數(shù)據(jù)的存儲方式以及如何在表上執(zhí)行寫入操作（即如何寫入數(shù)據(jù)）。反過來，查詢類型定義了如何將底層數(shù)據(jù)暴露給查詢（即如何讀取數(shù)據(jù)）。

Hudi 引入了以下目前已在業(yè)界廣泛使用的表類型，根據(jù)實際情況權(quán)衡取舍。
Copy On Write ：Merge On Read：讀取時合并 (MoR) 表類型通過使用定期壓縮將輕量級日志文件與基礎(chǔ)文件合并，從而平衡寫入和讀取性能。
數(shù)據(jù)更新和刪除操作會寫入日志文件（以基于行的格式，例如 Avro 或列式/基礎(chǔ)文件格式），然后在查詢執(zhí)行期間將日志文件中的這些更改與基礎(chǔ)文件動態(tài)合并。這種方法降低了寫入延遲，
并支持近乎實時的數(shù)據(jù)可用性。但是，查詢性能可能會因日志文件是否壓縮而有所不同。
核心事務(wù)功能（例如原子寫入、索引）以及獨特的新功能（例如增量查詢、自動文件大小調(diào)整和可擴展表元數(shù)據(jù)跟蹤）均在兩者中提供，且與表類型無關(guān)。

4.1Copy On Write Table

4.1概念

寫時復(fù)制 (COW) 表類型針對讀取密集型工作負(fù)載進(jìn)行了優(yōu)化。在此模式下，記錄更新或刪除會觸發(fā)在文件組中創(chuàng)建新的基礎(chǔ)文件，并且不會寫入日志文件。這確保每個查詢僅讀取基礎(chǔ)文件，從而提供
較高的讀取性能，而無需動態(tài)合并日志文件。雖然 COW 表非常適合 OLAP 掃描/查詢，但由于在更新或刪除期間重寫基礎(chǔ)文件的開銷，即使每個文件中只修改了少量記錄，它們的寫入操作也可能較慢。 
下面從概念上說明了當(dāng)數(shù)據(jù)寫入時復(fù)制表并在其上運行兩個查詢時其工作原理。

4.1.2COW工作原理

隨著數(shù)據(jù)的寫入，對現(xiàn)有文件組的更新會為該文件組生成一個新的切片，并標(biāo)記與提交請求的時刻相關(guān)聯(lián)；而插入操作則會分配一個新的文件組，并為該文件組寫入其第一個切片。
這些文件切片及其提交完成的時刻已在上方以同一顏色編碼。針對上圖 SQL 查詢首先檢查已完成寫入的時間線，并過濾每個文件組除最新文件切片之外的所有文件切片。如您所見，較舊的查詢不會看到
當(dāng)前正在進(jìn)行的提交的文件（以粉紅色編碼），但提交后啟動的新查詢會獲取新數(shù)據(jù)。因此，查詢不會受到任何寫入失敗/部分寫入的影響，并且只會讀取已提交的數(shù)據(jù)。

4.1.3 COW表對表的管理方式改進(jìn)點

1.在原有文件上進(jìn)行自動更新數(shù)據(jù)，而不是重新刷新整個表/分區(qū)

2.能夠只讀取修改部分的數(shù)據(jù)，而不是浪費查詢無效數(shù)據(jù)

3.嚴(yán)格控制文件大小來保證查詢性能（小文件會顯著降低查詢性能）

4.2 Merge On Read Table

4.2.1概念

讀取時合并 (MOR) 表類型通過使用定期壓縮將輕量級日志文件與基文件合并，從而平衡寫入和讀取性能。數(shù)據(jù)更新和刪除操作會寫入日志文件（以基于行的格式，例如 Avro 或列式/基文件格式），
然后在查詢執(zhí)行期間將日志文件中的這些更改動態(tài)地與基文件合并。這種方法可以降低寫入延遲并支持近乎實時的數(shù)據(jù)可用性。但是，查詢性能可能會因日志文件是否被壓縮而有所不同。

4.1.2MOR工作原理

下面說明了 MOR 表的工作原理，并展示了兩種類型的查詢 - 快照查詢和讀取優(yōu)化查詢。

?

這個例子中發(fā)生了很多有趣的事情，方法出方法的微妙之處。

1）如上圖所示，可以做到每一分鐘提交一次寫入操作
2）查詢表的方式有兩種，Read Optimized query和Snapshot query,取決于我們選擇是要查詢性能還是數(shù)據(jù)最新

3）如上圖所示，Read Optimized query查詢不到10:05之后的數(shù)據(jù)（查詢不到增量日志里的數(shù)據(jù)，沒有合并到base文件），而Snapshot query則可以查詢到全量數(shù)據(jù)（基本列數(shù)據(jù)+行式的增量日志數(shù)據(jù)）

4.3總結(jié)兩種表的類型之前的權(quán)衡

?

五. 查詢類型

?Snapshot Queries：查詢會查看截至最新完成操作的最新表快照。這些是每個人都習(xí)慣在表上運行的常規(guī) SQL 查詢。Hudi 存儲引擎會在支持的查詢引擎上盡可能使用索引來加速這些快照查詢。

?

?Time Travel Queries：查詢過去某個時刻的表快照。時間旅行查詢有助于訪問表的多個版本（例如，機器學(xué)習(xí)特征存儲，用于根據(jù)用于訓(xùn)練算法/模型的精確數(shù)據(jù)對其進(jìn)行評分），這些版本位于活動時間線中的某個時刻或過去的保存點。

?

?Read Optimized Queries (Only MoR tables)：讀優(yōu)化查詢通過純列式文件（例如Parquet 基礎(chǔ)文件）提供出色的快照查詢性能。用戶通常使用與事務(wù)邊界一致的壓縮策略，以提供表/分區(qū)的舊一致性視圖。這對于集成來自數(shù)據(jù)倉庫的 Hudi 表非常有用，因為這些數(shù)據(jù)倉庫通常僅將列式基礎(chǔ)文件作為外部表進(jìn)行查詢，或者對于延遲不敏感、更注重效率而非數(shù)據(jù)新鮮度的 ML/AI 訓(xùn)練作業(yè)。

?

? Incremental Queries (Latest State)：增量查詢僅返回自時間軸上某一時刻以來寫入表的新數(shù)據(jù)。提供自表的給定時間點以來插入/更新的記錄的最新值（即，查詢?yōu)槊總€記錄鍵輸出一條記錄）?？捎糜诒容^兩個時間點之間的表狀態(tài)差異。

?

?Incremental Queries(CDC)：這是另一種增量查詢，它提供類似數(shù)據(jù)庫的 Hudi 表變更數(shù)據(jù)捕獲流。CDC 查詢的輸出包含自某個時間點或兩個時間點之間插入、更新或刪除的記錄，以及每條變更記錄的前后圖像，以及導(dǎo)致變更的操作。

審核編輯 黃宇