一、集群架構(gòu)

1、B 站 SQL On Hadoop

下圖為 B 站 Presto 集群的架構(gòu)圖，最上層是內(nèi)部的一些數(shù)據(jù)服務(wù)，所有服務(wù)統(tǒng)一接入 Dispatcher。Dispatcher 是一套內(nèi)部自研的服務(wù)，根據(jù)查詢 HDFS 的數(shù)據(jù)量、目前引擎的負載情況等將用戶提交的 query 路由到相應(yīng)的引擎進行執(zhí)行。對于 presto 的查詢語法和 hive/spark 語法可能出現(xiàn)的不兼容問題，我們引進了 Linkedin 的開源軟件 Coral，將 hive 和 spark 的語法轉(zhuǎn)換為 presto 的語法進行執(zhí)行。

計算引擎的路由邏輯：對于查詢量比較小的 sql，會優(yōu)先路由到 presto 進行執(zhí)行，如果失敗則降級到 spark 進行執(zhí)行，再失敗則降級到 hive 進行執(zhí)行。

調(diào)度平臺（ETL）：用戶可以通過調(diào)度平臺編寫調(diào)度作業(yè)來執(zhí)行調(diào)度任務(wù)，具體是由 yarn 來調(diào)度。

Ranger：目前 HDFS 和 hive/presto/spark 都已經(jīng)接入到 Ranger 進行統(tǒng)一的權(quán)限控制。權(quán)限控制包括表字段級別的控制以及 column masking 和 row filter 的控制。

2、Presto 集群現(xiàn)狀

目前 Presto 包括了四套集群，分為兩個機房（IDC1 和 IDC2）。除了Cluster3 之外的集群都實現(xiàn)了跨機房功能，目前集群數(shù)最多的為 IDC2 的 Cluster1（441 為集群數(shù)量，2 為 coordinator 數(shù)量）。Presto 集群平均每月作業(yè)數(shù)量 500w，每日作業(yè)數(shù)約 16w～17w。平均每月讀 HDFS 數(shù)據(jù)量約 300PB，每日 10PB。

3、Presto 集群架構(gòu)

Presto 集群的架構(gòu)大致如下，用戶作業(yè)提交后，會先通過一個開源組件Presto-Gateway，將 sql 作業(yè)路由到對應(yīng)的 IDC 機房中相對應(yīng)的 presto 集群中的 coordinator 節(jié)點進行執(zhí)行。

二、Presto 簡介

1、Presto 歷史

Presto 是 2013 年 11 月份由 Facebook 開源的一個分布式 sql 查詢引擎，設(shè)計之初是為了進行 OLAP 數(shù)據(jù)查詢，支持標準的 ANSI SQL，也支持多數(shù)據(jù)源。在 2019 年 1 月時 Presto 內(nèi)部分裂出了兩個分支：PrestoSQL（trino）和 PrestoDB。PrestoSQL 相對于 PrestoDB 來說社區(qū)活躍度較高且更加注重 OLAP 的方向，而后者相對更注重 ETL 的方向。

2、Presto 基本原理

Presto 是一個典型的主從架構(gòu)，它由一臺 coordinator 和多個 worker 構(gòu)成，Presto worker 啟動時會在 coordinator 進行注冊。Presto 集群作業(yè)的執(zhí)行流程是：

1.coordinator 收到作業(yè)后通過 sql 解析器對作業(yè)進行解析生成語法樹， LogicPlanner 再對語法樹進行語義分析，將 AST 轉(zhuǎn)為邏輯執(zhí)行計劃，同時使用優(yōu)化器進行優(yōu)化。接著通過 DistributedPlanner 將計劃進行切分生成多個 stage，stage 內(nèi)部劃分為多個 task， 通過 scheduler 將多個 task 分發(fā)到不同的 worker 上執(zhí)行。由于Presto 本身不存儲數(shù)據(jù)，需要通過多個connector 來訪問不同數(shù)據(jù)源的數(shù)據(jù)。

三、Presto 改造

