播面

在利用 Apache Paimon 的 Partial-Update（局部更新）引擎实现实时多流拼接以替代传统的 Flink Stateful Join 时，设计 Flink 链路通常有两种主流方案：单作业 UNION ALL 写入 还是 启动多个不同的 Flink 作业并发写入（Multi-Writer 模式）。

根据 Paimon 官方文档（包括 master 分支最新规范）以及社区的最佳实践，通常优先推荐选择“单作业 UNION ALL 写入”。但在特定业务场景下，如果对业务解耦有极高要求，也可以在做好配套运维配置的前提下选择“多作业并发写入”。

以下将从底层机制、优缺点以及适用条件三个维度为您详细对比和剖析这两种方案：

---

方案一：单作业 UNION ALL 写入（官方首推方案）

1. 工作原理

在这种架构下，所有的源数据流都在同一个 Flink 作业中消费。对于每个流没有涉及的列，在 SQL 中通过补 NULL（或 CAST(NULL AS TYPE)）的方式，使所有流的 Schema 结构对齐，然后通过 UNION ALL 合并为一个统一的数据流，最后由同一个 Paimon Sink 写入目标表。

2. 核心优势

• 天生兼容动态分桶（Dynamic Bucket）：
  • 这是选择单作业的最关键技术因素。Paimon 的动态分桶模式（'bucket' = '-1'）能够根据数据量自动扩展桶。但是，Paimon 官方明确指出：动态分桶模式仅支持单作业写入。如果启动多个独立作业写入同一个动态分桶表，会导致 RocksDB 索引冲突、数据重复甚至 Checkpoint 失败。
• 无物理提交冲突（Commit Conflict）：
  • 因为只有一个 Flink 作业作为 Writer，各 Subtask 之间通过 Flink 内置的 Shuffle 机制按 Bucket 进行分发，确保一个 Bucket 同一时间只有一个 Writer 线程在写。这消除了 Paimon 底层的快照冲突（Snapshot Conflict）和文件冲突（Files Conflict）。
• Compaction（文件合并）高效且无冲突：
  • Flink 作业可以在写入数据的同时，在 Sink 端安全地进行自动的异步 Compaction，无需担心多个作业同时对同一个 Bucket 的数据文件进行逻辑删除和合并导致的冲突。

3. 局限性与风险

• 业务耦合度高：
  • 所有的多流拼接逻辑都在一个作业中。如果其中某一个源数据流由于格式异常、延迟、反压而导致任务重启，或者需要修改某一条流的清洗逻辑，整个 Flink 作业都必须停启，会影响其他正常流的写入。
• SQL 编写略显冗长：
  • 因为需要使用 UNION ALL，每一路流都需要用大量 NULL 字段进行对齐，当字段数量达到上百个时，SQL 的可读性和维护成本较高。

---

方案二：启动多个不同的 Flink 作业并发写入同一张表

1. 工作原理

不同的源数据流分别由不同的、相互独立的 Flink 作业进行消费。每个作业只关注自己负责的局部列，直接将包含主键和部分列的数据写入到同一个 Paimon 表中，在存储层（LSM-Tree 合并阶段）通过主键完成局部列的拼接。

2. 核心优势

• 业务完全解耦，运维灵活性高：
  • 各个流的作业可以独立上线、下线、扩缩容、调优。某一路流发生反压或崩溃，不会拖累其他流的正常写入。
• 开发更加简便：
  • 不需要编写复杂的 UNION ALL 补空列 SQL，各流只需按需写入各自拥有的列即可。

3. 局限性与致命痛点

• 不能使用动态分桶（Dynamic Bucket）：
  • 必须使用固定分桶（Fixed Bucket）（即必须指定 'bucket' = 'N'）。这意味着在表创建之初就必须准确预估数据量并设定合理的 Bucket 数量，否则后续调整桶大小（Rescale）需要进行繁琐的离线重构。
• Compaction 和 Snapshot 冲突频繁，导致作业频繁失败重启：
  • Paimon 默认会在 Writer 端自动触发 Compaction 并在 Checkpoint 时进行快照提交。由于多个 Flink 作业独立运行，它们会同时向同一个 Bucket 发起 Compaction 并在元数据层提交删除/修改文件的事务。一旦其中一个作业提交快照覆盖了另一个作业正在操作的文件，就会发生 Files conflict，导致 Flink 作业发生 Failover 强制重启。

4. 采用方案二必须满足的改造条件

如果因为业务解耦原因必须采用方案二，您需要在表和作业设计上做出以下妥协与额外运维配置：

1. 禁用 Writer 端 Compaction（开启 Write-Only 模式）：
   • 在 Paimon 表属性中设置 'write-only' = 'true'。这可以让 Flink 写入作业只写不合并，从而彻底避免多作业写入时的 Compaction 冲突。
2. 启动独立的 Compaction 作业（Dedicated Compaction Job）：
   • 因为 Flink 写入作业不再负责文件合并，小文件会迅速堆积导致读取性能崩溃。您必须额外启动一个专门的 Paimon Compaction 服务（使用 Flink Action 包或通过后台定期运行批任务来执行 sys.compact 存储过程）来进行全局的文件压缩。
3. 配置目录锁（Catalog Lock）：
   • 如果数据文件存储在对象存储（如 OSS、S3，其 Rename 不具备原子语义）上，您必须启用 Hive Metastore 或 JDBC Metastore，并开启 'lock.enabled' = 'true' 来确保并发提交的事务安全，避免出现极低概率的 Snapshot 丢失。
4. 乱序与 Sequence 组配置：
   • 多个作业独立写入时，由于网络和计算延迟不同，可能会发生严重的数据乱序。您必须为每一路流的字段配置独立的 Sequence Group（序列组，基于 'sequence-group.<group-name>.fields'），以防旧数据意外覆盖新写入的数据。

---

设计抉择与建议

• 优先推荐：单作业 UNION ALL。如果各数据流的开发团队较为统一，或者任务整体的数据吞吐量在集群可承受范围内，单作业方案可以避免复杂的物理冲突管理、可以使用更具伸缩性的动态分桶，整体维护成本最低。
• 次选方案：多作业并发 + 独立 Compaction 任务。如果业务流属于不同部门管理，必须在物理上彻底解耦，那么在采用此方案时，请务必确保设置了固定分桶（Fixed Bucket）、开启了 'write-only' = 'true' 属性，并部署了独立的 Dedicated Compaction 调度任务。