本文分享自華為雲社區《走向批處理-互動式分析一體化： Trino容錯模式深度測評與思考》，作者：HetuEngine九級代言 。

本文系華為雲大數據研發團隊原創，原創作者：文博，夢月

1 Trino簡介

2020年12月27日，Presto社區大佬們——Martin Traverso、 Dain Sundstrom 以及 David Phillips 宣佈將開源項目PrestoSQL的名字更名為TrinoDB（本文簡稱Trino）。

Trino是一款開源的高性能、分散式SQL查詢引擎，專門用於對各種異構數據源運行互動式分析查詢，支持從GB到PB的數據量範圍。Trino專門為互動式分析而設計，可以對來自不同數據源的數據（包括：Hive、AWS S3、Alluxio、MySQL、Kafka、ES等等）進行合併查詢，並提供良好的自定義連接器編程擴展框架。適用於期望響應時間從亞秒到數分鐘不等的分析師場景。

在誕生之初，Trino是為了填補當時 Facebook 內部實時查詢和 ETL 處理之間的空白。Trino的核心目標就是提供互動式查詢，也就是我們常說的 Ad-Hoc Query，很多公司都使用它作為 OLAP 計算引擎。近年來業務場景越來越複雜，除了互動式查詢場景，很多公司也需要兼顧批處理作業，技術大佬們開始思考如何用Trino來進行大數據集的批加工處理。

2 傳統Trino架構的局限性

在傳統Trino運行架構中，Trino 預先規划了處理特定查詢的所有task 。這些task彼此關聯，一項task的結果是下一項task的輸入。對於MPP引擎來說，這種相互依賴是必要的。一旦任何任務在此過程中失敗，就會破壞整個任務鏈條，導致整個SQL執行退出。

Trino執行SQL任務過程如下圖（來自Trino官網）：

優點：

       數據通過task進行流式傳輸，沒有中間檢查點，高吞吐低延遲

不足：

• 缺乏細粒度的故障回覆，出現問題只能從頭運行整個Query
• 完全依賴記憶體資源進行數據裝載和交換
• 執行規劃一旦確定就無法根據實際執行進展靈活調整

3 Trino容錯執行架構（FTE）

Trino開源社區設計了一種新的容錯執行架構（fault-tolerant execution architecture），它允許我們實現具有細粒度重試的高級資源感知調度（advanced resource-aware scheduling）。該項目代號為“Tardigrade”。

Tardigrade項目旨在打破原有的全有或全無的執行障礙。它為資源管理、自適應查詢優化和故障恢復帶來了許多新的機會。該項目以水熊蟲命名 ，水熊蟲是世界上最堅不可摧的生物，類似於FTE為 Trino 帶來的魯棒性。

以下是 Tardigrade 項目帶來的一些直觀效果：

• 當長時間運行的SQL Query遇到故障時，不必從頭開始運行；
• 當Query需要的記憶體超過集群中當前可用的記憶體時，仍然能夠運行成功；
• 當多個Query同時提交時，它們能夠以公平的方式共用資源，並穩步運行

從代碼實現角度看， Trino直接在內核中實現了task級容錯、自動重試、shuffle等核心功能。如下圖所示（來自Trino官網）：

Trino會將一個Query執行分成多個stage。在容錯模式下，上游stage的shuffle數據會進行落盤（支持寫到AWS S3、HDFS及本地存儲）。下游stage從中間存儲里讀取所需要的數據，併在該過程中對後續task任務進行重新優化與分配。

帶來的改進：

• 適應性規劃：可以在緩衝數據時，動態調整查詢計劃
• 資源管理：在查詢運行時調整資源分配。當集群空閑時，我們可以允許單個查詢利用集群上的所有可用資源。當更多工作負載開始時，可​​以逐漸減少初始查詢的資源分配。
• 細粒度的故障恢復：允許透明地重啟失敗的任務，使得ETL完成時間更可預測。

接下來，本文將帶各位深入體驗Trino容錯執行模式。

4 基礎性能測試

首先在計算資源充足的場景下進行基礎性能測試。選取1TB數據量的TPCDS，計算資源規格為2CN+16Worker 136GB/進程，測試開啟容錯前後，執行TPCDS99，耗時統計如下：

測試寫入性能選擇TPCDS表中最大的表catalog_sales測試寫入性能，SQL為：

--- create table catalog_sales_copy as select * from catalog_sales;