我們對 Presto 做的改造主要從可用性、穩(wěn)定性和性能提升三個角度出發(fā)。

Presto在B站的實踐：https://mp.weixin.qq.com/s/9_lSIFSw5o8sFC8foEtA7w 

1、可用性改進

① Presto 和 hive 語法之間兼容性的操作。

② Hive Ranger Plugin 的兼容。

在 Ranger 社區(qū)中，不同的引擎有不同的 policy 進行管理，我們使用了hive 的 policy 來統(tǒng)一進行管理。

2、穩(wěn)定性改進

① Coordinator 的多活改造。

Presto 的主從架構(gòu)存在單點故障的問題，也就是當 Coordinator 發(fā)生故障的時候會影響到整個集群的查詢。多活改造保證了當某一個 Coordinator 發(fā)生故障的時候，另一個 Coordinator 會繼續(xù)對外進行服務(wù)。此外，多活也可以減輕單臺 Coordinator 的作業(yè)壓力。

② label 改造。

由于多個部門同時使用 Presto 集群進行查詢，其中有一些部門對于作業(yè)的實時性要求比較高，有些部門會提交查詢數(shù)據(jù)量較大的 query 語句，這就會導(dǎo)致大 query 擠壓 Presto 的查詢性能，使實時性要求高的查詢無法完成。因此我們對 worker 進行了標簽的改造，同時在用戶提交任務(wù)時也給任務(wù)打上標簽，這樣 scheduler 在分發(fā)任務(wù)的時候就會根據(jù)任務(wù)標簽和 worker 標簽將任務(wù)分配到相應(yīng)的 worker 上去執(zhí)行。

③ 實時懲罰。

label 改造實現(xiàn)了不同部門之間 worker 資源的隔離，但對于同一個部門不同的業(yè)務(wù)還是會存在大 query 擠壓資源的現(xiàn)象。因此我們引進實時懲罰策略，對于提交的大語句判斷對應(yīng)的 resource group 并分配 CPU 的閾值。如果超過閾值，Presto worker 會進行 split 并下發(fā)懲罰信息暫停執(zhí)行，等整體 resource group 資源占用量低于閾值后再恢復(fù)調(diào)度。

④ 查詢限制。

在 presto Gateway 對 bad sql 進行攔截。包括短時間內(nèi)重復(fù)提交、查詢HDFS 數(shù)據(jù)量較大（超過 30TB）的查詢語句。

3、性能提升

性能提升主要圍繞 Presto 緩存來進行，緩存有三部分，分別為數(shù)據(jù)源/元數(shù)據(jù)/結(jié)果集的緩存。

四、Presto on Alluxio

前面幾章主要講解了我們內(nèi)部對 presto 的改造，接下來介紹 presto 對數(shù)據(jù)源和元數(shù)據(jù)的緩存。首先是對于 Alluxio 做緩存的介紹。

1、背景介紹 — Presto 痛點

① 計算存儲分離架構(gòu)帶來網(wǎng)絡(luò)開銷。

和傳統(tǒng)的 MySQL（存算一體）的數(shù)據(jù)庫不同，Presto 是一個存算分離的數(shù)據(jù)庫。Presto 本身只做計算不做存儲，它通過多個 connector 實現(xiàn)遠端獲取數(shù)據(jù)，也可以實現(xiàn)聯(lián)邦查詢。但從遠端獲取數(shù)據(jù)必然會帶來網(wǎng)絡(luò)上的性能開銷。

② 容易受慢 rpc (Remote Procedure Call) 或熱 dn 影響，查詢性能不穩(wěn)定。

我們 Presto 主要的場景是查詢 hive 表為主，需要去底層查詢 HDFS 的數(shù)據(jù)。由下圖可見，Presto 查詢 HDFS 時每隔一段時間就會有較長時間的慢 rpc 請求，進而導(dǎo)致 Presto 查詢性能的不穩(wěn)定。

③ 缺少 data locality，性能方面有待提升。

2、背景介紹 — 熱數(shù)據(jù)

