非同期マテリアライズドビューの概要

マテリアライズドビューは、効率的なソリューションとして、ビューの柔軟性と物理テーブルの高性能の利点を組み合わせています。 クエリの結果セットを事前に計算して保存できるため、 クエリリクエストが到着したときに、保存されたマテリアライズドビューから結果を直接迅速に取得でき、 複雑なクエリステートメントの再実行によるオーバーヘッドを回避できます。

ユースケース

• クエリの高速化と同時処理性能の向上: マテリアライズドビューはクエリ速度を大幅に向上させるとともに、システムの同時処理能力を高め、リソース消費を効果的に削減できます。
• ETLプロセスの簡素化: Extract、Transform、Load（ETL）プロセス中に、マテリアライズドビューはワークフローを合理化し、開発効率を向上させ、データ処理をスムーズにできます。
• Lakehhouseアーキテクチャにおける外部テーブルクエリの高速化: レイクハウスアーキテクチャにおいて、マテリアライズドビューは外部データソースのクエリ速度を大幅に向上させ、データアクセス効率を改善できます。
• 書き込み効率の向上: リソース競合を削減することで、マテリアライズドビューはデータ書き込みプロセスを最適化し、書き込み効率を向上させ、データの一貫性と整合性を確保できます。

制限事項

• 非同期マテリアライズドビューとベーステーブルデータの一貫性: 非同期マテリアライズドビューは最終的にベーステーブルデータと一致しますが、リアルタイムで同期することはできないため、リアルタイムの一貫性を維持できません。
• ウィンドウ関数クエリのサポート: 現在、クエリにウィンドウ関数が含まれている場合、そのクエリをマテリアライズドビューを利用するように透過的に書き換えることはサポートされていません。
• クエリテーブルより多くのテーブルを結合するマテリアライズドビュー: マテリアライズドビューで結合されるテーブル数がクエリに含まれるテーブル数を超える場合（例えば、クエリが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の構造情報を深く解析し、透過的書き換えに適したマテリアライズドビューを自動的に検索および選択できます。複数のマテリアライズドビューが利用可能な場合、アルゴリズムは特定の戦略（コストモデルなど）に基づいて、クエリSQLに応答するための最適なマテリアライズドビューも選択し、クエリパフォーマンスをさらに向上させます。

データレークに基づく非同期マテリアライズドビューの作成

データレークに基づく非同期マテリアライズドビューを作成するための構文は、内部テーブルに基づく非同期マテリアライズドビューを作成するものと全く同じですが、いくつかの考慮事項があります：

• マテリアライズドビューをリフレッシュするには、パーティションバージョン情報などのデータレークのメタデータが必要です。この情報は、外部環境から直接取得されるのではなく、データレークのメタデータキャッシュから取得されます。そのため、マテリアライズドビューがリフレッシュされた後、データはDorisを通じてデータレークからクエリされた結果と一致したままになります。ただし、他のエンジンを通じてデータレークからクエリされた結果とは一致しない可能性があり、これはキャッシュのリフレッシュ状態に依存します。
• 基盤となるHiveデータがDorisによって制御されていない外部プロセス（Spark、Hive、Flinkジョブなど）によってメタデータを変更せずに変更された場合（insert overwriteの実行など）、マテリアライズドビューはベーステーブルデータとの一貫性を仮定する可能性がありますが、クエリされたデータはDorisを通じてデータレークからクエリされた結果と一致しない可能性があります。この問題は、マテリアライズドビューの強制リフレッシュを手動で行うことで解決できます。
• Icebergに基づいてパーティション化されたマテリアライズドビューを作成する場合、単一のパーティション列を持つIcebergテーブルのみがサポートされています。パーティション進化については限定的なサポートが提供されています。例えば、時間ベースのパーティションの時間範囲の変更はサポートされていますが、パーティションフィールドの変更はサポートされていません。パーティションフィールドが変更された場合、マテリアライズドビューのリフレッシュは失敗します。
• Hudiに基づいてマテリアライズドビューを作成する場合、ベーステーブルデータが変更されたかどうかの認識はありません。そのため、マテリアライズドビュー（またはマテリアライズドビューのパーティション）がリフレッシュされると、ベーステーブルと同期されているとみなされます。その結果、Hudiに基づくマテリアライズドビューの作成は、手動でのオンデマンドリフレッシュが必要なシナリオにのみ適しています。

