上一篇文章在介绍Sql Parse阶段时,该阶段主要是使用Antlr4将一条SQL语句解析成语法树,然后使用Antlr4的访问者模式遍历生成语法树,也就是Logical Plan。但其实,Sql Parse这一阶段生成的Logical Plan是被称为Unresolved Logical Plan。所谓Unresolved,就是说SQL语句中的对象都是未解释的。

在论文中有介绍到Spark Sql以要计算的关系开头,从SQL解析器返回的抽象语法树(AST),或者使用API构造DataFrame对象。在这两种情况下,关系可能包含未解析的属性引用或关系:
例如,在SQL查询中 SELECT col FROM sales,而关于列col的类型是什么,甚至是否是有效的列名,要直到查询一下销售表slaes才知道。

因此如果我们不知道它的类型或没有将它与输入表匹配(或别名)。那么该属性称为未解析的属性即Unresolved。

而在Sql Analysis阶段,主要就是解决这个问题,也就是将Unresolved的变成Resolved的。Spark SQL通过使用Catalyst Rule和Catalog来跟踪所有数据源中的表以解析这些属性。它首先使用未绑定的属性和数据类型构建一个“未解析的逻辑计划”树,然后应用Rules执行以下操作(即对Unresolved应用如下的rules, rule可以理解为一条一条的规则,当匹配到树某些节点的时候就会被应用):

1) 从Catalog中按名称查询关系;
2) 根据输入属性名(比如上述的col列), 映射到具体的属性;
3) 确定哪些属性引用相同的值并赋予它们一个唯一的ID值(这稍后允许优化表达式,例如col=col);
4) 通过表达式传播和强制类型:例如,我们无法知道1+col的返回类型,直到我们解析col并可能将其子表达式强制转换为兼容类型;

当完成这些处理后,就会真正生成一棵Resolved Logical Plan,接下来具体看看 Analysis阶段的实现.....


Analysis阶段主要使用Analyzer绑定逻辑执行计划,即Analyzer使用Analysis Rules,结合SessionCatalog元数据,对未绑定的逻辑计划进行解析,生成了已绑定的逻辑计划。

在该处理过程中,先实例化一个Analyzer,在Analyzer中定义了FiexedPoint和Seq[Batch]两个变量,其中FixedPoint为迭代次数的上线,而Seq[Batch]为所定义需要执行批处理的序列,每个批处理由一系列Rule和策略所组成,策略一般分为Once和FixedPoint(可理解为迭代次数)。