Skip to content

Instantly share code, notes, and snippets.

@kimutansk

kimutansk/StreamPipeline_Watermark_abst.md

Created June 9, 2016 08:16
Show Gist options
  • Save kimutansk/121a758fc0a150167bb1d919ba5a57ed to your computer and use it in GitHub Desktop.
Save kimutansk/121a758fc0a150167bb1d919ba5a57ed to your computer and use it in GitHub Desktop.
Download ZIP
ストリーム処理パイプラインのWatermark
Raw
StreamPipeline_Watermark_abst.md

ストリーム処理の"Watermark"についての話

  • Watermarkとは？
    • 「どこまで処理したか？」を示す区切り
    • ストリームパイプライン上の各オペレータが保持
  • どのような利点があるか？
    • 「ここまでは処理した」ということが明確になる
    • 結果、障害発生時にどこから再実行すればいいかも明確になる
    • 上記の性質を基に、多様なスライディングウィンドウを定義利用可能
  • どう扱うか？
    • 各オペレータごとにInputWatermarkとOutputWatermarkを保持
      • InputWatermark:あるオペレータに対して送信されていないもっとも古いメッセージ
      • OutputWatermark:あるオペレータが処理完了していないもっとも古いメッセージ
    • 上流のオペレータのWatermarkと、自分が処理中のデータから求めることができる
  • 求められる要件
    • データソース側にWatermarkを指定してデータを取得する機構が必要
      • Kafka
      • Kinesis
      • Google Cloud PubSub
  • 遅延到着メッセージ"late data"への対応
    • Watermarkをうった後に更に遅れてメッセージが到着
    • 発生するかどうかはだれも予測できない
    • "late data"を受信した場合にそれを扱う特殊機構が必要(Triggers)
  • データソースで気を付けるべきこと
    • データソースに入力された時刻≠実際の発生時刻
    • データソース側で割り振った時刻を扱うケースが多いが、厳密に扱う必要がある場合は実時刻を用いる
      • その場合に"late data"への対応が必要となる
  • System watermark
    • メッセージにSystem側でも時刻を割り振った場合、それと実際に処理中のメッセージの時刻を比較
    • 比較することで遅延を算出可能

参照

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment