3. Watermarks 後半

Watermark Propagation and Output Timestamps

タイムスタンプについて
第２ステージのタイムスタンプは第１ステージのwindowの終わりが与えられている
他にもタイムスタンプの選択肢はある
- 原理的には最も古い非遅延データのタイムスタンプ〜無限までとれる
選択肢
- ウィンドウの終端
  - ウィンドウの代表値として出力タイムスタンプを利用する場合のみ安全
  - すべての選択肢の中で最もスムーズなwatermarkの進行を可能にする（後述）
- 最初の非遅延要素のタイムスタンプ
  - watermarkを可能な限り保守的にしたい場合に有効な選択肢
  - watermarkの進行は妨げられる
- 特定の要素のタイムスタンプ
  - システム依存で特定要素のタイムスタンプを採用するぼが良いこともある
  - 例
    - クエリと結果をjoinする場合
    - クエリのタイムスタンプを採用すると良いかも
  出力タイムスタンプをearliest elementにした場合との比較
  - 第２ステージのインプットのタイムスタンプが異なる
  - watermarkの遅延
    - 図3-6はwatermarkの進行が遅くなっている
      - ProcessingTime 12:07手前をみたときに点線がより左にある（＝古いEvent Timeまでしか処理してない）
    - 第一段階の出力ウォーターマークが、各windowの先頭要素のタイムスタンプに基準になるため
    - あるウィンドウが実体化された後にのみ、出力ウォーターマーク（＝下流の入力ウォーターマーク）が進む
  - semanticの違い
    - 第２ステージへの入力のタイムスタンプが異なる(= 平均値の計算に参入されるセッションが異なる）ため、出力される平均値が変わる
    - どちらかが正しいわけではないが、違うということは認識しよう

The Tricky Case of Overlapping Windows

sliding windowについて考える
出力タイムスタンプを最も古い要素に設定する方法は下流のwatermarkが遅延しやすい
sliding windowでのかんたんな例
- 3つの連続したwindowで処理
- 最初のwindowが1stステージで完了
- ⇒ 最初のwindowが2ndステージで完了
- ⇒ 少し遅れて次のwindowが1stステージで完了…
出力timestampをpane内の最初の非遅延データのtimestampにすると実際には次のことが起こる
- 1番目のwindowが1stステージで完了
- ⇒ 2ndステージの1番目のwindowは完了できないまま残る。
  - 2番目3番目のtimestampもfirst nonlate elementなので結構古い値がくる。そのためこれらの値を待ってから2ndステージを始める必要があるので1番目のwindowの出力はしばらくholdされる
- ⇒ 2番目3番目のwindowが終わってからようやく2ndステージの処理が始まる（ここで1~3番目のwindowの1stステージでの出力が処理される）
この処理結果は正しいが不必要に遅れて処理されてしまう。
- beamではwindowが重なっている場合はwindows N+1の出力タイムスタンプが常にwindow Nの終了時点より大きくなるような特別ロジックを用意している

Percentile Watermarks

いままではアクティブメッセージの最小イベント時間に着目してきた
- 全部を処理したい場合はこれでOK
- 一方でアクティブなメッセージの分布に着目するとよりきめ細かいトリガー条件を作成できる
- ⇒ percentile watermark
- 90パーセンタイルで問題ないのであれば異常値を無視できる

Untitled

当然低いパーセンタイルにwatermarkを設定すればそれだけ多くのデータが遅延データとして扱われることになる

Processing-Time Watermarks

event時間に関するwatermarkを見てきた
- oldデータと実時間の関係（遅れ具合）を見ることができた
これだけだと古いデータと遅延データの関係がわからない
- 1時間前のデータを高速に処理しているリアルタイムなストリーム処理
- リアルタイムなデータを処理しようとして1時間遅れているシステム
Processing-Time watermarkは上記の２つを区別するためのもの