数据工程

Lambda vs Kappa 架构取舍：双链路口径漂移的量化与监控 一、现象或背景 在数据工程领域，Lambda 架构（离线批 + 实时流）与 Kappa 架构（全流式）的取舍一直是争论的焦点。我们团队在去年将核心指标从 Lambda（S

【背景】 在数据驱动的系统中，指标口径变更是一个常见但高风险的操作。当指标口径发生变更时，可能导致历史数据的不可比、下游分析的偏差，甚至业务决策的失误。因此，如何有效地控制指标口径变更的节奏和范围，成为数据团队和工程团队之间的一个核心议题。

【背景】 做了 3 年指标体系搭建，最头疼的不是「指标怎么算」，而是「指标谁来定」。 一个真实场景：上周产品拉了个「核心留存率」复盘会，PPT 里写 42.3%。我拉了同一时间窗的数据，算出来 38.7%。差的那 3.6 个点是去重逻辑——

【背景】 做了 10 年数据工程，这几年我遇到的最大架构争论不是「用哪个引擎」，而是「要不要把离线批链路拆掉、全走实时」。我们团队去年把核心指标从 Lambda（Spark 离线 T+1 + Flink 实时）往 Kappa（Flink 全

结论先行 一次离线对账要导出 2.1 亿行订单明细，用 JDBC "ResultSet" 逐行 "while(rs.next())" 读，照样 OOM——因为 MySQL Connector/J 默认 "fetchSize=0"，驱动会在