主頁(yè) > 知識(shí)庫(kù) > 使用Spark進(jìn)行實(shí)時(shí)流計(jì)算的方法

使用Spark進(jìn)行實(shí)時(shí)流計(jì)算的方法

熱門(mén)標(biāo)簽:廊坊地圖標(biāo)注申請(qǐng)入口 怎么去掉地圖標(biāo)注文字 高德地圖標(biāo)注公司位置需要錢(qián)嗎 慶陽(yáng)外呼系統(tǒng)定制開(kāi)發(fā) 地圖標(biāo)注資源分享注冊(cè) 襄陽(yáng)外呼增值業(yè)務(wù)線路解決方案 北京外呼系統(tǒng)咨詢電話 合肥阿里辦理400電話號(hào) 海南人工外呼系統(tǒng)哪家好

Spark Streaming VS Structured Streaming

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

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

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

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

從Spark-2.X版本后,Spark Streaming就進(jìn)入維護(hù)模式,看見(jiàn)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)單來(lái)說(shuō)就是將一個(gè)微小時(shí)間段,比如說(shuō) 1s,的流數(shù)據(jù)當(dāng)前批數(shù)據(jù)來(lái)處理。如果我們要統(tǒng)計(jì)某個(gè)時(shí)間段的一些數(shù)據(jù)統(tǒng)計(jì),毫無(wú)疑問(wèn)應(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 類(lèi)似 RDD 的 API 的,非常的 low level。當(dāng)我們編寫(xiě) Spark Streaming 程序的時(shí)候,本質(zhì)上就是要去構(gòu)造 RDD 的 DAG 執(zhí)行圖,然后通過(guò) Spark Engine 運(yùn)行。這樣導(dǎo)致一個(gè)問(wèn)題是,DAG 可能會(huì)因?yàn)殚_(kāi)發(fā)者的水平參差不齊而導(dǎo)致執(zhí)行效率上的天壤之別。這樣導(dǎo)致開(kāi)發(fā)者的體驗(yàn)非常不好,也是任何一個(gè)基礎(chǔ)框架不想看到的(基礎(chǔ)框架的口號(hào)一般都是:你們專(zhuān)注于自己的業(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 只能保證自己的一致性語(yǔ)義是 exactly-once 的,而 input 接入 Spark Streaming 和 Spark Straming 輸出到外部存儲(chǔ)的語(yǔ)義往往需要用戶自己來(lái)保證。而這個(gè)語(yǔ)義保證寫(xiě)起來(lái)也是非常有挑戰(zhàn)性,比如為了保證 output 的語(yǔ)義是 exactly-once 語(yǔ)義需要 output 的存儲(chǔ)系統(tǒng)具有冪等的特性,或者支持事務(wù)性寫(xiě)入,這個(gè)對(duì)于開(kāi)發(fā)者來(lái)說(shuō)都不是一件容易的事情。

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

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

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

相對(duì)的,來(lái)看下Structured Streaming優(yōu)勢(shì):

  • 簡(jiǎn)潔的模型。Structured Streaming 的模型很簡(jiǎn)潔,易于理解。用戶可以直接把一個(gè)流想象成是無(wú)限增長(zhǎng)的表格。
  • 一致的 API。由于和 Spark SQL 共用大部分 API,對(duì) Spaprk SQL 熟悉的用戶很容易上手,代碼也十分簡(jiǎn)潔。同時(shí)批處理和流處理程序還可以共用代碼,不需要開(kāi)發(fā)兩套不同的代碼,顯著提高了開(kāi)發(fā)效率。
  • 卓越的性能。Structured Streaming 在與 Spark SQL 共用 API 的同時(shí),也直接使用了 Spark SQL 的 Catalyst 優(yōu)化器和 Tungsten,數(shù)據(jù)處理性能十分出色。此外,Structured Streaming 還可以直接從未來(lái) Spark SQL 的各種性能優(yōu)化中受益。
  • 多語(yǔ)言支持。Structured Streaming 直接支持目前 Spark SQL 支持的語(yǔ)言,包括 Scala,Java,Python,R 和 SQL。用戶可以選擇自己喜歡的語(yǔ)言進(jìn)行開(kāi)發(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è)頁(yè)面可能會(huì)產(chǎn)生一條用戶的該時(shí)間點(diǎn)的瀏覽日志。
  • Process time 處理時(shí)間: 則是這條日志數(shù)據(jù)真正到達(dá)計(jì)算框架中被處理的時(shí)間點(diǎn),簡(jiǎn)單的說(shuō),就是你的Spark程序是什么時(shí)候讀到這條日志的。
  • 事件時(shí)間是嵌入在數(shù)據(jù)本身中的時(shí)間。對(duì)于許多應(yīng)用程序,用戶可能希望在此事件時(shí)間操作。例如,如果要獲取IoT設(shè)備每分鐘生成的事件數(shù),則可能需要使用生成數(shù)據(jù)的時(shí)間(即數(shù)據(jù)中的事件時(shí)間),而不是Spark接收他們的時(shí)間。事件時(shí)間在此模型中非常自然地表示 - 來(lái)自設(shè)備的每個(gè)事件都是表中的一行,事件時(shí)間是該行中的一個(gè)列值。
  • 支持spark2的dataframe處理。
  • 解決了Spark Streaming存在的代碼升級(jí),DAG圖變化引起的任務(wù)失敗,無(wú)法斷點(diǎn)續(xù)傳的問(wèn)題。
  • 基于SparkSQL構(gòu)建的可擴(kuò)展和容錯(cuò)的流式數(shù)據(jù)處理引擎,使得實(shí)時(shí)流式數(shù)據(jù)計(jì)算可以和離線計(jì)算采用相同的處理方式(DataFrameSQL)。
  • 可以使用與靜態(tài)數(shù)據(jù)批處理計(jì)算相同的方式來(lái)表達(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ù)都類(lèi)似于將一行新數(shù)據(jù)添加到表中。

Spark 3.0.0發(fā)布以后 全新的Structured Streaming UI誕生,可見(jiàn)未來(lái)的Structured Streaming將不斷迎來(lái)進(jìn)步。

總結(jié)

到此這篇關(guān)于使用Spark進(jìn)行實(shí)時(shí)流計(jì)算的方法的文章就介紹到這了,更多相關(guān)Spark實(shí)時(shí)流計(jì)算內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

您可能感興趣的文章:
  • SparkGraphx計(jì)算指定節(jié)點(diǎn)的N度關(guān)系節(jié)點(diǎn)源碼

標(biāo)簽:商丘 綿陽(yáng) 鎮(zhèn)江 鶴崗 平頂山 臺(tái)州 株洲 哈密

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《使用Spark進(jìn)行實(shí)時(shí)流計(jì)算的方法》,本文關(guān)鍵詞  使用,Spark,進(jìn)行,實(shí)時(shí),流,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《使用Spark進(jìn)行實(shí)時(shí)流計(jì)算的方法》相關(guān)的同類(lèi)信息!
  • 本頁(yè)收集關(guān)于使用Spark進(jìn)行實(shí)時(shí)流計(jì)算的方法的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章