【大数据技术Hadoop+Spark】Spark RDD设计、运行原理、运行流程、容错机制讲解(图文解释)

简介: 【大数据技术Hadoop+Spark】Spark RDD设计、运行原理、运行流程、容错机制讲解(图文解释)

一、RDD的概念

RDD(Resilient Distributed Dataset),即弹性分布式数据集,是一个容错的、并行的数据结构,可以让用户显式地将数据存储到磁盘和内存中,并且还能控制数据的分区。不同RDD之间可以通过转换操作形成依赖关系实现管道化,从而避免了中间结果的I/O操作,提高数据处理的速度和性能。

一个RDD就是一个分布式对象集合,本质上是一个只读的分区记录集合,每个RDD可以分成多个分区,每个分区就是一个数据集片段,并且一个RDD的不同分区可以被保存到集群中不同的节点上,从而可以在集群中的不同节点上进行并行计算

二、RDD的分区

RDD的分区原则是分区的个数尽量等于集群中的CPU核心(Core)数目。对于不同的Spark部署模式而言,都可以通过设置spark.default.parallelism这个参数值来配置默认的分区数目。

local模式:默认为本地机器的CPU数目,若设置了localN 则默认为N

Standlone/yarn模式:在“集群中所有CPU核数总和”和“2”这两者中取较大值作为默认值

Mesos模式:默认的分区数是8。

三、DAG有向无环图

DAG(Directed Acyclic Graph)叫做有向无环图,Spark中的RDD通过一系列的转换算子操作和行动算子操作形成了一个DAG。DAG是一种非常重要的图论数据结构。如果一个有向图无法从任意顶点出发经过若干条边回到该点,则这个图就是有向无环图。“4→6→1→2”是一条路径,“4→6→5”也是一条路径,并且图中不存在从顶点经过若干条边后能回到该点。

四、RDD的依赖关系

1:窄依赖

窄依赖是指父RDD的每一个分区最多被一个子RDD的分区使用,即OneToOneDependencies。

窄依赖的表现一般分为两类,第一类表现为一个父RDD的分区对应于一个子RDD的分区;第二类表现为多个父RDD的分区对应于一个子RDD的分区。

一个父RDD的一个分区不可能对应一个子RDD的多个分区。

为了便于理解,我们通常把窄依赖形象的比喻为独生子女。

RDD做map、filter和union算子操作时,是属于窄依赖的第一类表现;而RDD做join算子操作(对输入进行协同划分)时,是属于窄依赖表现的第二类。输入协同划分是指多个父RDD的某一个分区的所有Key,被划分到子RDD的同一分区。当子RDD做算子操作,因为某个分区操作失败导致数据丢失时,只需要重新对父RDD中对应的分区做算子操作即可恢复数据。

2:宽依赖

宽依赖是指子RDD的每一个分区都会使用所有父RDD的所有分区或多个分区,即OneToManyDependecies。为了便于理解,我们通常把宽依赖形象的比喻为超生。

父RDD做groupByKey和join(输入未协同划分)算子操作时,子RDD的每一个分区都会依赖于所有父RDD的所有分区。当子RDD做算子操作,因为某个分区操作失败导致数据丢失时,则需要重新对父RDD中的所有分区进行算子操作才能恢复数据。

窄依赖与宽依赖的区别是是否发生Shuffle(洗牌)操作。宽依赖会发生Shuffle操作,而窄依赖不会发生Shuffle操作

Spark Shuffle一般分为两个部分:Shuffle Write和Shuffle Fetch 前者是Map任务划分分区,输出中间结果;而后者则是Reduce任务获取到的这些中间结果

3:DAG调度阶段

根据RDD之间依赖关系的不同可以将DAG划分成不同的调度阶段,对窄依赖来说,RDD分区的转换处理是在一个线程中完成的,所以窄依赖会被Spark划分到同一个Stage中,而对宽依赖来说,由于有Shuffle存在,因此只能在父RDD处理完成后,下一个Stage才能开始接下来的计算,因此是宽依赖划分Stage的依据

当A做groupByKey转换操作生成B时,由于groupByKey转换操作属于宽依赖类型,所以就把A划分为一个Stage,如Stage1;

当C做Map转换操作生成D, D与E做union转换操作生成F。由于Map和union转换操作都属于窄依赖类型,因此不进行Stage的划分,而是将C、D、E、F加入到同一个Stage中,如Stage2;

当F与B进行join转换操作时,由于这时的join操作是非协同划分,所以属于宽依赖,因此会划分为一个Stage,如Stage3;

五、RDD在Spark中的运行流程

RDD在Spark中的运行流程分为RDD Objects,DAGScheduler,TaskScheduler以及Worker四个部分

1:当RDD对象创建后 SparkContext会根据RDD对象构建DAG 然后将Task提交给DAGScheduler

2:将作业的DAG划分成不同的Stage,每个stage都是TaskSet任务集合,并交给TaskScheduler

3:把Task发给集群中Worker的Executor

4:把Task运行在Executor进程中

六、RDD容错机制

RDD容错主要采用以下两种方式

1:血统方式

根据RDD之间的依赖关系对丢失数据的RDD进行数据回复

2:检查点方式

其本质是将RDD写入磁盘存储

创作不易 觉得有帮助请点赞关注收藏~~~

相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
相关文章
|
人工智能 分布式计算 大数据
大数据≠大样本:基于Spark的特征降维实战(提升10倍训练效率)
本文探讨了大数据场景下降维的核心问题与解决方案,重点分析了“维度灾难”对模型性能的影响及特征冗余的陷阱。通过数学证明与实际案例,揭示高维空间中样本稀疏性问题,并提出基于Spark的分布式降维技术选型与优化策略。文章详细展示了PCA在亿级用户画像中的应用,包括数据准备、核心实现与效果评估,同时深入探讨了协方差矩阵计算与特征值分解的并行优化方法。此外,还介绍了动态维度调整、非线性特征处理及降维与其他AI技术的协同效应,为生产环境提供了最佳实践指南。最终总结出降维的本质与工程实践原则,展望未来发展方向。
697 0
|
存储 分布式计算 Hadoop
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
789 79
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第27天】在大数据时代,数据湖技术凭借其灵活性和成本效益成为企业存储和分析大规模异构数据的首选。Hadoop和Spark作为数据湖技术的核心组件,通过HDFS存储数据和Spark进行高效计算,实现了数据处理的优化。本文探讨了Hadoop与Spark的最佳实践,包括数据存储、处理、安全和可视化等方面,展示了它们在实际应用中的协同效应。
771 2
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
1251 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
存储 分布式计算 算法
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
469 0
|
消息中间件 分布式计算 NoSQL
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
400 0
|
消息中间件 存储 分布式计算
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
497 0