Amazon Redshift Queries ビューで問題のクエリを特定する

実行したクエリで何か問題やパフォーマンスの課題が発生した時に、実行しているクエリの状態や結果を知りたいときがあります。Redshiftではそんな時にクエリのプランや実行の各処理に要した時間を視覚化し、最適化すべき情報が素早く得られる Queries ビューが標準で提供されています。

Queries ビューにできること

Queries ビューは、過去24時間（デフォルト）に実行されたクエリが表示されます。Queries ビューの各行が一つのクエリに相当し、最も新しく実行したクエリが一番上の行に表示されます。Queryの番号を選択するとクエリの詳細が表示されます。

1. 一般的なクエリの参照（SELECT、INSERT、UPDATE、DELETE、UNLOAD）
2. VACUUM、ANALYZEの過程で実行されるクエリの参照
3. 実行したSQL、プラン、メトリックスの参照
4. 実行中のクエリの停止

※ 以前から気になっていたのですが、実行したはずのクエリが表示されない場合があるようです。後ほどご説明します。

１．一般的なクエリの参照

一般的なクエリ（SELECT、INSERT、UPDATE、DELETE、UNLOAD）については、以下の様に表示されます。

カーソルを使用したSELECTを実行した場合、実行中はSQL文が表示されますが、

実行後にカーソルIDが表示されるのみとなります。数秒以内で終了するカーソルを利用したクエリを確認するのは難しそうです。

２．VACUUM、ANALYZE の参照

VACUUM

VACUUMの実行工程がそれぞれ表示されます。

ANALYZE

実行中は analyze と表示されるのでわかりやすいのですが、ANALYZEが終わると analyze と表示されずその実行工程がそれぞれに置き換えられます。

実行後に確認すると analyze と表示されなくなることをお忘れなく。

３．Query Details の参照

Query Detailsの表示するには、Queries ビューのクエリのID（や虫眼鏡マーク）をクリックします。

また、もう一つの方法は、Performance ビューからクエリのIDをクリックでも開けます。

Query Execution Details セクションが展開されると、そのクエリの実行したSQL、Plan、メトリックス等の詳細画面が表示します。

SQL

実行中もしくは実行済みのSQL文を参照できます。

Query Execution Details

実行中もしくは実行済みのクエリの Plan や実行結果を参照できます。

Plan タブ

実行済みのクエリでも、プランを簡単に確認できます。EXPLAIN を指定してSQLを実行しなくても、プランが参照できるのは便利です。

大きなテーブルに対して Sequential Scan が発生していないか、テーブルをジョインしている時の絞り込み条件の順が適切であるかなどは、一般的なRDBの実行計画の参照のポイントと同様です。

Redshiftならではのポイントとしては、テーブルジョインが DS_DIST_NONE や DS_DIST_ALL_NONE の場合は、コロケーションが予測できますが、それ以外は再分散の発生が懸念されます。クエリで実行される分散の種類を確認し、その分散を変更する必要があるかどうか見極めてください。

• DS_DIST_NONE

対応するスライスはコンピューティングノードにコロケーションされているため、再分散は必要となりません。通常は、DS_DIST_NONE ステップ（ファクトテーブルと単一のディメンションテーブル間の結合）が 1 つあるだけです。

• DS_DIST_ALL_NONE

内部結合テーブルで DISTSTYLE ALL が使用されているため、再分散は必要となりません。テーブル全体が各ノードに配置されます。

• DS_DIST_INNER

内部テーブルが再分散されます。

• DS_BCAST_INNER

内部テーブル全体のコピーがすべてのコンピューティングノードにブロードキャストされます。

• DS_DIST_ALL_INNER

外部テーブルで DISTSTYLE ALL が使用されるため、内部テーブル全体が単一スライスに再分散されます。

• DS_DIST_BOTH

両方のテーブルが再分散されます。

分散計画は、クエリプランの評価  や ステップ 4: 分散スタイルを選択する ご参考にしてください。

Actual タブ

Planと実行結果を突き合わせして、実行クエリを分析できます。PlanとActual（実際のクエリ）の実行ステップ数が異なる場合は、ANALYZE を実行して統計を更新します。

• Avg 統計データスライス間のステップの平均値実行時間、およびその時間が表す合計クエリ実行時間の割合が表示されます。
• Max 統計任意のデータスライスのステップの最長実行時間と、ステップの平均実行時間と最大実行時間の差が表示されます。この差が極端に大きいクエリに着目してチューニングします。

