在 Hudi 中可以根据业务场景为 Hudi 表配置负载类Payload，它用于在更新期间合并同一记录的两个版本。本文将深入了解有效负载类的用途以及可以使用的所有不同方式。配置：hoodie.datasource.write.payload.class[1]
注意：对于新的记录合并API[2] ，这些可能会发生变化。因此此有效负载类详细信息适用于 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. * * 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 * * * @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 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
正如名称[3]所暗示的那样，当使用此有效负载类时，我们只需使用新的传入值覆盖任何现有值。因此，在上述示例中，一旦 commit2 完成，payload1_2 将成为 HK1 的最终值。这是 Hudi 提供的最简单的有效负载，并且对社区中的大多数用户来说效果很好。
DefaultHoodieRecordPayload
我们还有一个名为 DefaultHoodieRecordPayload[4] 的负载类。与 Hudi 一开始就提供的 OverwriteWithLatestAvroPayload 相比，这个 DefaultHoodieRecordPayload 是在 1.5 年前引入的。让我们深入了解一下这个负载类的特殊之处。
一般来说，Hudi表可以配置preCombine[5]字段。简而言之 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[6]、AWSDmsAvroPayload[7]、MySqlDebeziumAvroPayload[8]、PostgresDebeziumAvroPayload[9] 等。
还可以自定义合并两个版本的记录的负载类，为 lakehouse 用户提供了极大的灵活性。如果不是 SparkSQL 写入（MERGE INTO），没有多少系统能给你这种灵活性，但 Hudi 用户从一开始就享受它
结论
因为不同用例的场景不同，Hudi 支持Payload方式提供灵活性，有效负载类就是这样一种设计，可以根据自己的需求定义自己的 Payload 类，而不是局限于 Hudi 提供的 Payload。希望这篇博客有助于理解有效负载类的用途、常用的有效负载实现。
