非同期マテリアライズドビューのトラブルシューティング - E-MapReduce

このトピックでは、非同期マテリアライズドビューを検査し、使用中に発生する可能性のある問題を解決する方法について説明します。

非同期マテリアライズドビューの検査

使用している非同期マテリアライズドビューを完全に理解するには、その動作ステータス、更新履歴、およびリソース消費状況を確認します。

動作ステータスの確認

SHOW MATERIALIZED VIEWS コマンドを使用して、非同期マテリアライズドビューの動作ステータスを確認します。

構文

SHOW MATERIALIZED VIEWS
[FROM db_name]
[
WHERE NAME { = "mv_name" | LIKE "mv_name_matcher"}
]

パラメーター	必須	説明
db_name	いいえ	マテリアライズドビューを含むデータベースの名前。このパラメーターを省略した場合、デフォルトで現在のデータベースが使用されます。
mv_name	いいえ	完全一致するマテリアライズドビューの名前。
mv_name_matcher	いいえ	マテリアライズドビュー名のあいまい一致検索用のマッチャー。

返された情報では、次のフィールドに注目してください：

is_active ：マテリアライズドビューがアクティブ状態であるかどうかを示します。アクティブ状態のマテリアライズドビューのみがクエリを高速化し、クエリリライトを有効にできます。
last_refresh_state ：最新の更新のステータス。値には PENDING (待機中)、RUNNING (実行中)、FAILED (失敗)、SUCCESS (成功) が含まれます。
last_refresh_error_message ：最後の更新が失敗した理由。マテリアライズドビューがアクティブ状態でない場合、このフィールドに関連するエラーメッセージが記録されます。
rows ：マテリアライズドビューの行数。更新の遅延により、この値は実際の行数と異なる場合があることに注意してください。

例

SHOW MATERIALIZED VIEWS FROM test_db WHERE NAME LIKE 'mv_pred_2';

更新履歴の表示

information_schema データベースの task_runs テーブルをクエリして、非同期マテリアライズドビューの更新履歴を表示します。返された情報では、次のフィールドに注目してください：

CREATE_TIME と FINISH_TIME ：更新タスクの開始時刻と終了時刻。
STATE ：更新タスクのステータス。値には PENDING (待機中)、RUNNING (実行中)、FAILED (失敗)、SUCCESS (成功) が含まれます。
ERROR_MESSAGE ：更新タスクが失敗した理由。

例：

USE test_db;
SELECT * FROM information_schema.task_runs WHERE task_name ='mv-112517'

リソース消費状況の監視

更新タスクの実行中または実行後に、非同期マテリアライズドビューのリソース消費状況を監視および分析します。

更新タスク実行中のリソース消費状況の監視

更新タスクの実行中に、SHOW PROC '/current_queries'; を使用してリソース消費状況をリアルタイムで監視します。

返された情報では、次のフィールドに注目してください：

ScanBytes ：スキャンされたデータ量。
ScanRows ：スキャンされた行数。
MemoryUsage ：使用されたメモリ量。
CPUTime ：CPU 時間コスト。
ExecTime ：クエリ実行時間。

更新タスク完了後のリソース消費状況の分析

更新タスクの完了後、クエリプロファイルを使用してそのリソース消費状況を分析します。詳細については、「Query Profile の概要」をご参照ください。

非同期マテリアライズドビューが更新されると、INSERT OVERWRITE ステートメントが実行されます。対応するクエリプロファイルを確認して、更新タスクによって消費された時間とリソースを分析します。

返された情報では、次のメトリクスに注目してください：

Total ：クエリによって消費された合計時間。
QueryCpuCost ：クエリの合計 CPU 時間コスト。CPU 時間コストは、同時実行プロセス全体で集計されます。そのため、このメトリクスは実際のクエリ実行時間を超えることがあります。
QueryMemCost ：クエリの合計メモリコスト。
結合演算子や集計演算子などの、その他の演算子固有のメトリクス。

クエリがリライトされたかどうかの検証

EXPLAIN を使用してクエリプランを表示し、クエリが非同期マテリアライズドビューによってリライトされるかどうかを確認します。

クエリプランの SCAN エントリにマテリアライズドビューの名前が表示されている場合、そのクエリはマテリアライズドビューによってリライトされています。

構文

EXPLAIN [ LOGICAL | VERBOSE | COSTS ] <query>

説明

