手把手带你了解Spark作业“体检报告” --Spark UI

  • Spark UI 一级入口
    • Executors
    • Environment
    • Storage
    • SQL
    • Jobs
    • Stages
    • 总结
    • 扩展
  • Spark UI 二级入口
    • SQL 详情页
    • Exchange
    • Sort
    • Aggregate
    • Jobs 详情页
    • Stages 详情页
    • Stage DAG
    • Event Timeline
    • Task Metrics
    • Summary Metrics
    • Tasks

Spark UI 一级入口

集中在 Spark UI 最上面的导航条，这里罗列着 Spark UI 所有的一级入口，如下图所示。

        可以看到，导航条最左侧是 Spark Logo 以及版本号，后面则依次罗列着 6 个一级入口，每个入口的功能与作用我整理到了如下的表格中，你可以先整体过一下，后面我们再挨个细讲。

Executors

Executors Tab 的主要内容如下，主要包含“Summary”和“Executors”两部分。这两部分所记录的度量指标是一致的，其中“Executors”以更细的粒度记录着每一个 Executor 的详情，而第一部分“Summary”是下面所有 Executors 度量指标的简单加和。

Spark UI 都提供了哪些 Metrics，来量化每一个 Executor 的工作负载（Workload）。为了叙述方便，我们以表格的形式说明这些 Metrics 的含义与作用。

不难发现，Executors 页面清清楚楚地记录着每一个 Executor 消耗的数据量，以及它们对 CPU、内存与磁盘等硬件资源的消耗。基于这些信息，我们可以轻松判断不同 Executors 之间是否存在负载不均衡的情况，进而判断应用中是否存在数据倾斜的隐患。对于 Executors 页面中每一个 Metrics 的具体数值，它们实际上是 Tasks 执行指标在 Executors 粒度上的汇总。

Environment

Environment 页面记录的是各种各样的环境变量与配置项信息，如下图所示。

就类别来说，它包含 5 大类环境信息，为了方便叙述，我把它们罗列到了下面的表格中。

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

Storage

Storage 详情页，记录着每一个分布式缓存（RDD Cache、DataFrame Cache）的细节，包括缓存级别、已缓存的分区数、缓存比例、内存大小与磁盘大小。
        Spark 支持的不同缓存级别，它是存储介质（内存、磁盘）、存储形式（对象、序列化字节）与副本数量的排列组合。对于 DataFrame 来说，默认的级别是单副本的 Disk Memory Deserialized，如上图所示，也就是存储介质为内存加磁盘，存储形式为对象的单一副本存储方式。

Cached Partitions 与 Fraction Cached 分别记录着数据集成功缓存的分区数量，以及这些缓存的分区占所有分区的比例。当 Fraction Cached 小于 100% 的时候，说明分布式数据集并没有完全缓存到内存（或是磁盘），对于这种情况，我们要警惕缓存换入换出可能会带来的性能隐患。
        Size in Memory 与 Size in Disk，则更加直观地展示了数据集缓存在内存与硬盘中的分布。从上图中可以看到，由于内存受限（3GB/Executor），摇号数据几乎全部被缓存到了磁盘，只有 584MB 的数据，缓存到了内存中。坦白地说，这样的缓存，对于数据集的重复访问，并没有带来实质上的性能收益。
        基于 Storage 页面提供的详细信息，我们可以有的放矢地设置与内存有关的配置项，如 spark.executor.memory、spark.memory.fraction、spark.memory.storageFraction，从而有针对性对 Storage Memory 进行调整。

SQL

当我们的应用包含 DataFrame、Dataset 或是 SQL 的时候，Spark UI 的 SQL 页面，就会展示相应的内容，如下图所示。

一级入口页面，以 Actions 为单位，记录着每个 Action 对应的 Spark SQL 执行计划。我们需要点击“Description”列中的超链接，才能进入到二级页面，去了解每个执行计划的详细信息。

Jobs

Jobs 页面来说，Spark UI 也是以 Actions 为粒度，记录着每个 Action 对应作业的执行情况。

