Hudi架構
一. 時間軸(TimeLine)
1.1 時間軸(TimeLine)概念
Hudi的核心是維護在不同時刻（Instant）在表上執行的所有操作的時間軸，提供表的即時視圖，同時還有效地支持按時間順序檢索數據
1.2 Hudi的時間線由組成
Instant action:
在表上執行的操作類型
Instant time:
即時時間，通常是一個時間戳，它按照action的開始時間單調遞增
State:
時刻的當前狀態
1.3 時間線上的Instant action操作類型
hudi保證在時間線上的操作都是基於即時時間的，兩者的時間保持一致並且是原子性的
commits: 表示將一批數據原子寫入表中
cleans: 清除表中不在需要的舊版本文件的後臺活動。
delta_commit:增量提交是指將一批數據原子性寫入MergeOnRead類型的表中，其中部分或者所有數據可以寫入增量日誌中。
compaction: 協調hudi中差異數據結構的後臺活動，例如：將更新從基於行的日誌文件變成列格式。在內部，壓縮的表現爲時間軸上的特殊提交。
rollback:表示提交操作不成功且已經回滾，會刪除在寫入過程中產生的數據
savepoint:將某些文件標記爲“已保存”，以便清理程序時不會被清楚。在需要數據恢復的情況下，有助於將數據集還原到時間軸上某個點。
1.4 時間線上State狀態類型
任何給定的瞬間都可以處於以下狀態之一
requested:表示一個動作已被安排，但尚未啓動
inflight:表是當前正在執行操作
completed:表是在時間線上完成了操作
1.5 時間線官網實例
上圖中採用時間（小時）作爲分區字段，從 10:00 開始陸續產生各種 commits，10:20 來了一條 9:00 的數據，該數據仍然可以落到 9:00 對應的分區，通過 timeline 直接消費 10:00 之後的增量更新（只消費有新 commits的 group），那麼這條延遲的數據仍然可以被消費到，(沒有說明白它是怎麼處理延遲數據的)
二. 文件佈局
Hudi將一個表映射爲如下文件結構:
Hudi將HDFS上的數據集組織到基本路徑（HoodieWriteConfig.BASEPATHPROP）下的目錄結構中。
數據集分爲多個分區（DataSourceOptions.PARTITIONPATHFIELDOPT_KEY），這些分區與Hive表非常相似，是包含該分區的數據文件的文件夾。
數據集分爲多個分區（DataSourceOptions.PARTITIONPATHFIELDOPT_KEY），這些分區與Hive表非常相似，是包含該分區的數據文件的文件夾。
Hudi將數據表組織成分佈式文件基本路徑(basepath)下的目錄結構。
表被劃分爲多個分區，這些分區是包含該分區的數據文件的文件夾，非常類似於Hive表
在每個分區中，文件被組織成文件組，由文件ID唯一標識
每個文件組包含幾個文件片(FileSlice)
每個文件包含:
5.1) 一個基本文件(.parquet)： 在某個commit/compaction 即時時間(instant time)生成的(MOR可能沒有)
5.2) 多個日誌文件(.log*),這些日誌文件包含自生成基本文件以來對基本文件的插入/更新(COW沒有).Hudi採用了多版本併發控制(Multiversion Concurrency Control,MVCC)
6.1) compaction 操作: 合併日誌和基本文件以產生新的文件片
6.2) clean操作: 清楚不使用的/舊的文件以回收文件系統上的空間Hudi的base file(parquet 文件)在 footer 的 meta 去記錄了 record key組成的BloomFilter，用於在flie based index 的實現中實現高效率的 key contains 檢測。 只有不在 BloomFilter的key才需要掃描整個文件消滅假陽。
Hudi的log(avro 文件)是自己編碼的，通過積攢數據 buffer 以LogBlock爲單位寫出，每個LogBlock包含 magic number、size、content、footer等信息，用於數據讀、校驗和過濾。
三. 索引
3.1 簡介
Hudi 通過索引機制將給定的 hoodie 鍵（記錄鍵 + 分區路徑）一致地映射到文件 id，從而提供高效的 upsert。記錄鍵和文件組/文件 id 之間的這種映射，一旦記錄的第一個版本被寫入文件，就永遠不會改變。簡而言之，映射文件組包含一組記錄的所有版本（類似git）。
3.2 對比Hive沒有索引的區別
對於Copy-On-Write 表，這可以實現快速 upsert/delete 操作，避免需要連接整個數據集以確定要重寫哪些文件。對於Merge-On-Read 表，這種設計允許 Hudi 綁定任何給定基本文件需要合併的記錄數量。具體來說，給定的基本文件只需要針對作爲該基本文件一部分的記錄的更新進行合併。相反，沒有索引組件的設計 Hive ACID需要將所有基本文件與所有傳入的更新/刪除記錄合併
3.3 Hudi索引類型
3.4 全局索引與非全局索引
Bloom 和 simple index 都有全局選項，Base 索引本質上是一個全局索引
hoodie.index.type=GLOBAL_BLOOM
hoodie.index.type=GLOBAL_SIMPLE
全局索引：在全表的所有分區範圍下強制要求鍵保持唯一，即確保對給定的鍵有且只有一個對應的記錄。非全局索引：僅在表的某一個分區內強制要求鍵保持唯一，它依靠寫入器爲同一個記錄的更刪提供一致的分區路。
四. 表類型
4.1 COW：(Copy on Write)寫時複製表
4.1.1 概念
Copy on Write表中的文件切片僅包含基本列文件，並且每次提交都會生成新版本的基本文件。換句話說，每次提交操作都會被壓縮，以便存儲列式數據，因此Write Amplification寫入放大非常高（即只有一個字節的數據被提交修改，我們也需要先copy改值所在的最小單位塊複製到內存整體修改再寫會去），而讀取數據成本則沒有增加，所以這種表適合於做分析工作，讀取密集型的操作。
4.1.2 COW工作原理
當數據被寫入，對現有文件組的更新會爲該文件組生成一個帶有提交即時間標記的新切片，而插入分配一個新文件組並寫入該文件組第一個切片。這些切片和提交即時時間在上圖用同一顏色標識。針對圖上右側sql查詢，首先檢查時間軸上的最新提交併過濾掉之前的舊數據（根據時間查詢最新數據），如上圖所示粉色數據在10:10被提交，第一次查詢是在10:10之前，所以不會出現粉色數據，第二次查詢時間在10:10之後，可以查詢到粉色數據（以被提交的數據）。
4.1.3 COW表對錶的管理方式改進點
在原有文件上進行自動更新數據，而不是重新刷新整個表/分區
能夠只讀取修改部分的數據，而不是浪費查詢無效數據
嚴格控制文件大小來保證查詢性能（小文件會顯著降低查詢性能）
4.2 MOR：(Merge on Read)讀時複製表
4.2.1 概念
Merge on Read表使用列式存儲（parquet）+行式文件（arvo）存儲數據,它仍然支持只查詢文件切片中的基本列(parquet)來對錶進行查詢優化。用戶每次對錶文件的upsert操作都會以增量寫入delta log(avro)，增量日誌會對應每個文件最新的ID來幫助用戶完成快照查詢。因此這種表類型，能夠智能平衡讀取和寫放大（wa）,提供近乎實時的數據。這種表最重要的是合併壓縮，它用來選擇將對應delta log數據合併壓縮到表的基本文件中，來保持查詢時的性能（較大的增量日誌文件會影響合併時間和查詢時間）(通俗說就是你修改新增的值存在一個avro格式文件中，等你要查詢的時候就好去和原有的值進行合併操作返回唯一值，不過MOR表會定期自動合併)
Merge on Read 讀時合併
第一批數據，沒有Parquet文件，寫入到log文件
後期會compaction，執行合併的時候，將Parquet+log合併爲新的
Parquet。(有點類似關係型數據庫的WAL)
4.2.2 MOR表工作原理
如上圖所示，可以做到每一分鐘提交一次寫入操作
查詢表的方式有兩種，Read Optimized query和Snapshot query,取決於我們選擇是要查詢性能還是數據最新
如上圖所示，Read Optimized query查詢不到10:05之後的數據（查詢不到增量日誌裏的數據，沒有合併到base文件），而Snapshot query則可以查詢到全量數據（基本列數據+行式的增量日誌數據）
4.3 總結了兩種表類型之間的權衡
五. 查詢類型
Hudi支持如下三種查詢類型:
5.1 Snapshot Queries
5.2 Incremental Queries
增量查詢，可以查詢給定 commit/delta commit 即時操作以來新寫入的數據。 有效的提供變更流來啓用增量數據管道。
5.3 Read Optimized Query
讀優化查詢，可查看給定的 commit、compact 即時操作的表的最新的快照。 僅將最新文件片的基本/列文件暴露給查詢，並保證與非Hudi表相同的列查詢性能。