[TOC] ## Lambda **Lambda架构分为三层** ### 批处理层 (Batch Layer) 存储数据集， Batch Layer在数据集上预先计算查询函数，并构建查询所对应的 View。Batch Layer可以很好地处理离线数据，但有很多场景数据是不断实时生成且需要实时查询处理，对于这种情况， Speed Layer更为适合。 该层负责管理主数据集。主数据集中的数据必须具有以下三个属性： 1. 数据是原始的。 2. 数据是不可变的。 3. 数据永远是真实的 ### 加速层 (Speed Layer) Batch Layer处理的是全体数据集，而 Speed Layer处理的是最近的增量数据流。 Speed Layer 为了效率，在接收到新的数据后会不断更新Real-time View, 而Batch Layer 是根据全体离线数据集直接得到Batch View。 Speed Layer对数据进行计算并生成Realtime View, 其主要区别在于： 1. Speed Layer处理的数据是最近的增量数据流， Batch Layer处理的全体数据集。 2. Speed Layer为了效率，接收到新数据时不断更新Realtime View, 而 Batch Layer根据全体离线数据集直接得到 Batch View ### 服务层 (Serving Layer) Serving Layer 用于合并 Batch View和 Real-time View中的结 果数据集到最终数据集 架构图  <br/> **核心思想:** 将数据处理分为实时处理和批量处理两个路径，分别得到实时结果和离线结果，然后将结果合并。 * **优点:** * 可以快速响应实时数据，满足低延迟需求。 * 支持历史数据的离线分析，提供全面的数据洞察。 * 适用于对实时性和历史数据都有需求的场景。 * **缺点:** * 架构复杂，需要维护两条数据处理路径，增加了开发和维护的难度。 * 存在数据冗余，实时和离线处理可能需要存储多份相同的数据。 * **适用场景:** 需要兼顾实时和离线数据处理，且对延迟要求不高的场景，例如日志分析、报表生成等 * **典型技术:** - BatchLayer:可以选用MR、Spark等计算引擎 - SpeedLayer:可以选用Storm、Flink、SparkStreaming - ServingLayer：可以选用Mysql、Redis、HBase等数据库或缓存系统供用户查询（将两个View的合并结果导入供查询） ## 与 Kappa 架构对比 | 对比内容 | Lambda 架构 | Kappa 架构 | | --- | --- | --- | | 复杂度与开发、维护成本 | 需要维护两套系统(引擎)，批处理层采用Hadoop,加速层采用Spark，复杂度高，开发、维护成本高 | 只需要维护一套系统(引擎),实时层采用Flink，复杂度低，开发、维护成本低 | | 计算开销 | 需要一直运行批处理和伪实时计算，计算开销大 | 必要时进行全量计算，计算开销相对较小 | | 实时性 | 满足实时性，属于伪实时，在加速层采用Spark只是粒度细了一些 | 满足实时性 | | 数据处理能力 | 批式全量处理，吞吐量大，历史数据处理能力强 | 流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱 |