Spark SQL原始碼解析（三）Analysis階段分析
阿新 • • 發佈：2020-04-28
Spark SQL原理解析前言：
[Spark SQL原始碼剖析（一）SQL解析框架Catalyst流程概述](https://www.cnblogs.com/listenfwind/p/12724381.html)
[Spark SQL原始碼解析（二）Antlr4解析Sql並生成樹](https://www.cnblogs.com/listenfwind/p/12735833.html)
# Analysis階段概述
首先，這裡需要引入一個新概念，前面介紹SQL parse階段，會使用antlr4，將一條SQL語句解析成語法樹，然後使用antlr4的訪問者模式遍歷生成語法樹，也就是Logical Plan。但其實，SQL parse這一階段生成的Logical Plan是被稱為Unresolved Logical Plan。所謂unresolved，就是說SQL語句中的物件都是未解釋的。
比如說一條語句**SELECT col FROM sales**，當我們不知道col的具體型別（Int，String，還是其他），甚至是否在sales表中有col這一個列的時候，就稱之為是Unresolved的。
而在analysis階段，主要就是解決這個問題，也就是將Unresolved的變成Resolved的。Spark SQL通過使用Catalyst rule和Catalog來跟蹤資料來源的table資訊。並對Unresolved應用如下的rules（rule可以理解為一條一條的規則，當匹配到樹某些節點的時候就會被應用）。
- 從Catalog中，查詢Unresolved Logical Plan中對應的關係（relations）
- 根據輸入屬性名（比如上述的col列），對映到具體的屬性
- 確定哪些屬性引用相同的值並賦予它們唯一的ID（這個是論文中的內容，看不是很明白，不過主要是方便後面優化器實現的）
- Propagating and coercing types through expressions，這個看著也是有點迷，大概是對資料進行強制轉換，方便後續對1 + col 這樣的資料進行處理。
而處理過後，就會真正生成一棵Resolved Logical Plan，接下來就去看看原始碼裡面是怎麼實現的吧。
# Analysis階段詳細解析
通過跟蹤呼叫程式碼，在呼叫完SQL parse的內容後，就會跑去org.apache.spark.sql.execution.QueryExecution這個類中執行，後面包括Logical Optimization階段，Physical Planning階段，生成RDD任務階段都是在這個類中進行排程的。不過此次只介紹Analysis。
在QueryExecution中，會去呼叫org.apache.spark.sql.catalyst.Analyzer這個類，這個類是繼承自org.apache.spark.sql.catalyst.rules.RuleExecutor，記住這個，後面還有很多個階段都是通過繼承這個類實現的，實現原理也和Analysis階段相似。
繼承自RuleExecutor的類，包括這裡的Analyzer類，都是在自身實現大量的rule，然後註冊到batch變數中，這裡大概貼點程式碼瞅瞅。
```
class Analyzer(
catalog: SessionCatalog,
conf: SQLConf,
maxIterations: Int)
extends RuleExecutor[LogicalPlan] with CheckAnalysis {
......其他程式碼
lazy val batches: Seq[Batch] = Seq(
Batch("Hints", fixedPoint,
new ResolveHints.ResolveBroadcastHints(conf),
ResolveHints.ResolveCoalesceHints,
ResolveHints.RemoveAllHints),
Batch("Simple Sanity Check", Once,
LookupFunctions),
Batch("Substitution", fixedPoint,
CTESubstitution,
WindowsSubstitution,
EliminateUnions,
new SubstituteUnresolvedOrdinals(conf)),
......其他程式碼
```
先大概說下batches這個變數吧，batches是由Batch的列表構成。而Batch的具體簽名如下：
```
abstract class RuleExecutor[TreeType <: TreeNode[_]] extends Logging {
......其他程式碼
protected case class Batch(name: String, strategy: Strategy, rules: Rule[TreeType]*)
......其他程式碼
}
```
一個Batch由策略Strategy，和一組Rule構成，其中策略Strategy主要是區分迭代次數用的，按我的理解，某些rule可以迭代多次，越多次效果會越好，類似機器學習的學習過程。而策略Strategy會規定迭代一次還是固定次數。而rule就是具體的應用規則了，這個先略過。
在Analyzer這個類中，你會發現很大篇幅的程式碼都是各種各樣rule的實現。然後最終，Analyzer會去呼叫super.execute()方法，也就是呼叫父類（RuleExecutor）的方法執行具體邏輯。而父類又會去呼叫這個batches變數，迴圈來與Sql Parse階段生成的Unresolved Logical Plan做匹配，匹配到了就執行具體的驗證。還是貼下程式碼看看吧。
```
abstract class RuleExecutor[TreeType <: TreeNode[_]] extends Logging {
def execute(plan: TreeType): TreeType = {
var curPlan = plan
val queryExecutionMetrics = RuleExecutor.queryExecutionMeter
//遍歷Analyzer中定義的batchs變數
batches.foreach { batch =>
val batchStartPlan = curPlan
var iteration = 1
var lastPlan = curPlan
var continue = true
// Run until fix point (or the max number of iterations as specified in the strategy.
//這裡的continue決定是否再次迴圈，由batch的策略（固定次數或單次），以及該batch對plan的作用效果這兩者控制
while (continue) {
//呼叫foldLeft讓batch中每條rule應用於plan，然後就是執行對應rule規則邏輯了
curPlan = batch.rules.foldLeft(curPlan) {
case (plan, rule) =>