作者 | 劉垚

編輯 | 爾悅

> 小 T 導讀：在使用或者實現分散式資料庫（Distributed Database）時，會面臨把一個表的資料按照一定的策略分散到各個資料庫節點上的情況，隨之而來的是多節點資料查詢複雜性的問題，例如 Join 和子查詢。本文將會為你解讀分散式資料庫下子查詢和 Join 等複雜 SQL 如何實現，來幫助你更好地解決上述問題。

首先簡單講一下 SQL 的執行過程：

SQL ==> Parser ==> Translate & Semantic Check ==> Optimizer ==> Coordinator ==> Executer

- Parser 產生的是語法樹，即 Abstract Syntax Tree；
- Translate & Semantic Check，這一步會從 Catalog 讀取後設資料，用後設資料完善語法樹，便於 Optimizer 使用。例如：常見的 select * from tableA，一般會在這一步把“*”換成 tableA 的列；
- Optimizer 產生的是最佳化之後的邏輯執行計劃，即 Optimized Logical Plan，執行計劃是個有向無環圖，即 DAG；
- Coordinator 負責分發邏輯執行計劃給各個節點去計算；
- Executer 會把邏輯執行計劃轉成物理執行計劃，即 Physical Plan。

開源的資料庫有很多，我們可以結合一些主流資料庫的原始碼來理解子查詢和 Join 的實現方式，比如關係型資料庫 ：Impala、Presto、ClickHouse，時序資料庫（Time- Series Database）： TDengine 等。下面從子查詢和 Join 兩部分進行分析。

**子查詢部分**

邏輯執行計劃有多種 Node，分別對應著 SQL 中的各種計算，包括 Scan Node、Join Node、Aggregate Node、Sort Node、Project Node 等等，相應的物理執行計劃的運算元為 Scan Operator 、Join Operator、Aggregate Operator、Sort Operator、Project Operator 等等。而資料庫一般沒有計運算元查詢的運算元，這是因為將抽象語法樹轉成邏輯執行計劃之後，就已經沒有子查詢的概念了，其執行邏輯是資料運算元之間自下而上逐層傳遞，並逐層計算，並不特別計運算元查詢。下面講一下分散式資料庫針對子查詢的一些相關處理。

首先，分散式資料庫的最佳化器會將子查詢扁平化處理，這種方式一般分為兩種，一種是直接在語法樹（AST）上做子查詢扁平化（Subquery Flatten），另外一種是在生成邏輯執行計劃時進行扁平化。這兩種方式本質上大同小異，都要保證語義的等價性。但也並不是所有的子查詢都能扁平化，有如下幾種特殊情況：

- 子查詢和父查詢都有聚集函式
- 子查詢有聚集函式，並且父查詢有分組計算（Group By）
- 子查詢有聚集函式，並且用子查詢聚集函式的結果關聯（Join）父查詢的表
- 父查詢有聚集函式，並且子查詢有分組計算（Group By）
- 子查詢有 Limit（限制返回結果的行數），並且父查詢有過濾條件（Where）或者分組計算、排序（Order By）
- 其他