上部分從引擎的角度介紹了 Presto 的一些痛點，此部分從業(yè)務(wù)數(shù)據(jù)的角度介紹為什么需要 Alluxio 做存儲。

下圖為對 Presto query 血源信息做的 UI 展示，我們發(fā)現(xiàn)有些表/分區(qū)存在重復(fù)訪問的情況，比如圖中第一張表的訪問熱度（tableheat）達到了 866。我們可以對經(jīng)常被訪問的表進行緩存，從而提升 presto 引擎的查詢性能。 

3、Alluxio 的引入

① 架構(gòu)變化。

架構(gòu)上的變化主要有兩個，一是對于血緣變化的處理，二是添加了 Alluxio worker。

• Alluxio worker

原先 Presto worker 直接從 HDFS 訪問數(shù)據(jù)， 現(xiàn)在則是先通過 Alluxio worker 獲取數(shù)據(jù)，如果 Alluxio 中沒有對應(yīng)數(shù)據(jù)再去最訪問 HDFS 獲取數(shù)據(jù)。

• 增加 Presto 血緣信息解析用于獲取熱數(shù)據(jù)

Presto Coordinator 對 sql 進行解析時，會將血緣信息吐到 Kafka 中，再通過消費程序?qū)⑾鄳?yīng)的血緣信息落到數(shù)據(jù)庫中，最后通過自研的血緣分析服務(wù)對熱數(shù)據(jù)打上標識。下一次 Coordinator 從 Hive Metastore 訪問分區(qū)時會判斷分區(qū)的參數(shù)是否有熱數(shù)據(jù)標識，如果有標識，接下來就會走 Alluxio 的邏輯。

4、Presto on Alluxio 的實現(xiàn)細節(jié)

① Alluxio 與 HDFS 的 scheme 不同。

當 Presto 去 Hive Metastore 查詢的時候，如果想要訪問 Alluxio 的數(shù)據(jù)時，比較簡單的做法是將 Hive Metastore 里相應(yīng)的 scheme 轉(zhuǎn)換為 Alluxio 的 scheme，但這會帶來的問題是對于其他的引擎（比如 spark），因為其本來就沒有接入 Alluxio，會導(dǎo)致查詢不可用。對于這個問題，社區(qū)的解決方案是在高版本 Presto 中支持 Alluxio 連接器。原先 Presto 需要通過訪問 Hive Metastore 去獲取表信息，現(xiàn)在只需要訪問 Alluxio 就可以獲取信息。Alluxio 內(nèi)的 SDS 模塊有和 Hive Metastore 的通信功能，SDS 模塊會在 Alluxio 中將相應(yīng)的邏輯進行封裝，再返還給 Presto 進行處理。

其他互聯(lián)網(wǎng)公司方案：維護一套新的 Hive Metastore 來用于 adhoc 的場景，并定期將新 HMS 和原先的 HMS 保持同步。同時依靠自己開發(fā)的白名單來確定哪些表是需要 Alluxio 緩存的。

由于：

• 維護一套新的 HMS 運維成本太高。
• 我們希望通過自己的方式來掌管需要把哪些表存到 Alluxio 中。

所以我們團隊沒有使用上述兩種方案，而是通過打 Tag 的方式來控制哪些表走 Alluxio。我們的解決方案：改造 hive connector。因為我們需要通過 hive connector 來獲取 HMS 中的 parameter 信息，再通過識別分區(qū)參數(shù)里面 Alluxio 的 tag 來判斷是否走 Alluxio 的邏輯并且通過代碼將 scheme 替換成 Alluxio 的 scheme。

② Alluxio 緩存數(shù)據(jù)的確定。

• 熱數(shù)據(jù) tag 設(shè)置

