UData查詢引擎最佳化-如何讓一條SQL效能提升數倍

1 UData-解決資料使用的最後一公里

1.1 背景

在大資料的範疇，我們經歷了資料產業化的歷程，從各個生產系統將資料收集起來，經過實時和離線的資料處理最終彙集在一起，成為我們的主題域資料，下一步挖掘資料的價值將成為關鍵。

資料應用直接體現資料的價值，資料應用多種多樣，它們使用資料的方式也各不相同，UData作為資料資產和資料應用之間的橋樑，它的第一目標是解決所謂的資料使用的最後一公里問題。

UData平臺以資料指標為基本的管理單位，透過四個階段對於資料使用提供支援，一體化整合資料鏈路的整個生命週期，接資料、管資料、找資料、用資料。

UData核心聚焦資料應用場景，從資料應用倒推打通資料接入、資料管理、資料查詢等環節。各種資料應用對於資料的使用方式，大部分分為兩個場景：

1. 應用線上及時訪問資料，大多數以介面的形式，UData平臺相對應的提供了資料服務的模組；
2. 業務人員透過線上查詢自己需要的資料指標（資料指標地圖），視覺化的進行人工資料分析和展示，UData平臺同時提供了資料分析的模組。

1.2 UData功能架構圖

上圖，UData功能架構自底部向上，包含了資料流轉使用的整個過程，平臺內的功能模組從資料使用的流程角度，完整的涵蓋了資料使用最後一公里的整個生命週期。

1.3 Udata的資料管理

UData對於資料的使用，從物理和邏輯兩個層面進行了劃分，並且對於多個租戶同樣進行了資源和計算的隔離。

1.4 Udata目前能做什麼？

1.4.1 指標配置化開發管理

1. UData資料接入可以將外部資料實時或者定時的匯入平臺，同時平臺提供了多種資料來源的聯邦查詢；
2. 線上視覺化的建立資料指標，並對資料指標進行打標籤；
3. 資料指標地圖使業務人員方便的查詢自己需要的業務指標；
4. 資料指標的開發，管理，使用，幾個階段相互分離，職責劃分更加松耦合，業務注意力更加聚焦；

1.4.2 指標積木式編排和介面服務

1. UData從底層資料來源開始至最上層封裝成為資料指標對外提供資料服務；
2. 資料指標在UData中可以像積木一樣透過視覺化的方式進行任意組合；
3. UData提供了介面編排能力，可以在指標組合基礎之上，實現帶有業務邏輯的分支條件判斷；

1.4.3 指標及明細互動式關聯分析和協同分享

1. UData可以重用資料檢視和資料指標，建立資料集，以此為基礎向上進行資料分析；
2. 資料集的配置支援SQL模式和視覺化配置模式，分別針對不同SQL水平的分析人員；
3. 面向資料分析應用，以應用場景為單位進行資料和計算函式的管理和組織，場景可共享；
4. 資料線上化實時分析，無需線上匯出資料；
5. 線上Excel操作，持久化Excel模式，資料實時重新整理，Excel報表線上共享;

2 Udata-查詢引擎執行介紹-一條SQL的旅行

2.1 引擎架構

Udata查詢引擎基於StarRocks進行了部分改造，由兩部分組成FrontEnd(FE),BackEnd(BE)組成。

• FE：負責接收和返回客戶端的請求，後設資料和叢集的管理，查詢計劃的生成和最佳化，協調BE進行查詢。
• BE: 主要負責SR表的資料儲存和查詢，外部表形式連線三方儲存，並執行查詢計劃中的具體節點，例如scan, 投影，聚合等。

執行主流程：

1. FE收到Sql客戶端發起的查詢請求，解析sql並制定查詢計劃；
2. FE下發執行計劃到BE, 並指定一個BE為Coordinator;
3. 各BE按照查詢計劃中的PlanFragment為執行單位，接收工作，完成工作，並將結果匯聚到Coordinator節點；
4. Coordinator的BE節點將資料返回給FE;
5. FE向Sql客戶端返回結果；

2.2 從SQL語句到執行的過程

2.2.1 過程概覽

使用者透過Mysql客戶端工具或者JDBC等方式，將需要執行的SQL語句進行輸入，輸入後的SQL語句經過語法解析，Binder,Transformer,Optimizer等過程，從基礎的sql語句，經過語法樹，Relation，邏輯計劃，分散式物理計劃等過程，最終在FE端透過Coordinator傳送到BE側進行執行，並後續收集BE返回的資料，返回給呼叫客戶端。

2.2.2 舉例介紹

表結構：

