黄色的是数据结构，蓝色的spark的模块，绿色的是hive matestore 。
SQL和DataFrame 进来会先解析成逻辑执行计划，从hive metasotre里面拿一些表、字段的元数据信息，生成一个解析过的执行计划。经过spark的优化器，改变逻辑执行计划的逻辑结构，通过planner生成物理的执行计划。
将sql转换成抽象语法书（逻辑执行计划）
右边的含义：relation就是一个表的意思，UNresolveRelation是指还没有解析过，现在还没有从元数据那获取信息，不知道表里具体的情况；再往上是有一个left join，join的key值是id；经过join之后是Filter，是where里面的条件；然后是Project，叫做投影，是select里面选的字段。
Analyze是查询hive metastore，绑定元数据，拿一些table的信息、列的信息等，如果这个是一个view（视图），就会展开视图的逻辑，做进一步的解析。红色部分为发生的变化。
经过绑定元数据之后，UNresolveRelation变成了CatalogRelation，CatalogRelation代表的是hive表的意思，会绑定字段的类型，如果查一个不存在的字段或者表，就会在这一步报错
spark里面最重要的优化。基于规则的优化：谓词下推，过滤条件推测等几十个启发式规则。
比如上面的SQL，本来是left join之后来过滤时间的，优化器发现是在左表的条件和字段，直接推到了join之前了，在数据读上来的时候就直接过滤了，会提升速度。还会推测一些条件，比如dt是一个明确的值，右表的id也不能是空的。
最后一步生产实际的物理执行的节点和算子。
把CatalogRelation生成HiveTableScan，就是生成实际读hive表，从hdfs里面取读数据就是在hivetablescan中实现的。
选择join的类型，会发现dim表是很小的表，在生产物理执行计划的时候会生产广播的join也就是mapjoin，如果两个表都比较大，就会生产带shuffle的sortmergejoin。