実行計画の詳細レベルは、EXPLAIN LOGICAL < EXPLAIN < EXPLAIN VERBOSE < EXPLAIN COSTS の順になります。

ほとんどの場合、EXPLAIN を使用します。EXPLAIN VERBOSE と EXPLAIN COSTS は大量の冗長な情報を出力するため、主にプランのデバッグに使用されます。

パラメーター	説明
LOGICAL	簡潔な論理実行計画を表示します。
VERBOSE	データ型、NULL 許容情報、最適化戦略などを含む、詳細な論理実行計画を表示します。
COSTS	統計情報を含む、詳細な論理実行計画を表示します。
query	実行計画を表示したいクエリ文。

例 1：マテリアライズドビューによってリライトされたクエリ

データベースとテーブルを作成し、データをインポートします。

CREATE DATABASE IF NOT EXISTS test_db;
use test_db;
CREATE TABLE customer (
  c_custkey     INT(11)     NOT NULL,
  c_name        VARCHAR(26) NOT NULL,
  c_address     VARCHAR(41) NOT NULL,
  c_city        VARCHAR(11) NOT NULL,
  c_nation      VARCHAR(16) NOT NULL,
  c_region      VARCHAR(13) NOT NULL,
  c_phone       VARCHAR(16) NOT NULL,
  c_mktsegment  VARCHAR(11) NOT NULL
) ENGINE=OLAP
DUPLICATE KEY(c_custkey)
DISTRIBUTED BY HASH(c_custkey) BUCKETS 12;
INSERT INTO test_db.customer
WITH LABEL insert_load_customer
 VALUES
(1, 'Customer A', '123 Elm Street', 'New York', 'USA', 'North America', '555-1234', 'AUTOMOBILE'),
(2, 'Customer B', '456 Oak Avenue', 'Los Angeles', 'USA', 'North America', '555-5678', 'BUILDING'),
(3, 'Customer C', '789 Pine Blvd', 'Chicago', 'USA', 'North America', '555-9012', 'FURNITURE'),
(4, 'Customer D', '321 Maple Drive', 'Houston', 'USA', 'North America', '555-3456', 'MACHINERY'),
(5, 'Customer E', '654 Cedar Court', 'Phoenix', 'USA', 'North America', '555-7890', 'HOUSEHOLD');

マテリアライズドビューを作成します。

use test_db;
CREATE MATERIALIZED VIEW `mv_agg` (`c_custkey`)
DISTRIBUTED BY RANDOM
REFRESH ASYNC
PROPERTIES (
"replication_num" = "3",
"replicated_storage" = "true",
"storage_medium" = "HDD"
)
AS SELECT `customer`.`c_custkey`
FROM `test_db`.`customer`
GROUP BY `customer`.`c_custkey`;

クエリプランを表示します。

use test_db;
EXPLAIN LOGICAL SELECT `customer`.`c_custkey`
FROM `test_db`.`customer`
GROUP BY `customer`.`c_custkey`;

結果は次のとおりです。SCAN エントリにマテリアライズドビュー名 mv_agg が表示されており、クエリがマテリアライズドビューによってリライトされたことを示しています。

Explain String
- Output => [1:c_custkey]
- SCAN [mv_agg] => [1:c_custkey]
    MaterializedView: true
    Estimates: {row: 5, cpu: 40.00, memory: 0.00, network: 0.00, cost: 20.00}
    partitionRatio: 1/1, tabletRatio: 12/12
    1:c_custkey := 9:c_custkey

例 2：クエリリライトの無効化

クエリリライトが無効になっている場合、StarRocks は標準のクエリプランを使用します。次のクエリを実行します。

SET enable_materialized_view_rewrite = false;
EXPLAIN LOGICAL SELECT `customer`.`c_custkey`
  FROM `test_db`.`customer`
  GROUP BY `customer`.`c_custkey`;

結果は次のとおりです。SCAN エントリにはベーステーブル customer が表示されます。

Explain String
- Output => [1:c_custkey]
    - AGGREGATE[GLOBAL] [1:c_custkey]
        Estimates: {row: 5, cpu: 20.00, memory: 20.00, network: 0.00, cost: 60.00}
        - SCAN [customer] => [1:c_custkey]
            Estimates: {row: 5, cpu: 20.00, memory: 0.00, network: 0.00, cost: 10.00}
            partitionRatio: 1/1, tabletRatio: 12/12

問題の診断と解決

