Flink中RETRACT流是否必要？为何不能用UPSERT流完全替代？

• 首先*UPSERT流的强依赖前提是必须定义唯一主键*，但通用Dynamic Table和普通DataStream都没有强制要求绑定主键，大量无主键的动态表根本无法生成合法的UPSERT流。
• 普通DataStream没有内置主键语义和对应的状态维护逻辑，用户拿到UPSERT流后无法直接识别同主键的覆盖关系，很容易因为未按主键去重得到错误的计算结果。
• UPSERT流仅携带最新记录值、隐式实现同主键覆盖，不会保留完整的变更链路，也没有明确的撤回标记，不符合DataStream用户对全量变更日志的获取预期。
• DataStream API是通用流处理接口，设计上要兼容所有无结构化约束的流数据，绑定UPSERT的主键要求会大幅限制接口的通用性。

• 无主键场景完全无法支持：很多业务流（比如用户行为日志、时序上报数据）本身没有唯一业务主键，所有记录都是独立事件，UPSERT的主键依赖完全不成立，只能靠带明确+/-标记的RETRACT流处理变更。
• 依赖旧值的计算场景无法实现：比如差值计算、变更审计类需求需要获取更新前后的两个版本值，RETRACT流会同时下发旧值撤回消息和新值插入消息，而UPSERT流仅携带最新值，无法提供旧值支撑这类计算。
• 复杂多表关联逻辑无法处理：比如外连接、多层嵌套关联场景中，上游表的字段变更可能需要撤回下游关联生成的多条无关记录，UPSERT仅能靠同主键覆盖更新，无法精准定位并撤回无直接主键关联的衍生记录，RETRACT的明确撤回标记可以完美适配这类场景。
• 下游系统兼容性差：绝大多数中间件（比如Kafka、RabbitMQ）和存储系统本身没有内置主键覆盖语义，UPSERT流下发到这类组件后，下游消费方必须额外维护主键状态才能正确处理数据，大幅提高了使用门槛，而RETRACT流的显式变更标记不需要额外依赖即可被下游直接识别。

内容的提问来源于stack exchange，提问作者Dilibaba