Spark Streaming 對比 JStorm

001Spark Streaming vs JStorm

攜程實時平臺在接入Spark Streaming之前，JStorm已穩定運行有一年半，基本能夠滿足大部分的應用場景。接入Spark Streaming主要有以下幾點考慮：首先攜程使用的JStorm版本為2.1.1版本，此版本的JStorm封裝與抽象程度較低，並沒有提供High Level抽象方法以及對窗口、狀態和Sql等方面的功能支持，這大大的提高了用戶使用JStorm實現實時應用的門檻以及開發複雜實時應用場景的難度。在這幾個方面，Spark Streaming表現就相對好的多，不但提供了高度集成的抽象方法（各種算子），並且用戶還可以與Spark SQL相結合直接使用SQL處理數據。

其次，用戶在處理數據的過程中往往需要維護兩套數據處理邏輯，實時計算使用JStorm，離線計算使用Hive或Spark。為了降低開發和維護成本，實現流式與離線計算引擎的統一，Spark為此提供了良好的支撐。

最後，在引入Spark Streaming之前，我們重點分析了Spark與Flink兩套技術的引入成本。Flink當時的版本為1.2版本，Spark的版本為2.0.1。相比較於Spark，Flink在SQL與MLlib上的支持相對弱於Spark，並且公司許多部門都是基於Spark SQL與MLlib開發離線任務與算法模型，使得大大降低了用戶使用Spark的學習成本。

下圖簡單的給出了當前我們使用Spark Streaming與JStorm的對比：

002Spark Streaming設計與封裝

在接入Spark Streaming的初期，首先需要考慮的是如何基於現有的實時平臺無縫的嵌入Spark Streaming。原先的實時平臺已經包含了許多功能：元數據管理、監控與告警等功能，所以第一步我們先針對Spark Streaming進行了封裝並提供了豐富的功能。整套體系總共包含了Muise Spark Core、Muise Portal以及外部系統。

003Muise Spark Core

Muise Spark Core是我們基於Spark Streaming實現的二次封裝，用於支持攜程多種消息隊列，其中Hermes Kafka與源生的Kafka基於Direct Approach的方式消費數據，Hermes Mysql與Qmq基於Receiver的方式消費數據。接下來將要講的諸多特性主要是針對Kafka類型的數據源。

Muise spark core主要包含了以下特性：

Kafka Offset自動管理

支持Exactly Once與At Least Once語義

提供Metric註冊系統，用戶可註冊自定義metric

基於系統與用戶自定義metric進行預警

Long running on Yarn，提供容錯機制

004

Kafka Offset自動管理

封裝muise spark core的第一目標就是簡單易用，讓用戶以最簡單的方式能夠上手使用Spark Streaming。首先我們實現了幫助用戶自動讀取與存儲Kafka Offset的功能，用戶無需關心Offset是如何被處理的。

其次我們也對Kafka Offset的有效性進行了校驗，有的用戶的作業可能在停止了較長時間後重新運行會出現Offset失效的情形，我們也對此作了對應的操作，目前的操作是將失效的Offset設置為當前有效的最老的Offset。下圖展現了用戶基於muise spark core編寫一個Spark streaming作業的簡單示例，用戶只需要短短幾行代碼即可完成代碼的初始化並創建好對應的DStream：

默認情況下，作業每次都是基於上次存儲的Kafka Offset繼續消費，但是用戶也可以自行決定Offset的消費起點。下圖中展示了設置消費起點的三種方式:

Tips：

以後我都固定每天17:40更新文章了（節假日加班時間除外），記得每天來看哈