Apache Spark によるストリーム処理

第10章. 構造化ストリーミング・ソース

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

前の章では、Structured Streaming プログラミングモデルの概要と、それを実用的に適用する方法について説明した。 また、ソースが各 Structured Streaming プログラムの出発点であることも説明した。 この章では、ソースの一般的な特徴を学び、利用可能なソースについて、そのさまざまな設定オプションや演算子モードを含め、より詳細に検討する。

情報源を理解する

Structured Streamingでは、ソースはストリーミング・データ・プロバイダを表す抽象化である。ソース・インタフェースの背後にある概念は、ストリーミング・データは、単調にインクリメントするカウンタでインデックス付けされたシーケンスとして見ることができる、時間の経過に伴うイベントの連続的な流れであるということである。

図10-1は、ストリーム内の各イベントが、 オフセットが増加し続けるものとみなされる様子を示している。

図10-1. インデックス化されたイベントのシーケンスとして見たストリーム

図 10-2 に示すように、オフセットは、外部ソースにデータを要求し、どのデータがすでに消費され たかを示すために使用される。構造化ストリーミングは、外部システムから現在のオフセットを要求し、最後に処 理されたオフセットと比較することによって、処理するデータがいつあるかを知る。処理するデータは、2 つのオフセットstart とend の間のバッチを取得することによって要求される。 ソースは、指定されたオフセットをコミットすることで、データが処理されたことを通知される。 ソース契約は、コミットされたオフセット以下のオフセットを持つすべてのデータが処理されたこと、および後続の要求がそのコミットされたオフセットより大きいオフセットのみを規定することを保証する。 これらの保証を考慮すると、ソースは、システムリソースを解放するために、処理されたデータを破棄することを選択する可能性がある。

図10-2. オフセット処理のシーケンス

図10-2に示したオフセット・ベースの処理のダイナミクスを詳しく見てみよう：

1. t1において、システムはgetOffset を呼び出し、ソースの現在のオフセットを取得する。

2. t2において、システムは、getBatch(start, end) を呼び出し、最後の既知のオフセットまでのバッチを取得する。その間に新しいデータが到着している可能性があることに注意。

3. t3で、システムはオフセットをcommits 、ソースは対応するレコードを削除する。

このプロセスは絶え間なく繰り返され、ストリーミングデータの取得を保証する。 最終的な故障から回復するために、オフセットは外部ストレージにチェックポイントされることが多い。

オフセットに基づく相互作用の他に、ソースは2つの要件を満たす必要がある。 ...