由于 Alluxio 緩存空間的有限性，沒有必要將所有數(shù)據(jù)進行緩存，因此我們會對熱數(shù)據(jù)打上標識，只把熱數(shù)據(jù)存儲到 Alluxio 上。首先，在 Presto 端把 Presto query 血緣信息吐到 Kafka上，再通過 Kafka 消費程序分析血緣信息并落到 Tidb 上。血緣信息主要包括 query 語句，涉及到的 queryid 以及查詢表和分區(qū)。接下來通過緩存策略服務(wù)判斷數(shù)據(jù)熱度，并對熱度高的數(shù)據(jù)打上 tag。

• 緩存策略

訪問熱度判斷：計算表一周平均訪問次數(shù)，再根據(jù)全量表一周內(nèi)的被訪問頻率確定劃分閾值，高于閾值的為熱表。

計算 TTL（離當前最遠的熱分區(qū)的時間跨度）數(shù)據(jù)：使用滑動窗口的方式實現(xiàn)對離當前時間點最近的熱分區(qū)的時間跨度計算，在 Alluxio 中剔除超過最遠時間點熱度分區(qū)并將最近 logdate 的分區(qū)添加進緩存中。

③ 數(shù)據(jù)一致性保證。

當?shù)讓?HDFS 數(shù)據(jù)發(fā)生變更的時候，Alluxio 中便可能出現(xiàn)緩存了舊數(shù)據(jù)和臟數(shù)據(jù)的情況。針對這一問題，社區(qū)普遍的解決方案是通過配置參數(shù)達到和 HDFS 的元數(shù)據(jù)同步。但我們實踐過程中由于存在慢 rpc 的情況，所以無法使用社區(qū)的解決方案。為此我們自己開發(fā)了一套緩存失效服務(wù)來監(jiān)聽 Hive Meta Event，當監(jiān)聽到 alter partition  或者 drop partition 的事件時，服務(wù)會自動剔除 Alluxio 中存在的相應(yīng)分區(qū)。同時，我們也會監(jiān)聽 add partition事件。當 add partition 事件并且表的熱度較高時，我們也會將相應(yīng)分區(qū)緩存入 Alluxio。下面是 Presto on Alluxio 和 Presto on HDFS 的性能對比，查詢 Alluxio 對比查詢 HDFS 大概可以節(jié)省 20% 的查詢時間。

④ Presto on Alluxio 線上效果。

目前大約 30% 的 BI 業(yè)務(wù)已接入到 Alluxio 的緩存中，已緩存 20w 分區(qū)（約45TB）。改造后 Presto 讀 HDFS 的穩(wěn)定性有大幅提升，基本控制在 2.5ms 以內(nèi)。

⑤ Presto on Alluxio 線上故障。

問題：RocksDB 做元數(shù)據(jù)存儲的時候，線上 Master 進程偶發(fā) crash。

主要背景：Alluxio 原本是放在容器中的，Alluxio 主進程突然發(fā)生 crash，拉起 Alluxio 容器后出現(xiàn)了日志丟失的問題。

為了排查 crash 原因，我們將 Alluxio 部署到物理機上，在物理機上通過添加一些 JVM 的參數(shù)，等待問題的再次發(fā)生。

下圖為 JVM 崩潰時打印出來的錯誤日志，整個異常棧的調(diào)用過程為 client 端向 Alluxio 發(fā)請求獲取文件狀態(tài)時，會通過 Rocksdb getlocation，再通過 blockid 獲得其對應(yīng)的信息。在操作的過程中，rocks object 對象發(fā)生了 GC 被 JVM 回收了，但 rockesdb 是 c++ 的 jni 里面還有該引用，所以會產(chǎn)生 segment fault, 內(nèi)存地址越界，最后導(dǎo)致了 JVM 的崩潰。此問題已經(jīng)在社區(qū)中有了相應(yīng)的修復(fù)。具體可見以下鏈接：

https://github.com/Alluxio/alluxio/pull/14856

https://groups.google.com/g/rocksdb/c/PwapmWw 

五、Presto on Local Cache

1、RaptorX 背景

由于 Presto 在執(zhí)行計劃階段需要訪問 HMS 獲取表和分區(qū)的信息，而HMS 的響應(yīng)受單點 mysql 的吞吐影響，存在慢查詢。

