非同期マテリアライズドビューの概要
非同期マテリアライズドビューは、ビューの柔軟性と物理テーブルの高い性能を兼ね備えたクエリ高速化の手段です。クエリ結果を事前に計算して保存することで、後続のクエリはマテリアライズされた結果セットを直接利用でき、複雑な SQL を繰り返し実行する負荷を避けられます。
クイックツアー
非同期マテリアライズドビューを使用する前に、次の点を確認してください。
- 業務上、クエリの高速化、ETL の簡素化、レイクハウスの外部テーブルの高速化、または書き込みの最適化が必要ですか？
- クエリは SPJG（SELECT-PROJECT-JOIN-GROUP-BY）パターンに従っていますか？
- データの結果整合性（リアルタイムではない同期）を許容できますか？
- ベーステーブルの Catalog はサポート対象（Internal/Hive/Iceberg/Paimon/Hudi/JDBC/ES）に含まれていますか？
- 変更が少数のパーティションに集中する場合、更新コストを下げるためにパーティション単位の増分更新が必要ですか？
- ベーステーブルに頻繁な挿入、更新、削除がありながら変更行数が少ない場合、Incremental View Maintenance（IVM）は適していますか？
ユースケース
非同期マテリアライズドビューは、主に次の四つのシナリオを対象としています。
| シナリオ | 効果 |
|---|---|
| クエリの高速化と同時実行性能の向上 | クエリ速度を大幅に改善し、同時実行性能を高め、リソース消費を抑えます |
| ETL ワークフローの簡素化 | 抽出、変換、ロード（ETL）のプロセスを簡素化し、開発効率を高めます |
| レイクハウスの外部テーブルに対するクエリの高速化 | レイクハウスアーキテクチャにおける外部データソースへのクエリ速度を大幅に改善します |
| 書き込み効率の向上 | リソース競合を減らし、データ書き込み処理を最適化して、整合性と完全性を確保します |
制限事項
非同期マテリアライズドビューを使用する前に、次の制限事項に注意してください。
- データの整合性：非同期マテリアライズドビューはベーステーブルと結果整合性を保ちますが、リアルタイムには同期できず、リアルタイムの整合性は保証されません。
- ウィンドウ関数：現在、ウィンドウ関数を含むクエリをマテリアライズドビューに基づく形式へ透過的に書き換えることはサポートされていません。
- 複数テーブルのシナリオ：マテリアライズドビューが、クエリより多くのテーブルを結合する場合（たとえば、クエリは t1 と t2 のみを使用し、マテリアライズドビューは t1、t2、t3 を含む場合）、現在は透過的な書き換えをサポートしていません。
- 透過的な書き換えでサポートされない演算子：マテリアライズドビューに
UNION ALL、LIMIT、ORDER BY、またはCROSS JOINが含まれていても、ビュー自体は通常どおり作成できます。ただし、透過的な書き換えには使用できません。 - データ型の制限：現在、
VARBINARY型を使用したマテリアライズドビューの作成はサポートされていません。
仕組み
非同期マテリアライズドビューは、実質的には MTMV 型の内部テーブルです。マテリアライズドビューを作成すると、更新タスクも登録されます。このタスクの実行時に、INSERT OVERWRITE 文を使って最新のデータがマテリアライズドビューに書き込まれます。
更新の仕組み
同期マテリアライズドビューのリアルタイムな増分更新とは異なり、非同期マテリアライズドビューには次の四つの計算粒度があります。
| 更新方法 | 説明 | 適したシナリオ |
|---|---|---|
COMPLETE | マテリアライズドビューの定義 SQL が参照するすべてのデータを再計算します | データ量が少ない場合、初回のベースライン作成、またはベースラインの復旧 |
PARTITIONS | ベーステーブルのパーティションの変更を特定し、影響を受けるマテリアライズドビューの各パーティションを再計算します | データ量が多く、変更が少数のパーティションに集中する場合 |
INCREMENTAL | IVM を使って二回の更新間に生じた行単位の変更を計算し、マテリアライズドビューに適用します | 変更行数がテーブル全体または影響を受けるパーティションの行数よりはるかに少ない場合 |
AUTO | Doris が使用可能な更新方法を自動的に選択します | IVM、パーティション更新、全量更新の中からシステムに選択させたい場合 |
INCREMENTAL と PARTITIONS はどちらも増分更新ですが、粒度が異なります。前者は行単位の変更だけを処理し、後者は影響を受けるパーティション全体を再計算します。IVM は Doris 5.0.0 以降で利用でき、現在は実験的な機能です。要件と制限事項については、Incremental View Maintenance（IVM）を参照してください。
透過的な書き換え
透過的な書き換えは、データベースがクエリ性能を最適化するための重要な手段です。ユーザーのクエリを処理する際、システムは適切なマテリアライズドビューを利用するよう SQL を自動的に書き換え、実行効率を高めて計算コストを下げます。この処理はユーザーに対して透過的で、操作は不要です。
Doris の非同期マテリアライズドビューは、SPJG（SELECT-PROJECT-JOIN-GROUP-BY）パターンに基づく透過的な書き換えアルゴリズムを使用します。
- SQL の構造情報を詳しく分析します。
- 透過的な書き換えに適したマテリアライズドビューを自動的に探して選択します。
- 候補となるマテリアライズドビューが複数ある場合は、コストモデルなどの戦略に基づいてクエリに最適なビューを選択し、性能をさらに向上させます。
データレイク上での非同期マテリアライズドビューの作成
データレイク上で非同期マテリアライズドビューを作成する構文は、内部テーブル上で作成する場合と同じですが、次の点に注意してください。
- メタデータの取得元：マテリアライズドビューの更新に必要なパーティションのバージョンなどの情報は、外部環境から直接取得されるのではなく、データレイクのメタデータキャッシュから取得されます。そのため、更新完了後のデータは Doris 経由でデータレイクをクエリした結果と整合しますが、キャッシュの更新状況によっては、他のエンジンによるクエリ結果とは一致しない場合があります。
- 外部での変更の検知：Doris が制御していない外部プロセス（Spark、Hive、Flink のジョブなど）によって基になる Hive データが変更されても、メタデータが変わらない場合（たとえば、
insert overwriteの実行時）、マテリアライズドビューは誤ってベーステーブルと整合していると判断します。しかし、そのクエリ結果は Doris 経由でデータレイクをクエリした結果と一致しません。この問題は、マテリアライズドビューを手動で強制更新することで解決できます。 - Iceberg の制限：Iceberg 上でパーティション分割されたマテリアライズドビューを作成する場合、パーティション列が一つの Iceberg テーブルのみがサポートされ、パーティション進化への対応にも制限があります。たとえば、時間型パーティションの時間範囲の変更はサポートされますが、パーティションフィールド自体が変わると、マテリアライズドビューの更新は失敗します。
- Hudi の制限：Hudi 上にマテリアライズドビューを作成した場合、システムはベーステーブルのデータが変更されたかどうかを検知できません。マテリアライズドビュー（またはその一部のパーティション）が一度でも更新されると、ベーステーブルと同期していると見なされます。そのため、Hudi 上のマテリアライズドビューは、必要に応じて手動で更新するシナリオにのみ適しています。
データレイク上のマテリアライズドビューの更新サポート
次の表は、テーブルの種類と Catalog ごとの更新サポート状況を示します。
| テーブルの種類 | Catalog の種類 | 更新方法 | 更新トリガー | |
|---|---|---|---|---|
| 全量更新 | パーティション更新 | 自動トリガー | ||
| 内部テーブル | Internal | 2.1 以降でサポート | 2.1 以降でサポート | 2.1.4 以降でサポート |
| Hive | Hive | 2.1 以降でサポート | 2.1 以降でサポート | サポート対象外 |
| Iceberg | Iceberg | 2.1 以降でサポート | 3.1 以降でサポート | サポート対象外 |
| Paimon | Paimon | 2.1 以降でサポート | 3.1 以降でサポート | サポート対象外 |
| Hudi | Hudi | 2.1 以降でサポート | 3.1 以降でサポート | サポート対象外 |
| JDBC | JDBC | 2.1 以降でサポート | サポート対象外 | サポート対象外 |
| ES | ES | 2.1 以降でサポート | サポート対象外 | サポート対象外 |
データレイク上の透過的な書き換えのサポート
非同期マテリアライズドビューの透過的な書き換え機能は、現在、次のテーブルの種類と Catalog をサポートしています。
ベーステーブルのデータ変更のリアルタイム検知：マテリアライズドビューで使用するベーステーブルのデータが変わったときに、その変更をリアルタイムに検知し、クエリで最新のデータを使用できることを意味します。
| テーブルの種類 | Catalog の種類 | 透過的な書き換えのサポート | ベーステーブルのデータ変更のリアルタイム検知 |
|---|---|---|---|
| 内部テーブル | Internal | サポート | サポート |
| Hive | Hive | サポート | 3.1 以降でサポート |
| Iceberg | Iceberg | サポート | 3.1 以降でサポート |
| Paimon | Paimon | サポート | 3.1 以降でサポート |
| Hudi | Hudi | サポート | サポート対象外 |
| JDBC | JDBC | サポート | サポート対象外 |
| ES | ES | サポート | サポート対象外 |
外部テーブルのマテリアライズドビューで透過的な書き換えを有効にする
マテリアライズドビューが外部テーブルを使用する場合、デフォルトでは透過的な書き換えの対象になりません。有効にするには、次を実行します。
SET materialized_view_rewrite_enable_contain_external_table = true;
外部テーブルの透過的な書き換えの性能最適化
Doris 2.1.11 以降、外部テーブルに対する透過的な書き換えの性能が最適化されています。主な改善点は、外部テーブルを含む利用可能なマテリアライズドビューの取得性能です。
外部テーブルを含むパーティション分割されたマテリアライズドビューで透過的な書き換えが遅い場合は、fe.conf で次のパラメータを調整できます。
| パラメータ | デフォルト値 | 説明 | バージョン |
|---|---|---|---|
max_hive_partition_cache_num | 10000 | Hive Metastore におけるテーブル単位のパーティションキャッシュの最大数。Hive 外部テーブルに多数のパーティションがある場合は、20000 以上に設定します | - |
external_cache_expire_time_minutes_after_access | 10 分 | 最終アクセス後にキャッシュされたオブジェクトが期限切れになるまでの時間。必要に応じて増やせます（外部テーブルのスキーマキャッシュと Hive のメタデータキャッシュの両方に適用） | - |
external_cache_refresh_time_minutes | 10 分 | 外部テーブルのメタデータキャッシュオブジェクトの自動更新間隔。必要に応じて増やせます | 3.1+ |
外部テーブルのメタデータキャッシュの設定について詳しくは、メタデータキャッシュを参照してください。
マテリアライズドビューと OLAP 内部テーブルの関係
非同期マテリアライズドビューを定義する SQL で使用するベーステーブルのモデルに制限はありません。Duplicate モデル、Unique モデル（merge-on-write または merge-on-read）、Aggregate モデルなどを使用できます。
マテリアライズドビュー自体の内部実装には Duplicate モデルの OLAP テーブルが使われ、理論上は Duplicate モデルのすべての主要機能をサポートできます。ただし、マテリアライズドビューがデータ更新タスクを安定して効率的に実行できるように、機能には次の制限が設けられています。
- パーティション操作：マテリアライズドビューのパーティションは、ベーステーブルに基づいて自動的に作成、維持されます。ユーザーはマテリアライズドビューのパーティションを操作できません。
- 削除と名前変更：マテリアライズドビューには関連するジョブ（JOB）があるため、
DROP TABLEやRENAME TABLEコマンドで操作することはできません。該当する操作にはマテリアライズドビュー専用のコマンドを使用してください。 - 列のデータ型：マテリアライズドビューの列のデータ型は、作成時に指定したクエリ文から自動的に導出され、変更できません。変更すると更新タスクが失敗する可能性があります。
- プロパティの変更：マテリアライズドビューには Duplicate テーブルにはないプロパティがあります。これらはマテリアライズドビュー専用のコマンドで変更する必要があります。その他の共通プロパティは
ALTER TABLEコマンドで変更します。
よくある質問
Q1：非同期マテリアライズドビューは、ベーステーブルとのリアルタイムなデータ整合性を保証できますか？
いいえ。非同期マテリアライズドビューはベーステーブルと結果整合性を保ちますが、リアルタイムには同期できません。リアルタイムの整合性が必要な場合は、同期マテリアライズドビューを検討してください。
Q2：ウィンドウ関数を含むクエリを書き換えられないのはなぜですか？
現在の透過的な書き換えアルゴリズムは、まだウィンドウ関数をサポートしていません。ウィンドウ関数を含むクエリは、マテリアライズドビューに基づく形式には書き換えられません。
Q3：外部テーブルに基づくマテリアライズドビューが書き換えで使用されないのはなぜですか？
外部テーブルに基づくマテリアライズドビューは、デフォルトでは透過的な書き換えの対象になりません。書き換えに参加させるには、materialized_view_rewrite_enable_contain_external_table = true を設定してください。
Q4：外部プロセスで Hive 外部テーブルのデータを変更した後、マテリアライズドビューのクエリ結果が一致しないのはなぜですか？
Spark、Hive、Flink などの外部プロセスによって Hive データが変更されても、メタデータが変わらない場合（たとえば、insert overwrite）、マテリアライズドビューは変更を検知できません。マテリアライズドビューを手動で強制更新すると解決できます。
Q5：Hudi に基づくマテリアライズドビューは自動的に更新できますか？
ベーステーブルの変更を検知できないため、必要に応じて手動で更新するシナリオにのみ適しています。
関連項目
- 非同期マテリアライズドビューの作成、クエリ、保守：非同期マテリアライズドビューの作成、クエリ、保守
- 行単位の変更の維持：Incremental View Maintenance（IVM）
- ユーザーガイド：ユーザーガイド
- よくある質問：よくある質問