Lambda与Kappa数据架构对比

Lambda架构：

设计理念： 同时维护批处理层（Batch Layer）和流处理层（Speed Layer），在服务层（Serving Layer）合并结果。

三层结构：

1. 批处理层（Batch Layer）：
   • 存储全量原始数据（HDFS/S3）
   • 定期运行批作业计算准确结果
   • 保障数据准确性（Accuracy）
2. 流处理层（Speed Layer）：
   • 实时计算新到数据
   • 提供**低延迟（Low Latency）**的结果
   • 补偿批处理的延迟
3. 服务层（Serving Layer）：
   • 合并批结果和流结果
   • 提供统一查询服务

优缺点： | 优点 | 缺点 | |------|------| | 数据准确度高（批处理保证） | 两套代码维护成本高 | | 容错性好 | 结果合并逻辑复杂 | | 技术成熟 | 数据量翻倍存储 |

Kappa架构：

设计理念： 只用一套流处理引擎处理所有数据，通过重放历史数据实现批处理等效。

核心思想：

1. 所有数据以事件流形式进入Kafka（不可变日志）
2. 流处理引擎（如Flink）实时处理
3. 如需重新计算，直接重放Kafka中的历史数据
4. 无需单独的批处理层

优缺点： | 优点 | 缺点 | |------|------| | 一套代码，维护简单 | 流处理需支持Exactly-Once | | 实时性好（无批滞后）| 历史数据重放时间长 | | 架构简洁 | 复杂逻辑的流处理实现难度大 | | 存储成本低（无两份数据）| Kafka存储/IO要求高 |

选型对比： | 场景 | 推荐架构 | 原因 | |------|----------|------| | 金融/报表（要求绝对准确） | Lambda | 批处理保证准确性 | | 实时监控/推荐（追求低延迟） | Kappa | 架构简单延迟低 | | 数据量大但允许少量误差 | Kappa | 运维成本低 | | 公司刚起步实时数仓 | Kappa | 技术栈统一 |