本文轉載自 InfoQ 官網
作者：Alluxio-鍾榮榮；Meta-James Sun & Ke Wang

Raptor 是用來支持 Meta（以前的 Facebook）中的一些關鍵交互式查詢工作負載的 Presto 連接器（presto-raptor）。儘管 ICDE 2019 的論文 Presto：SQL on Everything（https://research.facebook.com...）中提到過這一特性，但它對於許多 Presto 用户來説仍然有些神秘，因為目前還沒有關於此特性的可用文檔。本文將介紹 Raptor 的歷史，以及為什麼 Meta 最終替換了它，轉而採用基於本地緩存的新架構 RaptorX。

Raptor 簡介

一般來説，Presto 作為一個查詢引擎並不具備存儲空間，因此開發了連接器來查詢不同的外部數據源。這個框架非常靈活，但在存算分離的架構中，很難提供低延遲保證。網絡和存儲延遲導致很難確保數據訪問的穩定性。為了解決這個問題，Raptor 被設計成 Presto 的獨享存儲引擎（shared-nothing storage engine）。

>> 動機—AB 測試框架中的一個初始用例 <<

在 Meta 公司，新的產品特性通常要經過 AB 測試，然後才能大範圍發佈。AB 測試框架允許工程師配置實驗，在實驗組啓用新特性，然後通過監控一些關鍵指標與對照組進行比較。該框架為工程師提供了一個 UI（用户界面）來分析他們的實驗統計數據，從而將配置轉換為 Presto 查詢，查詢語句是已知且有限的。查詢通常連接多個大型數據集，其中包括用户、設備、測試、事件屬性等。這個用例的基本需求是：

1.準確性：數據必須完整、準確，不能有偏差
2.靈活性：用户應該能夠根據分析需求隨意劃分其運行結果；
3.實時性：測試結果應在數小時內獲得；
4.交互延遲短：查詢需要在幾秒鐘內返回結果；
5.高可用：作為產品開發的關鍵服務，服務的宕機時間必須很短。

Presto 在典型的倉庫設置中（比如使用 Hive 連接器直接查詢倉庫數據）可以輕鬆滿足前兩個要求，但無法滿足其他的要求。倉庫數據大多是 T+1 導入，沒有近實時的數據導入，因此不能滿足實時性的要求。此外，Meta 的數據中心已經轉用存算分離的架構，當以高 QPS （查詢吞吐率）掃描大型表時，無法保證低延遲。同時，典型的 Presto 部署會停止整個集羣，因此也不能滿足高可用需求。

為了支持這一關鍵用例，我們開始了 Raptor 的產品化進程。

>>>   RaptorX 架構   <<<

Raptor 連接器使用 MySQL 作為 metastore 來存儲表和文件元數據。表數據存儲在每個 worker 節點的本地磁盤上，並定期備份到外部存儲系統，以便在 worker 節點崩潰時能夠進行數據恢復。數據以足夠小的批量方式導入 Raptor 集羣中，從而確保分鐘級別的延遲，滿足實時性要求。此外，還創建了備用集羣，提供高可用性。

