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