動的テーブルのパフォーマンスをモニターする¶

パフォーマンスのモニターは以下のタスクに役立ちます。

遅いまたはコストのかかる動的テーブルリフレッシュを識別する。
ボトルネックを診断する。
最適化の影響を測定する。

このトピックでは、動的テーブルのパフォーマンスをモニターするために探すものと、問題を診断する方法について説明します。モニターツールの情報については、動的テーブルをモニターするをご参照ください。

Tip

実践例については、チュートリアル：SCD タイプ1ワークロード用に動的テーブルのパフォーマンスを最適化するをご参照ください。

主要なパフォーマンス指標¶

動的テーブルのパフォーマンスをモニターするには、このセクションで説明するメトリックに焦点を当てます。

リフレッシュ期間¶

リフレッシュ時間は、各更新が完了するまでの時間を測定します。パフォーマンスの低下を検出するには、リフレッシュ期間を経時的に追跡します。

警告記号：

期間が時間の経過とともに増加する ：データ量の増加またはデータの局所性の低下により、リフレッシュ時間が徐々に増加する可能性があります。
ターゲットラグに期間が近づく ：リフレッシュがターゲットラグとほぼ同じ時間がかかる場合は、データの鮮度要件を満たさない可能性があります。
期間の分散が高い ：リフレッシュ時間の大きな変動は、ワークロードの急増やリソースの競合を示す可能性があります。

更新期間を表示するには、動的テーブルのリフレッシュ・ステータスの監視をご参照ください。

ラグメトリック¶

ラグメトリックは、動的テーブルがどの程度鮮度ターゲットを満たしているかを示します。ターゲットラグの仕組みについては、動的テーブルのターゲット・ラグの理解をご参照ください。

主要なメトリック：

実際の遅延 ：ソースデータが変更されてから、動的テーブルがその変更を反映するまでの時間。
ターゲットラグ内の時間比率 ：テーブルがターゲットラグ内にとどまっていた時間の割合。比率が1より小さい場合は、パイプラインが鮮度目標を満たしていないことを示します。
最大遅延 ：指定された期間における実際の最長ラグ。

ラグメトリックを表示するには、動的テーブルのリフレッシュ・ステータスの監視をご参照ください。

パーティションの統計¶

インクリメンタルリフレッシュの場合、スキャンされるパーティションの数は、テーブルの合計サイズではなく、変更されたデータに比例する必要があります。パーティションスキャンが高い場合は、データの局所性が低いことを示します。

警告記号：

インクリメンタルリフレッシュ中に、合計パーティションの大部分をスキャンしている。
パーティションスキャンが、対応するデータの増加なしに時間の経過とともに増加している。

パーティションの統計を表示するには、クエリープロファイルの分析をご参照ください。

データの局所性を向上させるためのガイダンスについては、データの局所性を向上させるをご参照ください。

リフレッシュモード¶

リフレッシュモードはパフォーマンスに直接影響します。動的テーブルが予期されるモードを使用していることを確認します。

リフレッシュモードを確認するには、 SHOW DYNAMIC TABLES を使用し、 refresh_mode および refresh_mode_reason 列を精査します。Snowsight で、オブジェクトヘッダーのリフレッシュモードを表示します。

適切なリフレッシュモードの選択のガイダンスについては、リフレッシュモードを選択をご参照ください。

遅いリフレッシュを診断¶

リフレッシュに予想以上に時間がかかる場合は、以下の手順に従って原因を特定してください。

徐々に増加したり、突然急増したりするなど、リフレッシュ期間の傾向をリフレッシュ履歴で確認してください（動的テーブルのリフレッシュ・ステータスの監視）。
クエリプロファイルを確認して、ボトルネックを特定します（クエリープロファイルの分析）：
- 高パーティションスキャンはデータの局所性が低いことを示します。
- スピルしたバイト数は、ウェアハウスが小さすぎることを示しています。
- 特定の演算子で時間がかかっている場合は、動的テーブルクエリを最適化する機会を示している可能性があります。
ラグが一貫してターゲットを超えているかどうかを確認します。これは、リフレッシュがデータ量に対応しない可能性があることを示しています（動的テーブルのリフレッシュ・ステータスの監視）。
上流の依存関係を確認して、上流テーブルが遅延を引き起こすか、大量の変更を生成するかをチェックします。

