本文轉載自 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智庫]：