一、集群架構

1、B 站 SQL On Hadoop

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

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

調度平臺（ETL）：用戶可以通過調度平臺編寫調度作業來執行調度任務，具體是由 yarn 來調度。

Ranger：目前 HDFS 和 hive/presto/spark 都已經接入到 Ranger 進行統一的權限控制。權限控制包括表字段級別的控制以及 column masking 和 row filter 的控制。

2、Presto 集群現狀

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

3、Presto 集群架構

Presto 集群的架構大致如下，用戶作業提交后，會先通過一個開源組件Presto-Gateway，將 sql 作業路由到對應的 IDC 機房中相對應的 presto 集群中的 coordinator 節點進行執行。

二、Presto 簡介

1、Presto 歷史

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

2、Presto 基本原理

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

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

三、Presto 改造

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

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

1、可用性改進

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

② Hive Ranger Plugin 的兼容。

在 Ranger 社區中，不同的引擎有不同的 policy 進行管理，我們使用了hive 的 policy 來統一進行管理。

2、穩定性改進

① Coordinator 的多活改造。

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

② label 改造。

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

③ 實時懲罰。

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

④ 查詢限制。

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

3、性能提升

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

四、Presto on Alluxio

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

1、背景介紹 — Presto 痛點

① 計算存儲分離架構帶來網絡開銷。

和傳統的 MySQL（存算一體）的數據庫不同，Presto 是一個存算分離的數據庫。Presto 本身只做計算不做存儲，它通過多個 connector 實現遠端獲取數據，也可以實現聯邦查詢。但從遠端獲取數據必然會帶來網絡上的性能開銷。

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

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

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

2、背景介紹 — 熱數據

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

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

3、Alluxio 的引入

① 架構變化。

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

• Alluxio worker

原先 Presto worker 直接從 HDFS 訪問數據， 現在則是先通過 Alluxio worker 獲取數據，如果 Alluxio 中沒有對應數據再去最訪問 HDFS 獲取數據。

• 增加 Presto 血緣信息解析用于獲取熱數據

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

4、Presto on Alluxio 的實現細節

① Alluxio 與 HDFS 的 scheme 不同。

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

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

由于：

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

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

② Alluxio 緩存數據的確定。

• 熱數據 tag 設置

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

• 緩存策略

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

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

③ 數據一致性保證。

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

④ Presto on Alluxio 線上效果。

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

⑤ Presto on Alluxio 線上故障。

問題：RocksDB 做元數據存儲的時候，線上 Master 進程偶發 crash。

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

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

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

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

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

五、Presto on Local Cache

1、RaptorX 背景

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

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

圖：presto 執行階段

2、RaptorX 功能介紹

• Hive Meta Cache

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

• File List Cache

在 Presto 的 coordinator 側對 HDFS 的元數據做一些緩存，避免長時間的 list status 操作。

• Fragment Result Cache

在 Presto worker 節點對部分查詢結果做緩存，避免重復計算。

• Orc/Parquet Footer Cache

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

• Alluxio Data Cache
• Soft Affinity scheduling

Raptorx 相關文章：??https://prestodb.io/blog/2021/02/04/raptorx、??

3、Presto Local Cache-Alluxio Local 模式

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

4、Presto Local Cache-Soft Affinity scheduling

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

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

Hash & Mod 是通過 Hash 計算，把 split 分發到對應的 worker 節點。它的缺陷是當 worker 節點數發生變動時（如故障等），總的 worker 節點數就會發生變化，會導致 split 重新分發到別的 worker 節點。

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

5、Presto Local Cache – Alluxio Cluster

6、Presto Local Cache – Local vs Cluster

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

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

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

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

7、Presto Local Cache – 改造點

• Local cache 與底層數據一致性（presto 端改造）

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

HiveFileContext 的核心參數有：

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

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

• Local cache 與底層數據一致性（Alluxio 端改造）

Alluxio 端改造：

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

（2）構建內存數據結構來保存文件以及時間信息

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

（4）修改 disk 的存儲路徑以及結構

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

（1）Local Cache restore 時間點

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

（2）Local Cache  加載失敗

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

9、Presto Local Cache – Local Cache 支持 HDFS 文件系統

社區對 local cache 實現的 scheme 要求為 Alluxio 和 ws 的 scheme，但我們的線上生產環境主要數據還是以 HDFS 為主，以 Alluxio 為輔。因此我們對 Alluxio 代碼做了一些改造，使其能夠支持 hdfs 和 viewfs 的scheme。

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

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

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

我們的改造：借鑒 HDFS，基于 AvailableSpace 來做磁盤選擇。基本思路是對多塊磁盤給到一個閾值，超過這個閾值的就認為是容量比較高的，將其放到一個高容量的 list 中，反之亦然。然后給一個概率值，比如 0.75 的概率寫到高容量磁盤，0.25 的概率寫到低容量磁盤。為什么不直接把數據優先寫入高容量磁盤呢，原因有二：

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

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

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

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

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

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

13、Presto Local Cache — 社區 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) 

六、后續工作

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

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

2、開發支持 textFile 格式的緩存

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

3、開發磁盤檢測 

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

4、改進 Soft-Affinity 

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

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

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

七、問答環節

Q1：presto 跨機房是如何實現的？

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

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

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

Q2：Local Cache 需要部署集群服務嗎？

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

Q3：怎么統計緩存命中率？

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

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

A4：在我們的實驗環境中。四并發查詢的響應時間明顯不如單并發，原因可能是因為數據存在 SSD 盤上，在多次讀數據的時候存在磁盤 io 的限制。

Q5：local cache 的內存占用大概是多少？

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