spark任务运行过程repartition和coalesce

简介

这里主要想要探究一下spark的任务的partition的默认的机制,这里只是使用样例做了针对性的测试,并没有从源码角度来进行阐述

测试使用了以下的代码进行测试
分为了3个代码方式

  1. 不做任何干预
  2. 使用repartition的方式调整partition的数量
  3. 使用coalesce 的方式调整partition的数量

先贴一下代码,方便对比

1. 不做任何干预的代码

hdfs:///user/daily/20200828/ 下有100个大小为180M左右的parquet文件


public class UserProfileTest {

    static String filePath = "hdfs:///user/daily/20200828/*.parquet";
    public static void main(String[] args) {
        SparkConf sparkConf = new SparkConf()
                .setAppName("user_profile_test")
                .set(ConfigurationOptions.ES_NODES, "")
                .set(ConfigurationOptions.ES_PORT, "")
                .set(ConfigurationOptions.ES_MAPPING_ID, "uid");

        SparkSession sparkSession = SparkSession.builder().config(sparkConf).getOrCreate();
        Dataset<Row> userProfileSource = sparkSession.read().parquet(filePath);
        userProfileSource.count();
        userProfileSource.write().parquet("hdfs:///user/daily/result20200828/");
    }
}

2. 使用repartition的方式调整partition的数量


        userProfileSource.repartition(20).count();
        userProfileSource.repartition(10).write().parquet("hdfs:///user/daily/result2020090201/");

3. 使用coalesce 的方式调整partition的数量

        userProfileSource.coalesce(20).count();
        userProfileSource.coalesce(10).write().parquet("hdfs:///user/daily/result2020090202/");

2. 默认情况job图

在这里插入图片描述

1. job0 stage图

在这里插入图片描述

1. stage0详情

可以看出这个stage耗时比较短,大部分的时间还用在传输task代码本身了

在这里插入图片描述

2. job1 stage图

在这里插入图片描述

1. stage1详情

在这里插入图片描述

3. job2 stage图

在这里插入图片描述

1. stage2详情

在这里插入图片描述
在这里插入图片描述

2. stage3详情

在这里插入图片描述

4. job3 stage图

在这里插入图片描述

1. stage4详情

在这里插入图片描述
在这里插入图片描述

3. repartition job图

在这里插入图片描述

1. job0 stage图

2. job1 stage图

3. job2 stage图

可以看到这个时候job2有三个stage,比默认的情况多了一个stage,这个stage是shuffle的过程
在这里插入图片描述

1. stage2的详情

当前stage主要做的任务就是repartition 就是进行分区的重新分配,该阶段主要进行shuffle write ,为下一个stage的使用做准备
在这里插入图片描述
在这里插入图片描述

2. stage3的详情

当前stage主要是在每个partition上进行count计算,partition和task的数量是20
这个阶段既有shuffle read 读取上一个stage产生的数据,又有shuffle write 为下一个阶段的汇总做准备
在这里插入图片描述
在这里插入图片描述

3. stage4的详情

这个阶段主要是进行shuffle read 来获取上一个阶段的数据来进行汇总操作。
在这里插入图片描述

4. job3 stage图

可以看到job3对应了两个stage,相比默认的情况多出了一个repartition的stage

在这里插入图片描述

1. stage5详情

这里看到3个executor都跑了4个线程来运行任务
当前stage主要的作用是进行repartition, 所以是进行shuffle write来为下一个阶段做准备。
在这里插入图片描述
在这里插入图片描述

2. stage6详情

这个过程是真正的写新的parquet文件,因为这里只有10个partition,所以3个executor并没有跑满,只是第一个跑了4个线程,后面两个都是3个线程。同时这个stage主要是shuffle read, 读取前面一个stage产生的shuffle write内容。
在这里插入图片描述

4. coalesce job图

在这里插入图片描述

1. job0 stage图

2. job1 stage图

3. job2 stage图

可以看到job2只有两个stage相对repartition的过程减少了shuffle的过程
在这里插入图片描述

1. stage2的详情

可以看到总共有20个task,使用了两个两个executor,最开始开启了5个线程,后面executor3关闭了,只剩下executor1的4个线程。
同时可以看到task列表中都有shuffle write 就是为了下一阶段的最终的count做准备。
在这里插入图片描述
在这里插入图片描述

2. stage3的详情

可以看到stage3只有一个partition,对应的是shuffle read , 读取stage2产生的数据来进行汇总计算
在这里插入图片描述

4. job3 stage图

job3只有一个stage , 相对于repartition的方式减少了shuffle的过程

在这里插入图片描述

1. stage4的详情

在这里插入图片描述
在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值