大数据技术4：Lambda和Kappa架构区别_lambda架构和kappa架构区别(1)

2401_84183033

于 2024-05-11 16:50:22 发布

阅读量316

点赞数 4

分类专栏：程序员文章标签：大数据面试学习

本文链接：https://blog.csdn.net/2401_84183033/article/details/138722005

版权

程序员专栏收录该内容

124 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

1 、Lambda 架构（融合批处理和实时处理）

Lambda 架构解决了将实时处理和批处理相结合以有效处理大数据工作负载的挑战。它采用混合方法，利用批处理和流处理来提供准确和最新的见解。Lambda 架构的核心是不可变数据的概念。所有传入的数据都以仅追加的方式捕获和存储，从而创建未更改的历史记录。

随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。

Lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。

Lambda 架构总共由三层系统组成：批处理层（Batch Layer），速度处理层（Speed Layer），以及用于响应查询的服务层（Serving Layer）。

批处理层 ：在批处理层中，以面向批处理的方式处理大量历史数据。数据从数据源引入、转换并存储在批处理系统（如 Apache Hadoop 或 Apache Spark）中。然后，转换后的数据将存储在批处理服务层中，在该图层中对其进行索引并使其可查询。
速度处理层 ：速度层处理实时数据处理。它近乎实时地处理传入的数据流并生成增量更新。然后将这些更新与批处理图层的结果合并，以提供统一的数据视图。速度层通常利用流处理框架，如Apache Storm或Apache Flink。速度层通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
**服务层：**服务层用作查询和可视化数据的访问点。它结合了批处理层和速度层的结果，并提供一致的数据视图。像Apache HBase或Apache Cassandra这样的技术通常用于存储和提供该层中的数据。

Lambda 架构优点：

它通过跨多个层使用复制的数据来提供容错能力，从而确保数据可用性和弹性。该体系结构还支持可扩展的处理，因为每一层都可以独立扩展以处理不断增加的工作负载。此外，批处理和实时处理的分离允许有效的资源利用，因为批处理计算可以在更大的时间窗口上执行。

Lambda 架构缺点：

虽然 Lambda 架构使用起来十分灵活，并且可以适用于很多的应用场景，但在实际应用的时候，Lambda 架构也存在着一些不足，主要表现在它的维护很复杂。

（1）同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。

（2）资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）

2 、Kappa 架构（简化实时处理）

Kappa 架构通过专注于流处理，提供了 Lambda 架构的简化替代方案。它包含不可变数据流的概念，无需维护单独的批处理层。Kappa流行的主要原因在于Kafka和Flink的兴起。Kafka不仅起到消息队列的作用，也可以保存更长时间的历史数据，以替代Lambda架构中批处理层数据仓库部分。

Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

在 Kappa 架构中，所有数据都作为无限的事件流引入和处理。数据流经系统并进行实时处理，从而实现近乎即时的洞察力。Kappa 架构的核心组件包括：

**流引入：**从各种源连续引入数据并存储在事件日志中，例如 Apache Kafka。事件日志充当持久、容错的存储机制，可保留事件的完整历史记录。
**流处理：**流处理层使用事件日志中的数据，应用实时计算，并生成所需的输出。像Apache Kafka Streams或Apache Flink这样的技术可用于处理和分析。
**输出服务：**处理后的数据可通过各种输出通道访问，例如实时仪表板、API 或数据接收器，以供进一步分析或使用。

Kappa架构有几个优点。通过专注于流处理，它简化了整体系统设计并降低了操作复杂性。该架构提供低延迟处理，因为数据近乎实时地处理，无需批量计算。它还在数据一致性方面提供了简单性，因为不需要同步和合并来自不同层的数据。

但是，在采用 Kappa 架构时需要牢记一些注意事项。由于所有数据都是实时处理的，因此如果没有额外的组件或流程，就没有对批处理或历史分析的固有支持。在处理某些需要分析大型历史数据集的用例时，此限制可能会带来挑战。此外，对连续流处理的依赖引入了对流处理框架的性能和可伸缩性的依赖。

Kappa 架构的重新处理过程：

重新处理是人们对 Kappa 架构最担心的点，但实际上并不复杂：

（1）选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如 Kafka，可以保存全部历史数据。

（2）当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。

（3）当新作业赶上进度后，应用切换数据源，读取 2 中产生的新结果表。

（4）停止老的作业，删除老的结果表。