相比 SQL 页面的 3 个 Actions：save（保存计算结果）、count（统计申请编号）、count（统计中签编号）。
        结合前面的概览页截图你会发现，Jobs 页面似乎凭空多出来很多 Actions。主要原因在于，在 Jobs 页面，Spark UI 会把数据的读取、访问与移动，也看作是一类“Actions”，比如图中 Job Id 为 0、1、3、4 的那些。这几个 Job，实际上都是在读取源数据（元数据与数据集本身）。
        至于最后多出来的、Job Id 为 7 的 save，你不妨结合下面代码

result05_01.write.mode("Overwrite").format("csv").save(s"${rootPath}/results/result05_01")

Stages

在 Stages 页面，Spark UI 罗列了应用中涉及的所有 Stages，这些 Stages 分属于不同的作业。要想查看哪些 Stages 隶属于哪个 Job，还需要从 Jobs 的 Descriptions 二级入口进入查看。

Stages 页面，更多地是一种预览，要想查看每一个 Stage 的详情，同样需要从“Description”进入 Stage 详情页

总结

扩展

  1. 一个是在 Executors 页面，为什么 RDD Blocks 与 Complete Tasks 的数量不一致？
            每个rdd经过处理后，又可能生成其他rdd，这里的tasks显示的是整个executors处理过的任务数，跟rdd cache的blocks无关。
  2. 在 Jobs 页面，为什么最后会多出来一个 save Action？
            因为代码最后一个是save，而save的mode是overwrite，save本身会有一个action，而overwrite的过程，实际上是先在临时文件夹生成数据，然后再move到目标文件夹，有一个数据移动的动作，所以Spark也把它算做了一个Action。

Spark UI 二级入口

所谓二级入口，它指的是， 通过一次超链接跳转才能访问到的页面。对于 SQL、Jobs 和 Stages 这 3 类入口来说，二级入口往往已经提供了足够的信息

SQL 详情页

在 SQL Tab 一级入口，我们看到有 3 个条目，分别是 count（统计申请编号）、count（统计中签编号）和 save。前两者的计算过程，都是读取数据源、缓存数据并触发缓存的物化，相对比较简单，因此，我们把目光放在 save 这个条目上。

点击图中的“save at:27”，即可进入到该作业的执行计划页面，如下图所示。

        为了方便你阅读，这里我手绘出了执行计划的示意图，供你参考，如下图所示。

过滤、投影、关联、分组聚合和排序。图中红色的部分为 Exchange，代表的是 Shuffle 操作，蓝色的部分为 Sort，也就是排序，而绿色的部分是 Aggregate，表示的是（局部与全局的）数据聚合。
无疑，这三部分是硬件资源的主要消费者，同时，对于这 3 类操作，Spark UI 更是提供了详细的 Metrics 来刻画相应的硬件资源消耗。接下来，咱们就重点研究一下这 3 类操作的度量指标。

Exchange

下图中并列的两个 Exchange，对应的是示意图中 SortMergeJoin 之前的两个 Exchange。它们的作用是对申请编码数据与中签编码数据做 Shuffle，为数据关联做准备。

对于每一个 Exchange，Spark UI 都提供了丰富的 Metrics 来刻画 Shuffle 的计算过程。从 Shuffle Write 到 Shuffle Read，从数据量到处理时间，应有尽有。为了方便说明，对于 Metrics 的解释与释义，我以表格的方式进行了整理，供你随时查阅。

比方说，我们观察到过滤之后的中签编号数据大小不足 10MB（7.4MB），这时我们首先会想到，对于这样的大表 Join 小表，Spark SQL 选择了 SortMergeJoin 策略是不合理的。
        基于这样的判断，我们完全可以让 Spark SQL 选择 BroadcastHashJoin 策略来提供更好的执行性能。至于调优的具体方法，想必不用我多说，你也早已心领神会：要么用强制广播，要么利用 3.x 版本提供的 AQE 特性。

Sort

可以看到，“Peak memory total”和“Spill size total”这两个数值，足以指导我们更有针对性地去设置 spark.executor.memory、spark.memory.fraction、spark.memory.storageFraction，从而使得 Execution Memory 区域得到充分的保障。
        以上图为例，结合 18.8GB 的峰值消耗，以及 12.5GB 的磁盘溢出这两条信息，我们可以判断出，当前 3GB 的 Executor Memory 是远远不够的。那么我们自然要去调整上面的 3 个参数，来加速 Sort 的执行性能。

