Lambda 架构是什么
Lambda 架构把数据处理拆成两条路径：批处理层对全量历史数据重算，结果准确但延迟高；速度层对增量数据实时处理，延迟低但结果可能是近似的；服务层在查询时合并两个视图对外提供结果。它以两套计算逻辑为代价，换取历史口径准确与实时数据可用的同时满足，是流处理框架成熟度有限时期的典型折中。
落地要盯住三件事
一是口径统一：两层必须共享同一份指标定义与数据模型，否则同一指标会出现两个数值；二是校验闭环：定期比对批处理与实时结果，偏差超过阈值时以批处理结果为准并修订实时逻辑；三是演进判断：当可重放的事件存储与流处理能力足够成熟，可以评估向单链路架构收敛，省下一份逻辑的维护成本。
基本信息
| 批处理层 | 处理全量历史数据，结果准确但延迟较高 |
|---|---|
| 速度层 | 处理增量数据，低延迟优先，结果可能近似 |
| 服务层 | 查询时按需合并批视图与实时视图 |
| 主要成本 | 同一业务逻辑需维护两套实现，并持续保持口径一致 |
| 校验机制 | 定期比对两层结果，偏差超限以批处理结果为准修订 |
Lambda 与 Kappa 对照
| 维度 | Lambda | Kappa |
|---|---|---|
| 处理路径 | 批处理与流处理双路并行 | 单一流路，靠重放补历史 |
| 实现成本 | 同一逻辑维护两套实现 | 一套逻辑，需可重放的事件存储 |
| 结果来源 | 两路视图在查询时合并 | 单一结果视图 |
| 主要风险 | 双路结果漂移 | 重放窗口与存储成本 |
| 适用时机 | 流处理能力有限、历史口径复杂 | 日志留存与重放能力完备 |
典型使用场景
- 实时看板同时要求历史口径准确，短期无法用纯流处理实现
- 既有离线数仓仍在服务报表，需要叠加实时视图供运营查看
- 历史数据需要反复重算修正，由批处理层承担修正职责
- 流处理框架能力有限，先用两层架构过渡并积累经验
选型提示：数据规模与时效要求不高时先用单一链路控制维护成本，两套逻辑的长期一致性问题往往比延迟更消耗人力。
两套实现长期漂移会导致同一指标出现两个数值，必须明确以哪一层为准、由谁负责校验与修正，否则争议无法收敛。