Apache Hudi 的Payload是一種可擴充套件的資料處理機制，通過不同的Payload我們可以實現複雜場景的定製化資料寫入方式，大大增加了資料處理的靈活性。Hudi Payload在寫入和讀取Hudi表時對資料進行去重、過濾、合併等操作的工具類，通過使用引數 "hoodie.datasource.write.payload.class"指定我們需要使用的Payload class。
1.摘要
Apache Hudi 的Payload是一種可擴充套件的資料處理機制，通過不同的Payload我們可以實現複雜場景的定製化資料寫入方式，大大增加了資料處理的靈活性。Hudi Payload在寫入和讀取Hudi表時對資料進行去重、過濾、合併等操作的工具類，通過使用引數 "hoodie.datasource.write.payload.class"指定我們需要使用的Payload class。本文我們會深入探討Hudi Payload的機制和不同Payload的區別及使用場景。
2. 為何需要Payload
在資料寫入的時候，現有整行插入、整行覆蓋的方式無法滿足所有場景要求，寫入的資料也會有一些定製化處理需求，因此需要有更加靈活的寫入方式以及對寫入資料進行一定的處理，Hudi提供的playload方式可以很好的解決該問題，例如可以解決寫入時資料去重問題，針對部分欄位進行更新等等。
3. Payload的作用機制
寫入Hudi表時需要指定一個引數hoodie.datasource.write.precombine.field，這個欄位也稱為Precombine Key，Hudi Payload就是根據這個指定的欄位來處理資料，它將每條資料都構建成一個Payload，因此資料間的比較就變成了Payload之間的比較。只需要根據業務需求實現Payload的比較方法，即可實現對資料的處理。
Hudi所有Payload都實現HoodieRecordPayload介面，下面列出了所有實現該介面的預置Payload類。
下圖列舉了HoodieRecordPayload介面需要實現的方法，這裡有兩個重要的方法preCombine和combineAndGetUpdateValue，下面我們對這兩個方法進行分析。
3.1 preCombine分析
從下圖可以看出，該方法比較當前資料和oldValue，然後返回一條記錄。
從preCombine方法的註釋描述也可以知道首先它在多條相同主鍵的資料同時寫入Hudi時，用來進行資料去重。
呼叫位置
其實該方法還有另一個呼叫的地方，即在MOR表讀取時會對Log file中的相同主鍵的資料進行處理。
如果同一條資料多次修改並寫入了MOR表的Log檔案，在讀取時也會進行preCombine。
3.2 combineAndGetUpdateValue分析
該方法將currentValue（即現有parquet檔案中的資料）與新資料進行對比，判斷是否需要持久化新資料。
由於COW表和MOR表的讀寫原理差異，因此combineAndGetUpdateValue的呼叫在COW和MOR中也有所不同：
- 在COW寫入時會將新寫入的資料與Hudi表中存的currentValue進行比較，返回需要持久化的資料
- 在MOR讀取時會將經過preCombine處理的Log中的資料與Parquet檔案中的資料進行比較，返回需要持久化的資料
4.常用Payload處理邏輯的對比
瞭解了Payload的核心原理，下面我們對比分析下集中常用的Payload實現的方式。
4.1 OverwriteWithLatestAvroPayload
OverwriteWithLatestAvroPayload 的相關方法實現如下
可以看出使用OverwriteWithLatestAvroPayload 會根據orderingVal進行選擇（這裡的orderingVal即precombine key的值），而combineAndGetUpdateValue永遠返回新資料。
4.2 OverwriteNonDefaultsWithLatestAvroPayload
OverwriteNonDefaultsWithLatestAvroPayload繼承OverwriteWithLatestAvroPayload，preCombine方法相同，重寫了combineAndGetUpdateValue方法，新資料會按欄位跟schema中的default value進行比較，如果default value非null且與新資料中的值不同時，則在新資料中更新該欄位。由於通常schema定義的default value都是null，在此場景下可以實現更新非null欄位的功能，即如果一條資料有五個欄位，使用此Payload更新三個欄位時不會影響另外兩個欄位原來的值。
4.3 DefaultHoodieRecordPayload
DefaultHoodieRecordPayload同樣繼承OverwriteWithLatestAvroPayload重寫了combineAndGetUpdateValue方法，通過下面程式碼可以看出該Payload使用precombine key對現有資料和新資料進行比較，判斷是否要更新該條資料。
下面我們以COW表為例展示不同Payload讀寫結果測試
5. 測試
我們使用如下幾條源資料，以key為主鍵，col3為preCombine key寫Hudi表。
首先我們一次寫入col0是'aa'、'bb'的兩條資料，由於他們的主鍵相同，所以在precombine時會根據col3比較去重，最終寫入Hudi表的只有一條資料。（注意如果寫入方式是insert或bulk_insert則不會去重）
查詢結果
下面我們使用col0是'cc'的資料進行更新，這是由於三種Payload的處理邏輯不同，最終寫入的資料結果也不同。
OverwriteWithLatestAvroPayload
完全用新資料覆蓋了舊資料。
OverwriteNonDefaultsWithLatestAvroPayload
由於更新資料中col1 col2為null，因此該欄位未被更新。
DefaultHoodieRecordPayload
由於cc的col3小於bb的，因此該資料未被更新。
6. 總結
通過上面分析我們清楚了Hudi常用的幾種Payload機制，總結對比如下
| Payload | 更新邏輯與適用場景 |
|---|---|
| OverwriteWithLatestAvroPayload | 永遠用新資料更新老資料全部欄位，適合每次更新資料都是完整的 |
| OverwriteNonDefaultsWithLatestAvroPayload | 將新資料中的非空欄位更新到老資料中，適合每次更新資料只有部分欄位 |
| DefaultHoodieRecordPayload | 根據precombine key比較是否要更新資料，適合實時入湖且入湖順序亂序 |
雖然Hudi提供了多個預置Payload，但是仍不能滿足一些特殊場景的資料處理工作：例如使用者在使用Kafka-Hudi實時入湖，但是使用者的一條資料的修改不在一條Kafka訊息中，而是多條相同主鍵的資料訊息到，第一條裡面有col0，col1的資料，第二條有col2，col3的資料，第三條有col4的資料，這時使用Hudi自帶的Payload就無法完成將這三條資料合併之後寫入Hudi表的工作，要實現這個邏輯就要通過自定義Payload，重寫Payload中的preCombine和combineAndGetUpdateValue方法來實現相應的業務邏輯，並在寫入時通過hoodie.datasource.write.payload.class指定我們自定義的Payload實現。