15，spark history webUI使用姿势

Environment

环境配置包括了几本的环境信息，和spark properties, 以及各种加载的jar包。
了解这些配置是我们排查问题的前提。

• 一般而言，我们通过spark-submit,以及其他方式运行spark-application, 通过Environment，我们可以看到一些基础的配置设置是否和目的一样。比如设置的spark.executor.core, spark.executor.memory是否和传参一致。
• 关于hadoop的相关properties,在这里是看不到的，如果想要看到可以自己写代码从sparkContext里面打印出来，或者通过配置spark.logConf=true，可以查看。

环境信息是排查问题首先要查看的地方，关于传参的一些配置是否被其他配置覆盖，这个地方基本都能看得到。比如常见的申请的并发数，yarn中临时目录的配置，jar包是否被更新等等，都可以在这个地方看的到。

Executors

• 这个是整个applications启动过的所有executors和driver。通过driver-stderr可以查看driver收集到的日志,每一个executor的日志也可以通过对应executor的stderr中查看。
• 以下图为例，红色的部分可以查看失败的Tasks, GC的一些情况，这些可以帮助我们排查一些问题，比如如果GC占用TaskTime的比例过高，考虑是否增加executor的内存大小，或者使用其他的GC收集算法。
• 对于正在运行中的application, 可以查看对应executor的threadDump, thread信息可以帮助我们查看当前executor正在干什么？是否有复杂的逻辑计算拖累了整体的运行进度,很多spark的bug和比较慢的处理片段都是通过thead信息得到的。具体的方式是查看driver或者executor里面threadState=RUNNING的线程
  

Executors的信息，我用的最多的还是日志和ThreadDump, 日志可以帮助我看到执行的流程和报错的位置，threadDump可以帮助我排查一些性能的问题。比如在读取hdfs比较慢的情况，和逻辑计算加载UDF性能比较差导致的性能问题，以及spark内部的一些bug。都可以通过threadDump中得到。

SQL

sql里面包含了各种执行计划的情况，通过详细的执行计划逻辑，我们可以知道表的查询方式和具体的查询过程。

• 表的大小和文件数，
• 表join的方式，是否需要广播等
• 查询的解析，分析，优化，物理计划的详细过程。

我们可以看到哪些逻辑被优化，数据被获取的方式，分区的方式等等。

SQL部分我主要用到的还是执行计划的部分，通过执行计划能够看到所有的执行逻辑，比如关于读取RC-File, ORC文件，其实不同的配置读取是不同的，以及各种下推的逻辑，有时候文件读取比较慢的问题，其实和问题的类型有很大的关系，如何修改并发度读取，很多时候需要看具体的执行计划，才知道需要怎么修改配置。还有一种就是表的join方式，对于慢任务而言，有时候一些表不大不小，可以适当的增加广播文件的大小，来提高性能。

Stage

stage需要关注三个方面

• DAG的过程，这个可以知道这个stage在干嘛，是shuffle,还是数据获取。
• 监控数据Summary Metrics ，这个可以看到输入数据，输出数据，最终要的是task的执行时间，最大值，最小值，中间值，以此来判断是否有慢任务。
• 如果有慢任务，就需要查看具体的task信息，对比inputSize, Shuffle WriterSize, GCTime等，通过与其他task对比，可以判断是否有数据倾斜，以及并发数是否太小。

Stages的部分，需要看的场景大部分是读取文件切分有问题，shuffle时候并发度有问题，数据倾斜问题。一般根据DAG的图和task的详细信息可以得到。

更加详细的可以参考这篇博客，这里就不再赘述。
https://mp.weixin.qq.com/s/3xzJMgo4QsB6BzCn4GgYWw