//
Lambda架构 vs Kappa架构 - CSDN博客
http://blog.csdn.net/post_yuan/article/details/52241252
Lambda 架构由Storm的作者Nathan Marz提出，其设计目的在于提供一个能满足大数据系统关键特性的架构，包括高容错、低延迟、可扩展等。其整合离线计算与实时计算，融合不可变性、读写分离和复杂性隔离等原则，可集成Hadoop, Kafka, Spark，Storm等各类大数据组件。
//
Kappa 架构
Kappa 架构是LinkedIn的Jay Kreps结合实际经验和个人体会，针对Lambda架构进行深度剖析，分析其优缺点并采用的替代方案。Lambda 架构的一个很明显的问题是需要维护两套分别跑在批处理和实时计算系统上面的代码，而且这两套代码得产出一模一样的结果。因此对于设计这类系统的人来讲，要面对的问题是：为什么我们不能改进流计算系统让它能处理这些问题？为什么不能让流系统来解决数据全量处理的问题？流计算天然的分布式特性注定其扩展性比较好，能否加大并发量来处理海量的历史数据？基于种种问题的考虑，Jay提出了Kappa这种替代方案。
那如何用流计算系统对全量数据进行重新计算，步骤如下：
1、用Kafka或类似的分布式队列保存数据，需要几天数据量就保存几天。
2、当需要全量计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个结果存储中。
3、当新的实例完成后，停止老的流计算实例，并把老的一引起结果删除。
一个典型的Kappa架构如下，
//
Kappa:比Lambda更好更灵活的实时处理架构 - bonelee - 博客园
http://www.cnblogs.com/bonelee/p/6603541.html
和Lambda架构相比，在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。或许有些人会质疑流式处理对于历史数据的高吞吐量会力不从心，但是这可以通过控制新实例的并发数进行改善。
Kappa架构的核心思想包括以下三点：
用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。
//
可能有这样回答：流计算给人的印象是对一些流式的、临时的数据进行计算，将结果保存后就将原始数据丢弃了，因此它不适合用来处理历史数据。其实这种答案并不完全正确，对于基于Lambda架构实现的Storm框架确实是这样的，但对于后来出现的Spark并不是。
Storm是在2011年7月开源的，Spark是在2012年之后逐渐为人们所知的，因此在Nathan Marz设计Lambda架构的时候，当时还并没有一个框架既可以用于离线处理，又可以进行实时计算。但随着Spark技术的发展，这一想法成为了可能，Spark本身可以用于批处理，而构建在Spark之上的Spark Streaming又可以用于实时计算，因此利用一套系统来应对批处理和实时计算相结合的业务完全是可行的。
