非同期マテリアライズドビューの概要
非同期マテリアライズドビューは、ビューの柔軟性と物理テーブルの高い性能を組み合わせたクエリ高速化の仕組みです。クエリ結果を事前に計算して保存することで、後続のクエリはマテリアライズされた結果を直接利用でき、複雑な SQL を繰り返し実行する負荷を避けられます。
クイックガイド
非同期マテリアライズドビューを使用する前に、次の点を確認してください。
- 業務上、クエリの高速化、ETL の簡素化、レイクハウスの外部テーブルに対するクエリの高速化、または書き込みの最適化が必要ですか？
- クエリは SPJG（SELECT-PROJECT-JOIN-GROUP-BY）パターンに従っていますか？
- データの結果整合性（リアルタイムではない同期）を許容できますか？
- ベーステーブルの Catalog はサポート対象（Internal/Hive/Iceberg/Paimon/Hudi/JDBC/ES）に含まれていますか？
- リフレッシュのコストを抑えるために、パーティション単位の増分リフレッシュが必要ですか？
利用シーン
非同期マテリアライズドビューは、主に次の四つのシーンを対象としています。
| 利用シーン | メリット |
|---|---|
| クエリの高速化と同時実行性能の向上 | クエリ速度を大幅に向上させ、同時実行性能を高め、リソース消費を削減します |
| ETL ワークフローの簡素化 | 抽出、変換、ロード（ETL）のプロセスを簡素化し、開発効率を向上させます |
| レイクハウスの外部テーブルに対するクエリの高速化 | レイクハウスアーキテクチャにおける外部データソースへのクエリ速度を大幅に向上させます |
| 書き込み効率の向上 | リソース競合を減らし、データ書き込み処理を最適化して、整合性と完全性を確保します |
制限事項
非同期マテリアライズドビューを使用する前に、次の制限事項に注意してください。
- データの整合性：非同期マテリアライズドビューはベーステーブルと結果整合性を保ちますが、リアルタイムに同期できず、リアルタイムの整合性は保証されません。
- ウィンドウ関数：現在、ウィンドウ関数を含むクエリを、マテリアライズドビューに基づく形式へ透過的に書き換えることはサポートされていません。
- 複数テーブルのケース：マテリアライズドビューの結合対象テーブルがクエリの対象より多い場合（たとえば、クエリは t1 と t2 のみを参照し、マテリアライズドビューは t1、t2、t3 を含む場合）、現在、透過的なクエリ書き換えはサポートされていません。
- 透過的なクエリ書き換えでサポートされない演算子：マテリアライズドビューに
UNION ALL、LIMIT、ORDER BY、またはCROSS JOINが含まれる場合、マテリアライズドビューは通常どおり作成できますが、透過的なクエリ書き換えには使用できません。 - データ型の制限：現在、
VARBINARY型を含むマテリアライズドビューの作成はサポートされていません。
仕組み
非同期マテリアライズドビューは、実質的には MTMV 型の内部テーブルです。マテリアライズドビューの作成時に、システムはリフレッシュタスクも登録します。このタスクが実行されると、INSERT OVERWRITE 文によって最新のデータがマテリアライズドビューに書き込まれます。
リフレッシュの仕組み
同期マテリアライズドビューのリアルタイム増分リフレッシュとは異なり、非同期マテリアライズドビューでは、より柔軟なリフレッシュ方法を選択できます。
| リフレッシュ方法 | 説明 | 適したケース |
|---|---|---|
| 全件リフレッシュ | マテリアライズドビューの定義 SQL が参照するすべてのデータを再計算し、マテリアライズドビューに全件を書き込みます | データ量が少ない場合、または全体の整合性を保証する必要がある場合 |
| パーティション単位の増分リフレッシュ | ベーステーブルのパーティションデータの変更を識別し、影響を受けたパーティションのみをリフレッシュします | データ量が多く、変更が特定のパーティションに集中している場合 |
- 全件リフレッシュ：マテリアライズドビューのデータがベーステーブルと完全に一致するようにしますが、計算リソースと時間をより多く消費する場合があります。
- パーティション単位の増分リフレッシュ：結果整合性を保ちながら、リフレッシュに必要なリソースと時間を大幅に削減します。
透過的なクエリ書き換え
透過的なクエリ書き換えは、データベースがクエリ性能を最適化するための重要な手段です。ユーザーのクエリを処理する際、システムは適切なマテリアライズドビューを利用できるよう 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;
外部テーブルの透過的なクエリ書き換えの性能最適化
2.1.11 以降、Doris では外部テーブルに対する透過的なクエリ書き換えの性能が最適化されました。主な改善点は、外部テーブルを含む利用可能なマテリアライズドビューを取得する処理の高速化です。
外部テーブルを含むパーティション化されたマテリアライズドビューで透過的なクエリ書き換えが遅い場合は、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 に基づくマテリアライズドビューは自動的にリフレッシュできますか？
ベーステーブルの変更を検知できないため、必要に応じて手動でリフレッシュする場合にのみ適しています。
関連項目
- 非同期マテリアライズドビューの作成、クエリ、保守：非同期マテリアライズドビューの作成、クエリ、保守
- ユーザーガイド：ユーザーガイド
- FAQ：FAQ