クエリオプティマイザがアラートを検知した場合、アラートに関連付けられた棒グラフにはアラートアイコンが付きます。大きなテーブルで Sequential Scan が頻繁に発生している場合は、ソートキーの見直しを検討してください。

さらに、Actual の棒グラフをクリックすると、Plan から Actual のデータをクエリの実際のパフォーマンスと比較することができます。

Cluster Performance During Query Execution

ここでは、クラスタの Performance タブと同様に、実行している間のメトリックが参照できます。このクエリの実行に利用したリソースの状況やパフォーマンスを把握できます。

• CPU Utilization
• NetworkReceiveThroughput
• NetworkTransmitThroughput
• Write IOPS
• Write Throughput
• Write Latency
• Read IOPS
• Read Throughput
• Read Latency
• Database Connections
• Health Status
• Maintenance Mode
• Percentage of Disk Space Used

以上のメトリックスの参照については、Amazon Redshift Performanceビューから読み解くアクティビティと監視のポイント を御覧ください。

４．実行中のクエリの停止

クエリビューから 実行中のクエリを開き、[Terminate Query] を押すとクエリを停止できます。コンソールへのログインやSQLコマンドの実行が不要なのは便利ですね。

強制終了したクエリは、ロールバックされます。

問題のクエリに出会ったら

なんか遅いと感じたらPerformanceビュー

なんか遅い、そんな時はPerformanceビューを覗くと一目瞭然です。重量級のクエリが同時実行している場合があります。これは、参照用の集計クエリ実行中にネットワークが度々落ちてしまって、それをリトライしていると何度も並列実行されることにより、遅くなってしまうことがあります。ターミナルが落ちて制御不能に陥ってもクエリは終了するまで粛々と動き続けます。（以下、イメージ図です）

こんな時は、「４．実行中のクエリの停止」の手順でクエリ停止することを考えてください。ロールバックされますので、更新系クエリーにも安心して利用できます。

転ばぬ先の杖として、statement_timeoutパラメタやWLMのクエリグループのキューに対してWLM タイムアウトを指定するのも良いでしょう。「なんか遅い、とにかく遅い」と感じたら、Performanceビューを覗いてください。以上のPerformanceビューの参照については、Amazon Redshift Performanceビューから読み解くアクティビティと監視のポイント を御覧ください。

検索や集計が想定以上に時間がかかる

問題のクエリのPlanを確認してください。大きなテーブルに対して Sequential Scan が発生していないか、テーブルをジョインしている時の絞り込み条件の順が適切であるか、再分散が発生していないかなど、確認して下さい。

Actualのグラフにアラートのアイコンが表示されている場合は、SQL文やソートキーの見直しを検討してください。

ノード数を増加したが性能が線形スケールしない

Plan で以下の結合が確認された時は再分散の発生が起こっています。このような場合、Performance ビューのネットワーク関連のメトリックスに再分散による想定外のネットワークIOを確認することができるでしょう。そのような場合は、直ちに分散タイプや分散キーを見なおしてください。 - DS_DIST_INNER - DS_BCAST_INNER - DS_DIST_ALL_INNER - DS_DIST_BOTH

Queries ビューにクエリが表示しないことがある？

クエリを実行しても Queries ビューに反映されないことが時々ありました。クエリの初回実行時には比較的表示されるのですが、特に同じクエリ（プランの実行ファイルがすでにキャッシュ済みのクエリ）を連続すると表示されないことが多く感じられます。

このような場合は、Performance ビューからクエリを選んで、クエリのIDをクリックすることで、Query Execution Details を表示できます。実行したはずのクエリが表示されない場合はこの方法で回避すると良いでしょう。

一般的なクエリ（SELECT、INSERT、UPDATE、DELETE）は表示されないことがありますが、VACUUMやANALYZEの実行は必ず表示されます。チューニングの観点では、同じような Plan のクエリが複数表示されるのはかえって見にくいので、結果的にはこれで良いのだと、自分に言い聞かせています。

まとめ

本番環境のみで発生する問題、再現性が難しい問題など、過去の調査は非常に困難です。なので、事前の設定などなしにすぐに、過去に発生した問題のクエリの特定に取り掛かり、原因究明できるのは、非常にありがたい機能です。

関連記事として、以下のブログがございますので合わせてお読みいただけると問題解決の手法や理解が深まるのではないかと思われます。

Amazon Redshift Performanceビューから読み解くアクティビティと監視のポイント

Amazon Redshift Loads ビューでデータのロードを管理する