Aggregate

对于 Aggregate 操作，Spark UI 也记录着磁盘溢出与峰值消耗，即 Spill size 和 Peak memory total。这两个数值也为内存的调整提供了依据，以上图为例，零溢出与 3.2GB 的峰值消耗，证明当前 3GB 的 Executor Memory 设置，对于 Aggregate 计算来说是绰绰有余的。
        结合上述的各类 Metrics，对于执行计划的观察与洞见，我们需要以统筹的方式，由点到线、由局部到全局地去进行。

Jobs 详情页

Jobs 详情页非常的简单、直观，它罗列着隶属于当前 Job 的所有 Stages。要想访问每一个 Stage 的执行细节，我们还需要通过“Description”的超链接做跳转。

Stages 详情页

要访问 Stage 详情，我们还有另外一种选择，那就是直接从 Stages 一级入口进入，然后完成跳转。因此，Stage 详情页也归类到二级入口。接下来，我们以 Id 为 10 的 Stage 为例，去看一看详情页都记录着哪些关键信息。
        Stage 详情页的信息量可以说是最大的。点进 Stage 详情页，可以看到它主要包含 3 大类信息，分别是 Stage DAG、Event Timeline 与 Task Metrics。其中，Task Metrics 又分为“Summary”与“Entry details”两部分，提供不同粒度的信息汇总。而 Task Metrics 中记录的指标类别，还可以通过“Show Additional Metrics”选项进行扩展。

Stage DAG

Stage DAG。点开蓝色的“DAG Visualization”按钮，我们就能获取到当前 Stage 的 DAG，如下图所示。

之所以说 Stage DAG 简单，是因为咱们在 SQL 二级入口，已经对 DAG 做过详细的说明。而 Stage DAG 仅仅是 SQL 页面完整 DAG 的一个子集，毕竟，SQL 页面的 DAG，针对的是作业（Job）。因此，只要掌握了作业的 DAG，自然也就掌握了每一个 Stage 的 DAG。

Event Timeline

与“DAG Visualization”并列，在“Summary Metrics”之上，有一个“Event Timeline”按钮，点开它，我们可以得到如下图所示的可视化信息。
        Event Timeline，记录着分布式任务调度与执行的过程中，不同计算环节主要的时间花销。图中的每一个条带，都代表着一个分布式任务，条带由不同的颜色构成。其中不同颜色的矩形，代表不同环节的计算时间。
        为了方便叙述，我还是用表格形式帮你梳理了这些环节的含义与作用，你可以保存以后随时查看。

条带的大部分应该都是绿色的（如图中所示），也就是任务的时间消耗，大部分都是执行时间。不过，实际情况并不总是如此，比如，有些时候，蓝色的部分占比较多，或是橙色的部分占比较大。
在这些情况下，我们就可以结合 Event Timeline，来判断作业是否存在调度开销过大、或是 Shuffle 负载过重的问题，从而有针对性地对不同环节做调优。
        比方说，如果条带中深蓝的部分（Scheduler Delay）很多，那就说明任务的调度开销很重。这个时候，我们就需要参考“三足鼎立”的调优技巧，去相应地调整 CPU、内存与并行度，从而减低任务的调度开销。
        再比如，如果条带中黄色（Shuffle Write Time）与橙色（Shuffle Read Time）的面积较大，就说明任务的 Shuffle 负载很重，这个时候，我们就需要考虑，有没有可能通过利用 Broadcast Join 来消除 Shuffle，从而缓解任务的 Shuffle 负担。

Task Metrics

Task Metrics 以不同的粒度，提供了详尽的量化指标。其中，“Tasks”以 Task 为粒度，记录着每一个分布式任务的执行细节，而“Summary Metrics”则是对于所有 Tasks 执行细节的统计汇总。我们先来看看粗粒度的“Summary Metrics”，然后再去展开细粒度的“Tasks”。

Summary Metrics

点开“Show Additional Metrics”按钮，勾选“Select All”，让所有的度量指标都生效，如下图所示。这么做的目的，在于获取最详尽的 Task 执行信息。

