2026年のSnowflake: アーキテクチャ、SQL、データエンジニア面接の質問

Snowflakeの面接では、SQLの構文だけでなく、データエンジニアがプラットフォームの分離型アーキテクチャを理解しているかどうかが問われます。Snowflakeが確立したマルチクラスター共有データ設計は、ストレージ、コンピュート、サービスを3つの独立したレイヤーに分離しており、この分離こそが、チームがプラットフォーム上で下すほぼすべてのパフォーマンスとコストに関する判断を説明します。本記事では、Snowflakeのアーキテクチャ、2026年にクエリを高速かつ低コストに保つSQLパターン、そして実務経験を明らかにする面接の質問を扱います。

Snowflakeアーキテクチャ: ストレージ、コンピュート、クラウドサービス

Snowflakeアーキテクチャを特徴づけるのは、ストレージとコンピュートが物理的に分離している点です。データはAmazon S3やAzure Blob Storageといったクラウドオブジェクトストアを基盤とする集中型ストレージレイヤーに一度だけ格納されます。任意の数のコンピュートクラスターが、データをコピーすることなく同じデータを同時に読み取れます。この手法は、設計を発表した2016年のSIGMOD論文で当初のエンジニアリングチームがマルチクラスター共有データと名付けたものです。

ストレージレイヤーは、micro-partitionsと呼ばれる不変で圧縮された列指向ファイルにデータを保持します。ユーザーがこれらのファイルを直接管理することはありません。Snowflakeがそれらを書き込み、メタデータを追跡し、回収します。コンピュートレイヤーは仮想ウェアハウスで構成され、各ウェアハウスはSnowflakeがオンデマンドでプロビジョニングするサーバーのクラスターです。クラウドサービスレイヤーは両者の上位に位置し、すべてを調整します。SQLを解析し、クエリを計画し、アクセス制御を適用し、トランザクションを管理し、Time Travelやzero-copy cloningといった機能を可能にするメタデータを保存します。

これらのレイヤーは独立しているため、データを1バイトも触れることなくウェアハウスのリサイズや削除ができ、コンピュートをまったくプロビジョニングせずにストレージをペタバイト規模まで拡張できます。

-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.

このスクリプトの実行後にanalytics_whを削除すると、すべてのコンピュート課金が停止する一方で、新しいウェアハウスが作成された瞬間にすべてのテーブルは引き続きクエリ可能なままです。この分離こそが、面接で明確に説明すべき最も重要な考え方です。

仮想ウェアハウスがSnowflakeのコンピュートをスケールさせる仕組み

仮想ウェアハウスは、TシャツサイズのようにX-Small、Small、Medium、Largeと段階的にサイズ指定される、名前付きのコンピュートクラスターです。1段階上げるごとにサーバー数と1時間あたりのクレジット消費量が両方とも倍増します。そのため、LargeウェアハウスはSmallの4倍のコストがかかりますが、スキャン中心のクエリをおよそ4倍速く完了させます。この価格と性能の線形なトレードオフは、最も安価な選択肢が、より大きなウェアハウスを短時間実行することであるケースが多いことを意味します。

スケーリングには2つの次元があり、両者を混同するのはよくある面接の落とし穴です。垂直スケーリングは、単一のウェアハウスをリサイズして1つのクエリを高速化します。水平スケーリングは、マルチクラスターウェアハウスにクラスターを追加して、より多くの同時クエリに対応します。午前9時に200人のアナリストからアクセスされるダッシュボードには、より大きなウェアハウスではなく、より多くのクラスターが必要です。1兆行の夜間バックフィルには、より多くのクラスターではなく、より大きなウェアハウスが必要です。

-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';

これを経済的に成り立たせるのがAUTO_SUSPENDとAUTO_RESUMEです。停止中のウェアハウスにはコストがかからず、Snowflakeは最低60秒で秒単位の課金を行います。対話的なウェアハウスに短い自動停止を設定すれば、アイドル状態のクラスターがクエリの合間にクレジットを浪費するのを防げます。

