目标
市场上的许多玩家已经建立了成功的MapReduce工作流程来每天处理以TB计的历史数据。但是谁愿意等待24小时才能获得最新的分析结果？这篇博文将向您介绍旨在利用批处理和流处理方法的Lambda架构。我们将利用Apache Spark（Core，SQL，Streaming），Apache Parquet，Twitter Stream等实时流数据快速访问历史数据。还包括清晰的代码和直观的演示！
简史
Apache Hadoop的丰富历史始于2002年。Hadoop由Doug Cutting创建，Doug Cutting是Apache Lucene（一个被广泛使用的文本搜索库）的创建者。Hadoop起源于Apache Nutch，一个开源的网络搜索引擎，它本身就是Lucene项目的一部分。它在10年前成为一个独立的项目。
因此，大量客户实施了有效的基于Hadoop的M/R处理管道。现实生活中有一些很好的例子：
Oozie编排的工作流程每天运行并处理高达150 TB的数据以生成分析结果
bash管理的工作流程每天运行并处理高达8 TB的数据以生成分析结果
现状
商业现实已经发生了变化，所以现在更快做出的决定更有价值。除此之外，技术也在不断发展。Kafka，Storm，Trident，Samza，Spark，Flink，Parquet，Avro，Cloud providers等都是工程师和企业广泛采用的流行语。
因此，现代基于Hadoop的M/R管道（使用Kafka，Avro和数据仓库等现代二进制格式，即Amazon Redshift，用于临时查询）。
这看起来相当不错，但它仍然是一种传统的批处理方式，具有所有已知的缺点，主要原因是客户端的数据在批处理花费大量时间完成之前的数据处理时，新的数据已经进入而导致数据过时。
Lambda架构
Nathan Marz针对通用的，可扩展的和容错的数据处理架构提出了术语Lambda Architecture。它是一种旨在通过利用批处理和流处理这两者的优势来处理大量数据的数据处理架构。
我强烈建议阅读Nathan Marz的书，因为它从提出者的角度提供了Lambda Architecture的完整表述。
图层
从宏观角度看，它的处理流程如下：
所有进入系统的数据都被分配到批处理层和速度层进行处理。批处理层管理主数据集（一个不可变的，仅可扩展的原始数据集）并预先计算批处理视图。服务层对批处理视图进行索引，以便可以在低延迟的情况下进行点对点查询。速度层只处理最近的数据。任何传入的查询都必须通过合并来自批量视图和实时视图的结果来得到结果。
焦点
许多工程师认为Lambda Architecture是全部关于这些层次和定义的数据流的，但Nathan Marz在他的书中将重点放在其他重要方面，如：
思考的分布式
避免增量架构
强制数据不可变
创建重新计算算法
数据的相关性
如前所述，任何传入查询都必须通过合并来自批量视图和实时视图的结果来得到答案，因此这些视图需要可合并性。需要注意的一点是，实时视图是以前的实时视图和新数据增量的函数，因此可以使用增量算法。批处理视图是所有数据的函数，因此应该在那里使用重算算法。
权衡
我们生活中的每一件事都是一种折衷，而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或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。