Spark Sql

本文主要介紹SparkSQL的優化器系統Catalyst，其設計思路基本都來自於傳統型數據庫，並且和大多數當前的大數據SQL處理引擎設計基本相同（Impala、Presto、Hive（Calcite）等），所以經過本文的學習也能夠基本瞭解全部其餘SQL處理引擎的工做原理。

SQL優化器核心執行策略主要分爲兩個大的方向：基於規則優化（RBO）以及基於代價優化(CBO)，基於規則優化是一種經驗式、啓發式地優化思路，更多地依靠前輩總結出來的優化規則，簡單易行且可以覆蓋到大部分優化邏輯，可是對於核心優化算子Join卻顯得有點力不從心。舉個簡單的例子，兩個表執行Join到底應該使用BroadcastHashJoin仍是SortMergeJoin？當前SparkSQL的方式是經過手工設定參數來肯定，若是一個表的數據量小於這個值就使用BroadcastHashJoin，可是這種方案顯得很不優雅，很不靈活。基於代價優化就是爲了解決這類問題，它會針對每一個Join評估當前兩張表使用每種Join策略的代價，根據代價估算肯定一種代價最小的方案。

在介紹SQL優化器工做原理以前，有必要首先介紹兩個重要的數據結構：Tree和Rule。相信不管對SQL優化器有無瞭解，都確定知道SQL語法樹這個概念，不錯，SQL語法樹就是SQL語句經過編譯器以後會被解析成一棵樹狀結構。這棵樹會包含不少節點對象，每一個節點都擁有特定的數據類型，同時會有0個或多個孩子節點（節點對象在代碼中定義爲TreeNode對象）。在任何一個SQL優化器中，一般會定義大量的Rule（後面會講到），SQL優化器會遍歷語法樹中每一個節點，針對遍歷到的節點模式匹配全部給定規則（Rule），若是有匹配成功的，就進行相應轉換，若是全部規則都匹配失敗，就繼續遍歷下一個節點。

Catalyst工做流程

任何一個優化器工做原理都大同小異：SQL語句首先經過Parser模塊被解析爲語法樹，此棵樹稱爲Unresolved Logical Plan；Unresolved Logical Plan經過Analyzer模塊藉助於數據元數據解析爲Logical Plan；此時再經過各類基於規則的優化策略進行深刻優化，獲得Optimized Logical Plan；優化後的邏輯執行計劃依然是邏輯的，並不能被Spark系統理解，此時須要將此邏輯執行計劃轉換爲Physical Plan；爲了更好的對整個過程進行理解，下文經過一個簡單示例進行解釋。