高速なSQLのためのmicro-partitionsとclustering key

Snowflakeはすべてのテーブルをmicro-partitionsの集合として格納します。各micro-partitionは50〜500 MBの非圧縮データを列指向形式で保持します。Snowflakeはmicro-partitionごとに、各カラムの最小値と最大値をメタデータに記録します。クエリがあるカラムでフィルタリングすると、オプティマイザーはそのメタデータを読み取り、値の範囲が一致し得ないパーティションをすべてスキップします。これがpartition pruningと呼ばれるプロセスです。これこそが、Snowflakeに手動のインデックスが不要な理由です。pruningはすべてのカラムで自動的に行われます。

pruningは、フィルタカラムがデータの読み込み順序と相関している場合に最も効果的に機能します。日付順に取り込まれたテーブルは、日付範囲のクエリを効率的にpruneします。大きなテーブルが読み込み順序とは無関係なカラムで頻繁にフィルタリングされる場合、clustering keyが関連する行をmicro-partitions間で近接配置し、テーブルが大きくなってもpruningが効果的に保たれます。

-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');

clustering keyは無料ではありません。Snowflakeはそれらを維持するために自動のバックグラウンドサービスを実行し、そのサービスはクレジットを消費します。経験則としては、クエリプロファイルがpruningの不良を示すテラバイト規模のテーブルにのみclustering keyを追加します。小さなテーブルはそれ自体で十分にpruneでき、早すぎるclustering keyはコストを浪費します。このトレードオフを説明できるかどうかが、しばしばジュニアとシニアの回答を分けます。

データのロードと変換: Snowpipe、Streams、Dynamic Tables

3つの取り込みパターンがほとんどのワークロードをカバーします。バルクのCOPY INTOは、ステージされたファイルを単一のコマンドでロードし、スケジュールされたバッチジョブに適しています。Snowpipeは、クラウドストレージのイベントを契機に、サーバーレスのマイクロバッチでファイルを継続的にロードし、ほぼリアルタイムの到着を実現します。Snowpipe Streamingは、サブ秒の鮮度が重要な場合に、低レイテンシのAPIを通じて個々の行をプッシュします。レイテンシとファイルサイズの要件に基づいてこれらを選択する問題は面接で頻出であり、正しい回答は「下流のコンシューマーが実際に必要とする鮮度による」から始まります。

ウェアハウス内での変換は、歴史的にStreamsとTasksに依存してきました。Streamはテーブル上の行レベルの変更(change data capture)をキャプチャし、Taskはそれらの変更を消費して下流にマージするSQLをスケジュールに従って実行します。

-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);

2026年には、Dynamic Tablesが増分変換を表現する好ましい方法になっています。StreamをTaskに接続してマージを手作業で書く代わりに、Dynamic Tableはターゲットラグとクエリを宣言し、Snowflakeが増分リフレッシュを自動的に導き出します。これにより、結果を新鮮に保ちながら、オーケストレーションの定型コードの大半を排除できます。

-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;

オープンフォーマット上で構築するチームのために、SnowflakeのIcebergテーブルは、顧客自身のクラウドバケットに格納されたApache Icebergデータをウェアハウスから読み書きできるようにします。これにより、Snowflakeのクエリエンジンとガバナンスを保ちつつ、ロックインを回避できます。多くのチームは、バージョン管理されテストされた変換のためにSnowflakeをdbtと組み合わせます。このワークフローはdbtによるデータ変換とテストのガイドで扱っています。

データエンジニアのためのSnowflake面接の質問

以下の質問は、Snowflakeのデータエンジニアリング面接で繰り返し登場します。優れた回答は、構文を暗唱するのではなく、機能をストレージとコンピュートの分離に結びつけます。

