📝 この記事について
SnowPro Core認定（COF-C03）の合格までにまとめた学習内容を、自身の備忘録として記事化したものです。本記事は分野1.0「Snowflake AIデータクラウドの機能とアーキテクチャ（約31%）」のまとめです。
試験全体の概要はこちらの概要記事を参照してください。
■ Snowflakeクレジットの費用
Snowflakeクレジットの費用は、クラウドプロバイダー、リージョン、アカウントエディションなど、インフラストラクチャおよびサービス関連の変数によって異なり、これらの要素はSnowflakeアカウントにおけるコンピューティングとストレージの基本料金に影響します。
ただし、SQL文の長さは料金に影響しません。 重要なのは、仮想ウェアハウスの稼働時間（つまり、起動状態にある時間）、消費するコンピューティングリソースの量、そして自動スケーリングやマルチクラスタウェアハウスなどの機能を使用しているかどうかです。
■ Snowflake アーキテクチャの3層構造
1. データベースストレージ (Database Storage)
データがロードされると、Snowflakeは自動的にデータを整理し、管理します。
- 機能: 永続データの中央リポジトリとして機能します。
-
特徴:
- データを最適化・圧縮された列指向形式で保存します。
- データを「マイクロパーティション」と呼ばれる連続したストレージ単位に自動分割します。
- 構造化、半構造化（JSON/XMLなど）、非構造化データのすべてをサポートします。
2. コンピュート (Compute)
クエリの実行やデータの処理を担当するレイヤーで、「仮想ウェアハウス」と呼ばれます。
- 機能: 大規模並列処理（MPP）コンピュートクラスターを使用して、クエリやデータロードを実行します。
-
特徴:
- ストレージとコンピュートが完全に分離されているため、それぞれを個別にスケーリング可能です。
- 各ノードはデータセットの一部をローカルにキャッシュし、処理を高速化します。
3. クラウドサービス (Cloud Services)
Snowflakeの全体的な調整と管理を行う「脳」にあたるレイヤーです。
- 機能: ユーザーのリクエストを処理するために、プラットフォームの全コンポーネントを結び付けます。
-
主な管理項目:
- 認証とアクセス制御: ユーザーのセキュリティと権限を管理します。
- メタデータ管理: オブジェクト情報や統計情報を管理します（Snowflake Horizon カタログ）。
- クエリの最適化: SQLの解析と最適な実行プランの作成を行います。
- インフラ管理: ソフトウェアの更新やチューニング、継続的なメンテナンスを自動で行います。
■ マイクロパーティションとデータクラスタリング
1. マイクロパーティション (Micro-partitions)
Snowflakeにおけるデータの最小管理単位であり、すべてのテーブルデータは自動的にこの形式で保存されます。
- 自動分割: データのロード時に、非圧縮状態で50MBから500MBの連続したストレージ単位に自動的に分割されます。この処理は、データが挿入される自然な順序に基づいて行われます。
- 列指向（カラムナー）形式: 各マイクロパーティション内では、データは列ごとに整理・圧縮されて保存されます。
- メタデータの保持: Snowflakeは、パーティションごとに全列の値の範囲（最小値・最大値）や個別の値の数などの統計情報を管理します。
-
メリット:
- プルーニング（間引き）: メタデータを利用して、クエリに不要なパーティションを読み飛ばすため、スキャン効率が劇的に向上します。
- 運用の簡素化: ユーザーが手動でパーティションを定義したり保守したりする必要はありません。
2. データクラスタリング (Data Clustering)
テーブル内のデータが、特定の列（日付や地域など）に沿ってどの程度整理（ソート）されているかを示す概念です。
- クラスタリングメタデータ: データがロードされる際、各マイクロパーティション内のデータの並び順に関する情報が自動的に記録されます。
- クラスタリングの深さ (Clustering Depth): 特定の列に関して、マイクロパーティション同士がどれだけ重なり合っているかを示す指標です。深さが小さい（1に近い）ほど、データが適切に整理（ソート）されており、クエリのパフォーマンスが向上します。
- クラスタリングキー (Clustering Key): 数テラバイトを超えるような巨大なテーブルにおいて、明示的にソートの基準となる列を指定する機能です。指定されたキーに基づいて、Snowflakeがバックグラウンドで自動的にデータを再整理（自動クラスタリング）します。
| 機能 | 役割 |
|---|---|
| マイクロパーティション | データを物理的にどう分けるか（Snowflakeが自動で最適化） |
| データクラスタリング | 分けられたデータが特定の列でどう並んでいるか（ソートの度合い） |
■ 仮想ウェアハウス（Virtual Warehouse）概要
1. 基本概念と役割
- 定義: Snowflakeのコンピューティングリソースのクラスターです。
- 主な機能: SQLクエリの処理、およびデータのロードを含むすべてのDML操作の実行を担当します。
- 特徴: 各ウェアハウスは独立した計算リソースを持ち、他のウェアハウスのパフォーマンスに影響を与えません。
2. サイズとパフォーマンス
- スケーリング: XS（最小）から6XL（最大）までのサイズがあり、サイズが1つ上がるごとに計算リソースと時間あたりのクレジット消費量が2倍になります。
- 柔軟性: ウェアハウスは稼働中でもいつでもサイズ変更（アップサイズ/ダウンサイズ）が可能です。
- 最適化: 大規模で複雑なクエリの処理時間は通常サイズに依存しますが、基本的な小規模クエリではリソースが大きいほど高速になるとは限りません。
3. コストと管理機能
- 課金体系: 起動するたびに最小60秒間、その後は1秒単位でクレジットが請求されます。
- 自動中断 (Auto-suspend): 指定された期間アクティブでない場合、ウェアハウスを自動的に一時停止してコストを抑制します。
- 自動再開 (Auto-resume): クエリが送信されると、一時停止中のウェアハウスを自動的に起動します。
4. 高度な構成
- マルチクラスターウェアハウス: 単一のウェアハウスに対して複数のコンピューティングクラスターを割り当て、ユーザーやクエリの急増（同時実行性）に自動スケーリングで対応する機能です。
- ウェアハウスタイプ: 「標準（Standard）」に加え、大規模なメモリを必要とする処理に適した「Snowpark用に最適化（Snowpark-optimized）」タイプが選択できます。
5. デフォルト設定の優先順位
セッションで使用されるデフォルトのウェアハウスは、以下の順序で決定（上書き）されます。
- ユーザーレベルのデフォルト設定
- クライアントツール（SnowSQLなど）の構成ファイルの設定
- 接続時のパラメータ指定
- セッション内での
USE WAREHOUSEコマンド実行（最終的な適用）
6. 仮想ウェアハウスの作成と詳細構成
仮想ウェアハウスを作成するには CREATE WAREHOUSE コマンドを使用します。ウェアハウスは、計算リソースの量、自動化の動作、および制限事項を定義する多くのプロパティによって構成されます。
6-1. 基本構成プロパティ
ウェアハウスの処理能力とワークロードのタイプを決定します。
| プロパティ | 説明 | 補足・デフォルト |
|---|---|---|
| WAREHOUSE_TYPE | 標準 または Snowpark最適化 を選択。 | Snowpark最適化はメモリ消費の多い処理向け。 |
| WAREHOUSE_SIZE | XS から 6XL までのサイズ。 | サイズが上がるとクレジット消費は倍増。 |
| GENERATION | コンピュートリソースの世代（'1' または '2'）。 | デフォルトは '1'。Gen2はパフォーマンスが向上。 |
| RESOURCE_CONSTRAINT | 特定のメモリやCPUアーキテクチャを指定。 | Snowpark最適化などの詳細なリソース定義に使用。 |
6-2. スケーリングと可用性（マルチクラスター）
Enterprise Edition以上で利用可能な、負荷に応じた自動拡張設定です。
| プロパティ | 説明 | 補足・デフォルト |
|---|---|---|
| MAX_CLUSTER_COUNT | 使用するクラスターの最大数。 | デフォルトは 1（単一クラスター）。 |
| MIN_CLUSTER_COUNT | 使用するクラスターの最小数。 | 最大数と同じなら「最大化モード」となる。 |
| SCALING_POLICY | クラスターの開始・停止の優先順位。 | STANDARD（待機最小）または ECONOMY（節約）。 |
6-3. 自動管理とコスト制御
運用の手間を省き、クレジットの浪費を防ぐための設定です。
| プロパティ | 説明 | 補足・デフォルト |
|---|---|---|
| AUTO_SUSPEND | 指定秒数の非アクティブ後に自動停止。 | デフォルトは 600秒（10分）。0またはNULLで無効。 |
| AUTO_RESUME | クエリ送信時に自動で再開するか。 | デフォルトは TRUE。 |
| INITIALLY_SUSPENDED | 作成直後に「一時停止」状態にするか。 | デフォルトは FALSE（直ちに稼働）。 |
| RESOURCE_MONITOR | 割り当てるリソースモニターの名前。 | 特定のクレジット制限を適用。 |
6-4. パフォーマンスと制限のパラメーター（Object Parameters）
個別のクエリ実行における詳細な制限を定義します。
- MAX_CONCURRENCY_LEVEL: ウェアハウスが同時に実行するSQLステートメントの目標数（デフォルトは8）。
- STATEMENT_TIMEOUT_IN_SECONDS: 実行中のクエリを強制終了するまでの制限時間（デフォルトは2日間）。
- STATEMENT_QUEUED_TIMEOUT_IN_SECONDS: クエリがキュー（待機状態）でキャンセルされるまでの時間。
- ENABLE_QUERY_ACCELERATION: 重いクエリの処理を高速化する「クエリアクセラレーションサービス」の有効化。
6-5. 作成権限と所有権
- デフォルトでは SYSADMIN ロール またはそれ以上のロールに作成権限があります。
- ウェアハウスを作成したロールには、そのオブジェクトに対する
OWNERSHIP権限が自動的に付与されます。
7. ウェアハウスの最適化
| 戦略 | 内容・効果 |
|---|---|
| サイズを拡大する | 計算リソースを増やし、大規模・複雑なクエリの処理を高速化します。 |
| マルチクラスターの利用 | コンシューマー数（同時実行数）が多い場合に自動拡張し、キューイング（待機）を削減します。 |
| 同時実行クエリの制限 | 同時に実行するクエリ数を絞ることで、1つあたりのクエリに割り当てるリソースを確保し、パフォーマンスを安定させます。 |
| メモリスピルの解決 | メモリ不足によるストレージへの書き出し（スピル）を防ぐよう調整し、実行速度の低下を回避します。 |
| キャッシュの最適化 | テーブルではなくウェアハウスのキャッシュからデータを読み込むようにすることで、クエリを高速化します。 |
| クエリアクセラレーション | 特定の重いクエリの一部をサーバーレスリソースにオフロードし、ウェアハウス全体の負荷を軽減します。 |
■ Snowflake クローン (CLONE) 概要
1. 基本概念：ゼロコピークローン
- 定義: システム内にある既存のオブジェクト（データベース、スキーマ、テーブルなど）のコピーを作成する機能です。
- ゼロコピー: 実際のデータは複製せず、メタデータのみをコピーするため、物理的なストレージコストを即座に消費しません。
- 独立性: クローン作成後はソースから完全に独立しており、一方への変更はもう一方には反映されません。
2. 主な特徴とメリット
- ストレージ効率: クローンに対してデータの追加・削除・変更が行われるまで、追加のストレージ料金は発生しません。
-
Time Travel 連携:
ATやBEFORE句を使用することで、過去の特定の時点の状態をクローンとして再現可能です。 - 再帰的コピー: データベースをクローンすると、その中のすべてのスキーマやオブジェクトも自動的にクローンされます。
3. 権限とプロパティの継承
- メタデータの継承: オブジェクト名や構造だけでなく、コメントやクラスタリングキーなどのメタデータも継承されます。
- 権限のコピー (COPY GRANTS): このパラメータを使用すると、元のオブジェクトに付与されていたアクセス権限（所有権を除く）を継承できます。
-
実行権限: テーブルのクローンには
SELECT権限、データベースにはUSAGE権限など、ソースオブジェクトに対する特定の権限が必要です。
4. クローンされないオブジェクト（注意点）
以下のオブジェクトは、データベースやスキーマをクローンしても含まれません。
- 外部テーブル
- 内部パイプ（外部ステージを参照するパイプのみクローン可能）
- ロード履歴: ソーステーブルのロード履歴は継承されないため、同じファイルをクローンに再度ロードできてしまいます。
5. 主なユースケース
- 開発・テスト: 本番データのスナップショットを即座に作成し、開発環境として利用する。
- バックアップ: 特定時点の状態を保存し、不測の事態に備える。
- データ共有: 特定の時点のデータセットを別環境に提供する。
■ リソースモニター（Resource Monitor）概要
1. 基本機能と目的
- 目的: 仮想ウェアハウスによるクレジット消費を監視・制御し、予期しないコストの発生を回避します。
- 監視対象: ユーザーが管理する仮想ウェアハウスおよびそれをサポートするクラウドサービスが対象です。
- 対象外: Snowpipeや自動再クラスタリングなどのサーバーレス機能、およびAIサービスは監視できません（これらには「予算（Budgets）」を使用します）。
2. モニターのタイプ
| タイプ | 監視範囲 | 特徴 |
|---|---|---|
| アカウント | アカウント内の全ウェアハウス | アカウントごとに1つのみ設定可能。 |
| ウェアハウス | 特定の1つまたは複数のウェアハウス | 複数を並行して運用可能。1つのウェアハウスを複数のモニターに割り当てることはできません。 |
3. 主なプロパティ
- クレジットクォータ: 指定した期間内に使用を許可するクレジット数。
- スケジュール: 監視の開始・終了日時や、リセット周期（毎日、毎週、毎月、毎年、なし）を指定します。デフォルトは毎月リセットです。
-
アクション（トリガー）: クォータの閾値（%）に達した際の動作を定義します。
- 通知: 管理者にアラートを送信します。
- 通知と一時停止: 実行中のクエリが完了した後にウェアハウスを停止します。
- 通知と即時一時停止: 実行中のクエリを直ちにキャンセルし、ウェアハウスを停止します。
4. アクセス制御と権限
- 作成権限: ACCOUNTADMIN ロールを持つユーザーのみが作成できます。
-
管理と表示: 適切なロールに
MONITOR（表示）やMODIFY（変更）権限を付与することで、管理権限を委譲できます。 - 通知の受信: アカウント管理者に加え、ウェアハウスモニターの場合は最大5人までの管理者以外のユーザー（要メール認証）を通知リストに登録できます。
5. 運用の注意点
- 厳密性の制限: ウェアハウスが停止するまでに若干のラグがあるため、設定したクォータをわずかに超えてクレジットを消費する可能性があります。
- 割り当て制限: 1つのモニターに割り当てられるウェアハウスの最大数は500個です。
- 通知設定: リソースモニターを作成しただけでは通知されません。各ユーザーのプロファイル設定で通知を明示的に有効にする必要があります。
📎 マイナー関数・コマンド一覧（試験対策）
🗂 ステージ・ファイル操作系
| コマンド/関数 | 何をするか | 覚え方 |
|---|---|---|
GET_PRESIGNED_URL(stage, path, expiry) |
外部ステージのファイルへの有効期限付きURLを生成 | Presigned = 事前署名 = 期限付き一時アクセス |
BUILD_SCOPED_FILE_URL(stage, path) |
トークンで保護されたスコープ付きURLを生成。Snowflake内部参照向け | Scoped = 範囲限定 |
BUILD_STAGE_FILE_URL(stage, path) |
ステージファイルへの恒久的なURLを生成 | 期限なし・長期利用向け |
GET_RELATIVE_PATH(stage, abs_path) |
絶対パスからステージ内の相対パスを取得 | ファイルの場所を特定する用途 |
GET_ABSOLUTE_PATH(stage, rel_path) |
相対パスから絶対パスを取得 | 上の逆 |
GET_STAGE_LOCATION(stage) |
ステージのクラウドストレージURLを返す | ステージそのものの場所を知りたい時 |
ALTER STAGE my_stage REFRESH |
ディレクトリテーブルを最新状態に更新 | S3等にファイルを追加した後に必要 |
⏱ Time Travel系
| コマンド/関数 | 何をするか | 覚え方 |
|---|---|---|
AT (OFFSET => -60*5) |
5分前の状態を参照 | マイナス秒数で過去指定 |
AT (TIMESTAMP => '2024-01-01 12:00:00'::timestamp) |
指定日時の状態を参照 | タイムスタンプで直接指定 |
BEFORE (STATEMENT => 'query_id') |
指定クエリ実行直前の状態を参照 | 誤操作を戻す時に便利 |
UNDROP TABLE my_table |
Time Travel範囲内で削除テーブルを復元 | DROP後のリカバリ |
💡 試験での出題パターン（ステージ・ファイル系）
- 「外部ユーザーに一時的にファイルをダウンロードさせたい」→
GET_PRESIGNED_URL - 「S3にファイルを追加したがディレクトリテーブルに反映されない」→
ALTER STAGE ... REFRESH - 「誤ってテーブルをDROPしてしまった」→
UNDROP TABLE - 「特定のクエリ実行前の状態に戻したい」→
BEFORE (STATEMENT => 'query_id')
📎 補足：テーブルタイプ比較表（頻出）
| Standard | Transient | Temporary | |
|---|---|---|---|
| Time Travel最大期間 | 最大90日（Enterprise以上） / 1日（Standard） | 最大1日 | 最大1日 |
| Fail-safe | あり（7日） | なし | なし |
| セッション終了後 | 残る | 残る | 消える（自動削除） |
| 主な用途 | 通常の永続テーブル | 一時的な大量データ処理・ストレージコスト削減 | セッション内の作業用・他ユーザーから不可視 |
⚠️ Fail-safeについての重要補足
- Fail-safeはユーザーが直接操作できない（Snowflakeサポートのみが復元可能）
- Transient・Temporaryテーブルはコスト削減のためFail-safeがない分、ストレージ料金が安い
- Fail-safeの7日間はTime Travel期間終了後にカウント開始
📎 補足：マルチクラスターウェアハウスの2つのモード
| モード | 条件 | 動作 |
|---|---|---|
| 最大化モード | MIN = MAX（例：MIN=3, MAX=3） | 常に指定数のクラスターが稼働。常時高負荷な環境向け |
| 自動スケールモード | MIN < MAX（例：MIN=1, MAX=3） | 負荷に応じて自動で増減。通常はこちらを使う |
- SCALING_POLICY = STANDARD：キューが発生したら即スケールアウト（待機時間最小化優先）
- SCALING_POLICY = ECONOMY：節約優先。スケールアウトの判断が保守的