輪読会ページ

Streaming Systems 輪読会 - 第9回 (2022/10/31 19:00〜)

発表者

• 中谷 翔 ( @laysakura で Twitter やら GitHub やら )
• 🚗の会社でデータベース・ストリーム処理・ETLあたりの研究開発
• 車載機とかIoT機器で動くストリーム処理系 SpringQL 作ってる
  • 一緒に作ってくれる人募集中

冒頭部分 (p.175)

• Persistent stateとは: 6章で出てきた「テーブル」のこと。ただし、そのテーブルは永続化されているという要請も追加。
  • 6章復習: テーブルは、ストリーム処理パイプラインの外に元々存在するテーブルの他に、”grouping” オペレーションでストリームからテーブルに変換されるときにできるものだった
  • ※この本ではステートはテーブルだという立場を取るが、テーブルではないステートも色々あると私は考える。オペレーター自身の内部状態など。本来はこういうのもpersistしないとat-least-once以上は実現できないはず

• この章の主題は以下:
  • パイプラインの中でステートを永続化することの必要性を説く
  • パイプラインの中でよくある暗黙的な2種類のステートを紹介
  • 暗黙的なステートではどうしようもないユースケース（広告のコンバージョン）を持ち出し、一般的で明示的な永続化ステートの必要性を説く
  • 一般的で明示的なステートのAPIを、Apache Beamから紹介する

Motivation (p.175-178)

The Inevitability of Failure

• Failure（故障）の例:
  • マシンの故障
  • 計画的なメンテナンス
  • コードの変更
  • 設定ミスによるコマンドの停止

• Unboundedデータを相手取るとき、パイプライン稼働時間は無限になり得る。無限時間故障し得ないなどということはあり得ない
• ステートの永続化 (checkpointing) をしていなければ、故障したときにパイプライン処理中のデータは失われ得る
  • non-grouping (stream → stream) 処理の経過: 入力側のストリームだけ再現できればなんとかなるので、チェックポインティングの必要性は薄い
    • ※実際には、non-groupingなオペレーターがステートを持っているかもしれない（例: マシン温度によって結果を変える）ので、ステートのチェックポイントは必要
  • grouping (stream → table) 処理の経過: テーブルを構築するための過去streamも含めて再現する必要があり、それは膨大になり得る。過去ストリーム全部を再現（保存）することは容量上不可能なことも考えられる。テーブルをチェックポインティングすべき
  • ungrouping (table → stream) 処理の経過: 故障時の入力テーブルの再現が必要であり、groupingと同様の議論
• パイプライン入力が無限列になり得る（つまり入力をすべて再現可能な状態に保全しておくことができない）ことを考えると、チェックポインティングがなければ、at-most-onceしか実現できない
  • unboundedデータでexactly-once, at-least-once を実現するためにはチェックポインティングは必須

• Boundedデータを相手取るケース（バッチ処理）はどうか