本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
Apache Flink® コミュニティに参加して、強化されたコンテキスト情報を活用したウィンドウ処理をよりインテリジェントにしよう
はじめに
このような状況に遭遇したことはありますか？クラス担任として、毎時生徒の出席を追跡する必要があります。現在のシステムは、その時間に何人の生徒が出席しているかだけを教えてくれますが、次のような疑問にも答えたいと思うかもしれません：誰か遅刻した生徒はいましたか？この時間に何回出席を確認しましたか？同様の状況がFlinkのウィンドウ処理にも存在します。現在のウィンドウ関数は、ウィンドウ内のデータのみを認識しており、そのデータが定時に到着したのか遅れて到着したのか、またはこのウィンドウがこれまでに何回処理されたのかについては分かりません。FLIP-2は、ウィンドウ関数により多くのコンテキスト情報を提供することで、「木を見て森を見ず」という問題を解決することを目指しています。
古いアプローチの何が問題だったのでしょうか？
現在のウィンドウ関数（WindowFunction）では情報へのアクセスが非常に限られており、不完全なレポートのようなものです：
問題1: 情報の制限
現在、ウィンドウ関数が知っているのは以下の3つだけです：
- どのウィンドウがトリガーされたか（例えば、午後1時から2時の間）
- このウィンドウのキーは何であるか（例えば、数学の授業）
- ウィンドウ内にどのようなデータがあるか（例えば、出席している生徒のリスト）
問題2: コンテキストの欠如
教師が「誰が出席しているか」だけでなく「誰が遅れているか」も知りたいように、ウィンドウ処理中にもっと多くの情報を必要とします。データが定時に到着したのか遅れたのか、計算が自然に時間によってトリガーされたのか、それとも他の理由で早期にトリガーされたのか、またこのウィンドウがこれまでに何回処理されたのかを知りたいのです。この情報は実世界のアプリケーションにおいて重要です。例えば、eコマースシステムでは通常の注文と遅延注文を区別する必要がありますし、監視システムではアラームが何回トリガーされたかを知る必要があります。データ分析では、どのデータが履歴バックフィルであるかを明確にマークする必要があります。これらすべてのシナリオでは、ウィンドウ関数がより多くのコンテキスト情報を提供することが求められます。
FLIP-2はこれをどのように解決するのでしょうか？
まず、古いアプローチと新しいアプローチの比較を見てみましょう：
FLIP-2のソリューションは巧妙で、2つの革新を含んでいます：
ステップ1: 新しいウィンドウ処理インターフェースの設計
まず、FLIP-2はProcessWindowFunctionという新しいインターフェースを設計しました。その主な特徴は、コンテキストオブジェクトの導入です。これは、各クラス担任にスマートアシスタントを与えるようなもので、ただ「誰がここにいるか」だけでなく、もっと多くの情報を提供できます。この新しいインターフェースは非常に柔軟で、いつでも新しい機能を追加できるため、スマートアシスタントがアップグレードされてより多くの情報を提供できるようなものです。
ステップ2: より多くのコンテキスト情報の追加
FLIP-2は、この新しいインターフェースに2種類の重要な情報を追加することを計画しています：
ウィンドウトリガーの理由
- ON_TIME: データが定時に到着し、処理された
- EARLY: 何らかの理由で結果を早く必要とした
- LATE: 遅れて到着したデータの処理
ウィンドウトリガーのカウント
- 各トリガーにはシーケンス番号が与えられる
- ウィンドウが何回トリガーされたかを追跡するのに役立つ
- 異なる処理バッチを区別するのに便利
次のシーケンス図を通して、異なるウィンドウトリガーのシナリオを理解しましょう：
このシーケンス図を詳しく説明します：
まず、正午から始まるタイムウィンドウが作成され、正午から午後1時までのデータを処理します。午前12時30分に最初のデータバッチが到着します。時にはウィンドウが終わるまで結果を待つことができない場合があります。例えば、リアルタイムモニタリングシステムでは早期に異常を検出したいですし、リアルタイムダッシュボードでは現在の統計を迅速に表示する必要があります。そのため、システムは早期計算トリガー（EARLYトリガー）をサポートしており、このトリガーにはid=1が付与されます。これは、教師が授業中に途中で出席を取り、出席率が低すぎるかどうかを迅速に特定するようなものです。
午前12時45分に新しいデータが到着します。システムは別の早期計算をトリガーし（EARLYトリガー）、今回はid=2が付与されます。これは、教師が再度出席を取ることに似ています。
時間が午後1時に達すると、ウィンドウが正式に終了します。システムは通常のトリガー（ON_TIMEトリガー）を実行し、id=3が付与されます。これは、教師が授業の最後に最終的な出席を取ることに相当します。
興味深いことに、午後1時10分にさらにデータが到着します。ウィンドウはすでに終了していますが、システムはこの遅れて到着したデータを処理し（LATEトリガー）、id=4が付与されます。これは、遅れて到着した生徒を記録することに似ています。
この例を通じて、新しいウィンドウ関数の力が分かります。それはデータ内容だけでなく、データがいつ到着したか（定時か遅れか）や処理回数を記録でき、データ処理をより柔軟かつインテリジェントにします。
実装方法
実装は主に2つの部分で構成されています：
新しいインターフェースの設計:java
public abstract class ProcessWindowFunction {
public abstract void process(KEY key, Context ctx, Iterable elements,
Collector out);
public abstract class Context {
public abstract W window(); // ウィンドウ情報
public abstract int id(); // トリガー回数
public abstract FiringInfo firingInfo(); // トリガー理由
}
}
内部実装の変更:
古いインターフェースとの互換性を維持しつつ、トリガー回数を追跡するためのカウンターを追加し、ウォーターマークチェックを使用してデータ到着ステータスを決定しました。この設計により、後方互換性を確保しながら新しい機能を提供しています。
どのような利点をもたらすのでしょうか？
これらの改善は、Flinkにとって具体的な利点をもたらします。まず、データ処理がより細分化されます。これにより、到着時間に基づいてデータを異なる方法で扱うことができるようになります：遅れたデータに対して特別な処理を行い、通常のデータと補足データを区別し、より複雑なビジネスシナリオをサポートします。第二に、監視とデバッグがより便利になります。新しい情報により、各ウィンドウが何回トリガーされ、データがいつ到着したかを明確に把握できます。この情報は問題調査