• 第2章まではwatermarkでどこまで処理したか管理するという話をした
• 本章ではwatermarkがどう作られてどう伝搬するかなどを説明する

Definition

watermarkをどう定めるかについて議論する。

疑問

event-time windowはいつ閉じればよいか。

• 進捗が分からなければ閉じられない
• 無限なデータ列に対して進捗は分からない（遅れたデータが来ないとは言い切れない）

ナイーブな回答例

• Processing Timeでwindowを閉じる。
  • 一つの回答にはなる。（が、不正確）
• メッセージ処理レート（速度）を使う
  • 入力の変化、期待される結果の変動、処理に利用できるリソースなどによって変わるので何かしらの示唆は得られる。
  • が、クラッシュしてたらレートは落ちるけど処理は完了しないので正しさが保証されないことは容易に分かる
• ⇒ どれもincorrect

よりrobustな定義

• 仮定：各メッセージには論理タイムスタンプがあるとする

  • 元のイベントの発生時刻をその論理的なイベントのタイムスタンプにできる

• 処理中メッセージのタイムスタンプについての下図のような分布がわかるようにな

  • パイプラインは並列化されているかもしれないので処理中メッセージのタイムスタンプにはばらつきがでる。これにより分布が形成される。

  

• in-flightの左端が「未完了メッセージの最も古いイベントタイムスタンプ」を意味する。

• これを使ってwatermarkを「単調増加する処理が完了していないイベントのタイムスタンプ」と定義する

• ※ この値が単調増加するとは限らないが今後議論する（らしい）

この定義の有用な性質

• 完全性
  • ウォーターマークがあるタイムスタンプTより進んだ場合、T以前の非遅延イベントの処理が発生しないことがその単調特性によって保証される。
  • したがって、T以前のすべての集計を正しく発することができる。
    • (matsu_chara: 遅延イベントは捨てられるけど、それは仕方ないということで完全性を主張していそう)