ui设计的推荐网站及网址,做网站后期为什么续费,网站建设报价明细模板,霸屏网站开发前言
本文隶属于专栏《大数据理论体系》#xff0c;该专栏为笔者原创#xff0c;引用请注明来源#xff0c;不足和错误之处请在评论区帮忙指出#xff0c;谢谢#xff01; 本专栏目录结构和参考文献请见大数据理论体系 姊妹篇
《分布式数据模型详解#xff1a;OldSQL 该专栏为笔者原创引用请注明来源不足和错误之处请在评论区帮忙指出谢谢 本专栏目录结构和参考文献请见大数据理论体系 姊妹篇
《分布式数据模型详解OldSQL NoSQL NewSQL》
《分布式计算模型详解MapReduce、数据流、P2P、RPC、Agent》
《大数据存储架构详解数据仓库、数据集市、数据湖、数据网格、湖仓一体》
《大数据处理架构详解Lambda架构、Kappa架构、流批一体、Dataflow模型、实时数仓》
《实时数仓详解》 思维导图 Lambda 架构
Lambda 的由来 我们通常认为这个希腊字母与这一模式相关联是因为数据来自两个地方。
批量数据和快速的流式数据代表Lambda符号的弯曲部分然后通过服务层(线段与曲线部分合并)合并如上图所示。
WHAT
Lambda架构Lambda Architecture是由Twitter工程师南森·马茨Nathan Marz提出的大数据处理架构。
它的目标是构建一个通用的、健壮的大数据系统能够同时满足实时查询和历史数据批处理的需求。
随着大数据的兴起越来越多的公司开始面临海量数据的处理问题。传统的批处理系统无法满足实时数据处理的需求而简单的流式处理系统又无法进行复杂的历史数据分析。这就需要一种混合架构能够兼顾实时性和复杂分析。Lambda架构应运而生。 关于 Lambda 架构的详情请参考我的博客——《什么是Lambda架构》 组成 Lambda 架构总共由三层系统组成批处理层Batch Layer速度处理层Speed Layer以及用于响应查询的服务层Serving Layer。
在 Lambda 架构中每层都有自己所肩负的任务。
批处理层
批处理层存储管理主数据集不可变的数据集和预先批处理计算好的视图。
批处理层使用可处理大量数据的分布式处理系统预先计算结果。
它通过处理所有的已有历史数据来实现数据的准确性。
这意味着它是基于完整的数据集来重新计算的能够修复任何错误然后更新现有的数据视图。
输出通常存储在只读数据库中更新则完全取代现有的预先计算好的视图。
速度处理层
速度处理层会实时处理新来的大数据。
速度层通过提供最新数据的实时视图来最小化延迟。
速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整但它们几乎在收到数据后立即可用。
而当同样的数据在批处理层处理完成后在速度层的数据就可以被替代掉了。
本质上速度层弥补了批处理层所导致的数据视图滞后。
比如说批处理层的每个任务都需要 1 个小时才能完成而在这 1 个小时里我们是无法获取批处理层中最新任务给出的数据视图的。
而速度层因为能够实时处理数据给出结果就弥补了这 1 个小时的滞后。
服务层
所有在批处理层和速度层处理完的结果都输出存储在服务层中服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。 Kappa 架构
Kappa架构是对Lambda架构的改进和优化由Jay Kreps于2014年首次提出。
随着流式计算系统的发展Lambda架构存在的一些问题逐渐显现出来
系统复杂度高需要同时开发和维护批处理系统和流式系统。通过日志重播实现低延迟查询会导致数据冗余。实时视图和批处理视图存在延迟不一致的问题。
为了解决这些问题Jay Kreps提出了Kappa架构。Kappa架构去除了Lambda架构的批处理层直接通过流式处理系统实现整个流程。 关于 Kappa 架构的详情请参考我的博客——《什么是Kappa架构》 组成 Kappa架构主要包含两个层:
流式处理层通过流式处理系统接收所有数据并进行实时计算更新存储中的结果视图。服务层对外提供查询服务直接基于流式处理层更新的结果视图进行查询返回。
Kappa架构减少了系统复杂度避免了数据冗余和数据不一致的问题。但需要流式处理系统能够保证Exactly-once语义以保证流式计算的正确性。而且去除批处理系统后对历史数据的复杂计算会更加困难。
以 Apache Kafka 为例来讲述整个Kappa架构的过程 部署 Apache Kafka并设置数据日志的保留期Retention Period。这里的保留期指的是你希望能够重新处理的历史数据的时间区间。例如如果你希望重新处理最多一年的历史数据那就可以把 Apache Kafka 中的保留期设置为 365 天。如果你希望能够处理所有的历史数据那就可以把 Apache Kafka 中的保留期设置为“永久Forever”。如果我们需要改进现有的逻辑算法那就表示我们需要对历史数据进行重新处理。我们需要做的就是重新启动一个 Apache Kafka 作业实例Instance。这个作业实例将重头开始重新计算保留好的历史数据并将结果输出到一个新的数据视图中。我们知道 Apache Kafka 的底层是使用 Log Offset 来判断现在已经处理到哪个数据块了所以只需要将 Log Offset 设置为 0新的作业实例就会重头开始处理历史数据。当这个新的数据视图处理过的数据进度赶上了旧的数据视图时我们的应用便可以切换到从新的数据视图中读取。停止旧版本的作业实例并删除旧的数据视图。
与 Lambda 架构不同的是Kappa 架构去掉了批处理层这一体系结构而只保留了速度层。 你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。
当然了也可以在上面讲到的步骤中做一些优化。 例如不执行第 4 步也就是不删除旧的数据视图。这样的好处是当你发现代码逻辑出错时可以及时回滚Roll Back到上一个版本的数据视图中去。又或者是你想在服务层提供 A/B 测试保留多个数据视图版本将有助于你进行 A/B 测试。 Lambda 架构 vs Kappa 架构
Lambda架构和Kappa架构的区别可以通过下表进行对比说明:
对比项Lambda架构Kappa架构组成批处理层速度层服务层流式处理层服务层数据处理方式批处理系统处理历史数据流式系统处理实时数据仅用流式系统处理全部数据系统复杂度较高需要开发和维护两个系统较低只需要一个流式系统延迟一致性存在实时视图和批处理视图有延迟差异更好没有批处理系统数据冗余存在需要重播日志到实时系统较少无需重播日志历史数据处理批处理系统可进行复杂历史分析相对复杂只有流式系统
总结来说:
Lambda架构通过批处理层和速度层的组合兼顾了低延迟和复杂分析但系统较复杂存在数据冗余和延迟不一致问题。
Kappa架构只通过流式系统实现所有处理简化了架构但历史数据分析相对复杂需要流式系统保证精确一次语义。
两者都有各自的优缺点需要根据具体场景进行技术选型和设计权衡。 Kappa 架构变种
Kappa-S
Kappa-S架构是在Kappa架构的基础上进行的优化和改进。
Kappa架构通过单个流式处理系统实现低延迟的实时计算以及历史数据的处理。
但原始的Kappa架构依然存在一些问题:
历史数据的处理还是相对复杂不如Lambda架构中的批处理系统。单个流式系统需要承担全部数据的处理面临较大的压力。流式系统需要保证精确一次语义实现较为复杂。
为了解决这些问题Jay Kreps等人提出了Kappa-S架构。该架构在Kappa架构的基础上引入了Stream-Serving层。 Kappa-S架构包含以下组件:
Stream层:实时流式处理层。Serving层:查询服务层。Stream-Serving层:用来预计算并服务历史数据的查询减轻Stream负载。
通过引入Stream-Serving层针对历史数据进行预计算Kappa-S架构减轻了流式处理的压力使历史数据的查询和分析更加简单同时也避免了流式系统需要提供精确一次语义的复杂性。可以看作是Kappa架构和Lambda架构的折中方案。
Kappa-Lambda
Kappa-Lambda架构是在Kappa架构的基础上引入了Lambda架构中的批处理层组件形成的一种混合架构。 Kappa-Lambda架构包含以下组件:
Stream层:实时流式处理层。Serving层:查询服务层。Batch层:批处理层用于复杂的历史数据分析。Speed层:速度层用于低延迟的实时计算。
其工作流程如下:
Stream层接收实时数据进行实时计算。Speed层从Stream层获取实时结果进行低延迟的实时分析。Serving层查询时实时部分从Speed层获取历史部分从Batch层获取。Batch层定期从Stream层获取数据进行复杂的历史数据分析和处理。
可以看出Kappa-Lambda架构相比Kappa架构引入了批处理层组件以便进行复杂的历史数据分析。同时保留了Speed层进行低延迟的实时计算。
这种设计兼顾了Kappa架构的简单性以及Lambda架构在复杂分析上的优势。既能实时处理也能进行复杂的批处理。
Kappa-DB
Kappa-DB架构是在Kappa架构的基础上通过引入数据库组件实现流式数据到数据库的持久化保存形成的一种架构设计。 Kappa-DB架构通常包含以下组件:
Stream层:实时流式处理层。Serving层:查询服务层。Database:数据库层用于存储流式处理的结果数据。
其工作流程如下:
Stream层接收实时数据进行实时处理。Stream层将处理结果写入数据库进行持久化存储。Serving层接收查询请求从数据库中读取数据进行计算后返回结果。定期进行归档或聚合避免数据库数据过多。
引入数据库组件的优点包括:
通过数据库持久化存储避免数据丢失。简化历史数据查询数据库可以进行索引优化。可以通过归档降低存储成本。可以重用数据库的计算能力减少流计算开销。
需要注意数据库写入成为系统瓶颈的问题通常要控制写入数据库的频率进行归档优化等。
总体上Kappa-DB架构通过融合流式处理和数据库实现了数据的持久化存储同时也继承了Kappa架构的优点。
Kappa 系列架构对比
架构类型组成优点缺点Kappa流式处理层服务层简单一致性好历史处理复杂Kappa-S流式处理层服务层预计算层减轻流量压力历史处理简单额外一层复杂度Kappa-Lambda流式处理层服务层速度层批处理层兼顾实时和批处理架构比较复杂Kappa-DB流式处理层服务层数据库层数据持久化利用DB计算DB成为瓶颈
综合来看:
Kappa架构简单但历史处理复杂Kappa-S通过预计算层减轻实时流量压力但增加了系统复杂度Kappa-Lambda引入批处理能力但架构非常复杂Kappa-DB使用数据库实现持久化但可能面临DB瓶颈
需要根据具体业务需求平衡实时处理、历史处理、一致性、范畴等方面的需求选择适合的架构。 流批一体 流批一体(Unified Batch and Streaming Processing)是指将流式处理和批处理统一在一个运行时框架中进行一体化的处理。
在流批一体架构中实时数据流和历史数据批量处理可以使用同一组数据处理工具和技术例如Apache Spark、Apache Flink等。流批一体架构可以将实时数据和历史数据进行统一的处理和分析以简化数据处理的复杂性和提高数据处理的效率。
在流批一体架构中实时数据流和历史数据批量处理可以使用同一套数据处理代码。这意味着数据处理人员可以使用同一种编程语言、框架和工具来处理实时数据和历史数据。这样可以减少数据处理人员的学习和使用成本并提高数据处理的效率和精度。
流批一体架构还可以将实时数据和历史数据存储在同一套数据存储系统中例如Apache HBase、Apache Cassandra等。这样可以简化数据存储的管理和维护并提高数据的可用性和可靠性。
总之流批一体是一种将流数据处理和批数据处理整合在一起的数据处理架构它可以简化数据处理的复杂性和提高数据处理的效率。流批一体架构可以在实时数据处理和历史数据批量处理之间实现无缝切换以满足不同的数据处理需求。
诞生背景
流批一体的诞生主要有以下背景:
Lambda架构的复杂性问题Lambda架构需要同时开发和维护批处理系统和流式处理系统系统复杂开发和运维困难。实时计算和历史计算的需求融合越来越多的应用同时需要实时数据处理和历史数据分析需要一个统一的框架。流式处理系统的发展成熟流式处理系统的计算模型和性能已经发展成熟可以用于替代传统的批处理任务。微批流式处理技术的出现Spark Streaming等系统采用微批流式处理简化了流式处理的事件时间管理。云原生技术的兴起Kubernetes等技术为流批一体提供了更好的资源调度和技术支撑。
综上流批一体可以看作是对Lambda架构的简化也是实时处理和批处理融合的产物以应对实时数据和历史数据双需求的场景。 Dataflow 模型
DataFlow 模型是一种用于描述数据处理流程的计算模型它描述了数据从源头到目的地的流动过程并指定了数据处理的方式和顺序。
DataFlow 模型常用于并行计算和数据流处理领域例如流处理框架 Apache Flink 就是基于 DataFlow 模型实现的。
在 DataFlow 模型中数据被视为流动的实体数据处理被视为一系列的数据转换操作。数据可以从一个或多个输入源中流入数据处理系统经过一系列的处理操作最终输出到一个或多个输出目的地中。在数据处理的过程中数据可以被分割成多个数据块这些数据块可以并行处理以提高数据处理的效率。
DataFlow 模型中的数据处理操作通常被描述为有向图中的节点数据流动则被描述为有向边。每个节点可以执行一些特定的数据处理操作例如数据过滤、数据转换、数据聚合等。节点之间的边表示数据的流动方向和数据处理顺序。在 DataFlow 模型中数据处理操作可以被组合成复杂的数据处理流程以实现不同的数据处理需求。
总之DataFlow 模型是一种用于描述数据处理流程的计算模型它描述了数据从源头到目的地的流动过程并指定了数据处理的方式和顺序。DataFlow 模型常用于并行计算和数据流处理领域例如流处理框架 Apache Flink 就是基于 DataFlow 模型实现的。 关于 Dataflow 模型的更多细节请参考我的博客——《DataFlow 模型是什么》 诞生背景
Dataflow模型的主要诞生背景:
大数据时代的数据规模爆炸需要并行计算能力流式计算和批处理的需求融合MapReduce模型的局限性MapReduce模型对迭代计算和DAG支持不友好而Dataflow模型通过Operator图更适合表达复杂的数据处理流程。分布式资源管理与集群调度技术的进步YARN、Mesos、Kubernetes等技术为Dataflow模型提供了更好的运行时支撑。内存计算的发展Spark等内存计算框架更适合Dataflow模型。
综上Dataflow模型是对MapReduce模型的重要发展和延伸可以更好地处理迭代、流式、DAG等复杂数据处理任务在大数据时代得到广泛应用。 关于 MapReduce 模型请参考我的博客——《MapReduce 编程模型到底是怎样的》 Dataflow 模型全流程 DataFlow 模型的全流程可以分为以下几个步骤
数据源输入数据源可以是各种类型的数据例如文件、数据库、消息队列等。在 DataFlow 模型中数据源被视为数据处理流程的起点数据从数据源中流入数据处理系统。数据切割在 DataFlow 模型中数据可以被分割成多个数据块这些数据块可以并行处理以提高数据处理的效率。数据切割可以根据数据的大小、时间戳、键值等方式进行以便更好地实现数据并行处理。数据转换在 DataFlow 模型中数据可以经过一系列的数据转换操作例如数据清洗、数据过滤、数据聚合等。数据转换操作被描述为有向图中的节点每个节点可以执行一些特定的数据处理操作节点之间的边表示数据的流动方向和数据处理顺序。数据聚合在 DataFlow 模型中数据可以经过多个数据转换操作后被聚合起来以便更好地实现数据分析和挖掘。数据输出在 DataFlow 模型中数据输出可以是各种类型的数据目的地例如文件、数据库、消息队列等。数据输出被视为数据处理流程的终点数据从数据处理系统中输出到数据目的地中。
在 DataFlow 模型中数据处理操作可以被组合成复杂的数据处理流程以实现不同的数据处理需求。数据处理流程可以使用各种数据处理框架和工具来实现例如 Apache Flink、Apache Beam、Apache Kafka 等。
Dataflow 模型怎样保证数据的准确性和一致性
DataFlow 模型可以通过以下方式来保证数据的准确性和一致性
数据校验在数据流入数据处理系统之前可以进行数据校验例如数据格式、数据类型、数据范围等。这可以保证数据的准确性和完整性。数据清洗在数据处理过程中可以进行数据清洗例如去除重复数据、填充缺失数据等。这可以保证数据的一致性和准确性。事务处理在数据处理过程中可以使用事务机制来确保数据的一致性。例如如果一个节点的数据处理失败整个数据处理流程可以回滚到之前的状态以保证数据的一致性。数据分区在数据处理过程中可以将数据分成多个数据块每个数据块可以并行处理。这可以提高数据处理的效率同时也可以避免数据竞争和数据冲突以保证数据的一致性。数据重试在数据处理过程中如果某个节点处理失败可以进行数据重试直到数据处理成功。这可以保证数据的完整性和准确性。 实时数仓
实时数仓是一种现代化的数据仓库具有大数据规模的小数据语义和性能。它可以处理实时数据、最新数据和历史数据并且能够跨数据域进行相关性分析。实时数仓具有更快的数据到达和查询速度可以在集成且安全的平台上完成所有功能。
实时数仓的优势包括更快的决策、数据民主化、个性化的客户体验、提高业务敏捷性和解锁新的业务用例。然而实时数仓也面临着ETL性能和复杂实时计算场景等挑战。
典型的实时数仓架构包括数据收集层、数据存储层、实时计算层和实时应用层。数据收集层负责接收和传输数据数据存储层用于实时数据存储实时计算层用于实时计算和分析实时应用层用于数据分析和挖掘。
实时数仓可以应用于实时OLAP分析、实时数据看板、实时业务监控和实时数据接口服务等场景。其技术实现通常包括消息总线、实时存储、流处理和分析以及应用层。
常用的实时数仓技术包括Apache Kafka、Apache Druid、Apache Spark、Hadoop、TiDB等具体选择取决于需求和偏好。 关于实时数仓的更多细节请参考我的博客——《实时数仓详解》 诞生背景
实时数仓的主要诞生背景有:
对实时数据分析需求的增长越来越多的企业希望能够立即分析操作数据以便及时做出决策。传统数仓延迟大的问题传统的数仓以批量方式定期更新无法满足对实时数据的分析需要。流式计算技术的发展大数据技术使得流式数据的采集、传输和计算成为可能。内存计算的进步Spark等内存计算技术使得内存级的交互式分析成为可能。对用户体验的提高要求用户希望立即获取分析见解不能等待传统数仓的延迟。云计算技术的进步云计算提供了实时数仓弹性扩展的能力。
架构
实时数仓通常具有四个组件数据收集层、数据存储层、实时计算层和实时应用层。这些组件协同工作以便在事件发生后立即或短时间内支持事件数据的处理和分析。所有数据处理阶段数据摄取、丰富、分析、基于 AI/ML 的分析都是连续的具有最小延迟并且能够实现实时报告和即席分析。
一个比较典型的实时数仓架构如下所示 数据收集层第三方服务和协同系统通过 Apache Kafka/Apache Nifi 之类的消息总线传输数据到实时数仓第三方数据源通过调用实时数仓的 API物联网系统通过直接连接并推送数据的方法传输数据数据存储层使用 Apache Kudu/Apache Druid/Amazon Redshift 来进行实时数据存储实时计算层使用 Apache Spark/Amazon Kinesis/Hadoop 来进行实时计算和分析实时应用层使用 AI 和机器学习技术对数据进行分析和挖掘使用 SQL Server/Oracle BI 来支持查询、报告和即席查询使用 Apache Impala 来支持实时报告和告警。 对比
架构类型组成优点缺点Lambda架构批处理层速度层服务层兼顾低延迟和复杂分析系统复杂,数据冗余Kappa架构流式处理层服务层系统简单,一致性好历史处理相对复杂流批一体统一运行时框架处理简化,效率高实时性打折扣Dataflow模型数据源、转换操作、数据汇聚灵活性强,可扩展性好需要解决一致性等问题实时数仓收集层存储层计算层应用层实时分析,低延迟基础设施要求高 总结
本文详细介绍了几种主要的大数据处理架构:
Lambda架构组合批处理层和速度层兼顾低延迟和复杂分析但系统较复杂存在数据冗余和延迟不一致问题。Lambda架构的批处理层可以基于Hadoop、Spark等技术来实现速度层可以基于Storm、Flink等流式处理系统来实现。服务层需要实现查询接口可以使用REST API。Lambda架构适合大数据场景但维护批处理层和速度层的重复开发较为麻烦。Kappa架构仅通过流式处理实现所有处理简化了架构但历史数据分析相对复杂。Kappa架构还有几种变种如Kappa-S、Kappa-Lambda、Kappa-DB。Kappa架构中的流式处理层可以基于Flink、Spark Streaming等来实现需要实现Exactly-once语义。服务层同样需要查询接口。Kappa架构简单高效但对实时流有较高要求历史数据处理不如Lambda架构方便。流批一体将流式处理和批处理统一在一个运行时框架中可以简化处理提高效率。流批一体需要统一运行时框架如Flink、Spark等可以通过DataStream和DataSet在流式处理和批处理之间无缝切换。计算模型也需要统一如Dataflow模型。流批一体简化系统但实时性不如纯流式处理。Dataflow模型将数据处理视为数据流经转换操作的流程可以表达复杂的数据处理流程。Dataflow模型通常用有向图表达并基于并行运行时框架实现如Flink。需要解决数据一致性、容错等问题。Dataflow模型可以灵活表示复杂处理流程。实时数仓通过流式处理实现对实时数据的快速存储和计算分析满足了对实时分析的需求。实时数仓中的消息总线可以用Kafka实现存储系统可以使用HBase、Druid等计算使用Spark Streaming、Flink。实时数仓可以快速分析数据并实时更新但对基础设施要求较高。
总的来说大数据处理架构的发展趋势是实时性增强、处理统一简化、满足复杂分析需求。需要根据具体业务场景需求选择合适的架构方案。未来可能是基于流式处理的架构为主同时引入批处理能力进行复杂分析。