ストレージとコンピュートを分離することはどんな問題を解決しますか? それは競合を排除します。ダッシュボードを実行するアナリスト、特徴量を訓練するデータサイエンスチーム、データをロードするELTジョブは、それぞれが同じテーブルに対して自身のウェアハウス上で実行でき、リソースを奪い合ったりデータをコピーしたりする必要がありません。コンピュートは重いジョブのためにスケールアップし、アイドル時には停止する一方、ストレージコストは接続されているコンピュートの量に関係なく一定に保たれます。

Time Travelとzero-copy cloningはどのように機能しますか? どちらもmicro-partitionsの不変性に依存します。Snowflakeはmicro-partitionを決して上書きしないため、古いバージョンは保持期間(Enterpriseでは最大90日)の間ディスク上に残ります。Time Travelは、それらの古いパーティションを指し示すことで、過去のタイムスタンプ時点のテーブルをクエリします。そしてCLONEは、一方が変更されるまでストレージを複製することなく、同じパーティションを参照する新しいテーブルを作成します。ペタバイト規模のテーブルのクローンを即座かつほぼ無料にするのは、このcopy-on-writeです。

clustering keyはいつ定義すべきですか? 読み込み順序とは無関係なカラムで頻繁にフィルタリングまたは結合される大きなテーブル(おおよそ1テラバイト以上)に限り、かつクエリプロファイルがpruningの不良を確認した後にのみ定義します。clusteringは継続的なメンテナンスのクレジットコストを伴うため、デフォルトではなく意図的な最適化です。

Snowflakeのコストはどのように制御しますか? ウェアハウスのサイジング、積極的な自動停止、実際の同時実行性に合わせたクラスター数、そしてクレジット支出に上限を設けるresource monitorを通じて制御します。resource monitorは、割り当てに達すると自動的にウェアハウスへ通知したり停止したりできます。

-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;

StreamsとTasksか、それともDynamic Tablesか? Dynamic Tablesは、ターゲットの鮮度が要件であり、Snowflakeがリフレッシュを管理できる宣言的なパイプラインに適しています。StreamsとTasksは、変換に命令的な制御、副作用、または単一のクエリでは表現できないロジックが必要な場合に、依然として適切なツールです。一方をデフォルトにするのではなく、それぞれがどこに適合するかを知っていることが、実務経験を示します。

Snowflake上のELTは従来のETLとどう異なりますか? Snowflakeの安価なストレージと伸縮自在なコンピュートは、生データをまずロードしてその場で変換することを実用的にします。このパターンはETL対ELTアーキテクチャのガイドで探究しています。全体の流れに備える候補者は、より広範なデータエンジニアリングトラックと並行して、ETLとELTのパターンモジュールで反復練習できます。

まとめ

• Snowflakeアーキテクチャは、ストレージ、コンピュート、クラウドサービスを3つの独立したレイヤーに分離しており、ほぼすべての設計上の回答はその分離に行き着きます
• 仮想ウェアハウスは、より重い単一クエリのために垂直に、より高い同時実行性のために水平にスケールします。自動停止と秒単位の課金が、アイドルなコンピュートを無料に保ちます
• micro-partitionsはカラムごとの最小値/最大値メタデータを持ち、自動的なpartition pruningを提供します。これがSnowflakeに手動のインデックスが不要な理由です
• clustering keyは、pruningの不良が実証されたテラバイト規模のテーブルにのみ追加します。メンテナンスがクレジットを消費するためです
• 取り込みパターンは必要な鮮度に合わせます。バッチにはバルクCOPY、継続的なマイクロバッチにはSnowpipe、サブ秒のレイテンシにはSnowpipe Streamingを使います
• 2026年には宣言的な増分変換にDynamic Tablesを優先し、StreamsとTasksは命令的なロジックのために取っておきます
• Time Travelとzero-copy cloningはどちらもmicro-partitionの不変性とcopy-on-writeを活用し、特定時点のクエリと即座のクローンを安価にします
• コストは、適切にサイジングされたウェアハウス、積極的な自動停止、同時実行性に合わせたクラスター、そしてresource monitorで制御します