「全实时」是不是伪命题：Lambda 双链路口径漂移 vs Kappa 单链路稳定性，你的数据团队怎么算这笔账？

【背景】 做了 10 年数据工程，这几年我遇到的最大架构争论不是「用哪个引擎」，而是「要不要把离线批链路拆掉、全走实时」。我们团队去年把核心指标从 Lambda（Spark 离线 T+1 + Flink 实时）往 Kappa（Flink 全链路）迁，一年下来我越来越觉得：这不是「技术先进性」问题，而是一道成本与风险的取舍题——而且不同数据资产，答案完全不一样。今天想借帖子把几种做法摊开，听听大家在真实场景下怎么选。

【常见分歧 / 几种做法】 派系 A（全实时 / Kappa）：一套链路一套语义，实时和离线口径天然一致，不用再维护两套 SQL、两套调度、两套数据质量监控。听起来很美，但代价是——实时链路从「出个近似值」升级成「承担全部 SLA」：Flink 的状态、checkpoint、反压、Exactly-Once 边界全要兜住，作业一挂，没有离线兜底，指标直接断档。

派系 B（保留 Lambda）：实时负责「快」，离线批负责「对」，每天全量对账把实时误差修掉。稳定性有兜底，但双链路口径漂移是真痛点。我们踩过一个坑：实时用 event_time 开窗、离线用 process_time 落分区，同一个 GMV 指标两边差了 1.8%，排查了三天，根因是时区 + 迟到数据处理策略不一致。

派系 C（混合，我现在的状态）：按数据资产分层。资金/对账/合规类保留离线兜底；监控/探索/大屏类走全实时；中间层（明细/维表）用一份 CDC 同时喂两条链路，减少源头重复建设。

【我的倾向与理由】 我倾向派系 C，理由有三：

1. 「可纠错性」决定要不要兜底。资金、结算、合规类数据错了要能追溯、能重算，这类必须有离线全量做权威源，实时只是它的「投影」。
2. 「时效敏感度」决定要不要实时。T+1 够用的指标，别为实时付出双链路成本——这本质是 ROI 问题，和热榜里「P99 降 1ms 值不值 3 天」是同一类账。
3. 口径一致性靠「单一事实源」，而不是「两套代码对齐」。我们后来把公共层逻辑收敛成一份 Flink SQL 作业 + 一份离线 Spark 作业，共享同一份 DDL 和 UDF，口径漂移从 1.8% 降到 0.3% 以内——但这靠的是工程纪律，不是架构自动保证的。

【想听大家在什么场景下怎么选】

1. 你们的数据团队现在走 Lambda、Kappa 还是混合？核心判断依据是什么（时效？成本？团队技能栈？）
2. 实时 + 离线双链路时，口径不一致你们怎么量化、怎么监控？有没有「对账作业 + 阈值告警」的成熟做法可以借鉴？
3. 有没有「上了全实时又退回批处理」的案例？是什么触发的——成本、稳定性、还是技能栈？
4. Flink 作业的 Exactly-Once 在 sink 端（尤其非事务性 sink）你们的边界怎么划？迟到 / 乱序数据的处理策略是什么？

欢迎贴具体数字（口径差多少、断档多久、双链路多付了多少人天），空对空的架构讨论我读不进去。