Flink 完美搭檔：資料存儲層上的 Pravega

作者 | 滕昱 DellEMC 研發總監

整理 | 趙海凱 DellEMC 實習生

本文将從大資料架構變遷曆史，Pravega 簡介，Pravega 進階特性以及車聯網使用場景這四個方面介紹 Pravega，重點介紹 DellEMC 為何要研發 Pravega，Pravega 解決了大資料處理平台的哪些痛點以及與 Flink 結合會碰撞出怎樣的火花。

大資料架構變遷

Lambda 架構之痛

如何有效地提取和提供資料，是大資料處理應用架構是否成功的關鍵之處。由于處理速度和頻率的不同，資料的攝取需要通過兩種政策來進行。上圖就是典型的 Lambda架構：把大資料處理架構分為批處理和實時流處理兩套獨立的計算基礎架構。

對于實時處理來說，來自傳感器，移動裝置或者應用日志的資料通常寫入消息隊列系統（如 Kafka), 消息隊列負責為流處理應用提供資料的臨時緩沖。然後再使用 Spark Streaming 從 Kafka 中讀取資料做實時的流計算。但由于 Kafka 不會一直儲存曆史資料，是以如果使用者的商業邏輯是結合曆史資料和實時資料同時做分析，那麼這條流水線實際上是沒有辦法完成的。是以為了補償，需要額外開辟一條批處理的流水線，即圖中" Batch "部分。

對于批處理這條流水線來說，集合了非常多的的開源大資料元件如 ElasticSearch, Amazon S3, HDFS, Cassandra 以及 Spark 等。主要計算邏輯是是通過 Spark 來實作大規模的 Map-Reduce 操作，優點在于結果比較精确，因為可以結合所有曆史資料來進行計算分析，缺點在于延遲會比較大。

這套經典的大資料處理架構可以總結出三個問題：

• 兩條流水線處理的延遲相差較大，無法同時結合兩條流水線進行迅速的聚合操作，同時結合曆史資料和實時資料的處理性能低下。
• 資料存儲成本大。而在上圖的架構中，相同的資料會在多個存儲元件中都存在一份或多份拷貝，資料的備援無疑會大大增加企業客戶的成本。并且開源存儲的資料容錯和持久化可靠性一直也是值得商榷的地方，對于資料安全敏感的企業使用者來說，需要嚴格保證資料的不丢失。
• 重複開發。同樣的處理流程被兩條流水線進行了兩次，相同的資料僅僅因為處理時間不同而要在不同的架構内分别計算一次，無疑會增加資料開發者重複開發的負擔。

流式存儲的特點

在正式介紹 Pravega 之前，首先簡單談談流式資料存儲的一些特點。

如果我們想要統一流批處理的大資料處理架構，其實對存儲有混合的要求。

• 對于來自序列舊部分的曆史資料，需要提供高吞吐的讀性能，即 catch-up read
• 對于來自序列新部分的實時資料，需要提供低延遲的 append-only 尾寫 tailing write 以及尾讀 tailing read

重構的流式存儲架構

像 Kafka，Cassandra 等分布式存儲元件來說，其存儲架構都從上往下遵循從專有的日志存儲，到本地檔案，再到叢集上的分布式存儲的這種模式。

而 Pravega 團隊試圖重構流式存儲的架構，引入 Pravega Stream 這一抽象概念作為流式資料存儲的基本機關。Stream 是命名的、持久的、僅追加的、無限的位元組序列。

如上圖所示，存儲架構最底層是基于可擴充分布式雲存儲，中間層表示日志資料存儲為 Stream 來作為共享的存儲原語，然後基于 Stream 可以向上提供不同功能的操作:如消息隊列，NoSQL，流式資料的全文搜尋以及結合 Flink 來做實時和批分析。換句話說，Pravega 提供的 Stream 原語可以避免現有大資料架構中原始資料在多個開源存儲搜尋産品中移動而産生的資料備援現象，其在存儲層就完成了統一的資料湖。

重構的大資料架構

我們提出的大資料架構，以 Apache Flink 作為計算引擎，通過統一的模型/API來統一批處理和流處理。以 Pavega 作為存儲引擎，為流式資料存儲提供統一的抽象，使得對曆史和實時資料有一緻的通路方式。兩者統一形成了從存儲到計算的閉環，能夠同時應對高吞吐的曆史資料和低延時的實時資料。同時 Pravega 團隊還開發了 Flink-Pravega Connector，為計算和存儲的整套流水線提供 Exactly-Once 的語義。

