Lambda架构
Nathan Marz针对通用的，可扩展的和容错的数据处理架构提出了术语Lambda Architecture。它是一种旨在通过利用批处理和流处理这两者的优势来处理大量数据的数据处理架构。
图层
从宏观角度看，它的处理流程如下：
所有进入系统的数据都被分配到批处理层和速度层进行处理。批处理层管理主数据集（一个不可变的，仅可扩展的原始数据集）并预先计算批处理视图。服务层对批处理视图进行索引，以便可以在低延迟的情况下进行点对点查询。速度层只处理最近的数据。任何传入的查询都必须通过合并来自批量视图和实时视图的结果来得到结果。
数据的相关性
如前所述，任何传入查询都必须通过合并来自批量视图和实时视图的结果来得到答案，因此这些视图需要可合并性。需要注意的一点是，实时视图是以前的实时视图和新数据增量的函数，因此可以使用增量算法。批处理视图是所有数据的函数，因此应该在那里使用重算算法。
权衡
我们生活中的每一件事都是一种折衷，而Lambda Architecture也不是一个例外。通常，我们需要解决一些主要的折衷：
- 完全重新计算与部分重新计算
- 在某些情况下，可以使用Bloom过滤器来避免完全重新计算
- 重算算法与增量算法
- 使用增量算法有很大的诱惑力，但根据指南我们必须使用重新计算算法，即使它使达到相同的结果变得更加困难。
- 加法算法与近似算法
- Lambda Architecture与加法算法很好地协作。因此，这是我们需要考虑使用近似算法的另一种情况，例如，HyperLogLog用于计数不同的问题等。
实现
有多种实现Lambda体系结构的方法，因为它对于每个层的底层解决方案都是不可知的。每一层都需要底层实现的特定功能，这可能有助于做出更好的选择并避免过度的决定：
- 批处理层：一次写入，批量读取多次
- 服务层：随机读取，不随机写入; 批量计算和批量写入
- 速度层：随机读取，随机写入; 增量计算
Kappa架构
正如前面提到的，Lambda Architecture有其优点和缺点，人们也划分成支持者和反对者两派。Kappa 架构是LinkedIn的Jay Kreps结合实际经验和个人体会，针对Lambda架构进行深度剖析，分析其优缺点并采用的替代方案。Lambda 架构的一个很明显的问题是需要维护两套分别跑在批处理和实时计算系统上面的代码，而且这两套代码得产出一模一样的结果。因此对于设计这类系统的人来讲，要面对的问题是：为什么我们不能改进流计算系统让它能处理这些问题？为什么不能让流系统来解决数据全量处理的问题？流计算天然的分布式特性注定其扩展性比较好，能否加大并发量来处理海量的历史数据？基于种种问题的考虑，Jay提出了Kappa这种替代方案。Kappa架构 简化了Lambda架构。Kappa架构系统是删除了批处理系统的架构。要取代批处理，数据只需通过流式传输系统快速提供：
那如何用流计算系统对全量数据进行重新计算，步骤如下：
1、用Kafka或类似的分布式队列保存数据，需要几天数据量就保存几天。
2、当需要全量计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个结果存储中。
3、当新的实例完成后，停止老的流计算实例，并把老的一引起结果删除。
一个典型的Kappa架构如下：
和Lambda架构相比，在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。或许有些人会质疑流式处理对于历史数据的高吞吐量会力不从心，但是这可以通过控制新实例的并发数进行改善。
Kappa架构的核心思想包括以下三点：
用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。