上一篇文章在介绍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（可理解为迭代次数）。