Spark Streaming與Storm

Spark Streaming處於Spark生態技術棧中，能夠和Spark Core和Spark SQL無縫整合；而Storm相對來講比較單一；

（一）概述

• Spark Streaming

　　　　Spark Streaming是Spark的核心API的一個擴展，能夠實現高吞吐量、具備容錯機制的實時流數據的處理。支持從多種數據源獲取數據，包括kafka、Flume、Twitter、ZeroMQ以及TCP等，從數據獲取以後，可使用諸如map、reduce、join、window等高級函數進行復雜算法處理。最後還能夠將處理結果存儲到文件系統，數據庫；還可使用Spark的其餘子框架，如圖計算等，對流數據進行處理。

　　　　Spark Streaming在內部的處理機制是，就收實時流的數據，並根據必定的時間間隔拆分紅一批批的數據，而後處理這些批數據，最終獲得處理後的一批結果數據。對應的批數據（batch data），在Spark內核對應一個RDD實例，所以，對流數據DStream能夠當作是一組RDDs。

　　　　執行流程（Receiver模式）：

　　　　

　　　　　　提升並行度：receiver task會每隔200ms block.interval將接受來的數據分裝到block中，調整block.interval的值；

　　　　　　　　　　　　啓用多個receiver進程來並行接受數據；

　　　　　　對於Direct模式提升並行度的方式只需增長kafka partition的數量；Director模式，消費者偏移量由spark本身管理，存在checkpoint目錄中

•  Storm

　　　　

　　　　storm採用Master/Slave體系結構

　　　　　　nimbus：該進程運行在集羣的主節點上，負責任務的指派和分發

　　　　　　supervisor：運行在集羣的從節點上，負責執行任務的具體部分

　　　　　　zookeeper：幫助主從作到解耦，存儲集羣資源元數據，當storm把元數據信息都存到zk中後，那storm本身就作到了無狀態，提交Topology應用的時候纔會用到nimbus；

　　　　　　worker：運行處理具體組件邏輯進程，worker之間經過netty傳送數據

　　　　　　task：worker中每一個spout/bolt的線程稱爲一個task，同一個spout/bolt的task可能會共享一個物理進程，該線程爲executor

　　　　

　　　　以上由spout和bolt組成的圖叫作topologies，上層的spout或者bolt向下層的Bolt來發射數據的時候，默認狀況下都是default stream

 　　　   storm經常使用的分發策略一共有5種，最經常使用的是Shuffle grouping和Fields grouping

　　　　storm中的ack機制：說白了就是storm經過Acker組件去數數，數Tuple tree裏面的Tuple是否都已經確認過，每一個Tuple Tree對應一個msgId

 　　　　提升並行度：

　　　　　　增長worker數量；增長Executor數量；設置task數量，默認一個線程裏面跑一個task

　　　　Storm實現可靠的消息保障機制：

　　

　　　　Tuple 的徹底處理須要 Spout、Bolt 以及 Acker（Storm 中用來記錄某棵 Tuple 樹是否被徹底處理的節點）協同完成，如上圖所示。從 Spout 發送 Tuple 到下游，並把相應信息通知給 Acker，整棵 Tuple 樹中某個 Tuple 被成功處理了都會通知 Acker，待整棵 Tuple 樹都被處理完成以後，Acker 將成功處理信息返回給 Spout；若是某個 Tuple 處理失敗，或者超時，Acker 將會給 Spout 發送一個處理失敗的消息，Spout 根據 Acker 的返回信息以及用戶對消息保證機制的選擇判斷是否須要進行消息重傳。

 

SparkStreaming源碼分析推薦