91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

Flink中的Pravega怎么用

發布時間:2021-12-31 10:24:27 來源:億速云 閱讀:149 作者:小新 欄目:大數據

這篇文章主要為大家展示了“Flink中的Pravega怎么用”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“Flink中的Pravega怎么用”這篇文章吧。

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

大數據架構變遷



 
             

Lambda 架構之痛


Flink中的Pravega怎么用


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

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

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

這套經典的大數據處理架構可以總結出三個問題:

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


 
             

流式存儲的特點


在正式介紹 Pravega 之前,首先簡單談談流式數據存儲的一些特點。

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

Flink中的Pravega怎么用

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


 
             

重構的流式存儲架構


Flink中的Pravega怎么用

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

而 Pravega 團隊試圖重構流式存儲的架構,引入 Pravega Stream 這一抽象概念作為流式數據存儲的基本單位。Stream 是命名的、持久的、僅追加的、無限的字節序列。

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


 
             

重構的大數據架構

Flink中的Pravega怎么用

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

Pravega 簡介


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

 
   

Pravega 基本概念


 

 

Flink中的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 系統架構


 

Flink中的Pravega怎么用

Flink中的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 進階特性


 
   

讀寫分離


 

Flink中的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 在集群不出現故障的情況下永遠不進行讀取操作,只進行寫入操作。

 
   

彈性伸縮


 

Flink中的Pravega怎么用


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

  • 數據流在 t0 時刻寫入 Pravega,根據路由鍵數據會路由到 Segment0 和Segment1 中,如果數據寫入速度保持恒定不變,那么 Segemnt 數量不會發生變化。
  • 在 t1 時刻系統感知到 segment1 數據寫入速率加快,于是將其劃分為兩個部分:Segment2 和 Segment3。這時候 Segment1 會進入 Sealed 狀態,不再接受寫入數據,數據會根據路由鍵分別重定向到 Segment2 和 Segment3.
  • 與 Scale-Up 操作相對應,系統也可以根據數據寫入速度變慢后提供 Scale-Down 操作。如在 t3 時刻系統 Segment2 和 Segment5 寫入流量減少,因此合并成新的 Segment6。

 
   

端到端的彈性伸縮


 

Flink中的Pravega怎么用


Pravega 是以 Kubernetes Operator 來對集群各組件進行有狀態的應用部署,這可以使得應用的彈性伸縮更為靈活方便。

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

 
   

事務性寫入


 

Flink中的Pravega怎么用


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

 
   

Pravega vs. Kafka


 

Flink中的Pravega怎么用


首先最關鍵的不同在于兩者的定位: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 的流批統一處理

車聯網使用場景

Flink中的Pravega怎么用


以無人駕駛車聯網這種能夠產生海量 PB 級數據的應用場景為例:

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

而客戶關注的關鍵指標主要在:

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

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

 
   

解決方案比較


 

Flink中的Pravega怎么用

Flink中的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怎么用”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

习水县| 招远市| 石柱| 大荔县| 宁陕县| 武胜县| 三江| 招远市| 孝义市| 青铜峡市| 西平县| 海淀区| 平度市| 和硕县| 开封市| 仁布县| 黔南| 鄂托克前旗| 湘阴县| 库尔勒市| 晋州市| 莲花县| 金溪县| 柘城县| 安丘市| 桐梓县| 西华县| 阿城市| 奈曼旗| 苗栗市| 瓮安县| 晴隆县| 肥城市| 台南县| 合川市| 永新县| 油尖旺区| 拉萨市| 昆山市| 任丘市| 龙州县|