Spark 3.0 关键新特性回顾

Spark 3.0 关键新特性回顾

从Spark 3.0官方的Release Notes可以看到，这次大版本的升级主要是集中在性能优化和文档丰富上(如下图)，其中46%的优化都集中在Spark SQL上。

今天Spark SQL的优化不仅仅服务于SQL语言，还服务于机器学习、流计算和DataFrame等计算任务， 因此社区对于Spark SQL的投入非常大。对外公布的TPC-DS性能测试结果相较于Spark 2.4会有2倍的提升。SQL优化里最引人注意的非Adaptive Query Execution莫属了， 还有一些其他的优化比如Dynamic Pruning Partition，通过Aggregator注册UDAF(User Defined Aggregator Function)等等都极大的提升了SQL引擎的性能。
本文会着重回顾AQE新特性及相关关注的特性和文档监控方面的变化。其他更多的信息比如复用子查询优化，SQL Hints，ANSI SQL兼容，SparkR向量化读写，加速器感知GPU调度等等，感兴趣的同学可以参考官网notes。

Adaptive Query Execution (AQE)

AQE对于整体的Spark SQL的执行过程做了相应的调整和优化(如下图)，它最大的亮点是可以根据已经完成的计划结点真实且精确的执行统计结果来不停的反馈并重新优化剩下的执行计划。

• 当用户提交了Spark SQL/Dataset/DataFrame时，在逻辑执行计划阶段，Spark SQL的Parser会用ANLTER将其转化为对应的语法树（Unresolved Logic Plan)，接着Analyzer会利用catalog里的信息找到表和数据类型及对应的列将其转化为解析后有schema的Logical Plan，然后Optimizer会通过一系列的优化rule进行算子下推（比如filter， 列剪裁)，提前计算常量（比如当前时间），replace一些操作符等等来去优化Logical Plan。
• 而在物理计划阶段，Spark Planner会将各种物理计划策略作用于对应的Logical Plan节点上，生成多个物理计划，然后通过CBO选择一个最佳的作为最终的物理算子树(比如选择用Broadcast的算子，而不是SortMerge的Join算子)， 最终将算子树的节点转化为Spark底层的RDD，Transformation和Action等，以支持其提交执行。
  在Spark 3.0之前， Spark的Catalyst的优化主要是通过基于逻辑计划的rule和物理计划里的CBO，这些优化要么基于数据库里的静态信息，要么通过预先得到统计信息， 比如数值分布的直方图等来预估并判断应该使用哪种优化策略。这样的优化存在很多问题，比如数据的meta信息不准确或者不全，或者复杂的