すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:May 08, 2026

従来のデータウェアハウスアーキテクチャ(Lambda アーキテクチャや Kappa アーキテクチャなど)には、主に以下の 3 つの課題があります。バッチ処理とストリーミング処理を別々のフレームワークで実装するため、開発およびメンテナンスコストが高くなること、複数のデータコピーによるストレージ効率の低下、レイヤー間でロジックやスキーマが揃っていないことによる一貫性の問題です。これらの課題を解決するために、Realtime Compute for Apache Flink ではマテリアライズドテーブルを導入しました。この機能は、データの鮮度(日次から数分単位まで)とクエリ文に基づいて自動的にテーブルスキーマを導出し、継続的に更新されるデータパイプラインを構築します。これにより、バッチ処理とストリーム処理のロジックが統合され、冗長なデータコピーが削減されるだけでなく、エンドツーエンドでデータ処理ロジックとテーブルスキーマの一貫性も確保され、リアルタイムデータウェアハウスのメンテナンスが大幅に簡素化されます。

基本概念

データの鮮度

  • 定義:データの鮮度はマテリアライズドテーブルの重要な属性です。これは、マテリアライズドテーブルの内容がベーステーブルの更新に対して最大でどの程度遅れてよいのかを定義します。ただし、これは保証ではなく、Flink が達成を目指す目標値です。データの鮮度は更新頻度を決定し、自動化されたデータパイプラインの管理において不可欠です。

  • 目的

    • 更新モード(継続的または完全)を決定します。

    • データの鮮度とリソース消費のバランスを取ります。たとえば、分単位のデータ鮮度はリアルタイムダッシュボードに最適ですが、日次または時間単位のデータ鮮度はバッチ分析に適しています。

更新モード

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

更新モード

説明

可視性

適用シナリオ

継続的モード

ストリーミングジョブを通じて、マテリアライズドテーブルのデータをインクリメンタルに更新します。

低遅延を実現するために即座に更新が反映されるか、一貫性を確保するためにチェックポイント完了後に更新が反映されます。

リスク管理やリアルタイムレコメンデーションなどのリアルタイムアプリケーションに最適です。

完全モード

スケジューラが定期的に(日次または時間単位で)バッチジョブをトリガーし、マテリアライズドテーブルのデータを完全に上書きします。デフォルトではテーブルレベルで上書きが行われますが、パーティションフィールド(時間パーティションなど)が定義されている場合は、パーティションレベルで上書きが行われ、毎回最新のパーティションのみが更新されます。

完全更新が完了した後にデータが可視になります。

既存データのバックフィルや定期レポートの生成などのシナリオに適しています。

クエリ定義

Flink SQL のすべてのクエリがサポートされており、データソースおよび計算ロジックの定義に使用できます。

動的更新

  • 継続的モードでは、クエリ結果がリアルタイムでマテリアライズドテーブルに反映されます。

  • 完全モードでは、クエリ結果がマテリアライズドテーブルを上書きして精度を確保します。

スキーマ

マテリアライズドテーブルのカラム名および型は、クエリから自動的に導出され、手動での宣言は不要です。

メリット

  • プライマリキーを明示的に宣言することで、クエリパフォーマンスを最適化できます。

  • パーティションキー(時間など)を定義することで、レイヤーごとにデータを整理し、更新効率を向上させます。

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

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

マテリアライズドテーブル C の鮮度が 30 分に設定されていると仮定します。そのソースであるマテリアライズドテーブル A が更新されると、Flink は 30 分以内にマテリアライズドテーブル C を可能な限り速やかに更新しようと試みます。マテリアライズドテーブル C のダウンストリームにあるマテリアライズドテーブル(E や F など)の鮮度は、マテリアライズドテーブル C の鮮度の正の整数倍(例:60 分または 90 分)である必要があります。鮮度の値を X 分から Y 時間に増やす(上限は 1 日)ことで、更新頻度が低下し、リソース消費を抑えることができます。

利用シーン

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

  • 既存データのバックフィル

    データ伝送遅延などの問題により、最終的なデータが部分的に歪むことがあります。従来は、このような既存データを修正するにはバッチジョブが必要でした。マテリアライズドテーブルでは、オンデマンドでの更新機能により、特定のマテリアライズドテーブルおよびそのすべてのダウンストリーム依存テーブルの更新を手動でトリガーできます。

  • データ処理ロジックおよびテーブルスキーマの統一

    Lambda アーキテクチャでは、既存データとリアルタイムデータが別々のシステムに格納されるため、それらの処理ロジックおよびデータをホストするテーブルのスキーマを揃えることが困難です。マテリアライズドテーブルを使用すると、データは単一のコピーのみが保存されるため、複雑な結合や計算が不要になります。この機能により、ストレージ効率が向上するだけでなく、バッチ処理とストリーム処理のロジックが整合し、既存データとリアルタイムデータをホストするテーブルのスキーマも統一されます。

  • 柔軟なデータ鮮度を持つ動的ダッシュボードの構築

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

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

参考文献

説明

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

このトピックでは、マテリアライズドテーブルの作成方法、既存データのバックフィル方法、マテリアライズドテーブルのデータ鮮度の変更方法、およびマテリアライズドテーブルのデータリネージの確認方法について説明します。

マテリアライズドテーブル:ストリーム・バッチ統合型データレイクハウスの構築

このトピックでは、マテリアライズドテーブルと Apache Paimon テーブルを使用してストリーム・バッチ統合型データレイクハウスを構築する方法について説明します。また、マテリアライズドテーブルの鮮度を調整してバッチ実行モードからストリーミング実行モードに切り替え、リアルタイムデータ更新を実現する方法についても説明します。

参考資料