kappa和lambda对比

首先我们会详细的讲解这两种架构，实现这两种架构的技术工具，还有就是如何决策使用这两种架构。

如何构建一个实时处理系统架构一直争论不断。一个好的实时处理系统必须是容错和可升级的。必须支持批量和增量的更新，必须可扩展。

在这些讨论中一个重要的里程碑是，storm的创始人，Nathan Marz，描述了我们目前所了解的lambda架构。Lambda架构目前已经有很多使用案例，实时上大量的公司都在使用，比如Yahoo和Netflix。当然，lambda架构也并不是得到的全是赞美，也有一些批判，就是它带来了编码的负担。( 原英：But of course, Lambda is not a silver bullet and has received some fair criticism on the coding overhead it can create.)

在2014年夏天，LinkedIn的Jay Kreps发表了一篇文章描述了Kappa架构，解决了一些Lambda架构的陷阱。Kappa架构并不是Lambda架构的替代，因为有些Lambda架构并不适合迁移到Kappa架构上去。

对于一个给定的案例，准确的评估哪种架构师最好的是很有挑战性的，错误的设计决策可能对数据分析项目的实施产生严重的影响。

现在，就深入细节去了解两种数据处理架构。

1

lambda架构

Lambda架构有三个层面组成：batch，speed，serving。

Batch层面有两个主要的任务：

1.管理历史数据。

2.重新结算结果，例如重新训练模型。

Batch层接受新的数据，将新的数据和历史数据进行合并，然后重新计算结果。Batch层计算了所有的数据，这使得系统能产生相对精确的结果。然而，由于计算时间比较久，使的结果延迟也会比较大。

Speed层主要提供低延迟，近实时的计算结果。Speed层接收数据，增量更新batch层的结果。由于speed层的增量算法，计算代价被极大减少。

Serving用batch层和speed层计算的结果提供多样的查询。

2

kappa架构

创建kappa架构的一个最重要的动机是避免维护batch和speed层两份独立的代码。一个核心的思想就是用一个单独的流处理引擎处理实时的计算和连续不断的数据的重复计算。代码的更改对结果影响很大，所以数据必须重新计算。结果kappa架构的组成只有两个部分：stream processing和serving。流处理层运行流处理任务。运行一个流处理作业以启用实时数据处理。仅仅当流处理作业更改了一些代码之后才会进行数据的重新处理。可以通过重启一个梗概代码后的流处理作业去处理所有以前的数据。

Serving层也是提供数据查询的。