这篇总结来自极客时间专栏《大规模数据处理实践》的 10-11 节。
关于第八节 CAP 的内容可以参考之前总结的另一篇文章 分布式系统的一致性协议之 2PC 和 3PC，这里就不再详述了。
关于 Lambda 架构和 Kappa 架构可以参考我之前总结的这篇文章 第一章 Streaming 101（里面有过简单的介绍）.
Lambda 架构
Lambda 架构算是第一代大数据处理架构，提出之后在工业届得到广泛应用，其大概的架构如下所示：
Lambda 架构分为三层：
- Batch Layer：批处理层，存储管理主数据集（不可变的数据集）和预先批处理计算好的视图，批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图（准确性有保证）；
- Speed Layer：速度处理层，主要是提供最新数据来减少延迟（偏实时/准实时计算）；
- Serving Layer：用于响应查询的服务层，所有在前面两层处理的数据都会存储在服务层，服务层向外部提供查询服务。
Lambda 架构可以做到实时分析，又能通过批计算保证过去数据的正确性，在实时计算还不很准确的时代，这种架构非常受欢迎。
Lambda 架构的问题是什么呢？
- 最主要的就是要维护两套系统，当业务变得非常复杂时，这个维护成本是非常高的；
个人看法：就 Lambda 架构本身而言，其对业内的影响无疑是成功的，这种架构直到现在依然在广泛应用，这种架构的提出也跟其特殊历史背景有关。
Lambda 提出的时代，一说到流计算，大家的第一印象就是不准确、估计值等，当时 DataFlow 模型还没出现，如果没算错，Spark Streaming 应该也没出现，这时候业务既想通过 storm 去做实时分析又想使用批处理去做数据校准/或者是预分析历史数据，Lambda 在那个时代给业内带来了一个全新的思路，在大数据处理历史上有跨时代的意义。
Kappa 架构
Kappa 架构是 Jay Kreps（Kafka 和 Samza 的作者之一）提出的一个种架构思想，架构框图如下：
Kappa 架构思想主要是：让速度处理层也可以做之前批处理层做的事情，这样就不需要去维护两套系统了。
那么，Kappa 的问题是什么？
- Kappa 架构只保留了速度层而缺少批处理层，在速度层上处理大规模数据可能会有数据更新出错的情况发生（数据出错的问题是非常难排查的）；
- Kappa 架构的批处理和流处理都放在了速度层上，这导致了这种架构是使用同一套代码来处理算法逻辑的，所以 Kappa 架构并不适用于批处理和流处理代码逻辑不一致的场景。
个人看法：Kappa 思想其实可以再进一步，就现在经常说的【批流统一】，批其实只是流的其中一种形态，这个就是后来 DataFlow 的主要思想。这些架构思想对业内的影响很大，基本上决定了这个领域的发展，不过比较可惜的是，这些牛逼的思路和想法现在还都是硅谷在引领，希望有一天国内能引领某些领域的发展。
有兴趣的同学，可以通过下面的链接购买，会有一些优惠