測試數據如下：

小結：

• 開啟Task容錯會進行中間交換區結果落盤，存在性能損耗，執行耗時約為之前的2倍；
• Query容錯沒有落盤的過程，與不開啟容錯性能持平。
• 1TB數據集時，Task容錯寫入性能也會有8%-10%損耗，但在10TB數據集時反而有性能提升，待深入分析；

5 大數據量場景的穩定性測試

本節將在計算資源嚴重不足的場景下進行TPCDS壓力測試。測試結果如下：

小結：

• 記憶體不足情況下使用Task容錯，能夠大幅度提高SQL執行成功率。與spill to disk特性結合使用能帶來更好的容錯效果；
• 在50TB數據集時，Task容錯仍然能夠提高執行成功率，但某些複雜SQL可能會存在單點瓶頸。目前觀察到主要是單點聚合瓶頸。

6 高併發場景測試

6.1 1TB TPCD標準數據集

計算資源規格：1CN+8Worker，136GB/進程

測試SQL用例： Q01（多事實表關聯查詢，即TPCDS99中的Q29）

測試結果如下表所示：

6.2 10TB TPCD標準數據集

計算資源規格：1CN+8Worker，136GB/進程

測試SQL用例：

單表多列聚合排序查詢Q02：

select

• ws_item_sk,
• ws_web_site_sk,
• sum(ws_sales_price) total

from

• web_sales

where

• ws_sold_date_sk >= 2450815
• and ws_sold_date_sk <= 2451179

group by

• ws_item_sk,
• ws_web_site_sk

having

• sum(ws_sales_price) > 0

order by

• total desc

limit 100;

開啟TASK容錯全部能夠執行成功。測結果如下表所示：

小結：

Task容錯能夠提升Trino引擎的併發上限，很大程度上減少諸如“Encountered too many errors talking to a worker node.”報錯的產生。

7 多個引擎橫向對比測試

首先從TPCDS99中挑選出計算資源受限前提下，Trino不開啟容錯100%會跑失敗的SQL用例，包括：

Q04，Q11，Q23，Q38，Q64，Q65，Q67，Q74，Q75，Q78，Q80，Q81，Q85，Q87，Q93，Q95，Q97

基於相同計算資源（記憶體、CPU、Container個數），橫向對比Trino、Spark、Hive(TEZ) 的性能表現。

註：測試Trino時實際採用的是華為雲HetuEngine 2.0的內核版本。

7.1 1TB TPCD標準數據集

可看出，在1TB數據量、使用相同資源情況下，開啟Task容錯，Trino能夠將原先跑失敗的SQL執行成功，且性能約為Spark的3倍左右，是Hive(TEZ)的數十倍。

7.2 10TB TPCDS標準數據集

針對10TB TPCDS標準數據集，進行對比測試：

可看出，在10TB數據量、使用相同資源情況下，開啟Task容錯，Trino能夠將原先跑失敗的SQL執行成功，且性能約為Spark的3倍左右。

8 綜合評價

綜上，基於測試數據總結歸納如下——

單併發基礎性能

• 記憶體資源充足：不開啟容錯 = Query容錯 > Task容錯
• 記憶體資源不足：Task容錯可以跑過，不開啟容錯/Query容錯跑不出結果

大數據量場景的穩定性

         Task容錯 + spill to disk > Task容錯 > 不開啟容錯

• 1-10TB數據集：Task容錯的表現很穩定，通過率100%
• 50TB數據集： 結合使用Task容錯、spill to disk相比單獨用Task容錯表現更好(少失敗1個用例)

併發場景的穩定性

         Task容錯 > 不開啟容錯

多個引擎橫向性能對比

• 1TB TPCDS數據集：Trino(Task容錯) > Spark > Hive(TEZ)
• 10TB TPCDS數據集：Trino (Task容錯) > Spark

總體而言，Trino的FTE功能在性能、穩定性維度的測試表現超出了預期。隨著該能力的逐步演進與完善，相信Trino將在一站式數據加工與分析場景發揮出更大的價值。

9 思考與改進

在擁有了第一手的測試數據與分析結論後，接下來我們將思考如何利用好Trino容錯模式，最大化的發揮其價值，同時要提前識別可能存在的問題，探索解決之道。

9.1 容錯模式啟用決策

