【Spark】底层执行任务逻辑

本文详细探讨了Spark中的广播变量及其原理,展示了如何通过广播变量减少内存消耗和提升网络传输效率。同时,介绍了RDD分区的概念,以及它们在任务分布和性能优化中的作用。重点讲解了使用和不使用广播变量的对比,并提供了使用注意事项,帮助开发者更好地进行Spark性能调优。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

持续更新,直到写出每个环节的关系。

目录

【spark广播】

一、使用广播变量的好处

二、广播变量的原理

三、代码中广播变量的使用

四、使用广播变量和不适用广播变量的对比

(一)图对比

 ​(二)实例说明

五、使用注意事项

【spark分区】


首先了解下driver、executor、task的关系。

【spark广播】

一、使用广播变量的好处

1、Driver每次分发任务的时候会把task和计算逻辑的变量发送给Executor。不使用广播变量,在每个Executor中有多少个task就有多少个Driver端变量副本。这样会导致消耗大量的内存导致严重的后果。

2、使用广播变量的好处,不需要每个task带上一份变量副本,而是变成每个节点的executor才一份副本。这样的话, 就可以让变量产生的副本大大减少;

二、广播变量的原理

广播变量,初始的时候,就在Drvier上有一份副本。task在运行的时候,想要使用广播变量中的数据,此时首先会在自己本地的Executor对应的BlockManager中,尝试获取变量副本;如果本地没有,那么就从Driver远程拉取变量副本,并保存在本地的BlockManager中;此后这个executor上的task,都会直接使用本地的BlockManager中的副本。executor的BlockManager除了从driver上拉取,也可能从其他节点的BlockManager上拉取变量副本。

BlockManager:负责管理某个Executor对应的内存和磁盘上的数据,尝试在本地BlockManager中找map。

三、代码中广播变量的使用

SparkContext的broadcast()方法,传入你要广播的变量:

sc.broadcast(b)       // b为需要广播出去的变量;sc为SparkContext

直接调用广播变量(Broadcast类型)的value() / getValue() 可以获取到之前封装的广播变量:

b.value()  //b为上面广播出去的变量。

四、使用广播变量和不适用广播变量的对比

(一)图对比

1、不使用广播变量


2、使用广播变量

 (二)实例说明

50个executor,1000个task。一个map,10M。 默认情况下,1000个task,1000份副本。10G的数据,网络传输,在集群中,耗费10G的内存资源。 如果使用了广播变量。50个execurtor,最多50个副本。最多500M的数据,网络传输。而且不一定都是从Driver传输到每个节点,还可能是就近从最近的节点的executor的bockmanager上拉取变量副本,网络传输速度大大增加;最多竟有500M的内存消耗。

 10000M,500M,20倍。20倍~以上的网络传输性能消耗的降低;20倍的内存消耗的减少。对性能的提升和影响,还是很客观的。 虽然说,不一定会对性能产生决定性的作用。比如运行30分钟的spark作业,可能做了广播变量以后, 速度快了2分钟,或者5分钟。但是一点一滴的调优,积少成多。最后还是会有效果的。

五、使用注意事项

1、广播变量在Driver端定义

2、广播变量在Execoutor只能读取不能修改

3、广播变量的值只能在Driver端修改

4、不能将RDD广播出去,RDD不存数据,可以将RDD的结果广播出去,rdd.collect()

spark中的广播变量_hyj-优快云博客

【spark分区】

rdd作为一个分布式的数据集,是分布在多个worker节点上的。如下图所示,RDD1有五个分区(partition),他们分布在了四个worker nodes 上面,RDD2有三个分区,分布在了三个worker nodes上面。


Spark 分区? - Marvin的回答 - 知乎

### Spark SQL 的底层执行引擎 Spark SQL 的底层执行引擎基于 Catalyst 查询优化器和 Tungsten 物理执行框架共同实现。Catalyst 是一种模块化的查询优化框架,它利用 Scala 函数式编程特性来表示逻辑计划树并对其进行转换[^3]。具体来说: - **Catalyst 查询优化器** 负责将用户的 SQL 或 DataFrame 操作转化为高效的物理执行计划。这一过程主要包括四个阶段:分析(Analysis)、逻辑优化(Logical Optimization)、物理规划(Physical Planning)以及代码生成(Code Generation)。其中,表达式代码生成由 `org.apache.spark.sql.catalyst.expressions.codegen.CodeGenerator` 类及其子类完成,这些子类负责生成高度优化的 Java 字节码以加速执行效率。 - **Tungsten 计划** 则专注于提升 Spark SQL 的性能,通过减少内存占用和提高 CPU 使用率来改进物理执行层面的表现。Tungsten 引入了更紧凑的数据表示形式、向量化处理以及高效的任务调度机制,从而显著提升了大规模数据集上的计算能力[^2]。 当用户提交一条 SQL 语句时,这条语句会被解析成抽象语法树 (AST),随后经过 Catalyst 的各个阶段逐步转化成为最终可被执行的 RDD 操作序列。整个过程中涉及到了多个组件间的协作,例如 Hive MetaStore 提供元数据支持而 Thrift Server 则作为长期运行的服务接受外部请求并通过 JDBC/ODBC 接口返回结果[^1]。 以下是展示如何启动 Spark ThriftServer 并连接到它的简单 Python 示例代码片段: ```python from pyspark.sql import SparkSession spark = SparkSession.builder \ .appName("StartThriftServer") \ .enableHiveSupport() \ .getOrCreate() # 启动 ThriftServer spark.conf.set("hive.server2.thrift.port", "10000") spark.sql("START THRIFTSERVER") print("ThriftServer has been started on port 10000.") ``` 此脚本创建了一个新的 SparkSession 实例,并启用了对 Hive 表的支持功能;接着设置好监听端口号之后便可以正式开启服务等待来自不同客户端的应用程序接入访问资源了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值