“Select All”生效之后，Spark UI 打印出了所有的执行细节。老规矩，为了方便叙述，我还是把这些 Metrics 整理到表格中，方便你随时查阅。其中，Task Deserialization Time、Result Serialization Time、Getting Result Time、Scheduler Delay 与刚刚表格中的含义相同，不再赘述，这里我们仅整理新出现的 Task Metrics。

对于这些详尽的 Task Metrics，难能可贵地，Spark UI 以最大最小（max、min）以及分位点（25% 分位、50% 分位、75% 分位）的方式，提供了不同 Metrics 的统计分布。这一点非常重要，原因在于，这些 Metrics 的统计分布，可以让我们非常清晰地量化任务的负载分布。
        根据不同 Metrics 的统计分布信息，我们就可以轻而易举地判定，当前作业的不同任务之间，是相对均衡，还是存在严重的倾斜。如果判定计算负载存在倾斜，那么我们就要利用“手工加盐”或是 AQE 的自动倾斜处理，去消除任务之间的不均衡，从而改善作业性能。
        在上面的表格中，有一半的 Metrics 是与 Shuffle 直接相关的，比如 Shuffle Read Size / Records，Shuffle Remote Reads，等等。
        这些 Metrics 我们在介绍 SQL 详情的时候，已经详细说过了。另外，Duration、GC Time、以及 Peak Execution Memory，这些 Metrics 的含义，要么已经讲过，要么过于简单、无需解释。因此，对于这 3 个指标，咱们也不再多着笔墨。
        这里特别值得你关注的，是 Spill（Memory）和 Spill（Disk）这两个指标（Spill数据在内存中的总尺寸，就是Spill（Memory)，在磁盘中的总大小，就是Spill（Disk））。Spill，也即溢出数据，它指的是因内存数据结构（PartitionedPairBuffer、AppendOnlyMap，等等）空间受限，而腾挪出去的数据。Spill（Memory）表示的是，这部分数据在内存中的存储大小，而 Spill（Disk）表示的是，这些数据在磁盘中的大小。
        因此，用 Spill（Memory）除以 Spill（Disk），就可以得到“数据膨胀系数”的近似值，我们把它记为 Explosion ratio。有了 Explosion ratio，对于一份存储在磁盘中的数据，我们就可以估算它在内存中的存储大小，从而准确地把握数据的内存消耗。

Tasks

Tasks 的不少指标，与 Summary 是高度重合的，如下图所示。同理，这些重合的 Metrics，咱们不再赘述，你可以参考 Summary 的部分，来理解这些 Metrics。唯一的区别，就是这些指标是针对每一个 Task 进行度量的。

按照惯例，咱们还是把 Tasks 中那些新出现的指标，整理到表格中，以备后续查看。

这里最值得关注的，是 Locality level，也就是本地性级别。在调度系统中，我们讲过，每个 Task 都有自己的本地性倾向。结合本地性倾向，调度系统会把 Tasks 调度到合适的 Executors 或是计算节点，尽可能保证“数据不动、代码动”。
        Logs 与 Errors 属于 Spark UI 的三级入口，它们是 Tasks 的执行日志，详细记录了 Tasks 在执行过程中的运行时状态。一般来说，我们不需要深入到三级入口去进行 Debug。Errors 列提供的报错信息，往往足以让我们讯速地定位问题所在。

