Kappa架构与Lambda架构比较

目标

市场上的众多参与者已经开发出了成熟的MapReduce方法来每天处理海量的历史数据（以TB计）。然而，谁能忍受需要等待24小时才能获得最新的分析结果呢？本文将为您介绍一种利用批处理和流处理技术构建的Lambda架构设计。该方案不仅支持高效的实时数据分析功能（包括Apache Spark的核心功能、SQL查询以及流式数据处理），还结合了实时存储格式如Apache Parquet和Twitter Stream等特性，能够快速访问历史数据。此外，并附带了详尽的代码示例和直观的操作演示！

简史

自2002年以来, Apache Hadoop便累积了丰富的历史. Hadoop由Doug Cutting于1999年创立, 并作为Apache Lucene项目的早期发展的一部分而存在. 其根源可以追溯至Apache Nutch, 经过13年的演进后, 在2013年正式成为独立项目.

基于此，在实际应用中相当数量的客户实现了高效的数据流处理系统。在现实生活中有几个典型的案例展示了该方法的成功应用。

Oozie编排的工作流程每天运行并处理高达150 TB的数据以生成分析结果

bash管理的工作流程每天运行并处理高达8 TB的数据以生成分析结果

现状

商业环境已经出现了重大转变，在这一背景下作出迅速决策的价值更加凸显了。与此同时，在技术领域正经历着持续革新。包括但不限于Kafka、Storm、Trident、Samza、Spark、Flink、Parquet、Avro以及云服务提供商等在内的技术都被广泛认可为工程实践中的重要工具。

基于Hadoop的MapReduce管道（采用Kafka、Avro和现代二进制格式如Amazon Redshift进行数据处理，并主要用于临时查询操作）

表现令人印象深刻。
然而它仍属于传统批次处理机制。
尽管如此却存在众所周知的局限性。
其主要原因在于，在开始批次处理之前
客户端系统需要完成所有的数据预处理工作
而此时后续的新数据及时接入导致原有数据 stale（过时）。

Lambda架构

Nathan Marz提出了一种通用、可扩展且容错的数据处理架构，并称之为Lambda Architecture.该架构旨在通过结合批处理与流处理的优势来高效地管理大规模数据.

值得推荐的是Nathan Marz所著的书籍[https://www.amazon.com/Big-Data-Principles-practices-scalable/dp/1617290343/][因为该书深入探讨了 Lambda架构，并且从提出者的角度提供了完整的阐述。]

图层

从宏观角度看，它的处理流程如下：

所有进入系统的数据均被分配至批处理级与实时级进行预处理与分析工作

焦点

许多工程师普遍认为Lambda Architecture涉及这些层次和数据流的详细定义。
然而，在他的著作中，
例如，在其著作中，

思考的分布式

避免增量架构

强制数据不可变

创建重新计算算法

数据的相关性

如前述内容所示，在接收任意输入查询时都需要将来自批量视点与实时视点的数据结果进行整合以得出答案因而这些视点应具备可整合性值得注意的是当前状态下的实时系统基于之前的实时系统以及新增的数据量因此能够采用增量式算法而批量处理系统则基于全部数据因而应当在该系统中执行全量计算

权衡

在我们的日常生活中，每一个行动都涉及权衡取舍，在Lambda架构中也是如此。在实际应用中，我们往往需要应对几种关键的权衡

完全重新计算与部分重新计算

在某些情况下，可以使用Bloom过滤器来避免完全重新计算

重算算法与增量算法

使用增量算法强烈的诱惑力很大。然而，在遵循指引的情况下我们必须采用重新计算算法。尽管如此，在这种情况下这种方法变得极为复杂且耗时长。

加法算法与近似算法

该架构与加法算法之间有着良好的协同作用。由此可见，在这种情形下采用近似算法是一种值得考虑的选择。例如，在计算不同元素数量的问题中可以采用HyperLogLog方法等。

实现

不同方法能够实现Lambda体系结构。由于每个层的底层解决方案都是不可知的。每层都必须基于底层实现特定的功能。这种做法能够帮助做出更好的选择并避免过度决策：

批处理层：一次写入，批量读取多次

服务层：随机读取，不随机写入; 批量计算和批量写入

速度层：随机读取，随机写入; 增量计算

Kappa架构

如前所述，在 Lambda 架构中存在某些局限性。尽管 LinkedIn 的 Jay Kreps 通过实践与洞察对 Lambda 架构进行了深入分析，并提出了 Kappa 架构以弥补其不足。Kappa 架构的主要特点在于它摒弃了 Lambda 架构中对批处理系统与流计算系统同时维护的需求，并通过设计简化了架构复杂度。具体而言，在 Lambda 架构中必须同时维护两套独立运行于批处理与实时计算系统的代码，并且这两套代码必须产生完全一致的结果。因此，在设计类似的数据处理系统时会面临一个问题：即为何不能将流计算系统扩展到能够解决这些问题？为何不能让流计算系统承担起数据全量处理的任务？由于流计算天然具备分布式特性从而具有良好的扩展性特征，请问能否通过增加并发度来有效管理海量的历史数据？Jay Kreps基于上述问题提出的解决方案即为 Kappa 架构——一种更为简洁高效的替代方案。Kappa架构 简化了Lambda架构的核心逻辑。具体来说，在 Kappa 架构中删除了传统 Lambda 架构中的批处理系统组件，并采用了一种全新的设计思路：通过将数据以流式传输的方式快速传递给相应的处理节点完成运算任务。

那如何用流计算系统对全量数据进行重新计算，步骤如下：

1、用Kafka或类似的分布式队列保存数据，需要几天数据量就保存几天。

在进行全量计算时，在完成所有操作后会自动触发重试功能吗？

3、当新的实例完成后，停止老的流计算实例，并把老的一引起结果删除。

一个典型的Kappa架构如下：

与Lambda架构相比，在Kappa架构中，仅在必要时会对历史数据执行重复计算，并且实时与批量处理采用相同的代码逻辑。可能会有人质疑流式处理在面对历史数据时的高吞吐量是否会导致性能不足，但通过控制新增实例的同时性数量，这种性能瓶颈是可以得到缓解的。

Kappa架构的核心思想包括以下三点：

采用Kafka或类似的分布式队列系统存储数据，在此情况下根据你所需的天数来决定存储的时间。

在进行全量重新计算的情况下，在新数据源上启动一个新的流计算实例，并将结果输出至新的存储位置。

当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。