本文分享自華爲雲社區《【GaussTech第2期】GaussDB SQL查詢語句執行過程解析》，作者： GaussDB 數據庫。
SQL於關係型數據庫而言，重要性不言而喻。就像一個樂團的指揮，指導着作品的正確演繹和節奏的和諧統一。華爲雲GaussDB作爲新一代關係型分佈式數據庫，具備卓越的技術性能和行業競爭力。很多人對GaussDB的關鍵技術很好奇，紛紛在論壇帖上留言：
今天我們就從GaussDB SQL引擎入手，瞭解一下GaussDB SQL查詢語句的執行過程，包括GaussDB SQL引擎原理和關鍵技術點。
如果您在瞭解的過程中有任何疑問或感興趣的關鍵技術點，可參與【雲咖問答】揭開GaussDB SQL引擎的神祕面紗，互動交流贏好禮活動，進行留言互動，專家會一對一進行答疑哦，更有機會獲得提問好禮激勵。
↓↓↓↓ 以下是正文
首先，簡單介紹一下GaussDB的系統結構，再解析GaussDB SQL查詢語句的執行過程。
GaussDB系統架構
圖(1) 集中式
圖(2) 分佈式
在GaussDB SQL語句執行過程中，會涉及以下幾個關鍵角色：
|
GTM |
全局事務管理器（Global Transaction Manager），負責生成和維護全局事務ID、事務快照、時間戳、sequence信息等全局唯一的信息。 |
|
CN |
協調節點（Coordinator Node）。負責接收來自應用的訪問請求，並向客戶端返回執行結果；負責分解任務，並調度任務分片在各DN上並行執行。每個CN與每個DN相連接，每個CN各持有一份元數據，元數據內容相同。 |
|
DN |
數據節點（Data Node）。負責存儲業務數據（支持行存、列存、混合存儲）、執行數據查詢任務以及向CN返回執行結果。 |
其中，DN主要承擔GaussDB SQL語句的執行，其邏輯架構如下圖所示：
圖(3) GaussDB邏輯架構
GaussDB包括兩個主要引擎：SQL引擎 (SQL Engine) 和存儲引擎 (Storage Engine) 。SQL引擎有時也被稱爲查詢處理器，它的主要功能是SQL 解析、查詢優化和查詢執行。SQL解析對輸入的 SQL 語句進行詞法解析、語法解析、語義解析，從而生成查詢樹。查詢樹經過規則優化（RBO）和代價優化（CBO）之後，產生執行計劃。執行器基於該執行計劃對相關數據進行提取、運算、更新、刪除等操作，以達到用戶查詢想要實現的結果。
存儲引擎負責管理所有數據的I/O，它包含數據讀寫處理（處理行、索引、頁、分配和行版本的I/O請求）、數據緩衝管理（Buffer Pool）和事務管理器。其中，事務管理又涉及到保持ACID屬性的鎖機制（Lock）和事務日誌管理（XLOG）。
在SQL引擎和存儲引擎之間是AM（Access Method) 層。AM對存儲層做了封裝，以支持多種存儲引擎（Astore，Ustore，etc.）。SQL層不直接調用存儲層，而是通過AM層，AM層會根據不同的存儲引擎調用不同的執行體。
從GaussDB邏輯架構圖中可以看出，GaussDB架構設計遵循現代軟件系統抽象化和分層解耦的設計原則，包括：統一事務機制、統一日誌系統、統一併發控制系統、統一元信息系統、統一緩存管理系統。因此，GaussDB技術架構具備以下主要特點：
-
支持SQL優化、執行、存儲分層解耦；
-
支持可插拔存儲引擎。
SQL查詢語句的執行過程
一條SQL查詢（SELECT）語句的執行過程，如下所示：
圖(4) 查詢語句的執行過程
從上圖可以看出，一條SQL語句需要經過SQL解析生成查詢樹、查詢優化生成執行計劃，然後將執行計劃轉交給查詢執行器做物理算子的執行操作。
SQL是介於關係演算和關係代數之間的一種描述性語言，它吸取了關係代數中一部分邏輯算子的描述，而放棄了關係代數中 “過程化” 的部分。SQL解析主要的作用就是將一個SQL語句編譯成爲一個由關係算子組成的查詢樹，通常包含詞法解析、語法解析、語義解析幾個子模塊。
規則優化（RBO）則是在查詢樹的基礎上進行等價的關係代數變換，把一條SQL語句轉換爲更高效的等價SQL，並在數據庫優化器中扮演關鍵角色。尤其在複雜查詢中，它能夠在性能上帶來數量級的提升。
查詢執行是根據執行計劃來執行SQL查詢語句。底層存儲方式的選擇合理性，將影響查詢執行效率。
解析器
1.詞法解析：從查詢語句中識別出系統支持的關鍵字、標識符、運算符、終結符等，確定每個詞固有的詞性。
SQL標準定義了SQL的關鍵字以及語法規則信息，GaussDB在做詞法分析過程中會將一個SQL語句根據關鍵字信息以及間隔信息劃分爲獨立的原子單位，每個單位以一個詞的方式展現。
2. 語法解析：根據定義的SQL語法規則，使用詞法分析中產生的詞去匹配語法規則，並生成對應的抽象語法樹（Abstract Syntax Tree，AST）。
3. 語義解析：對語法樹進行有效性檢查，檢查語法樹中對應的表、列、函數、表達式是否有對應的元數據，將抽象語法樹轉換爲查詢樹。
語義解析的過程也是有效性語義綁定的過程，通過語義分析的檢查，抽象語法樹就轉換成一個查詢樹。查詢樹可以通過關係代數表達式的形式來表現。
優化器
優化器是提升查詢效率非常重要的一個手段，它包括規則優化和查詢優化兩部分。
規則優化是在查詢樹的基礎上進行等價的關係代數變換，由於它是建立在關係代數基礎之上的優化形式，也可稱爲代數優化。雖然兩個關係代數式獲得的結果完全相同，但是它們的執行代價卻可能有很大的差異，這就構成了規則優化的基礎。
規則優化遵循兩個基本原則：
（1）等價性：原語句和重寫後的語句輸出結果相同。
（2）高效性：重寫後的語句比原語句執行時間短，且資源使用更高效。
GaussDB實現了一些關鍵的規則優化技術，例如：
謂詞下推：更早地觸發條件過濾，減少處理行數
冗餘運算消除：消除冗餘的表、列，減少計算量
子查詢提升：提升後可以匹配更多連接順序
Outer-To-Inner轉換：Inner Join可以匹配更多連接順序
子鏈接提升：減少subplan和Broadcast運算
消除不等值連接：減少NestLoop和Broadcast運算
在服務大量的客戶過程中，GaussDB對業務 SQL使用模式進行抽象，並實現了一些高級重寫規則。在今後的欄目中，我們會對GaussDB的規則優化技術做詳細介紹。
查詢優化
查詢優化是根據“規則優化”的輸出，結合數據庫內部統計信息來規劃SQL語句具體的執行方式，也就是執行計劃。基於優化方法的不同，查詢優化技術可以分爲：
（1）CBO（Cost Based Optimization，基於代價的查詢優化）：對SQL語句對應的待選執行路徑進行代價估算，從待選路徑中選擇代價最低的執行路徑作爲最終的執行計劃。
（2）ABO（AI Based Optimization，基於機器學習的查詢優化）：通過對歷史經驗的不斷學習，ABO將目標場景的模式進行抽象化，形成動態的模型，自適應地針對用戶的實際場景進行優化，從而獲得最優的執行計劃。
GaussDB採用基於CBO的優化技術，並結合ABO在建模效率、估算準確率和自適應性等方向進行積極探索，步驟如下：
圖(5) 查詢優化步驟
統計信息模型：統計信息是計算計劃路徑代價的基石，統計信息的準確度對代價估算模型中行數估算和代價估算起着至關重要的作用，直接影響查詢計劃的優劣。GaussDB基表數據的特徵包括distinct值、MCV (Most Common Values) 值、直方圖等。
行數估算 （Row Estimation）：當一個約束條件確定了選擇率之後，就可以確定每個計劃路徑所需要處理的行數，並根據行數推算出所需要處理的頁面數，爲代價估算做準備。
代價估算 （Cost Estimation）：根據數據量估算不同算子執行代價，各算子代價之和即爲計劃的總代價。
當計劃路徑處理頁面的時候，會產生I/O代價，而當計劃路徑處理元組的時候（例如,針對元組做表達式計算 ），會產生CPU代價。由於GaussDB是分佈式數據庫，在CN和DN之間傳輸數據又會產生通信代價，因此一個計劃的總代價可以表示爲：
總代價 = IO代價 + CPU代價 + 通信代價
-
路徑搜索：通過求解路徑最優算法（動態規劃、遺傳算法）處理連接路徑搜索過程，以最小搜索空間找到最優連接路徑。
GaussDB採用的是自底向上和隨機搜索模式相結合的方式。搜索過程也都是一個從查詢樹向執行計劃轉變的過程，例如針對每個表可以有不同的掃描算子，而邏輯連接算子也可以轉換爲多種不同的物理連接算子。
-
計劃生成：將查詢執行路徑轉換成執行計劃（PlanTree），提供給執行器執行。
查詢優化可能需要花費較長時間，特別是在處理複雜查詢時。計劃緩存是GaussDB的一個重要功能，它可以緩存查詢語句的執行計劃，以便在下次執行相同查詢時可以直接使用緩存中的執行計劃，從而避免重複計算和優化查詢性能。
分佈式查詢優化
作爲原生分佈式數據庫，分佈式查詢優化技術尤爲重要。
GaussDB分佈式架構充分運用每個節點的計算資源，且隨着節點規模的擴大其整體性能也呈線性增長。爲了實現分佈式架構下性能和資源的利用最大化，GaussDB支持四種分佈式計劃，分別爲CN 輕量化計劃、FQS（Fast Query Shipping）計劃、Stream計劃和Remote-Query計劃，如下圖所示：
圖(6) 四種分佈式計劃
-
CN 輕量化: 語句直接下發到單個 DN 上執行（LIGHT_PROXY）
-
執行原理：CN通過socket直接下發語句QPBE報文到對應DN。
-
適用場景：語句可以直接在一個DN執行（單shard語句）。
-
FQS（Fast Query Shipping）語句下發: 下發SQL語句的計劃
（REMOTE_FQS_QUERY）
-
執行原理：CN不通過優化器，直接生成RemoteQuery計劃，走執行器邏輯下發到DN。各DN根據下推語句生成執行計劃並進行執行，執行結果在CN上進行彙總。
-
適用場景：語句可以完全下推到多個DN上執行，且DN之間不需要數據交互。
-
STREAM 計劃下發：下發SQL計劃的分佈式計劃（STREAM）
-
執行原理：CN根據原語句通過優化器生成帶stream算子的執行計劃，下發給DN進行執行，DN執行過程中存在數據交互（stream節點）。stream算子在DN之間建立連接進行數據交互，CN彙總執行結果。DN承擔了大部分計算。
-
適用場景：執行時CN和DN之間、DN和DN之間有數據交互的複雜語句。
-
Remote-Query 計劃：下發部分SQL語句的分佈式計劃 (REMOTE_QUERY)
-
執行原理：CN通過優化器把原語句中的部分語句生成RemoteQuery計劃，把每個RemoteQuery下發到DN，DN執行後把中間結果數據發送給CN，CN收集後進行剩餘執行計劃的執行計算，因此，CN承擔了大部分計算。
-
適用場景：不滿足前三種生成條件的極少數場景，性能非常差。
在分佈式架構下，同一個表的數據會分佈到不同的數據節點上，創建表的時候可以選擇將數據在每個表上做哈希（Hash）分佈或者隨機分佈。爲了正確執行兩表連接操作，有可能需要將兩個表的數據重新分佈，因此，GaussDB的分佈式執行計劃中增加了三個使數據形成特定分佈方式的Stream算子。
圖(7) Stream算子
分佈式路徑生成時，會考慮兩表及連接條件上的數據是否處於同一個數據節點，如果不是，則會添加相應的數據分發算子。根據降低數據在DN節點間流動的原則來選擇重分佈的Stream算子。
正是基於Stream算子的合理運用，GaussDB在分佈式架構下處理大規模數據才成爲可能。針對Stream算子的優化也是GaussDB 查詢優化的重要部分。
圖(8) GaussDB分佈式查詢優化技術
【關鍵技術點】分佈式查詢優化：四種分佈式執行計劃、三個Stream算子。
執行器
執行器接收到的指令就是由優化器針對SQL查詢語句而產生的執行計劃，而執行計劃是由一些執行算子（Operator）、表達式等組成，主要是對關係集合進行運算，最終輸出用戶想要的結果集。下面是幾類常見的執行算子：
1. 掃描算子（Scan Plan Node）
掃描節點負責從底層數據來源抽取數據，數據來源可能是來自文件系統，也可能來自網絡。一般而言掃描節點都位於執行樹的葉子節 點，作爲執行的數據輸入來源，典型代表SeqScan、IndexScan、 SubQueryScan 。
關鍵特徵：輸入數據、葉子節點、表達式過濾
2. 控制算子（Control Plan Node）
控制算子一般不映射代數運算符，是爲了執行器完成一些特殊的流程引入的算子，例如Limit、RecursiveUnion、Union。
關鍵特徵：用於控制數據流程
3. 物化算子（Materialize Plan Node）
物化算子一般指算法要求，在做算子邏輯處理的時候，要求把下層 的數據進行緩存處理，因爲對於下層算子返回的數據量不可提前預 知，因此需要在算法上考慮數據無法全部放置到內存的情況，例如 Agg、Sort 。
關鍵特徵：需要掃描所有數據之後才返回
4. 連接算子（Join Plan Node） 這類算子是爲了應對數據庫中最常見的關聯操作，根據處理算法和 數據輸入源的不同分成MergeJoin, NestLoop Join, HashJoin。
關鍵特徵：關聯查詢
5. 其它算子
執行器的架構和技術也決定了數據庫查詢執行的整體運行效率。GaussDB執行引擎充分結合現代硬件技術的特徵，採用了諸如向量化引擎、LLVM等多種現代軟件技術，進行高效執行。
圖(9) GaussDB全並行執行架構
GaussDB 在執行分佈式計劃過程中，也採用了多種技術來提升查詢執行的性能。例如，在執行復雜查詢時，會將重執行算子下推到 DN 節點執行，如 AGG 算子等。在下推算子執行時，會考慮數據本地性，儘可能在本地計算，減少數據在網絡中的傳輸開銷。
如果您有任何疑問，或者感興趣的關鍵技術點，可在【雲咖問答】揭開GaussDB SQL引擎的神祕面紗，互動交流，贏好禮活動帖裏進行留言，專家會一對一進行答疑哦，還有機會獲得提問激勵。