共計(jì) 2946 個(gè)字符，預(yù)計(jì)需要花費(fèi) 8 分鐘才能閱讀完成。

這期內(nèi)容當(dāng)中丸趣 TV 小編將會(huì)給大家?guī)碛嘘P(guān)怎樣用 Spark 進(jìn)行實(shí)時(shí)流計(jì)算，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Spark Streaming VS Structured Streaming

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

提供了基于 RDDs 的 Dstream API，每個(gè)時(shí)間間隔內(nèi)的數(shù)據(jù)為一個(gè) RDD，源源不斷對(duì) RDD 進(jìn)行處理來實(shí)現(xiàn)流計(jì)算

Apache Spark 在 2016 年的時(shí)候啟動(dòng)了 Structured Streaming 項(xiàng)目，一個(gè)基于 Spark SQL 的全新流計(jì)算引擎 Structured Streaming，讓用戶像編寫批處理程序一樣簡(jiǎn)單地編寫高性能的流處理程序。

Structured Streaming 是 Spark2.0 版本提出的新的實(shí)時(shí)流框架（2.0 和 2.1 是實(shí)驗(yàn)版本，從 Spark2.2 開始為穩(wěn)定版本 )

從 Spark-2.X 版本后，Spark Streaming 就進(jìn)入維護(hù)模式，看見 Spark 已經(jīng)將大部分精力投入到了全新的 Structured Streaming 中，而一些新特性也只有 Structured Streaming 才有，這樣 Spark 才有了與 Flink 一戰(zhàn)的能力。

1、Spark Streaming 不足

Processing Time 而不是 Event Time

首先解釋一下，Processing Time 是數(shù)據(jù)到達(dá) Spark 被處理的時(shí)間，而 Event Time 是數(shù)據(jù)自帶的屬性，一般表示數(shù)據(jù)產(chǎn)生于數(shù)據(jù)源的時(shí)間。比如 IoT 中，傳感器在 12:00:00 產(chǎn)生一條數(shù)據(jù)，然后在 12:00:05 數(shù)據(jù)傳送到 Spark，那么 Event Time 就是 12:00:00，而 Processing Time 就是 12:00:05。我們知道 Spark Streaming 是基于 DStream 模型的 micro-batch 模式，簡(jiǎn)單來說就是將一個(gè)微小時(shí)間段，比如說 1s，的流數(shù)據(jù)當(dāng)前批數(shù)據(jù)來處理。如果我們要統(tǒng)計(jì)某個(gè)時(shí)間段的一些數(shù)據(jù)統(tǒng)計(jì)，毫無疑問應(yīng)該使用 Event Time，但是因?yàn)?Spark Streaming 的數(shù)據(jù)切割是基于 Processing Time，這樣就導(dǎo)致使用 Event Time 特別的困難。

Complex, low-level api

這點(diǎn)比較好理解，DStream（Spark Streaming 的數(shù)據(jù)模型）提供的 API 類似 RDD 的 API 的，非常的 low level。當(dāng)我們編寫 Spark Streaming 程序的時(shí)候，本質(zhì)上就是要去構(gòu)造 RDD 的 DAG 執(zhí)行圖，然后通過 Spark Engine 運(yùn)行。這樣導(dǎo)致一個(gè)問題是，DAG 可能會(huì)因?yàn)殚_發(fā)者的水平參差不齊而導(dǎo)致執(zhí)行效率上的天壤之別。這樣導(dǎo)致開發(fā)者的體驗(yàn)非常不好，也是任何一個(gè)基礎(chǔ)框架不想看到的（基礎(chǔ)框架的口號(hào)一般都是：你們專注于自己的業(yè)務(wù)邏輯就好，其他的交給我）。這也是很多基礎(chǔ)系統(tǒng)強(qiáng)調(diào) Declarative 的一個(gè)原因。

reason about end-to-end application

這里的 end-to-end 指的是直接 input 到 out，比如 Kafka 接入 Spark Streaming 然后再導(dǎo)出到 HDFS 中。DStream 只能保證自己的一致性語義是 exactly-once 的，而 input 接入 Spark Streaming 和 Spark Straming 輸出到外部存儲(chǔ)的語義往往需要用戶自己來保證。而這個(gè)語義保證寫起來也是非常有挑戰(zhàn)性，比如為了保證 output 的語義是 exactly-once 語義需要 output 的存儲(chǔ)系統(tǒng)具有冪等的特性，或者支持事務(wù)性寫入，這個(gè)對(duì)于開發(fā)者來說都不是一件容易的事情。

批流代碼不統(tǒng)一

