目前的测试效果性能较2.4.6 提高有20%
spark 3.0 性能改进项--简化内容可以参考 ：
spark3.0 的 发布时间 --2020年6月
大版本的更新注定有许多性能优化方面的新特性，其中整个版本升级改进中spark sql占 46% ，spark core占 16%
spark作为当前批量数据分析引擎，在SQL方面的优化主要四个方向7个方面：
1.开发交互方向：
新的explain格式，更加简洁方便查看，去掉了很多非必须的信息
所有的join 都支持hint 格式
2.动态优化
自适应查询执行(Adaptive Query Execution)
动态分区裁剪(Dynamic Partition Pruning)
3.Catalyst提升
增强嵌套列的裁剪和下推
增强聚合的代码生成
4.基础设施更新
支持Hadoop 3/JDK 11/Scala 2.1版本
对于技术人员对性能优化方面主要体现在对第二点动态优化关注
自适应查询执行通过使用<运行时的统计信息>进行三个方面的优化:
1)动态合并 shuffle partitions，根据统计信息设置reducer的数量来避免内存和I/O资源的浪费
Spark2.4的版本中，Reducer的个数是通过配置文件中的shuffle.partition来设置的，该参数需要根据每个任务的数据量进行评估，经过多次调整才能得出较为合理的值。而且业务数据量会随趋势膨胀。
设置过大，需要集群处理大量小的task，也就是造成每个task处理的数据量过小，增加task的调度开销和资源调度开销，如果是最终结果，该stage 要输出到文件，会有很多小的IO，
同时hdfs 会存储大量的小文件。
设置过小，正好相反，导致每个task 处理大量的数据，处理效率低下，无法有效利用集群资源的并行处理能力，甚至可能导致oom error。
Spark3.0中，则采用实时数据重新划分分区，将小数据的reduce合并到一个reduce中处理，重新平衡数据量加速数据处理效率
2)动态调整 join 策略，选择更优的join策略来提高连接查询性能
在大数据中，join策略可以大致分为三种，分别是HashJoin，BroadCastJon和MergeJoin。Spark会根据表数据的大小选择合适的Join策略，但是当前的选择都是基于静态统计信息的。
例如在Spark2.4中，如上两种表的大小分别为100GB（t1)和80GB(t2)，通过静态信息统计，Spark在最后选择了SortMergeJoin的策略。
但是这个方案是基于两个join表的大小为100和80GB大小的前提下的，并没有参考table2经过条件过滤之后的大小。
在Spark3.0中，加入了动态信息统计，引擎不仅会掌握table1和table2的静态统计信息，还会在执行过程中，适时收集两表的数据量的变化，及时调整策略。
如上例子，table2原本有80GB的数据参与join操作，但是经过过滤操作，有效的参与join的数据只有80MB，因此这样的数据量更适合Broadcast Join策略，所以在Spark3.0中会及时调整。
3)动态优化倾斜的 join（skew joins），优化join数据来避免不平衡查询造成的数据倾斜
Join的时间取决于最大的分区join时间，单个数据量过大的分区拖垮整个作业的运行时长，甚至内存溢出等。
spark2.0处理join 倾斜的主要方式有
1）增加shuffle partition 的数量，将大的partition进行再次拆分，数据进行分散处理。
2）加盐处理，也是将数据进行分散的方法
3）小表使用broadcast join
在Spark3.0中，通过对倾斜数据的自适应重分区,将大数据量的分区基于规则划分成多个小的分区，解决倾斜分区导致的整个任务的性能瓶颈，提高查询处理效率。
未来支付监管系统大数据部分如果有较严重的商户数据倾斜的话，该项可以较好的解决，数据因倾斜引起的运行时长问题
动态分区裁剪
基于运行时（run time）推断出来的信息来进一步进行分区裁剪
Dynamic partition pruning 本质是根据过滤条件能够进行更可能的数据过滤操作，减小数据处理的集合。
