【背景】 做了 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，理由有三：
- 「可纠错性」决定要不要兜底。资金、结算、合规类数据错了要能追溯、能重算，这类必须有离线全量做权威源，实时只是它的「投影」。
- 「时效敏感度」决定要不要实时。T+1 够用的指标，别为实时付出双链路成本——这本质是 ROI 问题，和热榜里「P99 降 1ms 值不值 3 天」是同一类账。
- 口径一致性靠「单一事实源」，而不是「两套代码对齐」。我们后来把公共层逻辑收敛成一份 Flink SQL 作业 + 一份离线 Spark 作业，共享同一份 DDL 和 UDF，口径漂移从 1.8% 降到 0.3% 以内——但这靠的是工程纪律，不是架构自动保证的。
【补：双链路口径漂移怎么量化与监控（踩坑后的落地方案）】 上面提到我们把口径漂移从 1.8% 压到 0.3%，但「压到 0.3%」不是靠一次重构，而是靠一套持续监控 + 自动告警 + 阈值收敛的闭环。补充我们实际在跑的三层监控：
第一层：T+1 对账作业（离线批跑，每天 02:00）
- 对每个核心指标，按「业务日期 × 租户」粒度对齐实时累积值与离线全量值
- 计算 drift_ratio = |realtime_cumulative - batch_full| / batch_full
- 告警规则：drift_ratio > 0.5% → P2 工单；> 1.0% → P1 并冻结该指标的下游消费
- 关键细节：对账窗口必须对齐 watermark。我们一开始用「实时已落库的最后一条 timestamp」做截止，结果迟到数据（watermark 容忍 5min）让对账窗口比离线短了 5min，drift 恒定偏高 0.1%——后来改成「离线分区的时间戳上界 - watermark_tolerance」做截止，漂移立刻归零
- 实现：Spark SQL 作业，读 Flink 的 sink 表（Hudi / Iceberg）与离线批结果表，输出 drift_ratio 到监控指标（Prometheus gauge:
dual_pipeline_drift_ratio{metric="gmv", tenant="*"}）
第二层：实时链路的「口径健康度」指标（Flink 内置 + 自定义）
- 监控 Flink 作业的 watermark lag：
currentWatermark - System.currentTimeMillis()> 60s → 告警（说明事件时间推进慢了，实时结果正在「欠账」） - 监控迟到数据占比：
late_events / total_events，连续 10min > 5% → 告警（说明 watermark 容忍度可能不够，口径会漂） - 监控 state size 增长率：
state_size_delta_1h / state_size_baseline> 20% → 告警（状态膨胀通常意味着窗口没正常 close，聚合结果会持续偏） - 这三个指标是「漂移的先行指标」——在 T+1 对账发现漂移之前 2~6 小时就能预警
第三层：下游消费的「口径一致性 SLO」
- 把「同一指标在实时与离线链路的 drift_ratio < 0.5%」写进 SLO 文档，而不是藏在监控面板里
- SLO 违约定义：连续 3 天 drift_ratio > 0.5%（排除已知的 watermark 窗口边界效应）
- 这个 SLO 的 owner 是数据平台团队，不是业务团队——和业务侧「P99 < 50ms」的 SLO 一样，门禁不是配置项，是功能
【想听大家在什么场景下怎么选】
- 你们的数据团队现在走 Lambda、Kappa 还是混合？核心判断依据是什么（时效？成本？团队技能栈？）
- 实时 + 离线双链路时，口径不一致你们怎么量化、怎么监控？有没有「对账作业 + 阈值告警」的成熟做法可以借鉴？
- 有没有「上了全实时又退回批处理」的案例？是什么触发的——成本、稳定性、还是技能栈？
- Flink 作业的 Exactly-Once 在 sink 端（尤其非事务性 sink）你们的边界怎么划？迟到 / 乱序数据的处理策略是什么？
欢迎贴具体数字（口径差多少、断档多久、双链路多付了多少人天），空对空的架构讨论我读不进去。