輪読会ページ

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

発表者

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

7章前半の資料

Streaming Systems 輪読会: Ch.7 The Practicalities of Persistent State (前半担当)

Generalized State (p.184-199)

<aside> ℹ️ 主旨

• 前半部分で見てきたステートは処理系が暗黙的に作るもの。以下の2通りがあった

(1) Row Grouping (そのまんまグルーピング): ウィンドウに入ってきたレコードをそのままステートとして保存。トリガーが来たら集約演算をする (2) Incremental Combining (逐次合算): 集約演算が結合法則と交換法則を満たす場合に、レコードではなく部分計算結果をステートとして保存。トリガーが来たら部分計算結果をさらに集約

• もっと複雑でユースケースに即したステートと、トリガーよりも柔軟なステートへの演算発火方法がある。それを説明

</aside>

<aside> ℹ️ まとめ方 書籍では以下の順序で説明されている:

(1) Generalized Stateの良さ（3つのflexibility） (2) Generalized Stateのユースケースの要件（広告コンバージョン計測） (3) ユースケース実現のコードと説明

(3)でコードで使われる要素技術が判明するまで、(1)の「何言ってんだ 🤔」感が拭えずつらかったので、このまとめでは以下の順でまとめる:

(i) Generalized Stateの良さ（3つのflexibility）と、対応する要素技術 (ii) Generalized Stateのユースケースの要件と、要素技術を使ってどう実現するかのざっくりとした説明 (iii) 要素技術が説明どおりに使われていることが実感できる箇所のコード抜粋 (iv) (i)の良さ再確認

</aside>

Generalized Stateの良さ1: Flexibility in data structures

• ステートとして使えるデータ構造が柔軟
  • 例:
    • MapState <String, Visit> (VisitはちょっとしたBeamの制約 (コーダー実装) があるだけの独自クラス)
    • SetState <Visit>
    • ValueState <Instant> (InstantはJavaの joda のやつ。Beam Java SDKがコーダー実装をpredefineしてるから使える)
  • 暗黙のステートだったら「レコードそのまんま」か「逐次合算するための途中集約結果」のみ
• 要素技術:
  • 上述の {Map,Set,Value}State などの型が用意されている

Generalized Stateの良さ2: Flexibility in write and read granularity

• 前提知識:
  • ストリーム処理は分散実行されている
  • ステートを持つPTransformも分散実行されている
  • ステートは .read() しなければアクセスできない
    • ノードのメモリに運良くステートの最新値が載っていたらそれ使うだろうし、そうでなければ .write() で永続化されたステート（≒チェックポイント）からステート最新値取りに行く必要がある
      • なるべくメモリから読めば済むようなスケジューリングを各種ストリーム処理エンジン（Flinkとか）は頑張っているはず
• .read(), .write() を独自定義のPTransformの中で手書き発行できるのが柔軟さ
  • .read() とかを条件分岐の中で打てるので、必要なときだけステートアクセス（NW越しにディスク読んだりして重たいかも）できる
• 要素技術:
  • <ステート型>.read(), <ステート型>.write(<ステート値>)
  • 例:
    • minGoalState .read();
    • minGoalState.write(visit.timestamp());

Generalized Stateの良さ3: Flexibility in scheduling of processing