基於 AST 進行子查詢扁平化時，需要先遍歷語法資料，並按規則進行判斷，進而去除不必要的子查詢。對於生成邏輯執行計劃時的子查詢扁平化，在生成 Plan Node 時需要先去除冗餘的 Node，舉個例子，SQL：select colA from (select * from tA) group by colA;
![](http://img.blog.itpub.net/blog/2022/06/07/9fb6365bbe42366c.png?x-oss-process=style/bb)

一般來說，邏輯執行計劃會有多個子計劃，通常在需要網路傳輸時才會產生子計劃，需要注意的是子計劃和子查詢之間並沒有必然的聯絡，即有子查詢不一定對應一個子計劃。

**Join 部分**

首先，分散式資料庫會對 Join 進行最佳化，包括 Join 消除（例如基於主鍵外來鍵去除不必要的 Join）、外連線消除（Outer Join 轉成 Inner Join）、Join Order 最佳化（基於資料的統計資訊，用動態規劃演算法、貪心演算法或遺傳演算法等最佳化 Table 的 Join 順序）等等。

再講一下 Join 的三種基本演算法：Hash Join（必須要有等值連線條件，例如 t1.colA = t2.colB）、Merge Join（左表和右表的資料都是有序的，按連線條件中的列有序）、Nestloop Join（含有非等值連線條件並且資料無序）。在實際當中，會把三種演算法進行混合使用，這是因為 Join 條件可以同時包含等值連線和非等值連線，例如 t1.colA = t2.colB AND t1.colC > t2.colC

**Hash Join**

在進行 Join Order 最佳化時，最佳化器會調整左表和右表的順序，一般把小表放右邊，大表放左邊，並且選擇 Join 模式：Shuffle Join（按照關聯條件，同時 shuffle 左表和右表，然後再計算 Join） 或 Boradcast Join（把右表廣播到左表所在的節點，注意左表不動，然後再計算 Join）。一般是基於代價去選擇 Join Order 最佳化，但考慮到統計資訊可能會存在誤差，因此很多資料庫可以透過 Hint、Query Option 等方式，由使用者來指定 Join 順序、Join 模式等。

Hash Join 是目前最常用的 Join 演算法，大部分資料庫都實現了 Hash Join。這種演算法會先讀取右表，並把右表的資料放入 Hash Map 裡，如果存不下就會放入外存。通常情況下，各個資料庫都會實現自己的 Hash Map，很少直接使用 STL 或 Boost 等第三方庫中的 Hash Map，原因主要有兩點：

- 定製化 Hash Map 會提升 Join 計算速度。
- 定製化 Hash Map 能更準確地控制記憶體使用，當記憶體不足時，會使用外存，定製化 Hash Map 可以根據 Join 演算法，最佳化 Swap 機制，減少 Swap 的資料量。Hash Map 的結構如下：

![](http://img.blog.itpub.net/blog/2022/06/07/31fdf295b77e6359.png?x-oss-process=style/bb)

右表可能含有重複的資料，所以會有 Duplicate Node。這裡的重複資料是指 Join Key（Join 條件對應的列）的資料重複，並且其他列不重複，所以要分別快取。注意上述圖中，是透過 Hash 演算法解決 Hash 衝突的問題，即不會把不同的 Join Key 放在同一個桶中。當然，現實操作中也有把不同的 Join Key 放在同一個桶中的情況，那需要遍歷 List 才能確定查詢的 Join Key 是否存在。

**Merge Join**

Merge Join 一般是在左表和右表的資料是有序的情況下使用。例如時序資料庫 TDengine，資料按時間戳列有序，那麼用時間戳列做 Join 時，TDengine database 會用 Merge Join 來計算，這樣的一個好處是處理速度非常快，並且佔用記憶體非常小。

**Nestloop Join**

這種 Join 演算法速度非常慢，但對於全功能資料庫而言是不可缺少的。使用這種演算法時，可以結合索引來提速。

總結而言，Hash Join 使用最廣，適用於很多資料分析的場景，並且大部分資料庫都支援；Merge Join 一般是在左右表資料有序時才會使用，不需要快取資料，所以使用記憶體非常少，計算速度是三種 Join 演算法中最快的；Nestloop Join 效能很差，分散式資料庫一般很少使用，有些分散式資料庫就不支援，可以透過索引來加速 Nestloop Join。

**寫在最後**

上面我們對子查詢和 Join 兩種複雜 SQL 的實現方式做了具體解讀，大家可以結合一些開源資料庫的原始碼來理解，像 TDengine 的原始碼都可以在 [GitHub]( https://github.com/taosdata/TDengine"GitHub") 上看到，如果你對時序資料庫的複雜 SQL 實現有興趣，這就是一個不錯的觀摩物件。也歡迎大家在下方評論區進行交流。

------------

想了解更多 TDengine Database的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/TDengine"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")

分散式資料庫下子查詢和 Join 等複雜 SQL 如何實現？

相關文章