根據(jù) IBM 的統(tǒng)計報告顯示，過去兩年內(nèi)，當(dāng)今世界上90%的數(shù)據(jù)產(chǎn)生源于新設(shè)備、傳感器以及技術(shù)的出現(xiàn)，數(shù)據(jù)增長率也會為此加速。而從技術(shù)上將，這意味著大數(shù)據(jù)領(lǐng)域，處理這些數(shù)據(jù)將變得更加復(fù)雜和具有挑戰(zhàn)性。例如移動應(yīng)用廣告、欺詐檢測、出租車預(yù)訂、患者監(jiān)控等場景處理時，需要對實(shí)時數(shù)據(jù)進(jìn)行實(shí)時處理，以便做出快速可行的決策。

目前業(yè)界有開源不少實(shí)時計算引擎，以 Apache 基金會的兩款開源實(shí)時計算引擎最受歡迎，它們分別是 Apache Spark 和 Apache Flink 。接下來，我們來聊一聊它們的使用場景、優(yōu)勢、局限性、相似性、以及差異性。方便大家在做技術(shù)選型時，選擇切合項(xiàng)目場景的實(shí)時計算引擎。

說起實(shí)時計算，可能會說到流式計算，那么流式和實(shí)時是否等價？嚴(yán)格意義上講，它們沒有必然的聯(lián)系。實(shí)時計算代表的是處理數(shù)據(jù)耗時情況，而流式計算代表的是處理數(shù)據(jù)的一種方式。

流式處理

首先，它是一種數(shù)據(jù)處理引擎，其設(shè)計時考慮了無邊界的數(shù)據(jù)集。其次，它與批處理不同，批處理的 Job 與數(shù)據(jù)的起點(diǎn)和終點(diǎn)有關(guān)系，并且 Job 在處理完有限數(shù)據(jù)后結(jié)束，而流式處理用于處理連續(xù)數(shù)天、數(shù)月、數(shù)年、或是永久實(shí)時的無界數(shù)據(jù)。

流處理的特點(diǎn)

容錯性：如果節(jié)點(diǎn)出現(xiàn)故障，流式處理系統(tǒng)應(yīng)該能夠恢復(fù)，并且應(yīng)該從它離開的位置再次開始處理；

狀態(tài)管理：在有狀態(tài)處理要求的情況下，流式處理系統(tǒng)應(yīng)該能夠提供一些機(jī)制來保存和更新狀態(tài)信息；

性能：延時應(yīng)盡可能的小，吞吐量應(yīng)盡可能的大；

高級功能：事件時間處理，窗口等功能，這些均是流式處理在處理復(fù)雜需求時所需要的功能。流式處理可以分析連續(xù)的數(shù)據(jù)流，在這種方式中，數(shù)據(jù)被視為連續(xù)流，處理引擎在很短的時間內(nèi) ( 幾毫米到幾分鐘 ) 內(nèi)取數(shù)、分析、以及響應(yīng)。

流式處理的場景使用場景

異常檢測：流式處理可以應(yīng)用于連續(xù)的數(shù)據(jù)流并近乎實(shí)時的檢測異常。例如，在金融交易數(shù)據(jù)中，欺詐性交易可以被視為異常，流式處理可以檢測到這些，保護(hù)銀行和客戶免受財務(wù)損失。

業(yè)務(wù)流程監(jiān)控：業(yè)務(wù)流程涉及特定域中的多個事件。例如，在電子商務(wù)業(yè)務(wù)中，從下單、支付、出庫、送貨、再到用戶簽收的所有事件都可以被視為一個業(yè)務(wù)流程。流處理可用于監(jiān)控此類流程的異常情況，例如在時間范圍內(nèi)為完成、交付商品時出錯等。

告警：流式處理可用于根據(jù)指定規(guī)則觸發(fā)告警，滿足特定條件，可以實(shí)時將告警發(fā)送到不同的目標(biāo)。

Spark

Spark 已成為批處理中 Hadoop 的真正繼承者，也是第一個完美支持 Lambda 架構(gòu)的框架。 Spark 受歡迎度極高，成熟并且廣泛使用。 Spark 免費(fèi)提供 SparkStreaming，它使用微批處理進(jìn)行流式傳輸。在 Spark2.0 之后，添加了許多優(yōu)秀的功能 ( 例如對tungsten、watermarks、event time 處理的支持 ) ，同時結(jié)構(gòu)化流也更加抽象，截止本篇博客 Spark 發(fā)布的可用版本為2.4.3，可以在最新版本中在微批處理和連續(xù)流模式之間進(jìn)行切換。

微批處理 & 連續(xù)流處理

結(jié)構(gòu)化流式傳輸默認(rèn)采用微批處理執(zhí)行，Spark 流式計算引擎會定時檢查流數(shù)據(jù)。在連續(xù)流處理中，Spark 不會啟動定時任務(wù)，而是啟動一組長時間運(yùn)行的任務(wù)，這些任務(wù)可以連續(xù)讀取、處理、寫入數(shù)據(jù)。