以下に、非同期マテリアライズドビューを使用する際に発生する可能性のある一般的な問題とその解決策を示します。

非同期マテリアライズドビューの作成失敗

非同期マテリアライズドビューを作成できない場合、つまり CREATE MATERIALIZED VIEW ステートメントが失敗する場合は、次の点を確認してください：

同期マテリアライズドビューを作成するための SQL 構文を誤って使用していないか確認してください。

StarRocks は、同期と非同期の 2 種類のマテリアライズドビューを提供しています。

同期マテリアライズドビューを作成するための基本的な SQL 構文は次のとおりです：
```
CREATE MATERIALIZED VIEW <mv_name> 
AS <query>
```
対照的に、非同期マテリアライズドビューを作成するための SQL 構文には、追加のパラメーターが含まれます：
```
CREATE MATERIALIZED VIEW <mv_name> 
REFRESH ASYNC -- 非同期マテリアライズドビューの更新ポリシー。
DISTRIBUTED BY HASH(<column>) -- 非同期マテリアライズドビューのデータ分散ポリシー。
AS <query>
```
SQL 構文以外の主な違いとして、非同期マテリアライズドビューは StarRocks が提供するすべてのクエリ構文をサポートしますが、同期マテリアライズドビューは限られた集計関数しかサポートしない点が挙げられます。
正しい PARTITION BY 列が指定されているか確認してください。

非同期マテリアライズドビューを作成する際に、パーティショニング戦略を指定して、きめ細かい更新を有効にすることができます。

現在、StarRocks は単一列のパーティションキーと Range Partition のみをサポートしています。パーティション列に対して date_trunc() 関数を使用すると、パーティショニング戦略の粒度レベルをロールアップして変更できます。他の式はサポートされていません。
マテリアライズドビューを作成するために必要な権限があるか確認してください。

非同期マテリアライズドビューを作成するには、クエリ対象のすべてのオブジェクト (テーブル、ビュー、マテリアライズドビュー) に対する SELECT 権限が必要です。クエリで UDF を使用する場合は、その関数に対する USAGE 権限も必要です。

マテリアライズドビューの更新失敗

マテリアライズドビューの更新が失敗する場合、つまり更新タスクのステータスが SUCCESS でない場合は、次の点を確認してください：

不適切な更新ポリシーを使用していないか確認してください。

デフォルトでは、マテリアライズドビューは作成直後に更新されます。ただし、v2.5 以前のバージョンでは、MANUAL 更新ポリシーを持つマテリアライズドビューは作成後に自動で更新されません。REFRESH MATERIALIZED VIEW コマンドを使用して手動で更新する必要があります。
更新タスクがメモリ制限を超えていないか確認してください。

通常、非同期マテリアライズドビューが大規模な集計や結合計算を伴う場合、大量のメモリリソースを消費します。この問題は、以下の方法で解決できます：
- マテリアライズドビューにパーティショニング戦略を指定して、きめ細かい更新を有効にします。
- 更新タスクの中間結果のスピルを有効にします。v3.1 以降、StarRocks はマテリアライズドビューの更新タスクの部分的な中間結果をディスクにスピルすることをサポートしています。次のようなステートメントを実行して、中間結果のスピルを有効にします。
```
-- マテリアライズドビューの作成時にプロパティを定義します。
CREATE MATERIALIZED VIEW mv1 
REFRESH ASYNC
PROPERTIES ( 'session.enable_spill'='true' )
AS <query>;
-- 既存のマテリアライズドビューにプロパティを追加します。
ALTER MATERIALIZED VIEW mv2 SET ('session.enable_spill' = 'true');
```

マテリアライズドビュー更新のタイムアウト

大規模なマテリアライズドビューは、更新タスクがタイムアウト制限を超えたために更新に失敗することがあります。一般的な解決策は次のとおりです：

マテリアライズドビューにパーティショニング戦略を指定して、きめ細かい更新を有効にします。

パーティション化されたマテリアライズドビューの作成で説明されているように、マテリアライズドビューをパーティション化することで、増分ビルドと更新が可能になり、初期更新時の過剰なリソース消費を回避できます。
タイムアウト期間をより長く設定する。

v3.2 より前のバージョンでは、マテリアライズドビューの更新タスクのデフォルトのタイムアウトは 5 分です。v3.2 以降、デフォルトは 1 時間です。タイムアウト例外が発生した場合は、次のコマンドを実行してタイムアウトを延長します。
```
ALTER MATERIALIZED VIEW mv2 SET ( 'session.query_timeout' = '4000' );
```
マテリアライズドビューのパフォーマンスボトルネックを分析する。