desc remote_mysql_decimal;

SQL:

select count(`decimal`) as sum,`key` from remote_mysql_decimal where id <= 1000 group by `key` order by sum desc limit 10;

2.2.3 執行過程詳解

1.解析SQL語句

在這一步驟中，SQL語句會進行語法檢查，不符合規範的語句返回錯誤，之後經過語法解析，會生成一個抽象語法樹，上面例項中的SQL語句（語句中有聚合，排序，謂詞條件，limit等元素）生成的語法樹結構如下：

2.繫結資料表後設資料資訊-生成Relation

生成語法樹之後，只是單純的SQL語法資訊，在SR中FE有一個重要的作用，就是儲存資料表的後設資料資訊（庫名，表名，列名，資料型別，對應的外表）等。
在這一步驟中，會將抽象語法樹和FE中的後設資料資訊（Catalog）進行關聯，豐富SQL相關的資訊，將抽象語法樹生成Relation這種資料結構。

3.Transformer - 基於RBO,進行Rewrite生成邏輯執行計劃

從Relation到邏輯計劃，只是基於一些SQL改寫規則，將樹中的一些節點轉變會邏輯計劃節點。

如：

• FromClause 會轉換為邏輯計劃中的LogicalScanOperator這種掃表操作；
• WhereClause 會轉換成邏輯計劃中的LOGICAL_FILTER，指導後續進行進行條件過濾；
• OrderByElements 會轉換成邏輯計劃的LOGICAL_TOPN，指導後續進行排序和limit;
• SelectList 會轉換為邏輯計劃的LogicalProjectOperator，指導後續進行投影操作，減少網路資料傳輸;

本例項中的SQL會生成如下的邏輯計劃：

4.Optimizer - 基於CBO最佳化

在這一步驟中，會根據上一步生成的邏輯計劃，同時結合FE中儲存的後設資料資訊，基於CBO最佳化執行計劃，進行謂詞下推，Join order 調整等。
本例項中生成的Optimizer Plan如下：

5.分散式物理計劃的生成- BE執行的並行單位（PlanFragment）

BE是分散式的，查詢實際執行的時候，會將計劃分配給具體的BE。BE之間，BE和FE之間透過RPC通訊傳輸資料，BE執行的最小並行單位是Fragment, 在這一步驟中會生成分散式的物理計劃。
本例項SQL生成的分散式物理計劃如下：

2.3 資料的輸出

2.3.1 PlanFragment在BE側的對映

物理執行計劃切分成PlanFragment之後，會傳送到BE側執行，BE會根據Fragment中的樹形結構，生成對應的Node，完成各自的運算元邏輯，運算元之間透過不停的呼叫下層運算元的get_next()函式，將資料用chunk的形式進行組織並流動起來，chunk的資料結構是一種列式的批結構，非常有利於向量化的執行。

2.3.2 執行模型

1.火山模型/迭代模型 （ Volcano Model ）

在這種模型中，每一種操作會抽象成一個Operator, 在執行側作為一個運算元，從頂到下呼叫next()介面，資料從底部的scan節點向上傳輸，但是每次只傳輸計算一條資料，也叫做（Tuple-at-a-time）,是一種拉取執行模式。
優點：每個Operator可以單獨實現邏輯，比較單間，靈活。
缺點：每次傳輸計算一條資料，導致next()函式呼叫次數過多，cpu效率低。

2.物化模式/Materialization Model

這種模型的處理方式，仍然是呼叫自頂向下，資料從底向上，但是每一個操作Operator一次性處理所有的輸入，處理完成之後，將結果一次性向上輸出。
此模式對於資料量較大的OLAP不太適合，但是比較適合資料量較小的OLTP系統。

3.向量化模式/批處理模型 （ Vectorized / Batch Model ）

這種模型和火山模型非常類似，不同之處是每個Operator的next()函式，會返回一批的tuples資料，相當於是一種批處理的模型，這是一種上面兩種模型的折中方式。
SR的向量化執行器主要集中在運算元向量化，表示式向量化，儲存向量化；充分利用SIMD指令最佳化，CPU Cache友好。

3 Udata查詢引擎-聯邦查詢的增強

3.1 Udata查詢引擎發展的三個階段

3.1.1 社群版FE + 自研JAVA版BE

Udata查詢引擎的第一階段，是參照StarRocks的C++版本BE實現了一個JAVA版本的BE,主要完成了Udata在第一個階段的進行聯邦查詢的資料服務的任務，並且在第一個版本基礎上，已經實現了聚合計算的下推，同時也經過了618的考驗，在執行引擎層面積累了大量的經驗，為我們開展引擎改造的第二階段提供了支援；

