在 8 月 13 日的 TDengine 開發者大會上，TDengine 計算引擎架構師廖浩均帶來題為《TDengine 3.0——全新計算查詢引擎的設計》的主題演講，詳細闡述了 TDengine 3.0 計算查詢引擎技術的最佳化與升級。本文根據此演講整理而成。

點選【[這裡]( https://www.taosdata.com/techtalk/13777.html"這裡")】檢視完整演講影片

3.0 中的查詢引擎在 2.0 版本的基礎上進行了重寫，在承襲 2.0 查詢引擎既有優勢和技術特性的基礎上，在工程實現和整體架構設計上有了極大的改善和提升。

總體來講，TDengine 3.0 大幅增強了對 SQL 語義的支援、完善了 SQL 查詢語法；強化了整體執行框架及 SQL 查詢的排程能力；提供更好的執行任務隔離機制，對於錯誤具備更好的容忍度；提供支援存算分離架構的能力。它主要包含以下幾個方面的特點：

**1.支援標準 SQL 查詢語法**
- 全新的 SQL 解析器、計劃生成及最佳化器，引入偽列 (_wstart/_wend/_qstart/_qend/_rowts) 等語法概念和新的（分組）關鍵詞，全面增強查詢語法。
- 消除 2.x 版本中對時序資料查詢施加的諸多限制，可以像使用關係物件資料庫查詢引擎一樣使用 SQL 查詢語法。
- 支援標籤/普通列的運算，標量函式和向量函式的巢狀、任意欄位（列）的分組/排序/聚合、無限制的多級子查詢。

**2.支援存算分離架構**
- 支援存算分離的體系架構，支援叢集內計算節點動態、快速、彈性部署。
- 查詢引擎能夠將查詢按需排程到計算節點，有效降低儲存節點（Vnode）計算資源的壓力。

**3.原生的流批一體化查詢處理**
- TDengine 3.0 原生支援流計算和互動式查詢。流計算引擎也使用 SQL 語言作為互動途徑，因此，流計算引擎直接使用查詢框架的 SQL 解析處理、執行計劃生成、查詢執行運算元、使用者應用互動等諸多方面的能力。

**4.更優秀的魯棒性和韌性設計**
- 為避免使用者錯誤導致的主服務當機，使用者定義函式的執行服務（UDFD）與 TDengine 的主程式進行隔離，UDFD 可以在崩潰以後自動被重新拉起。
- 對於 SQL 查詢轉化為排程器的查詢任務（Job），Job 在被分解以後會按層級排程執行，並且同層次任務相互獨立執行，單個任務失敗以後可以重新拉起進行處理。
- 對於不同分層的任務（Task），失敗任務可以從下游任務的結果快取（Sink Node）中再次請求資料並嘗試重新執行。

**5.更好的執行可觀測性**
- 將查詢計劃、執行開銷、查詢中 Task 的動態執行狀態等相關資訊透過命令列互動介面（CLI）呈現給使用者，助力使用者定位查詢執行的瓶頸，並進行針對性的最佳化處理。
- 提供 Explain 指令，使用者可以透過 Explain 獲得查詢執行的計劃、各運算元執行開銷等資訊，為使用者層面 SQL 改寫和最佳化效能提供支援。
- 透過心跳資訊，將服務端執行狀態推送到排程器，並反饋給使用者，讓使用者更好確定查詢執行的狀態。

**6.支援資料集快照查詢**
- 全面內建版本化的查詢支援能力，可以為事件驅動流計算引擎提供指定版本和時間範圍的歷史資料追溯查詢。
- 為雙（多）活叢集提供資料同步版本化讀取能力。

**查詢引擎架構設計**

![](http://img.blog.itpub.net/blog/2022/09/01/8f56d5e1a9147e50.jpeg?x-oss-process=style/bb)

上圖是 TDengine 3.0 的查詢引擎架構，左邊的 Query Wrapper 執行在 Vnode 和 Qnode 上，它裡面包含了一個執行器，其中的 Index 模組是處理 Vnode 中儲存的標籤資料的索引。執行器本身並不處理與排程器的互動行為，Query Wrapper 負責處理執行 Task 動作並將結果快取在 Sink Node；此外，執行器會呼叫 function 模組和 ScalarFunc 模組進行計算處理，並在必要的情況下透過 function 模組呼叫 UDF 服務。

中間的模組是由 Query Wrapper 和 libtaos.so 所共享的，裡面包含的是 function（系統中其他所有函式的定義模組）和 ScalarFunc（標量函式以及過濾的模組）。需要注意的是，在 function 模組中還包含了一個 UDFD 的計算模組，它是使用者定義程式的執行服務端，執行在一個獨立的程式空間。

最右邊的模組是執行在使用者程式空間中的驅動 libtaos.so，Driver 是 libtaos.so 裡的一個驅動，它負責串聯各個模組來完成查詢的操作，Parser 用來呼叫分詞器與語法分析器進行語法分析，生成語法樹（AST），Catalog 負責從 Mnode 和 Vnode 中獲取各種後設資料，Planner 負責將 AST 和 後設資料資訊轉化為邏輯執行計劃、物理執行計劃、並進行執行計劃重寫，最後生成分層查詢計劃，Command 負責執行本地化查詢操作。

相比於 2.0，3.0 在模組化和工程化上做了較多的最佳化，主要可以歸結為以下幾方面：

- 客戶端不參與計算，計算過程在服務端完成
- UDF 在獨立的程式空間中執行，與主服務程式隔離
- Qnode-aware 的自適應查詢任務排程策略
- Index-aware 的標籤過濾機制
- 節點間/運算元間採用標準的列格式（columnar data）資料進行資料傳遞
- 進行計算的節點會透過心跳將查詢執行資訊返回給排程器
- 重寫查詢框架，形成了高內聚、低耦合的框架模組

**時序資料查詢處理流程**

![](http://img.blog.itpub.net/blog/2022/09/01/f610b60458df39cc.jpeg?x-oss-process=style/bb)

首先，Parser 會把圖上的 SQL 語句轉成一個抽象語法樹，之後會依託於 Catalog 節點拉取相應的後設資料，然後將資訊傳遞到 planner，生成如圖上所示的邏輯計劃。之後在邏輯計劃層面會生成四個 node，自底向上分別是 Scan、Partition、Window、Project，它們分別對應 SQL 語句裡不同的幾個關鍵詞。

![](http://img.blog.itpub.net/blog/2022/09/01/2740e7ec0e3fd148.jpeg?x-oss-process=style/bb)

邏輯計劃傳遞下去，最後會在 planner 中生成一個物理計劃。上圖所示的紅色虛線以下部分（Partial Agg）是對物理計劃的執行，包括 VgID:#1 和VgTD:#2 兩個子任務；虛線上層是一個Global Merge，是最後的一個聚合階段，Partial 聚合結果經過 merge sort 後再次進行全域性聚合，形成結果以後送到計算節點本地的 sink node 進行快取，等待 scheduler 來拉取最後的計算結果。

在之前邏輯計劃中的 Logic partition 在物理計劃中卻看不到了，其實 Partition 分組邏輯是被下沉到了 TableScan 完成，這是一個最佳化操作。按照標籤分組機制，同一個表中資料一定同一分組，我們在 TableScan Node 中建立表分組的對映關係即可，再將資料塊打上 GroupID 就完成了分組操作，不需要對每一條資料進行掃描。

物理計劃的具體實現在 TDengine 系統執行的日誌裡面可以看到，感興趣的同學可以去看看，系統中的物理計劃採用 JSON 形式的文字呈現。

在實際操作中，物理計劃最終會傳遞到排程器中執行，排程器工作的元素就是 Task 和 Job，每個SQL 查詢是一個 Job，每個 Job 由若干個 Task 構成，每個 Task 包含了其執行的節點資訊、任務 ID、需要執行的物理計劃等資訊，不同的 Task 會形成一個層級化的樹形結構。

物理計劃傳遞到排程器後，虛線下面的兩個 Partial Agg 會被轉化成 Subplan #1(level 1) 和 Subplan #2(level 1)，這兩個執行計劃會分別傳送到不同的 Vnode 進行執行。虛線上層也是一個 Task [Subplan #0(level 0)]，等下層兩個 Task 執行完成或至少返回第一條記錄時，排程器就會拉起上一層 level 0 的 Task 進行執行，它是層級化的執行方式。

![](http://img.blog.itpub.net/blog/2022/09/01/9d2cbc4dbcac851f.jpeg?x-oss-process=style/bb)
時序資料查詢處理的整個流程

時序資料查詢處理的整體流程如上圖所示，其中計算節點的選擇主要有以下幾點策略：

部分聚合計算的計算節點由於聚合計算下推，要求在儲存有資料的 Vnode 上進行，以減小資料在叢集中傳輸帶來的開銷；
對於全域性聚合，可以在叢集中所有可用節點中任意選取，為了減小資料在叢集中傳輸的開銷，一般會選擇進行區域性聚合（Partial Agg) 的節點進行全域性聚合；
如果在叢集中存在 Qnode（計算節點），排程器會優先將後續階段的計算排程到計算節點上進行計算。

**時序資料查詢最佳化策略**

**排序消除**
排序是查詢過程中，I/O 和 CPU 開銷都非常高的操作。如果查詢結果要求按照 timestamp 排序（升序或降序）輸出，由於時序資料在 TDengine 中就是按照時間序列儲存，所以排序的操作可用直接消除，只需要將 TableScan 指定為升序/降序掃描返回結果即可。

**排序最佳化**
![](http://img.blog.itpub.net/blog/2022/09/01/d88bc16203ea9178.png?x-oss-process=style/bb)

操作邏輯如上圖所示。對於分散式的結果排序輸出，排序操作充分利用時序資料有序性，如果我們使用歸併排序替代完全排序，就能避免在標準外存排序過程中觸發的 IO 操作。這一操作主要在超級表查詢的場景中使用較多。

**資料替代**
從這一條最佳化策略開始，需要給大家補充一下關於 SMA 的背景知識。SMA 是 Small Materialized Aggregates 的簡稱。對於每個落盤的資料塊（Block）都會生成一個對應的 SMA 資訊，其中包含了每列資料的最大值、最小值、NULL 數量資訊。這些資訊針對數值型列都存在，必要時可以替代資料參與計算。相對於具體的資料來說，SMA 佔據的磁碟空間非常小，因此能夠極大地提升某些種類的查詢效能。
![](http://img.blog.itpub.net/blog/2022/09/01/9bd667df022ae0cc.png?x-oss-process=style/bb)

基於 SMA 的最佳化策略之一就是資料替代。針對每個函式，TDengine 定義了其需要的資料範圍，上表是一些聚合函式的資料計算需求列表。在 SQL 解析階段，如果確認其最終的資料需求是 Small Materialized Aggregates (SMA)，最終只會讀取 SMA 進行計算。但並非任何情況下都可以使用 SMA，對於所有標量函式，一旦在查詢請求裡面出現，SMA 是不參與到計算裡面來的。

在使用 SMA 時，查詢最佳化器會告訴執行節點，只需要去讀取每個 block 的 SMA 資訊就行，在整個查詢過程中，執行器不會再去讀取任何一條具體的資料，所以它的流程非常快。

**資料掃描最佳化**
TDengine 中定義了資料順序敏感型函式，在 SQL 語句中使用該型別的函式會觸發最佳化器使用特定的資料檔案掃描策略。在 SQL 語句 SELECT last(ts),count(*) FROM foo_table_name 中，Last 函式返回最後一個非 NULL 值，所以逆序掃描能夠更快獲得結果。而 count 函式對於掃描的順序並不敏感，因此，最佳化器會指令 TableScanNode 採用逆序掃描策略。

**動態裁剪 Block**
![](http://img.blog.itpub.net/blog/2022/09/01/01b3ea8650ad3716.jpeg?x-oss-process=style/bb)

對於某些查詢函式，例如：last/first/top/bottom 查詢，可以使用中間結果來動態裁剪讀取的 block 的資訊。

在執行過程之中，根據中間計算的結果及當前結果可以確定，下一個需要掃描的 block 是否需要真正地讀取。依然以 last 為例 SELECT last(ts) FROM foo_table_name，在每次需要讀取下一個 Database 時，首先使用 ts=100 過濾每個資料塊，如果資料塊包含的時間範圍晚於 ts=100， 才會讀取該資料塊資料並進行計算，大於 ts=100 的就自動跳過，這就實現了動態裁剪 Block 的功能。

**基於 SMA 的預過濾**
在進行 Last 查詢時，SMA 會被用來做預過濾，其中儲存了與之對應的資料塊的四項統計資訊：最大值、最小值、和 NULL 的數量。所有的針對資料的過濾條件首先應用在 SMA 之上，SMA 滿足過濾條件以後，再讀取資料塊，然後再次進行針對資料的過濾。

以 SELECT last(ts),count(*) FROM foo_table_name WHERE k > 20 為例，這裡面有一個過濾條件是 K 大於 20，如果其中儲存著關於 K 那一列的最大值、最小值資訊，就可以以此為條件進行過濾，如果其中的 MAX 值都小於 20，那麼這個 block 也會在 TableScanNode 裡面讀取真實資料之前就丟棄。

**Interval SMA**
時序資料庫（Time Series Database，TSDB）一個重要的應用場景就是為看板（Dash Board）提供定時的查詢（Standing Query, 應用或程式按照固定頻率發出的查詢）支援，看板應用以固定的頻率嚮應用及時序資料庫發出查詢執行，並在可接受的時間範圍內要求獲得查詢結果。

針對 Standing Query 的執行需求，為了提升響應速度，節約重複計算帶來的資源開銷。在 TDengine 3.0 中提供了使用流計算引擎的非同步 interval SMA（將針對時間視窗的聚合查詢轉化為投影查詢，因為計算結果已經透過流計算引擎計算完成並寫回到 TDengine）。

事實上，上述最佳化並不是 3.0 查詢計算引擎裡包含的所有最佳化策略，只是涉及到了幾個較為經典的查詢場景。關於查詢引擎的最佳化是非常瑣碎的，有些最佳化策略只針對一種場景，甚至如果改寫一下語句順序可能就不生效了。如果大家還想了解更多的查詢引擎最佳化策略，可以去 GitHub 上查閱 3.0 的程式碼，或者直接下載進行體驗。

**結語**

接下來，關於 TDengine 查詢引擎的最佳化，大致分為以下幾點：

- **標量計算庫採用 SIMD 進行最佳化：**採用 SIMD 指令加速標量計算的執行速度
- **支援多種指令碼語言的 UDF/UDAF：**3.0 現在支援 C 語言定義的 UDF/UDAF， 後續將支援指令碼語言定義的 UDF/UDAF，提供更便捷的使用體驗
- **支援高精度數值型別和二進位制型別資料：**高精度 Decimal 型別和 binary（1MB）型別資料的儲存、讀取和查詢
- **完善查詢最佳化器：**查詢最佳化器針對更多的查詢場景和用例提供高效率的最佳化，降低 SQL 執行的複雜程度
- **支援多源資料的聯邦查詢：**支援使用外部資料來源的聯邦查詢，透過定義聯結器，將其他的資料平臺作為查詢的基礎資料來源
- **提供更豐富的時序相關計算及分析函式和 SQL 查詢語法：**部分聚合函式將支援 CASE/WHEN、CTE 語法、SQL Hint，以及針對資料分析應用的需求，並提供更多的內建 SQL 函式

除此之外，後續我們還將完善查詢記憶體控制和任務執行/排程策略，在現有的隨機分配任務的基礎上，基於 Qnode 的執行負載狀況，排程查詢任務的執行；提供更好的記憶體控制策略，降低百萬/千萬級別表查詢過程中後設資料追蹤帶來的記憶體抖動；針對查詢範圍進行橫向的資料查詢範圍切分，在同一個 vnode 中並行拉起多個查詢執行同一個查詢處理。

總而言之，後面我們還有更多的工作要進行，會繼續最佳化 TDengine 3.0 查詢引擎的效能，也歡迎更多的 TDengine 關注者和支持者交流應用體驗，幫助我們進步。

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

想了解更多 TDengine Database的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/grafanaplugin"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)")

TDengine3.0計算查詢引擎的最佳化與升級

相關文章