マテリアライズドリフレッシュデータレークのサポート

マテリアライズドリフレッシュデータレークのサポートは、テーブルタイプとカタログによって異なります。

テーブルタイプ	カタログタイプ	リフレッシュ方法		トリガーリフレッシュ
		フルリフレッシュ	パーティションリフレッシュ	自動トリガー
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でサポート	サポートなし	サポートなし

データレークの透過的書き換えサポート

現在、非同期マテリアライズドビューの透過的書き換え機能は、以下のタイプのテーブルとカタログをサポートしています。

リアルタイムベーステーブルデータ認識：マテリアライズドビューが使用する基盤テーブルデータの変更を検出し、クエリ中に最新のデータを利用する能力を指します。

テーブルタイプ	カタログタイプ	透過的書き換えサポート	リアルタイムベーステーブルデータ認識
Internal table	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 = 20000、Hive Metastoreテーブルレベルパーティションキャッシュの最大数で、デフォルト値は10000です。 外部Hiveテーブルに多くのパーティションがある場合は、この値をより高く設定できます。

external_cache_expire_time_minutes_after_access、最後のアクセス後のキャッシュ有効期限。デフォルトは10分で、適切に増加させることができます。 （外部テーブルスキーマキャッシュとHiveメタデータキャッシュに適用されます）

external_cache_refresh_time_minutes = 60、外部テーブルメタデータキャッシュの自動リフレッシュ間隔。デフォルトは10分で、適切に増加させることができます。この設定はバージョン3.1からサポートされています。 外部テーブルメタデータキャッシュ設定の詳細については、メタデータキャッシュを参照してください。

マテリアライズドビューとOLAP内部テーブルの関係

非同期マテリアライズドビューは、ベーステーブルのテーブルモデルを使用してSQLを定義し、制限なく、詳細モデル、主キーモデル（merge-on-writeおよびmerge-on-read）、集約モデルなどが可能です。

マテリアライズドビューの基盤実装は、DuplicateモデルのOLAPテーブルに依存しており、理論的にはDuplicateモデルのすべてのコア機能をサポートできます。ただし、マテリアライズドビューがデータリフレッシュタスクを安定的かつ効率的に実行できることを確保するため、機能に対して一連の必要な制限を設けています。具体的な制限は以下の通りです：

• マテリアライズドビューのパーティションは、ベーステーブルに基づいて自動的に作成および維持されるため、ユーザーはマテリアライズドビューに対してパーティション操作を実行できません。
• マテリアライズドビューの背後には処理が必要な関連ジョブ（JOB）があるため、DELETE TABLEやRENAME TABLEなどのコマンドを使用してマテリアライズドビューを操作することはできません。代わりに、これらの操作には、マテリアライズドビュー固有のコマンドを使用する必要があります。
• マテリアライズドビューの列データタイプは作成時に指定されたクエリステートメントに基づいて自動的に推論されるため、これらのデータタイプは変更できません。そうしないと、マテリアライズドビューのリフレッシュタスクで障害が発生する可能性があります。
• マテリアライズドビューにはDuplicateテーブルにはないプロパティがあり、これらのプロパティはマテリアライズドビューのコマンドを通じて変更する必要があります。その他の一般的なプロパティはALTER TABLEコマンドを使用して変更する必要があります。

その他の参考資料

非同期マテリアライズドビューの作成、クエリ、メンテナンスについては、非同期マテリアライズドビューの作成、クエリ、メンテナンスを参照してください。

ベストプラクティスについては、ベストプラクティスを参照してください。

よくある質問については、よくある質問を参照してください。