微批處理中，驅(qū)動程序通過將記錄 Offset 保存到預(yù)寫 Log 來檢測進(jìn)度，然后可以使用該 Log 重新進(jìn)行查詢。需要注意的是，在微批處理處理開始之前，需要在下一個微批處理中處理的范圍 Offset 保存到 Log 中，以便獲取確定性的重新執(zhí)行和端到端語義。因此，源記錄可能需要等待當(dāng)前的微批處理處理完成，然后記錄其 Offset 。連續(xù)流處理中，通過完善和改進(jìn)算法來檢測查詢進(jìn)度，特殊標(biāo)記的記錄被寫入到每個任務(wù)的輸入數(shù)據(jù)流中。當(dāng)任務(wù)遇到標(biāo)記時，任務(wù)會異步報告處理的最后一個 Offset ，一旦驅(qū)動程序收到寫入接收器的所有任務(wù)的 Offset ，它就會將它們寫入預(yù)寫 Log 中。由于 Checkpoint 完全異步，因此任務(wù)可以不間斷的繼續(xù)，并提供一致的毫秒級延時。

Streaming

對于 Spark Streaming 來說，當(dāng)不同的數(shù)據(jù)來源輸入進(jìn)來時，基于固定的時間間隔，會形成一系列固定不變的數(shù)據(jù)集或者事件集 ( 例如 Kafka、Flume 等 ) 。這正好和SparkRDD 基于固定的數(shù)據(jù)集吻合，從每一個批處理來看，空間維度的 RDD 依賴關(guān)系一致，不同的是這4個批處理輸入的數(shù)據(jù)規(guī)模和數(shù)據(jù)內(nèi)容不同，所以生成的 RDD 依賴關(guān)系實(shí)例不一樣。

Spark的優(yōu)勢

支持 Lambda，且在 Spark 中免費(fèi)使用

高吞吐量，適用于不需要子延時的用例

容錯性，默認(rèn)使用微批處理

高度抽象的API

社區(qū)活躍度高

支持Exactly Once

Spark的不足

不是真正意義上的實(shí)時計算，不能夠滿足低延時需求

需要調(diào)整的參數(shù)太多，很難做到全面

在許多高級功能中落后于Flink

Flink

Flink 是一個開源的實(shí)時計算引擎，是實(shí)時計算領(lǐng)域的領(lǐng)導(dǎo)者。它擁有出色的圖計算和機(jī)器學(xué)習(xí)功能，其底層支持 On YARN 模式，且提供了本地 & 分布式模式，以及Docker & Kubernetes 等容器部署。像Spark一樣，它也支持 Lambda ，但實(shí)現(xiàn)與 Spark 完全相反。Flink本質(zhì)上是一個真正的實(shí)時計算引擎，將批處理作為有限數(shù)據(jù)流的特殊情況。雖然兩個計算框架中的 API 相似，但它們在實(shí)現(xiàn)中沒有任何相似之處，在 Flink 中，Map、 Filter、Reduce 等各個函數(shù)實(shí)現(xiàn)為長時間運(yùn)行的運(yùn)算符 ( 類似于 Storm 中的Bolt ) 。

如何使用 Flink 解決問題

在低延時場景，需要實(shí)時數(shù)據(jù)，以便能夠更快的檢測和解決關(guān)鍵事件。例如，在使用 Flink之前，計算的基本業(yè)務(wù)指標(biāo)，實(shí)現(xiàn)的延時時間約為3到4小時，這意味著，如果工程師在早上 10點(diǎn)左右檢測到業(yè)務(wù)指標(biāo)變化異常，只能在下午 14 點(diǎn)左右開始排查。如果能夠立馬解決，則只能在下午18左右時來驗(yàn)證解決方案，這樣實(shí)現(xiàn)起來效率不是很高。假如你的業(yè)務(wù)數(shù)據(jù)是基于時間序列的，那么我們需要使用事件時間來處理在時間窗口內(nèi)對業(yè)務(wù)指標(biāo)進(jìn)行分組。同時，F(xiàn)link 也可以很輕松的與存儲在 Kafka 和 HDFS 中的業(yè)務(wù)數(shù)據(jù)進(jìn)行集成。另外Flink具有良好的非功能特性，便于在生產(chǎn)中運(yùn)行，易于與不同的監(jiān)控后端集成 ( 例如 Graphite、Prometheus 等 ) ，以及提供良好的 UI 界面。此外，F(xiàn)link 工作的快速開發(fā)周期以及簡單的執(zhí)行模型使得學(xué)習(xí)曲線平穩(wěn)，開發(fā)效率高。Flink 相比較 SparkStreaming 不僅提供了更低的延時，而且 Flink 還對窗口和事件時間提供了更好的支持。

總結(jié)

SparkStreaming 通過小批量的方式保證了吞吐的情況下，同時提供了 ExactlyOnce 語義，但是不是嚴(yán)格意義上的實(shí)時，而且由于微批處理的方式，對窗口和事件時間的支持比較有限。Flink 采用分布式快照的方式實(shí)現(xiàn)了一個高吞吐、低延時，并且支持 ExactlyOnce 的實(shí)時計算引擎，同時 Flink的實(shí)時計算引擎也能更好支持窗口和事件時間。

在某些場景下Flink確實(shí)優(yōu)于Spark，但完全替代是不可能的，沒有最好的技術(shù)只有最合適的技術(shù)，現(xiàn)實(shí)中往往需要結(jié)合實(shí)際的項(xiàng)目需求、業(yè)務(wù)場景、以及技術(shù)儲備來選取最適合的計算引擎。2790264852歡迎用CDH的小伙伴來找我玩