核心结论：会跟着变化，但需依赖正确的配置和关联逻辑

在 Hudi 增量关联（实时同步新数据）场景中，当 hudi_pay 变更一条数据（如支付金额更新、支付状态修改）时，hudi_order_pay_join 关联结果表的数据会自动同步更新—— 前提是你正确配置了 Hudi 的增量查询、UPSERT 操作和关联逻辑。

以下从 “为什么会变”“关键配置保障”“实操验证” 三个维度详细说明，帮你理清底层逻辑和落地细节：

一、为什么 hudi_pay 变更会触发关联结果更新？

核心依赖 Hudi 的两个核心特性，再结合 Flink 增量关联逻辑，形成 “变更传导闭环”：

1. Hudi 增量查询捕获变更：hudi_pay 是 CDC 模式的 Hudi 表（operation=UPSERT），变更数据（更新 / 插入）会生成新的 commit 版本。增量关联作业通过 read.streaming.enabled=true 和 read.start-commit 配置，能实时捕获到这条变更记录。
2. 关联逻辑重算并覆盖旧数据：Flink 增量关联作业会将 hudi_pay 的变更记录，与 hudi_order 中对应的关联数据（通过 order_id 匹配）重新计算，生成新的关联结果。
3. Hudi 结果表 UPSERT 覆盖：关联结果表 hudi_order_pay_join 同样配置了 operation=UPSERT 和联合主键（order_id,pay_id），新的关联结果会根据联合主键匹配到旧记录，自动覆盖更新，实现 “变更同步”。

闭环流程：hudi_pay 数据变更 → 生成新 commit 版本 → Flink 增量查询捕获变更 → 与 hudi_order 关联重算 → hudi_order_pay_join UPSERT 覆盖旧结果 → 结果同步更新。

二、确保 “变更同步” 的关键配置（缺一不可）

要让关联结果跟着源表变更，必须满足以下 4 个核心配置，否则可能出现 “源表变了，结果表不变” 的情况：

1. 源表（hudi_pay/hudi_order）配置

• 必须启用 hoodie.datasource.write.operation=UPSERT（默认值）：确保变更数据（更新 / 插入）能写入 Hudi 表，并生成增量变更日志。
• 索引配置正确：hudi_pay 的 hoodie.bloom.index.fields 需包含关联字段 order_id，确保增量查询时能快速匹配到对应的 hudi_order 数据。
• 保留操作类型字段（op）：用于过滤删除事件，避免无效关联（但更新事件需保留，供增量关联捕获）。

示例 hudi_pay 关键配置回顾：

sql

CREATE TABLE hudi_pay (
  pay_id BIGINT PRIMARY KEY NOT ENFORCED,
  order_id BIGINT,  -- 关联字段
  pay_amount DECIMAL(10,2),
  pay_time TIMESTAMP(3),
  op STRING  -- 保留操作类型
) WITH (
  'connector' = 'hudi',
  'table.type' = 'MERGE_ON_READ',
  'hoodie.datasource.write.operation' = 'UPSERT',  -- 关键：支持更新
  'hoodie.index.type' = 'BLOOM',
  'hoodie.bloom.index.fields' = 'order_id',  -- 索引关联字段
  ...
);

2. 增量关联作业配置

• 启用流读取模式：read.streaming.enabled='true'（必须），否则无法实时捕获源表增量变更。
• 关联逻辑包含所有必要字段：确保 hudi_pay 变更的字段（如 pay_amount）被纳入关联查询，否则结果表无法同步更新该字段。
• 过滤删除事件，但保留更新事件：WHERE o.op != 'd' AND p.op != 'd'，仅排除删除事件，允许更新事件进入关联逻辑。

增量关联作业 SQL 关键片段：

sql

INSERT INTO hudi_order_pay_join
SELECT
  o.order_id,
  o.user_id,
  o.amount AS order_amount,
  o.create_time,
  p.pay_id,
  p.pay_amount,  -- 若 hudi_pay.pay_amount 变更，该字段会同步更新
  p.pay_time
FROM hudi_order /*+ OPTIONS('read.start-commit'='xxx', 'read.streaming.enabled'='true') */ o
LEFT JOIN hudi_pay /*+ OPTIONS('read.start-commit'='xxx', 'read.streaming.enabled'='true') */ p
ON o.order_id = p.order_id
WHERE o.op != 'd' AND p.op != 'd';  -- 保留更新事件

3. 结果表（hudi_order_pay_join）配置

• 联合主键正确：必须包含 order_id 和 pay_id（PRIMARY KEY (order_id, pay_id) NOT ENFORCED），确保新的关联结果能通过主键匹配到旧记录，实现 UPSERT 覆盖。
• 启用 operation=UPSERT：结果表默认是 UPSERT 操作，无需额外修改，但需确保未手动改为 INSERT（否则会重复写入，而非覆盖）。
• 表类型推荐 MERGE_ON_READ：兼顾实时性和写入性能，变更后结果表能快速反映最新数据（若用 COPY_ON_WRITE，写入时会直接覆盖旧文件，查询性能更好但写入延迟略高）。

