【笔记-软考】大数据架构-Lambda与Kappa架构对比

Author：赵志乾
Date：2024-07-28
Declaration：All Right Reserved！！！

1. 简介

        大数据系统架构的设计思想很大程度受技术条件和思维模式的限制；

        Lambda架构在提出初期面向小范围业务，直接将成熟离线处理技术(Hadoop)和实时处理技术(Storm)相结合，用View模型将二者处理后得到的输出结果结合起来，在服务层进行统一后，再开放给上层服务，是相当可行且高效的设计方式。

        而Kappa架构的作者对流式处理系统有着丰富的理论知识和使用经验，基于对流式计算的深入理解，Kappa架构在同一层内进行实时处理和离线处理。

2. 特性比对

对比内容	Lambda	Kappa
开发、维护成本	维护两套系统(引擎)，复杂度高，开发维护成本高	维护一套系统(引擎)，复杂度低，开发维护成本低
计算开销	一直运行批处理和实时计算，计算开销大	必要时进行全量计算，计算开销相对较小
实时性	满足实时性	满足实时性
历史数据处理能力	批式全量处理，吞吐量大，历史数据处理能力强	流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱

• 开发与维护成本：Lambda需要开发维护两套系统，一套负责离线的批处理计算，一般选择Hadoop作为批处理系统，并将处理结果保存到HBase，另一套需要进行实时流式计算，一般选择Storm、Spark作为流处理系统，计算结果保存到Redis中；在全量计算中，批处理系统还需长时间保持运行以保证离线运算结果的正确性，整体开发维护成本较高；而Kappa仅开发维护一套系统，其使用Kafka作为消息中间件，Flink作为流式计算系统，以数据并行和流水线方式执行任意流数据程序，且同时支持批处理和流处理，开发维护成本低；
• 计算开销：Lambda架构在计算时，需要让数据同时批处理和流处理层系统的运行，且两套系统都不能停机，计算开销大；而Kappa的数据存储只需面对流式计算，且只在必要时进行全量计算，计算消耗小；
• 实时性：Lambda架构的策略在于使用满足Monoid性质的数据View模型，对批处理层和速度层的输出进行统一管理，这样在新数据到达时，速度层可实时处理得到最新的View，然后和批处理层的View相结合，得到最新的实时结果；其优点是将实时处理变成了批处理和流处理结果的结合，稳定且计算成本可控；而Kappa架构的策略在于使用消息队列进行数据保存，采用并发计算；
• 历史数据处理能力：Lambda在设计上可以在批处理层对超大规模的历史数据进行批量计算，由于批处理层与速度层使用不同的计算系统，在进行批处理时速度层的实时计算不受影响；而Kappa在设计上使用了消息队列对数据进行缓存，其对数据量和历史数据回溯有性能的制约；

3. 架构选择

        Lambda和Kappa两种架构选择时，主要从业务需求、技术要求、系统复杂度、开发维护成本以及历史数据处理能力等维度考虑；

• 业务需求与技术要求：若对Hadoop、Spark、Storm等关键技术有强制性依赖，则应选择Lambda，若数据处理偏好于流式计算，又依赖Flink计算引擎，则应选择Kappa；
• 复杂度：若实时处理与离线处理的结果不能统一，则应选择Lambda，若算法模型参数变动频繁、或者算法模型支持同时执行批处理和流式计算，则应选择Kappa;
• 开发维护成本：Lambda需要更高的开发维护成本，适合有经济、技术和资源的开发者，而Kappa适合于不希望在开发维护上投入过多成本的开发者；
• 历史数据处理能力：若需频繁进行海量数据集进行分析，应选择Lambda，若始终使用小规模数据集，则应选择Kappa；