Snowflakeクエリが遅い原因と高速化チェックリスト完全版

Snowflakeクエリが遅い4大原因をウェアハウス・クラスタリング・キャッシュ・SQL記述に分類した樹形図の概念図 Snowflake
この記事をシェアする𝕏B!FacebookLINEPocket

はじめに:「あれ、なんか遅いぞ?」と思ったら

Snowflakeを使い始めたばかりの皆さん、こんな経験はありませんか?「昨日まで数秒で返ってきたクエリが、今日は1分待っても終わらない…」「同僚のクエリは速いのに、なぜか自分のだけ遅い…」。実はSnowflakeでクエリが遅くなる原因は、ほぼ決まったパターンに分類できます。

この記事では、クエリが遅い原因を「ウェアハウス」「クラスタリング」「キャッシュ」「SQLの書き方」の4つの観点から整理し、初心者でも順番にチェックできる高速化チェックリストとしてまとめました。

原因①:ウェアハウスのサイズが小さすぎる

Snowflakeにおけるウェアハウスとは、クエリを実行する「計算エンジン」のことです。サイズが大きいほど並列処理できる量が増え、クエリは速くなります。

サイズ不足を疑う症状

クエリプロファイルで「Bytes spilled to local/remote storage」(スピル)が大量に発生している場合、メモリ不足のサインです。これに該当する場合は、関連エラーとあわせてSnowflake「Memory limit exceeded」エラーの原因と解決方法も参考になります。

-- ウェアハウスサイズを一時的にXLにスケールアップ
ALTER WAREHOUSE my_wh SET WAREHOUSE_SIZE = 'XLARGE';

-- クエリ実行後、コスト節約のため元に戻す
ALTER WAREHOUSE my_wh SET WAREHOUSE_SIZE = 'SMALL';

キュー待ちを疑う症状

クエリ履歴で「Queued」時間が長い場合は、同じウェアハウスに同時実行が集中しています。マルチクラスターウェアハウスを有効化するか、用途別にウェアハウスを分けましょう。

原因②:プルーニングが効いていない(クラスタリング)

Snowflakeはテーブルをマイクロパーティションという小さなブロック単位で保存しており、クエリ実行時に「読まなくていいブロックをスキップ」する仕組みがあります。これをプルーニングと呼びます。

クエリプロファイルの「Partitions scanned / Partitions total」を確認してみてください。例えば 1000/1000 のように全部読んでいるなら、プルーニングが効いていません。

図解:Snowflakeのマイクロパーティションに対するプルーニングの仕組みを示し、クエリプロファイルのPartitions scanned/total比較や、クラスタリングキー未指定で全ブロックを読む非効率な状態と改善後のスキャン削減イメージを可視化

クラスタリングキーで改善

頻繁にWHERE句で使うカラム(日付など)をクラスタリングキーに指定すると、データが物理的に整理されてプルーニング効率が上がります。

-- 日付カラムでクラスタリング
ALTER TABLE sales_log CLUSTER BY (event_date);

-- クラスタリング状態を確認
SELECT SYSTEM$CLUSTERING_INFORMATION('sales_log');

ただし、クラスタリングは追加コストがかかるので、本当に大規模なテーブル(数十GB以上)にだけ適用するのがコツです。

原因③:キャッシュを活かせていない

Snowflakeには3層のキャッシュがあります。

  • 結果キャッシュ:24時間以内に実行された同一クエリの結果を即座に返します(無料・ウェアハウス不要)
  • ウェアハウスキャッシュ(SSD):稼働中ウェアハウスのローカルSSDに保持
  • リモートディスク:実体のストレージ層

ウェアハウスを頻繁にSUSPEND/RESUMEするとSSDキャッシュが失われ、毎回ストレージから読み直しになります。AUTO_SUSPENDを短くしすぎないこともコツです。

-- AUTO_SUSPEND を 60秒 → 300秒に延長
ALTER WAREHOUSE my_wh SET AUTO_SUSPEND = 300;

原因④:SQLの書き方

SELECT * で全カラム取得、サブクエリ内での重複JOIN、ORDER BY の乱用などは典型的なアンチパターンです。必要なカラムだけを指定し、フィルタ条件は早い段階で適用しましょう。タイムアウトに引っかかる場合は「Statement reached its statement timeout」エラーの対処法も併せてチェックしてみてください。

高速化チェックリストまとめ

  • ウェアハウスサイズは適切?スピル発生していないか?
  • キュー待ち時間が長くないか?(マルチクラスター検討)
  • Partitions scanned/total の比率は低いか?
  • クラスタリングキーを設定すべき大規模テーブルか?
  • AUTO_SUSPEND を短くしすぎていないか?
  • SELECT * や不要なORDER BYを使っていないか?

普段の運用ではACCOUNT_USAGEのQUERY_HISTORYから遅いクエリTOP10を定期的に監視すると、改善対象を見つけやすくなります。

参考リンク

関連記事

この記事をシェアする𝕏B!FacebookLINEPocket