写在前面

本文隶属于专栏《100个问题搞定大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和文献引用请见100个问题搞定大数据理论体系

解答

Kappa架构和Lambda架构有着或多或少的相似之处，只是出于简化考虑，去掉了批处理层，只保留了快速处理层。
其主要思想是避免从头开始进行批处理层计算，尝试把这些计算完全放在实时计算或快速处理层。
Lambda架构的一个缺点是必须编码并运行同样的逻辑两次，但Kappa架构避免了这个问题。
Kappa架构目前来说必须通过Kafka才能实现。

补充

Lambda架构的不足

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

使用 Lambda 架构时，架构师需要维护两个复杂的分布式系统，并且保证他们逻辑上产生相同的结果输出到服务层中。

举个例子吧，我们在部署 Lambda 架构的时候，可以部署 Apache Hadoop 到批处理层上，同时部署 Apache Flink 到速度层上。

我们都知道，在分布式框架中进行编程其实是十分复杂的，尤其是我们还会针对不同的框架进行专门的优化。

所以几乎每一个架构师都认同，Lambda 架构在实战中维护起来具有一定的复杂性。那要怎么解决这个问题呢？

我们先来思考一下，造成这个架构维护起来如此复杂的根本原因是什么呢？

维护 Lambda 架构的复杂性在于我们要同时维护两套系统架构：批处理层和速度层。

我们已经说过了，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延时性。

那我们能不能改进其中某一层的架构，让它具有另外一层架构的特性呢？

例如，改进批处理层的系统让它具有更低的延时性，又或者是改进速度层的系统，让它产生的数据视图更具准确性和更加接近历史数据呢？

Kappa 架构（Kappa Architecture），便是在这样的思考下诞生的。

Kappa 架构的诞生过程

Kappa 架构是由 LinkedIn 的前首席工程师杰伊·克雷普斯（Jay Kreps）提出的一种架构思想。

克雷普斯是几个著名开源项目（包括 Apache Kafka 和 Apache Samza 这样的流处理系统）的作者之一，也是现在 Confluent 大数据公司的 CEO。

克雷普斯提出了一个改进 Lambda 架构的观点：我们能不能改进 Lambda 架构中速度层的系统性能，使得它也可以处理好数据的完整性和准确性问题呢？

我们能不能改进 Lambda 架构中的速度层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据呢？

他根据自身多年的架构经验发现，我们是可以做到这样的改进的。

Apache Kafka 这样的流处理平台是具有永久保存数据日志的功能的。

通过平台的这一特性，我们可以重新处理部署于速度层架构中的历史数据。

以 Apache Kafka 为例来讲述整个Kappa架构的过程

部署 Apache Kafka，并设置数据日志的保留期（Retention Period）。
这里的保留期指的是你希望能够重新处理的历史数据的时间区间。
例如，如果你希望重新处理最多一年的历史数据，那就可以把 Apache Kafka 中的保留期设置为 365 天。
如果你希望能够处理所有的历史数据，那就可以把 Apache Kafka 中的保留期设置为“永久（Forever）”。
如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。
我们需要做的就是重新启动一个 Apache Kafka 作业实例（Instance）。
这个作业实例将重头开始，重新计算保留好的历史数据，并将结果输出到一个新的数据视图中。
我们知道 Apache Kafka 的底层是使用 Log Offset 来判断现在已经处理到哪个数据块了，所以只需要将 Log Offset 设置为 0，新的作业实例就会重头开始处理历史数据。
当这个新的数据视图处理过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到从新的数据视图中读取。
停止旧版本的作业实例，并删除旧的数据视图。这个架构就如同下图所示。

Kappa架构