Presto 在構(gòu)建 split 以及讀數(shù)據(jù)的情況下需要訪問 HDFS。HDFS 作為底層存儲對接了許多計算引擎，如 Hive、spark 等，在 RPC 請求穩(wěn)定性方面經(jīng)常存在 slow rpc，在讀 datanode 數(shù)據(jù)時，存在 slow dn。因此 RaptorX 應(yīng)運而生，它通過對元數(shù)據(jù)與數(shù)據(jù)源進行全方面緩存來解決上述問題。

圖：presto 執(zhí)行階段

2、RaptorX 功能介紹

• Hive Meta Cache

在 Presto 端的 Coordinator 側(cè)對 hive 端的 meta 信息做了緩存，但是考慮到元數(shù)據(jù)會出現(xiàn)變更，于是我們添加了版本號。每次請求元數(shù)據(jù)時，我們會將版本號和 HMS 中的版本號做匹配，判斷緩存的是否是一個新的 hive meta 數(shù)據(jù)。

• File List Cache

在 Presto 的 coordinator 側(cè)對 HDFS 的元數(shù)據(jù)做一些緩存，避免長時間的 list status 操作。

• Fragment Result Cache

在 Presto worker 節(jié)點對部分查詢結(jié)果做緩存，避免重復(fù)計算。

• Orc/Parquet Footer Cache

對 orc 或者 parquet 格式的文件的 foote r做緩存，提升 presto 查詢的性能。

• Alluxio Data Cache
• Soft Affinity scheduling

Raptorx 相關(guān)文章：??https://prestodb.io/blog/2021/02/04/raptorx、??

3、Presto Local Cache-Alluxio Local 模式

在 local 模式中，我們把 Alluxio 通過架構(gòu)的形式嵌入到 Presto worker的進程中，對 Presto 集群進行統(tǒng)一的管理。這種模式相對于 Presto on Alluxio 來說更加輕量以及便于維護。

4、Presto Local Cache-Soft Affinity scheduling

搭配 Alluxio Data Cache 使用，它可以使同一個 split 盡可能分發(fā)到同一個 worker 節(jié)點，保證緩存的命中率。

實現(xiàn)方式有兩種，第一種是基于 Hash & Mod，第二種是基于一致性 Hash。

Hash & Mod 是通過 Hash 計算，把 split 分發(fā)到對應(yīng)的 worker 節(jié)點。它的缺陷是當 worker 節(jié)點數(shù)發(fā)生變動時（如故障等），總的 worker 節(jié)點數(shù)就會發(fā)生變化，會導(dǎo)致 split 重新分發(fā)到別的 worker 節(jié)點。

一致性 hash 就是為了解決這個問題而提出的，其基本思路是通過一個哈希環(huán)（0-max（value）），首先將 Presto worker 給 Hash 到這個哈希環(huán)上，然后再將 split 哈希到環(huán)上。在選定方向后，在環(huán)上離 split 最近的一個 worker 會對 split 進行處理。這么做的好處是當  Presto worker 發(fā)生故障的時候，只有原先分發(fā)到這個 worker 的 split 才會重新分發(fā)到別的節(jié)點處進行執(zhí)行，此外還有一點優(yōu)化，單臺 worker 可能會出現(xiàn)負載較高的情況，因此我們對一致性 Hash 提出了虛擬節(jié)點的概念。比如將一臺 worker 映射到三臺 worker 分配到哈希環(huán)上，再重新進行 split 的分發(fā)，這樣可以做到 split 更加均勻的分發(fā)到不同的 worker 節(jié)點上。

5、Presto Local Cache – Alluxio Cluster

6、Presto Local Cache – Local vs Cluster

接下來我們看 presto on local cache 和 presto on alluxio cluster 的區(qū)別。

Local 是以 jar 包的形式嵌入到 presto 的進程中，cluster 則是需要維護一套 Alluxio 集群，因此 cluster 的運維成本更高。

