这篇总结来自极客时间专栏《大规模数据处理实践》的 10-11 节。
关于第八节 CAP 的内容可以参考之前总结的另一篇文章 分布式系统的一致性协议之 2PC 和 3PC,这里就不再详述了。
关于 Lambda 架构和 Kappa 架构可以参考我之前总结的这篇文章 第一章 Streaming 101(里面有过简单的介绍).
Lambda 架构
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 架构并不适用于批处理和流处理代码逻辑不一致的场景。
个人看法:Kappa 思想其实可以再进一步,就现在经常说的【批流统一】,批其实只是流的其中一种形态,这个就是后来 DataFlow 的主要思想。这些架构思想对业内的影响很大,基本上决定了这个领域的发展,不过比较可惜的是,这些牛逼的思路和想法现在还都是硅谷在引领,希望有一天国内能引领某些领域的发展。
有兴趣的同学,可以通过下面的链接购买,会有一些优惠
二维码扫描购买有一定优惠
网友评论