Lambda 架构是大数据实时 + 离线混合计算架构，核心设计目标：同时满足 低延迟实时计算 + 全量数据精准计算 + 高可用容错。

传统架构痛点：

• 纯批处理：数据准，但延迟极高（T+1、小时级），没法看实时大屏、实时统计；
• 纯流处理：延迟低，但只能增量计算，历史数据修正、复杂聚合容易不准，容错难。

Lambda 思路：同一份原始数据，走两条计算链路，最后合并对外提供服务。

核心设计原则（底层灵魂）

1. 数据不可变：原始日志 / 事件只追加、不修改、不删除；
2. 时间为轴：所有数据带时间戳，按时间分区处理；
3. 双计算链路：离线批链路 + 实时流链路 并行；
4. 最终合并视图：查询时把离线精准结果 + 实时增量结果合并；
5. 天然可重放：数据永久存储，随时重跑历史任务，修正数据。

四层完整架构拆解（逐层讲透）

第一层：数据源接入层

所有业务原始数据统一接入：

• 来源：用户行为日志、业务数据库 Binlog、IoT 设备上报、接口埋点、订单 / 支付流水；
• 中间缓冲：Kafka / MQ作用：削峰填谷、解耦、数据持久化、支持被批处理和流处理同时消费。

关键：一条数据进 MQ 后，一份给离线层消费，一份给实时层消费，不重复生产。

---

第二层：Batch Layer 批处理层（离线层 / 冷层）

核心职责

1. 持久化存储全量原始数据（数据湖）；
2. 周期性全量重计算，生成全局精准统计结果；
3. 负责数据清洗、维度关联、复杂聚合、数据修正。

存储组件

HDFS、Hive、Iceberg、Hudi、阿里云 OSS / 对象存储（数据湖）

计算组件

Spark Core/Spark SQL、MapReduce、Hive SQL

运行特点

• 调度周期：每日凌晨、每小时、每 6 小时定时调度；
• 计算范围：从历史第一天到当前时间全量数据重跑；
• 输出：离线全量视图（绝对准确、无误差，但是延迟大）；
• 优势：不怕数据错、不怕丢数据，随时重跑全量修复。

---

第三层：Speed Layer 速度层（实时层 / 热层）

核心职责

补全批处理还没算完的最新增量数据

• 批处理是定时跑，两次调度之间的几分钟 / 几小时空白，由速度层实时计算补上；
• 只处理最近增量数据，不做全量重算。

计算组件

Apache Flink、Storm、Kafka Streams、Spark Streaming

运行特点

• 延迟：毫秒～秒级；
• 计算方式：流式增量计算；
• 输出：实时增量视图；
• 短板：只算增量，长期累积会有小误差、状态倾斜、数据漂移，不能单独作为精准报表。

---

第四层：Serving Layer 服务层（对外查询层）

核心职责

1. 存储两层计算结果：
   • 存放批处理产出的离线全量结果
   • 存放速度层产出的实时增量结果
2. 查询合并：用户 / 业务查数据时，自动把「离线全量 + 实时增量」相加合并，返回既准又实时的最终结果。

常用组件

• 离线结果存储：HBase、Cassandra、ClickHouse、Hive；
• 实时结果存储：Redis、ClickHouse、Druid、TimescaleDB；
• 对外接口：自研查询服务、JDBC/HTTP 接口、大数据可视化平台。

完整数据流全流程

1. 业务产生日志 / 流水 → 推入 Kafka；
2. Kafka 数据分流：
   • 分流 1：写入 HDFS / 数据湖，进入批处理层；
   • 分流 2：被 Flink/Storm 消费，进入速度层；
3. 批处理层：定时全量计算 → 生成离线宽表 / 统计结果 → 写入服务层存储；
4. 速度层：实时消费 Kafka 增量 → 实时聚合统计 → 写入服务层实时存储；
5. 前端报表 / 大屏 / 业务系统发起查询 → 服务层合并离线 + 实时数据 → 返回最终结果。

举个通俗例子：电商日活统计

• 批处理层：每天凌晨跑全量历史用户行为，算出截止昨天的精准日活；
• 速度层：实时消费今日用户登录行为，算出今天实时新增日活；
• 服务层展示：总日活 = 昨日精准日活 + 今日实时新增日活；既能看实时在线人数，又保证历史数据绝对准确。

Lambda 架构优缺点

优点

1. 完美兼顾实时性 + 准确性；
2. 数据不可变、可重放，容错极强，数据出错可全量重跑修复；
3. 高吞吐，支撑 PB 级大数据；
4. 解耦设计，离线、实时任务互不影响；
5. 适合大屏实时报表、用户画像、交易统计、IoT 监控。

缺点

1. 两套逻辑重复开发：同一套统计逻辑，要写一份离线 SQL、一份实时 Flink 逻辑，维护成本高；
2. 双链路部署、调优、监控，架构复杂；
3. 存储、计算资源开销翻倍；
4. 两层结果对齐、口径统一容易出 BUG。

适用场景 & 不适用场景

适合

• 企业实时数据大屏、运营报表；
• 电商交易、支付风控实时统计；
• IoT 设备实时监控 + 历史回溯；
• 用户行为分析、画像标签。

不适合

• 小数据量、业务简单、无需实时；
• 成本敏感、不想维护两套计算逻辑。

衍生架构：Kappa 架构

为了解决 Lambda 两套代码重复的问题，诞生 Kappa 架构：

• 不再分批处理 + 速度层，统一只用流式计算；
• 全量历史数据也当成流回放，用同一套 Flink 逻辑计算；
• 一套代码搞定离线 + 实时，架构更简单，但精准度、容错性不如原生 Lambda。