鑽石舞台

本次分享主要有以下幾個內容：

•Presto 在騰訊的使用狀況•可用性擴展•穩定性改善•性能優化•未來工作

Presto 在騰訊的使用狀況

可用性擴展

我們知道，原生的 Presto 配置 Catalog 是需要重啟集群的。而騰訊對這個進行了改造，使得 Presto 支持動態 Catalog 配置，動態 Catalog 信息是保存到 Catalog Store（猜想應該是元數據等服務）。對Catalog 的增刪操作都是發到 Coordinator，然後再由 Coordinator 同步到 Worker。

Presto 的 Iceberg 數據源的社區進行了一些功能提升，騰訊 Presto 團隊將一些有用的 Patch Merge 到自己分支。

穩定性改善

穩定性建設之一是 JVM 調優。主要包括 JDK 由8升級到11. -XX:GCLockerRetryAllocationCount 增加到 100。

騰訊 Presto 團隊弄了一個新的策略：在 Full GC 之後，如果 workers 還出現 OOM 的問題，就會 kill 掉 workers 上使用內存最多的查詢。

ORC 文件如果有很多 stripes 的話，很容易導致 Worker 出現 OOM，對於這個問題主要有以下兩個解決辦法：

將大的ORC 文件拆分成 stripe 比較合適的小文件，但是這個需要修改用戶的數據。

優化 Presto ORC Reader，不需要在不同的 splits 中讀取相同 ORC文件的重複 StripeStatistics。

其他擴展性提升：

對重要業務的不同類型工作負載使用獨立集群處理；

限制查詢的 split 數，避免大查詢以及處理許多小文件的查詢；

轉發到 Presto 的查詢失敗時會通過 SuperSQL 自動轉發到 Hive/Spark，這個操作對用戶是無感知的。

減少 hive.dfs-timeout 來避免從 HDFS DataNode 讀取數據時等待過長的時間。

性能優化

引入了 Presto on Alluxio，目前 Alluxio 節點和 Presto 是混部的，Presto Alluxio Local Cache 正在測試中。

對不同的數據源使用不同的路由策略。

當路由的時候，會檢查 Alluxio 集群的健康，如果 Alluxio 路徑不可訪問時自動使用 HDFS 路徑；

熱數據範圍是由用戶在白名單中指定的，其可以支持多個 Alluxio 集群；

第一次讀取數據時，把數據緩存到 Alluxio 中。數據的過期和 evict 都是自動的。

上面是 Presto on Alluxio 的性能測試，主要選取了8中類型的 SQL 進行了測試。（過往記憶大數據備註：性能提升看起來不明顯啊？）

目前，騰訊的 Presto 是部署在 K8S 上的。

支持通過節點的 CPU 和 內存的使用情況自動擴縮容。

對 distinct Count 查詢進行了重寫，將其轉換成 grouping sets，從而通過部分聚合消除數據傾斜。同樣場景下的用戶場景性能提升了2-3倍。

未來工作