无论是SQL AST，DataFrame还会Dataset都是按照这个流程来执行的

Unresolved Logical Plan 先生成一个纯粹的逻辑计划，这个时候还没和实际上的数据有任何的交互
Logical Plan 这个时候和数据交互后得到一个实际的逻辑执行计划
Optimized Plan 因为上一步已经和数据进行一定的交互，引擎可以在这个基础上进行一定的优化
Physical Plans 在逻辑执行生成的结果上引擎将这个计划落实到多个物理执行计划了
Costed Model 通过Catalyst优化器惊醒评估，在一堆的物理执行计划当中挑选一个对机器成本最低的一个
RDD 生成代码并最终执行
Catalyst工作原理
在SparkSQL中，catalyst的执行过程就是有逻辑执行计划到最终RDD生成的这一部分。我们以一段最简单的SQL语句来看看过程是怎样的

select sum(v)
from (
  select
  t1.id,
  1 + 2 + t1.value as v
  from t1 join t2
  where
     t1.id = t2.id and
     t2.id > 50 * 1000) tmp;

这是一段包括了连接，自查询和一定条件筛选的SQL语句，在这个过程当中我们看看catalyst是怎么工作的。

scan(t1) 和 scan(t2) 首先是执行扫描两个表
filter 定义过滤条件：t1.id = t2.id and t2.id > 50000
project 定义需要的字段：t1.id 1+2+t1.value as v
aggregate 聚合计算：sum(v)
如果执行这个过程引擎需要先将两个表的全量数据扫描出来，然后再将id相同的数据保留下来(这个过程设计到join，我们将在下面深入join的执行过程)，然后对得到的临时表的value字段进行+1+2的执行过程，最后在此基础上对v字段进行聚合计算。
而Catalyst优化器将会对这个逻辑执行计划进行优化，比如：谓词下压，常量值计算。
首先，将第2步的t2.id > 50000这个过程下压到scan(t2)这个过程，这样得到的两个表(t1和t2)的数据量将会减少，然后在执行join流程的过程时计算量也将大大减少。
接着，在得到一个临时字段的时候：1+2+t1.value as v的时候，这样的执行过程将会极大地增加cpu的计算量，我们都知道了其实就是3+t1.value了，但是引擎在执行的过程中还是会对每一条记录执行一次1+2=3的过程，所以可以直接将其优化成3+t1.value了。
另外，如果是两个大小表之间进行join的话，还可以从CommonJoin转化成MapJoin，就是使用broadcast计算将小表当成一个广播变量发送到各个executor上面去，将执行join。这样就可以避免了shuffle过程，也就是没有了reduce的部分了。

奈斯，感谢分享