Snowsight の Graph ビューで、次の条件を探します。
- リフレッシュを実行する上流テーブル（ executing ステータスと共に表示）。
- 上流テーブルの失敗または中断。
- 上流テーブルのリフレッシュに通常より時間がかかる。
Graph ビューにアクセスするには、動的テーブルに接続されたテーブルのグラフ表示をご参照ください。
上流の依存関係から大量の変更があると、リフレッシュが遅くなる可能性があるため、動的テーブルによる処理の変更量を確認してください。

DYNAMIC_TABLE_REFRESH_HISTORY 関数を使用して、最近のリフレッシュで変更された行数を確認します。
```
SELECT
  name,
  data_timestamp,
  statistics:numInsertedRows::INT AS rows_inserted,
  statistics:numDeletedRows::INT AS rows_deleted,
  refresh_action
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
ORDER BY data_timestamp DESC
LIMIT 10;
```
Copy
テーブルの合計サイズに対して変更量が多い場合（テーブル行の5%以上）は、代わりにフルリフレッシュモードの使用を検討してください。

一般的なパターンと推奨アクション¶

リフレッシュ時間は安定しているが、ラグが高い ：現在のウェアハウスのサイズとデータ量に対して、ターゲットラグが厳しすぎる可能性があります。リフレッシュは正常に終了しますが、今後の変更に対処することができません。ターゲットラグおよびウェアハウスリソースがデータ量に応じているかを確認します。
リフレッシュ時間が突然急増し、スピルしたバイト数が多い ：ウェアハウスが小さすぎるか、他のクエリが同時に実行されているため、ウェアハウスのリフレッシュを処理するのに十分なメモリがありません。ウェアハウスサイズを拡大するまたは動的テーブルリフレッシュを専用のウェアハウスに移動します。
パーティションスキャンは時間の経過とともに増加しているが、データ量は同じまま ：データの局所性が低いため、Snowflakeが必要以上にパーティションをスキャンしています。クラスタリングキーとデータの局所性を確認します。また、上流の変更が、いくつかの連続したパーティションではなく、多くの分散したパーティションに影響するかどうかを確認します。
各リフレッシュはテーブルの大部分（行またはパーティションの5%以上）を処理している ：インクリメンタルリフレッシュは、テーブルのほとんどが頻繁に変更される場合にほとんど利点をもたらしません。フルリフレッシュモードへの切り替えまたは、パイプラインを再設計して、リフレッシュごとに変更されるデータ量を削減します。

調査結果に基づいて、動的テーブルのパフォーマンスの最適化から適切な修正を適用してください。

注釈

リフレッシュのスキップや失敗 は通常、パフォーマンスの問題ではなく、構成の問題が原因です。Troubleshooting skipped or failed dynamic table refreshes をご参照ください。

クエリープロファイルの分析¶

クエリプロファイルは、各リフレッシュの詳細な実行統計を表示します。リフレッシュが遅い場合は、クエリプロファイルは最適化の機会を特定するのに役立ちます。

クエリプロファイルにアクセスするには：

Transformation » Dynamic Tables に移動します。
動的テーブルを選択し、 Refresh History タブを開きます。
分析したいリフレッシュの横にある Show query profile を選択します。

まず、更新履歴からクエリIDを取得します。

SELECT
  name,
  refresh_start_time,
  query_id
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
WHERE state = 'SUCCEEDED'
ORDER BY refresh_start_time DESC
LIMIT 5;

Copy

