解構流儲存 — Pravega，與 Flink 構建端到端的大資料流水處理線

本篇內容整理自 Pravega 中國社群創始人、戴爾科技集團軟體工程技術總監滕昱在 Flink Forward Asia 2021 主會場的演講。主要內容包括：
儲存抽象的現狀
Pravega 效能架構詳解
Pravega 流儲存資料演示
展望未來

FFA 2021 直播回放 & 演講 PDF 下載

一、儲存抽象的現狀

在計算機軟體設計中，有一個非常著名的觀點：任何新的計算機問題都可以通過新加入的抽象層解決，對於儲存也是一樣。上圖列出了三種大家主要使用的儲存抽象，即塊儲存、檔案儲存和物件儲存。塊儲存基本上和現代計算機工業同時期誕生；檔案儲存作為當今主流的儲存抽象稍晚出現；物件儲存更晚，其誕生於 1990 年代。而在實時計算的發展和雲時代背景下，流式的資料有著越來越廣泛的應用，我們認為需要一種新興的儲存抽象來應對這一種強調低延時、高併發流量的資料。而在檔案儲存中新增位元組流可能是一個最直觀的想法，但在實際需求上面臨著一系列的挑戰，實現反而更加複雜，如下圖所示：

資料的寫入大小對吞吐量的影響至關重要，為了平衡延時和吞吐量，在實現上需要引入 batching，並且需要預分配空間避免塊分配造成的效能損耗，最後作為儲存，持久化也必須保證。

本地檔案系統本質上是不安全的。在現實世界中，每時每刻硬體節點，磁碟介質都可能會損壞。為了解決這些問題，就需要引入分散式儲存系統，例如常見的多副本系統，但副本的拷貝費時費空間，分散式一致性協議的資料安全問題又會成為新的難題。

如果基於 shared-nothing 架構設計，完全並行不存在共享資源，例如上圖中有三個副本分別存於三個獨立的物理節點之上，那麼單條流資料的儲存大小就受限於單個物理界點的儲存上限，所以這依然不是一個完備的解決方法。

由此可見，由於上述一系列的問題，基於檔案系統構建流儲存是相當複雜的。

於是，我們受到了開篇的觀點的啟示，嘗試換個角度，使用分散式檔案和物件儲存的分層架構模式來解決這個問題。底層的可擴充套件儲存可以作為一個資料湖，流的歷史資料可以存入其中與其他非流的資料集共存，在節省了資料遷移、儲存運維開銷的同時可以解決資料孤島的問題，批流結合的計算將會更加方便。

分層架構可以解決分散的多客戶端。為了解決容錯恢復的問題，我們在流儲存的基礎上增加了分散式 log 儲存。

在真實應用例項中，實時應用程式的流量可能隨著時間波動，為了應對資料的峰谷，我們引入了動態伸縮功能。

在左上角的圖示中，橫軸表示時間，縱軸表示應用程式的資料。它的波形圖剛開始很平穩，到了特定點時資料量突然變大，這往往是一些跟時間有關的應用程式的特性，比如早晚高峰、雙十一等場景，這個時候流量就會蜂擁而入。

一個完備的流儲存系統應該能夠感知到實時流量的變化進行資源的合理分配。當資料量變大時，底層會動態地分配更多的儲存單元處理資料。在雲原生時代的底層架構中，動態伸縮也是通用的儲存系統中非常重要的一點。

二、Pravega 效能架構詳解

Pravega 的設計宗旨是成為流的實時儲存解決方案。

第一，應用程式將資料持久化儲存到 Pravega 中，藉助分層儲存架構，Pravega Stream 實現了無上限的流儲存；
第二，Pravega 支援端到端的僅一次語義，包括讀端的 checkpoint 與事務性寫功能，使得計算可以拆分為多個可靠的獨立應用程式，實現了流式系統的微服務架構；
第三，Pravega 的動態伸縮機制，可以實現流量監控並自動在底層進行資源的分配，讓開發和運維人員無需手動排程叢集。

Pravega 獨立的伸縮機制，讓生產者和消費者互不影響，資料處理管道變得富有彈性，能對資料的實時變化做出適時的反應。

如圖所示，Pravega 是從儲存的視角看待流資料。Kafka 本身的定位是訊息系統，所以它會從訊息視角看待流資料。訊息系統與儲存系統的定位是不同的，訊息系統是指訊息傳輸系統，主要關注資料傳輸與生產消費的過程。Pravega 的定位是企業級的分散式流儲存產品，不但滿足流的屬性還支援資料儲存的持久化、安全可靠、隔離等屬性。

