PrithvirajBoseによる寄稿
このブログでは、ApacheSparkのステートフルトランスフォーメーションのウィンドウ処理の概念について説明します。
ステートフルトランスフォーメーションとは何ですか？
Sparkストリーミングは、受信データが離散化ストリーム（DStreams）と呼ばれるマイクロバッチにグループ化されるマイクロバッチアーキテクチャを使用します。これは、基本的なプログラミングの抽象化としても機能します。 DStreamsは内部に復元力のある分散データセット（RDD）を備えており、この標準のRDD変換とアクションの結果として実行できます。
ストリーミングでは、バッチ間でデータを追跡するユースケースがある場合、ステートフルDStreamが必要です。
たとえば、ユーザーセッション中のウェブサイトでのユーザーの操作を追跡したり、特定のTwitterハッシュタグを経時的に追跡して、世界中のどのユーザーがそれについて話しているかを確認したりできます。
ステートフル変換のタイプ。
Javaの例でのソケットプログラミング
ステートフルDStreamには、ウィンドウベースの追跡と完全なセッション追跡の2つのタイプがあります。
ステートフルトラッキングでは、すべての受信データをキーと値のペアに変換して、バッチ間でキーの状態を追跡できるようにする必要があります。これは前提条件です。
さらに、チェックポインティングも有効にする必要があります。これについては、後のブログで説明します。
>ウィンドウベースの追跡
ウィンドウベースの追跡では、着信バッチは時間間隔でグループ化されます。つまり、「x」秒ごとにバッチをグループ化します。これらのバッチのさらなる計算は、スライド間隔を使用して行われます。
たとえば、ウィンドウ間隔= 3秒およびスライド間隔= 2秒の場合、すべての受信データは3秒ごとにバッチにグループ化され、これらのバッチの計算は2秒ごとに実行されます。あるいは、最後の3秒に到着したバッチに対して2秒ごとに計算を行うと言うこともできます。
上の図では、着信バッチが3単位時間（ウィンドウ間隔）ごとにグループ化され、計算が2単位時間（スライド間隔）ごとに実行されていることがわかります。
注：Apache Flinkとは異なり、Apache Sparkにはウィンドウのタンブリングの概念がなく、すべてのウィンドウがスライドします。
火
ウィンドウベースの変換で人気のあるAPIは
PairDStreamFunctions.reduceByKeyAndWindow 。
このAPIにはいくつかのオーバーロードされたバージョンがありますが、パラメーターの数が最も多いバージョンを見てみましょう。この説明の後、このAPIのオーバーロードされたバージョンの残りの部分は自明であるはずです。
戻り値：変換されたDStream [（K、V）]
reduceFunc ：連想削減機能。
invReduceFunc ：上記のreduce関数の逆。これは、着信バッチと発信バッチを効率的に計算するために必要です。この関数の助けを借りて、発信されるバッチの値は、上記のreduce関数の累積値から差し引かれます。たとえば、それぞれのキーの着信値の合計を計算している場合、発信バッチについては、それぞれのキーの値を減算します（現在のバッチに存在する場合は無視します）。
windowDuration ：バッチをグループ化するための時間の単位。これはバッチ間隔の倍数である必要があります。
slideDuration ：計算の時間の単位。これはバッチ間隔の倍数である必要があります。 パーティション ：結果のDStreamを格納するために使用するパーティショナー。パーティショニングの詳細については、以下をお読みください。 この 。
filterFunc ：期限切れのキーと値のペアを除外する関数。たとえば、キーの更新がしばらくない場合は、削除したい場合があります。
これが プログラム ソケットストリームからの単語をカウントします。上記の関数のオーバーロードバージョンを使用しました。ウィンドウ間隔は4秒、スライド間隔は2秒です。
次のブログでは、完全なセッションの追跡とチェックポイントについて書きます。
質問がありますか？コメント欄にご記入ください。折り返しご連絡いたします。
関連記事：