獨家揭祕 | 阿里雲分析型數據庫AnalyticDB新一代CBO優化器技術

0一、概述

對於數據庫來講，其中倆個核心的模塊是：優化器和執行引擎。優化器負責給執行引擎提供輸入，它接收來自 SQL Parser 解析好的 AST 樹，而後須要從全部可能的計劃中選擇代價最優的計劃提供給執行引擎。基於代價的優化器本質上是一個複雜的搜索問題，想要解決好這個問題，須要從四個方向入手：

1）搜索框架：既然是搜索問題，那麼就須要一個搜索框架來承載這個問題。從數據庫的發展歷程來看，基於 Cascades 的搜索框架已經成爲了業界標準，包括商業數據庫 SQL Server 以及開源數據庫 GP/ORCA 都採用 Cascades 實現。AnalyticDB CBO 也是基於 Cascades 論文實現的。

2）分佈式並行計劃：相對於傳統的單機版數據庫，AnalyticDB 是一個分佈式 MPP 數據庫，優化器生成的計劃是一個分佈式並行計劃。所以須要把分佈式並行計劃的生成和搜索框架結合起來，基於代價選擇最佳的分佈式並行計劃。

3）代價估算：代價估算是優化器可否尋找到最優計劃的關鍵因素，代價估算作很差，優化器不可能作好。代價估算涉及到統計信息的推導和代價模型。統計信息的推導依賴於：原始表的統計信息、中間算子的推導算法、對數據的各類假設（均勻性假設、獨立性假設、包括性假設、包含性假設）以及在一些極端狀況下的猜想。所以統計信息的推導存在大量的不肯定性，也正是由於這些不肯定性，極大的加重了優化器尋找最優解的難度。

4）統計信息收集：收集必要的統計信息是 CBO 工做的前提，CBO 和統計信息之間的關係猶如一把槍和彈藥之間的關係，槍再好若是沒有充足的彈藥的話，那麼無異於巧婦難爲無米之炊。統計信息須要作到：基本信息可以自動化收集，自動化更新，高級統計信息能夠手動收集，爲 CBO 提供可靠的、多維度的統計信息。

0二、架構

搜索框架

搜索框架在整個 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 動態採樣就能夠發揮它的價值，動態採樣會實時下發採樣，獲取必要的統計信息，提高優化器的決策質量。

其次，動態採樣也能夠做爲統計信息收集的一種兜底策略，當基礎統計信息因爲某些緣由致使未收集的狀況下，動態採樣的存在能夠避免優化器因爲缺失統計信息而產生災難性的計劃。可是動態採樣是在查詢優化階段同步阻塞執行的，所以它必然會增長查詢優化的總體耗時，同時也會增長整個數據庫系統的負載，所以咱們嚴格限制動態採樣的使用場景。

0三、設計與實現

接下來咱們會經過一個例子來展開搜索框架、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 節點，彙總到單節點。

0四、參考

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