視角的不同帶來了設計架構上的差異性，由於訊息系統無需處理長時間的資料儲存，因此都會需要額外的任務和元件進行資料的搬運來完成持久化。而定位流儲存的 Pravega 則在主儲存中直接解決了資料 retention 問題。Pravega 的資料儲存的核心引擎稱之為 segment store，直接對接 HDFS 或 S3 的分散式儲存元件用以進行長期、持久化的儲存。依託底層儲存元件的成熟架構與可擴充套件能力，Pravega 在儲存端也就自然具備了大規模儲存和可擴充套件的特性。

另一個架構上的差異則來自於客戶端的小寫優化。在典型的 IoT 場景中，邊緣端的寫入端數量通常比較大，而每次寫入的資料量可能並不多。Pravega 的設計也充分考慮了這一場景，採用了在客戶端和 segment store 兩次 batching 的優化，將來自多個客戶端的小寫合併成對於底層磁碟友好的小批量寫入，從而在保證低延時的基礎上，大幅提升了高併發寫入的效能。

這一設計也相應地對效能產生了影響。Pravega 測試了在同樣的高併發負載下，與 Kafka 和 Pulsar 的效能對比，實驗結果如下圖所示。在我們的測試中使用高度並行的負載，每個 Stream/Topic 最多有 100 個寫入端和 5000 個 segment。Pravega 可以在所有情況下都維持 250MBps 的速率，這也是測試雲環境中磁碟的寫入最大速率。而左右兩圖中可以看到，Kafka 和 Pulsar 在增加分割槽和生產者數量時，效能都會顯著降低，在大規模的併發度下先後出現效能的降級。

這一實驗過程和環境也完整地公開在這一篇部落格之中，實驗的程式碼也完全開源並貢獻到了 openmessaging-benchmark 之中，有興趣的同學可以嘗試重現。

三、Pravega 流儲存資料演示

從儲存角度，我們已經介紹了 Pravega 對流儲存的變化和架構特點。接下來，我們講講如何消費流儲存資料。Pravega 如何跟 Flink 配合，構建端到端的大資料流水處理線。

我們提出的大資料架構，以 Apache Flink 作為計算引擎，通過統一的模型以及 API 來統一批處理和流處理；以 Pravega 作為儲存引擎，為流式資料儲存提供統一的抽象，使得對歷史和實時資料有一致的訪問方式。兩者統一形成了從儲存到計算的閉環，能夠同時應對高吞吐的歷史資料和低延時的實時資料。

更進一步，對於邊緣計算的場景，Pravega 也相容常用的訊息通訊協議，實現了相應的資料接收器，可以作為大資料流水處理的管道，從管道收集資料，把資料給到下游計算引擎應用程式，完成從邊緣到資料中心的資料處理流水線。通過這樣的方式，企業級使用者可以很容易地搭建自己的大資料處理流水線。這也是我們開發流儲存產品的目的。

我們認為在雲原生時代，動態伸縮的功能是非常重要的，這樣不但可以減輕應用程式開發的難度，而且可以更高效地利用底層的硬體資源。之前介紹了 Pravega 的動態伸縮，Flink 的新版本也支援了動態伸縮功能。那麼我們將兩個獨立的伸縮聯絡起來，把動態伸縮功能推到整條流水線呢？

我們跟社群一起合作，完成了完整的伸縮鏈路，把端到端的 Auto-scaling 功能帶給所有的客戶。上圖是端到端 Auto-scaling 概念的示意圖。當資料注入變大時，Pravega 能夠發生自動伸縮，分配更多的 segment 處理儲存端的壓力。而通過 metrics 以及 Kubernetes HPA 功能，Flink 也可以相應地分配更多平行計算的節點給到相應的計算任務中去，從而應對資料流量的變化。這是新一代對企業級使用者非常關鍵的雲原生能力。

四、展望未來

在 Flink Forward Asia 2021 大會上，Pravega 社群也跟 Flink 一起，共同釋出了資料庫同步方案的白皮書。Pravega 作為 CNCF 的專案也在不斷髮展，同時也會更堅定地擁抱開源。

隨著技術的不斷髮展，越來越多的流式引擎和資料庫引擎開始朝著融合的方向發展。展望未來，儲存和計算，流和表的界限逐漸模糊。Pravega 批流一體的儲存設計也暗合了 Flink 未來很重要的一個發展方向。Pravega 也會積極與包括 Flink 在內的資料湖倉相關的開源社群溝通合作，為企業級使用者構建更友好、更強大的新一代資料流水線。