Day38-04｜19.3.1 Lambda 架构对大数据处理系统的理解：用两条计算路径兼顾实时与准确

对应教材目录：第 19 章 大数据架构设计理论与实践 → 19.3 Lambda 架构 → 19.3.1 Lambda 架构对大数据处理系统的理解

学习目标：理解 Lambda 架构提出的背景和基本思想；掌握批处理层、速度层、服务层以及不可变数据的关系；理解实时近似结果与批量最终结果如何协同；能够判断 Lambda 架构适合解决什么问题，以及它为什么会增加维护复杂度。

一、Lambda 架构解决的核心矛盾

大数据系统通常同时面临两个目标：一方面，业务希望尽快得到结果，例如实时风控、设备告警、推荐和监控；另一方面，系统又需要依靠完整数据进行高准确度计算、修正迟到事件和重建历史结果。单一批处理架构准确但延迟高，单一流处理架构低延迟但状态复杂、重算困难。

Lambda 架构的基本思想是使用两条计算路径：批处理层对全量数据进行准确计算，速度层对最新数据进行低延迟处理，服务层合并两者结果向外提供查询。

                         +--> 批处理层 --> 批视图
                        /                    |
不可变数据集 -> 数据流                     +--> 服务层 --> 查询结果
                        \                    |
                         +--> 速度层 --> 实时视图

这里的关键不是“同时使用批处理和流处理”这么简单，而是建立一种结果语义：速度层负责降低新数据到达后的等待时间，批处理层负责最终准确性和历史重算，服务层在查询时把两类结果合并起来。

二、不可变数据集是基础

1. 事实数据优先

Lambda 架构通常把原始事件视为不可变事实。事件一旦写入，尽量不直接修改，而是通过新事件表达修正、撤销或补偿。这样可以重新计算历史结果，也能在规则或算法变化时重建视图。

2. 事件结构

一个可重算的事件至少应包含事件 ID、事件类型、业务主体、事件时间、产生来源、版本、有效载荷和追踪标识。

Event = id + type + entityId + eventTime + source
        + schemaVersion + payload + traceId

事件数据需要持久化、分区和备份。数据保存期限要结合业务和合规要求，不能为了追求“永不删除”而忽视隐私和成本治理。

3. 为什么不直接覆盖结果

如果只保存当前汇总结果，出现业务规则错误、代码缺陷、迟到事件或数据修复时，系统无法可靠重建历史。不可变事件允许批处理重新运行，代价是存储成本和计算成本增加，需要通过归档、压缩和生命周期管理控制。

三、批处理层

1. 批处理层职责

批处理层定期读取完整数据集，执行全量或增量计算，生成高准确度的批视图。它通常不追求毫秒级延迟，而关注正确性、可重复性、可重算和大吞吐。

2. 批处理过程

不可变事件
   -> 分区读取
   -> 清洗、去重、关联
   -> 业务规则与聚合
   -> 批视图/索引/数据集市
   -> 质量校验和版本发布

批任务要支持断点、重试、依赖管理、数据质量校验和结果版本。任务失败后应能重跑，不应依赖人工修改中间表。

3. 批视图的特点

批视图通常是某个时间点对完整数据集的计算结果，例如用户历史累计消费、设备长期健康指标和月度销售汇总。批视图应标明计算时间、数据范围、代码版本、规则版本和质量状态，方便追溯。

四、速度层

1. 速度层职责

速度层接收最新事件，进行低延迟增量计算，生成实时视图。它不一定能看到全部历史数据，也可能暂时受到乱序、重复、迟到和故障影响，因此结果通常被称为近实时或暂时结果。

2. 实时处理要素

速度层需要处理事件时间、窗口、状态、去重、背压、checkpoint、重试和故障恢复。状态服务应支持持久化和迁移，不能把关键业务状态只放在单个进程内存中。

3. 速度视图的作用

速度视图用于补充批视图尚未包含的新数据。在批处理周期内，用户查询可以看到“最近事件带来的增量”。当批处理完成并发布新批视图后，速度视图中已经被批处理覆盖的部分应被清理、截断或通过版本水位排除。

五、服务层与结果合并

服务层向应用提供查询接口，不应让每个业务应用自行理解批视图和实时视图的合并逻辑。它需要根据查询时间、实体、版本水位和数据范围，合并两类结果。

查询请求
   |
   +--> 批视图：截至 batchWatermark 的准确结果
   |
   +--> 实时视图：batchWatermark 之后的增量
   |
   +--> 合并、去重、冲突处理
   |
返回统一结果 + 新鲜度/版本信息

1. 合并方式

对于计数和金额，可以使用批结果加速度层增量；对于状态和去重结果，需要根据事件 ID、版本和时间范围合并；对于复杂模型结果，可能需要采用优先级、覆盖或独立服务策略。

2. 一致性边界

查询结果应说明数据的新鲜度和准确度。用户看到的实时结果可能暂时没有包含迟到事件，批处理完成后可能被修正。高风险账务不应盲目使用未确认的速度层结果，应根据业务设置确认和对账流程。

六、批处理与速度层之间的协调

1. 批处理水位

批处理完成并发布的时间点可以作为批处理水位。速度层只负责水位之后的事件，避免同一事件在两条路径重复计算。

2. 事件去重

事件 ID、业务唯一号和版本必须稳定。批处理和速度层可以使用相同的去重规则，但不能依赖两个系统各自维护且不一致的去重表。

