一、Lambda体系结构
Lambda体系结构由Storm的作者Nathan Marz提出，其设计目的是提供满足大数据系统关键特性(如高容错、低延迟和可扩展性)的体系结构。 可以将离线计算与实时计算集成，融合无偏差、读写隔离和复杂性隔离等原则，集成Hadoop、Kafka、Spark、Storm等各种大数据组件
Lambda体系结构可以分解为三层层： Batch Layer、实时层(speed )和服务层。
Batch Layer :存储数据集，在数据集上预计算查询函数，并生成与查询对应的视图。 “Batch Layer”可以很好地处理脱机数据，但有很多场景数据会持续实时生成，需要实时查询处理，在这种情况下，“Speed Layer”比较适合。
Speed Layer : Batch Layer处理整个数据集，Speed Layer处理最近的增量数据流。 为了提高效率，在收到新数据后，速度层会不断更新实时视图，但Batch Layer会直接从整个脱机数据集检索batch视图。
Serving Layer : Serving Layer用于将Batch View和实时视图的结果数据集合并到最终数据集。
典型的Lambda体系结构如下：
该体系结构主要面向逻辑复杂、延迟少的异步处理程序，如搜索引擎、推荐引擎等。
系统从一个流中读取我们定义为不变的数据，将其分别流入实时系统(如Storm )和批处理系统(如Hadoop )，并分别输出自己的结果。 这些结果在查询端合并。 当然，这样的系统也有很多变体。 例如，上图中的Kafka可以替换为其他分布式队列，Storm可以替换为其他流计算引擎。
二. Kappa体系结构
Kappa体系结构是LinkedIn的Jay Kreps结合实际经验和个人体验，对Lambda体系结构进行深入分析，分析其优缺点，并采用的替代方案。 Lambda体系结构的一个明显问题是需要维护批处理和运行在实时计算系统上的两个代码。 而且，这两个代码将产生完全相同的结果。 因此，对于设计这种系统的人来说，面临的问题是为什么不能改进流计算系统来解决这些问题。 为什么不能让流媒体系统解决数据总量处理的问题？ 流媒体计算的天然分布式特性是高度可扩展的，是否可以增加并发量以处理大量的历史数据？ 考虑到各种问题，Jay提出了一种叫做Kappa的替代方案。
那么，如何使用流量计算系统重新计算总量数据，步骤如下。
1、用Kafka或类似的分布式队列保存数据，需要几天的数据量保存几天。
2、需要总量计算时，重新创建流计算实例，从头开始读取数据进行处理，并输出到结果存储器。
3、新实例完成后，停止旧的流计算实例，删除旧的引起的结果。
典型的Kappa体系结构如下：
三.综述
目前，大多数互联网企业都采用了这种Lambda大数据架构，不仅能够同时满足不同时效复杂性的数据需求，而且能有效节约企业的机器成本。 离线链接(批处理层)通常可以对数据进行大量复杂的计算。 数据产量通常在T 1)第二天，在某些场景中，脱机链接分为两个链接：脱机(日级别)和近线(时间级别)。 实时链接)如今，大多数互联网公司都采用了这一大数据架构，不仅可以同时满足不同时间复杂度的数据需求，还可以有效地节约企业的机器成本。 离线链接(批处理层)通常可以对数据进行大量复杂的计算。 数据产量通常在T 1)第二天，在某些场景中，脱机链接分为两个链接：脱机(日级别)和近线(时间级别)。 实时链路(高速处理层)通常用于实现核心KPI指标计算、或高时效要求业务计算)实时推荐等。
Kappa体系结构还在不断发展，需要更多的企业用户的磨练和参与。 目前已被引入要求业务实时性更多的公司、部门，最有名的应该是阿里双十一大银幕项目。
————————————————
这是CSDN博客“BabyFish13”的原创文章，符合CC 4.0 BY-SA版权协议。 请附上原文来源的链接和本声明。
原文链接： https://blog.csdn.net/baby fish 13/article/details/106363970 /