データ基盤チームはDatabricksでDelta Lakeのテーブルを作ってきました。ところが今期、マーケティング部がSnowflakeを契約し、「同じ顧客データをSnowflakeからも見たい」と言ってきます。夜間にSnowflakeへコピーする案を出すと、情シスからは「同じデータを2か所に持つと、どちらが正しいか分からなくなる」と止められます。経営企画は「Icebergにすればどこからでも読めると聞いた。なぜそうしないのか」と聞いてきます。あなたは、どのエンジンが書き、どのエンジンが読めるのかを、まだ一枚の表にできていません。答えに詰まります。

テーブルフォーマット選びは、機能の比較表を眺めても決まりません。決め手になるのは「どのエンジンがテーブルに書き込み、どのエンジンが読むだけか」です。ここが決まると、選択肢はほぼ1つに絞れます。

状況別の早見表：書き手と読み手の組み合わせで当たりをつける

あなたの状況最初に検討するもの選んだあとで困りやすいこと
Databricksが主で、他のエンジンからは読むだけDelta Lake（必要なテーブルだけUniFormでIceberg互換にする）Iceberg側から書き込むとデータを壊すおそれがあり、書き手はDatabricksに限られる
SnowflakeやBigQueryも含め、複数のエンジンから読み書きしたいIceberg（カタログを1つに決める）カタログの選び方を誤ると、一部のエンジンから書けない
Athenaとオープンソースのエンジン（Spark・Trino）が中心のAWS環境Iceberg（AWS Glueのカタログ）AthenaはGlue以外のカタログのIcebergテーブルを扱えない
業務DBの変更を、数分おきにレイクへ反映し続けたいHudi（Merge-on-Read）か、Iceberg・DeltaのMERGEHudiは読めるエンジンが限られ、Athenaからは読み取りのみ
1つのDWHの中で完結していて、他から読む予定がないテーブルフォーマット自体を急いで入れない運用の手間だけが増える

右端の列は、どれも「書き手を1つに決めないと起きること」です。読むエンジンが増えるのは構いませんが、書くエンジンを増やすと整合性の問題が一気に増えます。

テーブルフォーマットは、ファイルの集まりを「テーブル」に変える

S3やGCSに置いたParquetファイルは、安く大量に置けます。しかし、ファイルが何百個あっても、それはファイルの集まりで、テーブルではありません。書き込みの途中で読むと中途半端なデータが見え、行を1件直すにもファイルごと書き直すことになります。

ファイルの一覧やスキーマ、変更の履歴をメタデータとして別に持ち、ファイルの集まりをテーブルとして扱えるようにする仕組みを、テーブルフォーマットと呼びます。

できること素のParquetファイルテーブルフォーマット
書き込み途中のデータを見せないできないコミット単位で切り替わる
行単位の更新・削除ファイルを丸ごと書き直すMERGEやUPDATEで書ける
過去の時点を読む自分でバックアップを取るスナップショットを指定して読める
列の追加・型の変更読み手との調整が要るメタデータで管理する

3つのフォーマットの出自は次のとおりです。

フォーマット出自いまの運営
Apache IcebergNetflixで開発され、Apacheソフトウェア財団に寄贈されたApacheソフトウェア財団
Delta LakeDatabricksが開発し、2019年に公開したLinux Foundation（2019年に移管）
Apache HudiUberで2016年に開発が始まり、2017年に公開されたApacheソフトウェア財団（2020年にトップレベルプロジェクト）

2024年6月には、DatabricksがIcebergの開発者たちが創業したTabularの買収を発表しました。DeltaとIcebergのどちらか一方を選ぶというより、Deltaで書いてIcebergとしても読ませる構成が現実的になっています。

主要エンジンの対応は、「読める」と「書ける」を分けて見る

カタログや契約の説明では「Iceberg対応」「Delta対応」と一言で書かれがちです。実際には、読み取りだけの対応と書き込みまでの対応がはっきり分かれます。以下は2026-10-17時点で各社の公式ドキュメントを確認した内容です。

エンジンIcebergDelta LakeHudi
SnowflakeSnowflakeをカタログにすれば読み書きできる。外部カタログはIceberg RESTカタログなら書き込み可、それ以外は機能が限られる外部カタログ連携でDeltaのファイルを読む（Delta-based Iceberg tables）公式ドキュメントで対応を確認できず
BigQueryBigQueryが管理するIcebergテーブル（Apache Iceberg managed tables）で読み書きできる。外部テーブルもあるBigLake external tables for Delta Lakeで読み取りHudiの同期ツールが作るマニフェスト経由で読み取り（CoWなど条件あり）
Athena読み取り・書き込み・タイムトラベルに対応（AWS Glueのカタログのみ）読み取りのみ。タイムトラベルは非対応読み取りのみ。書き込みは非対応
DatabricksUniFormでDeltaのテーブルをIcebergとして読ませるネイティブ（このガイドでは扱わない）