3.1.2 原生StarRocks + Udata改進

鑑於StarRocks表的優異效能，我們將查詢引擎切換回原生的SR, 同時將之前的積累的最佳化經驗，在原生SR上進行了實現，包括聚合查詢和Sort排序的下推，額外支援了外表資料來源CK,Jsf,Http，進行了查詢函式format等的豐富。

3.1.3 未來探索方向

在下一個階段，Udata查詢引擎將會在SR的基礎之上，密切地配合社群，引入新版本的功能，同時進行資料湖的使用探索和高效能的點查實踐，以及跨SR叢集的聯邦查詢等。

3.2 計算下推 - 極限壓榨底層引擎的計算能力

3.2.1 最佳化背景

StarRocks在聯邦查詢方面針對MySQL, ElasticSearch已經有了非常快的效能，StarRocks在聯邦查詢方面的設計思想是針對不同的查詢外部資料來源，設計不同的Scan節點，並且儘可能的將謂詞下推到Scan節點，在Scan節點查詢到資料之後，上層會共用Project節點，Agg節點，TopN等這些節點的運算元，基本的查詢架構類似下圖。

這種設計使StarRocks有非常好的擴充套件性，可以很容易的擴充套件到新一種的資料來源，也正是這種高度可擴充套件的設計使我們有機會在聯邦查詢的細節層面，做進一步的最佳化，比如將一些運算元的計算也儘可能的推到外部表引擎，可以節省一部分網路傳輸的時間，同時最大程度的壓榨底層引擎原生計算能力，透過我們的測試這種計算下推也達到了數倍於原來的效能。

3.2.2 最佳化範圍

在最佳化之前我們針對底層引擎和運算元的特徵做了調研，最佳化的範圍包括如下：

• 針對ES引擎，進行了聚合運算元的下推，但是某些特殊運算元排除，不支援sum(distinct ), avg(distinct ) 運算元下推；
• 針對MySQL引擎和ClickHouse，進行了聚合運算元，TopN運算元的下推；
• 針對新增加的Jsf和Http，進行了查詢引數下推，執行時列過濾；

3.2.3 整體最佳化思路

目前整體的最佳化思路，主要分為兩個部分，FE側的改造和BE側的擴充，同時對於原生StarRocks計算方式保持相容，可以輕易的切換回原來的計算模式。

1）FE 側改造最佳化- Optimizer Plan 的轉換

執行計劃最佳化流程

目前Udata查詢引擎對執行計劃進行最佳化的節點是在原來的Optimizer之後，我們從Scan節點開始對於執行計劃，進行了模式匹配，命中模式之後，進行對應的計算下推和投影的合併，同時過濾底層引擎不支援的特殊運算元（ 如ES的sum(distinct) ），最終將轉變後的物理計劃傳送給BE側進行執行。

模式匹配和計劃改寫

物理計劃的樹狀封裝：

ElasticSearch:

Mysql:

查詢樹改寫：

最終，AggScanOperator 會轉變為AggNode,傳送到BE進行執行。

2）BE 側改造最佳化

針對執行計劃進行了改寫之後，同樣在BE側我們建立了對應的Node節點，完成計算下推後的執行邏輯，向下對接外部執行引擎，同時向上對接類似join的聚合節點，最終輸出結果資料。

3）原生SR相容

同時執行層面，我們設定了靈活的開關 （ set agg_push_down = 0 ），可以非常容易的關閉UData最佳化。

3.2.4 改造成效-（ 30秒 vs 6秒 ）

在我們的實際過程中，我們對於計算下推，尤其是多表聚合後關聯的場景進行了觀察測試，計算效能隨著聚合表數目的增加，會有成倍數的效果提升。

3.3 JSF&HTTP&ClickHouse的支援 - 京東生態的對齊

3.3.1 簡介

JSF是京東內部的一種RPC呼叫服務，很多資料分析的場景中，一些維表是在其他服務中用JSF或者Http的方式提供的，或者一些已經計算好的資料指標需要在我們的UData計算引擎中進行關聯查詢，因此我們增加了對於JSF和Http的支援，來作為京東生態的一個補充。

JSF和HTTP查詢的兩個關注點是如何將查詢引數進行下推和如何將返回的結構化資料對映為表中的列資料，以便在聯邦查詢中進行資料關聯和聚合。

同時，京東內部有不少使用ClickHouse的場景，我們也進行了查詢支援，ClickHouse支援TCP協議，http協議，mysql wire協議，目前Udata查詢引擎透過Mysql wire協議和ClickHouse進行外表關聯。

