用Spark進行實時流計算

獨孤風發表於2020-08-04
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一戰的能力。

1、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實戰電子書

相關文章