一个spark任务的分析

1. 简述

这里主要是想要分析一个spark-on-yarn任务如何查看在yarn上的监控信息和程序运行的信息。

2. spark程序和提交命令

1. spark任务源代码（主要部分）

        SparkConf sparkConf = new SparkConf()
                .setAppName("UserProfileSynTask");
        if (localDeploy) {
            sparkConf.setMaster("local");
        }

        SparkSession sparkSession = SparkSession.builder().config(sparkConf).getOrCreate();
        Dataset<Row> userProfileSource = sparkSession.read().parquet(filePath);
        Dataset<Row> wantedCols = userProfileSource
                .select("uid", "fav", "reads", "search_words")
                .na().drop(new String[]{"uid"}).na().drop("all",new String[]{"fav", "reads", "search_words",});
       Dataset<UserReadRecord> searchUserProfile = wantedCols.mapPartitions(...);
       MyEsSparkSQL.saveToEs(searchUserProfile, esIndex);
       saveToRedis(searchUserProfile);

       Long total = searchUserProfile.count();
       System.out.println("---------total------------");

2. 使用的提交命令

spark2-submit --master yarn --deploy-mode  client   --queue root.dev --driver-memory 3g  --executor-memory 5g  --executor-cores 1   --num-executors 1   --conf spark.yarn.am.memory=2500M --class com.user_profile.UserProfileSynStarter  aaa.jar

程序户读取的文件是hdfs:///user/data/profile/dt=20200831下面所有的parquet文件，这个目录下总共有100个文件,每个文件的大小在150M左右

$ hsl  hdfs:///user/data/profile/dt=20200831|grep par|wc -l
100

3. 如何在yarn上查看

这个任务在yarn上面已经结束了

1. 找到对应的任务

根据setAppName("UserProfileSynTask");在yarn的任务后天进行搜索找到对应的任务，因为这个任务已经跑完了，所以显示的是history,点进去可以看到这个任务之前运行时候的一些环境

2. 任务的主监控页面

点击上面的history然后可以看到spark任务的监控页面

在这个页面的上面一行可以看到监控的主要维度有

1. job: 当前spark进程有哪些job
2. stage: 当前spark进程有哪些stage
3. storage: 存储的使用情况
4. environment: 当前spark进程主要运行环境信息
5. executors: 当前spark任务使用了哪些executor
6. SQL: spark任务有哪些sql操作

3. job页面

当前spark进程有哪些job,通过这个页面可以看到spark进程完成了哪些job,每个job的耗时等。

上图中总共有6个job
分别对应的代码是

1. job0 对应的是

Dataset<Row> userProfileSource = sparkSession.read().parquet(filePath);

1. job详情

是执行list file，点击job可以看到详情

2. stag0的信息

对应的有100个task,是不是对应的partition也是100呢

2. job1对应的是

Dataset<Row> userProfileSource = sparkSession.read().parquet(filePath);

和job0是一样的，但是是对parquet文件的初步的读
点击job可以看到详情

1. job详情

2. stag详情

3. job2对应的是

MyEsSparkSQL.saveToEs(searchUserProfile, esIndex);

这个job对应的是写入es当中，耗时比较长

1. 对应的stag

task在executor层面的数据运行数据统计

task 任务的详情，总共125,太多了，这里只使用少部分

可以看到每个task的输入差不多是125M左右，具体是怎么划分partition的，后面需要再探讨一下。125125=15625M ， parquet是150100=15000M,理论上这两者之间应该是对应的关系。

这里的Locality Levels分为很多种
代表 task 的计算节点和 task 的输入数据的节点位置关系

1. PROCESS_LOCAL: 数据在同一个 JVM 中，即同一个 executor 上。这是最佳数据 locality。
2. NODE_LOCAL: 数据在同一个节点上。比如数据在同一个节点的另一个 executor上；或在 HDFS 上，恰好有 block 在同一个节点上。速度比 PROCESS_LOCAL 稍慢，因为数据需要在不同进程之间传递或从文件中读取
3. NO_PREF: 数据从哪里访问都一样快，不需要位置优先
4. RACK_LOCAL: 数据在同一机架的不同节点上。需要通过网络传输数据及文件 IO，比 NODE_LOCAL 慢
5. ANY: 数据在非同一机架的网络上，速度最慢

4. job3对应的是

这个job的count对应的是往redis当中写入数据

searchUserProfile.mapPartitions(new MapPartitionsFunction<UserReadRecord, UserReadRecord>() {

            @Override
            public Iterator<UserReadRecord> call(Iterator<UserReadRecord> input) throws Exception {
                Map<String, Map<String, String>> redisMap = new HashMap<>();
                while (input.hasNext()) {
                    UserReadRecord aRecord = input.next();
                    Map<String, String> mapBean = ObjectUtil.obj2StringMap(aRecord);
                    String profileKey = RedisConfig.getUserProfileKey(aRecord.getUid());
                    redisMap.put(profileKey, mapBean);

                    if (redisMap.size() > 500) {
                        trySaveRedis(redisMap);
                        redisMap.clear();
                        Thread.currentThread().sleep(50);
                    }
                }
                if (redisMap.size() > 0) {
                    trySaveRedis(redisMap);
                    redisMap.clear();
                    Thread.currentThread().sleep(50);
                }
                return new ArrayList().iterator();
            }
        }, Encoders.bean(UserReadRecord.class)).count();

相关详情图



可以看到的是这job对应了两个stage(stage3,stage4),猜测是因为第一个stag是在每个partition上进行统计，然后经历一次shuffle进行统计
点击上面的stage的链接可以看到stage的详情
DAG显示了任务有哪些操作

1. stage3的相关信息

这里可以看出来这个任务是并行的，多个executors的耗时分布也有

然后在executor层面做了汇总

stage又会分为多个task , task的数量太多这里只截取一部分


这里的Locality Levels分为很多种
代表 task 的计算节点和 task 的输入数据的节点位置关系

1. PROCESS_LOCAL: 数据在同一个 JVM 中，即同一个 executor 上。这是最佳数据 locality。
2. NODE_LOCAL: 数据在同一个节点上。比如数据在同一个节点的另一个 executor上；或在 HDFS 上，恰好有 block 在同一个节点上。速度比 PROCESS_LOCAL 稍慢，因为数据需要在不同进程之间传递或从文件中读取
3. NO_PREF: 数据从哪里访问都一样快，不需要位置优先
4. RACK_LOCAL: 数据在同一机架的不同节点上。需要通过网络传输数据及文件 IO，比 NODE_LOCAL 慢
5. ANY: 数据在非同一机架的网络上，速度最慢

2. stage4的相关信息

相对来说stage4的任务则简单的多，应该是对前面的多个task进行汇总处理

5. job4对应的是

Long total = searchUserProfile.count();

可以看到这个就是一个简单的count操作

1. job详情

2. stage5详情

3. stage6详情

这里可以看到shuffle的size都是125，就是前面的125个task运算的结果。

4. environment

当前spark进程主要运行环境信息，可以从这里看到很多你的想要的信息，能够完成任务的排查了解

7. executors

当前spark任务使用了哪些executor

8. SQL

spark任务有哪些sql操作