ストリーミングストラクチャードスパークストリーミング対

簡単な紹介

スパークストリーミング

スパークストリーミングスパークが最初ストリーム処理フレームワークは、マイクロバッチストリーミングを形成するために使用されました。

DSTREAM API、RDD間隔各時間におけるデータのベースRDDSを提供し、安定したストリームは、RDDフロー計算を達成するために処理されます

構造化ストリーミング

スパークは、テーブルアペンド行に連続してデータをストリーミングするために無制限テーブル対応の概念を用いて、2.Xフレームの流出します。

スパークSQL機能のほとんどは、ベーススパークSQLエンジンの実装

違い

1.フローモデル

スパークストリーミング

ここに画像を挿入説明
スパーク使用ストリーミングマイクロバッチ処理方法。各バッチは、我々はデータを処理し、RDDの安定したストリームを受信するように動作することができるRDDあるバッチ間隔、です。

マイクロバッチストリーミング火花が最終的に付与されています

構造化ストリーミング

ここに画像を挿入説明

構造化ストリーミングが継続的に追加されているテーブルとして、ライブデータストリームを処理することです

データは以下のようにリアルタイムのストリーミング構造化された連続テーブルに追加されますストリーム上のデータの各々は、テーブルに新しい行を追加することと同様です。

ここに画像を挿入説明

一例として、上記図、入力ソース入力テーブルからデータを取得するために1秒とクエリトリガ計算は、結果は指定された出力モードを書き込み、続いて、表間隔を結果書き込みます。

上記一秒間隔は、トリガ(トリガ間隔)が指定された指定されていない場合、前処理データは、新しいデータがあるかどうか、システムは直ちにチェックを完了する。

需要注意的是,Spark Streaming本身设计就是一批批的以批处理间隔划分RDD;而Structured Streaming中并没有提出批的概念,Structured Streaming按照每个Trigger Interval接收数据到Input Table,将数据处理后再追加到无边界的Result Table中,想要何种方式输出结果取决于指定的模式。所以,虽说Structured Streaming也有类似于Spark Streaming的Interval,其本质概念是不一样的。Structured Streaming更像流模式。

2. RDD vs. DataFrame、DataSet

Spark Streaming中的DStream编程接口是RDD,我们需要对RDD进行处理,处理起来较为费劲且不美观。

stream.foreachRDD(rdd => {
    balabala(rdd)
})

Structured Streaming使用DataFrame、DataSet的编程接口,处理数据时可以使用Spark SQL中提供的方法,数据的转换和输出会变得更加简单。

spark
    .readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "hadoop01:9092")
    .option("subscribe", "order_data")
    .load()
    .select($"value".cast("string"))
    .as[String]
    .writeStream
    .outputMode("complete")
    .format("console")

3. Process Time vs. Event Time

Process Time:流处理引擎接收到数据的时间

Event Time:时间真正发生的时间

Spark Streaming中由于其微批的概念,会将一段时间内接收的数据放入一个批内,进而对数据进行处理。划分批的时间是Process Time,而不是Event Time,Spark Streaming没有提供对Event Time的支持。

Structured Streaming提供了基于事件时间处理数据的功能,如果数据包含事件的时间戳,就可以基于事件时间进行处理。

这里以窗口计数为例说明一下区别:

我们这里以10分钟为窗口间隔,5分钟为滑动间隔,每隔5分钟统计过去10分钟网站的pv

假设有一些迟到的点击数据,其本身事件时间是12:01,被spark接收到的时间是12:11;在spark streaming的统计中,会毫不犹豫的将它算作是12:05-12:15这个范围内的pv,这显然是不恰当的;在structured streaming中,可以使用事件时间将它划分到12:00-12:10的范围内,这才是我们想要的效果。

4. 可靠性保障

两者在可靠性保证方面都是使用了checkpoint机制。

checkpoint通过设置检查点,将数据保存到文件系统,在出现出故障的时候进行数据恢复。

在spark streaming中,如果我们需要修改流程序的代码,在修改代码重新提交任务时,是不能从checkpoint中恢复数据的(程序就跑不起来),是因为spark不认识修改后的程序了。

在structured streaming中,对于指定的代码修改操作,是不影响修改后从checkpoint中恢复数据的。具体可参见文档

5. sink

二者的输出数据(写入下游)的方式有很大的不同。

spark streaming中提供了foreachRDD()方法,通过自己编程实现将每个批的数据写出。

stream.foreachRDD(rdd => {
    save(rdd)
})

structured streaming自身提供了一些sink(Console Sink、File Sink、Kafka Sink等),只要通过option配置就可以使用;对于需要自定义的Sink,提供了ForeachWriter的编程接口,实现相关方法就可以完成。

// console sink
val query = res
    .writeStream
    .outputMode("append")
    .format("console")
    .start()

最后

总体来说,structured streaming有更简洁的API、更完善的流功能、更适用于流处理。而spark streaming,更适用于与偏批处理的场景。

在流处理引擎方面,flink最近也很火,值得我们去学习一番。

reference

https://blog.knoldus.com/spark-streaming-vs-structured-streaming/

https://dzone.com/articles/spark-streaming-vs-structured-streaming

https://spark.apache.org/docs/2.0.2/streaming-programming-guide.html

https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html


間違った場所には、正しい私の交換を喜ば場合は、上記のは、個人的な理解です。

ここに画像を挿入説明
個人公開番号:ヤードの農家のピークは、毎週最新の業界情報、技術的な出版元の記事を押して、我々は注意を歓迎します。

おすすめ

転載: www.cnblogs.com/upupfeng/p/12079462.html