持續創作，加速成長！這是我參與「掘金日新計劃 · 10 月更文挑戰」的第14天，點擊查看活動詳情
1 UData-解決數據使用的最后一公里1.1 背景
在大數據的范疇，我們經歷了數據產業化的歷程，從各個生產系統將數據收集起來，經過實時和離線的數據處理最終匯集在一起，成為我們的主題域數據，下一步挖掘數據的價值將成為關鍵。
數據應用直接體現數據的價值，數據應用多種多樣，它們使用數據的方式也各不相同，UData作為數據資產和數據應用之間的橋梁，它的第一目標是解決所謂的數據使用的最后一公里問題。
UData平臺以數據指標為基本的管理單位，通過四個階段對于數據使用提供支持，一體化整合數據鏈路的整個生命周期，接數據、管數據、找數據、用數據。
UData核心聚焦數據應用場景，從數據應用倒推打通數據接入、數據管理、數據查詢等環節。各種數據應用對于數據的使用方式，大部分分為兩個場景：
應用在線及時訪問數據，大多數以接口的形式，UData平臺相對應的提供了數據服務的模塊；業務人員通過在線查找自己需要的數據指標（數據指標地圖），可視化的進行人工數據分析和展示，UData平臺同時提供了數據分析的模塊。1.2 UData功能架構圖
上圖，UData功能架構自底部向上，包含了數據流轉使用的整個過程，平臺內的功能模塊從數據使用的流程角度，完整的涵蓋了數據使用最后一公里的整個生命周期。
1.3 Udata的數據管理
UData對于數據的使用，從物理和邏輯兩個層面進行了劃分，并且對于多個租戶同樣進行了資源和計算的隔離。
1.4 Udata目前能做什么？1.4.1 指標配置化開發管理UData數據接入可以將外部數據實時或者定時的導入平臺，同時平臺提供了多種數據源的聯邦查詢；在線可視化的創建數據指標，并對數據指標進行打標簽；數據指標地圖使業務人員方便的查找自己需要的業務指標；數據指標的開發，管理如何比對excel表格兩列數據中的相同部分?，使用，幾個階段相互分離，職責劃分更加松耦合，業務注意力更加聚焦；1.4.2 指標積木式編排和接口服務UData從底層數據源開始至最上層封裝成為數據指標對外提供數據服務；數據指標在UData中可以像積木一樣通過可視化的方式進行任意組合；UData提供了接口編排能力，可以在指標組合基礎之上，實現帶有業務邏輯的分支條件判斷；1.4.3 指標及明細交互式關聯分析和協同分享UData可以重用數據視圖和數據指標，創建數據集，以此為基礎向上進行數據分析；數據集的配置支持SQL模式和可視化配置模式，分別針對不同SQL水平的分析人員；面向數據分析應用，以應用場景為單位進行數據和計算函數的管理和組織，場景可共享；數據在線化實時分析，無需線上導出數據；在線Excel操作，持久化Excel模式，數據實時刷新，Excel報表在線共享;2 Udata-查詢引擎執行介紹-一條SQL的旅行2.1 引擎架構
Udata查詢引擎基于進行了部分改造，由兩部分組成(FE),(BE)組成。
執行主流程：
FE收到Sql客戶端發起的查詢請求，解析sql并制定查詢計劃；FE下發執行計劃到BE, 并指定一個BE為;各BE按照查詢計劃中的為執行單位，接收工作，完成工作，并將結果匯聚到節點；的BE節點將數據返回給FE;FE向Sql客戶端返回結果；2.2 從SQL語句到執行的過程2.2.1 過程概覽
用戶通過Mysql客戶端工具或者JDBC等方式，將需要執行的SQL語句進行輸入，輸入后的SQL語句經過語法解析，,,等過程，從基礎的sql語句，經過語法樹，，邏輯計劃，分布式物理計劃等過程，最終在FE端通過發送到BE側進行執行，并后續收集BE返回的數據，返回給調用客戶端。
2.2.2 舉例介紹
表結構：
desc ;
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.綁定數據表元數據信息-生成
生成語法樹之后，只是單純的SQL語法信息，在SR中FE有一個重要的作用，就是保存數據表的元數據信息（庫名，表名，列名，數據類型，對應的外表）等。
在這一步驟中，會將抽象語法樹和FE中的元數據信息（）進行關聯，豐富SQL相關的信息，將抽象語法樹生成這種數據結構。
3. - 基于RBO,進行生成邏輯執行計劃
從到邏輯計劃，只是基于一些SQL改寫規則，將樹中的一些節點轉變會邏輯計劃節點。
如：
本實例中的SQL會生成如下的邏輯計劃：
4. - 基于CBO優化
在這一步驟中，會根據上一步生成的邏輯計劃，同時結合FE中保存的元數據信息，基于CBO優化執行計劃，進行謂詞下推，Join order 調整等。
本實例中生成的 Plan如下：
5.分布式物理計劃的生成- BE執行的并行單位（）
BE是分布式的，查詢實際執行的時候，會將計劃分配給具體的BE。BE之間，BE和FE之間通過RPC通信傳輸數據，BE執行的最小并行單位是, 在這一步驟中會生成分布式的物理計劃。
本實例SQL生成的分布式物理計劃如下：
2.3 數據的輸出2.3.1 在BE側的映射
物理執行計劃切分成之后，會發送到BE側執行，BE會根據中的樹形結構，生成對應的Node，完成各自的算子邏輯，算子之間通過不停的調用下層算子的()函數，將數據用chunk的形式進行組織并流動起來如何比對excel表格兩列數據中的相同部分?，chunk的數據結構是一種列式的批結構，非常有利于向量化的執行。
2.3.2 執行模型1.火山模型/迭代模型 （ Model ）
在這種模型中，每一種操作會抽象成一個, 在執行側作為一個操作數，從頂到下調用next()接口，數據從底部的scan節點向上傳輸，但是每次只傳輸計算一條數據，也叫做（Tuple-at-a-time）,是一種拉取執行模式。
優點：每個可以單獨實現邏輯，比較單間，靈活。
缺點：每次傳輸計算一條數據，導致next()函數調用次數過多，cpu效率低。
2.物化模式/ Model
這種模型的處理方式，仍然是調用自頂向下，數據從底向上，但是每一個操作一次性處理所有的輸入，處理完成之后，將結果一次性向上輸出。
此模式對于數據量較大的OLAP不太適合，但是比較適合數據量較小的OLTP系統。
3.向量化模式/批處理模型 （ / Batch Model ）
這種模型和火山模型非常類似，不同之處是每個的next()函數，會返回一批的數據，相當于是一種批處理的模型，這是一種上面兩種模型的折中方式。
SR的向量化執行器主要集中在算子向量化，表達式向量化，存儲向量化；充分利用SIMD指令優化，CPU Cache友好。
3 Udata查詢引擎-聯邦查詢的增強3.1 Udata查詢引擎發展的三個階段
3.1.1 社區版FE + 自研JAVA版BE
Udata查詢引擎的第一階段，是參照的C++版本BE實現了一個JAVA版本的BE,主要完成了Udata在第一個階段的進行聯邦查詢的數據服務的任務，并且在第一個版本基礎上，已經實現了聚合計算的下推，同時也經過了618的考驗，在執行引擎層面積累了大量的經驗，為我們開展引擎改造的第二階段提供了支持；
3.1.2 原生 + Udata改進
鑒于表的優異性能，我們將查詢引擎切換回原生的SR, 同時將之前的積累的優化經驗，在原生SR上進行了實現，包括聚合查詢和Sort排序的下推，額外支持了外表數據源CK,Jsf,Http，進行了查詢函數等的豐富。
3.1.3 未來探索方向
在下一個階段，Udata查詢引擎將會在SR的基礎之上，密切地配合社區，引入新版本的功能，同時進行數據湖的使用探索和高性能的點查實踐，以及跨SR集群的聯邦查詢等。
3.2 計算下推 - 極限壓榨底層引擎的計算能力3.2.1 優化背景
在聯邦查詢方面針對MySQL, 已經有了非常快的性能，在聯邦查詢方面的設計思想是針對不同的查詢外部數據源，設計不同的Scan節點，并且盡可能的將謂詞下推到Scan節點，在Scan節點查詢到數據之后，上層會共用節點，Agg節點，TopN等這些節點的算子，基本的查詢架構類似下圖。
這種設計使有非常好的擴展性，可以很容易的擴展到新一種的數據源，也正是這種高度可擴展的設計使我們有機會在聯邦查詢的細節層面，做進一步的優化，比如將一些算子的計算也盡可能的推到外部表引擎，可以節省一部分網絡傳輸的時間，同時最大程度的壓榨底層引擎原生計算能力，通過我們的測試這種計算下推也達到了數倍于原來的性能。
3.2.2 優化范圍
在優化之前我們針對底層引擎和算子的特征做了調研，優化的范圍包括如下：
3.2.3 整體優化思路
目前整體的優化思路，主要分為兩個部分，FE側的改造和BE側的擴充，同時對于原生計算方式保持兼容，可以輕易的切換回原來的計算模式。
1）FE 側改造優化- Plan 的轉換
執行計劃優化流程
目前Udata查詢引擎對執行計劃進行優化的節點是在原來的之后，我們從Scan節點開始對于執行計劃，進行了模式匹配，命中模式之后，進行對應的計算下推和投影的合并，同時過濾底層引擎不支持的特殊算子（ 如ES的sum() ），最終將轉變后的物理計劃發送給BE側進行執行。
模式匹配和計劃改寫
物理計劃的樹狀封裝：
:
Mysql:
查詢樹改寫：
最終， 會轉變為,發送到BE進行執行。
2）BE 側改造優化
針對執行計劃進行了改寫之后，同樣在BE側我們創建了對應的Node節點，完成計算下推后的執行邏輯，向下對接外部執行引擎，同時向上對接類似join的聚合節點，最終輸出結果數據。
3）原生SR兼容
同時執行層面，我們設置了靈活的開關 （ set = 0 ），可以非常容易的關閉UData優化。
3.2.4 改造成效-（ 30秒 vs 6秒 ）
在我們的實際過程中，我們對于計算下推，尤其是多表聚合后關聯的場景進行了觀察測試，計算性能隨著聚合表數目的增加，會有成倍數的效果提升。