基於Kafka的實時計算引擎如何選擇？Flink or Spark？

1.前言

目前實時計算的業務場景愈來愈多，實時計算引擎技術及生態也愈來愈成熟。以Flink和Spark爲首的實時計算引擎，成爲實時計算場景的重點考慮對象。那麼，今天就來聊一聊基於Kafka的實時計算引擎如何選擇？Flink or Spark？

2.爲什麼須要實時計算？

根據IBM的統計報告顯示，過去兩年內，當今世界上90%的數據產生源於新設備、傳感器以及技術的出現，數據增加率也會爲此加速。而從技術上將，這意味着大數據領域，處理這些數據將變得更加複雜和具備挑戰性。例如移動應用廣告、欺詐檢測、出租車預訂、患者監控等場景處理時，須要對實時數據進行實時處理，以便作出快速可行的決策。

目前業界有開源很多實時計算引擎，以Apache基金會的兩款開源實時計算引擎最受歡迎，它們分別是Apache Flink和Apache Spark。接下來，咱們來聊一聊它們的使用場景、優點、侷限性、類似性、以及差別性。方便你們在作技術選型時，選擇切合項目場景的實時計算引擎。 

2.1 如何理解流式與實時？

提及實時計算，可能會說到流式計算，那麼流式和實時是不是等價的呢？嚴格意義上講，它們沒有必然的聯繫。實時計算表明的是處理數據耗時狀況，而流式計算表明的是處理數據的一種方式。

2.2 什麼是流式處理？

首先，它是一種數據處理引擎，其設計時考慮了無邊界的數據集。其次，它與批處理不一樣，批處理的Job與數據的起點和終點有關係，而且Job在處理完有限數據後結束，而流式處理用於處理連續數天、數月、數年、或是永久實時的無界數據。

流處理的特色：

• 容錯性：若是節點出現故障，流式處理系統應該可以恢復，而且應該從它離開的位置再次開始處理；
• 狀態管理：在有狀態處理要求的狀況下，流式處理系統應該可以提供一些機制來保存和更新狀態信息；
• 性能：延時應儘量的小，吞吐量應儘量的大；
• 高級功能：事件時間處理，窗口等功能，這些均是流式處理在處理複雜需求時所須要的功能；

2.3 何時適合流式處理？

流式處理能夠分析連續的數據流，在這種方式中，數據被視爲連續流，處理引擎在很短的時間內（幾毫米到幾分鐘）內取數、分析、以及響應。下面讓咱們來看看流式處理的場景使用場景：

• 異常檢測：流式處理能夠應用於連續的數據流並近乎實時的檢測異常。例如，在金融交易數據中，欺詐性交易能夠被視爲異常，流式處理能夠檢測到這些，保護銀行和客戶免受財務損失。
• 業務流程監控：業務流程涉及特定域中的多個事件。例如，在電子商務業務中，從下單、支付、出庫、送貨、再到用戶簽收的全部事件均可以被視爲一個業務流程。流處理可用於監控此類流程的異常狀況，例如在時間範圍內爲完成、交付商品時出錯等。
• 告警：流式處理可用於根據指定規則觸發告警，知足特定條件，能夠實時將告警發送到不一樣的目標。

3. Spark

Spark已成爲批處理中Hadoop的真正繼承者，也是第一個完美支持Lambda架構的框架。Spark受歡迎度極高，成熟而且普遍使用。Spark免費提供Spark Streaming，它使用微批處理進行流式傳輸。在Spark2.0以後，添加了許多優秀的功能（例如對tungsten、watermarks、event time處理的支持），同時結構化流也更加抽象，截止本篇博客Spark發佈的可用版本爲2.4.3，能夠在最新版本中在微批處理和連續流模式之間進行切換。

3.1 微批處理 & 連續流處理

