基于Kafka的實時計算引擎如何選擇？

老碼農(nóng)來回答這個問題。

Kafka

kafka 是linkedin開源的一款開源的分布式mq消息中間件，現(xiàn)在已經(jīng)捐獻給apache軟件基金會（ASF）。具有吞吐量大，低延時，容錯性高，擴展性好的特點。在大型數(shù)據(jù)處理中常扮演數(shù)據(jù)管道的角色。也就是數(shù)據(jù)在中轉(zhuǎn)，傳輸中起到一個管道的作用，類似于水管但是還可以起到緩沖作用。數(shù)據(jù)流過大也能有效的對數(shù)據(jù)進行傳輸。我們項目的日志管道就是Kafka。

實時計算

聊完kafka再聊一下什么是實時計算。實時計算是基于海量數(shù)據(jù)，進行秒級響應，實時入庫，實時分析處理數(shù)據(jù)的一種大數(shù)據(jù)計算方式。要求時效性高，常用于網(wǎng)站流量分析、股市分析、天氣氣候分析等需要實時處理的業(yè)務場景。打個比方，就是有PB級別數(shù)據(jù)不斷傳遞過來，需要立馬處理入庫分析。與此對應的是離線計算。這些通常是不需要立即處理，我先存起來，慢慢進行分析，或者用到的時候我再分析。說到實時計算，就不能不提流式計算，其實兩者沒有必然關(guān)系。實時強調(diào)實時性，流式是一種模型，從一個方向流向其他方向，而且某個點的流處理一次就沒了，而且設計是無界的，源源不斷。把數(shù)據(jù)想象成水管里的水就會很好理解這個概念，打開水龍頭源源不斷流出來。從技術(shù)選型來說目前 有Storm、 apache spark 和apache flink 。

storm 是一個專注實時處理的流式數(shù)據(jù)處理引擎。推特開源。但是因為對數(shù)據(jù)是行級別處理以及容錯。所以效率不高，適合對實時性要求高，數(shù)據(jù)集不算太大的情況下使用。spark 是一個高效率、易用性強、通用性強，兼容性好的數(shù)據(jù)處理引擎。 比Hadoop 要快很多，Spark支持Java、Python和Scala的API，還支持超過幾十種高級算法，用戶可以快速構(gòu)建不同的應用 。目前業(yè)界用的也最多。方案成熟，資料也非常全。基本一線大廠都有spark海量數(shù)據(jù)處理平臺。但是spark 默認走的是批處理。數(shù)據(jù)是一批一批處理離線計算的。但是通過 spark stream 流式處理的擴展。使得spark也能進行實時的數(shù)據(jù)計算，但是底層還是批處理，通過固定的offset偏移量進行實時流式批處理。flink 是大數(shù)據(jù)處理的一顆新星。核心是一個流式的數(shù)據(jù)流執(zhí)行引擎，其針對數(shù)據(jù)流的分布式計算提供了數(shù)據(jù)分布、數(shù)據(jù)通信以及容錯機制等功能?；诹鲌?zhí)行引擎，F(xiàn)link提供了諸多更高抽象層的API以便用戶編寫分布式任務。實現(xiàn)FaaS（函數(shù)即服務）是真正意義上的實時計算引擎。目前也是最先進的。但是才火起來。除了一線大廠，小廠是目前是很難玩轉(zhuǎn)的。而且目前資料比較少，還可能有一些坑要踩。但是這些遮擋不了flink的光芒。目前社區(qū)十分活躍，而且阿里有魔改版本Blink。常遠來看更有前途。

總結(jié)

通過上面的介紹結(jié)合自己的業(yè)務場景以及團隊技術(shù)層次應該心中有答案了。個人看好flink。你有不同的觀點可以留言討論