SPARK SQL AQE理解

Spark AQE SkewedJoin 在字节跳动的实践和优化 - 文章 - 开发者社区 - 火山引擎

1，优化join：利用执行结束的上游 stage 的统计信息（主要是数据量和记录数），可以预估两表的数据量，根据数据量确定使用何种JOIN方式

2，优化shuffle ：根据map端信息可以推断出每个partition的数据量，可以推断出关联的两个partition的每个数据量，决定左表进行切分，右表广播

3，reducer优化：MapStage 执行结束之后，每一个 MapTask 会生成统计结果 MapStatus，并将其发送给 Driver。MapStatus维护了一个 Array[Long]，记录了该 MapTask 中属于下游每一个 ReduceTask 的数据大小。当 Driver 收集到了所有的 MapTask 的MapStatu之后，就能够计算得到每一个 ReduceTask 的输入数据量，以及分属于每一个上游 MapTask 的数据大小。根据每一个 ReduceTask 的数据大小，Spark AQE 能够判断出数据倾斜，并根据上游 MapTask 的统计信息，合理切分 Reducetask，尽可能保证切分的均匀性。

4，上述自优化阶段出现的问题：

• 不准确的统计数据可能导致 Spark 无法识别数据倾斜。

• 切分不均匀导致优化处理效果不理想。

• 不支持复杂场景例如同一个字段发生连续 join。  

5，AQE无法处理的情形：

AQE SkewedJoin 功能并不能处理所有发生数据倾斜的 Join，这是由它的实现逻辑所决定的。

第一，如果倾斜的分区的大部分数据来自于上游的同一个 Mapper，AQE SkewedJoin 无法处理，原因是 Spark 不支持 Reduce Task 只读取上游 Mapper 的一个 block 的部分数据。

第二，如果 Join 的发生倾斜的一侧存在 Agg 或者 Window 这类有指定 requiredChildDistribution 的算子，那么 SkewedJoin 优化无法处理，因为将分区切分会破坏 RDD 的 outputPartitioning，导致不再满足 requiredChildDistribution。

第三，对于 Outer/Semi Join，AQE SkewedJoin 是无法处理非 Outer/Semi 侧的数据倾斜。比如，对于 LeftOuter Join，SkewedJoin 无法处理右侧的数据倾斜。

第四，AQE 无法处理倾斜的 BroadcastHashJoin。

6，AQE效果不明显时，可以使用以下进行调节：

• 提高 spark.shuffle.minNumPartitionsToHighlyCompress，保证值大于等于 shuffle 并发（当开启 AQE 时，即为spark.sql.adaptive.coalescePartitions.initialPartitionNum）。

• 调小 spark.shuffle.accurateBlockThreshold，比如 4M。但是需要注意的是，这会增加 Driver 的内存消耗，需要同步增加 Driver 的 cpu 和内存。

• 降低 spark.sql.adaptive.skewJoin.skewedPartitionFactor，降低定义发生倾斜的阈值。

7，目前在做SQL优化时，明显感觉到部分统计信息时静态的，比如只能得到整表信息，无法得到筛选后的表信息，往往数据量会相差许多倍。根据整表信息最终可能采用SMJ，而筛选后时BHJ，系统给的join方法反而拖慢了效率。而AQE是动态估算的，能部分解决这些问题。

• 动态合并shuffle分区（Dynamically coalescing shuffle partitions）
• 动态调整Join策略（Dynamically switching join strategies）
• 动态优化数据倾斜Join（Dynamically optimizing skew joins）

8，概念辨析- BLOCK MANAGER

Spark:BlockManager原理剖析与源码分析_blockmanagermaster-优快云博客

Spark MapOutputTracker 原理 | 学习笔记