第二點是緩存的粒度不同，local 緩存粒度更加細，做到了 page 級別的緩存，cluster 是做文件級別的緩存。

第三點是 local 離計算節(jié)點資源更近，而 cluster 需要額外的計算機器資源來部署 Alluxio 集群。

7、Presto Local Cache – 改造點

• Local cache 與底層數(shù)據(jù)一致性（presto 端改造）

當?shù)讓?hdfs 文件發(fā)生變動時，Alluxio 中緩存的可能是舊的數(shù)據(jù)。這時候Presto 引擎查詢時，返回的可能是不準確的臟數(shù)據(jù)。改造的思路是基于文件的 LastModifiedTime（最后更改時間）來判斷，對 Presto 來說最初是獲取 HDFS 的元數(shù)據(jù)文件時同時獲取，然后將相應(yīng)的信息封裝到 split 中，Presto 通過 scheduler 將相應(yīng)的 split 調(diào)度到 Presto worker 節(jié)點，在節(jié)點處將相關(guān)的信息封裝到HiveFileContext 中。在具體構(gòu)建 pagesource 時，將 HiveFileContext 傳到本地文件系統(tǒng)中。核心方法是openFile，它不同于傳統(tǒng)方法直接傳一個 path 路徑，openFile 方法是傳一個 HiveFileContext，因此它不是一個標準的 hadoop api。openFile 會通過 HiveFileContext 來判斷是否走 Alluxio。

HiveFileContext 的核心參數(shù)有：

（1）cacheable：搭配前文提到的 soft affinixity scheduling 使用，當一臺worker 的負載達到上限，不得不調(diào)度到其他 worker 進行執(zhí)行時，由于這臺 worker 只是臨時支援的，我們會將 cacheable 置 false。

（2）ModificationTime：用于在 Alluxio 中判斷緩存的是否是新的數(shù)據(jù)。

• Local cache 與底層數(shù)據(jù)一致性（Alluxio 端改造）

Alluxio 端改造：

（1）當 presto 去底層讀取數(shù)據(jù)時，通過 localcache.manage.get 得到對應(yīng)的 page，這時我們需要通過比較文件的 LastModifiedTime 和 Alluxio 內(nèi)存文件中的 LastModifiedTime 來判斷文件是否一致。

（2）構(gòu)建內(nèi)存數(shù)據(jù)結(jié)構(gòu)來保存文件以及時間信息

（3）持久化信息（可用于在 restore 中恢復(fù)）

（4）修改 disk 的存儲路徑以及結(jié)構(gòu)

8、Presto Local Cache – Local Cache 啟動問題

（1）Local Cache restore 時間點

Local cache 會去指定的 path 路徑加載 page，當 page 較多時就會出現(xiàn)加載耗時高的情況。如下圖所示，get file system 時，我們會在 AlluxioCachingFileSystem 創(chuàng)建 local cache，再對 localcache 進行異步加載。但對于 Presto worker 來說，它第一次 get file system 是在 get split 的時候。這種時候可能 local cache 還沒有異步加載完畢，此時便會導(dǎo)致緩存命中率的下降。對此進行的改造是：在 Presto worker 啟動時，構(gòu)建一個空路徑，通過空路徑構(gòu)建一個 getfilesystem，同步對 local file 進行加載，然后再對外提供服務(wù)。

（2）Local Cache  加載失敗

local cache 主要是寫在 SSD 盤上，可能會遇到磁盤損壞，或者我們先添加一個新 path 路徑用于存儲 page。但我們新添加的 path 路徑對應(yīng)的 SSD 可能存在磁盤容量身偏高的場景，于是我們設(shè)置了一個 local cache 的開關(guān)，在以上情況發(fā)生時會將 local cache 的開關(guān)關(guān)閉。

9、Presto Local Cache – Local Cache 支持 HDFS 文件系統(tǒng)

社區(qū)對 local cache 實現(xiàn)的 scheme 要求為 Alluxio 和 ws 的 scheme，但我們的線上生產(chǎn)環(huán)境主要數(shù)據(jù)還是以 HDFS 為主，以 Alluxio 為輔。因此我們對 Alluxio 代碼做了一些改造，使其能夠支持 hdfs 和 viewfs 的scheme。

