Kappa架构与Lambda架构对比
请对比实时数仓的Lambda架构和Kappa架构的设计理念、优缺点以及在什么场景下选择Kappa架构。
回答
我还是少年
一、Lambda架构：
设计： 批处理（Batch Layer）+ 流处理（Speed Layer）+ 服务层（Serving Layer）
数据摄入 → 批处理层（全量计算）→ 服务层
→ 流处理层（增量计算）→ 服务层（合并结果）
优点：
- 数据完整：批处理保证全量准确
- 延迟可控：流处理补偿批处理的延迟
- 容错性强：批处理可从原始数据重新计算
缺点：
- 维护两套代码：批处理和流处理逻辑需要各自实现
- 数据不一致：批量和流式结果可能不一致（需要合并逻辑）
- 复杂度高：运维两套系统
二、Kappa架构：
设计： 只用流处理，用Replay机制处理全量数据
数据摄入 → Kafka（消息队列，保留全量数据）→ 流处理引擎（实时处理）→ 服务层
↑--------- Replay（回溯）----------|
优点：
- 单一代码：一套流处理逻辑
- 架构简单：Kafka + Flink/Storm
- 灵活：通过调整Offset来回溯计算
缺点：
- 消息队列保留数据有限（需配置大容量的Kafka/Tiered Storage）
- 历史数据全量重新计算慢（需加快照/状态恢复）
- 流处理状态管理复杂（大状态问题）
三、选择建议：
选择Kappa架构的场景：
- 数据量可被Kafka/消息队列承载
- 实时性要求高（秒级延迟）
- 团队资源有限（只需维护一套流处理）
- 数据模型简单，不涉及复杂批量聚合
选择Lambda架构的场景：
- 历史数据量大，无法全部保留在消息队列
- 需要复杂的批量ETL/回溯
- 对数据准确性要求绝对（如金融）
现代实践（混合/流批一体）：
- Flink支持批模式和流模式在同一个引擎下
- Kafka支持Tiered Storage（远程存储）扩展保留时间
- 很多企业采用Kappa为主，批处理辅助的混合模式