Google Cloud Professional Data Engineer試験でストリーミング問題が出ると、多くの人がつまずくのが「トリガー」の概念です。特にAfterWatermarkにEarlyトリガーやLateトリガーをどう組み合わせるかが分かりにくく、私も学習中に何度も混乱しました。本記事では、試験中に迷わないためにAfterWatermarkとEarly/Lateトリガーの役割を整理し、典型的な出題パターンを解説します。
なぜトリガーで混乱するのか
- 固定・スライディングウィンドウは直感的に理解できるが、トリガーは動きがイメージしづらい
- 「Watermark」という概念が抽象的で、実データとのズレをどう扱うかが難しい
- 試験では「遅延データ」「部分的な早期結果」「最終結果」など曖昧な条件で出題される
AfterWatermarkの基本
Watermarkとは何か
Watermarkは「システムがここまでのイベントタイムのデータはすべて到着したと推定する」境界です。遅延データが来る可能性は残りますが、通常はこの時点でウィンドウを閉じて結果を確定させます。
AfterWatermarkトリガーの挙動
AfterWatermarkは、Watermarkがウィンドウの終了点を越えたときに結果を出力するトリガーです。これだけを指定した場合、遅れて到着したデータは集計に反映されません。
Earlyトリガーの役割
部分的な中間結果を出す
Earlyトリガーは「ウィンドウが閉じる前に暫定結果を出したい」場合に利用します。例えば、一定の処理時間が経過するごとに中間集計を出力する、といった動作が可能です。
試験で問われるケース
問題文に「ユーザーはなるべく早く暫定集計を見たいが、最終的な正しい集計も必要」と書かれていたら、AfterWatermarkとEarlyトリガーの組み合わせが正解です。
Lateトリガーの役割
遅延データの取り込み
Lateトリガーは、ウィンドウが閉じた後に遅延して到着したデータを再度集計する仕組みです。これを使うと「確定済みの結果が後から更新される」ことになります。
Late を効かせるには withAllowedLateness の設定が実質必須と考えた方がよさそうです。繰り返し発火時に値を積み上げる(accumulating)か破棄する(discarding)かは Accumulation mode で制御するようです。
試験で問われるケース
問題文に「遅延して到着したイベントも可能な限り集計に反映したい」とあれば、Lateトリガーを設定するシナリオです。
試験での判断基準
- 暫定結果が必要 → Earlyトリガー
- 遅延データを反映したい → Lateトリガー
- 最終的な確定結果を出す → AfterWatermark
- すべて必要 → AfterWatermark + Early + Late の組み合わせ
一次情報リンク:
– Beam Triggers: https://beam.apache.org/documentation/programming-guide/#triggers
– Window accumulation modes: https://beam.apache.org/documentation/programming-guide/#window-accumulation-modes
– Dataflow ウィンドウとトリガー: https://cloud.google.com/dataflow/docs/concepts/streaming-with-cloud-dataflow
実務と試験での整理の違い
実務では、Early/Lateトリガーを多用すると結果更新が多発し、下流システムの負荷やユーザー体験に影響するため、必要最小限にとどめる設計が一般的です。しかし試験問題では「ユーザー要件に正しく応える」ことが第一なので、問題文に書かれたニーズを素直にトリガーにマッピングするのが正解です。
まとめ
トリガーの混乱は「どのタイミングで結果を出すか」を意識すれば整理できます。AfterWatermarkは確定結果、Earlyは暫定結果、Lateは遅延データの補正。試験では、要件に合わせてこれらを組み合わせられるかがポイントです。読了後は公式ドキュメントのトリガー図解を確認し、自分でシナリオを考えてみると理解が定着します。