結構化流式傳輸默認採用微批處理執行，Spark流式計算引擎會定時檢查流數據。在連續流處理中，Spark不會啓動定時任務，而是啓動一組長時間運行的任務，這些任務能夠連續讀取、處理、寫入數據。

微批處理中，驅動程序經過將記錄Offset保存到預寫Log來檢測進度，而後可使用該Log從新進行查詢。須要注意的是，在微批處理處理開始以前，須要在下一個微批處理中處理的範圍Offset保存到Log中，以便獲取肯定性的從新執行和端到端語義。所以，源記錄可能須要等待當前的微批處理處理完成，而後記錄其Offset。

連續流處理中，經過完善和改進算法來檢測查詢進度，特殊標記的記錄被寫入到每一個任務的輸入數據流中。當任務遇到標記時，任務會異步報告處理的最後一個Offset，一旦驅動程序收到寫入接收器的全部任務的Offset，它就會將它們寫入預寫Log中。因爲Checkpoint徹底異步，所以任務能夠不間斷的繼續，並提供一致的毫秒級延時。

 3.2 Streaming 

對於Spark Streaming來講，當不一樣的數據來源輸入進來時，基於固定的時間間隔，會造成一系列固定不變的數據集或者事件集（例如Kafka、Flume等）。這正好和Spark RDD基於固定的數據集吻合，從每個批處理來看，空間維度的RDD依賴關係一致，不一樣的是這4個批處理輸入的數據規模和數據內容不一樣，因此生成的RDD依賴關係實例不同。

3.3 優點

列舉了Spark常見優點，以下所示：

• 支持Lambda，且在Spark中無償使用
• 高吞吐量，適用於不須要子延時的用例
• 容錯性，默認使用微批處理
• 高度抽象的API
• 社區活躍度高
• 支持Exactly Once

3.4 限制

另外，Spark也有它不足的地方，以下所示：

• 不是真正意義上的實時計算，不可以知足低延時需求
• 須要調整的參數太多，很難作到全面
• 在許多高級功能中落後於Flink

4.Flink

Flink也是來自Spark相似的學術背景，Spark來自加州大學伯克利分校，Flink來自柏林大學。像Spark同樣，它也支持Lambda，但實現與Spark徹底相反。Flink本質上是一個真正的實時計算引擎，將批處理做爲有限數據流的特殊狀況。雖然兩個計算框架中的API類似，但它們在實現中沒有任何類似之處，在Flink中，Map、Filter、Reduce等各個函數實現爲長時間運行的運算符（相似於Storm中的Bolt）。

4.1 什麼是Apache Flink？

Flink是一個開源的實時計算引擎，是實時計算領域的領導者。它擁有出色的圖計算和機器學習功能，其底層支持On YARN模式，且提供了本地&分佈式模式，以及Docker&Kubernetes等容器部署。

4.2 如何使用Flink解決問題？

在低延時場景，須要實時數據，以便可以更快的檢測和解決關鍵事件。例如，在使用Flink以前，計算的基本業務指標，實現的延時時間約爲3到4小時，這意味着，若是工程師在早上10點左右檢測到業務指標變化異常，只能在下午14點左右開始排查。若是可以立馬解決，則只能在下午18左右時來驗證解決方案，這樣實現起來效率不是很高。

假如你的業務數據是基於時間序列的，那麼咱們須要使用事件時間來處理在時間窗口內對業務指標進行分組。同時，Flink也能夠很輕鬆的與存儲在Kafka和HDFS中的業務數據進行集成。另外，Flink具備良好的非功能特性，便於在生產中運行，易於與不一樣的監控後端集成（例如Graphite、Prometheus等），以及提供良好的UI界面。此外，Flink工做的快速開發週期以及簡單的執行模型使得學習曲線平穩，開發效率高。

4.3 什麼是窗口和事件時間？

Flink相比較Spark Streaming不只提供了更低的延時，並且Flink還對窗口和事件時間提供了更好的支持。

4.3.1 窗口