3.3.2 主要改造點介紹

• 在FE側，增加了JSF，HTTP，ClickHouse三種外部表對應的後設資料結構，可以持久化外部表查詢需要的底層引擎的屬性資訊；
• FE側RBO改造，對於SQL語法樹對應的FromClause轉換為對應的邏輯計劃，並進一步轉換為物理計劃節點；
• BE側增加對應的ScanNode，進行資料查詢；
• 對於JSF和HTTP，透過函式，用於從FE側將查詢引數傳輸到BE側真實的查詢節點，查詢引數下推，同時列的過濾條件在獲取資料後，在Scan節點執行時過濾；
• 對於JSF和HTTP，建表中增加Mapping，將返回的JSON資料對映到資料列；
• ClickHouse外部表查詢節點，可以支援兩種模式，普通的scan查詢和計算下推的Agg查詢；

3.3.3 使用方式及案例展示

1）Jsf外部表使用

Jsf建表語句 ( 表結構+訪問JSF必須的元資訊 )：

Mapping ( Jsf 返回的json字串與資料表結構的對映 )：

查詢Sql語句 （ 查詢引數下推 和 列表示式執行時過濾 ）：

上面的sql是用來查詢Jsf外表的，同樣的其他聚合函式都可以用於該Jsf表查詢，上面主要有以下需要進行下說明:

1. 列表示式過濾：（ recv_count >= 1000 ) 這種過濾條件用於Scan操作獲取到資料之後，在BE節點內執行時進行再次過濾；
2. 查詢引數下推： jsfparam函式內建於Udata查詢引擎，可以透過此函式，將需要帶入到Jsf呼叫中的引數從呼叫端一直傳遞到Jsf服務中，從而減少資料的獲取；
3. 聯邦查詢：Jsf表同其他外表一樣可以支援聯邦查詢，也同樣可以支援其他外表支援的聚合等查詢操作；

2）Http外部表使用

Http建表語句：

Http的建表語句同上面Jsf表，只是Properties有所變化，變成了http訪問的元資訊。

查詢函式：

• httpconfig : 第一個引數是資料表中的某一個列名，後面是一個map, 目前僅支援 httpmethod 表示請求的方式 get/post ;
• httpheader : 第一個引數是資料表中的某一個列名，後面是一個map, json結構，解析後，按照key=>value 的配對，放入http請求的 header中去 ;
• httpbody : 第一個引數是資料表中的某一個列名，後面是引數，將直接放入http的請求的body中，這裡需要注意的是 http請求的方式是 application/json , 還是 x-www-form-urlencoded ，兩種方式body中的寫法是不一樣的，x-www-form-urlencoded 寫法是 key1=value&key2=value2 ;

3.4 查詢代理-使Udata查詢引擎在理論上具備了查詢一切的可能性

UData查詢引擎目前支援的聯邦資料來源有Es, Mysql, Ck, StarRocks, Hive, Iceberg, Hudi 等，同時對於UData目前不支援的資料來源可以透過代理外掛的形式進行擴充套件，我們提供了Udata Proxy的設計，只要遵循Udata代理提供的介面，實現對應的邏輯，來完成其他三方資料來源的讀取，便可以整合到UData查詢引擎中，並和其他資料來源一樣可以完成普通查詢和聯邦關聯查詢。

3.4.1 批處理 vs 分頁流式

Udata查詢引擎增加了Proxy scan 節點，Scan節點和Proxy代理之間可以透過Http和RPC兩種協議進行通訊；

資料從Proxy傳輸到Scan節點有兩種方式：

• 批處理：一次性獲取proxy返回的全部資料；
• 分頁流式：適合資料量比較大的場景，利用scroll_id的引數，使資料可以分頁微批的方式流向scan節點，需要Proxy中邏輯程式碼也支援滑動查詢；

3.4.2 邏輯讀外掛熱插拔

任何異構的資料來源可以透過邏輯讀外掛的形式來支援，Proxy runtime 提供外掛的執行環境，並進行並行執行緒的管理，邏輯讀外掛可以透過Proxy管理端進行上傳和管理，熱插拔及時生效；

4 團隊介紹

京東物流運營資料產品部-資料工具研發組職責為面向京東物流業務場景，打造資料相關工具及平臺研發，提供資料服務、分析和產品化能力，助力業務降低資料使用成本，助力研發提升資料開發效率，讓資料發揮更大價值，主打產品——服務分析一體化系統UData。

作者：劉敬斌 賀思遠