Flink join对比

三种 Join 方式全面对比

一、机制对比

维度	Stream-Stream Join	Lookup Join	Delta Join（Fluss 规划中）
驱动方式	双向驱动，两条流互等	单向驱动，流查维表	单向增量驱动 + 存储查询
Join 对象	流 ⟷ 流	流 → 表（维表）	流 → Fluss 表（带 changelog）
状态管理	两条流都存 Flink State	维表缓存在 Flink 或外部查询	状态卸载到 Fluss
State 大小	大（两条流都要缓存）	小/无（查外部存储）	极小（Flink 侧几乎无状态）
结果语义	完整的双向关联	只能流查表，维表变更不反推	双向感知变更

二、性能对比

维度	Stream-Stream Join	Lookup Join	Delta Join
延迟	低（内存中匹配）	取决于维表存储（ms ~ min）	亚秒级（规划值）
吞吐	受 State 限制，大状态下降	高（无重状态）	高（规划值）
Checkpoint	慢（State 大）	快（State 小）	快（State 卸载）
撤回	严重（Outer Join 撤回风暴）	无撤回	轻微（存储层管理）
资源消耗	高（CPU + 内存 + 磁盘）	低	低（Flink 侧）

三、数据正确性对比

维度	Stream-Stream Join	Lookup Join	Delta Join
维表变更感知	✅ 双向感知	❌ 不感知（查时快照）	✅ 感知（changelog 驱动）
数据一致性	高（但撤回复杂）	中（维表延迟导致结果偏差）	高（规划值）
乱序处理	容易产生错误中间结果	无影响（点查快照）	待验证
数据丢失风险	低（State 有 checkpoint）	低	取决于 Fluss 可靠性

四、典型场景对比

场景	推荐方案	原因
订单流 Join 支付流（两条大流）	Stream-Stream Join	双向等待匹配，Lookup Join 做不了
订单流补全用户信息（流 + 维表）	Lookup Join	经典维表关联，简单高效
实时宽表打宽（多维度补全）	Lookup Join	一条事实流 join 多张维表
实时对账（两条流互相校验）	Stream-Stream Join	必须双向匹配
CDC 流关联实时更新的维表	Delta Join（未来）	维表频繁变更，Lookup 快照会不准
大流 Join + 维表变更需回刷	Delta Join（未来）	Stream-Stream 太重，Lookup 不感知变更

五、Lookup Join 的致命短板

维表变更不回推，举个例子：

10:00  订单A进来，查用户表 → 用户等级=金牌 → 输出：订单A + 金牌
10:05  用户等级从金牌升级为钻石

• Lookup Join： 订单 A 的结果永远是"金牌"，不会更新。因为查的是 10:00 那一刻的快照
• Stream-Stream Join： 如果用户变更也是一条流，可以感知到变更并更新结果
• Delta Join（规划）： Fluss 的 changelog 会驱动重新关联，输出更新后的结果

这就是 Lookup Join 最大的 trade-off：用"不感知维表变更"换来"轻量无状态"。

---

六、Paimon 场景下的实际搭配建议

                    ┌─ Lookup Join ──> Paimon 维表（用户、商品、地区...）│
Kafka/CDC 事实流 ──┤│└─ Stream-Stream Join ──> 另一条事实流（支付、物流...）│▼写入 Paimon 宽表│▼StarRocks/Hologres 查询

实际操作：

1. 能用 Lookup Join 的优先用 — 维表关联场景（90% 的 Join 需求），简单、资源省
2. 两条大流必须互 Join → Stream-Stream Join — 尽量用 Interval Join 限定时间窗口，控制 State
3. 先打宽再写入 Paimon — 在 Flink 层把 Join 做完，结果写 Paimon，避免在 Paimon 上做 Join
4. 维表更新频率高且需要结果准确 → 考虑缩短 Paimon checkpoint 间隔，或者用 MySQL/Redis 做维表

一句话总结：Lookup Join 是干活的主力，Stream-Stream Join 是不得不用的重武器，Delta Join 是画的饼。当前 Paimon 的最佳实践就是 Lookup Join + Stream-Stream Join 组合拳，在 Flink 层打宽后写入 Paimon。