FAQ
ビルドとリフレッシュ
Q1: Dorisはマテリアライズドビューでどのパーティションをリフレッシュする必要があるかをどのように判断しますか？
Dorisは内部でマテリアライズドビューとベーステーブル間のパーティション対応を計算し、前回の正常なリフレッシュ後にマテリアライズドビューが使用したベーステーブルパーティションのバージョンを記録します。例えば、マテリアライズドビューmv1がベーステーブルt1とt2から作成され、t1に基づいてパーティション化されている場合。
mv1のパーティションp202003がベーステーブルt1のパーティションp20200301とp20200302に対応していると仮定すると、p202003をリフレッシュした後、Dorisはパーティションp20200301とp20200302を、テーブルt2の現在のバージョンと共に記録します。
次回のリフレッシュ時に、Dorisはp20200301、p20200302、およびt2のバージョンが変更されているかをチェックします。いずれかが変更されている場合、p202003をリフレッシュする必要があることを示します。
または、t2への変更をmv1のリフレッシュをトリガーすることなく受け入れることができる場合、マテリアライズドビューのexcluded_trigger_tablesプロパティを使用してこれを設定できます。
Q2: マテリアライズドビューが多くのリソースを消費し、他のビジネス処理に影響を与える場合はどうすればよいですか？
マテリアライズドビューのプロパティを通じてworkload_groupを指定することで、マテリアライズドビューのリフレッシュタスクに割り当てるリソースを制御できます。
メモリ割り当てが少なすぎて、単一パーティションのリフレッシュにより多くのメモリが必要な場合、タスクが失敗する可能性があることに注意が必要です。このトレードオフはビジネス要件に基づいて慎重に検討する必要があります。
Q3: 既存のマテリアライズドビューに基づいて新しいマテリアライズドビューを作成できますか？
はい、これはDoris 2.1.3以降でサポートされています。ただし、各マテリアライズドビューはデータ更新時に独自のリフレッシュロジックを使用します。例えば、mv2がmv1に基づき、mv1がt1に基づいている場合、mv2のリフレッシュ時にmv1とt1間の同期は考慮されません。
Q4: Dorisはどの外部テーブルをサポートしていますか？
Dorisがサポートするすべての外部テーブルを使用してマテリアライズドビューを作成できます。ただし、現在パーティションリフレッシュをサポートしているのはHiveのみで、他のタイプのサポートは将来予定されています。
Q5: マテリアライズドビューはHiveと同じデータを表示しますが、実際には一致していません。
マテリアライズドビューはCatalogを通じて取得された結果との一貫性のみを保証します。Catalogにはメタデータとデータキャッシングが含まれているため、マテリアライズドビューとHiveデータの一貫性を確保するには、REFRESH CATALOGなどの方法を使用してCatalogをリフレッシュし、CatalogデータをHiveと同期する必要がある場合があります。
Q6: マテリアライズドビューはスキーマ変更をサポートしていますか？
いいえ、マテリアライズドビューの列属性はマテリアライズドビュー自体のSQL定義から派生するため、スキーマ変更はサポートされていません。明示的なカスタム変更は許可されていません。
Q7: マテリアライズドビューが使用するベーステーブルはスキーマ変更を行うことができますか？
はい、スキーマ変更は許可されています。ただし、変更後、このベーステーブルを使用するマテリアライズドビューのステータスはNORMALからSCHEMA_CHANGEに変わり、この時点でマテリアライズドビューは透過的書き換えには使用できませんが、マテリアライズドビューへの直接クエリは影響を受けません。マテリアライズドビューの次のリフレッシュタスクが成功すると、そのステータスはNORMALに戻ります。
Q8: プライマリキーモデルのテーブルを使用してマテリアライズドビューを作成できますか？
マテリアライズドビューのベーステーブルのデータモデルに制限はありません。ただし、マテリアライズドビュー自体は詳細モデルのみ可能です。
Q9: マテリアライズドビューにインデックスを作成できますか？
はい。
Q10: マテリアライズドビューはリフレッシュ中にテーブルをロックしますか？
リフレッシュ中の短期間にテーブルロックが発生しますが、継続的にテーブルロックを占有することはありません（データインポート時のロック時間とほぼ同等）。
Q11: マテリアライズドビューはニアリアルタイムシナリオに適していますか？
特にそうではありません。マテリアライズドビューをリフレッシュする最小単位はパーティションであり、大量のデータでは大幅なリソースを消費し、リアルタイム性に欠けます。代わりに同期マテリアライズドビューや他の方法の使用を検討してください。
Q12: パーティション化されたマテリアライズドビューの構築時にエラーが発生
Error Message:
Unable to find a suitable base table for partitioning
このエラーは通常、マテリアライズドビューのSQL定義とパーティション項目の選択が増分パーティション更新を許可しないため、パーティション化されたマテリアライズドビューの作成時にエラーが発生することを示しています。
-
増分パーティション更新の場合、マテリアライズドビューのSQL定義とパーティション項目の選択は特定の要件を満たす必要があります。詳細はMaterialized View Refresh Modesを参照してください。
-
最新のコードはパーティションビルド失敗の理由を示すことができ、エラーの概要と説明は付録2に記載されています。
例：
CREATE TABLE IF NOT EXISTS orders (
o_orderkey INTEGER NOT NULL,
o_custkey INTEGER NOT NULL,
o_orderstatus CHAR(1) NOT NULL,
o_totalprice DECIMALV3(15, 2) NOT NULL,
o_orderdate DATE NOT NULL,
o_orderpriority CHAR(15) NOT NULL,
o_clerk CHAR(15) NOT NULL,
o_shippriority INTEGER NOT NULL,
O_COMMENT VARCHAR(79) NOT NULL
) DUPLICATE KEY(o_orderkey, o_custkey) PARTITION BY RANGE(o_orderdate) (
FROM
('2024-05-01') TO ('2024-06-30') INTERVAL 1 DAY
) DISTRIBUTED BY HASH(o_orderkey) BUCKETS 3 PROPERTIES ("replication_num" = "1");
CREATE TABLE IF NOT EXISTS lineitem (
l_orderkey INTEGER NOT NULL,
l_partkey INTEGER NOT NULL,
l_suppkey INTEGER NOT NULL,
l_linenumber INTEGER NOT NULL,
l_quantity DECIMALV3(15, 2) NOT NULL,
l_extendedprice DECIMALV3(15, 2) NOT NULL,
l_discount DECIMALV3(15, 2) NOT NULL,
l_tax DECIMALV3(15, 2) NOT NULL,
l_returnflag CHAR(1) NOT NULL,
l_linestatus CHAR(1) NOT NULL,
l_shipdate DATE NOT NULL,
l_commitdate DATE NOT NULL,
l_receiptdate DATE NOT NULL,
l_shipinstruct CHAR(25) NOT NULL,
l_shipmode CHAR(10) NOT NULL,
l_comment VARCHAR(44) NOT NULL
) DUPLICATE KEY(
l_orderkey, l_partkey, l_suppkey,
l_linenumber
) DISTRIBUTED BY HASH(l_orderkey) BUCKETS 3 PROPERTIES ("replication_num" = "1");
以下のマテリアライズドビュー定義では、orders.o_orderdateがマテリアライズドビューのパーティション分割フィールドとして選択されている場合、増分パーティション更新が可能です。逆に、lineitem.l_shipdateを使用した場合は増分更新が有効になりません。
理由：
-
lineitem.l_shipdateはベーステーブルのパーティション分割列ではなく、lineitemにはパーティション分割列が定義されていません。 -
lineitem.l_shipdateはouter join操作中にnull値を生成する列です。
CREATE MATERIALIZED VIEW mv_1 BUILD IMMEDIATE REFRESH AUTO ON MANUAL partition by(o_orderdate) DISTRIBUTED BY RANDOM BUCKETS 2 PROPERTIES ('replication_num' = '1') AS
SELECT
l_linestatus,
sum(
l_extendedprice * (1 - l_discount)
) AS revenue,
o_orderdate,
o_shippriority
FROM
orders
LEFT JOIN lineitem ON l_orderkey = o_orderkey
WHERE
o_orderdate <= DATE '2024-06-30'
AND o_orderdate >= DATE '2024-05-01'
GROUP BY
l_linestatus,
o_orderdate,
o_shippriority;
Q13: マテリアライズドビューの作成時にエラーが発生
Error Message:
ERROR 1105 (HY000): errCode = 2, detailMessage = Syntax error in line 1:
BUILD IMMEDIATE REFRESH AUTO ON MANUAL
理由として以下が考えられます：
-
非同期マテリアライズドビューを作成するためのステートメントは、新しいoptimizerでのみサポートされています。新しいoptimizerを使用していることを確認してください：
SET enable_nereids_planner = true; -
リフレッシュキーワードにタイポグラフィエラーがあるか、マテリアライズドビューのSQL定義に構文エラーがある可能性があります。マテリアライズドビューのSQL定義と作成文の正確性を確認してください。
Q14: マテリアライズドビューが正常にリフレッシュされた後も、まだデータがない場合
マテリアライズドビューは、ベーステーブルまたはベーステーブルパーティションからバージョン情報を取得する能力に基づいて、データの更新が必要かどうかを判断します。
JDBC Catalogなど、現在バージョン情報の取得をサポートしていないデータレイクに遭遇した場合、リフレッシュプロセスはマテリアライズドビューが更新不要であると仮定します。そのため、マテリアライズドビューを作成またはリフレッシュする際は、autoではなくcompleteを指定する必要があります。
データレイクに対するマテリアライズドビューサポートの進捗については、Data Lake Support Status.を参照してください。
Q15: パーティション化されたマテリアライズドビューが常にフルリフレッシュされるのはなぜですか？
マテリアライズドビューのパーティションの増分リフレッシュは、ベーステーブルパーティションからのバージョン情報に依存します。前回のリフレッシュ以降にベーステーブルパーティションのデータが変更された場合、マテリアライズドビューは対応するパーティションをリフレッシュします。 パーティション化されたマテリアライズドビューがフルリフレッシュされている場合、考えられる理由は以下の通りです：
マテリアライズドビューの定義SQLで参照されているパーティション追跡対象外のテーブルで変更が発生し、どのパーティションを更新する必要があるかを判断できないため、フルリフレッシュが強制される。 例： このマテリアライズドビューはordersテーブルのo_orderdateパーティションを追跡しますが、lineitemまたはpartsuppのデータが変更された場合、システムはどのパーティションを更新する必要があるかを判断できないため、フルリフレッシュが発生します。
CREATE MATERIALIZED VIEW partition_mv
BUILD IMMEDIATE
REFRESH AUTO
ON SCHEDULE EVERY 1 DAY STARTS '2024-12-01 20:30:00'
PARTITION BY (DATE_TRUNC(o_orderdate, 'MONTH'))
DISTRIBUTED BY HASH (l_orderkey) BUCKETS 2
PROPERTIES
("replication_num" = "3")
AS
SELECT
o_orderdate,
l_orderkey,
l_partkey
FROM
orders
LEFT JOIN lineitem ON l_orderkey = o_orderkey
LEFT JOIN partsupp ON ps_partkey = l_partkey
and l_suppkey = ps_suppkey;
materialized viewがどのベーステーブルを追跡しているかは、以下を実行することで確認できます
SELECT *
FROM mv_infos('database'='db_name')
WHERE Name = 'partition_mv' \G
返されたresultは、MvPartitionInfoでpartitionType=FOLLOW_BASE_TABLEを示し、マテリアライズドビューのパーティションがベーステーブルのパーティションに従うことを表しています。 relatedColはo_orderdateを示し、マテリアライズドビューのパーティションがo_orderdate列に基づいていることを意味します。
Id: 1752809156450
Name: partition_mv
JobName: inner_mtmv_1752809156450
State: NORMAL
SchemaChangeDetail:
RefreshState: SUCCESS
RefreshInfo: BUILD IMMEDIATE REFRESH AUTO ON SCHEDULE EVERY 1 DAY STARTS "2025-12-01 20:30:00"
QuerySql: SELECT
`internal`.`doc_db`.`orders`.`o_orderdate`,
`internal`.`doc_db`.`lineitem`.`l_orderkey`,
`internal`.`doc_db`.`lineitem`.`l_partkey`
FROM
`internal`.`doc_db`.`orders`
LEFT JOIN `internal`.`doc_db`.`lineitem` ON `internal`.`doc_db`.`lineitem`.`l_orderkey` = `internal`.`doc_db`.`orders`.`o_orderkey`
LEFT JOIN `internal`.`doc_db`.`partsupp` ON `internal`.`doc_db`.`partsupp`.`ps_partkey` = `internal`.`doc_db`.`lineitem`.`l_partkey`
and `internal`.`doc_db`.`lineitem`.`l_suppkey` = `internal`.`doc_db`.`partsupp`.`ps_suppkey`
MvPartitionInfo: MTMVPartitionInfo{partitionType=EXPR, relatedTable=orders, relatedCol='o_orderdate', partitionCol='o_orderdate'}
SyncWithBaseTables: 1
ソリューション:
lineitemテーブルやpartssuppテーブルの変更がマテリアライズドビューに影響しない場合、excluded_trigger_tablesプロパティを設定することで、これらのテーブルによる完全リフレッシュのトリガーを除外できます:
ALTER MATERIALIZED VIEW partition_mv set("excluded_trigger_tables"="lineitem,partsupp");
クエリと透過的な書き換え
Q1: マテリアライズドビューがヒットしたことを確認する方法、およびヒットしない理由を見つける方法は？
explain query_sqlを使用して、マテリアライズドビューヒットの概要を表示できます。
例えば、次のマテリアライズドビューを考えてみます:
CREATE MATERIALIZED VIEW mv11
BUILD IMMEDIATE REFRESH AUTO ON MANUAL
partition by(l_shipdate)
DISTRIBUTED BY HASH(l_orderkey) BUCKETS 10
PROPERTIES ('replication_num' = '1')
AS
SELECT l_shipdate, l_orderkey, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_orderkey, O_ORDERDATE;
クエリは次のようになります：
explain
SELECT l_shipdate, l_orderkey, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_orderkey, O_ORDERDATE;
-
マテリアライズドビューのヒット情報は、プランの最後に表示されます。
-
MaterializedViewRewriteSuccessAndChose: 透明リライトが成功したことを示し、Cost-Based Optimizer（CBO）によって選択されたマテリアライズドビューの名前を一覧表示します。
-
MaterializedViewRewriteSuccessButNotChose: 透明リライトが成功したが、CBOによって選択されなかったマテリアライズドビューの名前を一覧表示します。選択されなかったということは、実行プランがこれらのマテリアライズドビューを使用しないことを意味します。
-
MaterializedViewRewriteFail: 透明リライトの失敗とその理由の概要を一覧表示します。
-
explain出力の最後にMaterializedView情報がない場合、マテリアライズドビューが使用不可能な状態にあり、そのため透明リライトに参加できないことを意味します。（マテリアライズドビューがいつ使用不可能になるかの詳細については、「使用方法と実践 - マテリアライズドビューステータスの確認」セクションを参照してください。）
出力例は次のとおりです：
| MaterializedView |
| MaterializedViewRewriteSuccessAndChose: |
| internal#regression_test_nereids_rules_p0_mv#mv11, |
| |
| MaterializedViewRewriteSuccessButNotChose: |
| |
| MaterializedViewRewriteFail: |
+------------------------------------------------------------------------------------+
Q2: マテリアライズドビューがヒットしない理由は何ですか？
まず、マテリアライズドビューがヒットするかどうかを確認するには、以下のSQLを実行してください（詳細はQueries and Transparent Rewriting - Q1を参照）：
explain
your_query_sql;
ヒットしない場合、以下の理由が考えられます：
-
Doris バージョン 2.1.3 以前では、マテリアライズドビューの透過的書き換え機能がデフォルトで無効になっています。透過的書き換えを実現するには、対応するスイッチを有効にする必要があります。具体的なスイッチ値については、async-materialized view関連スイッチを参照してください。
-
マテリアライズドビューが使用不可能な状態にあり、透過的書き換えがヒットしない可能性があります。マテリアライズドビューのビルド状態を確認するには、マテリアライズドビューステータスの確認に関するセクションを参照してください。
-
最初の2つのステップを確認した後でも、マテリアライズドビューがヒットしない場合、SQLで定義されたマテリアライズドビューとクエリSQLが、現在のマテリアライズドビューの書き換え機能の範囲外にある可能性があります。詳細については、Materialized View Transparent Rewriting Capabilitiesを参照してください。
-
ヒット失敗に関する詳細な情報と説明については、付録1を参照してください。
以下は、マテリアライズドビューの透過的書き換えが失敗した例です：
ケース1：
マテリアライズドビュー作成SQL：
CREATE MATERIALIZED VIEW mv11
BUILD IMMEDIATE REFRESH AUTO ON MANUAL
partition by(l_shipdate)
DISTRIBUTED BY HASH(l_orderkey) BUCKETS 10
PROPERTIES ('replication_num' = '1')
AS
SELECT l_shipdate, l_orderkey, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_orderkey, O_ORDERDATE;
クエリ実行:
explain
SELECT l_shipdate, l_linestatus, O_ORDERDATE, count(*)
FROM orders
LEFT OUTER JOIN lineitem on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_linestatus, O_ORDERDATE;
Explain出力:
| MaterializedView |
| MaterializedViewRewriteSuccessAndChose: |
| |
| MaterializedViewRewriteSuccessButNotChose: |
| |
| MaterializedViewRewriteFail: |
| Name: internal#doc_test#mv11 |
| FailSummary: View struct info is invalid, The graph logic between query and view is not consistent |
出力において、MaterializedViewRewriteFailは失敗の要約を示し、The graph logic between query and view is not consistentは、クエリとマテリアライズドビューの結合ロジックが同じではないことを示しており、結合タイプや結合されるテーブルが異なることを意味します。
上記の例では、クエリとマテリアライズドビューのテーブル結合順序が一致していないため、エラーが発生します。透過的書き換え失敗の要約と説明については、付録1を参照してください。
ケース2:
クエリ実行:
explain
SELECT l_shipdate, l_linestatus, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_linestatus, O_ORDERDATE;
Explainの出力:
| MaterializedView |
| MaterializedViewRewriteSuccessAndChose: |
| |
| MaterializedViewRewriteSuccessButNotChose: |
| |
| MaterializedViewRewriteFail: |
| Name: internal#doc_test#mv11 |
| FailSummary: View struct info is invalid, View dimensions doesn't not cover the query dimensions |
失敗の概要View dimensions doesn't cover the query dimensionsは、クエリのGROUP BYフィールドがマテリアライズドビューのGROUP BYフィールドから取得できないため、エラーが発生していることを示しています。
Q3: マテリアライズドビューの状態が変化して使用不可になる状況は何ですか？
「使用不可」とは、マテリアライズドビューが透明な書き換えに使用できないことを意味しますが、直接クエリは可能です。
-
完全なマテリアライズドビューの場合、基底テーブルのデータ変更やSchema Changeにより、マテリアライズドビューが使用不可になる可能性があります。
-
パーティション化されたマテリアライズドビューの場合、基底テーブルのデータ変更により対応するパーティションが使用不可になり、基底テーブルのSchema Changeによりマテリアライズドビュー全体が使用不可になる可能性があります。
現在、マテリアライズドビューのリフレッシュに失敗した場合も使用不可になります。ただし、失敗したマテリアライズドビューでも透明な書き換えに使用できるよう最適化が予定されています。
Q4: マテリアライズドビューへの直接クエリがデータを返さない場合はどうすればよいですか？
マテリアライズドビューがまだ構築中であるか、構築が失敗している可能性があります。
マテリアライズドビューのステータスを確認してこれを検証できます。具体的な方法については、マテリアライズドビューのステータス確認に関するセクションを参照してください。
Q5: マテリアライズドビューが使用する基底テーブルのデータが変更されたが、マテリアライズドビューがまだリフレッシュされていない場合、透明な書き換えの動作はどうなりますか？
async-materialized viewsと基底テーブルのデータ間には一定の遅延があります。
1. 内部テーブルとデータ変更を感知できる外部テーブル（Hiveなど）の場合：基底テーブルのデータが変更されると、マテリアライズドビューが使用可能かどうかは grace_period しきい値によって決まります。
grace_periodは、マテリアライズドビューと基底テーブル間のデータ不整合を許可する期間です。例えば：
-
grace_periodを0に設定した場合、透明な書き換えに使用するためには、マテリアライズドビューが基底テーブルデータと一致している必要があることを意味します。外部テーブル（Hiveを除く）の場合、データ変更を感知できないため、それらを使用するマテリアライズドビューは透明な書き換えに使用できます（ただし、データが不整合である可能性があります）。 -
grace_periodを10秒に設定した場合、マテリアライズドビューデータと基底テーブルデータ間で最大10秒の遅延を許可します。遅延が10秒以内であれば、マテリアライズドビューは透明な書き換えに使用できます。
2. パーティション化されたマテリアライズドビューで一部のパーティションが無効になった場合、2つのシナリオがあります：
-
クエリが無効なパーティションのデータを使用しない場合、マテリアライズドビューは使用可能です。
-
クエリが無効なパーティションのデータを使用し、データ遅延が
grace_period以内の場合、マテリアライズドビューは使用可能です。遅延がgrace_periodを超える場合、元のテーブルとマテリアライズドビューをunionすることでクエリに応答できます。これにはenable_materialized_view_union_rewriteスイッチの有効化が必要で、バージョン2.1.5からデフォルトで有効になっています。
リファレンス
1 マテリアライズドビュー関連の設定
| 設定 | 説明 |
|---|---|
| SET enable_nereids_planner = true; | マテリアライズドビュー書き換えに必要な新しいオプティマイザーを有効にします。 |
| SET enable_materialized_view_rewrite = true; | クエリ書き換えを有効または無効にします。デフォルト：有効。 |
| SET materialized_view_rewrite_enable_contain_external_table = true; | 外部テーブルを含むマテリアライズドビューの書き換え参加を許可します。デフォルト：無効。 |
| SET materialized_view_rewrite_success_candidate_num = 3; | CBOが考慮する書き換え成功候補の最大数。デフォルト：3。 |
| SET enable_materialized_view_union_rewrite = true; | データが不十分な場合の基底テーブルとマテリアライズドビュー間のUNION ALLを許可します。デフォルト：有効。 |
| SET enable_materialized_view_nest_rewrite = true; | ネストされたマテリアライズドビュー書き換えを有効にします。デフォルト：無効。 |
| SET materialized_view_relation_mapping_max_count = 8; | 書き換え時の関係マッピングの最大数。デフォルト：8。 |
2 透明な書き換え失敗の概要と説明
| 概要 | 説明 |
|---|---|
| View struct info is invalid | マテリアライズドビューの構造情報が無効です。現在書き換えでサポートされているSQLパターンには、クエリとマテリアライズドビューの両方でのjoin、およびクエリでの集約とマテリアライズドビューでのjoinありまたはなしが含まれます。このエラーは透明な書き換え中によく表示されます。各書き換えルールが特定のSQLパターンを担当しているためです。必要なパターンと一致しないルールにヒットした場合、このエラーが発生しますが、一般的に書き換え失敗の主要な原因ではありません。 |
| Materialized view rule exec fail | 通常、透明な書き換えルールの実行中の例外を示します。調査するには、EXPLAIN memo plan query_sqlを使用して具体的な例外スタックを確認してください。 |
| Match mode is invalid | クエリ内のテーブル数がマテリアライズドビュー内のテーブル数と一致せず、書き換えがサポートされません。 |
| Query to view table mapping is null | クエリとマテリアライズドビューテーブル間のマッピング生成に失敗しました。 |
| queryToViewTableMappings are over the limit and be intercepted | クエリ内の自己joinテーブルが多すぎて書き換え空間の過度な拡張を引き起こし、透明な書き換えが停止されました。 |
| Query to view slot mapping is null | クエリとマテリアライズドビューテーブル間のスロットマッピングに失敗しました。 |
| The graph logic between query and view is not consistent | クエリとマテリアライズドビュー間のjoinタイプまたはjoinされたテーブルが異なります。 |
| Predicate compensate fail | 通常、クエリの条件範囲がマテリアライズドビューの範囲を超えている場合に発生します。例：クエリがa > 10だがマテリアライズドビューがa > 15。 |
| Rewrite compensate predicate by view fail | 述語補償に失敗しました。通常、クエリに補償が必要な追加条件があるが、それらの条件で使用される列がマテリアライズドビューのSELECT句に現れない場合です。 |
| Calc invalid partitions fail | パーティション化されたマテリアライズドビューで、クエリが使用するパーティションが有効かどうかの計算に失敗しました。 |
| mv can not offer any partition for query | クエリがマテリアライズドビューの無効なパーティションのみを使用しています（最後のリフレッシュ以降にデータが変更されました）。show partitions from mv_nameでパーティション有効性を確認してください（SyncWithBaseTables=falseはリフレッシュが必要であることを示します）。データ遅延を許可するためにgrace_period（秒単位）を設定してください。 |
| Add filter to base table fail when union rewrite | クエリがマテリアライズドビューの無効なパーティションを使用し、マテリアライズドビューと基底テーブルのunion allの試行に失敗しました。 |
| RewrittenPlan output logical properties is different with target group | 書き換え後、マテリアライズドビューの出力論理プロパティが元のクエリのものと一致しません。 |
| Rewrite expressions by view in join fail | join書き換えにおいて、クエリで使用されるフィールドまたは式がマテリアライズドビューに存在しません。 |
| Rewrite expressions by view in scan fail | 単一テーブル書き換えにおいて、クエリで使用されるフィールドまたは式がマテリアライズドビューに存在しません。 |
| Split view to top plan and agg fail, view doesn't not contain aggregate | 集約書き換え中、マテリアライズドビューに集約関数が含まれていません。 |
| Split query to top plan and agg fail | 集約書き換え中、クエリに集約関数が含まれていません。 |
| rewritten expression contains aggregate functions when group equals aggregate rewrite | クエリとマテリアライズドビューが同じGROUP BYを持つ場合、書き換えられた式に集約関数が含まれています。 |
| Can not rewrite expression when no roll up | クエリとマテリアライズドビューが同じGROUP BYを持つ場合、式の書き換えに失敗しました。 |
| Query function roll up fail | 集約書き換え中、集約関数のroll-upに失敗しました。 |
| View dimensions do not cover the query dimensions | クエリのGROUP BYがマテリアライズドビューのGROUP BYに存在しない次元を使用しています。 |
| View dimensions don't not cover the query dimensions in bottom agg | 上記と同様ですが、下位レベルの集約に固有です。 |
| View dimensions do not cover the query group set dimensions | クエリのGROUP SETSがマテリアライズドビューのGROUP BYに存在しない次元を使用しています。 |
| The only one of query or view is scalar aggregate and can not rewrite expression meanwhile | クエリにはGROUP BYがあるが、マテリアライズドビューにはありません。 |
| Both query and view have group sets, or query doesn't have but view has, not supported | クエリとマテリアライズドビューの両方にGROUP SETSがある、またはマテリアライズドビューのみにある場合のサポートされていない透明な書き換えシナリオです。 |
3 非同期マテリアライズドビューパーティション構築失敗の理由
パーティション化されたマテリアライズドビューのリフレッシュメカニズムは、増分パーティション更新に依存しています：
-
まず、マテリアライズドビューのパーティション列が基底テーブルのパーティション列にマッピングできるかを計算します。
-
次に、具体的なマッピング関係（1:1または1:n）を決定します。
| 概要 | 説明 |
|---|---|
| Partition column cannot be found in the SQL SELECT column | マテリアライズドビュー定義のPARTITION BY後で使用される列は、マテリアライズドビューを定義するSQLのSELECT句に現れる必要があります。 |
| Cannot find a valid partition track column, because %s | 適切なパーティション列を見つけることができません。具体的な理由は「because」の後に続きます。 |
| Partition track does not support mark join | マテリアライズドビューのパーティションフィールドが参照する列が、mark joinの入力テーブルのパーティション列であり、現在サポートされていません。 |
| Partition column is in an unsupported join null generation side | マテリアライズドビューのパーティションフィールドの参照列が、LEFT JOINの右側など、joinのnull生成側にあります。 |
| Relation should be LogicalCatalogRelation | マテリアライズドビューが参照するパーティション基底テーブルのスキャンタイプはLogicalCatalogRelationである必要があります。他のタイプは現在サポートされていません。 |
| Self join does not support partition update | 自己joinを含むSQLクエリの場合、マテリアライズドビューの構築は現在サポートされていません。 |
| Partition track already has a related base table column | マテリアライズドビューが参照するパーティション列は、現在単一の基底テーブルのパーティション列の参照のみをサポートしています。 |
| Relation base table is not MTMVRelatedTableIf | マテリアライズドビューが参照するパーティション基底テーブルがMTMVRelatedTableIfを継承していません。これはテーブルがパーティション化可能かどうかを示します。 |
| The related base table is not a partition table | マテリアライズドビューが使用する基底テーブルがパーティションテーブルではありません。 |
| The related base table partition column doesn't contain the MV partition | マテリアライズドビューのPARTITION BY後で参照される列が、パーティション基底テーブルに存在しません。 |
| Group BY sets are empty, does not contain the target partition | マテリアライズドビューを定義するSQLで集約を使用していますが、GROUP BY句が空です。 |
| Window partition sets do not contain the target partition | ウィンドウ関数を使用していますが、マテリアライズドビューが参照するパーティション列がPARTITION BY句にありません。 |
| Unsupported plan operation in track partition | マテリアライズドビューを定義するSQLがORDER BYなどのサポートされていない操作を使用しています。 |
| Context partition column should be a slot from column | ウィンドウ関数を使用し、PARTITION BY句で、マテリアライズドビューが参照するパーティション列が単純な列ではなく式です。 |
| Partition expressions use more than one slot reference | GROUP BYまたはPARTITION BY後のパーティション列が、単純な列ではなく複数の列を含む式です。例：GROUP BY partition_col + other_col。 |
| Column to check using invalid implicit expression | マテリアライズドビューのパーティション列はdate_trunkでのみ使用でき、パーティション列を使用する式はdate_trunkなどのみです。 |
| Partition column time unit level should be greater than SQL SELECT column | マテリアライズドビューにおいて、PARTITION BY後のdate_trunkの時間単位粒度が、マテリアライズドビューを定義するSQLのSELECT後に現れる時間単位粒度よりも小さいです。例：マテリアライズドビューがPARTITION BY(date_trunc(col, 'day'))を使用しているが、マテリアライズドビューを定義するSQLのSELECT後にdate_trunc(col, 'month')があります。 |