Spark 运行状态监控与优化

关注

发布于: 2021 年 04 月 17 日

当我们调试 spark 程序或者排查任务运行状态的时候，除了看 spark 提供的原生日志以外，spark 还为我们提供了很好的监控工具 Monitor，具体的参数详情可以参考Monitoring and Instrumentation。我们本章通过讲解一个 spark 进行资源优化和并发调整的例子来演示如何用好 Monitor 工具。

1、测试环境

队列总资源

2、任务测试

(1)任务配置-1

运行情况

监控内容：上图是 SPARK 任务监控的几个方面，Jobs 是一个 Application 包含的 Job 详情，一个 Application 可能包含一个或多个 Job；Stages 是一个 Job 包含的 Stage 详情，一个 Job 会被划分为一个或多个 Stage；Environment 包含了 Application 提交的配置信息；Executor 包含了运行的 Executor 数以及 Executor 中的 Task 信息；SQL 可以查看具体的任务执行详情。

Executor 分析：在 Executor 中，我们看到如上图所示的详情，从 Summary 的统计的中，我们可以看到整个任务启动的 Executor 有 24 个，我们也可以推算出来，24 个 Executor 大约 200G，加上其他的一些内存耗费，基本上用完了整个队列 240G 的内存资源。

Jobs 分析：通过 Jobs 模块可以查看 Application 的每个 Job 的运行时间。

(2)任务配置-2

我们修改配置，将内存减为原来的一半，再继续跑一下测试。

运行情况

Executor 分析：在 Executor 中，我们看到如上图所示的详情，从 Summary 的统计的中，我们可以看到整个任务启动的 Executor 有 30 个了，我们同样也可以推算出来，30 个 Executor 大约 120G 内存，加上其他的一些内存耗费，可能整个队列还剩一百多的内存剩余，但是为什么不继续开 Executor 了呢，因为 30 个 Executor 已经用完了 60 个 core，我们的整个队列资源上限就是 60 个 core，所以相当于内核限制了并发上限。

Jobs 分析：这是通过 Jobs 看到的具体 Job 运行信息，在这里，我们惊奇的发现，虽然并发提高了一点点，但是具体的 Job 运行时间并没有缩短，这就有点违背常理。于是我有调整以下配置，将 Executor 内存可劲儿调大到 16G。

(3)任务配置-3

运行情况

Executor 分析：通过上面我们看到，Executor 总数大大缩减了只有 13 个，并发性能大大减少，那再看一下 Job 运行时间是否有改变。

Jobs 分析：可以看到，其中 Job1 的运行时间确实增为原来的 2 倍左右，说明内存和并发对性能还是有影响的。但是，Job2 和 Job3 的时间似乎并没有改变，而且可以发现，三个配置的 Job2/3 的运行时间都没什么改变，这是什么原因呢。

于是通过 Executor 模块查看 Executor 的具体任务运行详情，可以看到 Executor18 和 19 的运行任务数远超过其他的 Executor，这就说明在任务分配的时候，出现了任务分配不均的问题。根据经验，我们自然而然的想到数据本地性的问题，数据本地性就是 task 在执行前都会获取数据的分区信息进行分配，总是会优先将其分配到它要计算的数据所在节点，尽可能的减少网络传输。所以，我又进行了数据本地性的验证。