非同期マテリアライズドビューの概要
Materialized viewは効率的なソリューションとして、viewの柔軟性と物理テーブルの高いパフォーマンス上の利点を組み合わせています。 クエリの結果セットを事前に計算して格納することができ、 クエリリクエストが到着した際に格納されたmaterialized viewから直接結果を迅速に取得することで、複雑なクエリ文の再実行のオーバーヘッドを回避できます。
使用ケース
- クエリの高速化と並行性の改善: Materialized viewはクエリ速度を大幅に向上させると同時に、システムの並行処理能力を高め、リソース消費を効果的に削減できます。
- ETLプロセスの簡素化: Extract、Transform、Load（ETL）プロセスにおいて、materialized viewはワークフローを合理化し、開発効率を向上させ、データ処理をスムーズにできます。
- Lakehouse アーキテクチャにおける外部テーブルクエリの高速化: lakehouseアーキテクチャにおいて、materialized viewは外部データソースのクエリ速度を大幅に向上させ、データアクセス効率を改善できます。
- 書き込み効率の向上: リソース競合を削減することで、materialized viewはデータ書き込みプロセスを最適化し、書き込み効率を向上させ、データの一貫性と整合性を確保できます。
制限事項
- 非同期Materialized Viewとベーステーブルデータの一貫性: 非同期materialized viewは最終的にベーステーブルデータと一貫性を保ちますが、リアルタイムで同期することはできず、リアルタイムの一貫性を維持できません。
- Window Function クエリのサポート: 現在、クエリにwindow functionが含まれている場合、そのクエリをmaterialized viewを利用するように透過的に書き換えることはサポートされていません。
- クエリテーブルよりも多くのテーブルを結合するMaterialized View: materialized viewで結合されるテーブル数がクエリに含まれるテーブル数を超える場合（例えば、クエリがt1とt2のみを含むのに対し、materialized viewにt1、t2、および追加のt3が含まれる場合）、現在システムはそのクエリをmaterialized viewを利用するように透過的に書き換えることをサポートしていません。
- materialized viewにUNION ALL、LIMIT、ORDER BY、CROSS JOINなどの集合演算が含まれている場合、materialized viewは正常に構築できますが、透過的な書き換えには使用できません。
原理の紹介
Materialized viewは、データベースの高度な機能として、本質的にMTMVタイプの内部テーブルとして機能します。materialized viewを作成する際、システムは同時にリフレッシュタスクを登録します。このタスクは必要に応じて実行され、INSERT OVERWRITE文を実行して最新のデータをmaterialized viewに書き込みます。
リフレッシュメカニズム
同期materialized viewで使用されるリアルタイム増分リフレッシュとは異なり、非同期materialized viewはより柔軟なリフレッシュオプションを提供します。
-
フルリフレッシュ:
このモードでは、システムはmaterialized viewのSQL定義に含まれるすべてのデータを再計算し、完全な結果をmaterialized viewに書き込みます。このプロセスにより、materialized view内のデータがベーステーブルデータと一貫性を保つことが保証されますが、より多くの計算リソースと時間を消費する可能性があります。 -
パーティション増分リフレッシュ:
materialized viewのベーステーブルのパーティションデータが変更された場合、システムはこれらの変更をインテリジェントに識別し、影響を受けるパーティションのみをリフレッシュできます。このメカニズムにより、materialized viewのリフレッシュに必要な計算リソースと時間が大幅に削減され、最終的なデータ一貫性が確保されます。
透過的書き換え:
透過的書き換えは、データベースがクエリパフォーマンスを最適化するための重要な手段です。ユーザークエリを処理する際、システムは自動的にSQLを最適化および書き換えて、実行効率を向上させ、計算コストを削減できます。この書き換えプロセスはユーザーに対して透過的で、介入を必要としません。
Doris非同期materialized viewは、SPJG（SELECT-PROJECT-JOIN-GROUP-BY）モデルに基づく透過的書き換えアルゴリズムを利用します。このアルゴリズムはSQLの構造情報を詳細に分析し、透過的書き換えに適したmaterialized viewを自動的に検索および選択できます。複数のmaterialized viewが利用可能な場合、アルゴリズムは特定の戦略（コストモデルなど）に基づいて、クエリSQLに応答する最適なmaterialized viewを選択し、クエリパフォーマンスをさらに向上させます。
データレイクベースの非同期Materialized Viewの作成
データレイクベースの非同期materialized viewを作成する構文は、内部テーブルベースの非同期materialized viewを作成する構文と全く同じですが、いくつかの考慮事項があります：
- materialized viewをリフレッシュするには、パーティションバージョン情報などのデータレイクからのメタデータが必要です。この情報は外部環境から直接取得するのではなく、データレイクのメタデータキャッシュから取得されます。したがって、materialized viewがリフレッシュされた後、データはDorisを通じてデータレイクからクエリされた結果と一貫性を保ちます。ただし、他のエンジンを通じてデータレイクからクエリされた結果とは、キャッシュのリフレッシュ状況に応じて一致しない場合があります。
- 基盤のHiveデータがDorisによって制御されない外部プロセス（Spark、Hive、Flinkジョブなど）によって、メタデータを変更せずに修正された場合（insert overwriteの実行など）、materialized viewはベーステーブルデータとの一貫性があると仮定する可能性がありますが、クエリされたデータはDorisを通じてデータレイクからクエリされた結果と一致しない場合があります。この問題は、materialized viewを手動で強制的にリフレッシュすることで解決できます。
- Icebergベースのパーティション化materialized viewを作成する場合、単一のパーティション列を持つIcebergテーブルのみがサポートされます。パーティション進化に対しては限定的なサポートが提供されます。例えば、時間ベースのパーティションの時間範囲の変更はサポートされますが、パーティションフィールドの変更はサポートされません。パーティションフィールドが変更された場合、materialized viewのリフレッシュは失敗します。
- Hudiベースのmaterialized viewを作成する場合、ベーステーブルデータが変更されたかどうかの認識がありません。したがって、materialized view（またはmaterialized viewのパーティション）がリフレッシュされると、ベーステーブルと同期されたと見なされます。結果として、Hudiベースのmaterialized viewの作成は、手動のオンデマンドリフレッシュが必要なシナリオにのみ適しています。
Materialized リフレッシュデータレイクのサポート
materialized リフレッシュデータレイクのサポートは、テーブルタイプとcatalogによって異なります。
| テーブルタイプ | Catalogタイプ | リフレッシュ方法 | トリガーリフレッシュ | |
|---|---|---|---|---|
| フルリフレッシュ | パーティションリフレッシュ | 自動トリガー | ||
| Internal Table | 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でサポート | サポートされていません | サポートされていません |
データレイクに対する透過的書き換えサポート
現在、非同期materialized viewの透過的書き換え機能は、以下のタイプのテーブルとcatalogをサポートしています。
リアルタイムベーステーブルデータ認識：materialized viewが使用する基盤テーブルデータの変更を検出し、クエリ時に最新のデータを利用する能力を指します。
| テーブルタイプ | Catalogタイプ | 透過的書き換えサポート | リアルタイムベーステーブルデータ認識 |
|---|---|---|---|
| Internal Table | Internal | サポート | サポート |
| Hive | Hive | サポート | 3.1でサポート |
| Iceberg | Iceberg | サポート | 3.1でサポート |
| Paimon | Paimon | サポート | 3.1でサポート |
| Hudi | Hudi | サポート | サポートされていません |
| JDBC | JDBC | サポート | サポートされていません |
| ES | ES | サポート | サポートされていません |
外部テーブルを使用するMaterialized viewは、デフォルトで透過的書き換えに参加しません。
外部テーブルを含むmaterialized viewの透過的書き換えを有効にしたい場合は、SET materialized_view_rewrite_enable_contain_external_table = trueを設定できます。
バージョン2.1.11以降、Dorisは外部テーブルの透過的書き換えパフォーマンスを最適化しており、主に外部テーブルを含む利用可能なmaterialized viewを取得するパフォーマンスを改善しています。
外部テーブルを含むパーティション化materialized viewで透過的書き換えが遅い場合は、fe.confで設定する必要があります：
max_hive_partition_cache_num = 20000、Hive Metastoreテーブルレベルパーティションキャッシュの最大数で、デフォルト値は10000です。
外部Hiveテーブルに多くのパーティションがある場合は、この値をより高く設定できます。
external_cache_expire_time_minutes_after_access、最終アクセス後にキャッシュが期限切れになるまでの期間です。デフォルトは10分で、適切に増加させることができます。
（外部テーブルスキーマキャッシュとHiveメタデータキャッシュに適用されます）
external_cache_refresh_time_minutes = 60、外部テーブルメタデータキャッシュの自動リフレッシュ間隔です。デフォルトは10分で、適切に増加させることができます。この設定はバージョン3.1からサポートされています。
外部テーブルメタデータキャッシュ設定の詳細については、メタデータキャッシュを参照してください。
Materialized ViewとOLAP内部テーブルの関係
非同期materialized viewは、テーブルモデルの制限なくベーステーブルを使用してSQLを定義します。これは詳細モデル、プライマリキーモデル（merge-on-writeおよびmerge-on-read）、集約モデルなどが可能です。
materialized viewの基盤実装はDuplicateモデルのOLAPテーブルに依存しており、理論的にはDuplicateモデルのすべてのコア機能をサポートできます。ただし、materialized viewが安定的かつ効率的にデータリフレッシュタスクを実行できるよう、機能に一連の必要な制限を課しています。具体的な制限は以下の通りです：
- materialized viewのパーティションはベーステーブルに基づいて自動的に作成および維持されるため、ユーザーはmaterialized viewに対してパーティション操作を実行できません。
- materialized viewの背後には処理が必要な関連ジョブ（JOB）があるため、DELETE TABLEやRENAME TABLEなどのコマンドをmaterialized viewの操作に使用することはできません。代わりに、これらの操作にはmaterialized view固有のコマンドを使用する必要があります。
- materialized viewの列データ型は作成時に指定されたクエリ文に基づいて自動的に推測されるため、これらのデータ型を変更することはできません。そうしないと、materialized viewのリフレッシュタスクが失敗する可能性があります。
- materialized viewはDuplicateテーブルにはないプロパティを持っており、これらのプロパティはmaterialized viewのコマンドを通じて変更する必要があります。その他の共通プロパティはALTER TABLEコマンドを使用して変更する必要があります。
その他の参考資料
非同期materialized viewの作成、クエリ、メンテナンスについては、非同期Materialized Viewの作成、クエリ、メンテナンスを参照してください。
ベストプラクティスについては、ベストプラクティスを参照してください。
よくある質問については、よくある質問を参照してください。