マテリアライズドビューが複雑な計算を伴う場合、計算自体に時間がかかることがあります。クエリプロファイルを使用してパフォーマンスボトルネックを分析し、最適化します：
1. information_schema.task_runs をクエリして、更新タスクの query_id を取得します。
2. query_id を使用してクエリプロファイルを取得し、分析します。詳細については、「Query Profile の概要」をご参照ください。

マテリアライズドビューが利用不可

マテリアライズドビューがクエリをリライトまたは更新できず、その is_active ステータスが false の場合、原因はベーステーブルのスキーマ変更である可能性があります。この問題を解決するには、次のコマンドを実行して、マテリアライズドビューのステータスを手動でアクティブに設定します：

ALTER MATERIALIZED VIEW mv1 ACTIVE;

それでも解決しない場合は、マテリアライズドビューを削除して再作成してください。

マテリアライズドビュー更新タスクによる過剰なリソース消費

更新タスクが過剰なシステムリソースを消費していると判明した場合は、次の点を確認してください：

作成されたマテリアライズドビューが大きすぎないか確認してください。

複数のテーブルを結合して負荷の高い計算が発生している場合、更新タスクは大量のリソースを消費します。これを解決するには、マテリアライズドビューのサイズを評価し、その作成を再計画してください。
更新間隔が頻繁すぎないか確認してください。

マテリアライズドビューが固定間隔の更新ポリシーを使用している場合は、更新頻度を減らしてください。更新タスクがベーステーブルのデータ変更によってトリガーされる場合、頻繁なデータインポートがこの問題を引き起こす可能性があります。これを解決するには、マテリアライズドビューに適切な更新ポリシーを定義してください。
マテリアライズドビューがパーティション化されているか確認してください。

パーティション化されていないマテリアライズドビューは、StarRocks が毎回マテリアライズドビュー全体を更新するため、更新中に大量のリソースを消費する可能性があります。これを解決するには、マテリアライズドビューにパーティショニング戦略を指定して、きめ細かい更新を有効にしてください。

過剰なリソースを消費する更新タスクを停止するには：

マテリアライズドビューのステータスを非アクティブに設定して、すべての更新タスクを停止します。
```
ALTER MATERIALIZED VIEW mv1 INACTIVE;
```
CANCEL REFRESH MATERIALIZED VIEW を使用して、実行中の更新タスクを終了します。
```
CANCEL REFRESH MATERIALIZED VIEW mv1;
```

マテリアライズドビューでクエリをリライトできない

マテリアライズドビューが関連するクエリをリライトできない場合は、次の点を確認してください：

TRACE を使用してリライト失敗の理由を診断する

StarRocks は、マテリアライズドビューがクエリをリライトできない理由を診断するための TRACE コマンドを提供しています：
- TRACE LOGS MV <query> ：v3.2 以降で利用でき、詳細なリライトプロセスとリライト失敗の理由を分析できます。
- TRACE REASON MV <query> ：v3.2.8 以降で利用でき、リライト失敗の簡潔な理由を表示します。
例：
```
TRACE REASON MV SELECT SUM(c1) FROM `glue_ice`.`iceberg_test`.`ice_test3`;
```
マテリアライズドビューとクエリが一致するかどうかを確認する
- StarRocks は、テキストベースの一致ではなく構造ベースの一致を使用して、マテリアライズドビューとクエリを照合します。したがって、クエリがマテリアライズドビューの定義と同一に見えても、リライトされない場合があります。
- マテリアライズドビューは、SPJG (Select/Projection/Join/Aggregation) クエリのリライトのみをサポートします。ウィンドウ関数、ネストされた集計、または集計と組み合わせた結合を含むクエリはリライトできません。
- マテリアライズドビューは、外部結合で複雑な結合述語が含まれるクエリをリライトできません。たとえば、A LEFT JOIN B ON A.dt > '2023-01-01' AND A.id = B.id のようなケースでは、述語を JOIN ON 句から WHERE 句に移動してください。
マテリアライズドビューのクエリリライトの制約については、「制約」をご参照ください。
マテリアライズドビューのステータスがアクティブであるか確認する

