两种架构的取舍
Lambda 架构把同一条链路做成两套：速度层负责秒级近似结果，批处理层每天重算一份精确结果，查询时再用批层覆盖流层的数。这样能得到又准又快的指标，代价是同一口径要写两遍代码。Kappa 架构只保留流处理一条链路，口径变更时通过重放历史数据来修正结果，前提是数据源可以长期重放。选择哪一种，取决于「同一口径维护两套实现的成本」和「历史数据能不能重放」这两件事哪个更棘手。
基本信息
| Lambda | 批层 + 速度层 + 服务层，最终以批层为准 |
|---|---|
| Kappa | 单一流链路，口径变更靠重放历史 |
| 取舍 | Lambda 两套逻辑易漂移；Kappa 依赖可重放的数据源 |
| Kappa 前提 | 消息保留期足够长，或原始数据在对象存储上可回放 |
| 典型组件 | Flink/Spark 流作业、离线批作业、查询层合并 |
Lambda 典型数据流
Lambda 典型数据流
Kafka ─┬─→ 流作业（秒级）──→ 实时视图 ─┐
└─→ 批作业（T+1）──→ 全量视图 ─┴─→ 查询层合并典型使用场景
- 实时大屏同时要求秒级可见与日终准确，Lambda 的分层最直接
- 口径尚未稳定时用 Kappa，改逻辑只改一处再重放
- 数据源是 Kafka 且保留期很短，只能依赖批层兜底
- 业务规则复杂、流处理难以表达全部逻辑，批层承担主计算
- 已有成熟批任务想逐步实时化，可先并存再收敛成单链路
两种架构对比
| 维度 | Lambda | Kappa |
|---|---|---|
| 链路数量 | 两条（流 + 批） | 一条（纯流） |
| 口径一致性 | 两套实现，需人工对齐 | 单实现，天然一致 |
| 修正手段 | 批层覆盖流层 | 重放历史数据 |
| 时效与准确 | 实时近似 + 日终精确 | 取决于流作业本身 |
| 主要风险 | 两套逻辑漂移对不上账 | 源端保留不足导致无法补数 |
数据可长期重放（Kafka 大保留期或对象存储归档）时 Kappa 更易维护；否则批层仍是兜底。
两条链路合并时要明确「谁覆盖谁」以及覆盖发生的时刻，否则同一指标在同一天内会出现先升后降或反复跳变。