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

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

說起實(shí)時(shí)計(jì)算善榛，可能會(huì)說到流式計(jì)算，那么流式和實(shí)時(shí)是否等價(jià)呻畸？嚴(yán)格意義上講移盆，它們沒有必然的聯(lián)系。實(shí)時(shí)計(jì)算代表的是處理數(shù)據(jù)耗時(shí)情況伤为，而流式計(jì)算代表的是處理數(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í)的無界數(shù)據(jù)。

流處理的特點(diǎn)

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

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

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

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

流式處理的場景使用場景

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

業(yè)務(wù)流程監(jiān)控：業(yè)務(wù)流程涉及特定域中的多個(gè)事件烦绳。例如，在電子商務(wù)業(yè)務(wù)中配紫，從下單径密、支付、出庫躺孝、送貨享扔、再到用戶簽收的所有事件都可以被視為一個(gè)業(yè)務(wù)流程底桂。流處理可用于監(jiān)控此類流程的異常情況，例如在時(shí)間范圍內(nèi)為完成惧眠、交付商品時(shí)出錯(cuò)等籽懦。

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

Spark

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

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

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

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

Streaming

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

Spark的優(yōu)勢

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

高吞吐量看蚜，適用于不需要子延時(shí)的用例

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

高度抽象的API

社區(qū)活躍度高

支持Exactly Once

Spark的不足

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

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

在許多高級(jí)功能中落后于Flink

Flink

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

如何使用 Flink 解決問題

在低延時(shí)場景，需要實(shí)時(shí)數(shù)據(jù)咪惠，以便能夠更快的檢測和解決關(guān)鍵事件击吱。例如，在使用 Flink之前遥昧，計(jì)算的基本業(yè)務(wù)指標(biāo)覆醇，實(shí)現(xiàn)的延時(shí)時(shí)間約為3到4小時(shí)，這意味著炭臭，如果工程師在早上 10點(diǎn)左右檢測到業(yè)務(wù)指標(biāo)變化異常永脓，只能在下午 14 點(diǎn)左右開始排查。如果能夠立馬解決鞋仍，則只能在下午18左右時(shí)來驗(yàn)證解決方案常摧，這樣實(shí)現(xiàn)起來效率不是很高。假如你的業(yè)務(wù)數(shù)據(jù)是基于時(shí)間序列的威创，那么我們需要使用事件時(shí)間來處理在時(shí)間窗口內(nèi)對(duì)業(yè)務(wù)指標(biāo)進(jìn)行分組排宰。同時(shí)，F(xiàn)link 也可以很輕松的與存儲(chǔ)在 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 不僅提供了更低的延時(shí)隐岛，而且 Flink 還對(duì)窗口和事件時(shí)間提供了更好的支持猫妙。

總結(jié)

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

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