3. 视图切换

批视图发布时应采用版本化和原子切换，避免服务层读取到部分更新结果。可以通过新版本目录、元数据指针或双缓冲方式发布。

4. 迟到事件和修正

迟到事件可能已经被速度层处理，也可能在批处理之后才到达。系统需要确定迟到窗口、重算范围和修正通知。对外账务和监管指标要保留修正记录，不能静默改变历史结果。

七、Lambda 架构的典型数据流

事件源
  |
  +--> 不可变数据存储 --------------------------+
  |                                             |
  +--> 消息队列 -> 速度层 -> 实时视图             |
                                                v
                                  批处理层 -> 批视图
                                                |
                       批次水位、版本、质量状态
                                                v
                                      服务层合并查询
                                                |
                                         业务应用

事件源到不可变存储和消息队列的写入需要考虑一致性。若一边成功、一边失败，可能造成批处理和实时处理看到不同数据。常见做法包括可重放消息、日志型队列、统一采集层和补偿校验。

八、Lambda 架构中的质量与治理

1. 数据质量

批处理层可以进行全面质量校验，速度层要进行轻量快速校验。两者规则应尽量共享，但允许根据实时性采用不同层级。最终质量以批处理和对账结果为准。

2. 版本治理

应管理事件模式、批处理代码、流处理代码、业务规则、模型和视图版本。批处理和速度层使用不同版本会造成结果口径不一致，必须建立兼容和发布流程。

3. 安全治理

原始事件、批视图、实时视图和服务结果都需要权限。速度层状态、消息队列和临时缓存容易被忽略，必须纳入加密、租户隔离和审计。

九、Lambda 架构的适用场景

适合以下情况：

  • 既需要实时结果，又要求历史准确重算。
  • 原始事件可以长期保存或按合规期限保留。
  • 批处理结果是最终可信数据，实时结果主要用于快速响应。
  • 业务能够接受批处理和实时结果在短时间内存在差异。
  • 团队有能力维护两套计算逻辑和统一数据模型。

不适合所有场景。如果数据量很小、只需要简单实时计算，Lambda 会增加不必要复杂度；如果业务只接受严格实时且不需要历史重算，单一流处理可能更直接；如果团队无法承担两套代码和一致性治理，应该谨慎采用。

十、案例分析：实时用户画像系统

某内容平台需要实时更新用户兴趣标签，同时每天生成准确的长期画像。用户行为包括点击、收藏、关注、取消关注和停留时长。

采用 Lambda 架构：

  1. 所有行为事件写入不可变存储，并通过消息队列进入速度层。
  2. 速度层根据最近行为更新实时兴趣和短期热度，用于推荐排序。
  3. 批处理层每天读取完整事件，去重、修正迟到行为并计算长期画像。
  4. 服务层按批次水位合并长期画像与最新短期增量。
  5. 事件、标签、模型和规则均版本化，推荐服务记录使用的画像版本。
  6. 用户删除或撤回授权时，对原始事件、画像和缓存执行生命周期清理。
  7. 通过点击率、新鲜度、批流差异、延迟和重算一致性验证系统。

十一、案例题答题模板

回答 Lambda 架构题时，可以按以下顺序：

  1. 说明业务同时需要低延迟和高准确度。
  2. 设计不可变数据集，保证可重放和可重算。
  3. 说明批处理层的全量/增量计算和批视图。
  4. 说明速度层的实时处理、状态、窗口和实时视图。
  5. 说明服务层按水位合并、去重和冲突处理。
  6. 说明故障、迟到、重复、版本和质量校验。
  7. 说明安全、权限、生命周期和运维成本。
  8. 给出延迟、准确率、批流差异和恢复时间等指标。

十二、课后练习

练习 1

Lambda 架构为什么需要不可变数据集？

参考答案：不可变事件可以被重放和重新计算，支持迟到数据修正、规则变更、模型升级和历史结果重建；如果只保存覆盖后的汇总结果，出现错误时难以恢复和追溯。

练习 2

批处理层和速度层分别承担什么职责？

参考答案：批处理层读取完整数据，生成准确、可重算的历史视图；速度层处理最新事件，生成低延迟的增量视图，弥补批处理延迟。

练习 3

为什么服务层不能简单地把两个结果表相加？

参考答案：不同指标的合并规则不同，可能存在重复事件、状态覆盖、版本水位和迟到修正；服务层应依据实体、事件 ID、时间范围和业务语义进行合并。

练习 4

论文题：论“Lambda 架构在实时风控中的应用”。

参考答案要点：不可变交易事件、消息接入、速度层实时特征、批处理历史模型、服务层合并、迟到和重放、幂等、风控决策、审计、数据安全及实时性与准确性的权衡。

十三、今日复盘

  • 我能否解释 Lambda 架构解决的核心矛盾？
  • 我是否理解批处理层、速度层和服务层的职责？
  • 我能否画出不可变数据、批视图和实时视图的关系？
  • 我是否考虑水位、重复、乱序、迟到和视图切换？
  • 我能否说明 Lambda 架构的适用边界和维护成本？
  • 我能否在案例题中写出批流结果合并与验证指标？

Lambda 架构的核心结论是：以不可变数据为事实基础，用批处理获得最终准确性，用速度层获得低延迟，用服务层统一对外提供结果。它的代价是需要维护两条计算路径、处理结果一致性和版本治理，因此只有在实时与准确都重要时才值得采用。