ストリーミング・システム

第3章 ウォーターマーク ウォーターマーク

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

これまでは、パイプラインの作者（）やデータサイエンティストの視点からストリーム処理を見てきた。第2章では、イベント時間のどこで処理が行われ、処理時間のいつ結果が現れるのかという基本的な疑問に対する答えの一部として、透かしを紹介した。本章では、同じ疑問に対して、ストリーム処理システムの基本的な仕組みの観点からアプローチする。これらの仕組みを見ることは、透かしにまつわる概念を動機付け、理解し、適用するのに役立つだろう。透かしがどのようにデータ入力時に作成され、どのようにデータ処理パイプラインを伝搬し、どのように出力タイムスタンプに影響を与えるかについて議論する。また、電子透かしが、束縛のないデータを扱いながら、イベントタイムのどこでデータが処理され、いつ実体化されるかという疑問に答えるために必要な保証をどのように保持するかを示す。

定義

継続的にデータを取り込み、結果を出力するパイプラインを考える。我々は、イベント・タイム・ウィンドウをいつクローズ（ウィンドウがそれ以上データを期待しないことを意味する）と呼び出すのが安全か、という一般化問題を解決したい。そのために、パイプラインが、制限のない入力に対して行っている進捗を特徴付けたい。

イベント・タイム・ウィンドウの問題を解決するための単純なアプローチとしては、現在の処理時間をイベント・タイム・ウィンドウの基準とすることである。第1章で見たように、データの処理と転送は瞬時ではないので、処理時間とイベント時間が等しくなることはほとんどない。パイプラインに不都合やスパイクがあれば、Windowsへのメッセージの代入を誤るかもしれない。結局のところ、このようなウィンドウを保証する堅牢性がないため、この戦略は失敗する。

もう一つの直感的な、しかし究極的には正しくないアプローチは、パイプラインによって処理されるメッセージのレートを考慮することである。これは興味深いメトリックではあるが、入力の変化、期待される結果の変数、処理に利用可能なリソースなどによって、レートは恣意的に変化する可能性がある。さらに重要なことは、レートは完全性に関する基本的な質問に答える助けにはならないということだ。具体的には、ある時間間隔のメッセージをすべて見たのはいつなのかを、レートは教えてくれない。実世界のシステムでは、メッセージがシステムを通して進んでいない状況が存在する。これは、一過性のエラー（クラッシュ、ネットワーク障害、マシン停止時間など）の結果であることもあれば、アプリケーションロジックの変更やその他の手動介入を必要とするアプリケーションレベルの障害のような永続的なエラーの結果であることもある。もちろん、多くの障害が発生している場合、処理速度メトリックはこれを検出するための良いプロキシになるかもしれない。しかし、レートメトリックは、パイプラインを通過する単一のメッセー ジが失敗していることを知ることはできない。しかし、そのようなメッセージが1つでもあれば、出力結果の正しさに任意に影響を与えることができる。

より堅牢な進捗状況の測定が必要である。そこに到達するために、、ストリーミング・データについて1つの基本的な仮定をする。各メッセージは、関連する論理イベントのタイムスタンプを持つ。各メッセージには関連する論理イベントのタイムスタンプがある。この仮定は、入力データの連続的な生成を意味するため、連続的に到着する非束縛データの文脈では妥当である。ほとんどの場合、元のイベントが発生した時刻を論理的なイベントタイムスタンプとすることができる。すべての入力メッセージにイベントタイムスタンプが含まれていれば、任意のパイプラインにおけるそのようなタイムスタンプの分布を調べることができる。このようなパイプラインは、多くのエージェントに分散して並列処理され、個々のシャード間の順序が保証されていない入力メッセージを消費するかもしれない。したがって、このパイプラインのアクティブなインフライトメッセージのイベントタイムスタンプのセットは、 ...