幫助 Meta 解決 Presto 中的數據孤島問題

語言: CN / TW / HK

本文轉載自 InfoQ 官網

作者:Alluxio-鍾榮榮;Meta-James Sun & Ke Wang

幫助 Meta 解決 Presto 中的數據孤島問題

Raptor 是用來支持Meta(以前的Facebook)中的一些關鍵交互式查詢工作負載的Presto連接器(presto-raptor)。儘管ICDE 2019的論文 Presto:SQL on Everything(https://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架構信息(https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-architecture-details)或觀看附錄—Raptor講座(https://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 性能提升十倍》(https://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(https://engineering.fb.com/2016/06/16/core-data/data-scale-june-2016-recap/),查看2016年Data@Scale會議上關於Raptor的公開講座。

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