貨拉拉大資料離線混合引擎服務建設實踐

　　 1. 背景

　　貨拉拉作為一家資料智慧驅動的科技物流型平臺企業，內部分析師和研發人員等每天會透過大資料服務進行大量 ad-hoc 查詢分析。透過 NPS 調研發現使用者普遍反饋 ad-hoc 查詢慢問題，對查詢效率滿意度較低。大資料使用 Hive on Tez 作為 ad-hoc 查詢引擎，受限於引擎自身特點，在 ad-hoc 查詢場景無法滿足使用者對時效的要求。為提升 SQL 查詢效率，大資料引入更多型別引擎並自主研發了離線混合引擎服務來幫助使用者查詢提速。以下描述貨拉拉大資料在離線 ad-hoc 查詢場景下透過混合引擎服務進行提效的一些實踐經驗。

　　 2. 業界調研

　　在業界調研過程中，我們也發現了一些類似的產品，例如騰訊的SuperSQL、阿里的DLA、華為的HetuEngine、360的Quicksql和網易開源的Kyuubi等，下面表格總結了它們各自的特點以及差異。

　　總的來說，它們一般具備以下特點：

　　1. 多資料來源能力：支援多種 BigData/RDBMS/NoSQL/FileSystem 資料來源。

　　2. 多引擎路由能力：在不指定引擎的模式下，能夠根據SQL特徵分析，路由到最合適的引擎執行，並能智慧降級。

　　3. SQL轉換能力：上層提供單一的SQL語法，底層能夠根據轉換為不同引擎的SQL語法。

　　4. SQL最佳化能力：能夠透過RBO/CBO/HBO等能力，最佳化SQL執行。

　　5. 聯邦查詢能力：在統一平臺上能夠進行多資料來源之間的聯邦查詢。

　　 3. 設計與實現

　　系統的設計目標需要考慮以下幾個方面：

　　• 功能需求：研發一個能充分結合多引擎優點，實現多引擎智慧路由，遮蔽引擎間差異性，多引擎間能自動降級，提供統一大資料SQL引擎的系統。

　　• 穩定性：系統需要具備良好的穩定性，以確保其在高負載和複雜場景下的穩定執行。

　　• 擴充套件性：系統需要具備一定的可擴充套件性，以滿足未來業務的發展需求。

　　• 易用性：業務易接入，無需過多的改造工作。

　　• 正確性：無因多引擎間的相容性導致的資料質量問題。在上述設計目標要求下，我們的服務架構採用典型的Master/Worker架構。Master角色實現HA部署來保證服務穩定性；Worker角色具備良好的擴充套件性，可基於請求量的大小而彈性調整服務的規模；在易用性方面，提供了SDK/JDBC/Cli等接入方式；在資料正確性方面，透過自研的多引擎資料對賬工具來保證。在調研過程中，我們有發現一些案例是將所有功能都整合到一個SDK，然後讓業務接入使用。但是我們沒有采取這種方式，而是選擇了做成一個獨立的服務，主要是因為這樣可以減少業務頻繁升級帶來的麻煩，並且也可以得到更多自主可控的能力。

　　3.1 功能架構

　　下圖展示的是服務的整體功能架構圖。　　

　　服務的功能架構從上到下分為以下幾層：

　　1. 應用層：服務上面承載的業務有即席查詢平臺（BigQuery）、資料質量平臺（大禹）、BI平臺（雲臺）、ABTest平臺等。

　　2. 接入層：提供SDK、JDBC、Shell等接入方式來提交SQL查詢；提供認證、許可權、限流、審計等功能。

　　3. 路由層：能夠對SQL進行特徵分析，選擇出最適合的引擎，對SQL進行解析與轉換提交到引擎執行，並在某個引擎執行失敗後能夠進行智慧降級到其他引擎執行。

　　4. 執行層：能夠將SQL投遞到具體引擎並獲取結果返回給客戶端，並感知底層引擎算力；對資源（執行緒/記憶體/連線）進行管理。

　　5. 引擎層：具體執行SQL的引擎，目前包括Presto和Hive引擎。離線混合引擎服務的主要功能包括接入層、路由層和執行層。除此之外，我們還對服務提供了一些管理/輔助能力，主要包括：對服務配置進行管理，能夠實時更新配置，動態上下線節點；提供HBO服務，記錄SQL最近路由以及執行相關等資訊；提供日誌服務，讓使用者能夠查詢歷史SQL執行日誌；接入公司Monitor監控系統，對服務核心指標進行埋點，能夠實時監控服務狀態。

　　3.2 系統架構

　　系統角色包括Client/Master/Worker，角色之間透過gRPC進行通訊。在系統設計與實現上，我們也充分參考了YARN的資源管理設計、HiveServer2的介面設計以及Query狀態機設計等。下圖展示的是角色之間的互動圖。　

　　3.2.1 Master

　　Master透過Zookeeper實現HA部署來保證服務的高可用性，服務狀態會持久化到外部儲存，便於在服務當機或者切主時能夠恢復。主要包含以下幾個功能：

　　1. 資源生命週期管理：為Client分配QueryId以及Worker Slot資源，並對其生命週期進行管理。

　　2. 負載均衡：透過心跳感知每個Worker資源現狀，對新的請求實現負載均衡。

　　3. 服務上下線：Worker節點上線會向Master註冊，加入資源池；可以透過Master修改節點狀態下線節點。

　　3.2.2 Client