10、Presto Local Cache — Local Cache 支持多磁盤

背景：單磁盤空間不足且 io 存在限制。

社區(qū)解決方法：通過 Hash&Mod 寫入多磁盤，這種方法的缺陷是沒有考慮到每個磁盤本身容量的情況。

我們的改造：借鑒 HDFS，基于 AvailableSpace 來做磁盤選擇?；舅悸肥菍Χ鄩K磁盤給到一個閾值，超過這個閾值的就認為是容量比較高的，將其放到一個高容量的 list 中，反之亦然。然后給一個概率值，比如 0.75 的概率寫到高容量磁盤，0.25 的概率寫到低容量磁盤。為什么不直接把數(shù)據(jù)優(yōu)先寫入高容量磁盤呢，原因有二：

（1）磁盤容量只是其中一個考量因素，不能單純根據(jù)容量高就優(yōu)先寫；

（2）假設(shè)線上把所有 page 都寫入磁盤容量比較高的盤里面，會造成這個盤的 io 壓力過大的情況。

11、Presto Local Cache – Local Cache 測試效果

單并發(fā)場景下開啟 local cache 緩存可以減少 20% 左右的查詢時間，大大提升了查詢效率。四并發(fā)場景下測試查詢時間有一定提升，但相比單并發(fā)場景下，性能有一定的損失。

12、Presto Local Cache — Local Cache 線上效果

目前上線了 3 個 presto 集群，緩存命中率約 40%。

13、Presto Local Cache — 社區(qū) PR 

• Get raw filesystem should consider CachingFileSystem