次に、 GET_QUERY_OPERATOR_STATS 関数でクエリプロファイルを分析します。

SELECT *
FROM TABLE(GET_QUERY_OPERATOR_STATS('<query_id>'));

Copy

何を探すか¶

スキャンされたパーティションとプルーニングされたパーティション ：パーティションの総数に対してパーティションスキャンが高い場合、原因は通常データの局所性の不足またはクラスタリングの欠如です。
時間分布 ：どの演算子が最も多くの時間を消費するかを確認します。時間がかかる演算子は、クエリを最適化する機会を示している可能性があります。演算子固有のガイダンスについては、インクリメンタルリフレッシュ向けにクエリを最適化するをご参照ください。
ローカルまたはリモートストレージにスピルしたバイト ：スピルしたバイト数が多い場合は、ウェアハウスがリフレッシュワークロードに対して小さすぎるか、同じウェアハウスで実行されている他のクエリがリフレッシュに使用可能なメモリを減らしていることを示します。ウェアハウスサイズの拡大または専用のウェアハウスで動的テーブルリフレッシュを実行して、競合を低減することを検討してください。

クエリプロファイルで見つかった問題の対処方法の詳細については、動的テーブルのパフォーマンスの最適化をご参照ください。

ウェアハウスの使用状況のモニター¶

ウェアハウスが動的テーブルワークロードを処理できるかどうかを確認し、コストを削減する方法を見つけるには、ウェアハウスの使用状況をモニターします。

モニターする主要メトリック¶

スピルしたバイト数の割合 ：ローカルまたはリモートストレージにスピルしたバイト数は、ウェアハウスが小さすぎる可能性があることを意味します。ウェアハウスサイズの拡大を検討してください。スピルしたバイトの特定とトラブルシューティングの詳細については、ストレージにスピルするクエリの検出をご参照ください。
ウェアハウス利用率 ：ウェアハウスにワークロードをリフレッシュするための十分なリソースがあるかどうかを確認します。利用率が低いことは、大規模なウェアハウスがある可能性があることを意味します。キューの時間が長いということは、ウェアハウスが小さすぎるか、同時クエリの実行が多すぎることを意味します。
クエリのキューイング ：キューに入れられたクエリは、リフレッシュを遅らせます。リフレッシュが頻繁にキューに入れられる場合ウェアハウスのサイズを拡大し、動的テーブルのリフレッシュ専用のウェアハウスを使用するか、変数のワークロードを処理するためにマルチクラスターウェアハウスを検討してください。
クレジット使用状況 ：クレジットを追跡して、パフォーマンスとコストのバランスをとる。定期的にモニターして、ウェアハウスを適切なサイズにしたり、リフレッシュスケジュールを調整したりする機会を見つけてください。

ウェアハウスの使用状況とキュー時間を表示するには、キューの削減をご参照ください。動的テーブルのパフォーマンスの最適化により動的テーブルのウェアハウス設定を最適化します。

依存関係をモニターする¶

動的テーブル間の依存関係はパフォーマンスに影響を与える可能性があります。上流テーブルのパフォーマンス問題は、下流テーブルにカスケードします。下流テーブルは、上流テーブルがリフレッシュを完了するのを待ってからリフレッシュを開始する必要があるためです。

上流依存関係に関連するパフォーマンスの問題を診断するには、遅いリフレッシュを診断をご参照ください。

依存関係のグラフを表示するには、動的テーブルに接続されたテーブルのグラフ表示をご参照ください。

パフォーマンスの問題に関するアラートの設定¶

アラートを設定して、パフォーマンスが低下したときに通知することができます。次の条件に対して、アラートを作成することをお勧めします。

リフレッシュ時間がしきい値を超えている。
ラグが一貫してターゲットに達していない。

アラートは、イベントテーブルを使用してリフレッシュイベントを追跡します。セットアップ手順については、動的テーブルのイベントテーブル監視とアラートをご参照ください。