Spark SQL 原理和運行機制
Catalyst 是 Spark SQL 執行優化器的代號，所有 Spark SQL 語句最終都能通過它來解析、優化，最終生成可以執行的 Java 字節碼。
Catalyst 最主要的數據結構是樹，所有 SQL 語句都會用樹結構來存儲，樹中的每個節點有一個類（class），以及 0 或多個子節點。Scala 中定義的新的節點類型都是 TreeNode 這個類的子類。
Catalyst 另外一個重要的概念是規則。基本上，所有優化都是基于規則的。可以用規則對樹進行操作，樹中的節點是只讀的，所以樹也是只讀的。規則中定義的函數可能實現從一棵樹轉換成一顆新樹。
整個 Catalyst 的執行過程可以分為以下 4 個階段：
分析階段，分析邏輯樹，解決引用
邏輯優化階段
物理計劃階段，Catalyst 會生成多個計劃，并基于成本進行對比
代碼生成階段
?catalyst整體執行流程
說到spark sql不得不提的當然是Catalyst了。Catalyst是spark sql的核心，是一套針對spark sql 語句執行過程中的查詢優化框架。因此要理解spark sql的執行流程，理解Catalyst的工作流程是理解spark sql的關鍵。而說到Catalyst，就必須得上下面這張圖1了，這張圖描述了spark sql執行的全流程。其中，長方形框內為catalyst的工作流程。
圖1 spark sql 執行流程圖
SQL語句首先通過Parser模塊被解析為語法樹，此棵樹稱為Unresolved Logical Plan；Unresolved Logical Plan通過Analyzer模塊借助于Catalog中的表信息解析為Logical Plan；此時，Optimizer再通過各種基于規則的優化策略進行深入優化，得到Optimized Logical Plan；優化后的邏輯執行計劃依然是邏輯的，并不能被Spark系統理解，此時需要將此邏輯執行計劃轉換為Physical Plan。
Catalyst工作流程
任何一個優化器工作原理都大同小異：SQL語句首先通過Parser模塊被解析為語法樹，此棵樹稱為Unresolved Logical Plan；Unresolved Logical Plan通過Analyzer模塊借助于數據元數據解析為Logical Plan；此時再通過各種基于規則的優化策略進行深入優化，得到Optimized Logical Plan；優化后的邏輯執行計劃依然是邏輯的，并不能被Spark系統理解，此時需要將此邏輯執行計劃轉換為Physical Plan；為了更好的對整個過程進行理解，下文通過一個簡單示例進行解釋。
Parser
Parser簡單來說是將SQL字符串切分成一個一個Token，再根據一定語義規則解析為一棵語法樹。Parser模塊目前基本都使用第三方類庫ANTLR進行實現，比如Hive、 Presto、SparkSQL等。下圖是一個示例性的SQL語句（有兩張表，其中people表主要存儲用戶基本信息，score表存儲用戶的各種成績），通過Parser解析后的AST語法樹如右圖所示：
Analyzer
通過解析后的邏輯執行計劃基本有了骨架，但是系統并不知道score、sum這些都是些什么鬼，此時需要基本的元數據信息來表達這些詞素，最重要的元數據信息主要包括兩部分：表的Scheme和基本函數信息，表的scheme主要包括表的基本定義（列名、數據類型）、表的數據格式（Json、Text）、表的物理位置等，基本函數信息主要指類信息。
Analyzer會再次遍歷整個語法樹，對樹上的每個節點進行數據類型綁定以及函數綁定，比如people詞素會根據元數據表信息解析為包含age、id以及name三列的表，people.age會被解析為數據類型為int的變量，sum會被解析為特定的聚合函數，如下圖所示：
SparkSQL中Analyzer定義了各種解析規則，有興趣深入了解的童鞋可以查看Analyzer類，其中定義了基本的解析規則，如下：
Optimizer
優化器是整個Catalyst的核心，上文提到優化器分為基于規則優化和基于代價優化兩種，當前SparkSQL 2.1依然沒有很好的支持基于代價優化（下文細講），此處只介紹基于規則的優化策略，基于規則的優化策略實際上就是對語法樹進行一次遍歷，模式匹配能夠滿足特定規則的節點，再進行相應的等價轉換。因此，基于規則優化說到底就是一棵樹等價地轉換為另一棵樹。SQL中經典的優化規則有很多，下文結合示例介紹三種比較常見的規則：謂詞下推（Predicate Pushdown）、常量累加（Constant Folding）和列值裁剪（Column Pruning）。
上圖左邊是經過Analyzer解析后的語法樹，語法樹中兩個表先做join，之后再使用age>10對結果進行過濾。大家知道join算子通常是一個非常耗時的算子，耗時多少一般取決于參與join的兩個表的大小，如果能夠減少參與join兩表的大小，就可以大大降低join算子所需時間。謂詞下推就是這樣一種功能，它會將過濾操作下推到join之前進行，上圖中過濾條件age>0以及id!=null兩個條件就分別下推到了join之前。這樣，系統在掃描數據的時候就對數據進行了過濾，參與join的數據量將會得到顯著的減少，join耗時必然也會降低。
常量累加其實很簡單，就是上文中提到的規則 ?x+(1+2) ?-> x+3，雖然是一個很小的改動，但是意義巨大。示例如果沒有進行優化的話，每一條結果都需要執行一次100+80的操作，然后再與變量math_score以及english_score相加，而優化后就不需要再執行100+80操作。
列值裁剪是另一個經典的規則，示例中對于people表來說，并不需要掃描它的所有列值，而只需要列值id，所以在掃描people之后需要將其他列進行裁剪，只留下列id。這個優化一方面大幅度減少了網絡、內存數據量消耗，另一方面對于列存數據庫（Parquet）來說大大提高了掃描效率。
除此之外，Catalyst還定義了很多其他優化規則，有興趣深入了解的童鞋可以查看Optimizer類，下圖簡單的截取一部分規則：
至此，邏輯執行計劃已經得到了比較完善的優化，然而，邏輯執行計劃依然沒辦法真正執行，他們只是邏輯上可行，實際上Spark并不知道如何去執行這個東西。比如Join只是一個抽象概念，代表兩個表根據相同的id進行合并，然而具體怎么實現這個合并，邏輯執行計劃并沒有說明。
此時就需要將邏輯執行計劃轉換為物理執行計劃，將邏輯上可行的執行計劃變為Spark可以真正執行的計劃。比如Join算子，Spark根據不同場景為該算子制定了不同的算法策略，有BroadcastHashJoin、ShuffleHashJoin以及SortMergeJoin等（可以將Join理解為一個接口，BroadcastHashJoin是其中一個具體實現），物理執行計劃實際上就是在這些具體實現中挑選一個耗時最小的算法實現，這個過程涉及到基于代價優化策略，后續文章細講。
