?

?

作者 | 滕昱 DellEMC 研發總監

整理 | 趙海凱 DellEMC 實習生

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

大數據架構變遷

Lambda 架構之痛

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

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

對于批處理這條流水線來說，集合了非常多的的開源大數據組件如 ElasticSearch, Amazon S3, HDFS, Cassandra 以及 S

作者 | 滕昱 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 社區生態篇直播～

park 等。主要計算邏輯是是通過 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 社區生態篇直播～

總結

以上是生活随笔為你收集整理的Flink 完美搭档：数据存储层上的 Pravega的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。