　　Client（SDK/JDBC/Cli）功能相對簡單，負責提交SQL到Worker角色執行，等待SQL執行完成並獲取結果返回。具體流程步驟為：首先透過Zookeeper獲取Master地址並向Master申請資源，然後向指定Worker提交SQL，最後等待SQL執行完成並獲取結果。

　　3.2.3 Worker

　　Worker是系統中較為複雜的部分，負責接收Client提交的SQL，經過一系列複雜的轉換，最後提交到計算引擎執行，獲取計算結果並返回給客戶端。下圖展示的是SQL在Worker內部的執行流程圖。　　

　　1. Worker接收到SQL後會交給QueryManager進行管理，QueryManager主要負責管理Query資訊、監聽Query的執行狀態以及投遞SQL到執行引擎。

　　2. Dispatcher會對SQL進行特徵分析，包括但不限於SQL型別、SQL掃描資料量、SQL中各種執行運算元數量（GroupBy/Join/MapJoin等）、SQL是否包含特定關鍵字/UDF等，進而決定SQL投遞到哪個計算引擎。

　　3. SQL Converter負責將源SQL轉換為目標引擎的SQL語法。

　　4. 提交到QueryExecutor中執行，QueryRunner負責提交SQL到計算引擎中執行，獲取SQL執行日誌（儲存在本地或者遠端儲存），並不斷向QueryManager上報Query狀態，最後獲取計算結果並返回給客戶端。

　　5. 如果投遞到某個引擎執行失敗之後，QueryManager會為該SQL降級到其他引擎中執行（兜底引擎是Hive），確保SQL最終能夠執行成功。

　　3.2.4 Query的生命週期

　　Query的生命週期透過狀態機進行流轉，包含6種狀態，流轉圖如下圖所示：　　

　　1. INITIALIZED：Query向Master申請到資源後被置為INITIALIZED狀態，如果一直處於INITIALIZED沒有得到Worker的ACK，該資源便會被Master回收掉。

　　2. RUNNING：Query提交到Worker便會被置為RUNNING狀態，在多引擎間進行降級繼續保持RUNNING狀態。

　　3. FINISHED：在目標引擎上執行成功時便會被置為FINISHED狀態。

　　4. CLOSED：Client主動close/cancel後便會被置為CLOSED狀態。

　　5. TIMEOUT：Query查詢達到使用者設定超時時間或者該Query已經長時間沒有操作。

　　6. ERROR：Query在計算引擎上執行失敗且無法降級時便會被置為ERROR狀態。

　　3.3 其他

　　在這個過程中也發現一些比較有意思的點：

　　1. Client端是根據Query的狀態來驅動的，所以在更新Query狀態的鏈路上一定要特別注意，減少不必要的效能損耗。

　　2. HBO服務：使用者在一個小時間區間內（例如30min）可能會重複提交的一些SQL，所以可以快取SQL的路由引擎和最後執行成功引擎等資訊（設定一定TTL），這樣使用者提交重複SQL就不需要再次經過Dispatcher模組了，也可以減少一些時間損耗。

　　3. 引擎間執行方式相容：比如Hive在SQL執行成功時，計算過程已完成且資料寫到HDFS臨時目錄等待使用者讀取；但Presto是典型的Pipeline執行模式，資料會像流水一樣返回給使用者（一邊計算一邊返回結果），所以就可能會出現當計算結果資料量比較大時，到獲取結果的最後階段才出錯。這種情況也需要被服務cover住，所以當資料量較小時，可以全部儲存在記憶體中，但是當發現資料量過大時就需要溢寫到磁碟或者外部儲存，這樣在執行過程中發現錯誤也能及時進行降級。

　　 4. 上線效果

　　從2022年1月份上線以來，內部進行了多個版本的迭代，在查詢提效這方面也取到了良好的效果。目前ad-hoc 即席查詢取數：P65提速82%（50s-> 8s），P75提速64.1%（78s->28s），各個分位的效果提升如下圖。　　

　　（BigQuery: 貨拉拉自研的ad-hoc即席查詢工具）

　　 5. 未來規劃

　　資料分析和開發人員更應該關注的是業務邏輯的實現，而不是底層計算引擎的選型與SQL調優。貨拉拉離線混合引擎服務的長遠規劃，旨在為使用者提供統一的計算入口，遮蔽掉底層計算引擎的複雜性，降低使用者使用門檻，實現業務層與引擎層的解耦。當前混合引擎支援的場景還比較有限，比如不支援ETL和多資料來源聯邦查詢等場景，距離構建統一的計算引擎還有一定的距離。結合業務需求以及技術演進需要，混合引擎的下一步規劃，將從以下3個點來開展：

　　1. 更高的查詢效率。目前混合引擎實現了對P65簡單查詢的10秒內響應，但是對於較為複雜的查詢，其查詢效率並沒有得到提升。主要原因是這部分查詢不滿足路由規則，沒有被路由到Presto上去執行。目前的路由規則（比如資料量大小、Join數等閾值）相對比較靜態，不會根據引擎的負載情況而調整。後續將對路由規則進行最佳化，儘可能多的將查詢路由到Presto，提升查詢效率。

　　2. 支援ETL場景。引入Spark引擎，將離線鏈路的ETL任務無感遷移到Spark，並且保證任務的穩定性。

　　3. 支援多資料來源聯邦查詢。打通多資料來源，實現不同型別資料來源（離線數倉、OLAP 資料、線上資料等）的資料聯合分析/及時查詢的需求，消除不同資料來源之間的資料“孤島”。