Pravega 簡介

Pravega 的設計宗旨是為流的實時存儲提供解決方案。應用程式将資料持久化存儲到 Pravega 中，Pravega 的 Stream 可以有無限制的數量并且持久化存儲任意長時間，使用同樣的 Reader API 提供尾讀 (tail read) 和追趕讀 (catch-up read) 功能，能夠有效滿足離線計算和實時計算兩種處理方式的統一。

Pravega 基本概念

結合上圖簡要介紹 Pravega 的基本概念：

• Stream

Pravega 會把寫入的資料組織成 Stream,Stream 是命名的、持久的、僅追加的、無限的位元組序列。

• Stream Segments

Pravega Stream 會劃分為一個或多個 Segments，相當于 Stream 中資料的分片，它是一個 append-only 的資料塊，而 Pravega 也是基于 Segment 基礎上實作自動的彈性伸縮。Segment 的數量也會根據資料的流量進行自動的連續更新。

• Event

Pravega's client API 允許使用者以 Event 為基本機關寫入和讀取資料，Event 具體是Stream 内部位元組流的集合。如 IOT 傳感器的一次溫度記錄寫入 Pravega 就可以了解成為一個 Event.

• Routing Key

每一個 Event 都會有一個 Routing Key，它是使用者自定義的一個字元串，用來對相似的 Event 進行分組。擁有相同 Routing Key 的 Event 都會被寫入相同的 Stream Segment 中。Pravega 通過 Routing Key 來提供讀寫語義。

• Reader Group

用于實作讀取資料的負載均衡。可以通過動态增加或減少 Reader Group 中 Reader的數量來改變讀取資料的并發度。更為詳細的介紹請參考 Pravega 官方文檔：

http://pravega.io/docs/latest/pravega-concepts

Pravega 系統架構

在控制層面，Controller 作為 Pravega 叢集的主節點對資料層面的 Segment Store做管理，提供對流資料的建立，更新以及删除等操作。同時它還承擔實時監測叢集健康狀态，擷取流資料資訊，收集監控名額等功能。通常叢集中會有3份 Controller 來保證高可用。

在資料層面，Segment Store 提供讀寫 Stream 内資料的 API。在 Pravega 裡面，資料是分層存儲的：

• Tier 1 存儲

Tier1 的存儲通常部署在 Pravega 叢集内部，主要是提供對低延遲，短期的熱資料的存儲。在每個 Segment Store 結點都有 Cache 以加快資料讀取速率，Pravega 使用Apache Bookeeper 來保證低延遲的日志存儲服務。

• Long-term 存儲

Long-term 的存儲通常部署在 Pravega 叢集外部，主要是提供對流資料的長期存儲，即冷資料的存儲。不僅支援 HDFS，NFS，還會支援企業級的存儲如 Dell EMC的 ECS，Isilon 等産品。

Pravega 進階特性

讀寫分離

在 Tier1 存儲部分，寫入資料的時候通過 Bookkeeper 保證了資料已經在所有的 Segment Store 中落盤，保證了資料寫入成功。

讀寫分離有助于優化讀寫性能：隻從 Tier1 的 Cache 和 Long-term 存儲去讀，不去讀 Tier1 中的 Bookkeeper。

在用戶端向 Pravega 發起讀資料的請求的時候，Pravega 會決定這個資料究竟是從Tier1 的 Cache 進行低延時的 tail-read，還是去 Long-term 的長期存儲資料(對象存儲/NFS)去進行一個高吞吐量的 catch-up read（如果資料不在 Cache，需要按需load 到 Cache 中）。讀操作是對用戶端透明的。

Tier1 的 Bookkeeper 在叢集不出現故障的情況下永遠不進行讀取操作，隻進行寫入操作。

彈性伸縮

Stream 中的 Segment 數量會随着 IO 負載而進行彈性的自動伸縮。以上圖為例子簡單闡述：

資料流在 t0 時刻寫入 Pravega，根據路由鍵資料會路由到 Segment0 和Segment1 中，如果資料寫入速度保持恒定不變，那麼 Segemnt 數量不會發生變化。

在 t1 時刻系統感覺到 segment1 資料寫入速率加快，于是将其劃分為兩個部分:Segment2 和 Segment3。這時候 Segment1 會進入 Sealed 狀态，不再接受寫入資料，資料會根據路由鍵分别重定向到 Segment2 和 Segment3.

與 Scale-Up 操作相對應，系統也可以根據資料寫入速度變慢後提供 Scale-Down 操作。如在 t3 時刻系統 Segment2 和 Segment5 寫入流量減少，是以合并成新的 Segment6。

