先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7

深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年最新大数据全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
img
img
img
img
img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

如果你需要这些资料,可以添加V获取:vip204888 (备注大数据)
img

正文

在这里插入图片描述
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 运行步骤
  1. 启动driver,创建sparkcontext
  2. client提交程序给driver,driver向cluster manager申请集群资源
  3. 资源申请完毕,在worker中启动executor
  4. 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 (备注大数据)
img

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

ad阶段跨网络、从远端节点读取的数据总量 |
| date size total | 原始数据在内存中展开之后的总大小 |
| remote bytes read to disk | shuffle read阶段因数据块过大而直接落盘的情况 |

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以添加V获取:vip204888 (备注大数据)
[外链图片转存中…(img-OFodBh8e-1713153723760)]

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

Logo

永洪科技,致力于打造全球领先的数据技术厂商,具备从数据应用方案咨询、BI、AIGC智能分析、数字孪生、数据资产、数据治理、数据实施的端到端大数据价值服务能力。

更多推荐