Spark SQL 架構簡介
簡單看一下Spark SQL 的架構。下面這張圖描述了一條 SQL 提交之後需要經歷的幾個階段，結合這些階段就可以看到在哪些環節可以做優化。
很多時候，做數據倉庫建模的同學更傾向於直接寫 SQL 而非使用 Spark 的 DSL。一條 SQL 提交之後會被 Parser 解析並轉化爲 Unresolved Logical Plan。它的重點是 Logical Plan 也即邏輯計劃，它描述了希望做什麼樣的查詢。Unresolved 是指該查詢相關的一些信息未知，比如不知道查詢的目標表的 Schema 以及數據位置。
上述信息存於 Catalog 內。在生產環境中，一般由 Hive Metastore 提供 Catalog 服務。Analyzer 會結合 Catalog 將 Unresolved Logical Plan 轉換爲 Resolved Logical Plan。
到這裏還不夠。不同的人寫出來的SQL 不一樣，生成的 Resolved Logical Plan 也就不一樣，執行效率也不一樣。爲了保證無論用戶如何寫 SQL 都可以高效的執行，Spark SQL 需要對 Resolved Logical Plan 進行優化，這個優化由 Optimizer 完成。Optimizer 包含了一系列規則，對 Resolved Logical Plan 進行等價轉換，最終生成 Optimized Logical Plan。該 Optimized Logical Plan 不能保證是全局最優的，但至少是接近最優的。
上述過程只與 SQL 有關，與查詢有關，但是與 Spark 無關，因此無法直接提交給 Spark 執行。Query Planner 負責將 Optimized Logical Plan 轉換爲 Physical Plan，進而可以直接由 Spark 執行。
由於同一種邏輯算子可以有多種物理實現。如 Join 有多種實現，ShuffledHashJoin、BroadcastHashJoin、BroadcastNestedLoopJoin、SortMergeJoin 等。因此 Optimized Logical Plan 可被 Query Planner 轉換爲多個 Physical Plan。如何選擇最優的 Physical Plan 成爲一件非常影響最終執行性能的事情。一種比較好的方式是，構建一個 Cost Model，並對所有候選的 Physical Plan 應用該 Model 並挑選 Cost 最小的 Physical Plan 作爲最終的 Selected Physical Plan。
Physical Plan 可直接轉換成 RDD 由 Spark 執行。我們經常說“計劃趕不上變化”，在執行過程中，可能發現原計劃不是最優的，後續執行計劃如果能根據運行時的統計信息進行調整可能提升整體執行效率。這部分動態調整由 Adaptive Execution 完成。
後面介紹字節跳動在 Spark SQL 上做的一些優化，主要圍繞這一節介紹的邏輯計劃優化與物理計劃優化展開。