(https://github.com/prestodb/presto/pull/17390, Merged) 

• Wrapper the input and output stream of HadoopExtendedFileSystem

(https://github.com/prestodb/presto/pull/17365, Merged) 

• Adapt disable filesystem cache

(https://github.com/prestodb/presto/pull/17367, Open) 

• Support hdfs and viewfs as the external filesystem

(https://github.com/Alluxio/alluxio/pull/15131, Closed) 

• Support timely invalidation of parquet metadata cache

(https://github.com/prestodb/presto/pull/17500, Merged) 

六、后續(xù)工作

1、推廣 local 模式上線多個集群

相對于 Presto on Alluxio, local cache 更加穩(wěn)定也更加輕量。于是我們后續(xù)將繼續(xù)推廣 Local 模式。

2、開發(fā)支持 textFile 格式的緩存

社區(qū)實現(xiàn)只支持 orc、parquet、rcFile，但線上有很多表用的是 textFile 的格式，所以我們需要開發(fā) textFile 的緩存。

3、開發(fā)磁盤檢測 

線上的一些 Presto 節(jié)點會存在慢節(jié)點的情況，需要對有問題的節(jié)點進行隔離。

4、改進 Soft-Affinity 

原先 soft affinity 會將同一個文件的 split 分發(fā)到同一個節(jié)點，會造成單臺worker 節(jié)點壓力比較大的情況，后續(xù)計劃使用 path+start 作為 key 來哈希，分散大文件分到單個 worker split 的壓力。

5、改進 soft-affinity 排除不開啟 cache 的節(jié)點 

對于沒有 local cache 的 presto worker 進行排除。

七、問答環(huán)節(jié)

Q1：presto 跨機房是如何實現(xiàn)的？

A1：由于業(yè)務(wù)發(fā)展，原本在一個 idc 機房的機位已經(jīng)達到上限，需要開辟新的機房來存儲數(shù)據(jù)。在新機房部署 Hadoop 和 Presto 集群，大家比較容易想到的跨機房難點是資源緊張，因此我們設(shè)計了一套 Presto 跨機房的功能。內(nèi)部是通過用戶作業(yè)提交到 Presto Getaway，再由 Presto Getaway 分發(fā)到不同集群，對 Presto Getaway 進行改造：

1. 分析 sql 語句，看是查詢了哪些表和分區(qū)，然后對 nnproxy 做了改造，看這些表和分區(qū)在哪個機房下，數(shù)據(jù)量有多少，然后 Presto Getaway 會根據(jù)以上信息判斷這條 sql 語句會路由到哪個集群執(zhí)行。比如如果用戶提交來的 query 涉及到很多個表，首先對涉及到的表進行分析，最后調(diào)度到占數(shù)據(jù)量最大的機房執(zhí)行。

2. 此外還有一些優(yōu)化工作。我們知道有個概念叫做移動數(shù)據(jù)不如移動計算，原先通過 hive connector 去訪問數(shù)據(jù)的話會出現(xiàn)帶寬資源比較緊張的現(xiàn)象，因此我們做了一個計算的下推。主要是實現(xiàn)了一個叫 IDC connector 的連接器。我們可以將第二個機房看作是一個 connector，將跨機房的相應(yīng)邏輯拋到第二個機房的 presto coordinator 進行處理。IDC2 的 Presto coordinator 獲取底層 HDFS 的數(shù)據(jù)并處理完成后會將結(jié)果返還給第一個機房做一個結(jié)果合并。此外我們還使用了 Alluxio 來緩存跨機房的數(shù)據(jù)，比如我們的 query 語句被推到 IDC1 機房進行執(zhí)行，但很多數(shù)據(jù)需要通過 IDC2 獲取，這時 Alluxio 可以將熱度較高的數(shù)據(jù)跨機房進行緩存，下次就只需要通過 Alluxio 來進行跨機房數(shù)據(jù)的獲取。這兩個方法的好處都是可以減少跨機房的流量壓力。

Q2：Local Cache 需要部署集群服務(wù)嗎？

A2：不需要。對于 Alluxio 集群模式需要單獨部署 Alluxio 集群，然后 presto 訪問 Alluxio 集群。但如果使用 presto local cache 則不需要部署 alluxio 集群，Alluxio 是通過 jar 包的形式嵌入 presto 的進程中，它跟原先的 presto cluster 是共用同一套 presto 集群的，因此相對于 presto on alluxio 來說它會更加的輕量級。

Q3：怎么統(tǒng)計緩存命中率？

A3：社區(qū)實現(xiàn)主要是對 worker 端的 metrics進行統(tǒng)計，單臺 worker 在生產(chǎn)環(huán)境中的命中率達到了 90% 以上。我們自己更加關(guān)注 coordinator 端的命中率。前面有提到 hive connector 讀取 HMS 中 split 的信息時會帶上參數(shù)來判斷是否走 Alluxio，我們會統(tǒng)計 query 走 Alluxio 的次數(shù)，除以整個 presto 集群 query 的次數(shù)來得到緩存命中率。目前線上的緩存命中率基本可以達到 40% 左右。

Q4：怎么解決 local cache 的高并發(fā)性能問題？

A4：在我們的實驗環(huán)境中。四并發(fā)查詢的響應(yīng)時間明顯不如單并發(fā)，原因可能是因為數(shù)據(jù)存在 SSD 盤上，在多次讀數(shù)據(jù)的時候存在磁盤 io 的限制。

Q5：local cache 的內(nèi)存占用大概是多少？

A5：我們發(fā)現(xiàn)存相同大小的文件，local cache 的內(nèi)存占用相對較低。這是因為 cluster 是基于文件級別存儲的，并且當別的 Alluxio worker 參加執(zhí)行時，別的 worker 也會緩存對應(yīng)文件。對 local cache 來說，首先是緩存粒度更細（基于 page），只會精準緩存某些 page。另外是 soft affinity scheduling 的策略，它會盡可能將文件對應(yīng)的 split 分發(fā)到 worker 執(zhí)行。就算遇到單 worker 負載高，分發(fā)到其他的 worker 上進行執(zhí)行的情況時，我們也會通過把 cacheable 參數(shù)置 false，讓臨時 worker 不緩存文件。