実務で効く Snowflake パフォーマンス チューニング入門

2026/03/17 実施のイベント Snowflake Tech Fast Track の登壇資料です。

【Data Superhero セッション】
実務で効く Snowflake パフォーマンスチューニング入門

Snowflakeは基本的に自動最適化が強力なDWHですが、設計やクエリの書き方、Warehouseの使い方によって性能やコストは大きく変わります。本セッションでは、実務でよく遭遇する「クエリが遅い」「コストが増えた」といった課題を題材に、Query Profileの見方、クラスタリングやパーティション設計の考え方、Warehouse設定の基本、dbtと組み合わせて使う際の話など、パフォーマンス改善のためにまず押さえるべきポイントを整理して解説します。明日から使える実践的な考え方を中心に紹介します。

https://www.snowflake.com/snowflake-tech-fast-track/

Transcript

1. © 2026 Snowflake Inc. All Rights Reserved 実務で効く Snowflake パフォーマンス チューニング入門 大野 巧作（けびん） Data Superhero
2. © 2026 Snowflake Inc. All Rights Reserved 自己紹介 大野 巧作（けびん / Kevinrobot34） Data Superhero 2026 Finatext Holdings Ltd. - VP of Data & AI
3. © 2026 Snowflake Inc. All Rights Reserved Agenda 1. パフォーマンス最適化の考え方 2. 最適化施策と事例 a. スキャン量を減らす b. 計算量を減らす c. 計算資源を最適化する 3. まとめ 4. Appendix
4. © 2026 Snowflake Inc. All Rights Reserved パフォーマンス最適化の考え方
5. © 2026 Snowflake Inc. All Rights Reserved パフォーマンス改善のサイクル • 考え方のポイント ◦ まず目標を決め、対象を適切に特定する ◦ 「推測するな、計測せよ」 ◦ パフォーマンス改善施策の3つの視点 対象の特定 調査・実験・計測 パフォーマンス 改善の施策
6. © 2026 Snowflake Inc. All Rights Reserved • ゴールを決めずにはじめてしまうとと、どこまでやっても「まだ改善できるかも」と いう状態が続いて、終わりが見えなくなります。 • 「このクエリを10秒以内に収める」「月のコンピュートコストを20%削減する」のよう に、具体的な目標があって初めて「十分に改善できた」と判断できます。 • 目標が決まったら、どこを改善すれば最も効果が大きいかを考えます。 まだ問題になっていない箇所を先に最適化する（premature optimization）のは 避けましょう。 ◦ 調査コストや実装コストとのトレードオフにも要注意です まず目標を決め、対象を適切に特定する
7. © 2026 Snowflake Inc. All Rights Reserved • 推測や憶測で判断してはダメ 、ということ • 「このツールでこの分析すると遅い」ではなく「このクエリが何秒かかっていて、ク エリの中でもこの処理が一番ボトルネック」というように、Snowflake で実際に何 が起きているのかを見ようとする 姿勢が大事です • Snowflake には Query Profile や Performance Explorer などの機能が充実し ているので、これらを使いこなすことで、これが実現できます 「推測するな、計測せよ」
8. © 2026 Snowflake Inc. All Rights Reserved • このあと事例の紹介もしますが、どれも皆さんの環境とは確実に何かは違いま す。そのため鵜呑みにはしないように気をつけてください。 • また、 Snowflake も日々進化しているので、今日と明日とでは実行結果が異な ることも考えられます。 • 推測はせずに、それぞれの事例に合わせた実験などをして、計測しましょう。そ の上でそれぞれにあった最適化方法を模索してください。 「推測するな、計測せよ」
9. © 2026 Snowflake Inc. All Rights Reserved パフォーマンス改善の 3つの視点 スキャン量を減らす キャッシュやプルーニング を利用し、そもそも読み込 むデータを減らすアプロー チ 計算量を減らす クエリのロジックを見直し、 処理するデータ量を減ら すアプローチ 計算資源を最適化する ウェアハウスの設定や使 い方を見直し、リソースを 無駄なく使うアプローチ 最適化施策のポイントは多岐にわたりますが、 今日はこの3つの視点を軸に、事例も交えて紹介していきます。
10. © 2026 Snowflake Inc. All Rights Reserved 事例：スキャン量を減らす
11. © 2026 Snowflake Inc. All Rights Reserved スキャン量を減らす • パフォーマンス最適化の一つの重要なアプローチは 「無駄なファイルを読み込まない 」ということです。 • 具体例としては以下の通りです ◦ キャッシュを利用する ◦ Partition Pruning
12. © 2026 Snowflake Inc. All Rights Reserved Snowflake の３種のキャッシュ Query Result Cache Metadata Cache Warehouse Cache レイヤー Cloud Service Cloud Service Compute 対象 Query Result Metadata Micro Partition 有効期間 24時間 永続的 Warehouse 起動時 有効化の方法 USE_CACHED_RES ULT=True 自動 自動 • Snowflake には３種類のキャッシュがあります • 基本的には自動で有効化されているため、キャッシュの性質を理解し、 適切にキャッシュが利用されるようにワークロードを修正するのが大事
13. © 2026 Snowflake Inc. All Rights Reserved Partition Pruning と Clustering • Snowflake のデータは micro partition で immutable に保存されています • Where のフィルター条件がある場合、必要がある partition のみを読み込むよう に、できる限り枝刈りをしてくれます → partition pruning という • うまく pruning できるかどうかは、 partition の切り分け方に依存します ◦ つまり Clustering が大事です ◦ Clustering はデータを「ソートしておく」こと ◦ 適切な Clustering はいい感じの partition を 作ってくれる https://www.dremio.com/blog/how-z-ordering-in-apache-iceberg-helps-improve-performance/ より
14. © 2026 Snowflake Inc. All Rights Reserved Clustering の種類 Manual Clustering テーブル作成時に、 明示的にソート条件を指 定しておく テーブルを CTAS で作る 時に order by を追加して おくイメージ。 Natural Clustering テーブルの更新の性質が 良いと、自然とテーブルが Clustering される 適切な差分更新をするの がこちらに該当。 Auto Clustering 明示的に指定したキーで 定期的に Clustering しな おす テーブル作成時に cluster by で指定する。 ※ 追加コストがある 大きく分けて３つの Clustering の方法があります。
15. © 2026 Snowflake Inc. All Rights Reserved Clustering の種類 Manual Clustering テーブル作成時に、 明示的にソート条件を指 定しておく Natural Clustering テーブルの更新の性質が 良いと、自然とテーブルが Clustering される Auto Clustering 明示的に指定したキーで 定期的に Clustering しな おす 大きく分けて３つの Clustering の方法があります。 01/01 01/02 01/03 01/04 01/01 01/02 01/03 01/04 insert insert Sort in DDL data MP1 MP2 MP3 MP4 MP1 MP2 MP3 MP4 CTAS 01/01 01/02 01/03 01/04 data MP1 MP2 MP3 MP4 Sort with Key 定期的に MPを作り直す
16. © 2026 Snowflake Inc. All Rights Reserved Query Profile で確認できる キャッシュについても、 Pruning についても Query Profile で確認可能です
17. © 2026 Snowflake Inc. All Rights Reserved サブクエリ利用時は pruning が効かないことがある ナウキャストの事例 • クエリコンパイルは Cloud Service Layer で行われる • Partition Pruning はクエリコンパイルの中で実行される • 一般にサブクエリは計算しないと結果が分からないため、 サブクエリによる絞り込みは Partition Pruning と相性が悪い • サブクエリを使わないようにクエリを分割し 変数などを使うと Pruning が効くようになる • またサブクエリを使った条件であっても Metadata Cache を利用できるものであれば Partition Pruning が可能 詳細はこちら
18. © 2026 Snowflake Inc. All Rights Reserved 事例：計算量を減らす
19. © 2026 Snowflake Inc. All Rights Reserved 計算量を減らす • パフォーマンス最適化のもう一つの重要なアプローチは 「無駄な計算はしない 」ということです。 • 具体例としては以下の通りです ◦ 結合爆発 (Exploding Join) の解決 ◦ 入れ替え可能な Join と Group By がある場合、先に集約する
20. © 2026 Snowflake Inc. All Rights Reserved 結合爆発（ Exploding Join） • 結合爆発（Exploding Join）とは、 JOINの結果として出力される行数が、 JOINに入力された行数よりも多くなる現象のこと • Query Profile を見ることで簡単に確認できる • いわゆるデカルト積（直積、Cartesian Product） な Joinのこと Outputが Inputより 大きい
21. © 2026 Snowflake Inc. All Rights Reserved 結合爆発（ Exploding Join） • 意図したものであれば仕方ないが、意図せず発生することもよくある ◦ Join の条件が不等号やその他複雑な条件の場合 ▪ この時、 Snowflake はまずデカルト積となる Join を行い、その後に filter を適用する ▪ → 結合条件をなるべくシンプルにできないか検討する ◦ 単純に結合条件を間違っている ▪ → 直しましょう ▪ dbt などのツールがクエリを構築している場合要注意
22. © 2026 Snowflake Inc. All Rights Reserved dbt incremental model のクエリ ナウキャストの事例 • dbt incremental model は dbt で差分更新するための便利な機能です • delete+insert という方式の場合、途中で DELETE 文が自動生成されるのです が、設定の書き方を気をつけないと結合爆発が起きるクエリになることがありまし た。 delete from pos_data where (data_date) in ( select (data_date) from pos_data__dbt_tmp ); delete from pos_data using pos_data__dbt_tmp where ( pos_transaction__dbt_tmp.data_date = pos_transaction.data_date ); unique_key=["data_date"] の場合 → 結合爆発するクエリ unique_key="data_date" の場合 → 結合爆発しないクエリ
23. © 2026 Snowflake Inc. All Rights Reserved dbt incremental model のクエリ ナウキャストの事例 • このように何らかのツールでクエリが生成されている場合には、 実際のクエリと直接向き合うことが重要です。 • 意図したクエリを生成できるようにツールを使いましょう。 ※ この事象は過去に、古いバージョンの 　 dbt を利用していた時のものなので、 　 現在は振る舞いが変わっている部分も 　 あります 詳細はこちら
24. © 2026 Snowflake Inc. All Rights Reserved 事例：計算資源を最適化する
25. © 2026 Snowflake Inc. All Rights Reserved ウェアハウスの力を引き出す • ここまでは「単一クエリの最適化」 の話でした • コストの最適化、という意味だと実はこれだと不十分 ◦ Snowflake のコンピュート課金はあくまでウェアハウスを何分動かしたか？ であり、あるクエリを何分動かしたかではない。 • → ウェアハウスに効率よくクエリを捌いてもらうのが重要 ※ クエリの過度な並列実行は OOM の原因となることもあるのは要注意です
26. © 2026 Snowflake Inc. All Rights Reserved ウェアハウスの MAX_CONCURRENCY_LEVEL • デフォルトでは8になっていて、8本は並列でクエリを動かすことができる • ウェアハウスの画面に行くと並列度の状況を確認することができる 並列実行 直列実行
27. © 2026 Snowflake Inc. All Rights Reserved 並列実行による最適化 ナウキャストの事例：COPY INTO の並列化 • ナウキャストで dbt-snowflake を活用しているプロジェクトでの、データのエクス ポートを dbt macro で実現している箇所があります。 • 単一ウェアハウスのまま並列にクエリを実行できるように設定することでウェアハ ウス稼働時間を最大50%削減することができました。 Query 1 Query 2 Query 3 Query 1 Query 2 Query 3 実行時間 最大50% 削減 詳細はこちら
28. © 2026 Snowflake Inc. All Rights Reserved ウェアハウスの集約による最適化 ファイザーの事例 • Snowflake Summit 2025 で聞いたファイザーの事例です。元々は部署ごとに専 用のウェアハウスを用意してそれぞれ利用していたそうです。 • 共有ウェアハウスを用意し、問題のないワークロードに関してはこれを利用する ように変更したところ、30%程のコスト削減につながったとのこと • ウェアハウスを集約し、計算資源の利用率が 上がったことに良てコスト最適化につながった ということになります。 詳細はこちら
29. © 2026 Snowflake Inc. All Rights Reserved まとめ
30. © 2026 Snowflake Inc. All Rights Reserved まとめ • パフォーマンス改善のサイクルを適切に回しましょう ◦ 目標をまず設定 ◦ 対象の特定 → 調査・実験・計測 → 改善施策の実施 → 再度特定 → … • 改善施策の３つの視点 ◦ スキャン量を減らす ：キャッシュやプルーニング ◦ 計算量を減らす 　　：集約の順序や結合爆発に注意 ◦ 計算資源を最適化 　：適切なクエリの並列実行による最適化 • これらの考え方を踏まえ、ぜひ皆さんのワークロードの最適化に 役立てください！
31. © 2026 Snowflake Inc. All Rights Reserved THANK YOU
32. © 2026 Snowflake Inc. All Rights Reserved Appendix
33. © 2026 Snowflake Inc. All Rights Reserved Snowsight で各機能を利用するのに必要な権限② Query History • 自分が実行したクエリの履歴は追加の権限は無しでいつでも表示されます • 他のユーザーのクエリ履歴を表示するためには、 以下の権限のどれかが必要になります ◦ ACCOUNTADMIN ◦ ある Warehouse の MONITOR または OPERATE 権限 ◦ SNOWFLAKE.GOVERNANCE_VIEWER の DB ロールが付与されている場合、 SQLでは 履歴の確認が可能。さらに SNOWFLAKE db の IMPORTED PRIVILEGES もついている 場合、UIでも見られる。 ▪ しかし SNOWFLAKE db の IMPORTED PRIVILEGES の権限はかなり強いものになる ので要注意 ▪ 例えば SNOWFLAKE.CORTEX_USER などの別の DB ロールも一括で付与されることに なるため、 Query History 以外の権限も管理したい場合には要注意。 ◦ 詳細はこちら
34. © 2026 Snowflake Inc. All Rights Reserved Snowsight で各機能を利用するのに必要な権限② その他の機能 • Query Insights ◦ ACCOUNT_USAGE.QUERY_INSIGHTS ビューにデータはあり、 SNOWFLAKE.GOVERNANCE_VIEWER データベースロールで閲覧可能 ◦ Query Profile のタブとしてみる場合には Query History 側の権限も必要 ◦ 詳細はこちら • Performance Explorer ◦ SNOWFLAKE.PERFORMANCE_EXPLORER_USER アプリケーションロール ◦ 詳細はこちら • Cost Management ◦ SNOWFLAKE.APP_USAGE_VIEWER アプリケーションロール、もしくは SNOWFLAKE.APP_USAGE_ADMIN アプリケーションロールを付与することで閲覧可能 ◦ 詳細はこちら
35. © 2026 Snowflake Inc. All Rights Reserved 重いクエリを特定する具体的な方法 • メモリのスピルがおきているクエリ ◦ account_usage.query_history の中で、bytes_spilled_to_local_storage や bytes_spilled_to_remote_storage が0より大きいクエリを確認すれば良い ◦ 詳細はこちら • ウェアハウスのサイズがあってないクエリ ◦ Account_usage.warehouse_load_history で、 avg_queued_load が0より大きいものを確認すれば良い ◦ 詳細はこちら • 結合爆発のおきているクエリ ◦ 直接は確認できないので、まず実行時間の長いクエリを探す ◦ その上で GET_QUERY_OPERATOR_STATS を利用し、 output_rows / input_rows が大きい ノードが存在しないかを確認する ◦ 詳細はこちら
36. © 2026 Snowflake Inc. All Rights Reserved 参考資料 • https://medium.com/snowflake/the-basics-of-joins-in-snowflake-3da7736075f9 • https://medium.com/snowflake/snowflake-clustering-demystified-8042fa81289e • https://docs.google.com/presentation/d/1PabfRSyOzNaQ2Anr2Zimaio2KrYiqZidhRpsxcWfk4A/edit#slide=id.p • https://select.dev/posts/snowflake-clustering • https://select.dev/posts/snowflake-range-join-optimization • https://www.linkedin.com/pulse/query-lifecycle-snowflake-minzhen-yang-7mbfc • https://www.linkedin.com/pulse/query-compilation-overview-snowflake-minzhen-yang-upudc • https://www.linkedin.com/pulse/pruner-pruning-snowflake-part-1-overview-minzhen-yang-hbcec • https://zenn.dev/indigo13love/articles/b93ab72f34aa72 • https://zenn.dev/dataheroes/articles/bd4b285c0ab751 • https://zenn.dev/dataheroes/articles/a3ee996f6477d7 • https://zenn.dev/finatext/articles/snowflake-chache • https://zenn.dev/finatext/articles/snowflake-subquery-and-pruning • https://zenn.dev/finatext/articles/snowflake-summit-2025-consolidating-warehouse • https://zenn.dev/finatext/articles/snowflake-summit-2025-boost-query-performance • https://zenn.dev/finatext/articles/snowflake-summit-2025-adaptive-compute • https://zenn.dev/finatext/articles/61c4a1bf4a2a1e • https://techblog.finatext.com/dbt-snowflake-incremental-exploding-joins-7ca8a6b484ca • https://techblog.finatext.com/jp-optimizing-pipelines-controlling-concurrency-in-snowflake-and-dbt-6ed7dab57c8c
37. © 2026 Snowflake Inc. All Rights Reserved THANK YOU