從前面的測試數據可以看出，開啟容錯模式對於短查詢性能存在一定的影響（對大查詢性能反而存在優化的可能）。因此需要思考何時、何種方式來開啟容錯模式。

有如下思路可供選擇——

• 用戶自主擇機啟用

最簡單的辦法就是讓業務用戶自主擇機選擇啟用或者關閉容錯模式。通常情況下，有經驗的用戶知道哪些查詢可能是計算量大或者運行時間久的查詢。他們可以通過改變JDBC連接的session參數來實現在“互動式模式”和“容錯模式”之間靈活切換；

• 基於代價決策

可以基於SQL執行的預測代價來決定是否開啟“容錯模式”。一般來說，這個技術需要依賴實現統計獲得的列級別統計信息。然而，列級別統計信息有時候是不可用的，而且基於代價估算的預測精度往往不夠理想；

• 自適應選擇技術

預設情況下，查詢可以“互動式模式”啟動，然後在運行N分鐘後，經過一段時間學習後，由引擎內核根據可用資源情況、業務特點等維度信息，自主決策啟動或關閉“容錯模式”。這個思路需要將Trino引擎與機器學習、AI技術結合起來，踐行數智融合路線；

• 基於歷史信息決策

針對特定數據源的某些類型的查詢，可以預先收集歷史運行記錄併進行分析建模。基於事先學習掌握的先驗知識模型，在SQL執行前選擇最優的執行模式。

9.2 水平擴展規模應用

Trino具備了容錯執行模式，測試數據顯示效果不錯，那麼接下來大家就會思考：是否可以基於該能力提供更大規模的分析查詢加速服務呢？

實際業務場景中，企業可能需要按需進行任務提交與彈性資源調度，尤其是在大規模、雲原生環境中，即使開啟容錯模式，對於單個Trino集群，其協調節點（Coordinator）依然可能存在併發能力的瓶頸。此外，從軟體架構角度看，單一Trino集群的可用性也存在一定的風險，影響雲服務環境下的SLA目標達成。

針對上述問題，華為雲互動式分析引擎HetuEngine提供了三層分散式架構，通過統一的SQL訪問入口——HSFabric來向業務提供全局唯一的JDBC服務地址。

通過HSFabric統一SQL訪問入口，HetuEngine實現了將業務層邏輯與某個特定的計算實例解耦，單個資源租戶內部可以橫向擴展多個計算實例，同一個租戶內部的SQL任務可以在不同計算實例間靈活分配。

無論從多租戶還是單一租戶角度看，HetuEngine的併發容量可水平擴展，同時也提升了服務可用性和資源利用率。

基於上述架構，HetuEngine支持服務管理員自由決定是否開啟/關閉單個租戶的容錯執行模式，以便更好的滿足不同場景的業務訴求。

9.3 故障處理與恢復

在Trino容錯執行過程中，Stage間的Shuffle數據會大量落入到分散式文件系統上。這裡以HDFS為例進行討論可能存在問題。

假設——1個大SQL在執行過程中，Trino正在往HDFS上寫shuffle數據，突然Trino所在物理機節點發生意外（比如，停電、斷網、操作系統崩潰等），或者Trino本身出現故障停止工作（比如，過載等）。這可能會導致整個Trino集群都徹底停止工作。此時，需要管理員人工介入才能重新恢復Trino集群的正常工作狀態。

顯而易見，對Trino來說，至少存在2個問題需要思考和解決：

• 如何實現Trino集群的應急快速恢復
• 確保HDFS上的殘留文件及時被清理，避免存儲空間耗盡

華為雲互動式分析引擎HetuEngine基於三層服務化+容器化架構，可有效應對上述挑戰：

針對問題1：

藉助於全容器化的部署架構，HetuEngine的任一計算實例（對應於1個分散式Trino集群）中的任一軟體進程在發生故障/意外時，均可由Service層快速自動拉起新的容器進程來接管和補齊服務缺失，在人工介入前快速完成故障自愈。

在可用資源可能存在不足時，HetuEngine支持計算實例線上彈性伸縮，通過自動調整Worker數量來動態平衡資源利用率，快速補充因故障而丟失的Worker節點資源。

在Coordinator節點發生故障時，HetuEngine從三方面入手進行應對——

1. 同一計算實例中的Worker節點立即與備Coordinator進行組網；
2. 備Coordinator升為新的主Coordinator；
3. 統一SQL入口立即將新的SQL請求引流到新的主Coordinator

