spark基本原理&;UI界面解读_spark ui,中高级大数据开发面试题目汇总解答
一级入口重点内容executors不同executors之间,是否存在负载倾斜不同executors之间,是否存在负载倾斜storage分布式数据集的缓存级别,内存,磁盘缓存比例SQL初步了解不同执行计划的执行时间,确实是否符合预期jobs初步感知不同jobs的执行时间,确实是否符合预期stage初步感知不同stage的执行时间,确实是否符合预期记录了以action为粒度,记录了每个action作
先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新大数据全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip204888 (备注大数据)
正文
18. DAG会被提交到dag scheduler解析
19. DAG图会被切为很多个阶段 stage
20. 每个stage又分为若干个任务
21. 每一个阶段stage是任务的集合
22. 把这个阶段stage提交给task scheduler
23. task scheduler负责分发任务
24. worker node上的executor会向task scheduler主动申请
25. task scheduler会返回任务给worker node上的executor去派生线程去执行
26. 计算给节点的分发原则:
27. 计算向数据靠拢。数据在哪个节点上面,task scheduler优先分配,完成本地化的处理。
28. executor运行的结果会再次反馈给task scheduler
29. 再向上传给 dag scheduler
30. spark context做最后的处理。返回给用户看或者写入HDFS
31. sparkcontext:代表了整个应用程序连接集群的通道。链接应用和集群
1.2 核心原理
1.2.1 关键概念
driver: 该进程调用spark程序的main方法,并且启动sparkcontext
cluster Manager:该进程负责和外部集群工具打交道,申请或释放集群资源
Woker:该进程是一个守护进程,负责启动和管理executor
executor:该进程是一个JVM虚拟机。负责运行spark task
1.2.2 运行步骤
- 启动driver,创建sparkcontext
- client提交程序给driver,driver向cluster manager申请集群资源
- 资源申请完毕,在worker中启动executor
- driver将程序转化为tasks,分发给executor执行
1.2.3 spark运行模型
1.2.3.1 单机
使用线程模拟并行来运行程序
- 一般用于测试开发
- 不能启动spark的master、worker守护进程
- 不能启动Hadoop的各项服务
- sparksubmit进程是客户提交任务的client进程,又是spark的driver程序、还充当着spark执行task的executor的角色
1.2.3.2 集群
使用集群管理器来和不同类型的集群交互,将任务运行在集群中。
- spark standalone
- hadoop yarn
- Apache mesos
- kubernetes
2 Spark UI深入解读
- 在日常的开发工作中,我们总会遇到spark应用运行失败,或者执行效率不达预期的情况。对于这样的问题,想找到根本原因(root cause),就可以通过spark ui来获取最直接、最直观的线索,在全量的审查spark应用的同时,迅速定位问题所在。
- 如果我们把失败的、或是执行低效的spark应用看做是“病人”的话,那么spark ui中关于应用的众多衡量指标(metrics),就是这个病人的“体检报告”。结合多样的metrics,身为“大夫”的开发者可以结合经验来迅速定位“病灶”。
2.1 spark UI一级入口
打开spark UI,映入眼帘的是默认的Jobs页面。JObs页面记录着应用中涉及的actions动作,以及与数据读取、移动有关的动作。其中每一个action都对应着一个job,而每一个job都对应着一个作业。我们一会再去对jobs页面做展开,现在先把目光集中在spark ui最上面的导航条,这里面罗列这spark ui的所有一级入口
入口页 | 包含内容。作用 |
---|---|
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阶段因数据块过大而直接落盘的情况 |
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip204888 (备注大数据)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
ad阶段跨网络、从远端节点读取的数据总量 |
| date size total | 原始数据在内存中展开之后的总大小 |
| remote bytes read to disk | shuffle read阶段因数据块过大而直接落盘的情况 |
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip204888 (备注大数据)
[外链图片转存中…(img-OFodBh8e-1713153723760)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
更多推荐
所有评论(0)