播面

在利用 Apache Paimon 的 partial-update（局部更新）引擎进行多流实时拼接以取代传统的 Flink Stateful Join 时，链路设计是一个非常关键的架构决策。

在设计 Flink 写入链路时，主要有两种方案：单作业 UNION ALL 写入 和 启动多个 Flink 作业并发写入同一张表。

结论先行：在绝大多数生产场景下，强烈推荐使用“单作业 UNION ALL 写入”。如果业务由于团队协作、资源隔离等原因必须采用“多作业并发写入”，则需要引入非常复杂的配套架构（如专用压缩作业和分布式锁）。

方案一：单作业 UNION ALL 写入（官方及业界主流推荐）

在此方案中，你将读取多个源表（例如订单、支付、物流等 Kafka 流量），在 Flink 中通过 Projection（投影）对齐 schema（缺失的字段补为 NULL），然后通过 UNION ALL 合并为一个流，最后由同一个 Flink 汇（Sink）写入 Paimon 表。

INSERT INTO paimon_wide_table
SELECT order_id, user_id, price, CAST(NULL AS STRING) as pay_status, CAST(NULL AS STRING) as ship_status FROM order_stream
UNION ALL
SELECT order_id, CAST(NULL AS BIGINT) as user_id, CAST(NULL AS DOUBLE) as price, pay_status, CAST(NULL AS STRING) as ship_status FROM pay_stream
UNION ALL
SELECT order_id, CAST(NULL AS BIGINT) as user_id, CAST(NULL AS DOUBLE) as price, CAST(NULL AS STRING) as pay_status, ship_status FROM ship_stream;

🟢 优点：

1. 完全避免快照与写入冲突（零冲突）：
   在 Flink 拓扑中，Paimon Writer 会自动根据 Bucket 进行 Shuffle，确保每个 Bucket 物理上只由一个并发的 Writer 任务写入。在单作业内部，由于只有一个 Global Committer 进行快照提交，写入是完全线性且安全的，不需要任何分布式锁机制。
2. 支持动态桶（Dynamic Bucket）：
   如果数据量无法精准预估，使用 'bucket' = '-1'（动态桶）能让 Paimon 自动扩展 Bucket 数量，减少小文件并优化吞吐。动态桶机制强绑定单作业写入，多作业并发写入动态桶表会导致索引映射错乱从而损坏数据。
3. 极低的运维与存储开销：
   Paimon 的 Writer 默认会在写入的同时在后台异步自动进行 Compaction（文件压缩）。因为是单作业，Writer 可以安全地合并 Sorted Run 小文件，维持 LSM 树的高查询性能，不需要额外启动别的辅助任务。
4. 易于统一控制乱序：
   多流拼接不可避免存在数据乱序。在单作业内，可以非常方便地定义全局的 watermark 或者统一利用 sequence-group（序列组）来控制不同字段的更新顺序，确保后到的晚期数据不会覆盖掉更新的数据。

🔴 缺点：

• 故障隔离性较差：一旦其中一个上游源流（如支付流）发生异常导致作业崩溃，整条多流拼接的 Flink 链路都会停摆并发生重启。
• 业务变动重构代价高：如果其中某一个子流的 Schema 发生变更，必须停止整个大作业并重新提交部署。

方案二：启动多个不同的 Flink 作业并发写入（多 Writer 并发）

在此方案中，你为每个数据源启动一个独立的 Flink 作业（Job A 负责写订单字段，Job B 负责写支付字段等），它们并发地向同一个 Paimon 目录发起 Commits。

🟢 优点：

• 业务和故障完全隔离：各个作业生命周期独立。Job A 挂了，Job B 依然能够正常实时更新它的那部分字段，互不干扰。
• 资源配置灵活：可以根据各个流的数据量和吞吐压力，单独调整每个 Flink 作业的 Parallelism 和 Slot 资源分配。

🔴 缺点与设计踩坑（为什么复杂）：

如果你直接启动两个普通的 Flink 写入作业，短时间内作业可能就会因为 Snapshot Conflict（快照冲突）或 Compaction 冲突而频繁崩溃重启。要让该方案落地，你必须付出极高的技术和运维成本进行调优：

1. 必须关闭 Writer 端的自动 Compaction（转为 Write-Only）：
   因为两个 Job 可能会同时对同一个 Bucket 的数据文件进行 Compaction 并标记为删除，这在 Commit 阶段会产生严重的乐观锁冲突。
   你必须在 Paimon 表属性中强制设置：
   'write-only' = 'true'
2. 必须额外运行一个“专用 Compaction 作业”：
   既然写入作业不负责压缩小文件，长此以往会导致小文件泛滥，读取性能骤降。你必须额外启动一个专门的 Flink Action / Spark 压缩作业来定时或持续合并该表的文件：
   bash

   # 启动一个独立的后台压缩任务
   flink run ... paimon-flink-action.jar compact --warehouse ... --database ... --table ...

3. 必须开启分布式 Catalog 锁：
   在对象存储（如 S3、OSS）或 HDFS 上，由于不支持原子的 Rename 语义，多作业并发提交极易导致元数据损坏。你必须在 Catalog 级别启用分布式锁（例如基于 Hive Metastore 或 ZooKeeper 的锁）：
   'lock.enabled' = 'true'
4. 无法使用动态桶：
   必须使用固定桶（'bucket' = 'N'），这意味着你在建表之初就必须做好容量规划，且随着业务增长，后续调整桶宽度的成本很高。

架构选型对比总结

💡 生产落地最佳实践建议

如果你的核心目的是通过 Paimon 代替 Flink 状态来实现低成本的多流拼接，建议首选 方案一：单作业 UNION ALL。为了保证其在生产环境高可用，应配合以下表配置项：

1. 配置 Sequence Group（序列组）解决多流乱序问题：
   多流并发 UNION ALL 到一张表时，各个流的数据到达顺序不一致（例如订单消息先到，用户基本信息后到）。如果不加控制，旧数据可能会覆盖新写入的数据。
   应该在 Paimon 建表 DDL 中根据不同的流划分不同的“序列组”：
   sql

   CREATE TABLE paimon_wide_table (
       order_id STRING PRIMARY KEY NOT ENFORCED,
       price DOUBLE,
       order_time TIMESTAMP(3),
       pay_status STRING,
       pay_time TIMESTAMP(3),
       -- 更多字段...
   ) WITH (
       'merge-engine' = 'partial-update',
       -- 订单流的序列字段控制 price 这一组字段
       'fields.order_time.sequence-group' = 'price',
       -- 支付流的序列字段控制 pay_status 这一组字段
       'fields.pay_time.sequence-group' = 'pay_status'
   );

2. 开启正确的 Changelog Producer：
   如果下游还需要以流式方式（Streaming Read）去消费这张拼接好的宽表，必须配置 Changelog 产生机制，否则下游读不到合并后的正确 Changelog 撤回流。推荐对于多流拼接配置 lookup 机制：
   sql

   'changelog-producer' = 'lookup'

3. 处理撤回与删除：
   partial-update 默认不支持接收 DELETE 消息（收到会报错）。如果你的上游存在撤回或物理删除，请配置：
   sql

   'partial-update.ignore-delete' = 'true' -- 如果业务上可以忽略删除
   -- 或者
   'partial-update.remove-record-on-delete' = 'true' -- 收到 DELETE 时物理删除整行