StarRocks は、クエリをリライトする前にマテリアライズドビューのステータスを確認します。アクティブ状態のマテリアライズドビューのみがクエリをリライトできます。これを解決するには、次のコマンドを実行して、マテリアライズドビューのステータスを手動でアクティブに設定します：
```
ALTER MATERIALIZED VIEW mv1 ACTIVE;
```
マテリアライズドビューがデータ整合性の要件を満たしているか確認する

StarRocks は、マテリアライズドビューとベーステーブル間のデータ整合性をチェックします。デフォルトでは、マテリアライズドビューに最新データが含まれている場合にのみ、クエリはリライトできます。これを解決するには：
- マテリアライズドビューに PROPERTIES('query_rewrite_consistency'='LOOSE') を追加して、整合性チェックを無効にします。
- マテリアライズドビューに PROPERTIES('mv_rewrite_staleness_second'='5') を追加して、ある程度のデータ不整合を許容します。最後の更新がこの時間間隔内に行われていれば、ベーステーブルのデータが変更されたかどうかに関係なく、クエリはリライトできます。
- マテリアライズドビューのクエリ文に出力列が不足していないか確認する
  
  範囲クエリとポイントクエリをリライトするには、フィルタリング述語で使用される列をマテリアライズドビューのクエリの SELECT 式に含める必要があります。マテリアライズドビューの SELECT ステートメントを確認し、クエリの WHERE 句と ORDER BY 句で参照される列が含まれていることを確認してください。
例 1：マテリアライズドビュー mv1 はネストされた集計を使用しているため、クエリをリライトできません。
```
CREATE MATERIALIZED VIEW mv1 REFRESH ASYNC AS
SELECT COUNT(DISTINCT cnt) 
FROM (
    SELECT c_city, COUNT(*) cnt 
    FROM customer 
    GROUP BY c_city
) t;
```
例 2：マテリアライズドビュー mv2 は結合と集計を組み合わせているため、クエリをリライトできません。これを解決するには、まず集計を含むマテリアライズドビューを作成し、そのビューに基づいて結合を含むネストされたマテリアライズドビューを作成します。
```
CREATE MATERIALIZED VIEW mv2 REFRESH ASYNC AS
SELECT *
FROM (
    SELECT lo_orderkey, lo_custkey, p_partkey, p_name
    FROM lineorder
    JOIN part ON lo_partkey = p_partkey
) lo
JOIN (
    SELECT c_custkey
    FROM customer
    GROUP BY c_custkey
) cust
ON lo.lo_custkey = cust.c_custkey;
```
例 3：マテリアライズドビュー mv3 は、述語で参照される列が SELECT 式に含まれていないため、SELECT c_city, sum(tax) FROM tbl WHERE dt='2023-01-01' AND c_city = 'xxx' のようなクエリをリライトできません。
```
CREATE MATERIALIZED VIEW mv3 REFRESH ASYNC AS
SELECT c_city, SUM(tax) FROM tbl GROUP BY c_city;
```
これを解決するには、次のようにマテリアライズドビューを作成します。
```
CREATE MATERIALIZED VIEW mv3 REFRESH ASYNC AS
SELECT dt, c_city, SUM(tax) FROM tbl GROUP BY dt, c_city;
```

マテリアライズドビューのクエリリライトのタイムアウト

ベーステーブルに多くの候補となるマテリアライズドビューがある場合、オプティマイザが候補のマテリアライズドビューを 1 つずつ評価するため、クエリリライトの段階で予想以上に時間がかかることがあります。

optimizer_materialized_view_timelimit のスコープを確認する

optimizer_materialized_view_timelimit はセッション変数です。デフォルト値は 1000 ms です。この値は、単一の候補マテリアライズドビューの最適化タイムアウトであり、クエリリライト段階全体の合計タイムアウトではありません。ベーステーブルに定義されている候補マテリアライズドビューが多いほど、累積評価時間は長くなる可能性があります。その結果、合計リライト時間が単一の timelimit 値を大幅に超えることがあります。
mv_plan_cache_max_size の意味を確認する

mv_plan_cache_max_size は FE の設定項目です。デフォルト値は 1000 です。この値は、マテリアライズドビューのプランキャッシュの最大容量であり、タイムアウト期間ではありません。プランキャッシュには、マテリアライズドビューの事前解析されたプランが保存されます。FE が再起動すると、キャッシュはクリアされ、再構築されます。
タイムアウトがクエリに影響を与える場合は、マテリアライズドビューのリライトを無効にしてください。
```
SET enable_materialized_view_rewrite = false;
```