现在对于实时大数据计算有不同的架构可以选择。现在不仅仅有Lambda，着这里我将谈论两种架构，结合相关案例讨论他们的不同。

实时计算系统的要求

在开始讨论架构之前，我们先讨论一下在大数据里领域实时计算系统的要求。

最明显的要求的就是数据在不断运动中，换句话说，数据是连续的、无边界的。当数据事件发生时，你就可以进行分析。如果你对当前的数据进行分析，并且需要很低的延迟，那么你很可能需要实时计算系统。

当我们讨论大数据的时候，我们经常期望数据的大小、产生速度、数据的类型是有限度的。在实时数据计算时，我们经常需要系统的伸缩性、容错性、可预测性来解决流数据不理想问题。

新数据时代新架构

为了满足这些需求产生了新的架构，换句话说需求是创新之母。
Nathan Marz提出的Lambda架构是现在进行实时处理的常见架构。它设计的目的是以低延迟处理和更新数据、支持线性扩展和容错机制。

image002.png

它显著的特点是数据即进入批处理层(batch layer)也进入speed layer。
对于批处理层，数据到达时先进行存储，适时计算批处理结果视图。当然批处理计算以一定间隔触发，计算的数据范围可以从几小时到几年。

speed layer用于计算实时视图的，是批处理层的补充。

一个复杂的查询可能即从批处理视图又从实时视图中获取结果，将以最优的方式组合两类结果。批处理的计算流程可能包含更加复杂、计算成本更高的规则，数据结果质量更高，而实时视图可以给用户最新的计算结果。随着时间的流逝，实时计算的数据会过期，会被批处理计算结果取代。

这个架构的另一个好处是当用户改变计算规则时，可以重新计算历史数据。

下面，我们将讨论Kappa架构。
Kappa架构是由Jay Kreps提出。这种架构只关注流式计算，并不是取代Lambda架构，除非完全满足你的使用案例。对于这种架构，数据以流的方式被采集过来，实时层(Real-time Layer)将计算结果放入服务层(Serving Layer)以供查询。

image004.png

这种思路是将实时数据处理与数据的持续从处理集成到单一流处理引擎上。对的，就是在数据流上重新处理与计算。这就要求采集的数据流可以从新从特定位置或全部快速被回放。如果计算逻辑被更改，会新起一个流式计算，将以前的数据快速回放，重新计算，将新结果保存到服务层。

这种架构试图只维护一份代码，简化Lamabda架构中既要维护批处理也要维护speed Layer层的代码。另外，结果的查询只需要在单一的服务层即可，不需要批处理与实时计算结果都得查询一遍。

这种架构的复杂性在于引入了处理流数据的一些问题，这些问题在批处理中反而比较容易解决，例如处理重复数据，交叉引用事件，维护操作顺序等。

没有解决所有问题的方案

许多实时案例适用于Lambda架构，同样kappa也有适用领域。如果流处理与批处理分析流程比较统一，用Kappa比较合适。然而在其他一些场景中，需要对整个数据集进行批量处理而且优化空间较低，使用Lambda架构性能会更好，实现也更简单。

还有一些比较复杂的场景，批处理与流处理产生不同的结果（使用不同的机器学习模型，专家系统，或者实时计算难以处理的复杂计算），可能更适合Lambda架构。