结果表关键配置回顾：

sql

CREATE TABLE hudi_order_pay_join (
  order_id BIGINT,
  user_id BIGINT,
  order_amount DECIMAL(10,2),
  create_time TIMESTAMP(3),
  pay_id BIGINT,
  pay_amount DECIMAL(10,2),
  pay_time TIMESTAMP(3),
  PRIMARY KEY (order_id, pay_id) NOT ENFORCED  -- 联合主键：匹配旧记录
) WITH (
  'connector' = 'hudi',
  'table.type' = 'MERGE_ON_READ',
  'hoodie.datasource.write.operation' = 'UPSERT',  -- 关键：覆盖更新
  ...
);

4. Flink 作业配置

• 开启 Checkpoint：确保作业故障恢复后，能从断点继续捕获增量变更，不丢失更新事件（建议配置 1 分钟一次）。
• 并行度匹配：Flink 作业并行度需与 Hudi 表分区数、Kafka 分区数匹配，避免数据倾斜导致变更事件延迟或丢失。

三、实操验证：手动测试变更同步效果

为了确认功能生效，可按以下步骤手动测试：

步骤 1：初始化数据

1. 向 MySQL 订单表插入一条数据：order_id=1001, user_id=1, amount=100, create_time='2025-01-01 10:00:00'；
2. 向 MySQL 支付表插入一条关联数据：pay_id=2001, order_id=1001, pay_amount=100, pay_time='2025-01-01 10:05:00'；
3. 等待 Flink 作业同步数据到 hudi_order、hudi_pay 和 hudi_order_pay_join；
4. 在 Doris 中查询关联结果：

   sql

   SELECT order_id, pay_id, pay_amount FROM doris_order_pay_join WHERE order_id=1001;
   -- 预期结果：order_id=1001, pay_id=2001, pay_amount=100
   

步骤 2：修改 hudi_pay 数据

1. 在 MySQL 中更新支付金额：UPDATE pay_table SET pay_amount=90 WHERE pay_id=2001；
2. Debezium 捕获该 binlog 变更，写入 Kafka，Flink 作业同步到 hudi_pay（生成新的 commit 版本）；
3. 增量关联作业捕获 hudi_pay 的更新事件，重新关联 hudi_order（order_id=1001），生成新的关联结果；
4. 新结果通过 UPSERT 覆盖 hudi_order_pay_join 中 order_id=1001, pay_id=2001 的旧记录。

步骤 3：验证关联结果更新

在 Doris 中重新查询：

sql

SELECT order_id, pay_id, pay_amount FROM doris_order_pay_join WHERE order_id=1001;
-- 预期结果：order_id=1001, pay_id=2001, pay_amount=90（已同步更新）

四、常见问题：为什么变更后结果表没更新？

如果测试后结果表未同步更新，大概率是以下 3 个问题：

1. 增量查询未启用：hudi_pay 或 hudi_order 未配置 read.streaming.enabled='true'，导致作业无法捕获增量变更；
2. 联合主键缺失：hudi_order_pay_join 未设置 (order_id, pay_id) 联合主键，新结果无法匹配旧记录，导致重复写入而非覆盖；
3. 关联逻辑未包含变更字段：若 hudi_pay 变更的字段（如 pay_amount）未出现在关联查询的 SELECT 子句中，结果表自然不会更新该字段；
4. 作业未正常运行：Flink 增量关联作业挂掉或处于停滞状态，需检查作业日志和 Checkpoint 状态。

五、补充说明：删除事件的处理

如果 hudi_pay 发生删除事件（op='d'），由于关联逻辑中过滤了 p.op != 'd'，增量关联作业不会处理该事件，hudi_order_pay_join 中对应的关联记录会保留原样。

若需同步删除结果表的记录，需单独处理：

1. 新增一个删除流作业，捕获 hudi_pay 的删除事件；
2. 关联 hudi_order 获取 order_id，生成结果表的删除记录；
3. 以 operation=DELETE 方式写入 hudi_order_pay_join，删除对应的关联记录：

sql

-- 同步 hudi_pay 删除事件到结果表
INSERT INTO hudi_order_pay_join /*+ OPTIONS('hoodie.datasource.write.operation'='DELETE') */
SELECT
  o.order_id,
  o.user_id,
  o.amount AS order_amount,
  o.create_time,
  p.pay_id,
  p.pay_amount,
  p.pay_time
FROM hudi_order /*+ OPTIONS('read.streaming.enabled'='true') */ o
JOIN hudi_pay /*+ OPTIONS('read.streaming.enabled'='true') */ p
ON o.order_id = p.order_id
WHERE p.op = 'd';

总结

在 Hudi 增量关联场景中，hudi_pay 的变更会通过 “增量捕获→关联重算→UPSERT 覆盖” 的逻辑，自动同步到 hudi_order_pay_join 结果表，核心是确保源表、关联作业、结果表的配置一致且正确。

该机制完全满足 “实时同步新数据 + 变更联动” 的业务需求，与 Paimon 的变更同步逻辑异曲同工，仅在配置细节上有差异。