Snowflakeの場合、外部カタログのテーブルは「Snowflakeからの機能は限定的」と公式に書かれています。Snowflakeから書き込みたいテーブルは、Snowflakeをカタログにするか、Iceberg RESTカタログを使います。BigQueryの管理するIcebergテーブルも、名前の変更・クローン・行レベルのセキュリティが使えないなど、通常のテーブルとの違いがあります。導入前に、自社が使う機能が制限に入っていないかを公式の一覧で確かめます。

Delta Lakeを選ぶなら、UniFormの「読み取り専用」を前提にする

冒頭の会社のようにDatabricksで作り込んでいるなら、Delta Lakeを続けるのが自然です。移す理由がありません。他のエンジンから読ませたいテーブルにだけ、UniFormを有効にします。UniFormは、Deltaで書くたびにIcebergのメタデータも生成する機能です。

CREATE TABLE sales.orders (
  order_id BIGINT,
  customer_id BIGINT,
  ordered_at TIMESTAMP,
  amount DECIMAL(12, 2)
)
USING DELTA
TBLPROPERTIES (
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg'
);

Delta Lakeの公式ドキュメントには、次の制約が書かれています。UniFormはIcebergやHudiから見ると読み取り専用で、外から書き込むとDeltaのテーブルのデータが失われるおそれがあります。また、削除ベクトル（deletion vectors）を有効にしたテーブルでは動きません。冒頭の例でいえば、Snowflakeは読むだけ、書くのはDatabricksだけ、と運用ルールに書いておきます。

DatabricksとSnowflakeの使い分けそのものはDatabricksとはとクラウドDWH入門にまとめています。

Icebergを選ぶなら、先にカタログを1つに決める

Icebergのテーブルは、カタログが「いまの最新のメタデータはどれか」を指し示すことで成り立ちます。複数のエンジンが同じテーブルに書くなら、全員が同じカタログを見ていなければなりません。AWSならGlue、Snowflakeが中心ならSnowflakeのカタログかSnowflake Open Catalog、と先に決めます。Athenaは、AWS Glueのカタログに登録したIcebergテーブルだけを扱えます。

Icebergの便利な点は、パーティションを利用者に意識させないことです。テーブルを作るときに「注文日時を日単位で分ける」と宣言しておけば、利用者は普通に日時で絞り込むだけで、不要なファイルを読まずに済みます。

CREATE TABLE sales.orders (
  order_id BIGINT,
  customer_id BIGINT,
  ordered_at TIMESTAMP,
  amount DECIMAL(12, 2)
)
USING iceberg
PARTITIONED BY (days(ordered_at));

-- 利用者はパーティションを気にせず、日時で絞り込むだけでよい
SELECT SUM(amount) FROM sales.orders WHERE ordered_at >= TIMESTAMP '2026-10-01 00:00:00';

更新が多いならHudi、ただし読む側を先に確かめる

Hudiの特徴は、2つの保存方式を選べることです。Copy-on-Writeは、更新のたびに該当するファイルを書き直します。読むのは速いが、書くのは重くなります。Merge-on-Readは、変更を差分のログに書いておき、読むときや定期的な圧縮で本体と合わせます。書くのは軽いが、読むときに合わせる手間がかかります。AWSの公式ドキュメントも、更新が多く読むのが少ない用途にはMerge-on-Read、読むのが多く変更が少ない用途にはCopy-on-Writeが向くと説明しています。

業務DBの変更を取り込む道具として、HudiにはHoodieStreamer（旧称DeltaStreamer）があります。KafkaやDebeziumの変更イベントを読み、Hudiのテーブルに反映し続けます。

spark-submit \
  --class org.apache.hudi.utilities.streamer.HoodieStreamer \
  hudi-utilities-bundle.jar \
  --table-type MERGE_ON_READ \
  --source-class org.apache.hudi.utilities.sources.debezium.PostgresDebeziumSource \
  --target-base-path s3://example-bucket/lake/orders \
  --target-table orders \
  --op UPSERT
# スキーマレジストリやKafkaの接続設定は省略

