原文連結：https://blog.csdn.net/D55dffdh/article/details/82423831

Spark Streaming 支援實時資料流的可擴充套件(Scalable)、高吞吐(high-throughput)、容錯(fault-tolerant)的流處理(stream processing)。

 

 

架構圖

特性如下：

• 可線性伸縮至超過數百個節點;

• 實現亞秒級延遲處理;

• 可與 Spark 批處理和互動式處理無縫整合;

• 提供簡單的API實現複雜演算法;

• 更多的流方式支援，包括 Kafka、Flume、Kinesis、Twitter、ZeroMQ 等。

001、原理

Spark 在接收到實時輸入資料流後，將資料劃分成批次(divides the data into batches)，然後轉給 Spark Engine 處理，按批次生成最後的結果流(generate the final stream of results in batches)。

 

 

002、API

DStream：

DStream(Discretized Stream，離散流)是 Spark Stream 提供的高階抽象連續資料流。

組成：一個 DStream 可看作一個 RDDs 序列。

核心思想：將計算作為一系列較小時間間隔的、狀態無關的、確定批次的任務，每個時間間隔內接收的輸入資料被可靠儲存在叢集中，作為一個輸入資料集。

 

 

特性：一個高層次的函數語言程式設計 API、強一致性以及高校的故障恢復。

應用程式模板：

模板1

 

 

模板2

 

 

WordCount示例

 

 

Input DStream：

Input DStream 是一種從流式資料來源獲取原始資料流的 DStream，分為基本輸入源(檔案系統、Socket、Akka Actor、自定義資料來源)和高階輸入源(Kafka、Flume等)。

Receiver：

每個 Input DStream(檔案流除外)都會對應一個單一的 Receiver物件，負責從資料來源接收資料並存入 Spark 記憶體進行處理。應用程式中可建立多個 Input DStream 並行接收多個數據流。

每個 Receiver 是一個長期執行在Worker或者 Executor 上的 Task，所以會佔用該應用程式的一個核(core)。如果分配給 Spark Streaming 應用程式的核數小於或等於 Input DStream 個數(即Receiver個數)，則只能接收資料，卻沒有能力全部處理(檔案流除外，因為無需Receiver)。

Spark Streaming 已封裝各種資料來源，需要時參考官方文件。

Transformation Operation

常用Transformation

 

 

updateStateByKey(func)

updateStateByKey可對DStream中的資料按key做reduce，然後對各批次資料累加

WordCount的updateStateByKey版本

 

 

transform(func)

通過對原 DStream 的每個 RDD 應用轉換函式，建立一個新的 DStream。

官方文件程式碼舉例

 

 

Window operations

視窗操作：基於 window 對資料 transformation(個人認為與Storm的tick相似，但功能更強大)。

引數：視窗長度(window length)和滑動時間間隔(slide interval)必須是源DStream 批次間隔的倍數。

舉例說明：視窗長度為3，滑動時間間隔為2;上一行是原始 DStream，下一行是視窗化的 DStream。

 

 

常見 window operation

 

 

 

官方文件程式碼舉例

 

 

join(otherStream, [numTasks])

連線資料流

官方文件程式碼舉例1

 

 

官方文件程式碼舉例2

 

 

Output Operation

 

 

快取與持久化：

通過 persist()將 DStream 中每個 RDD 儲存在記憶體。

Window operations 會自動持久化在記憶體，無需顯示呼叫 persist()。

通過網路接收的資料流(如Kafka、Flume、Socket、ZeroMQ、RocketMQ等)執行 persist()時，預設在兩個節點上持久化序列化後的資料，實現容錯。

Checkpoint：

用途：Spark 基於容錯儲存系統(如HDFS、S3)進行故障恢復。

分類：

元資料檢查點：儲存流式計算資訊用於 Driver 執行節點的故障恢復，包括建立應用程式的配置、應用程式定義的 DStream operations、已入隊但未完成的批次。

資料檢查點：儲存生成的 RDD。由於 stateful transformation 需要合併多個批次的資料，即生成的 RDD 依賴於前幾個批次 RDD 的資料(dependency chain)，為縮短 dependency chain 從而減少故障恢復時間，需將中間 RDD 定期儲存至可靠儲存(如HDFS)。

使用時機：

Stateful transformation：updateStateByKey()以及 window operations。

需要 Driver 故障恢復的應用程式。

003、使用方法

Stateful transformation

 

 

需要 Driver 故障恢復的應用程式(以WordCount舉例)：如果 checkpoint 目錄存在，則根據 checkpoint 資料建立新 StreamingContext;否則(如首次執行)新建 StreamingContext。

 

 

checkpoint 時間間隔

方法：

 

 

原則：一般設定為滑動時間間隔的5-10倍。

分析：checkpoint 會增加儲存開銷、增加批次處理時間。當批次間隔較小(如1秒)時，checkpoint 可能會減小 operation 吞吐量;反之，checkpoint 時間間隔較大會導致 lineage 和 task 數量增長。