手把手带你了解Spark作业“体检报告” --Spark UI相关推荐

  1. 结对作业项目报告——四则运算UI设计（UI第一组 PB16120211 章豪 PB16151063 吴宏宇）...

    一.项目要求 UI要求: 这是交付给最终用户的软件,有一定的界面和必要的辅助功能.完成Windows和Linux电脑图形界面的程序,需实现以下功能: 对上述各属性参数(生成题目的数量,操作数的数量,题 ...

  2. 手把手带你玩转Spark机器学习-使用Spark构建回归模型

    系列文章目录 手把手带你玩转Spark机器学习-专栏介绍 手把手带你玩转Spark机器学习-问题汇总 手把手带你玩转Spark机器学习-Spark的安装及使用 手把手带你玩转Spark机器学习-使用S ...

  3. 手把手带你玩转Spark机器学习-使用Spark进行数据处理和数据转换

    系列文章目录 手把手带你玩转Spark机器学习-专栏介绍 手把手带你玩转Spark机器学习-问题汇总 手把手带你玩转Spark机器学习-Spark的安装及使用 手把手带你玩转Spark机器学习-使用S ...

  4. 手把手带你玩转Spark机器学习-使用Spark进行数据降维

    系列文章目录 手把手带你玩转Spark机器学习-专栏介绍 手把手带你玩转Spark机器学习-问题汇总 手把手带你玩转Spark机器学习-Spark的安装及使用 手把手带你玩转Spark机器学习-使用S ...

  5. 24.大数据学习之旅——spark手把手带你入门

    Spark介绍 Apache Spark™ is a fast and general engine for large-scale data processing. Spark Introduce ...

  6. 手把手带你用Python完成一个数据分析项目，能写进简历那种！（另送15个实战案例）...

    最近几年,数据分析可真是太火了. 阿里.字节等互联网巨头基于大数据打造的商业模式获得巨大成功,使得"数据思维"."数据能力"迅速成为衡量职场人能力的核心指标,专 ...

  7. 手把手带你用Python完成一个数据分析项目，能写进简历，拿走不谢！（另送15个实战案例）...

    最近几年,数据分析可真是太火了. 阿里.字节等互联网巨头基于大数据打造的商业模式获得巨大成功,使得"数据思维"."数据能力"迅速成为衡量职场人能力的核心指标,专 ...

  8. 手把手带你用Python做数据分析和可视化项目实战，能写进简历的那种！（另送15个实战案例）...

    最近几年,数据分析可真是太火了. 阿里.字节等互联网巨头基于大数据打造的商业模式获得巨大成功,使得"数据思维"."数据能力"迅速成为衡量职场人能力的核心指标,专 ...

  9. 手把手带你掌握计算机视觉原始论文细节阅读

    人工智能研究在本质上是学术性的,在你能够获得人工智能的某些细节之前,需要掌握大量的跨各类学科的知识. 那么,阅读原始论文在学习的过程中有多重要? 原始论文细节阅读是互联网大厂人工智能岗位面试必考题,也 ...

最新文章

  1. H.265视频编码与技术全析（上）
  2. 010-012列表：一个打了激素的数组
  3. 行内标签（最常用的：a标签、img标签、span标签）
  4. Pyhton 操作MySQL数据库
  5. android之权限大全
  6. linux 编译zbar
  7. pytorch生成一个数组
  8. JQuery Datatables Ajax dataSrc的使用
  9. js设置控制滚动条位置
  10. PyCharm 在Windows的有用快捷键
  11. flatten的用法
  12. 有趣的python代码实例_Python之路：200个Python有趣的小例子一网打尽
  13. XML_CPP_资料_libXml2_01
  14. php和全栈,php与h5全栈工程师是什么意思
  15. php如何实现文件操作,php实现操作文件的各种方式总结（附代码）
  16. iframe框架_性能优化去除iframe脚手架升级方案
  17. clipboard.js使用方法
  18. 十大电子元器件及其相关基础知识
  19. 如何解决unity使用vs2017、vs2018、vs2019等 编辑器创建新项目时无法产生.sln文件的一个小办法
  20. 专题讲座3 数论+博弈论 学习心得

热门文章

  1. Linux~linux无法解析域名
  2. 盛世看增长，乱世看效率 from 思维碎片@知识星球
  3. c语言温度换算作业,怎么编写一个华氏摄氏度与摄氏温度之间的C语言转换程序?...
  4. 数据库迁移工具Kettle连接Mysql数据库报错：Driver class ‘org.gjt.mm.mysql.Driver‘ could not be found, make sure the解决
  5. java的栈区 堆区存放什么_简单整理java中的栈内存, 堆内存是什么？
  6. 经典的《Rework》
  7. 南艺计算机作曲专业怎样,南京艺术学院作曲与作曲技术理论专业/学费/录取分数线/怎么样...
  8. 强化学习算法：AC系列详解
  9. 基于matlab的运动模糊图像处理,基于matlab运动模糊图像处理
  10. 袋鼠云数据中台专栏（一） ：浅析数据中台策略与建设实践