spark基本原理&amp；UI界面解读_spark ui，通过五轮面试斩获offer阿里实习生亲述

本文链接：https://blog.csdn.net/2401_84166896/article/details/137489791

本文深入探讨Spark UI，重点分析Executor的负载情况、Environment的配置信息和SQL执行计划。通过Executor的summary和详细信息，可以评估数据倾斜；Environment中的spark properties揭示运行时设置；SQL部分展示了执行计划和性能指标，帮助理解任务执行效率。

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

入口页	包含内容。作用
jobs	actions，以及数据的读取与移动等操作。作业详情预览
stages	DAG中每个stage的入口。作业详情预览
storage	分布式数据集缓存(cache)详情页。审查cache在内存与磁盘中的分布情况
storage	分布式数据集缓存(cache)详情页。审查cache在内存与磁盘中的分布情况
environment	配置项，环境变量详情。审查spark配置项是否符合预期
executors	分布式运行环境与计算负载详情页。深入审查执行计划中的每一个环节

JOB：作业详情的预览

什么情况下spark会产生一个job？对应的action算子会产生，对应的数据的读取和移动操作。

stage。一个Job可以拆分为多个stage。job拆分stage的详细情况。划分stage的依据是宽窄依赖
storage。在cache数据的时候，会有应用。
environment。spark任务的配置项、环境变量。
executor。分布式运行环境计算负载的详情页，作用是审查executor之间是否存在数据倾斜。比如，看input的数据的差异用于评估负载情况。
SQL。spark SQL执行计划的详情页。

executor、environment、storage不存在二级入口，但是SQL、storage、JOBs有二级入口

2.1.1 executors

2.1.1.1 summary

在这里插入图片描述

RDD blocks：原始分区数据集的分区数量
storage memory：用于cache时所占的内存的占用情况。
disk used。计算过程中消耗的磁盘空间。
cores。用于计算的CPU的核数。
acitive task：活跃的task数量
failed task：失败的task数量
complete task：完成的task数量
task time(GC time)。任务的执行时候，以及任务的GC时间
input。输入数据量的大小
shuffle read 大小
shuffle write 大小
blocklisted。黑名单

2.1.1.2 executors

executors tab的主要内容如下，主要包含“summary”和“executors”两部分。这两部分记录的度量指标是一致的，其中“executors”以更新粒度记录者每一个executor的详情，而第一部分“summary”是下面所有executors度量指标的简单加和。
sparkUI都提供了哪些metrics，来量化每一个executor的工作负载（workload）。

metric	含义
RDD	原始数据集的分区数量
storage memory	用于cache的内存占用
disk used	计算过程中消耗的磁盘空间
cores	用于计算的CPU核数
active/failed/complete	total tasks
task time(GC time)	任务执行时间(括号内为任务GC时间)
input	输入数据量大小
shuffle head/write	shuffle读写过程中消耗的数据量
logs/thread dump	日志与core dump

不难发现，executors页面清清楚楚的记录着每一个executor消耗的数据量，以及他们对CPU、内存与磁盘等硬件资源的消耗。基于这些信息，我们可以轻松判断应用中是否存在数据倾斜的隐患。
Thread Dump。Java中的诊断工具，每个JVM都可以显示所有线程在某一个点的状态，用作Java定位问题的诊断功能。

runnable。当前可以运行的线程
timed-waiting。线程主动等待的意思。
waiting。等待的线程。

summary是executors所有指标聚合的情况。
基于这些信息，盘点不同executor之间是否存在负载不均衡的情况、数据倾斜的隐患。

2.1.2 environment

各种各样环境变量与配置信息。

metric	含义
runtime information	Java Scala版本号信息
spark properties	所有spark配置项的设置细节，重点
Hadoop properties	hadoop配置项细节
system properties	应用提交方法(spark-shell/spark-submit)
classpath entries	classpath路径设置信息

spark properties是重点。其中记录着所有运行时生效的spark配置项设置。通过spark properties，我们可以确认运行时的设置，与我们预期的设置是否一致，从而排除因配置项设置错误而导致的稳定性或是性能问题。

2.1.2.1 runtime information

在这里插入图片描述

2.1.2.2 spark properties

spark任务的各种配置项、判断参数是否合理
在这里插入图片描述

2.1.2.3 resource properties

不重要
在这里插入图片描述

2.1.2.4 Hadoop properties

Hadoop的各种配置项

2.1.2.5 system properties

系统配置项，可以看启动命令。sum.java.command

2.1.2.6 classpath properties

配置、jar包的路径

2.1.3 storage

在这里插入图片描述

记录了每一个缓存，rdd cache、dataframe cache。包括缓存级别、已缓存的分区数、缓存比例、内存大小与磁盘大小。
spark支持不同的缓存级别，他是存储介质(内存、磁盘)、存储形式(对象、序列化字节)与副本数量的排列组合。对于data frame来说，默认的级别是单副本的disk memory deserialized，也就是存储介质为内存加磁盘，粗出形式为对象的单一副本存储方式。

metric	含义
storage level	存储级别
cached partitions	已缓存的分区数
fraction caches	缓存比例
size in memory	内存大小
size on disk	磁盘大小

