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

最新推荐文章于 2024-07-28 06:30:00 发布

jarckv

最新推荐文章于 2024-07-28 06:30:00 发布

阅读量337

点赞数 5

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

本文链接：https://blog.csdn.net/jarckv/article/details/138901185

版权

程序员专栏收录该内容

59 篇文章 0 订阅

订阅专栏

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

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

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

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）停止老的作业，删除老的结果表。