本文轉載自 InfoQ 官網

作者：Alluxio-鍾榮榮；Meta-James Sun & Ke Wang

Raptor 是用來支持Meta（以前的Facebook）中的一些關鍵交互式查詢工作負載的Presto連接器（presto-raptor）。儘管ICDE 2019的論文 Presto：SQL on Everything（http://research.facebook.com/publications/presto-sql-on-everything/）中提到過這一特性，但它對於許多 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架構信息(http://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-architecture-details)或觀看附錄—Raptor講座(http://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-talk)。

侷限

通過存算耦合，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 性能提升十倍》（http://prestodb.io/blog/2021/02/04/raptorx）。

>>> 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(http://engineering.fb.com/2016/06/16/core-data/data-scale-june-2016-recap/)，查看2016年Data@Scale會議上關於Raptor的公開講座。

想要獲取更多有趣有料的【活動信息】【技術文章】【大咖觀點】，請關注[Alluxio智庫]：