想要了解更多 Raptor 存儲引擎的相關信息，請查看附錄—Raptor 架構信息(https://prestodb.io/blog/2022...)或觀看附錄—Raptor 講座(https://prestodb.io/blog/2022...)。

侷限

通過存算耦合，Raptor 集羣可以支持低延遲、高吞吐量的查詢工作負載。但是，這種架構帶來了以下幾個問題：

集羣利用率低

Raptor 集羣的大小通常取決於需要存儲多少數據。由於存算耦合，隨着表的增多，將需要更多的 worker 提供足夠的存儲空間，即使在集羣空閒時段，重新將機器分配給其他業務使用的難度也變得非常大。

尾部性能較差

由於數據是對應分配給 worker 節點的，如果一個 worker 節點宕機或變慢，必然會影響查詢性能，難以提供穩定的尾部性能。

工程開銷較大

Raptor 需要很多存儲引擎特有的特性和處理功能的支持，比如數據導入/釋放、數據壓縮、數據備份/恢復、數據安全等。對於直接查詢 Meta 數據倉庫的 Presto 集羣而言，所有這些服務都由專門的團隊管理，所有用例都能從中受益。而對於 Raptor 來説，情況就不同了，這導致了工程開銷。

運維開銷較高

由於 Raptor 集羣需要部署額外的存儲系統，因此也就帶來額外的運維開銷。不同的集羣配置和行為意味着需要單獨建立 oncall 的處理流程。

潛在的安全和隱私漏洞

隨着安全和隱私需求的增加，安全與隱私策略的統一實現變得更加重要。使用單獨的存儲引擎使得這些策略執行起來非常困難且脆弱。

RaptorX 的啓用

Raptor 有着很多的痛點，因此從 2019 年開始，Meta 的工程師們就在重新思考 Raptor 的未來，是否有可能既從本地閃存中受益，又無需承擔存算緊耦合架構帶來的代價？最終確定的方向是在原生數據倉庫之上添加一個新的本地緩存層。這個項目作為 Presto Raptor 連接器用例的替代品被命名為 RaptorX。

從技術層面來講，RaptorX 項目與 Raptor 無關。直觀來説，同樣的閃存設備在 RaptorX 裏被當作數據緩存使用來存儲 Ratpor 表，因此將熱數據存放在計算節點上。將本地閃存作為緩存使用而不作為存儲引擎使用的優點如下：
●   Presto 無需管理數據生命週期；
●  單個 worker 故障導致的數據丟失對查詢性能的影響較小；
●  緩存作為文件系統層的一個特性，是 presto-hive 連接器的一部分，因此 RaptorX 集羣的架構類似於其他 presto 集羣，減少了運維開銷。

>>>   RaptorX 架構   <<<

Raptor 和 RaptorX 的根本區別是如何使用 worker 上的本地固態硬盤（SSD）。在 RaptorX 中，Presto Worker 使用 Alluxio 在本地緩存文件數據。不同表列的訪問模式可能差異很大，像 ORC 和 Parquet 這樣的列式文件格式通常用於數據存儲，增加文件中的數據本地性。通過在列式文件上以較小的頁面大小緩存文件片段，只有頻繁訪問的數據才會被保存在接近計算的地方。Presto coordinator 會嘗試將處理相同數據的計算任務調度到相同的 worker 節點上，以提高緩存效率。RaptorX 還實現了文件 footer 和元數據緩存，以及其他能進一步提高性能的智能緩存策略。

要了解更多有關 RaptorX 的信息，參見 《RaptorX: 將 Presto 性能提升十倍》（https://prestodb.io/blog/2021...）。

>>> RaptorX 和 Raptor 性能基準測試 <<<

我們對 RaptorX 和 Raptor 進行了基準性能對比測試。基準測試運行在一個有大約 1000 個 Worker 節點和一個 coordinator 的集羣上。Raptor 和 RaptorX 使用相同的硬件，整個數據集都能夠緩存到 RaptorX 的本地固態硬盤中，因此緩存

從基準測試結果中可以看到，RaptorX 的 P90 延遲與 Raptor 相比降低了一半。RaptorX 中的平均查詢延遲和 P90 查詢延遲之間的差異要比 Raptor 小得多。這是因為在 Raptor 中，數據被物理綁定到計算它的 worker 點上，因此運行慢的節點將不可避免地影響查詢延遲。而在 RaptorX 中，我們採用軟親和（soft affinity） 調度。軟親和調度將選擇兩個 worker 節點作為處理分片（split）的候選節點。如果首選的 worker 節點運行正常，則選擇該節點，否則將選擇輔助（secondary） worker 節點。數據很有可能在多個節點上緩存，因此對整體工作負載的調度策略可以進一步優化，從而達到更好的 CPU 負載均衡。

>>>   從 Raptor 遷移到 RaptorX   <<<

Meta 公司所有以前的 Raptor 用例都遷移到了 RaptorX 上, RaptorX 提供了更好的用户體驗，並且易於擴展。

A/B 測試框架

在前一節中，我們提到了 A/B 測試框架的要求是：準確性、靈活性、實時性、低交互延遲和高可用性。因為 RaptorX 是 Hive 原始數據的緩存層，所以 Hive 保證了數據的準確性。它享受所有來自核心 Presto 引擎的查詢優化，以及 Hive 連接器中的許多特定優化。基準測試結果表明，RaptorX 的平均查詢和 P90 查詢延遲都優於 Raptor。對於實時性要求，我們能夠從 Meta 的近實時倉庫數據導入框架優化中受益，它提高了所有 Hive 數據的實時性。與 Raptor 一樣，備用集羣保證了高可用性。

在遷移過程中，由於用户體驗良好，測試框架的使用量增長了 2 倍。RaptorX 集羣能夠按照與遷移前的 Raptor 集羣相同的容量支持額外的用量。集羣的 CPU 資源得到充分利用，無需擔心存儲限制。

儀表板

在 Meta 中 Raptor 的另一個典型用例是優化儀表板體驗。Presto 用於支持 Meta 中的許多儀表板用例，一些數據工程團隊通過預聚合一些數據表，並且手動導入指定的 Raptor 集羣來獲得更好的查詢性能。在遷移到 RaptorX 之後，數據工程師便可以省去數據導入操作，也不再需要擔心基礎表（base tables）和預聚合表之間的數據一致性問題，同時，P50 以上的大多數分位的查詢延遲的降幅都達到了 30%左右。

>>>   Raptor 範圍之外   <<<

由於 RaptorX 在正常的 Hive 連接器工作負載下作為 booster 使用起來很容易，我們也在 Meta 的數倉交互式工作負載中啓用了 RaptorX。這些是多租户集羣，通過 Presto 處理幾乎所有 Hive 數據的非 ETL 查詢，包括 Tableau、內部儀表板、各種自動生成的 UI 分析查詢、各種內部工具生成的工作負載、工作流原型（pipeline prototyping）、調試、數據探索等。RaptorX 為這些集羣提供了支持，提高了相同數據集的查詢性能。

附錄

Raptor 架構信息

Raptor 表是根據哈希函數進行桶（bucket）劃分的。來自同一個 bucket 的數據被存儲在同一個 worker 節點上。在同一列上的多個表被稱為一個 distribution。一個表桶可以包含多個分片（shard）, 而分片是 Raptor 數據的基本不可變單位, 以 ORC 格式的文件存儲。表也可以有排序屬性，可以更好地優化查詢。

執行優化
Raptor 作為 Presto 的本地存儲引擎，允許 Presto 將計算安排在數據節點上，從而提供低延遲、高吞吐量的數據處理能力。除了通用的 SQL 優化外，Raptor 的數據組織方式還能實現更多的執行優化。

●  本地關聯：當在桶列上關聯同一 distribution 的表時，Raptor 將進行本地關聯（Collocated Join），因為具有相同連接鍵的數據在同一個 worker 上，避免了重新分配。
●  數據裁剪: Raptor 可以進行分片粒度和 ORC 讀取器粒度的裁剪
o   分片粒度的裁剪：分片的列範圍存儲在元數據中，可以根據查詢謂詞跳過分片。如果表有排序屬性，分片將在該 worker 內被排序，這也可用於分片裁剪。
o   ORC 讀取器粒度的裁剪：ORC 讀取器基於謂詞，通過利用 Stripe（一組行數據）元數據針對 Stripe 和行組進行裁剪。如果數據是有序的，排序屬性也有助於數據裁剪。

其他特性
●  時間列：一個時間或日期類型的列可以被指定為時間列。如果指定了一個時間列，Raptor 會在分片上嚴格按天進行限制（即一個 shard 裏的記錄都是屬於某一天的）。鑑於數據保留策略，這將能夠提高大表的數據留存性能。
●  後台壓縮：為了保證實時性，數據通常是以小的時間粒度導入 Raptor 的，這可能導致產生很多小文件，對查詢性能不利。Raptor worker 定期運行後台作業，將多個小分片壓縮成大分片，並進行外部排序，保證排序屬性。
● 數據恢復：如果某個 worker 發生故障，coordinator 將在集羣的其他節點上重新分配故障 worker 的數據。所有 worker 將從備份存儲中下載必要的數據。在恢復過程中，如果某個查詢需要訪問缺失數據，該操作將被阻止，直到數據下載/恢復完畢。
●  數據清理：每個 worker 都有一個後台進程，將其分配的數據與本地數據進行比較，從而恢復缺失的數據，更新陳舊的數據。
●  數據再平衡：如果 coordinator 檢測到數據不平衡（例如，增加了新的 worker 節點），它會修復不平衡的數據分佈。 

Raptor 講座
引用
如需瞭解更多有關 Raptor 的信息, 可點擊此鏈接：Presto Raptor: MPP Shared-Nothing Database on Flash(https://engineering.fb.com/20...)，查看 2016 年 Data@Scale 會議上關於 Raptor 的公開講座。

想要獲取更多有趣有料的【活動信息】【技術文章】【大咖觀點】，請關注[[Alluxio智庫]](https://page.ma.scrmtech.com/...)：