SparkStreaming VS Structed Streamin
導言
Spark在2.*版本後加入StructedStreaming模組,與流處理引擎Sparkstreaming一樣,用於處理流資料。但二者又有許多不同之處。
Sparkstreaming首次引入在0.*版本,其核心思想是利用spark批處理框架,以microbatch(以一段時間的流作為一個batch)的方式,完成對流資料的處理。
StructedStreaming誕生於2.*版本,主要用於處理結構化流資料,除了與Sparkstreaming類似的microbatch的處理流資料方式,也實現了long-running的task,可以"不停的"迴圈從資料來源獲取資料並處理,從而實現真正的流處理。以dataset為代表的帶有結構化(schema資訊)的資料處理由於鎢絲計劃的完成,表現出更優越的效能。同時Structedstreaming可以從資料中獲取時間(eventTime),從而可以針對流資料的生產時間而非收到資料的時間進行處理。
StructedStreaming的相關介紹可參考()
SparkStreaming的相關介紹可參考()。
SparkStreaming與Structed Streaming對比
流處理模式 | SparkStreaming | Structed streaming |
---|---|---|
執行模式 | Micro Batch | Micro batch / Streaming |
API | Dstream/streamingContext | Dataset/DataFrame,SparkSession |
Job 生成方式 | Timer定時器定時生成job | Trigger觸發 |
支援資料來源 | Socket,filstream,kafka,zeroMq,flume,kinesis | Socket,filstream,kafka,ratesource |
executed-based | Executed based on dstream api | Executed based on sparksql |
Time based | Processing Time | ProcessingTime & eventTIme |
UI | Built-in | No |
執行模式
Spark Streaming以micro-batch的模式
以固定的時間間隔來劃分每次處理的資料,在批次內以採用的是批處理的模式完成計算
Structed streaming有兩種模式:
Micro-batch模式
一種同樣以micro-batch的模式完成批處理,處理模式類似sparkStreaming的批處理,可以定期(以固定間隔)處理,也可以處理完一個批次後,立刻進入下一批次的處理
Continuous Processing模式
一種啟動長時執行的執行緒從資料來源獲取資料,worker執行緒長時執行,實時處理訊息。放入queue中,啟動long-running的worker執行緒從queue中讀取資料並處理。該模式下,當前只能支援簡單的projection式(如map,filter,mappartitions等)的操作
API
Sparkstreaming :
Sparkstreaming框架基於RDD開發,自實現一套API封裝,程式入口是StreamingContext,資料模型是Dstream,資料的轉換操作透過Dstream的api完成,真正的實現依然是透過呼叫rdd的api完成。
StructedStreaming :
Structed Streaming 基於sql開發,入口是sparksession,使用的統一Dataset資料集,資料的操作會使用sql自帶的最佳化策略實現
Job生成與排程
SparkStreamingJob生成:
job透過定時器根據batch duration定期生成Streaming的Job(org.apache.spark.streaming.scheduler.Job)該Job是對Spark core的job的封裝,在run方法中會完成對sparkcontext.runJob的呼叫// 透過timer定時器定期發生generatorJobs的訊息 timer = new RecurringTimer(clock, ssc.graph.batchDuration.milliseconds, longTime => eventLoop.post(GenerateJobs(new Time(longTime))), "JobGenerator")//呼叫eventLoop的processEvent方法處理根據訊息型別處理訊息 private def processEvent(event: JobGeneratorEvent) { logDebug("Got event " + event) event match { case GenerateJobs(time) => generateJobs(time) case ClearMetadata(time) => clearMetadata(time) case DoCheckpoint(time, clearCheckpointDataLater) => doCheckpoint(time, clearCheckpointDataLater) case ClearCheckpointData(time) => clearCheckpointData(time) } }
Sparkstreaming的Job的排程:
生成Job之後,透過呼叫JobScheduler的submitJobSet方法提交job,submitJobSet透過jobExecutor完成呼叫job的run方法,完成spark Core job的呼叫 def submitJobSet(jobSet: JobSet) { if (jobSet.jobs.isEmpty) { logInfo("No jobs added for time " + jobSet.time) } else { listenerBus.post(StreamingListenerBatchSubmitted(jobSet.toBatchInfo)) jobSets.put(jobSet.time, jobSet) jobSet.jobs.foreach(job => jobExecutor.execute(new JobHandler(job))) logInfo("Added jobs for time " + jobSet.time) } } 其中JobExecutor是一個有numCorrentJob(由spark.streaming.concurrentJobs決定,預設為1)個執行緒的執行緒池,定義如下: jobExecutor = ThreadUtils.newDaemonFixedThreadPool(numConcurrentJobs, "streaming-job-executor")
StructedStreaming job生成與排程 :
Structed Streaming透過trigger完成對job的生成和排程。具體的排程可參考中的About trigger章節
支援資料來源
SparkStreaming出現較早,支援的資料來源較為豐富:Socket,filstream,kafka,zeroMq,flume,kinesis
Structed Streaming 支援的資料來源 : Socket,filstream,kafka,ratesource
executed-based
SparkStreaming在執行過程中呼叫的是dstream api,其核心執行仍然呼叫rdd的介面
Structed Streaming底層的資料結構為dataset/dataframe,在執行過程中可以使用的鎢絲計劃,自動程式碼生成等最佳化策略,提升效能
Time Based
Sparkstreaming的處理邏輯是根據應用執行時的時間(Processing Time)進行處理,不能根據訊息中自帶的時間戳完成一些特定的處理邏輯
Structed streaming,加入了event Time,weatermark等概念,在處理訊息時,可以考慮訊息本身的時間屬性。同時,也支援基於執行時時間的處理方式。
UI
Sparkstreaming 提供了內建的介面化的UI操作,便於觀察應用執行,批次處理時間,訊息速率,是否延遲等資訊。
Structed streaming 暫時沒有直觀的UI
作者:WestC
連結:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4662/viewspace-2818617/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- spark structed streaming 寫入hudi表SparkStruct
- sparkStreaming 之 kafka源SparkKafka
- 大資料-SparkStreaming(一)大資料Spark
- Kafka結合SparkStreaming開發KafkaSpark
- SparkStreaming 的使用與總結Spark
- SparkStreaming實時流處理學習Spark
- SparkStreaming入門教程(三)高階輸入源:Flume、KaSpark
- Playwright VS Selenium VS Puppeteer VS Cypress
- SparkStreaming報錯: Only one SparkContext may be running in this JVM (see SPARK-2243)SparkContextJVM
- 【Spark篇】---SparkStreaming中運算元中OutPutOperator類運算元Spark
- vs 2017 vs code
- Airflow vs. Luigi vs. Argo vs. MLFlow vs. KubeFlowAIUIGo
- 透過案例對SparkStreaming透徹理解三板斧之二Spark
- 圖解SparkStreaming與Kafka的整合,這些細節大家要注意!圖解SparkKafka
- Spark-stream基礎---sparkStreaming和Kafka整合wordCount單詞計數SparkKafka
- 【Spark篇】---SparkStreaming+Kafka的兩種模式receiver模式和Direct模式SparkKafka模式
- Axum vs Actix vs Rocket
- RDBMS VS XML VS NoSQLXMLSQL
- 記一次SparkStreaming不產生新的batchJob的問題排查SparkBAT
- 如何解除安裝VS 2017之前版本比如VS 2013、VS2015、 VS vNext?
- coca 搭配 in vs on vs at | page1
- coca 搭配 in vs on vs at | page3
- spring vs yii2 vs LaravelSpringLaravel
- [譯]await VS return VS return awaitAI
- The SQL vs NoSQL Difference: MySQL vs MongoDBMySqlMongoDB
- HashSet vs. TreeSet vs. LinkedHashSet
- Redux vs Mobx系列(-):immutable vs mutableRedux
- JavaScript 的 4 種陣列遍歷方法: for VS forEach() VS for/in VS for/ofJavaScript陣列
- Tomcat vs Jetty vs Undertow效能對比TomcatJetty
- ABAP vs Java, 蛙泳 vs 自由泳Java
- When to use var vs let vs const in JavaScriptJavaScript
- 微軟常用執行庫合集下載(vs2008(sp)/vs2010(sp)/vs2012/vs2013/vs2015/vs2017)包含32位/64位微軟
- 測試速度比較:Selenium vs Playwright vs Cypress vs Puppeteer vs TestCafe
- javascript — == vs ===JavaScript
- vs 2017
- PostgreSQL DBA(131) - Develop(numeric vs float vs int)SQLdev
- PostgreSQL DBA(6) - SeqScan vs IndexScan vs Bit...SQLIndex
- 我將從VS Code切換到VS Codium