Snowflake入門 - AWSメインでやってきた自分から見たZero to Snowflake
はじめに
Snowflakeの公式入門チュートリアル「Zero to Snowflake」を一通りやってみました。
これまではAWSでの開発・運用改善などをメインにやってきて、データエンジニアリングは未経験です。チュートリアルの手順をなぞる記事ではなく、そんな自分が実際に触ってみて「おっ」と思ったポイントを中心に書きます。
そもそも Snowflake って何？
チュートリアルに入る前に、Snowflakeが何をするものなのかを整理しておきます。
Snowflakeを一言でいうと、クラウド上で動くデータウェアハウス（DWH）サービスです。大量のデータを格納して、SQLで分析できる基盤を提供してくれます。
AWSでいうRedshiftに近いポジションですが、触ってみて一番違うと感じたのは**「ストレージとコンピュートが完全に分離されている」**という点です。
- ストレージ: データの保管場所。使った分だけ課金
- コンピュート（ウェアハウス）: クエリを実行する計算リソース。起動している時間だけ課金
この2つが独立しているので、「データは常に置いておくけど、クエリを投げるときだけコンピュートを起動する」という使い方ができます。Redshiftのようにクラスタを常時起動しておく必要がなく、使わない時間は完全にゼロ円にできるのが大きな違いです。
また、データ分析以外にもデータシェアリングや**Cortex（AI機能）**など、データ活用のための機能が一通り揃っているのも特徴です。
そもそもウェアハウスって何？
Snowflakeを触っていて最初に戸惑うのが、この「ウェアハウス」という言葉です。一般的な「データウェアハウス（DWH）」とは別物で、Snowflake用語では**クエリを実行するためのコンピュートリソース（計算リソース）**を指します。
AWSでいうEC2のような位置付けですが、以下の点で全く違います。
- 自動起動 / 自動停止: クエリが来たら起動、一定時間アイドルで停止
- サイズ変更がSQL一発:
ALTER WAREHOUSE my_wh SET WAREHOUSE_SIZE = 'LARGE';で完了 - 秒単位課金: 起動している秒数だけ課金される
CREATE WAREHOUSE my_wh
WITH WAREHOUSE_SIZE = 'X-SMALL' -- サイズ（XS〜6XLまで）
AUTO_SUSPEND = 60 -- 60秒アイドルで自動停止
AUTO_RESUME = TRUE -- クエリが来たら自動起動
INITIALLY_SUSPENDED = TRUE; -- 作成時は停止状態
EC2を「起動したら誰かが止めないと課金され続ける」感覚で運用していた身からすると、使わない時間は本当にゼロ円になるのは結構衝撃でした。
やったこと
Snowflakeの公式入門コンテンツ「Zero to Snowflake」のStep 1〜9を実施しました。業務の合間に1日1時間ずつ進めて、約1週間で完走しました。
- Step 1-3: 基本操作（ウェアハウス作成、データロード、クエリ実行）
- Step 4-6: 半構造化データ、キャッシュ、クローン
- Step 7: タイムトラベル
- Step 8-9: データシェアリング、マーケットプレイス
なお、このチュートリアルはSQL中心で進みますが、ウェアハウス作成・データロード・データシェアリングなどの操作はSnowsightのUIからでも実行できます。チュートリアルがSQLベースなのは、コピペで再現しやすく手順が伝わりやすいからだと思います。
全体を通して感じたのは、Snowflakeは「データを守る」「データを共有する」ということにすごく力を入れているということ。ただのDWHではなく、データを中心にした協業のプラットフォームという印象を受けました。
印象に残ったポイント
1. UNDROP —— 「消したら終わり」じゃない安心感
UNDROP / タイムトラベルって何？
Snowflakeにはタイムトラベルという機能があり、DROPしたテーブルや削除・更新前のデータを、一定期間内であればSQLコマンド一発で元に戻せる仕組みが最初から組み込まれています。デフォルトで有効で、特別な設定は不要です。
基幹システムの運用保守をやっていた身からすると、本番環境で何かを消すのは本当に怖いことです。
オンプレのOracleで運用していたときは、バックアップからの復元となると手順確認して、影響範囲を洗い出して、関係者に連絡して……という一連の流れが頭をよぎる。
Snowflakeのタイムトラベルは違いました。
まず、テーブルをDROPします。
DROP TABLE json_weather_data;
当然、この状態でクエリを投げるとエラーになります。
ここで UNDROP です。
UNDROP TABLE json_weather_data;
もう一度SELECTすると、データがそのまま戻っています。
これだけで戻る。テーブル単位で。デフォルトで有効。
オンプレ環境で夜間バッチの障害対応やマスタ調査をやっていた経験があるので、「DROP直後にワンコマンドで戻せる」ことのありがたみは結構リアルに感じました。
もちろんタイムトラベルの保持期間（デフォルト1日、最大90日）はあるので万能ではないですが、「うっかり」レベルのミスに対するセーフティネットが最初から組み込まれているのは、触っていて安心感がありました。
2. データシェアリング —— UIがわからなくてSQLに逃げたら、逆にスッキリした話
データシェアリングって何？
自分のアカウント内のデータを、コピーや転送なしで他のSnowflakeアカウントに「見せる」機能です。共有先は通常のテーブルと同じ感覚でSELECTでき、元データが更新されれば即座に反映されます。AWSでいうと、S3バケットポリシーでクロスアカウント参照を設定する感覚に近いですが、テーブル単位・カラム単位で権限制御できるのがSnowflakeならではのポイントです。
Step 8のデータシェアリングで、チュートリアルの指示通りUIから共有を作成しようとしたんですが、正直どこを押せばいいのかわからなかった。
「共有名を入れて『共有の作成』をクリック」と書いてあるのに、該当する画面がどうしても見つからない。
数分迷った末に、SQLで直接実行することにしました。
CREATE SHARE ZERO_TO_SNOWFLAKE_SHARED_DATA;
GRANT USAGE ON DATABASE CITIBIKE TO SHARE ZERO_TO_SNOWFLAKE_SHARED_DATA;
GRANT USAGE ON SCHEMA CITIBIKE.PUBLIC TO SHARE ZERO_TO_SNOWFLAKE_SHARED_DATA;
GRANT SELECT ON ALL TABLES IN SCHEMA CITIBIKE.PUBLIC TO SHARE ZERO_TO_SNOWFLAKE_SHARED_DATA;
SHOW SHARES;
結果に ZERO_TO_SNOWFLAKE_SHARED_DATA が OUTBOUND で表示されて、「あ、できてる」と。
この体験で気づいたのは、Snowflakeは「SQLですべてが完結する」設計になっているということ。昔、CloudFormationでインフラをコードとして管理していたという経験もあり、「宣言的に書いて、実行して、状態を確認する」という流れ自体は馴染みがあります。Snowflakeの場合、それがSQLという共通言語で統一されているのが良い。
GUIに迷ったらSQLに逃げる、というのは入門者にとって意外と有効な戦略かもしれません。
DE未経験だからこそ感じたこと
Step 1で CREATE WAREHOUSE を実行したとき、最初は「これEC2みたいなものか」と思いました。でも触っていくうちに、だいぶ違うなと。
使わなければ自動で停止するし、必要になれば自動で再開する。サイズ変更もSQLひとつ。前職でCloudFormationのテンプレートを整備して「EC2のリソース払い出しフロー」を標準化する、みたいな仕事をやっていたので、計算資源の管理がここまで抽象化されているのは正直うらやましかった。
AWSで構築・運用をやっていると「リソースの面倒を見る」ことが仕事の大部分を占めますが、Snowflakeはそこを徹底的に隠してくれている。インフラじゃなくてデータの作業に集中できるように作られてるんだな、というのが一番の感想です。
おわりに
データエンジニア未経験でも、Snowflakeの入門は問題なくできました。SQLの経験があれば取っ掛かりやすいし、AWSでの経験があるからこそ「ここが違う」と気づけたポイントもあった気がします。
次はCortex Searchのチュートリアルに進みます。Snowflakeの上でAI/検索がどう動くのか、引き続き未経験者目線でレポートする予定です。
