Zenn
🏡

SnowPro Core資格への道 ~Part11：パフォーマンスに対するウェアハウスの最適化~

に公開
Snowflake
SnowPro Core
tech

はじめに

9月のSnowflake World Tour TokyoまでにSnowPro Coreをとります！

試験を8月28日(木)に受けようと思います。あと32日。
先週からProCoreのUdemy2周目を始めていて、ここにきて初めて7割取れた！
正直お盆以降SWTに向けたイベント準備とかやることが多すぎる。
自分で完結できることは早く終わらせたくなってきているので、スピードアップするー(っていう言霊）

現在こちらのUdemyの問題を解いています。
Snowflake SnowPro Core Certification Practice Tests COF-C02

過去のSnowPro Core合格体験記を今更読んだ

https://zenn.dev/ognr_jp/articles/f471814de95c02
https://qiita.com/a-kamiya/items/bf009967d5051f0f4353

どうやら過去の合格者はこのUdemyの方がよくつかわれているみたい。
https://www.udemy.com/course/snowflake-snowpro-core-certification-questions-exam/

今のUdemyを3周してある程度自信がついてきてから、買うことにします。

パフォーマンスに対するウェアハウスの最適化

https://docs.snowflake.com/ja/user-guide/performance-query-warehouse

このページを参照し「サルでもわかるように説明して」ってAIに教えてもらったのが下記の説明です。
公式ドキュメントより分かりやすいなと思ったので、ほぼそのまま公開します。
復習の過程で間違ってそうなものがあったら加筆する予定です。

1. 行列をなくそう！（キューを減らす）

🐵 サルでもわかる解説

人気のバナナ屋さんに、たくさんのサルが並んでいたら、自分の番まで時間がかかりますよね？Snowflakeも同じで、たくさんのクエリ（お願いごと）が列を作って待っている（キューイング）と、どんどん遅くなってしまいます。

💡 こうしよう

  • レジを増やす（マルチクラスターウェアハウス）: たくさんのクエリを同時にさばけるように、ウェアハウスのクラスター数を増やしましょう。レジが増えれば、行列は短くなりますよね！
  • 実行時間を監視する: どのクエリが長く待たされているかチェックして、対策を考えましょう。

2. 机を大きくしよう！（メモリスピルを解決する）

🐵 サルでもわかる解説

小さな机でたくさんのバナナの皮むきをすると、バナナが机からこぼれ落ちてしまいますよね？それを拾うのは大変です。
Snowflakeも、メモリ（机）が足りないと、データを一時的にディスク（床）に置く（スピル）ことがあります。床からデータを拾ってくるのは時間がかかるので、パフォーマンスが落ちてしまいます。

💡 こうしよう

  • もっと大きな机を使う（ウェアハウスのサイズを大きくする）: メモリをたくさん使えるように、ウェアハウスのサイズを X-Small から Small や Medium に大きくしてみましょう。机が広ければ、バナナがこぼれる心配もありません！

3. もっと力持ちになろう！（ウェアハウスサイズを拡大する）

🐵 サルでもわかる解説

たくさんのバナナの箱を一度に運びたいとき、小さなサルより大きなゴリラの方が早いですよね？
複雑で重いクエリ（たくさんのバナナの箱）を処理するときは、ウェアハウスのサイズを大きくすると、パワフルになって処理が速くなります。

💡 こうしよう

  • ウェアハウスのサイズを大きくする: クエリの実行に時間がかかっている場合、ウェアハウスのサイズを一段階上げてみましょう。Medium を Large にするだけで、見違えるほど速くなることもあります。

4. すごい助っ人を呼ぼう！（クエリアクセラレーション）

🐵 サルでもわかる解説

バナナの皮むき大会で、自分だけでは大変なとき、超高速で皮をむいてくれるすごい助っ人がいたら助かりますよね？
クエリアクセラレーションサービスは、まさにそんな存在です。重い処理の一部を、Snowflakeが用意した特別な助っ人部隊（サーバーレスリソース）に任せることで、自分のウェアハウスの負担を減らし、処理を高速化できます。

💡 こうしよう

  • クエリアクセラレーションを試す: 大規模なスキャンやソートが発生するクエリで有効です。ウェアハウスの設定で有効にできるか確認してみましょう。

5. よく使うバナナは手元に置こう！（キャッシュの最適化）

🐵 サルでもわかる解説

毎日食べるバナナを、いちいち遠くの倉庫まで取りに行くのは面倒ですよね？よく使うものは、手元のカゴに入れておけば（キャッシュ）、すぐ取り出せて便利です。
Snowflakeも一度実行したクエリの結果などをキャッシュしているので、同じクエリが来たときに高速で結果を返せます。

💡 こうしよう

  • 同じクエリを繰り返し実行するような使い方を意識する: BIツールなどで同じダッシュボードを何度も見るときなどは、キャッシュが効いて2回目以降の表示が速くなります。この仕組みをうまく活用しましょう。

6. 一度に欲張りすぎない！（同時実行クエリを制限する）

🐵 サルでもわかる解説

一度に10本のバナナを食べようとすると、口がいっぱいになって、かえって食べるのが遅くなってしまいますよね？
Snowflakeも、一度にたくさんのクエリを実行しすぎると（同時実行数が多い）、リソースが分散してしまい、一つ一つのクエリが遅くなることがあります。

💡 こうしよう

  • 同時実行レベルを調整する: MAX_CONCURRENCY_LEVEL パラメータを設定して、同時に実行できるクエリの数をあえて制限することで、リソースの競合を防ぎ、安定したパフォーマンスを保つことができます。

実際やってみた

-- テスト用の小さいウェアハウスを作成
CREATE OR REPLACE WAREHOUSE anata_no_test_wh
  WAREHOUSE_SIZE = 'X-SMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

-- 作成したウェアハウスを使用する
USE WAREHOUSE anata_no_test_wh;

-- 特定期間における高額購入顧客トップ100を抽出するクエリを動かしてみる
SELECT
    c.c_first_name,
    c.c_last_name,
    SUM(ss.ss_net_paid_inc_tax) as total_spent
FROM
    SNOWFLAKE_SAMPLE_DATA.TPCDS_SF100TCL.STORE_SALES AS ss
JOIN
    SNOWFLAKE_SAMPLE_DATA.TPCDS_SF100TCL.CUSTOMER AS c ON ss.ss_customer_sk = c.c_customer_sk
JOIN
    SNOWFLAKE_SAMPLE_DATA.TPCDS_SF100TCL.DATE_DIM AS d ON ss.ss_sold_date_sk = d.d_date_sk
WHERE
    d.d_year = 2000 AND d.d_moy BETWEEN 1 AND 6 -- 2000年の上半期に限定
GROUP BY
    c.c_customer_sk,
    c.c_first_name,
    c.c_last_name
ORDER BY
    total_spent DESC
LIMIT 100;

-- セッションキャッシュを無効にする（純粋な性能比較のため）
ALTER SESSION SET USE_CACHED_RESULT = FALSE;
-- ウェアハウスのサイズをLARGEに変更（スケールアップ）
ALTER WAREHOUSE anata_no_test_wh SET WAREHOUSE_SIZE = 'LARGE';

-- 特定期間における高額購入顧客トップ100を抽出するクエリを動かしてみる
SELECT
    c.c_first_name,
    c.c_last_name,
    SUM(ss.ss_net_paid_inc_tax) as total_spent
FROM
    SNOWFLAKE_SAMPLE_DATA.TPCDS_SF100TCL.STORE_SALES AS ss
JOIN
    SNOWFLAKE_SAMPLE_DATA.TPCDS_SF100TCL.CUSTOMER AS c ON ss.ss_customer_sk = c.c_customer_sk
JOIN
    SNOWFLAKE_SAMPLE_DATA.TPCDS_SF100TCL.DATE_DIM AS d ON ss.ss_sold_date_sk = d.d_date_sk
WHERE
    d.d_year = 2000 AND d.d_moy BETWEEN 1 AND 6 -- 2000年の上半期に限定
GROUP BY
    c.c_customer_sk,
    c.c_first_name,
    c.c_last_name
ORDER BY
    total_spent DESC
LIMIT 100;

XSで10TBのデータ検索を実行してみた結果、14分16秒かかりました！
ちなみに、ちゃんとクエリプロファイルを作れたことが個人的にはうれしかったりするw

ウェアハウスをLに変更、セッションキャッシュを無効にして実行したところ・・・
1分39秒？！すんごい速い！
業務とかでウェアハウスを自分の判断で変えることはほぼないので、感動するほどです。

まとめ

Snowflakeのパフォーマンス改善は、まるでサルのバナナ問題と同じくらいシンプルです！

  1. 行列をなくす（キューを減らす）
  2. 机を大きくする（メモリスピルを解決する）
  3. 力持ちになる（ウェアハウスサイズを拡大する）
  4. 助っ人を呼ぶ（クエリアクセラレーション）
  5. よく使うものは手元に（キャッシュの最適化）
  6. 欲張りすぎない（同時実行クエリを制限する）

これらのポイントを意識して、快適なSnowflakeライフを送りましょう！ 🚀

Discussion