用Spark進行實時流計算

Spark Streaming VS Structured Streaming

Spark Streaming是Spark最初的流處理框架，使用了微批的形式來進行流處理。

提供了基於RDDs的Dstream API，每一個時間間隔內的數據爲一個RDD，源源不斷對RDD進行處理來實現流計算

Apache Spark 在 2016 年的時候啓動了 Structured Streaming 項目，一個基於 Spark SQL 的全新流計算引擎 Structured Streaming，讓用戶像編寫批處理程序同樣簡單地編寫高性能的流處理程序。

Structured Streaming是Spark2.0版本提出的新的實時流框架（2.0和2.1是實驗版本，從Spark2.2開始爲穩定版本)

從Spark-2.X版本後，Spark Streaming就進入維護模式，看見Spark已經將大部分精力投入到了全新的Structured Streaming中，而一些新特性也只有Structured Streaming纔有，這樣Spark纔有了與Flink一戰的能力。

一、Spark Streaming 不足

• Processing Time 而不是 Event Time

  首先解釋一下，Processing Time 是數據到達 Spark 被處理的時間，而 Event Time 是數據自帶的屬性，通常表示數據產生於數據源的時間。好比 IoT 中，傳感器在 12:00:00 產生一條數據，而後在 12:00:05 數據傳送到 Spark，那麼 Event Time 就是 12:00:00，而 Processing Time 就是 12:00:05。咱們知道 Spark Streaming 是基於 DStream 模型的 micro-batch 模式，簡單來講就是將一個微小時間段，好比說 1s，的流數據當前批數據來處理。若是咱們要統計某個時間段的一些數據統計，毫無疑問應該使用 Event Time，可是由於 Spark Streaming 的數據切割是基於 Processing Time，這樣就致使使用 Event Time 特別的困難。

• Complex, low-level api

  這點比較好理解，DStream （Spark Streaming 的數據模型）提供的 API 相似 RDD 的 API 的，很是的 low level。當咱們編寫 Spark Streaming 程序的時候，本質上就是要去構造 RDD 的 DAG 執行圖，而後經過 Spark Engine 運行。這樣致使一個問題是，DAG 可能會由於開發者的水平良莠不齊而致使執行效率上的天壤之別。這樣致使開發者的體驗很是很差，也是任何一個基礎框架不想看到的（基礎框架的口號通常都是：大家專一於本身的業務邏輯就好，其餘的交給我）。這也是不少基礎系統強調 Declarative 的一個緣由。

• reason about end-to-end application

  這裏的 end-to-end 指的是直接 input 到 out，好比 Kafka 接入 Spark Streaming 而後再導出到 HDFS 中。DStream 只能保證本身的一致性語義是 exactly-once 的，而 input 接入 Spark Streaming 和 Spark Straming 輸出到外部存儲的語義每每須要用戶本身來保證。而這個語義保證寫起來也是很是有挑戰性，好比爲了保證 output 的語義是 exactly-once 語義須要 output 的存儲系統具備冪等的特性，或者支持事務性寫入，這個對於開發者來講都不是一件容易的事情。

• 批流代碼不統一

  儘管批流本是兩套系統，可是這兩套系通通一塊兒來確實頗有必要，咱們有時候確實須要將咱們的流處理邏輯運行到批數據上面。關於這一點，最先在 2014 年 Google 提出 Dataflow 計算服務的時候就批判了 streaming/batch 這種叫法，而是提出了 unbounded/bounded data 的說法。DStream 儘管是對 RDD 的封裝，可是咱們要將 DStream 代碼徹底轉換成 RDD 仍是有一點工做量的，更況且如今 Spark 的批處理都用 DataSet/DataFrame API 了。

2.、Structured Streaming 優點

相對的，來看下Structured Streaming優點：

• 簡潔的模型。Structured Streaming 的模型很簡潔，易於理解。用戶能夠直接把一個流想象成是無限增加的表格。

• 一致的 API。因爲和 Spark SQL 共用大部分 API，對 Spaprk SQL 熟悉的用戶很容易上手，代碼也十分簡潔。同時批處理和流處理程序還能夠共用代碼，不須要開發兩套不一樣的代碼，顯著提升了開發效率。

• 卓越的性能。Structured Streaming 在與 Spark SQL 共用 API 的同時，也直接使用了 Spark SQL 的 Catalyst 優化器和 Tungsten，數據處理性能十分出色。此外，Structured Streaming 還能夠直接從將來 Spark SQL 的各類性能優化中受益。

• 多語言支持。Structured Streaming 直接支持目前 Spark SQL 支持的語言，包括 Scala，Java，Python，R 和 SQL。用戶能夠選擇本身喜歡的語言進行開發。

• 一樣能支持多種數據源的輸入和輸出，Kafka、flume、Socket、Json。

• 基於Event-Time，相比於Spark Streaming的Processing-Time更精確，更符合業務場景。

• Event time 事件時間: 就是數據真正發生的時間，好比用戶瀏覽了一個頁面可能會產生一條用戶的該時間點的瀏覽日誌。

• Process time 處理時間: 則是這條日誌數據真正到達計算框架中被處理的時間點，簡單的說，就是你的Spark程序是何時讀到這條日誌的。

• 事件時間是嵌入在數據自己中的時間。對於許多應用程序，用戶可能但願在此事件時間操做。例如，若是要獲取IoT設備每分鐘生成的事件數，則可能須要使用生成數據的時間（即數據中的事件時間），而不是Spark接收他們的時間。事件時間在此模型中很是天然地表示 - 來自設備的每一個事件都是表中的一行，事件時間是該行中的一個列值。

• 支持spark2的dataframe處理。

• 解決了Spark Streaming存在的代碼升級，DAG圖變化引發的任務失敗，沒法斷點續傳的問題。

• 基於SparkSQL構建的可擴展和容錯的流式數據處理引擎，使得實時流式數據計算能夠和離線計算採用相同的處理方式（DataFrame&SQL）。

• 可使用與靜態數據批處理計算相同的方式來表達流計算。

底層原理徹底不一樣

Spark Streaming採用微批的處理方法。每個批處理間隔的爲一個批，也就是一個RDD，咱們對RDD進行操做就能夠源源不斷的接收、處理數據。

Structured Streaming將實時數據當作被連續追加的表。流上的每一條數據都相似於將一行新數據添加到表中。

Spark 3.0.0發佈之後 全新的Structured Streaming UI誕生，可見將來的Structured Streaming將不斷迎來進步。

更多Flink，Kafka，Spark等相關技術博文，科技資訊，歡迎關注實時流式計算 公衆號後臺回覆 「電子書」 下載300頁Flink實戰電子書