S3からのデータロード｜DatabricksとSnowflakeで全然違う「ロードの裏側」

はじめに

S3にあるデータをDatabricksやSnowflakeで分析したい場面は多いですよね。

どちらのプラットフォームでも「ロード処理」は必要ですが、データがどこに置かれるかが根本的に異なります。この違いを理解しておくと、アーキテクチャ選定やコスト管理で役立ちます。

この記事では、S3からのデータロードにおけるDatabricksとSnowflakeの仕組みを図解で比較します。

この記事は2026年1月時点の情報です。最新の仕様は各公式ドキュメントをご確認ください。

Snowflakeのデータロード

Snowflakeでは、S3のデータをSnowflake内部ストレージにコピーします。

S3 (JSON)
    │
    │ Snowpipe（コピー）
    ▼
Snowflake内部ストレージ（データ実体がここに移動）

処理の流れ

1. S3にデータが配置される
2. Snowpipe（またはCOPY INTO）がデータを検知
3. Snowflakeの内部ストレージにデータがコピーされる
4. 以降のクエリはSnowflake内部のデータに対して実行

snowpipe_example.sql

-- ステージの作成
CREATE STAGE my_s3_stage
  URL = 's3://my-bucket/data/'
  CREDENTIALS = (AWS_KEY_ID = '...' AWS_SECRET_KEY = '...');

-- テーブルへのロード
COPY INTO my_table
FROM @my_s3_stage
FILE_FORMAT = (TYPE = 'JSON');

ポイントは、データの実体がSnowflake側に移動することです。S3は入り口として使われますが、最終的なデータはSnowflakeが管理します。

Databricksのデータロード

Databricksでは、S3のデータはS3に残ったまま、フォーマットだけがDelta Lakeに変換されます。

S3 (JSON)
    │
    │ Auto Loader（変換）
    ▼
S3 (Delta Lake形式)（データ実体はS3のまま）
    │
    │ 参照
    ▼
Databricksからクエリ

処理の流れ

1. S3にデータが配置される
2. Auto Loader（またはSpark処理）がデータを検知
3. Delta Lake形式に変換してS3に書き込み
4. DatabricksはS3上のDelta Lakeに対してクエリを実行

autoloader_example.py

# Auto Loaderでの増分読み込み
df = (spark.readStream
      .format("cloudFiles")
      .option("cloudFiles.format", "json")
      .load("s3://my-bucket/raw/"))

# Delta Lakeとして保存（同じくS3上）
(df.writeStream
   .format("delta")
   .option("checkpointLocation", "s3://my-bucket/checkpoints/")
   .start("s3://my-bucket/bronze/"))

ポイントは、データの実体がS3に残り続けることです。Databricksはあくまでコンピュート層として動作し、ストレージはAWSに委ねます。

Delta Lakeの実体

Delta LakeはS3上のファイル形式です。特別なサービスではなく、Parquet + メタデータ管理の仕組みです。

s3://bucket/bronze/history/
├── _delta_log/           ← メタデータ（トランザクションログ）
│   ├── 00000000000000000000.json
│   └── 00000000000000000001.json
├── part-00000-xxx.parquet ← データ本体
├── part-00001-xxx.parquet
└── part-00002-xxx.parquet

ディレクトリ/ファイル	役割
_delta_log/	トランザクションログ。ACIDを実現
*.parquet	実データ。列指向で圧縮効率が高い

Delta Lakeはオープンフォーマットなので、Databricks以外のツール（Spark、Trino、Athenaなど）からも読み取れます。

Snowflake vs Databricks 比較表

項目	Snowflake	Databricks
ロード処理	必要	必要
データの場所	Snowflake内部	S3（そのまま）
ストレージ課金	Snowflakeに払う	AWSに払う
データ形式	Snowflake独自	Delta Lake（オープン）
他ツールからのアクセス	制限あり	可能

メリット・デメリット

Snowflake（内部ストレージ）

メリット	デメリット
管理がシンプル	ベンダーロックイン
最適化が自動	データ移行が面倒
パフォーマンスが安定	ストレージコストがSnowflake価格

Snowflakeはフルマネージドなので、運用負荷を下げたい場合に適しています。

Databricks（S3 + Delta Lake）

メリット	デメリット
データがオープン形式で残る	S3の管理が必要
他ツールからもアクセス可能	ストレージコストを別途管理
ベンダーロックインを回避	設定の自由度が高い分、複雑になりがち

Databricksは、データのポータビリティを重視する場合やマルチツール環境に適しています。

補足: Snowflakeの外部テーブル

SnowflakeでもS3を直接参照することは可能です。ただし、パフォーマンスは内部テーブルより劣ります。

external_table_example.sql

-- 外部テーブル（S3を直接参照）
CREATE EXTERNAL TABLE events_external
  WITH LOCATION = @my_s3_stage
  FILE_FORMAT = (TYPE = 'PARQUET');

-- 通常テーブル（Snowflake内部）
CREATE TABLE events_internal AS
SELECT * FROM events_external;

外部テーブルは参照のたびにS3にアクセスするため、大量データの分析には向きません。本番運用では内部にロードするのが一般的です。

使い分けの目安

ユースケース	推奨
頻繁にクエリする分析テーブル	内部テーブル
一時的な参照・検証	外部テーブル
アーカイブデータへの稀なアクセス	外部テーブル

まとめ

S3からのデータロードは、DatabricksとSnowflakeでデータの配置場所が根本的に異なります。

観点	Snowflake	Databricks
データの場所	Snowflake内部	S3のまま
運用の楽さ	◎	△
データのポータビリティ	△	◎
コスト管理	Snowflake一本	AWS + Databricks

選択の指針:

• シンプルな運用・フルマネージド志向 → Snowflake
• オープン性・マルチツール連携 → Databricks

どちらが「正解」ということはなく、組織の要件やエコシステムに応じて選択しましょう。

参考リンク