第4章 パフォーマンス最適化・クエリ・変換(Performance & Transformation, 21%)
🎯 この節の学習目標
Snowflake のアーキテクチャ(1章)の要点は、ストレージとコンピュートの分離でした。どのウェアハウスからも同じデータにアクセスできるため、用途ごとにウェアハウスを分けても、データのコピーは一切不要です。そして課金は各ウェアハウスの稼働時間ベースなので、「ウェアハウスを増やすと待機コストが倍増する」ということもありません(使っていなければサスペンドされるだけです)。
そこで実務では、性質の異なるワークロードごとにウェアハウスを分離するのが定石です。
| ワークロード | 特徴 | ウェアハウス設計の例 |
|---|---|---|
| データロード(ETL/ELT) | 夜間バッチなど定期的・計画的。ファイル並列数に応じたサイズで十分 | ロード専用WH。処理量に見合うサイズ、終了後すぐサスペンド |
| BI・ダッシュボード | 多数のユーザーによる小〜中規模クエリが同時多発 | BI専用WH。マルチクラスタで同時実行に追従 |
| アドホック分析・データサイエンス | 少人数だが重いクエリが不定期に発生 | 分析専用WH。必要に応じて大きめサイズ、auto-suspend 活用 |
分離の最大の利点は相互干渉の排除です。夜間ロードが長引いても BI ユーザーのクエリはキューに詰まりませんし、アドホックな重いクエリがダッシュボードを遅くすることもありません。またウェアハウス単位でコストが集計されるため、部門やワークロードごとのコスト把握も容易になります。
図:ワークロード種別ごとの専用ウェアハウスへの分離
1-5 で学んだ2つの拡張方法を、ワークロード管理の観点から整理し直します。
| スケールアップ(サイズ変更) | スケールアウト(マルチクラスタ) | |
|---|---|---|
| 何を変えるか | ウェアハウスのサイズ(XS→S→M…、1段階でノード数・メモリ倍増) | 同一サイズのクラスタの数(MIN/MAX_CLUSTER_COUNT) |
| 解決する問題 | 個々のクエリが重い:複雑な結合・大量データのスキャン・スピルの発生 | 同時実行が多い:キュー待ち(Queued)時間の増大 |
| 効かない問題 | 同時実行の詰まり(1つのクエリは速くなるが、キューは残る) | 個々の重いクエリ(クラスタが増えても1クエリは1クラスタで実行) |
| 典型ワークロード | ETL・アドホックの重い分析 | BI・ダッシュボード |
サイズ選定に万能の公式はありませんが、実務では「小さめで始めて、Query Profile の所見(スピル・実行時間)を見ながら上げる」のが基本です。サイズを1段階上げるとクレジット消費率は倍になりますが、実行時間が半分近くまで短縮されるなら総コストはほぼ変わらず、待ち時間だけが改善します。逆に、小さいクエリしか流れないウェアハウスを大きくしても、ノードが遊ぶだけでコストの無駄になります。
📝 試験のポイント
「複雑で重いクエリ・大量データ処理・スピル → スケールアップ」「同時実行ユーザー数の増加・キュー待ち → スケールアウト(マルチクラスタ)」という対応付けは、シナリオ問題として繰り返し問われます。症状がどちらなのかを見極めるのが解答の鍵です。
Query Acceleration Service(QAS)は、Enterprise エディション以上で利用できる機能で、ウェアハウスで実行中のクエリのうち大規模なスキャン・フィルタ部分をサーバーレスの計算資源へオフロードして並列処理します。ウェアハウス単位で有効化します。
-- QAS を有効化し、スケールファクターを設定する
ALTER WAREHOUSE analytics_wh SET
ENABLE_QUERY_ACCELERATION = TRUE
QUERY_ACCELERATION_MAX_SCALE_FACTOR = 8;通常のウェアハウスとは別に、Snowpark-optimized warehouse という種類があります。同サイズの標準ウェアハウスに比べてノードあたりのメモリが大幅に多く構成されており、Snowpark(Python など)によるメモリ集約的な処理——大規模なデータフレーム操作や機械学習モデルの学習など——に向いています。
CREATE WAREHOUSE ml_wh
WAREHOUSE_SIZE = 'MEDIUM'
WAREHOUSE_TYPE = 'SNOWPARK-OPTIMIZED';SQL 中心の一般的なワークロードには標準ウェアハウスで十分です。「メモリ集約処理(ML学習など)には Snowpark-optimized」という対応だけ覚えておけば試験対策としては足ります。
なお、標準ウェアハウスには改良版の世代である Gen2(第2世代)標準ウェアハウスも提供されています。より新しいハードウェアとソフトウェア最適化により、同じサイズ表記でも従来の標準ウェアハウスより分析クエリや DELETE / UPDATE / MERGE などのテーブル書き換えが高速になるよう設計されています。サイズやマルチクラスタといった使い方の考え方は従来と同じで、「標準ウェアハウスに性能を改良した新世代がある」と押さえておけば十分です。
ウェアハウスの秩序を保つために、次のパラメータを設定できます(アカウント・セッション・ウェアハウスなどのレベルで指定可能です)。
| パラメータ | 意味 | 使いどころ |
|---|---|---|
| STATEMENT_TIMEOUT_IN_SECONDS | ステートメントの実行時間の上限。超えるとクエリは自動的にキャンセルされる | 書き間違いによる暴走クエリが何時間もクレジットを消費するのを防ぐ |
| STATEMENT_QUEUED_TIMEOUT_IN_SECONDS | キュー待ち時間の上限。超えたクエリはキューから取り除かれる | 「古くなったら実行する意味がない」クエリ(ダッシュボードの自動更新など)が、混雑解消後にまとめて流れるのを防ぐ |
| MAX_CONCURRENCY_LEVEL | 1クラスタで同時実行するステートメント数の目安 | 下げると1クエリあたりの資源が増え、上げると同時実行性が増す(通常は既定値のままでよい) |
💡 具体例:アドホック分析用ウェアハウスの保護設定
-- 2時間を超えるクエリは自動キャンセル、5分以上キューに滞留したら取り除く
ALTER WAREHOUSE adhoc_wh SET
STATEMENT_TIMEOUT_IN_SECONDS = 7200
STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = 300;アドホック用ウェアハウスは想定外の重いクエリが流れやすいため、タイムアウトを設定しておくとコストの事故を防げます。2つのパラメータは「実行中の上限」と「待ち時間の上限」という別物である点に注意してください。
✅ この節のまとめ
問1. 夜間のデータロード処理が長引くと、朝のBIダッシュボードのクエリが遅くなるという問題が起きている。Snowflakeにおける最も適切な解決策はどれか。
正解:B
Snowflakeではどのウェアハウスも同じデータにアクセスできるため、ワークロードごとにウェアハウスを分ければ相互干渉がなくなります。これが最も基本的で効果的な設計です。Aは共用のままなので競合が残り、重いロードとBIが同じキューを奪い合う構図は変わりません。Cのようなクエリ単位の優先度指定機能はありません。Dはロードの効率の話であり、干渉問題を解決しません。
問2. Query Acceleration Service(QAS)の説明として正しいものはどれか。
正解:B
QASはEnterprise以上で利用でき、対象クエリのスキャン・フィルタ処理をサーバーレス計算資源へオフロードします。scale factor でウェアハウスの何倍まで借りるかを制御し、断続的に発生する大型クエリに有効です。Aはエディション条件が誤りで、メモリ増強は Snowpark-optimized warehouse の特徴です。Cはクエリ結果キャッシュの説明です。Dはマルチクラスタウェアハウスの説明です。
問3. STATEMENT_QUEUED_TIMEOUT_IN_SECONDS を設定した場合の動作として正しいものはどれか。
正解:B
STATEMENT_QUEUED_TIMEOUT_IN_SECONDS は「キュー待ち時間の上限」で、超過したクエリはキューから除去されます。定期更新のダッシュボードクエリなど、遅れて実行しても意味のないクエリの滞留防止に使います。Aは STATEMENT_TIMEOUT_IN_SECONDS(実行時間の上限)の説明で、2つの区別がこの問題の論点です。Cは AUTO_SUSPEND の説明です。Dのような再優先順位付けの機能はありません。
問4. 次のうち、スケールアップ(ウェアハウスサイズの変更)が適切な場面と、スケールアウト(マルチクラスタ)が適切な場面の組み合わせとして正しいものはどれか。
正解:B
サイズアップは1クラスタあたりの計算資源(ノード数・メモリ)を増やすため、個々の重いクエリ・スピルに効きます。マルチクラスタはクラスタ数を増やして同時実行を捌くため、キュー待ちに効きます。Aは対応が逆です。Cは誤りで、キュー待ちにはスケールアウトが適切であり、サイズアップではキューは解消しません。Dは誤りで、ストレージはコンピュートと独立しており、ウェアハウス設定とは無関係です。