cached partitions 和fraction caches分别记录着数据集成功缓存的分区数量，以及这些缓存的分区占所有分区的比例。当fraction cached小于100%的时候。说明分布式数据集并没有完全缓存到内存(或是磁盘)。对于这种情况，我们要警惕缓存换入换出可能带来的性能隐患。
基于storage页面提供的详细信息，我们可以有的放失的设置于内存有关的配置项，如spark.executor.memory、spark.executor.fraction、spark.executor.storageFraction、从而有针对性的对storage memory进行调整。
cache partitions 已缓存的分区数
fraction cached。缓存的比例，代表缓存的分区占所有分区的比例，当小于100%的时候，代表分布式的数据没有完全划分到内存或者磁盘里面。

缓存换入换出，有可能带来性能的问题。

size in memory。内存缓存的大小

storage memory不足的情况下，会把他size到磁盘里面。

size in disk。磁盘缓存的大小

2.1.4 SQL

在这里插入图片描述

以actions为单位，记录着每个action对应的sparksql执行计划。我们需要点击“description”列中的超链接，才能进入到二级页面，去了解每个执行计划的详细信息。
Jobs：同理，低于jobs来说，spark ui也是以actions为粒度，记录着每个action对应作业的执行情况。我们要了解作业详情页，也必须通过“description”页面提供的二级入口链接。
一个action对应一个query，一个query会有多个job id。
以actions为单位，记录着每个action对应的spark sql执行计划。我们需要点击“description”列中的超链接，才能进入到二级页面，去了解每个执行计划的详细信息。

2.1.4 JOBs

在这里插入图片描述

description。描述
submitted。提交时间
duration。执行时间
stage。成功

2.1.4 stage

在这里插入图片描述

我们知道，每一个作业，都包含多个阶段，就是我们常说的stages。在stages页面，spark ui罗列了应用中涉及的所有stage，这些stages分属于不同的作业。要想查看哪些stages隶属于哪个job，还需要从jobs的descritions二级入口进入查看。
stage页面，更多的是一种预览，要想查看每一个stage的详情，同样需要从“description”进入详情页。

总结：

一级入口	重点内容
executors	不同executors之间，是否存在负载倾斜
environment	不同executors之间，是否存在负载倾斜
storage	分布式数据集的缓存级别，内存，磁盘缓存比例
SQL	初步了解不同执行计划的执行时间，确实是否符合预期
jobs	初步感知不同jobs的执行时间，确实是否符合预期
stage	初步感知不同stage的执行时间，确实是否符合预期

记录了以action为粒度，记录了每个action作业的情况。
executor可以看到不同executor负载情况、执行情况，判断数据倾斜
environment可以看到spark任务的配置情况，判断配置是否合理。参数的配置。

配置优先级：code>conf>默认

SQL。可以了解不同任务执行时间是否符合预期。
job。可以看到job的执行情况，是否符合预期
storage。可以看到storage的执行情况，是否符合预期
stage。可以看到stage的执行情况，是否符合预期

2.2 spark UI二级入口

所为二级入口，指的是通过一次超链接跳转才能访问到的页面。对于SQL、jobs和stages这三类入口来说，二级入口往往已经提供了足够的信息，基本覆盖了“体检报告”的全部内容。因此，尽管spark UI也提供了少量的三级入口(需要凉调才能到达的页面)，但是这些隐藏在“犄角旮旯”的三级入口，往往不需要开发者去特别关注。
接下来我们就沿着sql->job->stages的顺序，一次的去访问他们的耳机入口，从而针对全局dag，作业以及执行阶段，获得更加深入的探索和洞察。

2.2.1 sql详情页

在 SQLtab一级入口，我们看到有1个条目
点击图中的“description”，即可进入到该作业的执行计划页面，如下图所示。

2.2.1.1 exchange

在这里插入图片描述

可以看到，对应每一个exchange，spark ui都提供了丰富的metrics来刻画shuffle的计算过程。从shuffle write到shuffle read，从数据量到处理时间，应有尽有。

metrics	含义
shuffle records written	shuffle write阶段写入的数据条目数量
shuffle write time total	shuffle write阶段花费的写入时间
records read	shuffle read阶段读取的数据条目数量
local bytes read total	shuffle read阶段从本地节点读取的数据总量
fetch wait time total	shuffle read阶段花费在网络传输上的时间
remote bytes read total	shuffle read阶段跨网络、从远端节点读取的数据总量
date size total	原始数据在内存中展开之后的总大小
remote bytes read to disk	shuffle read阶段因数据块过大而直接落盘的情况
shuffle bytes written total	shuffle中间文件总大小

结合这份shuffle的体检报告，我们就能一量化的方式，去掌握shuffle过程的计算细节，从而为调优提供更多的洞察和思路。

2.2.1.2 sort

接下来，我们再来说说sort。相比exchange，sort的度量指标没有那么多，不过，他们足以让我们一窥sort再运行时，对内存的消耗，如下图所示。
-

metrics	含义
sort time total	排序消耗的总时间
peak memory total	内存的消耗峰值(集群范围内)
spill size total	排序过程中移除到磁盘的数据总量

可以看到“peak memory total ”和“spill size total”这两个数值，足以指导我们更有针对性的去设置spark.executor.memory、spark.memory.fraction、spark.memory.storageFraction，从而使得execution memory区域得到充分的保障。