作者回复: 完美,满分💯!置顶🔝 老弟功底十分扎实~👍👍👍
作者回复: 好问题~ 第一个问题实际上,就是数据倾斜,data skew,倾斜会导致你说的,闲的闲死、忙的忙死,忙的那个拖累作业整体性能。两种思路,一个是用spark3.0的AQE,join自动倾斜处理。另一个是手工加盐。这两种方法,其实在《性能篇》都有详细的介绍。稍后我把那边比较核心的讲解,给你贴过来。这会在地铁上,不好操作。 第二个,其实是两个层面的事情。一个是调度系统,说的是代码调度,调度到数据所在的地方。而shuffle呢,数据移动是刚需,是计算逻辑需要。换句话说,这个时候,代码动不动,数据都要动。这个其实已经超出调度系统范畴,纯粹是计算逻辑需要。两个层面的问题哈~
作者回复: 好问题~ 是的, 就像你分析的那样,如果map task计算阶段,发现没有某些reduce task的数据,那么index文件中的索引,就会一直顺延~ 思考的很深入,赞👍~
作者回复: 好问题~ 先说第一个,这个就是index文件的作用,它记录的就是隶属于不同Reduce task的数据索引,Reduce task基于这些索引来判断,哪些数据属于他。举例来说,Reduce task 3,那么data文件中,index从3到4之间的数据,就是属于这个Reduce task 3的。 第二个,好问题。这个其实是“静态思维”惹的祸。要知道,不管是Map task,还是Reduce task,消耗的计算资源,都是同一个集群、同样节点上同样的一批Executors。 Reduce tasks对于Map tasks是有依赖的,同一批Executors,执行完Map tasks之后,数据落盘到了spark.local.dir配置的目录。接下来,还是这同一批Executors,启动Reduce tasks,跨网络去不同节点上拉取属于自己的数据。 因此,Executors一直没闲着,不存在资源浪费的问题。要动态地看待Map & Reduce过程,他们在时间线上,是有前后关系的。而所有任务,消耗的都是同一批硬件资源~
作者回复: shuffle与executors数量无关哈,即便是一个executors,像groupByKey、join、reduceByKey这些操作,照样会引入shuffle,只不过shuffle都在同一个executors发生,省去了网络I/O的开销,但是磁盘开销还是会有
作者回复: 一个个来看哈 1)Map task,其并行度由其Stage中的首个RDD决定,如果Map task是读取HDFS,那么并行度就是分布式文件block数量; 2)是的,中间文件的合并,可以理解为归并排序;另外,对于Join策略,Spark通常默认选取SMJ,因此Sort有利于后期做数据关联
作者回复: Quote “运行stage0的executor产生的数据称作建材,结束后driver继续提交stage1,运行stage1的executor全集群得去拉去各自所需的建材,可以这样理解嘛老师?” 是的,理解是对的~ 完全正确 对于每个map task来说,data、index都存储在本机磁盘,具体目录由spark.local.dir配置项来确定。哪些文件,存储在哪里,尺寸大小,这些meta data,都会由存储系统当中的BlockManager来记录,每个Executors都有自己的BlockManager。各个Executors的BlockManager会向Driver的BlockManagerMaster定期汇报这些meta data。reduce task在尝试拉取data、index文件时,需要通过Executors的BlockManager去拿到这些元信息,然后完成数据拉取。如果Executors的BlockManager没有这些元信息,BlockManager回去找Driver端的BlockManagerMaster,从而拿到全局元信息~
作者回复: 老弟说的是对的~ Reduce Task拉取数据的过程就是Shuffle Read。 这里的写法有问题,我回头让编辑帮忙改下,这里应该是最后的总结部分,改得比较仓促,出typo了,感谢老弟提醒~
作者回复: 之前有hash shuffle manager和Tungsten shuffle manager,不过现在都统一到sort shuffle manager里面了。hash很早就deprecate掉了,对于文件的消耗太大了;Tungsten shuffle manager,基本运行机制与sort shuffle manager一致,主要是在计算过程中,尽可能地利用了Tungsten的数据结构和内存寻址方式。在计算流程上,Tungsten based shuffle和sort based shuffle是一样的~
作者回复: Hash-based shuffle已经deprecate了哈,现在默认的都是Sort-based shuffle。Shuffle的目的不是排序,单纯的Shuffle,做不到全局有序。Sort-based只是shuffle的一种实现方式~ Sort-based实现方式至少有两个收益: 1)为后续可能的Sort Merge Join奠定基础 2)为后续可能的全局排序,奠定基础