文章目录
- 1. 简述
- 2. spark程序和提交命令
- 1. spark任务源代码(主要部分)
- 2. 使用的提交命令
- 3. 如何在yarn上查看
- 1. 找到对应的任务
- 2. 任务的主监控页面
- 3. job页面
- 1. job0 对应的是
- 1. job详情
- 2. stag0的信息
- 2. job1对应的是
- 1. job详情
- 2. stag详情
- 3. job2对应的是
- 1. 对应的stag
- 4. job3对应的是
- 1. stage3的相关信息
- 2. stage4的相关信息
- 5. job4对应的是
- 1. job详情
- 2. stage5详情
- 3. stage6详情
- 4. environment
- 7. executors
- 8. SQL
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任务的监控页面
在这个页面的上面一行可以看到监控的主要维度有
- job: 当前spark进程有哪些job
- stage: 当前spark进程有哪些stage
- storage: 存储的使用情况
- environment: 当前spark进程主要运行环境信息
- executors: 当前spark任务使用了哪些executor
- 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 的输入数据的节点位置关系
- PROCESS_LOCAL: 数据在同一个 JVM 中,即同一个 executor 上。这是最佳数据 locality。
- NODE_LOCAL: 数据在同一个节点上。比如数据在同一个节点的另一个 executor上;或在 HDFS 上,恰好有 block 在同一个节点上。速度比 PROCESS_LOCAL 稍慢,因为数据需要在不同进程之间传递或从文件中读取
- NO_PREF: 数据从哪里访问都一样快,不需要位置优先
- RACK_LOCAL: 数据在同一机架的不同节点上。需要通过网络传输数据及文件 IO,比 NODE_LOCAL 慢
- 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 的输入数据的节点位置关系
- PROCESS_LOCAL: 数据在同一个 JVM 中,即同一个 executor 上。这是最佳数据 locality。
- NODE_LOCAL: 数据在同一个节点上。比如数据在同一个节点的另一个 executor上;或在 HDFS 上,恰好有 block 在同一个节点上。速度比 PROCESS_LOCAL 稍慢,因为数据需要在不同进程之间传递或从文件中读取
- NO_PREF: 数据从哪里访问都一样快,不需要位置优先
- RACK_LOCAL: 数据在同一机架的不同节点上。需要通过网络传输数据及文件 IO,比 NODE_LOCAL 慢
- 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操作