現實場景中，大部分的數據來源都是無界的，不少狀況下，咱們會對固定時間間隔的數據進行統計，好比每隔10秒統計一下集羣服務的QPS，此時，窗口機制可以很好的幫助咱們實現這類需求。

1. 狀況一：假設數據源分別在時間14秒，第14秒和第16秒產生消息類型K的消息（窗口大小爲10秒）。這些消息將落入窗口中，如上圖所示，在第14秒產生的前兩個消息將落入窗口1（5秒~15秒）和窗口2（10秒~20秒），第16秒產生的第三個消息將落入窗口2（10秒~10秒）和窗口3（15秒~25秒）。每一個窗口發出的最終計數分別爲（F,2）、(F,3)、(F,1)，這是一種理想的狀態。
2. 狀況二：假設其中一條消息（第14秒生產的）因爲網絡緣由到達時延時了5秒（第19秒到達），那麼此時消息在窗口的分佈如何呢？延時的消息落入到窗口2和窗口3，由於第19秒在10秒~20秒和15秒~25秒這兩個窗口。對於窗口2來講，計算沒有什麼問題（由於消息應該落入該窗口），可是它影響了窗口1和窗口3的結果。

4.3.2 事件時間

如今咱們嘗試使用事件時間來解決狀況二的延時問題。要啓用事件時間處理，須要一個時間戳提取器，從消息中提取事件時間信息。流式計算按照數據的事件時間來將數據分配到對應的窗口，而不是按照處理數據的時間，處理結果以下圖。

引入事件時間後的結果看起來更好了，窗口2和窗口3發出了正確的結果，可是窗口1仍然是錯誤的。Flink沒有將延遲的消息分配給窗口3，由於它如今檢查的是消息的事件時間了，而且理解它不在窗口中。可是爲何沒有將消息分配給窗口1呢？緣由在於延遲的消息到達系統時（第19秒），窗口1的評估已經完成了（15秒）。

4.3.3 水印

爲了達到解決狀況二的問題，達到狀況一的預期結果。引入水印機制，水印機制能夠看做是一種告訴Flink一個消息延遲多少的方式。如今將水印設置爲當前時間負5秒，告訴Flink但願消息最多有5秒的延遲，這是由於每一個窗口在水印經過時被評估。因爲設置的水印時間爲當前時間負5秒，因此窗口1（5秒~15秒）將在第20秒時被評估，以此類推，窗口2（10秒~20秒）將在第25秒時進行評估。優化後的結果以下：

最後調整引入水印機制後，獲得正確的結果，這3個窗口均按照預期的方式發出計數，即(F,2)、(F,3)、(F,1)。

5.總結（Flink VS Spark）

瞭解了Flink和Spark各自的特色後，知道了Spark Streaming經過小批量的方式保證了吞吐的狀況下，同時提供了Exactly Once語義，可是不是嚴格意義上的實時，並且因爲微批處理的方式，對窗口和事件時間的支持比較有限。Flink採用分佈式快照的方式實現了一個高吞吐、低延時，而且支持Exactly Once的實時計算引擎，同時Flink的實時計算引擎也能更好支持窗口和事件時間。

經過對Flink和Spark特色的掌握，再結合實際的項目需求、業務場景、以及技術儲備，來選取最適合的計算引擎。

6.結束語

這篇博客就和你們分享到這裏，若是你們在研究學習的過程中有什麼問題，能夠加羣進行討論或發送郵件給我，我會盡我所能爲您解答，與君共勉！

另外，博主出書了《Kafka並不難學》和《Hadoop大數據挖掘從入門到進階實戰》，喜歡的朋友或同窗， 能夠在公告欄那裏點擊購買連接購買博主的書進行學習，在此感謝你們的支持。關注下面公衆號，根據提示，可免費獲取書籍的教學視頻。

原文出處：https://www.cnblogs.com/smartloli/p/10963221.html