第18章. Sparkストリーミング実行モデル
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
第16章でSpark Streamingの旅を始めたとき、このストリーミングAPIが提供するプログラミングモデルと演算モデルをDStream抽象化がどのように具現化するかについて説明した。第17章でプログラミングモデルについて学んだ後、Spark Streamingランタイムの背後にある実行モデルを理解する準備が整った。
この章では、バルク同期アーキテクチャと、それがマイクロバッチストリーミングモデルを推論するためのフレームワークをどのように提供するかについて学ぶ。 次に、Spark Streamingがレシーバモデルを使用してデータを消費する方法と、このモデルがデータ処理の信頼性の点で提供する保証について調べる。 最後に、信頼性の高いデータ配信を提供できるストリーミングデータプロバイダのレシーバの代替として、ディレクトリAPIを調べる。
バルク同期アーキテクチャ
第5章では、 、ストリームからのデータのマイクロバッチに対して分散ストリーム処理がどのように行われるかを推論することができる理論的枠組みとして、バルク同期並列(BSP)モデルについて説明した。
Spark Streamingは、バルク同期並列処理に似た処理モデルに従っている:
-
クラスタ上のすべてのSparkエクゼキュータは、例えばネットワークタイムプロトコル(NTP)サーバを介して同期されるなど、同期クロックを持っていると仮定される。
-
Receiverベースのソースの場合、1つまたは複数のエグゼキュータが、 Sparkの特殊化ジョブであるReceiverを実行する。 このReceiverは、Streamの新しい要素を消費するタスクがある。 このReceiverは、2クロックのティックを受信する:
-
これは、ストリームから受信した要素をブロックに割り当てるタイミング、つまり、現在のインターバルで、単一のエクゼキュータによって処理されるべきストリームの部分を示す。 このような各ブロックは、各バッチインターバルで生成されるレジリエンス分散データセット(RDD)のパーティションになる。
-
、頻度が低いのがバッチインターバルである。これは、レシーバーが最後のクロックチック以降に収集されたストリームからデータをアセンブルし、クラスタ上で分散処理するためのRDDを生成するタイミングを示す。
-
-
ダイレクトアプローチを使用する場合、関連するのはバッチ間隔の刻みのみである。
-
すべての処理中、通常の(バッチ)Sparkジョブの場合と同様に、ブロックはブロックマネージャに通知される。ブロックマネージャは、Sparkに投入されたすべてのデータブロックが、設定された永続化レベルに従って複製されることを保証するコンポーネントであり、フォールトトレランスを目的としている。
-
各バッチインターバルで、前のバッチインターバルでデータを受信した RDDが利用可能になり、その結果、このバッチ中に処理がスケジュールされる。
図18-1は、これらの要素がどのように組み合わさって概念的にはDStreamを形成しているかを示している。
図18-1. DStreamの構造:ブロックとバッチ
厳密なバルク同期モデルで同時実行を実現する場合、ここでのバリアはバッチ間隔での新しいRDDの到着となる。 ただし、Spark Streamingでは、新しいバッチが到着した瞬間のクラスタの状態とは無関係にデータ配信が行われるため、これは実際にはバリアではない:Sparkのレシーバは、新しいバッチを開始するためにクラスタがデータの受信を終了するのを待たない。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access