マテリアライズドテーブルの管理 - Realtime Compute for Apache Flink

ラムダアーキテクチャやカッパアーキテクチャなどの従来のデータウェアハウスアーキテクチャには、主に 3 つの課題があります。バッチとストリーミングのフレームワークを分離して運用することによる保守コストの増大、重複したデータコピーによるストレージの無駄、レイヤー間でロジックがずれることによる整合性リスクです。Realtime Compute for Apache Flink のマテリアライズドテーブルは、クエリ文からテーブルスキーマを自動的に導出し、設定可能なデータの鮮度の目標値 (1 日単位から数秒単位まで) に基づいて、継続的に更新されるデータパイプラインを作成することで、これらの課題に対処します。バッチ処理とストリーム処理を単一の経路に統合することで、マテリアライズドテーブルは冗長なデータコピーを排除し、エンドツーエンドで一貫したデータ処理ロジックとスキーマを保証します。これにより、リアルタイムデータウェアハウスの保守を簡素化できます。

基本概念

データの鮮度

定義：データの鮮度は、マテリアライズドテーブルの重要な属性です。マテリアライズドテーブルとベーステーブルの間で許容される最大遅延を定義します。これはベストエフォートの目標であり、保証ではありません。Flink はこの値を使用して、自動化されたデータパイプラインの更新頻度を決定します。
目的：
- 更新モード (継続モードまたはフルモード) を決定します。
- データの鮮度とリソース消費のバランスを取ります。たとえば、分単位の鮮度はリアルタイムダッシュボードに適しており、日次または時間単位の鮮度はバッチ分析に適しています。

更新モード

マテリアライズドテーブルは、継続モードとフルモードの 2 つの更新モードをサポートします。

更新モード	説明	可視性	適用シナリオ
継続モード	ストリーミングジョブによって、マテリアライズドテーブルを増分更新します。	更新は、低レイテンシーが求められる場合は即時に、整合性が求められる場合はチェックポイント完了後に可視になります。	リスク管理やリアルタイムレコメンドなどのリアルタイムアプリケーションに最適です。
フルモード	スケジューラが定期的にバッチジョブ (日次または時間単位) をトリガーし、マテリアライズドテーブルを完全に上書きします。デフォルトでは、上書きはテーブルレベルで行われます。時間パーティションなどのパーティションフィールドが定義されている場合、上書きはパーティションレベルで行われ、毎回最新のパーティションのみが更新されます。	データは、フル更新の完了後に可視になります。	履歴データのバックフィルや定期レポートの生成などのシナリオに適しています。

クエリ定義

任意の Flink SQL クエリを使用して、データソースと計算ロジックを定義できます。

動的更新：

継続モードでは、クエリ結果がリアルタイムでマテリアライズドテーブルに取り込まれます。
フルモードでは、クエリ結果がマテリアライズドテーブルを上書きして、正確性を確保します。

スキーマ

列名と型はクエリから自動的に導出されるため、手動で宣言する必要はありません。

メリット：

主キーを明示的に宣言すると、クエリパフォーマンスが最適化されます。
(時間などの) パーティションキーを定義すると、データが階層化および整理され、更新効率が向上します。

マテリアライズドテーブルの仕組み

マテリアライズドテーブルを作成する際は、FRESHNESS パラメーターと AS <select_statement> 句を指定する必要があります。Flink エンジンはテーブルスキーマを自動的に導出してカタログに登録し、FRESHNESS の値に基づいてストリーミングまたはバッチの更新ジョブを作成します。

たとえば、マテリアライズドテーブル C の鮮度が 30 分の場合、Flink はマテリアライズドテーブル A が更新されてから 30 分以内に、可能な限り近いタイミングで C を更新しようとします。ダウンストリームのマテリアライズドテーブル (E や F など) では、C の鮮度の正の倍数となる鮮度値 (60 分や 90 分など) を使用する必要があります。鮮度値を増やす (たとえば X 分から Y 時間へ、上限は 1 日) と、更新頻度が下がり、リソース消費を削減できます。

ユースケース

バッチ処理とストリーム処理を統合することで、マテリアライズドテーブルは次のユースケースにおいて、技術面およびコスト面でのメリットを提供します。

履歴データのバックフィル。

最終データは、伝送遅延などの問題により、部分的に歪む場合があります。履歴データの修正には、従来は別途バッチジョブが必要でした。マテリアライズドテーブルはオンデマンド更新をサポートしており、特定のテーブルと、そのすべてのダウンストリーム依存先に対して、手動で更新をトリガーできます。
データ処理ロジックとテーブルスキーマの統一。

ラムダアーキテクチャでは、履歴データとリアルタイムデータが別々のシステムに存在するため、処理ロジックとテーブルスキーマの整合を取ることが困難です。マテリアライズドテーブルはデータのコピーを 1 つだけ保存し、複雑な結合や計算を排除します。これにより、ストレージ効率が向上するとともに、バッチ処理とストリーム処理のロジック、および履歴データとリアルタイムデータのスキーマを統一できます。
データの鮮度を柔軟に調整できる動的ダッシュボードの構築。

動的ダッシュボードでは、ビジネスシナリオごとに異なるデータの鮮度レベルが求められることがよくあります。マテリアライズドテーブルでは、鮮度値を変更するだけで、更新間隔を日次から数秒単位まで調整できます。個別のリアルタイムパイプラインを構築して保守する必要はありません。

マテリアライズドテーブルの使用

参照	説明
マテリアライズドテーブルの作成と使用	マテリアライズドテーブルの作成方法、履歴データのバックフィル、データの鮮度の変更方法、データリネージの確認方法について説明します。
マテリアライズドテーブル（ストリームバッチ統合データレイクハウスの構築）	マテリアライズドテーブルと Apache Paimon テーブルを使用してストリームバッチ統合データレイクハウスを構築する方法、および鮮度を調整してバッチ実行モードからストリーミング実行モードに切り替え、リアルタイムのデータ更新を実現する方法について説明します。

Realtime Compute for Apache Flink:マテリアライズドテーブル