針對問題2：

HetuEngine的Service層全天24小時不間斷監控，跟蹤並及時發現、清理各層級作業殘留（包括：數據、文件、目錄、元數據等）。

同時針對歷史任務進行多維度地深入洞察，生成高價值SQL運維圖表和決策推薦信息，最終呈現在控制台頁面。

Service層提供的全方位貼心服務，極大降低了對數據分析平臺管理員的專業知識要求，解決管理員對於長期運營的後顧之憂。

9.4 大數據平臺業務無損的彈性擴縮容

通常來說，大數據平臺的彈性伸縮方案只會涵蓋Hive、Spark這類批處理引擎。因Hive、Spark本身具備了容錯執行能力，即使因為大數據平臺的管控面下髮指令強制縮容一個正在運行Hive/Spark作業的物理節點，也不會影響相關作業的最終執行成功，最多只是引發了局部task的重試，增加了執行時長。因此，面向Hive、Spark引擎的大數據平臺彈性伸縮方案相對來說比較容易，只需要關註資源層面的管理操作即可。

但對Trino這類MPP架構引擎來說，上述大數據平臺的彈性伸縮管理模式就可能會面臨如下幾個方面的挑戰：

• MPP架構的SQL引擎一般都是常駐形態，在縮容過程中任何一個節點被強殺都可能導致該節點上正在運行中的SQL任務失敗；
• Trino的協調節點Coordinator預設為1個，在縮容過程中，強殺Coordinator所在的節點會導致整個Trino集群不可用，運行中的所有SQL任務失敗；
• Trino集群的擴容，需要平臺管理面深入理解Trino集群的內部服務發現與工作機制，針對具體集群的IP和埠號定製配置，才能順利的將新節點加入到一個已經存在的Trino集群中。

綜上，要想在大數據平臺服務上實現對Trino生態引擎的彈性伸縮，且做到業務無損，需要在大數據平臺服務層和Trino內核層之間抽象出一個面向多資源租戶+多個計算實例（Trino集群）的資源管理&業務接入service層。

HetuEngine的service層對大數據平臺服務層屏蔽底層Trino內核細節，對上提供Rest API調用，並將大數據平臺服務層的管理運維訴求轉換為對具體Trino集群的實際變更。同時要做到對多個Trino集群的日常狀態監控與自維護。

在上述架構基礎之上，可以基於Trino容錯執行的能力，在開啟彈性伸縮時，進一步降低大數據平臺層面彈性伸縮的等待時間。

一種可行的思路大致是——

大數據平臺服務層向HetuEngine的service層下發縮容指令，service確定即將被縮容的節點上正在運行的計算實例，並將其動態切換到容錯模式。在通常情況下，service層可以快速向上層服務層答覆縮容操作准備繼續，不用等待SQL任務執行完。

9.5 小結

基於上述架構與思路，華為雲HetuEngine能很好地應對容錯執行模式可能引入的新問題，顯著提升生產環境實際運維效率，助力用戶很方便地享受容錯執行的新紅利。

接下來， HetuEngine將逐步引入和完善在兩個不同執行模式間的智能切換能力，進一步完善對大數據云服務彈性伸縮的場景適配，在數據湖內一站式SQL分析領域持續創新、長期演進。

10 HetuEngine 2.0版本預告

預計2023年9月30日，HetuEngine 2.0將隨華為雲MRS 3.3.0-LTS正式發佈。在該版本中，可以看到一系列的新能力，例如——

• 基於Java17運行全新內核，基礎性能、穩定性再上一個新臺階，TPCDS提速30%
• 大SQL主動防禦：事前提示/攔截，事中熔斷，事後統計
• 支持容錯執行模式：適用範圍更廣泛，使能一站式SQL加工 & 分析
• 租戶內多計算實例架構：自動負載均衡、針對單個業務的併發能力可水平擴展
• 新增數據源類型：Hudi，MySQL
• 新增支持新建Hudi表、Insert數據
• 新增支持Hue對接HetuEngine，提供可視化SQL編輯頁面
• 新增支持代理用戶模式，支持對客戶的自有用戶體系的代理鑒權及審計

相關鏈接：https://support.huaweicloud.com/intl/zh-cn/cmpntguide-lts-mrs/mrs_01_1711.html

點擊關註，第一時間瞭解華為雲新鮮技術~