在 Hudi 中可以根据业务场景为 Hudi 表配置负载类Payload，它用于在更新期间合并同一记录的两个版本。本文将深入了解有效负载类的用途以及可以使用的所有不同方式。
配置：hoodie.datasource.write.payload.class

注意：对于新的记录合并API ，这些可能会发生变化。 因此此有效负载类详细信息适用于 Hudi 0.13.0 之前的所有版本。 未来的版本可能会弃用这一点。

Payload类

Hudi 有一个有效负载类接口，它将确定如何将同一记录的两个版本合并在一起。
核心方法如下：

/**
* This methods lets you write custom merging/combining logic to produce new values as a function of current value on storage and whats contained
* in this object. Implementations can leverage properties if required.
* <p>
* eg:
* 1) You are updating counters, you may want to add counts to currentValue and write back updated counts
* 2) You may be reading DB redo logs, and merge them with current image for a database row on storage
* </p>
*
* @param currentValue Current value in storage, to merge/combine this payload with
* @param schema Schema used for record
* @param properties Payload related properties. For example pass the ordering field(s) name to extract from value in storage.
* @return new combined/merged value to be written back to storage. EMPTY to skip writing this record.
*/
Option<IndexedRecord> combineAndGetUpdateValue(IndexedRecord currentValue, Schema schema, Properties properties) throws IOException;

Hudi 在内部将一条记录表示为 HoodieRecord，它由一对 HoodieKey 和 HoodieRecordPayload 组成。 正如我们在之前的博客中看到的，HoodieKey 代表一条记录的主键（通常是分区路径和记录键）。 HoodieRecordPayload是用户实际传入的数据。

让我们来看一个典型的例子。 在 commit1 中摄取了 2 条记录，即 {HK1, payload1_1} 和 {HK2, payload2_1}。 在 commit2 中，假设摄取 {HK1, payload1_2} 和 {HK3, payload3_1}。

由于更新了 HK1，Hudi 将合并两个有效载荷（payload1_1 和 payload1_2 以产生 HK1 的最终输出。这就是上面显示的 combineAndGetUpdateValue() 发挥作用的地方。

本质上，HK1.payload1_2.combineAndGetUpdateValue(HK1.payload1_1) 在 commit2 结束时推导出 HK1 的最终值。

在这种情况下，让我们深入研究 Hudi 提供的一些有效负载实现。 默认负载类称为 OverwriteWithLatestAvroPayload。

OverwriteWithLatestAvroPayload

正如名称所暗示的那样，当使用此有效负载类时，我们只需使用新的传入值覆盖任何现有值。 因此，在上述示例中，一旦 commit2 完成，payload1_2 将成为 HK1 的最终值。 这是 Hudi 提供的最简单的有效负载，并且对社区中的大多数用户来说效果很好。

DefaultHoodieRecordPayload

我们还有一个名为 DefaultHoodieRecordPayload 的负载类。 与 Hudi 一开始就提供的 OverwriteWithLatestAvroPayload 相比，这个 DefaultHoodieRecordPayload 是在 1.5 年前引入的。 让我们深入了解一下这个负载类的特殊之处。

一般来说，Hudi表可以配置preCombine字段。 简而言之 preCombine 字段用于解决同一批次中同一记录的两个版本之间的优胜者。 例如，如果在写入 Hudi 时在同一批次中摄取 {HK1, payload1_1} 和 {HK1, payload1_2}，Hudi 将在内部路由之前对传入记录进行去重。 因此在这种情况下，preCombine 字段值将决定多个版本中的获胜者。

例如可以在表schema中选择“updated_at”字段作为 preCombine 字段。 因此，如果传入批次中有超过 1 条具有相同 HoodieKey 的记录，则具有较高 preCombine 值的记录将优先。

尽管 OverwriteWithLatestAvroPayload 和 DefaultHoodieRecordPayload 可能看起来很相似，但有一个关键区别。 这是 combineAndGetUpdateValue() 的实现方式。 DefaultHoodieRecordPayload 在将传入记录与存储中的记录合并时也遵循 preCombine 值，而 OverwriteWithLatestAvroPayload 将盲目地选择传入而不是存储中的任何内容。

让我们添加带有插入记录（HK3，以及 HK1 的更新值）的 commit2。

OverwriteWithLatestAvroPayload 和 DefaultHoodieRecordPayload 都用 payload1_2 更新了 HK1。 OverwriteWithLatestAvroPayload 始终选择较新的传入，因此选择了 payload1_2。 DefaultHoodieRecordPayload 根据 preCombine 字段值推导。 由于 payload1_2 的预组合字段值（20）高于 payload1_1 的预组合字段值（10），DefaultHoodieRecordPayload 也选择 payload1_2 作为 HK1 的最终快照。

现在让我们使用 commit3，它使用较低的 preCombine 值更新 HK1 以模拟迟到的数据。

OverwriteWithLatestAvroPayload 选择新的传入有效负载而不考虑 preCombine 值，因此它选择 payload1_3 作为 HK1 的最终值。 但 DefaultHoodieRecordPayload 根据 preCombine 值选择最终获胜者，因此它选择 payload1_2 作为 HK1 的最终快照值。

社区有其他有效负载类供使用，如 OverwriteNonDefaultsWithLatestAvroPayload、AWSDmsAvroPayload、MySqlDebeziumAvroPayload、PostgresDebeziumAvroPayload 等。

还可以自定义合并两个版本的记录的负载类，为 lakehouse 用户提供了极大的灵活性。 如果不是 SparkSQL 写入（MERGE INTO），没有多少系统能给你这种灵活性，但 Hudi 用户从一开始就享受它

结论

因为不同用例的场景不同，Hudi 支持Payload方式提供灵活性，有效负载类就是这样一种设计，可以根据自己的需求定义自己的 Payload 类，而不是局限于 Hudi 提供的 Payload。 希望这篇博客有助于理解有效负载类的用途、常用的有效负载实现。