赞
踩
Lambda架构(Lambda Architecture)是由Twitter工程师南森·马茨(Nathan Marz)提出的大数据处理架构。
它的目标是构建一个通用的、健壮的大数据系统,能够同时满足实时查询和历史数据批处理的需求。
随着大数据的兴起,越来越多的公司开始面临海量数据的处理问题。传统的批处理系统无法满足实时数据处理的需求,而简单的流式处理系统又无法进行复杂的历史数据分析。这就需要一种混合架构,能够兼顾实时性和复杂分析。Lambda架构应运而生。
Lambda 架构总共由三层系统组成:批处理层(Batch Layer),速度处理层(Speed Layer),以及用于响应查询的服务层(Serving Layer)。
在 Lambda 架构中,每层都有自己所肩负的任务。
批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图。
批处理层使用可处理大量数据的分布式处理系统预先计算结果。
它通过处理所有的已有历史数据来实现数据的准确性。
这意味着它是基于完整的数据集来重新计算的,能够修复任何错误,然后更新现有的数据视图。
输出通常存储在只读数据库中,更新则完全取代现有的预先计算好的视图。
速度处理层会实时处理新来的大数据。
速度层通过提供最新数据的实时视图来最小化延迟。
速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整,但它们几乎在收到数据后立即可用。
而当同样的数据在批处理层处理完成后,在速度层的数据就可以被替代掉了。
本质上,速度层弥补了批处理层所导致的数据视图滞后。
比如说,批处理层的每个任务都需要 1 个小时才能完成,而在这 1 个小时里,我们是无法获取批处理层中最新任务给出的数据视图的。
而速度层因为能够实时处理数据给出结果,就弥补了这 1 个小时的滞后。
所有在批处理层和速度层处理完的结果
都输出存储在服务层中,服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。
Kappa架构是对Lambda架构的改进和优化,由Jay Kreps于2014年首次提出。
随着流式计算系统的发展,Lambda架构存在的一些问题逐渐显现出来:
为了解决这些问题,Jay Kreps提出了Kappa架构。Kappa架构去除了Lambda架构的批处理层,直接通过流式处理系统实现整个流程。
关于 Kappa 架构的详情请参考我的博客——《什么是Kappa架构?》
Kappa架构主要包含两个层:
Kappa架构减少了系统复杂度,避免了数据冗余和数据不一致的问题。但需要流式处理系统能够保证Exactly-once
语义,以保证流式计算的正确性。而且,去除批处理系统后,对历史数据的复杂计算会更加困难。
与 Lambda 架构不同的是,Kappa 架构去掉了批处理层这一体系结构,而只保留了速度层。 你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。
当然了,也可以在上面讲到的步骤中做一些优化。 例如不执行第 4 步,也就是不删除旧的数据视图。这样的好处是当你发现代码逻辑出错时可以及时回滚(Roll Back)到上一个版本的数据视图中去。又或者是你想在服务层提供 A/B 测试,保留多个数据视图版本将有助于你进行 A/B 测试。
Lambda架构和Kappa架构的区别可以通过下表进行对比说明:
对比项 | Lambda架构 | Kappa架构 |
---|---|---|
组成 | 批处理层 速度层 服务层 | 流式处理层 服务层 |
数据处理方式 | 批处理系统处理历史数据 流式系统处理实时数据 | 仅用流式系统处理全部数据 |
系统复杂度 | 较高,需要开发和维护两个系统 | 较低,只需要一个流式系统 |
延迟一致性 | 存在,实时视图和批处理视图有延迟差异 | 更好,没有批处理系统 |
数据冗余 | 存在,需要重播日志到实时系统 | 较少,无需重播日志 |
历史数据处理 | 批处理系统可进行复杂历史分析 | 相对复杂,只有流式系统 |
总结来说:
Lambda架构通过批处理层和速度层的组合,兼顾了低延迟和复杂分析,但系统较复杂,存在数据冗余和延迟不一致问题。
Kappa架构只通过流式系统实现所有处理,简化了架构,但历史数据分析相对复杂,需要流式系统保证精确一次语义。
两者都有各自的优缺点,需要根据具体场景进行技术选型和设计权衡。
Kappa-S架构是在Kappa架构的基础上进行的优化和改进。
Kappa架构通过单个流式处理系统实现低延迟的实时计算以及历史数据的处理。
但原始的Kappa架构依然存在一些问题:
为了解决这些问题,Jay Kreps等人提出了Kappa-S架构。该架构在Kappa架构的基础上,引入了Stream-Serving层。
Kappa-S架构包含以下组件:
通过引入Stream-Serving层针对历史数据进行预计算,Kappa-S架构减轻了流式处理的压力,使历史数据的查询和分析更加简单,同时也避免了流式系统需要提供精确一次语义的复杂性。可以看作是Kappa架构和Lambda架构的折中方案。
Kappa-Lambda架构是在Kappa架构的基础上,引入了Lambda架构中的批处理层组件,形成的一种混合架构。
Kappa-Lambda架构包含以下组件:
其工作流程如下:
可以看出,Kappa-Lambda架构相比Kappa架构,引入了批处理层组件,以便进行复杂的历史数据分析。同时保留了Speed层,进行低延迟的实时计算。
这种设计兼顾了Kappa架构的简单性,以及Lambda架构在复杂分析上的优势。既能实时处理,也能进行复杂的批处理。
Kappa-DB架构是在Kappa架构的基础上,通过引入数据库组件,实现流式数据到数据库的持久化保存,形成的一种架构设计。
Kappa-DB架构通常包含以下组件:
其工作流程如下:
引入数据库组件的优点包括:
需要注意数据库写入成为系统瓶颈的问题,通常要控制写入数据库的频率,进行归档优化等。
总体上,Kappa-DB架构通过融合流式处理和数据库,实现了数据的持久化存储,同时也继承了Kappa架构的优点。
架构类型 | 组成 | 优点 | 缺点 |
---|---|---|---|
Kappa | 流式处理层 服务层 | 简单,一致性好 | 历史处理复杂 |
Kappa-S | 流式处理层 服务层 预计算层 | 减轻流量压力 历史处理简单 | 额外一层复杂度 |
Kappa-Lambda | 流式处理层 服务层 速度层 批处理层 | 兼顾实时和批处理 | 架构比较复杂 |
Kappa-DB | 流式处理层 服务层 数据库层 | 数据持久化 利用DB计算 | DB成为瓶颈 |
综合来看:
需要根据具体业务需求,平衡实时处理、历史处理、一致性、范畴等方面的需求,选择适合的架构。
流批一体(Unified Batch and Streaming Processing)是指将流式处理和批处理统一在一个运行时框架中,进行一体化的处理。
在流批一体架构中,实时数据流和历史数据批量处理可以使用同一组数据处理工具和技术,例如Apache Spark、Apache Flink等。流批一体架构可以将实时数据和历史数据进行统一的处理和分析,以简化数据处理的复杂性和提高数据处理的效率。
在流批一体架构中,实时数据流和历史数据批量处理可以使用同一套数据处理代码。这意味着,数据处理人员可以使用同一种编程语言、框架和工具来处理实时数据和历史数据。这样可以减少数据处理人员的学习和使用成本,并提高数据处理的效率和精度。
流批一体架构还可以将实时数据和历史数据存储在同一套数据存储系统中,例如Apache HBase、Apache Cassandra等。这样可以简化数据存储的管理和维护,并提高数据的可用性和可靠性。
总之,流批一体是一种将流数据处理和批数据处理整合在一起的数据处理架构,它可以简化数据处理的复杂性和提高数据处理的效率。流批一体架构可以在实时数据处理和历史数据批量处理之间实现无缝切换,以满足不同的数据处理需求。
流批一体的诞生主要有以下背景:
综上,流批一体可以看作是对Lambda架构的简化,也是实时处理和批处理融合的产物,以应对实时数据和历史数据双需求的场景。
DataFlow 模型是一种用于描述数据处理流程的计算模型,它描述了数据从源头到目的地的流动过程,并指定了数据处理的方式和顺序。
DataFlow 模型常用于并行计算
和数据流处理
领域,例如流处理框架 Apache Flink 就是基于 DataFlow 模型实现的。
在 DataFlow 模型中,数据被视为流动的实体,数据处理被视为一系列的数据转换操作。数据可以从一个或多个输入源中流入数据处理系统,经过一系列的处理操作,最终输出到一个或多个输出目的地中。在数据处理的过程中,数据可以被分割成多个数据块,这些数据块可以并行处理,以提高数据处理的效率。
DataFlow 模型中的数据处理操作通常被描述为有向图中的节点,数据流动则被描述为有向边。每个节点可以执行一些特定的数据处理操作,例如数据过滤、数据转换、数据聚合等。节点之间的边表示数据的流动方向和数据处理顺序。在 DataFlow 模型中,数据处理操作可以被组合成复杂的数据处理流程,以实现不同的数据处理需求。
总之,DataFlow 模型是一种用于描述数据处理流程的计算模型,它描述了数据从源头到目的地的流动过程,并指定了数据处理的方式和顺序。DataFlow 模型常用于并行计算和数据流处理领域,例如流处理框架 Apache Flink 就是基于 DataFlow 模型实现的。
关于 Dataflow 模型的更多细节请参考我的博客——《DataFlow 模型是什么?》
Dataflow模型的主要诞生背景:
综上,Dataflow模型是对MapReduce模型的重要发展和延伸,可以更好地处理迭代、流式、DAG等复杂数据处理任务,在大数据时代得到广泛应用。
DataFlow 模型的全流程可以分为以下几个步骤:
在 DataFlow 模型中,数据处理操作可以被组合成复杂的数据处理流程,以实现不同的数据处理需求。数据处理流程可以使用各种数据处理框架和工具来实现,例如 Apache Flink、Apache Beam、Apache Kafka 等。
DataFlow 模型可以通过以下方式来保证数据的准确性和一致性:
实时数仓是一种现代化的数据仓库,具有大数据规模的小数据语义和性能。它可以处理实时数据、最新数据和历史数据,并且能够跨数据域进行相关性分析。实时数仓具有更快的数据到达和查询速度,可以在集成且安全的平台上完成所有功能。
实时数仓的优势包括更快的决策、数据民主化、个性化的客户体验、提高业务敏捷性和解锁新的业务用例。然而,实时数仓也面临着ETL性能和复杂实时计算场景等挑战。
典型的实时数仓架构包括数据收集层、数据存储层、实时计算层和实时应用层。数据收集层负责接收和传输数据,数据存储层用于实时数据存储,实时计算层用于实时计算和分析,实时应用层用于数据分析和挖掘。
实时数仓可以应用于实时OLAP分析、实时数据看板、实时业务监控和实时数据接口服务等场景。其技术实现通常包括消息总线、实时存储、流处理和分析以及应用层。
常用的实时数仓技术包括Apache Kafka、Apache Druid、Apache Spark、Hadoop、TiDB等,具体选择取决于需求和偏好。
关于实时数仓的更多细节请参考我的博客——《实时数仓详解》
实时数仓的主要诞生背景有:
实时数仓通常具有四个组件:数据收集层、数据存储层、实时计算层和实时应用层。这些组件协同工作,以便在事件发生后立即或短时间内支持事件数据的处理和分析。所有数据处理阶段(数据摄取、丰富、分析、基于 AI/ML 的分析)都是连续的,具有最小延迟,并且能够实现实时报告和即席分析。
一个比较典型的实时数仓架构如下所示:
架构类型 | 组成 | 优点 | 缺点 |
---|---|---|---|
Lambda架构 | 批处理层 速度层 服务层 | 兼顾低延迟和复杂分析 | 系统复杂,数据冗余 |
Kappa架构 | 流式处理层 服务层 | 系统简单,一致性好 | 历史处理相对复杂 |
流批一体 | 统一运行时框架 | 处理简化,效率高 | 实时性打折扣 |
Dataflow模型 | 数据源、转换操作、数据汇聚 | 灵活性强,可扩展性好 | 需要解决一致性等问题 |
实时数仓 | 收集层 存储层 计算层 应用层 | 实时分析,低延迟 | 基础设施要求高 |
本文详细介绍了几种主要的大数据处理架构:
总的来说,大数据处理架构的发展趋势是实时性增强
、处理统一简化
、满足复杂分析需求
。需要根据具体业务场景需求选择合适的架构方案。未来可能是基于流式处理的架构为主,同时引入批处理能力进行复杂分析。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。