一套具適應性的分散式 SQL 引擎，同時支撐次秒級儀表板與長達數小時的 ETL，並可插接數十種資料來源。
Presto 是 Facebook 打造的開源分散式 SQL 查詢引擎，目的是取代組織為了不同類型分析而被迫並存的多套互不相容的類 SQL 系統。單一 coordinator 負責解析、規劃與查詢最佳化，再把 stage 化為 task 派送到 worker；worker 共用一個長生命週期的 JVM，以管線化的 in-memory driver loop 在欄式 page 上處理資料。SQL 之下的一切都藏在 Connector API 後面，這個介面分成 Metadata、Data Location、Data Source 與 Data Sink 四部分，因此同一套引擎可以讀 Hive 資料倉儲、分片 MySQL、Raptor 快閃儲存、鍵值系統與 Kafka，甚至在同一個查詢裡同時讀。Presto 刻意不用大量設定參數，而是選擇適應性：延遲式 split 指派、以 HTTP long-polling 實作並具端到端 backpressure 的 shuffle、CPU 的 multi-level feedback queue、可超額配置的記憶體 pool、動態寫入並行度，以及對 dictionary 編碼區塊的推測式處理。論文指出，這一套引擎既服務 50ms 的廣告主儀表板，也跑五小時的 ETL，每天處理數百 PB 資料與數千兆（quadrillion）列。
2013 年前後，Facebook 的分析工作跑在 Hive 上：類 SQL 查詢被編譯成 MapReduce 或 Tez 工作，stage 之間的中間結果落到檔案系統。這種設計換來了容錯，卻讓再簡單的查詢也以「分鐘」為時間下限，互動式探索、BI 工具與面向使用者的儀表板在資料倉儲上等於不可行。另一條路是 Vertica、Teradata、Redshift 或 Exadata 這類 MPP 資料倉儲，但它們只有在資料被載入自家儲存後才有巔峰效能，代價是搬運數 PB 資料並維護第二份真實來源。Spark SQL 與 Impala 縮短了差距，但前者仍缺乏端到端管線化，後者則侷限在 Hadoop 生態系內。實務結果是：同一個組織按延遲級距養了好幾套互不相容的類 SQL 系統，使用者還得自己判斷該把查詢丟給哪一套。
論文以 Facebook 的四個生產使用情境來鋪陳 Presto：Interactive Analytics、Batch ETL、A/B Testing 與 Developer/Advertiser Analytics，它們幾乎在每個面向上都不同。Interactive Analytics 在約 50GB 到 3TB 的壓縮資料上跑 50 至 100 個並行探索式查詢，使用者盯著時鐘等；Batch ETL 願意犧牲延遲換取資源效率與叢集吞吐量；A/B Testing 需要即時算出完整且正確的結果，並在 5 到 30 秒內讓使用者任意切片；Developer/Advertiser Analytics 則要求 50ms 到 5 秒的回應與 99.999% 可用性。論文主張的不是同一組設定能服務四者，而是同一份程式碼、同一種 SQL 方言與同一套 Connector API 能被組態成這四種樣貌。這正是「查詢引擎」與「產品家族」的分水嶺。
Presto 沒有把外部系統當成退而求其次的路徑，而是把每個資料來源都放在一個插件介面之後，並將它拆成 Metadata API、Data Location API、Data Source API 與 Data Sink API。這樣拆分之所以重要，是因為它把最佳化器在規劃期需要的東西（schema、統計資訊、實體 layout、分割、排序、索引）與 worker 在執行期需要的東西（要讀的 split、要回傳的 page、要寫入的 sink）分了開來。由於 connector 回報的是 layout 而不只是資料列，最佳化器才能把述詞下推到分片 MySQL、對生產環境的鍵值儲存選用 index nested-loop join，或在 join 兩側已依 join 鍵分割時直接消掉一次 shuffle。主儲存庫已有十多個社群貢獻的 connector，而通用的 Thrift RPC connector 讓「替專有服務加上 SQL 介面」簡化成實作約半打 RPC 端點。
論文把這點明講成一條工程哲學：一個執行任意使用者自訂運算的多租戶引擎，必須適應的不只是不同的查詢特性，還有這些特性的各種組合，因此逐一為工作負載調參的做法根本擴展不了。具體而言，split 是延遲指派給佇列最短的 task，因此慢 split 與慢節點會自我修正；輸出緩衝區使用率會節流有效並行度；輸入緩衝區的監測決定 HTTP 請求並行度；當上游 stage 塞住時寫入並行度會自動增加；page processor 還會推測該處理整個 dictionary 還是只處理被引用到的索引。在端到端 backpressure 出現之前，少數幾個客戶端很慢的工作就能佔住數十 GB 緩衝記憶體，並拖垮同時執行的延遲敏感查詢。適應性正是讓單一叢集能承載沒人事先列舉過的查詢形狀的關鍵。
Presto 透過 in-memory 緩衝區以 HTTP long-polling 交換中間結果：產出端的 task 把輸出留在緩衝區，消費端輪詢，而每次回應中夾帶的 token 就隱含地確認了前一段資料，因此不需要額外的 ack 通道。stage 之間完全不落磁碟，資料一產生就往下游串流，這也是某些查詢形狀能在讀完全部輸入前就回傳結果的原因。這是 Presto 與 Hive、Spark SQL 最根本的分歧，而且是刻意的取捨：放棄物化 shuffle 天然提供的重試點，換取互動式與面向使用者場景所需的延遲。long-polling 尤其能在傳輸量很小時壓低回應時間，而儀表板查詢正是這種情況。
由於每個 worker 上多個查詢共用一個 JVM，Presto 自帶排程器，而不是仰賴作業系統或叢集管理器。CPU 採用協作式多工，每個 split 單次最多佔用執行緒一秒鐘的 quanta；task 則依累積 CPU 時間被歸入 multi-level feedback queue 的五個層級，因此便宜的查詢留在高層快速結束，昂貴的查詢逐步下沉。記憶體則區分為 user memory（使用者能從查詢與資料推理出來的用量）與 system memory（實作副產物，例如 shuffle 緩衝區），兩者各有每節點與全域上限。引擎刻意超額配置叢集記憶體，賭的是不會所有查詢在同一時刻於同一節點都用到上限，並以 spilling 與 reserved pool 作為這個賭注的後盾。
Presto 對運算式求值與整個運算子都產生 JVM bytecode，而有趣的論點在於：為什麼在這個平台上通用直譯必然失敗。因為引擎每個 quanta 就會在不相干 task 的 split 之間切換，共用的緊湊處理迴圈所收集到的 profiling 資訊會被其他查詢污染，JIT 因此永遠無法特化它。為每個 task 產生獨立的 Java 類別，讓每個 task 擁有自己的 profile，JIT 便能將單型（monomorphic）呼叫點內聯、對具型別的欄位展開迴圈、自動向量化，並隨著 task 在生命週期中看到的資料改變而重新最佳化。引擎也順著 G1 收集器的脾氣設計——避免配置超過 humongous 門檻的物件、以分段與扁平陣列取代龐大的相互參照物件圖——因為否則 GC 行為就會直接決定吞吐量。
客戶端以 RESTful HTTP 介面送出 SQL，coordinator 先評估排隊政策，接著由 ANTLR 為基礎的 parser 產生語法樹，analyzer 用它決定型別與強制轉型、解析函式與作用域，並抽出子查詢、聚合與 window function。邏輯 planner 產出的是純邏輯的 plan node 樹，不帶任何執行資訊，每個節點的子節點就是它的輸入。最佳化器接著貪婪地套用轉換規則直到達到不動點：每條規則有一個能比對 plan 子樹的 pattern，比對成功就改寫成邏輯等價的子計畫。Presto 內建述詞與 limit 下推、欄位裁剪與去相關（decorrelation），另有兩項會使用表格與欄位統計資訊的成本式最佳化——join 策略選擇與 join 重排——而更完整的 Cascades 式搜尋當時仍在進行中。
最佳化器把計畫切成 stage，也就是能跨 worker 平行執行的單位，並在其間插入具緩衝的 in-memory shuffle；由於 shuffle 會付出延遲、緩衝記憶體與 CPU 成本，把 shuffle 數量壓到最低是實體規劃的核心目標。plan node 會宣告輸出屬性——分割、排序、bucketing、grouping——也能宣告 required 與 preferred 屬性，於是多餘的 shuffle 直接被消去，其餘的則調整參數。Presto 貪婪地挑選能滿足最多 required 屬性的分割方式，這可能表示改用較少的欄位分割並接受更嚴重的 skew。當 connector 提供 layout 時，效果非常實際：A/B Testing 中 join 兩側本來就依同一欄位分割，因此可用 co-located join 省掉整次 shuffle；而圖 3 那個需要四次 shuffle 的天真計畫，最後會塌縮成單一個資料處理 stage。
stage 順序由兩種政策決定。all-at-once 同時排程所有 stage 以最小化 wall clock 時間，服務延遲敏感的使用情境；phased execution 則找出資料流圖中必須同時啟動才能避免死結的強連通分量，並依拓撲順序執行，因此 hash join 在 build 端完成前不會排程 probe 端的串流，對批次工作的記憶體效率好得多。task 排程再把 stage 分成 leaf 與 intermediate：leaf stage 從 connector 讀資料，在沒有額外限制且 split 夠多時會排到叢集中每一個 worker 上，因為解壓縮、解碼與過濾佔了大部分 CPU 且高度可平行化；排程器也能依插件提供的網路拓撲，優先選擇 rack-local 讀取。intermediate stage 的 task 可以放在任何節點，而且引擎可以在執行期間動態改變其數量。
split 是外部儲存系統中某塊可定址資料的不透明控制代碼，內容由 connector 定義——分散式檔案系統是檔案路徑加位移量，Redis 則是表格資訊加上鍵與值的格式以及主機清單。Presto 要求 connector 分成小批次列舉 split，並延遲指派給 task，換來四項好處：查詢回應時間與列舉時間解耦，而 Hive connector 光是列出分割與其中的檔案就可能花上數分鐘；帶 LIMIT 或被提早取消的查詢常常在列舉完成前就結束；coordinator 把新的 split 指派給佇列最短的 task，吸收了各 split CPU 成本與各 worker 速度的差異；coordinator 記憶體也不必一次容納數百萬個 split 的 metadata。每個 leaf stage 的 task 至少要拿到一個 split 才具備執行資格，而 intermediate task 永遠可執行，只有被中止或所有上游 task 完成時才結束。論文明講的代價是：準確回報查詢進度變得困難。
在 task 內部，driver loop 在能夠推進的運算子配對之間搬動 page——page 是資料列序列的欄式編碼，由每欄一個且採扁平記憶體表示的 Block 組成——而不是採用 Volcano 式遞迴迭代器的 pull 模型。之所以選這個迴圈，正是因為運算子可以被帶到已知狀態後讓出執行緒，而不是無限期阻塞，這才讓協作式多工成立；此外，當輸出緩衝區滿、輸入緩衝區空或記憶體耗盡時，排程器也會提早切換。在網路端，引擎監看輸出緩衝區使用率，當它持續偏高就減少可執行的 split 以降低有效並行度，這既讓網路資源分配更公平，也避免一個下載 10 到 50MB 的緩慢 BI 客戶端佔住數十 GB 緩衝區。接收端則追蹤每次請求傳輸量的移動平均，據此計算目標 HTTP 並行度，產生的 backpressure 會往上游傳遞。寫入則反向套用同一個想法：當產出資料的 stage 超過緩衝區使用率門檻時，就在更多節點上新增 task 以提高寫入並行度，在 S3 小檔爆量與寫入吞吐量之間取得平衡。
所有非瑣碎的配置都必須歸類為 user 或 system memory，並向對應的 pool 預約；超過全域或每節點上限的查詢會被終止，而當節點記憶體耗盡時，引擎會停住 task 處理來阻擋新的預約。論文把算式攤開來：500 節點叢集、每節點 100GB 查詢記憶體、單一查詢全域上限 5TB，理論上可容納十個查詢；但若要允許 2:1 的 skew，每節點上限就得壓到 20GB，保證能並行的只剩五個——少到不可接受，因此才刻意超額配置。有兩個機制維持超額配置叢集的健康。spilling 會依執行時間由小到大對合格的 task 進行記憶體撤回，直到最後一次請求能被滿足為止，撤回方式是把 hash join 與聚合的狀態寫到磁碟。若未設定 spilling 或已無可撤回的記憶體，就換 reserved pool 出手：記憶體吃緊節點上用量最大的查詢會被提升到所有 worker 的 reserved pool，而為了避免不同 worker 各自卡住不同查詢造成死結，全叢集同一時間只允許一個查詢進入 reserved pool。
Presto 成為「聯邦式、與儲存無關的 SQL 引擎」的樣板：Amazon Athena 直接建構在它之上，Uber、Netflix、Airbnb、Bloomberg 與 LinkedIn 都在生產環境使用，Qubole、Treasure Data 與 Starburst 則圍繞它推出商業產品。2019 年專案分裂，原作者的分支先成為 PrestoSQL 再更名為 Trino，Facebook 這一脈則以 PrestoDB 之名納入 Linux Foundation 的 Presto Foundation。Trino 後來逐一補上本論文點名的缺口——完整的成本式最佳化器、以 build 端值裁剪 probe 端掃描的 dynamic filtering，以及把 exchange 物化到物件儲存的容錯執行，而後者正是論文說自己正在評估的可選 checkpointing。Meta 則往另一個方向推進，用 C++ 重寫 worker 的執行層，成果就是 Velox 與 Prestissimo：保留 coordinator、connector 與 split 模型，替換掉論文第五節極力辯護的那些 JVM 運算子。Connector API 以及它隱含的 catalog 模型，如今已是查詢引擎接上 Iceberg、Delta Lake 與 Hudi 表格的標準做法，因此現代 lakehouse 那套「開放表格式與可插拔引擎分離」的架構，大體上就是 Presto 架構的一般化。它最持久的想法或許也最樸素：shuffle 是否物化，是一個可與延遲交換的旋鈕，而不是分散式查詢引擎的既定性質。
“In aggregate, Presto processes hundreds of petabytes of data and quadrillions of rows per day at Facebook.”
“Tests on a sample of production workload from the Batch ETL use case show that lazy loading reduces data fetched by 78%, cells loaded by 22% and total CPU time by 14%.”
“However, as of late 2018, Presto does not have any meaningful built-in fault tolerance for coordinator or worker node crash failures.”