端到端的彈性伸縮

Pravega 是以 Kubernetes Operator 來對叢集各元件進行有狀态的應用部署，這可以使得應用的彈性伸縮更為靈活友善。

Pravega 最近也在和 Ververica 進行深度合作,緻力于在 Pravega 端實作 Kubernetes Pod 級别的彈性伸縮同時在 Flink 端通過 rescaling Flink 的 Task 數量來實作彈性伸縮。

事務性寫入

Pravega 同樣提供事務性的寫入操作。在送出事務之前，資料會根據路由鍵寫入到不同的 Transaction Segment 中，這時候 Segment 對于 Reader 來說是不可見的。隻有在事務送出之後，Transaction Segment 才會各自追加到 Stream Segment 的末尾，這時候 Segment 對于 Reader 才是可見的。寫入事務的支援也是實作與 Flink 的端到端 Exactly-Once 語義的關鍵。

Pravega vs. Kafka

首先最關鍵的不同在于兩者的定位：Kafka 的定位是消息隊列，而 Pravega 的定位是存儲，會更關注于資料的動态伸縮，安全性，完整性等存儲特性。

對于流式資料處理來說，資料應該被視為連續和無限的。Kafka 作為基于本地檔案系統的一個消息隊列，通過采用添加到日志檔案的末尾并跟蹤其内容( offset 機制)的方式來模拟無限的資料流。然而這種方式必然受限于本地檔案系統的檔案描述符上限以及磁盤容量，是以并非無限。

而兩者的比較在圖中給出了比較詳細的總結，不再贅述。

Pravega Flink Connector

為了更友善與 Flink 的結合使用，我們還提供了 Pravega Flink Connector（

https://github.com/pravega/flink-connectors),

Pravega 團隊還計劃将該 Connector 貢獻到 Flink 社群。Connector 提供以下特性：

• 對 Reader 和 Writer 都提供了 Exactly-once 語義保證，確定整條流水線端到端的 Exactly-Once
• 與 Flink 的 checkpoints 和 savepoints 機制的無縫耦合
• 支援高吞吐低延遲的并發讀寫
• Table API 來統一對 Pravega Sream 的流批統一處理

車聯網使用場景

以無人駕駛車聯網這種能夠産生海量 PB 級資料的應用場景為例：

• 需要對車況路況資料做實時的處理以及時對路線規劃做出微觀的預測和規劃
• 需要對較長期行駛資料運作機器學習算法來做路線的宏觀預測和規劃，這屬于批處理
• 同時需要結合實時處理和批處理，利用曆史資料生成的機器學習模型和實時資料回報來優化檢測結果

而客戶關注的關鍵名額主要在：

• 如何保證高效地端到端處理速度
• 如何盡可能減少機器學習模型的訓練時間
• 如何盡可能降低存儲資料的消耗與成本

下面給出引入 Pravega 前後的解決方案比較。

解決方案比較

Pravega 的引入無疑大大簡潔了大資料處理的架構：

• Pravega 作為抽象的存儲接口，資料在 Pravega 層就實作了一個資料湖：批處理,實時處理和全文搜尋都隻需要從 Pravega 中擷取資料。資料隻在 Pravega 存儲一份，而不需要像第一種方案中資料備援地存儲在 Kafka，ElasticSearch 和 Long Term Storage 中，這可以極大減少了企業使用者資料存儲的成本。
• Pravega 能夠提供自動的 Tier Down，無需引入 Flume 等元件來進行額外的 ETL 開發。
• 元件得到精簡，從原來的 Kafka+Flume+HDFS+ElasticSearch+Kibana+Spark+SparkStreaming 精簡到 Pravega+Flink+Kibana+HDFS ,減輕運維人員的運維壓力。
• Flink 能夠提供流批處理統一的功能，無需為相同的資料提供兩套獨立的處理代碼。

總 結

Flink 俨然已經成為流式計算引擎中的一顆閃亮的明星，然而流式存儲領域尚是一片空白。而 Pravega 的設計初衷就是為了填上大資料處理架構這一拼圖最後的空白。“所有計算機領域的問題，都可以通過增加一個額外的中間層抽象解決”，而 Pravega 本質就是在計算引擎和底層存儲之間充當解耦層，旨在解決新一代大資料平台在資料存儲層上的挑戰。

Tips：點選下方連結可回顧作者分享視訊及了解更多 Flink 社群生态篇直播～