Spark在SQL查询方面的性能优化主要分为四个方向七个方面
- 开发交互方向
新的Explain格式
所有join支持hints - 动态优化
自适应查询执行
动态分区裁剪 - Catalyst提升
增强嵌套列的裁剪和下推
增强聚合的代码生成 - 基础设施更新
支持新的Scala和Java版本
1.自适应查询执行：通过使用运行时的统计信息
1）根据统计信息设置reducer的数量来避免内存和I/O资源的浪费
对reducer的个数进行了优化：避免reduder 空转资源浪费情况
2）选择更优的join策略来提高连接查询性能
基于静态信息统计的基础上加入动态信息统计，在两表join执行时，适时收集两表数据量的变化，及时调整策略
join策略
Shuffle Hash Join:适应于要join的表数据量比较大
将大表按照join的key进行重分区
Broadcast Hash Join：map端join 当一张表数据较小时
broadcast 阶段:小表被缓存在executor中 ：
hash join 阶段 ：在每个executor中执行hash join
Sort Merge Join: Spark默认的 ，一般适用于两张大表进行join时
Cartesian Join：没有指定join key (ON条件)
Broadcast Nested Loop Join：当没有合适的join机制可供选择时
优先级：Broadcast Hash Join > Sort Merge Join > Shuffle Hash Join > cartesian Join > Broadcast Nested Loop Join.
3）优化join数据来避免不平衡查询造成的数据倾斜
join的时间取决于最大的分区join时间
表中的数据倾斜导致整个表连接任务的耗时操作
解决：通过对倾斜数据的自适应重分区
2.动态分区裁剪
是从下推演化而来，下推数据静态裁剪，通过将条件下推至数据源，从而减小了上层算子计算的数据量。动态裁剪是在静态裁剪的基础上，加入了运行时的数据裁剪。
补充
查询下推：
- 逻辑优化角度
从逻辑优化的角度来看，查询下推属于是将逻辑查询树中的一些节点下推到叶子结点或接近叶子结点，即更接近数据源的地方，从而使得上层节点的操作所涉及到的数据量大大减少，提高数据处理效率。
- 物理计划执行角度
从物理计划执行的角度来看，查询下推是将查询的条件下推到数据源，让数据源直接过滤掉与查询结果无关的数据，从而降低数据IO，提高数据的传输和处理效率。
参考https://zhuanlan.zhihu.com/p/192339214
https://www.cnblogs.com/jmx-bigdata/p/14021183.html