盡管批流本是兩套系統(tǒng)，但是這兩套系統(tǒng)統(tǒng)一起來確實(shí)很有必要，我們有時(shí)候確實(shí)需要將我們的流處理邏輯運(yùn)行到批數(shù)據(jù)上面。關(guān)于這一點(diǎn)，最早在 2014 年 Google 提出 Dataflow 計(jì)算服務(wù)的時(shí)候就批判了 streaming/batch 這種叫法，而是提出了 unbounded/bounded data 的說法。DStream 盡管是對(duì) RDD 的封裝，但是我們要將 DStream 代碼完全轉(zhuǎn)換成 RDD 還是有一點(diǎn)工作量的，更何況現(xiàn)在 Spark 的批處理都用 DataSet/DataFrame API 了。

2.、Structured Streaming 優(yōu)勢(shì)

相對(duì)的，來看下 Structured Streaming 優(yōu)勢(shì)：

簡(jiǎn)潔的模型。Structured Streaming 的模型很簡(jiǎn)潔，易于理解。用戶可以直接把一個(gè)流想象成是無限增長(zhǎng)的表格。

一致的 API。由于和 Spark SQL 共用大部分 API，對(duì) Spaprk SQL 熟悉的用戶很容易上手，代碼也十分簡(jiǎn)潔。同時(shí)批處理和流處理程序還可以共用代碼，不需要開發(fā)兩套不同的代碼，顯著提高了開發(fā)效率。

卓越的性能。Structured Streaming 在與 Spark SQL 共用 API 的同時(shí)，也直接使用了 Spark SQL 的 Catalyst 優(yōu)化器和 Tungsten，數(shù)據(jù)處理性能十分出色。此外，Structured Streaming 還可以直接從未來 Spark SQL 的各種性能優(yōu)化中受益。

多語言支持。Structured Streaming 直接支持目前 Spark SQL 支持的語言，包括 Scala，Java，Python，R 和 SQL。用戶可以選擇自己喜歡的語言進(jìn)行開發(fā)。

同樣能支持多種數(shù)據(jù)源的輸入和輸出，Kafka、flume、Socket、Json。

基于 Event-Time，相比于 Spark Streaming 的 Processing-Time 更精確，更符合業(yè)務(wù)場(chǎng)景。

Event time  事件時(shí)間: 就是數(shù)據(jù)真正發(fā)生的時(shí)間，比如用戶瀏覽了一個(gè)頁面可能會(huì)產(chǎn)生一條用戶的該時(shí)間點(diǎn)的瀏覽日志。

Process time  處理時(shí)間:  則是這條日志數(shù)據(jù)真正到達(dá)計(jì)算框架中被處理的時(shí)間點(diǎn)，簡(jiǎn)單的說，就是你的 Spark 程序是什么時(shí)候讀到這條日志的。

事件時(shí)間是嵌入在數(shù)據(jù)本身中的時(shí)間。對(duì)于許多應(yīng)用程序，用戶可能希望在此事件時(shí)間操作。例如，如果要獲取 IoT 設(shè)備每分鐘生成的事件數(shù)，則可能需要使用生成數(shù)據(jù)的時(shí)間（即數(shù)據(jù)中的事件時(shí)間），而不是 Spark 接收他們的時(shí)間。事件時(shí)間在此模型中非常自然地表示 – 來自設(shè)備的每個(gè)事件都是表中的一行，事件時(shí)間是該行中的一個(gè)列值。

支持 spark2 的 dataframe 處理。

解決了 Spark Streaming 存在的代碼升級(jí)，DAG 圖變化引起的任務(wù)失敗，無法斷點(diǎn)續(xù)傳的問題。

基于 SparkSQL 構(gòu)建的可擴(kuò)展和容錯(cuò)的流式數(shù)據(jù)處理引擎，使得實(shí)時(shí)流式數(shù)據(jù)計(jì)算可以和離線計(jì)算采用相同的處理方式（DataFrame SQL）。

可以使用與靜態(tài)數(shù)據(jù)批處理計(jì)算相同的方式來表達(dá)流計(jì)算。

底層原理完全不同

Spark Streaming 采用微批的處理方法。每一個(gè)批處理間隔的為一個(gè)批，也就是一個(gè) RDD，我們對(duì) RDD 進(jìn)行操作就可以源源不斷的接收、處理數(shù)據(jù)。

Structured Streaming 將實(shí)時(shí)數(shù)據(jù)當(dāng)做被連續(xù)追加的表。流上的每一條數(shù)據(jù)都類似于將一行新數(shù)據(jù)添加到表中。

上述就是丸趣 TV 小編為大家分享的怎樣用 Spark 進(jìn)行實(shí)時(shí)流計(jì)算了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。