注意したいのは読む側です。上の表のとおり、Athenaは読み取りのみで、増分クエリにも対応していません。BigQueryで読む場合も条件があります。変更を数分おきに反映する要件が本当にあるかを確かめ、日次で足りるならIcebergやDeltaのMERGEで済ませるほうが、読めるエンジンの選択肢は広く残ります。業務DBから変更を取り出す仕組みはCDC実装ガイドで扱っています。

どれを選んでも、掃除の仕事は必ず残る

テーブルフォーマットは、過去の時点を読めるように古いファイルを残します。放っておくとストレージ代が積み上がり、小さなファイルが増えて読むのも遅くなります。既定値は次のとおりです。

フォーマット古いデータを消す操作既定の保持期間
Icebergexpire_snapshots（古いスナップショットを消す）指定しなければ5日より前を削除。直近1つは必ず残す
Delta LakeVACUUM（参照されなくなったファイルを消す）ファイルは7日、変更ログは30日
Hudicleaner（古いファイルを消す）と、Merge-on-Readの圧縮設定で決める

Icebergの場合、Sparkからは次のように実行します。小さなファイルをまとめる rewrite_data_files も一緒に定期実行します。

CALL catalog.system.expire_snapshots('sales.orders', TIMESTAMP '2026-10-10 00:00:00', 10);
CALL catalog.system.rewrite_data_files('sales.orders');

保持期間は、そのまま「何日前まで戻れるか」になります。ここは業務の話です。DeltaでVACUUMを7日で回していれば、7日より前の状態には戻れません。監査や事故対応で何日前まで遡る必要があるかを業務側と決め、その日数から逆算して設定します。日次の掃除はオーケストレーターに載せておくと忘れません。

決め方の手順：既存の資産から順に確かめる

冒頭の会社なら、次の順に確かめます。

順番確かめることこの会社の答え
1いま一番データを書いているエンジンはどれかDatabricks
2他に読みたいエンジンはどれか。読むだけか、書きもするかSnowflakeで読むだけ
3変更を数分おきに反映する要件があるか無い（日次で足りる）
4何日前まで遡れる必要があるか30日（月次の締め直しのため）

この答えから、Delta Lakeを続け、マーケティング部が使う顧客テーブルだけUniFormを有効にし、SnowflakeからはIcebergとして読む、という構成が決まります。VACUUMの保持期間は30日に伸ばします。新しく作るテーブルを層ごとにどう分けるかは、メダリオンアーキテクチャの考え方と組み合わせます。

よくある質問（FAQ）

ParquetとIcebergは何が違うのですか?

Parquetはデータを列ごとに詰めて保存するファイルの形式です。Iceberg・Delta Lake・Hudiは、複数のParquetファイルをまとめて1つのテーブルとして扱うためのメタデータの仕組みです。どのファイルが最新のテーブルに含まれるか、どんな変更があったかを記録するので、書き込みの途中を読み手に見せず、過去の時点のテーブルも読めます。

Databricksを使っていますが、Icebergに移す必要はありますか?

他のエンジンから読むだけなら、移す必要はありません。Delta Lakeのまま、読ませたいテーブルだけUniFormを有効にすれば、Icebergとして読めます。ただし、Delta Lakeの公式ドキュメントではUniFormはIceberg側から見て読み取り専用で、削除ベクトルを有効にしたテーブルでは動かないとされています。他のエンジンからも書きたくなった時点で、Icebergへの移行を検討します。

複数のエンジンから同じIcebergテーブルに書き込めますか?

同じカタログを見ていれば可能です。ただし、エンジンごとに使えるカタログが違います。たとえばAthenaはAWS Glueのカタログのみ、Snowflakeは外部カタログのうちIceberg RESTカタログのときだけ書き込めます。書き手が増えるほど事故も増えるので、テーブルごとに書き手を1つに決めるのが安全です。

タイムトラベルで何日前まで戻れますか?

掃除の設定で決まります。Delta LakeのVACUUMは既定でファイルを7日残し、変更ログは30日残します。Icebergのexpire_snapshotsは、指定しなければ5日より前のスナップショットを消します。監査や締め直しで必要な日数を先に決め、それに合わせて保持期間を伸ばします。伸ばした分だけストレージ代は増えます。

テーブルフォーマットはあとから変えられますか?

変えられますが、データの書き直しが必要になることが多く、無料ではありません。全テーブルを一度に移すと停止時間が長くなるので、新しく作るテーブルから新しいフォーマットにし、既存のテーブルは使われ方を見ながら順に移します。Deltaのまま読ませたいだけなら、UniFormで書き直さずに済むこともあります。

出典

「どのエンジンが書き、どこから読むか」の一枚表づくりから、自社のレイクハウス構成の整理をご一緒します。初回相談（30分・無料）で一緒に整理できます。