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は遅延データの補正。試験では、要件に合わせてこれらを組み合わせられるかがポイントです。読了後は公式ドキュメントのトリガー図解を確認し、自分でシナリオを考えてみると理解が定着します。