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

Realtime Compute for Apache Flink:Manage materialized tables

最終更新日:May 09, 2025

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

主要な概念

データの鮮度

  • 定義: データの鮮度は、マテリアライズドテーブルの重要な属性です。マテリアライズドテーブルの内容がベーステーブルの更新に遅れることができる最大時間を定義します。データの鮮度は保証ではありません。代わりに、Flink が達成しようとする目標です。データの鮮度は更新頻度を決定し、自動データパイプラインの管理に不可欠です。

  • 目的:

    • 更新モードを決定します: 連続または完全。

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

更新モード

マテリアライズドテーブルは、2 つの更新モードをサポートしています。連続モードと完全モードです。

更新モード

説明

可視性

適用可能なシナリオ

連続モード

ストリーミングジョブを介してマテリアライズドテーブルデータを増分更新します。

更新は、低レイテンシを提供するためにすぐに表示されるか、整合性を確保するためにチェックポイントの完了後に表示されます。

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

完全モード

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

データは、完全更新が完了した後に表示されます。

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

クエリの定義

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

動的更新:

  • 連続モードでは、クエリ結果はリアルタイムでマテリアライズドテーブルに取り込まれます。

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

スキーマ

マテリアライズドテーブルの列名と型は、クエリから自動的に導出されるため、手動で宣言する必要はありません。

メリット:

  • プライマリキーを明示的に宣言して、クエリのパフォーマンスを最適化します。

  • パーティションキー(時間など)を定義してデータを階層的に整理し、更新効率を向上させます。

マテリアライズドテーブルのしくみ

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

マテリアライズドテーブル C の鮮度が 30 分に設定されているとします。ソースであるマテリアライズドテーブル A が更新されると、Flink は 30 分以内にできるだけ早くマテリアライズドテーブル C を更新しようとします。E や F などのダウンストリームのマテリアライズドテーブルの鮮度は、マテリアライズドテーブル C の鮮度の正の倍数(60 分または 90 分など)である必要があります。鮮度の値を X 分から Y 時間(最大 1 日)に増やすと、更新頻度が減るため、リソース消費が削減されます。

シナリオ

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

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

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

  • データ処理ロジックとテーブルスキーマの統合。

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

  • 適応可能なデータ鮮度を備えた動的ダッシュボードの構築。

    動的ダッシュボードでは、多くの場合、ビジネスシナリオごとに異なるデータ鮮度が必要になります。マテリアライズドテーブルは、鮮度の値を変更することで、更新間隔を毎日から数秒ごとまで簡単に調整できるため、このニーズに対応します。このアプローチにより、個別のリアルタイムパイプラインを構築および維持する必要がなくなります。

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

参照

説明

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

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

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

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

参照