Spark Streaming vs. Kafka Stream 哪個更適合你
譯者注:本文介紹了兩大常用的流式處理框架,Spark Streaming和Kafka Stream,并對他們各自的特點做了詳細說明,以幫助讀者在不同的場景下對框架進行選擇。以下是譯文。流式處理的需求每天都在增加,僅僅對大量的數(shù)據(jù)進行處理是不夠的。數(shù)據(jù)必須快速地得到處理,以便企業(yè)能夠實時地對不斷變化的業(yè)務環(huán)境做出反應。流式處理是持續(xù)而又并發(fā)地對數(shù)據(jù)進行實時處理。流式處理是處理數(shù)據(jù)流或傳感器數(shù)據(jù)的理想平臺,而“復雜事件處理”(CEP)則利用了逐個事件處理和聚合等技術。對于實時數(shù)據(jù)處理功能,我們有很多選擇可以來實現(xiàn),比如Spark、Kafka Stream、Flink、Storm等。在這個博客中,我將討論Apache Spark和Kafka Stream的區(qū)別。
Apache Spark
Apache Spark是大規(guī)模數(shù)據(jù)處理的通用框架,支持多種不同的編程語言和概念,例如MapReduce、內存處理、流式處理、圖形處理和機器學習。它也可以用于Hadoop的頂層。數(shù)據(jù)可以從多種來源(例如Kafka、Flume、Kinesis或TCP套接字)獲取,并且使用一些復雜的算法(高級功能,例如映射、歸約、連接和窗口等)對數(shù)據(jù)進行處理。
在框架內部,它的工作原理如下圖。 Spark Streaming接收實時輸入數(shù)據(jù)流,并將數(shù)據(jù)分成多個批次,然后由Spark引擎對其進行處理,批量生成最終的結果流。
Spark Streaming提供了一個被稱為離散化數(shù)據(jù)流(discretized stream,縮寫為DStream)的高級抽象,它代表了一個持續(xù)的數(shù)據(jù)流。DStream可以從諸如Kafka、Flume或Kinesis等來源的輸入數(shù)據(jù)流中創(chuàng)建,或者通過對其他DStream執(zhí)行高級操作來創(chuàng)建。在框架內部,DStream可以看成是一系列的RDD(Resilient Distributed Datasets,彈性分布式數(shù)據(jù)集)。
Kafka Stream
Kafka Streams是一個用于處理和分析數(shù)據(jù)的客戶端庫。它先把存儲在Kafka中的數(shù)據(jù)進行處理和分析,然后將最終所得的數(shù)據(jù)結果回寫到Kafka或發(fā)送到外部系統(tǒng)去。它建立在一些非常重要的流式處理概念之上,例如適當區(qū)分事件時間和處理時間、窗口支持,以及應用程序狀態(tài)的簡單(高效)管理。同時,它也基于Kafka中的許多概念,例如通過劃分主題進行擴展。此外,由于這個原因,它作為一個輕量級的庫可以集成到應用程序中去。這個應用程序可以根據(jù)需要獨立運行、在應用程序服務器中運行、作為Docker容器,或通過資源管理器(如Mesos)進行操作。
Kafka Streams直接解決了流式處理中的很多困難問題:
- 毫秒級延遲的逐個事件處理。
- 有狀態(tài)的處理,包括分布式連接和聚合。
- 方便的DSL。
- 使用類似DataFlow的模型對無序數(shù)據(jù)進行窗口化。
- 具有快速故障切換的分布式處理和容錯能力。
- 無停機滾動部署。
Apache Spark可以與Kafka一起使用來傳輸數(shù)據(jù),但是如果你正在為新應用程序部署一個Spark集群,這絕對是一個復雜的大問題。
為了克服這個復雜性,我們可以使用完整的流式處理框架,Kafka streams正是實現(xiàn)這個目的的***選擇。
我們的目標是簡化流式處理,使之成為異步服務的主流應用程序編程模型。這是我知道的***個庫,它充分利用了Kafka,而不僅僅把Kafka當做是一個信息中介。
Streams建立在KTables和KStreams的概念之上,這有助于他們提供事件時間處理。
給出一個與Kafka的核心抽象高度集成的處理模型,能夠減少流式架構中移動件的總數(shù)。
將狀態(tài)表與事件流完全整合起來,并在單個概念框架中提供這兩個東西,這使得Kafka Streams完全成為一個嵌入式的庫,而不是流式處理集群(只是Kafka和你的應用程序)。當你向應用程序加入了一個新的實例,或者現(xiàn)有的實例發(fā)生崩潰的時候,它能夠自動均衡負載,并維護表的本地狀態(tài),使得系統(tǒng)能夠從故障中恢復出來。
Kafka Streams具備低延遲的特點,并且支持易于使用的事件時間。它是一個非常重要的庫,非常適合某些類型的任務。這也是為什么一些設計可以針對Kafka的工作原理進行深入地優(yōu)化的原因。你不需要設置任何種類的Kafka Streams集群,也沒有集群管理器。如果你需要實現(xiàn)一個簡單的Kafka的主題到主題的轉換、通過關鍵字對元素進行計數(shù)、將另一個主題的數(shù)據(jù)加載到流上,或者運行聚合或只執(zhí)行實時處理,那么Kafka Streams適合于你。
如果事件時間不相關,并且秒級的延遲可以接受,那么Spark是你的***選擇。它相當穩(wěn)定,并且可以很容易地集成到幾乎任何類型的系統(tǒng)中去。此外,每個Hadoop發(fā)行版都包含它。而且,用于批處理應用程序的代碼也可以用于流式應用程序,因為API是相同的。
結論
我認為,Kafka Streams最適用于“Kafka > Kafka”場景,而Spark Streaming可用于“Kafka > 數(shù)據(jù)庫”或“Kafka > 數(shù)據(jù)科學模型“這樣的場景。