01、概述
對於數據庫來說，其中倆個核心的模塊是：優化器和執行引擎。優化器負責給執行引擎提供輸入，它接收來自 SQL Parser 解析好的 AST 樹，然後需要從所有可能的計劃中選擇代價最優的計劃提供給執行引擎。基於代價的優化器本質上是一個複雜的搜索問題，想要解決好這個問題，需要從四個方向入手：
1）搜索框架：既然是搜索問題，那麼就需要一個搜索框架來承載這個問題。從數據庫的發展歷程來看，基於 Cascades 的搜索框架已經成爲了業界標準，包括商業數據庫 SQL Server 以及開源數據庫 GP/ORCA 都採用 Cascades 實現。AnalyticDB CBO 也是基於 Cascades 論文實現的。
2）分佈式並行計劃：相對於傳統的單機版數據庫，AnalyticDB 是一個分佈式 MPP 數據庫，優化器生成的計劃是一個分佈式並行計劃。因此需要把分佈式並行計劃的生成和搜索框架結合起來，基於代價選擇最佳的分佈式並行計劃。
3）代價估算：代價估算是優化器能否尋找到最優計劃的關鍵因素，代價估算做不好，優化器不可能做好。代價估算涉及到統計信息的推導和代價模型。統計信息的推導依賴於：原始表的統計信息、中間算子的推導算法、對數據的各種假設（均勻性假設、獨立性假設、包括性假設、包含性假設）以及在一些極端情況下的猜測。因此統計信息的推導存在大量的不確定性，也正是因爲這些不確定性，極大的加劇了優化器尋找最優解的難度。
4）統計信息收集：收集必要的統計信息是 CBO 工作的前提，CBO 和統計信息之間的關係猶如一把槍和彈藥之間的關係，槍再好如果沒有充足的彈藥的話，那麼無異於巧婦難爲無米之炊。統計信息需要做到：基本信息能夠自動化收集，自動化更新，高級統計信息可以手動收集，爲 CBO 提供可靠的、多維度的統計信息。
02、架構
搜索框架
搜索框架在整個 CBO 中處於非常中心的一個位置，它會調用 Property Enforcement 框架，生成分佈式執行計劃，然後調用代價估算模塊，給每一種候選分佈式執行計劃評估代價，最終基於代價選擇最優的分佈式執行計劃。搜索框架包括以下幾個部分：
Memo 表示搜索空間：對於一個查詢計劃來說，首先需要把它初始化，形成初始化的搜索空間。隨着搜索的進行，搜索空間會不斷擴充。由於搜索空間會非常龐大，因此 Memo 需要做到高效存儲。
Search 表示搜索算法：搜索算法由三部分組成，第一部分用於遞歸遍歷搜索空間，第二部分用於調用展開規則產生新的等價候選計劃，擴充搜索空間，第三分部用於用於推導分佈式計劃的屬性要求並計算代價值，進而尋求最優的分佈式執行計劃。
Scheduler 表示調度搜索算法的調度器：在當前的 AnalyticDB CBO 版本中，基於單線程和棧實現：把搜索任務壓入到一個棧中，然後循環取棧中的任務去執行，直到任務結束。
考慮到其他開源優化器產品，例如 ORCA 提到了多線程並行搜索的理念，我們預留了多線程調度器的接口，相對於優化器衆多棘手的問題來說，它的優先級並不是那麼高，實現並行搜索的好處是非常明顯的，它可以顯著降低任務調度的執行時間，充分發揮多核並行的能力，從整個查詢的角度來看，可以縮短查詢優化的耗時，從而降低整體查詢的耗時。但是並行搜索帶來的線程同步問題，以及線程間依賴處理問題，挑戰還是很大的。
Rule 表示展開規則：展開規則用於生成等價候選計劃，等價候選計劃會被放入到 Memo 中，形成完整的搜索空間。展開規則決定了優化器可以展開多少種候選計劃，因此展開規則的種類，以及每種展開規則的算法效率對 CBO 來說也是至關重要的。展開規則種類越多，搜索空間就越完善，也就更有可能尋求到最優解，同時每種展開規則的算法越高效，生成完整的搜索空間就越高效，查詢優化就越快。
分佈式並行計劃
相對於傳統的單機版數據庫來說，分佈式 MPP 數據庫給優化器帶來了新的挑戰。在分佈式 MPP 數據庫中，數據的分佈屬性變得十分的重要，它會直接影響到數據的正確性。爲了滿足不同算子對數據分佈的要求，我們往往需要做數據重分佈。
然而數據的重分佈，也就是數據 shuffle 的代價非常昂貴，因此，在保證數據正確性的前提下，儘可能的減少數據 shuffle，可以大幅度提升分佈式計劃的執行性能。作爲分佈式 MPP 數據庫優化器來說，需要把數據的 Partitioning 屬性，以及 Sorting、Grouping 屬性，也納入到搜索空間來綜合考慮，基於代價選擇最優的分佈式並行執行計劃。
因此我們設計實現了一套完整的 Property Enforcement 框架，用於描述在分佈式場景下，分佈式計劃對數據分佈的要求。同時我們把 Property Enforcement 的過程和搜索框架無縫的結合在一起，實現了面向分佈式 MPP 數據庫的 CBO。
代價估算
代價估算是整個 CBO 質量好壞的關鍵因素，代價估算做的好，CBO 纔有可能選擇出最優的計劃，它包括三個部分。
Statistics 用於描述原始表的統計信息。包括表級別的統計信息 Row Count，單個字段的統計信息：每個字段的 NDV 值（distinct 值），Max 值，Min 值，NULL 值，Histogram 值（分佈信息，用於區間查詢）, Count-Min Sketch 值(用於等值查詢)，DataSize 值。這些統計信息我們把它歸納爲基礎統計信息，需要做到自動收集，自動更新。
同時考慮到多個字段之間的關聯度、Functional deplendency、數據的傾斜等這些因素對統計信息估算的影響，還會提供命令行工具，手動收集這些信息，對於這些需要手動收集的信息，我們把它歸納爲高級統計信息，只有在必要的時候，才需要顯示的手動收集。另外，對於一些複雜的 predicate，例如 like，那麼即使收集了 Histogram 也無法支持這種場景，因此我們也會在運行時基於動態採樣來獲取對應的統計信息。
Stats Derivation 用於推導經過各個算子之後的統計信息。統計信息的推導依賴於原始表的統計信息，數學公式，對數據屬性的假設（例如，數據的分佈是均勻的，多列之間的選擇率是沒有相關性的），以及極端情況下，啓發式的假設（例如對於一個用戶自定義的 UDF，它的選擇率只能給一個默認值）。
統計信息的推導的好壞對優化器來說至關重要，這也一直是學術界的研究熱點。本質上來說，只有打破對數據屬性的假設，纔有可能使得統計信息的估算做到知其然知其所以然，然而打破這些假設，依賴於對原始數據的分析，生成更多維度的統計信息，必然也要付出更多的代價。
Cost Model 表示代價模型。代價模型的工作必須要建立在合理的統計信息推導的基礎之上，否則它的意義不會很大。代價模型需要對實際的計算模型進行評估，把統計信息轉換爲可以量化的代價值，從而爲優化器提供決策依據。
統計信息收集
Analyze 用於收集統計信息。對於商業數據庫來說，爲了提升用戶體驗，做到開箱即用，都致力於 Auto analyze，即統計信息收集的自動化，以及自動更新。但是收集本身也是有代價的，因此我們把統計信息分爲倆類：基礎統計信息和高級統計信息。
基礎統計信息就是前面提到的：表級別的統計信息 row count，單個字段的統計信息：每個字段的 NDV 值（distinct 值），Max 值，Min 值，NULL 值，Histogram 值（分佈信息，用於區間查詢），Count-Min Sketch 值(用於等值查詢)，DataSize 值。基礎統計信息必須要做到自動化收集、自動化更新，否則很可能由於這些統計信息的缺失，導致優化器產生災難性的計劃。
同時爲了提升優化器在複雜情況下的決策質量，還提供了一些高級的命令用於收集更加複雜的統計信息，例如可以收集 column group 的統計信息，來獲取多個字段之間的關聯度信息。高級統計信息需要手工觸發收集，只有在必要的時候纔會收集。
基於 Analyze 命令收集統計信息，無論是自動化收集，還是手工收集，本質上來說所，它都是一個獨立的進程：Analyze 會調用 Data Profiling 任務，對原始數據進行分析，生成統計信息，並存儲在 Metadata 庫中。
考慮到實際情況下，可能存在一些非常複雜的查詢條件，不管是基礎的統計信息還是高級統計信息，都無法很好的對它做合理的估算，這個時候，dynamic sampling 動態採樣就可以發揮它的價值，動態採樣會實時下發採樣，獲取必要的統計信息，提升優化器的決策質量。
其次，動態採樣也可以作爲統計信息收集的一種兜底策略，當基礎統計信息由於某些原因導致未收集的情況下，動態採樣的存在可以避免優化器由於缺失統計信息而產生災難性的計劃。但是動態採樣是在查詢優化階段同步阻塞執行的，因此它必然會增加查詢優化的整體耗時，同時也會增加整個數據庫系統的負載，因此我們嚴格限制動態採樣的使用場景。
03、設計與實現
接下來我們會通過一個例子來展開搜索框架、Property Enforcement 框架、以及代價估算的設計與實現。
查詢語句
這一個簡化版的 TPCH q3，非常典型的三表 Join。其中 customer 表按照 c_custkey 進行分區，orders 表按照o_orderkey 進行分區，lineitem 表按照 l_orderkey 進行分區。
SELECT l_orderkey, o_orderdate, o_shippriority FROM customer, orders, lineitem WHERE c_custkey = o_custkey AND l_orderkey = o_orderkey
查詢優化
在進入到 CBO 之前，原始的執行計劃如下圖所示，customer 表和 orders 表先 Join，Join 的結果再和 lineitem 表 Join，然後輸出結果。
進入到 CBO 後，首先需要把查詢計劃轉換爲 Group 和 GroupExpression，並初始化 Memo 搜索空間。可以看到共有 6 個 Group，每個 Group 都有一個 GroupExpression。Group 和 GroupExpression 都是搜索空間裏面的重要概念，關於它的詳細介紹可以參考：AnalyticDB Cost based Optimizer 搜索框架，這裏不展開。
簡單來說：對於邏輯等價的，可以產生相同結果的 Logical Expression 和 Physical Expression 的集合稱爲 Group，GroupExpression 則包括 Logical GroupExpression 和 Physical GroupExpression，每一種 GroupExpression 表示一種等價候選計劃。
在這裏，我們爲了簡化描述，只考慮 Join 的 Order，以及分佈式 Join 情況下，Repartition Join 和 Replicate Join 這兩種屬性要求，對於 Join 的算法默認只考慮 Hash-join 物理實現。
其他算子：TableScan 和 Output 也默認只有一種物理實現。調度器調度搜索任務，執行搜索流程，擴展搜索空間。可以看到隨着搜索算法的不斷迭代，Memo 裏面的 Group 和 GroupExpression 會新增：白色表示 Logical GroupExpression，灰色表示 Physical GroupExpression。
可以看到，在應用了 Join 的結合律之後，新產生了 Group7 和 Group8 這倆個 Group；同時應用了 Join 的交換律之後，Group5 和 Group3 裏面新增了很多等價的 Logical GroupExpression；同樣 Group7 和 Group8 裏面也有等價的 Logical GroupExpression。
最終考慮倆種分佈式 Join 實現：Repartition Join 和 Replicate Join，這樣就生成了完整的搜索空間。
當整個搜索空間被完整的擴充出來之後，接下來需要調用 Property Enforcement 框架，對每一種物理執行計劃，去 Enforce 必要的屬性，從而滿足分佈式執行計劃的要求，然後再調用代價估算模塊，去計算每一種分佈式計劃的代價，並把代價最小的計劃標記爲最優解，也就是 Winner。當每一個 Group 的 Winner 都被計算出來之後，將每個 Winner 串接起來，就是最優的分佈式執行計劃。
關於 Property Enforcement 和代價估算的詳情，可以參考下面這三篇文章，這裏不展開。
AnalyticDB Cost based Optimizer 分佈式並行計劃 AnalyticDB Cost based Optimizer 代價估算 AnalyticDB Cost based Optimizer 統計信息收集
下圖中黑色意味着 Winner，表示的是在滿足某種屬性要求的情況下，代價最低最低的物理執行計劃。
我們遍歷每個 Group 的 Winner，將 Winner 串接起來，就形成了最優的分佈式執行計劃。
每一個 Winner 經過 Property Enforcement 之後，都會在必要的時候插入必要的 Exchange 節點，來滿足分佈式計劃的屬性要求，所以生成的分佈式執行計劃如下圖所示。可以看到：首先 customer 表做了一個全表廣播到所有節點，進而滿足和 orders 表 Join 的要求，Join 之後的結果按照 order 表分佈，orders 表和 lineitem 表數據分佈本身就滿足 Join 的要求，因此不需要插入 Exchange 節點，最終 Join 的結果要輸出到 Output 節點，因此插入 Gather 節點，彙總到單節點。
04、參考
An Overview of Query Optimization in Relational Systems
The Cascades Framework for Query Optimization Efficiency in the columbia database query optimizer
Orca: A Modular Query Optimizer Architecture for Big Data
Incorporating Partitioning and Parallel Plans into the SCOPE Optimizer
Profiling Relational Data – A Survey
上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/
本文爲阿里雲原創內容，未經允許不得轉載。