Kappa:比Lambda更好更灵活的实时处理架构

为了进一步探讨这种批处理和实时处理有效整合在同一系统的架构，我们将在今天的文章中分析Lambda三层结构模型的适用场景，同时暴露出Lambda架构一个最明显的问题：它需要维护两套分别跑在批处理和实时计算系统上面的代码，而且这两套代码需要产出一致的结果。根据对此缺点的分析，我们引出当时还在LinkedIn的大神Jay Kreps提出的Kappa架构，本文会对Kappa架构原理进行介绍，并讨论两个架构的优缺点，最后给出一个Kappa架构的案例分析。

Lambda架构回顾

Lambda架构的核心思想是把大数据系统拆分成三层：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer负责数据集存储以及全量数据集的预查询。Speed Layer主要负责对增量数据进行计算，生成Realtime Views。Serving Layer用于响应用户的查询请求，它将Batch Views和Realtime Views的结果进行合并，得到最后的结果，返回给用户。

图1给出了Lambda的整体架构图：

Kappa架构上述提到，为了将批处理和实时处理相结合，Lambda设计了Batch Layer和Speed Layer两层结构，分别用于批处理和实时计算，因此需要维护两套分别跑在批处理和实时计算系统之上的代码。面对这个问题，有人会有这样的疑问，为什么不用流计算系统来进行全量数据处理从而去除Batch Layer这一层?

可能有这样回答：流计算给人的印象是对一些流式的、临时的数据进行计算，将结果保存后就将原始数据丢弃了，因此它不适合用来处理历史数据。其实这种答案并不完全正确，对于基于Lambda架构实现的Storm框架确实是这样的，但对于后来出现的Spark并不是。

Storm是在2011年7月开源的，Spark是在2012年之后逐渐为人们所知的，因此在Nathan Marz设计Lambda架构的时候，当时还并没有一个框架既可以用于离线处理，又可以进行实时计算。但随着Spark技术的发展，这一想法成为了可能，Spark本身可以用于批处理，而构建在Spark之上的Spark Streaming又可以用于实时计算，因此利用一套系统来应对批处理和实时计算相结合的业务完全是可行的。

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

• 用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
• 当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
• 当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。
  

Kappa的架构图如图2所示：

和Lambda架构相比，在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。或许有些人会质疑流式处理对于历史数据的高吞吐量会力不从心，但是这可以通过控制新实例的并发数进行改善。

上面架构图中，新老实例使用了各自的结果存储，这便于随时进行回滚，更进一步，假如我们产出的是一些算法模型之类的数据，用户还可以同时对新老两份数据进行效果验证，做一些A/B test或者使用bandit算法来最大限度的使用这些数据。

两个架构的对比优缺点对比

如上表所示，Kappa架构相对来说有更多的优点，目前也被更多的厂商用于构建商业项目。

第一，Lambda架构不仅需要维护两套分别跑在批处理和实时计算系统上面的代码，还需要批处理和全量计算长时间保持运行;而Kappa架构只有在需要的时候才进行全量计算。

第二，Kappa架构下可以启动很多个实例进行重复计算，因此在需要对一些算法模型进行调优时，Kappa架构下只需要更改一套系统的参数即可，并且允许对新老数据进行效果比对;但是在Lambda架构下，需要同时更改流计算系统算法模型和批处理系统算法模型，调参过程相对比较复杂。

第三，从用户开发、测试和运维的角度来看，Kappa架构下，开发人员只需要面对一个框架，开发、测试和运维的难度都会相对较小，这是个非常重要的优点。