はじめに
ストリーム処理において、原始イベントデータを參照データと統合する「データ豊富化（Data Enrichment）」は、リアルタイム分析や即時意思決定の基盤となる重要なプロセスです。Apache Flinkはその高パフォーマンスと柔軟なアーキテクチャにより、低遅延と高スループットを両立させることが可能で、特に金融、メディア、IoTなどの分野で広く採用されています。本記事では、Flinkを用いたデータ豊富化の主要なパターンとその実裝方法、性能設計のポイントを解説します。
データ豊富化の背景と課題
データ豊富化は、イベントデータに外部參照データを結合し、より包括的な視點で分析を可能にする技術です。典型的な応用例には、株式取引における最大買値・売値の計算、OTTメディアの地理的分析、センサーからのデータ補完、ECでの顧客情報統合などが挙げられます。しかし、リアルタイム処理では「低遅延」と「高スループット」のバランスを取ることが課題であり、Flinkはその両立を実現するための強力なツールとして注目されています。
データ豊富化の主なパターン
1. 參照データのキャッシュ
靜的參照データ
- 実裝方法：參照データを各サブタスクのメモリに事前にロード
- 利點：低遅延と高スループットを実現
- 制限：データサイズが大きい場合、メモリ不足を引き起こす可能性
動的參照データ
- 実裝方法：Flinkの狀態後端（HashMap/RocksDB）を用いたパーティション化キャッシュ
- 關鍵技術：
- Keyed Stream：特定のキー（例：航空機番號）でパーティション処理
- Keyed State：各キーの狀態は対応するサブタスクのみで有効
- 利點：大規模データにも対応可能、クラスタスケールでの拡張性
- 課題：狀態の有効期限（TTL）管理が必要
2. 同期/非同期検索
同期検索
- 実裝方法：イベントごとにブロッキングAPI呼び出し
- 問題點：処理がブロッキングされ、スループット低下を引き起こす
非同期検索（Async I/O）
- 実裝方法：AsyncFunctionを用いた非同期リクエスト
- 特徴：
- 無順序（unordered）または順序（ordered）処理の選択
- 超時設定とリクエスト容量制限
- 利點：ブロッキングを迴避し、スループット向上
- 制限：外部システムの負荷管理が必要
キャッシュと検索の組み合わせ
- 実裝方法：API呼び出し後に狀態にキャッシュし、TTLを設定
- 利點：API呼び出し回數を削減、狀態管理を簡略化
- 適用場面：最新データを保証する必要があるケース（例：顧客情報更新）
3. 參照データをストリームとして扱う
- 実裝方法：Change Data Capture（CDC）で參照データの変更をキャプチャし、Kafkaに書き込み
- 処理フロー：
- Kafka Connectでデータベース変更イベント（例：MySQL Binlog）をKafkaに転送
- Flinkアプリケーションが參照データストリームと原始イベントストリームを統合
- Co-process Functionでリアルタイムに合併
- 關鍵技術：
- CDC統合：Kafka Connectでデータベース変更を抽出
- 狀態管理：Flink狀態に最新の參照データを保存
- 遅延イベント処理：イベント発生時刻と參照データ更新時刻の一致を確保
- 実例：
- データソース：MySQL（Aurora）で參照データ（為替レート）を保存
- プロセスフロー：
- Kafka Connectで変更イベントをKafkaに転送
- Flinkアプリケーションが參照データストリームと原始註文ストリームを読み込む
- 狀態に最新の為替レートを保存し、註文イベントをリアルタイムに豊富化
- テストケース：
- 遅延イベント（註文生成時刻が參照データ更新時刻より古い）の生成
- 正確な過去の為替レートとの一致を検証
技術的詳細
- 狀態後端：HashMap（メモリ）/ RocksDB（永続化）
- 狀態タイプ：ValueState、ListState、MapState
- 非同期処理：AsyncFunctionによる複數リクエストの並列処理
- TTLメカニズム：狀態の有効期限を制御し、狀態の膨張を防ぐ
- 順序処理：すべての前処理イベントが完了するまでイベントをバッファリング
データベースとKafkaトピックの設定
- MySQLデータベース構造：
- テーブル名：rates
- フィールド：currency（USD/Euro/INR/GBP）、exchange_rate、last_updated_time
- Kafkaトピック：
- orders_topic：原始註文イベント（order_id、price、timestamp）
- rates_topic：DebeziumコンネクタでMySQLのratesテーブルを読み込み、Kafkaに書き込む
Flinkアプリケーションの実行フロー
- データストリームの接続：
- Kafkaからorders_topicとrates_topicのデータストリームを読み込む
- 2つのDataStream（ordersStream、ratesStream）を生成
- 狀態管理とデータ豊富化：
- KeyedStreamでキーベース処理：currencyでordersStreamとratesStreamをkeyBy操作
- MapState<StateKey, List>で各currencyの履歴為替データを保存
- 遅延イベント処理：註文イベントのtimestampが為替データの更新時刻より古い場合、狀態內の最も古い有効な為替レートを使用
- データ処理ロジック：
- coProcessFunctionで雙方向ストリームを処理：
- processElement1（註文イベント処理）：註文timestampと為替データtimestampを比較し、條件を満たす最新の為替レートを選択
- processElement2（為替イベント処理）：新規為替データを狀態に保存し、後続の註文イベントに適用
重要な技術実裝
- 狀態管理：MapStateで各currencyの履歴データを保存
- タイムスタンプ処理：註文イベントのtimestampと為替データのlast_updated_timeを比較
- ストリーム処理モード：keyBy操作で雙方向ストリームを関連付け、coProcessFunctionでイベント駆動の狀態更新
パターンの特徴と適用場面
| パターンタイプ |
特性説明 |
適用場面 |
| 実時データ豊富化 |
新しい註文と為替データを即時処理 |
即時反応が必要な取引システム |
| 遅延イベント処理 |
過去のデータを保存して遅延イベントを追跡 |
註文生成時刻がデータ更新時刻より古い |
| 狀態駆動更新 |
狀態管理を基にデータをマッチ |
歴史データと現在データの関連処理 |
| 雙方向ストリーム関連 |
キーを基に註文と為替データを関連 |
共通キーを持つデータの処理 |
| イベント時間処理 |
タイムスタンプ比較で正確なマッチ |
精密なタイムスタンプマッチが必要な場面 |
パフォーマンスの考慮點
- 遅延（Latency）：
- 実時処理では狀態アクセスの効率が重要
- イベントタイム比較ロジックが処理速度に影響
- スループット（Throughput）：
- 狀態管理のメモリ使用量が並列処理能力に影響
- 雙方向ストリームのkeyBy操作で過度な分散を避ける
- 拡張性：
- 狀態パーティション戦略がクラスタ拡張性能に影響
- イベントタイム処理ではクロック同期の問題を考慮
結論
Apache Flinkは、データ豊富化のための柔軟で高パフォーマンスなフレームワークとして、リアルタイム処理の課題を解決するための強力なツールです。各パターンの選択は、アプリケーションの要件や外部システムとの連攜に応じて調整が必要です。特に、狀態管理や非同期処理の設計は、低遅延と高スループットのバランスを取る上で重要です。実裝においては、TTL設定や狀態のパーティション戦略を慎重に検討し、スケーラビリティと信頼性を確保することが求められます。