2026年版 Delta Lake vs Apache Iceberg：レイクハウスアーキテクチャと面接対策

Delta LakeとApache Icebergは、2026年現在のモダンデータレイクハウスを支える二大オープンテーブルフォーマットです。両者はクラウドオブジェクトストレージにACIDトランザクション、スキーマ進化、タイムトラベル機能を提供するという同一の課題を解決しますが、本番ワークロードにおいて重要な違いをもたらすアーキテクチャ上のアプローチが異なります。

Delta Lake vs Iceberg：コアアーキテクチャの違い

両フォーマットともデータをParquetファイルとしてオブジェクトストレージに保存しますが、メタデータレイヤーは大きく異なります。

Delta Lakeは、すべての変更を記録するJSONファイルを含むトランザクションログ（_delta_log/）を使用します。各コミットは新しいJSONファイルを作成し、定期的なチェックポイントでこれらをParquetに統合して読み取りを高速化します。Delta Lakeプロトコル仕様では、前方互換性のためにバージョン管理されたリーダー/ライター機能が定義されています。

Apache Icebergは、マニフェストリストを指すメタデータJSONファイルの階層を維持します。マニフェストリストはファイルレベルの統計情報を含むマニフェストを指します。この設計により、プランニング段階での述語プッシュダウンが可能になり、クエリエンジンはデータを読み取る前にファイル全体をスキップできます。

| 機能 | Delta Lake | Apache Iceberg | |------|------------|----------------| | トランザクションログ | JSON + Parquetチェックポイント | メタデータJSON + マニフェストファイル | | パーティション進化 | 再書き込みが必要 | 再書き込みなしでインプレース変更可能 | | エンジンサポート | Spark、Trino、Flink | Spark、Trino、Flink、Dremio、Athena | | タイムトラベル | バージョンベース | ブランチ/タグ付きスナップショットベース | | スキーマ進化 | カラム追加/名前変更 | カラム追加/名前変更/並べ替え/型拡張 |

隠しパーティション：Icebergの重要な優位性

従来のHiveスタイルパーティショニングは、クエリ内でパーティションカラムを露出させ（WHERE year=2026 AND month=7）、物理レイアウトとSQL構文を密結合させます。Icebergの隠しパーティションは、これらの関心を分離します。

# iceberg_partition_example.py
from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import StringType, TimestampType, LongType, NestedField
from pyiceberg.partitioning import PartitionSpec, PartitionField
from pyiceberg.transforms import MonthTransform

# スキーマ定義
schema = Schema(
    NestedField(1, "event_id", LongType(), required=True),
    NestedField(2, "event_time", TimestampType(), required=True),
    NestedField(3, "user_id", StringType(), required=True),
    NestedField(4, "event_type", StringType(), required=False),
)

# event_timeから月を抽出する隠しパーティション
partition_spec = PartitionSpec(
    PartitionField(
        source_id=2,  # event_timeフィールド
        field_id=1000,
        transform=MonthTransform(),
        name="event_month"
    )
)

catalog = load_catalog("glue", **{"type": "glue"})
catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=partition_spec
)

クエリはevent_timeで直接フィルタリングでき、エンジンはWHERE句でパーティションカラムを露出させることなく自動的にパーティションプルーニングを適用します。パーティション進化により、既存データを書き換えることなく月次から日次パーティショニングへの切り替えが可能です。

Delta Lake ACIDトランザクションと楽観的同時実行制御

Delta Lakeは楽観的同時実行制御を使用してシリアライザブル分離を実装します。ライターは競合を検出するためにコミット前にトランザクションログをチェックします。

# delta_concurrent_writes.py
from delta import DeltaTable
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", 
            "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

# 自動競合解決による並行MERGE操作
delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# 受信バッチと既存データをマージ
delta_table.alias("target").merge(
    source=incoming_df.alias("source"),
    condition="target.event_id = source.event_id"
).whenMatchedUpdateAll() \
 .whenNotMatchedInsertAll() \
 .execute()

# 競合検出はコミット中に自動的に実行される
# 失敗したトランザクションは更新されたスナップショットで再試行

Delta Lakeの競合解決ルールにより、同一パーティションへの競合する更新をシリアライズしながら、並行追記を成功させることができます。

タイムトラベルとデータバージョニングの比較

両フォーマットともタイムトラベルをサポートしていますが、セマンティクスが異なります。

-- Delta Lake: バージョン番号によるクエリ
SELECT * FROM events VERSION AS OF 42;

-- Delta Lake: タイムスタンプによるクエリ
SELECT * FROM events TIMESTAMP AS OF '2026-07-15 10:00:00';

-- Iceberg: スナップショットIDによるクエリ
SELECT * FROM analytics.events FOR SYSTEM_VERSION AS OF 8823749234;

-- Iceberg: タイムスタンプによるクエリ
SELECT * FROM analytics.events FOR SYSTEM_TIME AS OF TIMESTAMP '2026-07-15 10:00:00';

Iceberg 1.5以降ではブランチングとタグ付けが追加されており、分離された実験用の名前付きブランチを作成し、マージまたは破棄することができます。Delta Lakeはシャロークローンを通じて同様のワークフローを実現します。

-- Iceberg: テスト用ブランチの作成
ALTER TABLE analytics.events CREATE BRANCH experiment;

-- メインに影響を与えずにブランチに書き込み
INSERT INTO analytics.events.branch_experiment 
SELECT * FROM staging.events WHERE event_type = 'test';

-- ブランチをメインにマージ
CALL system.fast_forward('analytics.events', 'main', 'experiment');

クエリエンジン互換性マトリクス

エンジン互換性は多くの組織においてフォーマット選択の決め手となります。

| エンジン | Delta Lakeサポート | Icebergサポート | |----------|-------------------|------------------| | Apache Spark | ネイティブ（Databricks、OSS） | ネイティブ | | Trino/Presto | コネクタ | ネイティブ | | Apache Flink | コネクタ | ネイティブ（1.16以降） | | Dremio | 読み取り専用 | ネイティブ | | AWS Athena | 限定的 | ネイティブ | | Snowflake | 外部テーブル | ネイティブ（Icebergテーブル） | | BigQuery | 外部テーブル | BigLake Iceberg |

Spark専用環境では、Delta Lakeのより緊密な統合がより良いパフォーマンスを提供します。マルチエンジンアーキテクチャでは、Icebergの幅広い互換性が有利です。Iceberg RESTカタログは、カタログ操作のためのベンダー中立APIを提供します。

パフォーマンス最適化テクニック

両フォーマットとも、最適なクエリパフォーマンスのためにメンテナンス操作が必要です。

# delta_optimize.py
from delta import DeltaTable

delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# 小さなファイルをコンパクト化（ビンパッキング）
delta_table.optimize().executeCompaction()

# 複数カラム述語用のZオーダー
delta_table.optimize().executeZOrderBy("user_id", "event_time")

# 古いバージョンを削除（バキューム）
delta_table.vacuum(retentionHours=168)  # 7日間保持

-- Iceberg: コンパクション用のデータファイル書き換え
CALL catalog.system.rewrite_data_files(
  table => 'analytics.events',
  strategy => 'binpack',
  options => map('target-file-size-bytes', '134217728')
);

-- Iceberg: 古いスナップショットの期限切れ処理
CALL catalog.system.expire_snapshots(
  table => 'analytics.events',
  older_than => TIMESTAMP '2026-07-01 00:00:00',
  retain_last => 10
);

Zオーダリングは関連データをクラスタリングし、述語プッシュダウンの効果を向上させます。ストリーミングソースから多数の小さなファイルを取り込む場合、両フォーマットともファイルコンパクションの恩恵を受けます。

データレイクハウス面接でよくある質問

データエンジニアリング面接で頻出する質問に備えましょう。

Q: IcebergをDelta Lakeより選択する場合はどのような場合ですか？

Icebergが適している場合：（1）複数のクエリエンジン（Spark、Trino、Flink）が同じテーブルにアクセスする、（2）データを書き換えずにパーティションスキームを進化させる必要がある、（3）組織がベンダー中立のオープン標準を好む。Delta LakeはDatabricks中心のアーキテクチャや、Unity Catalogガバナンスが組織のニーズに合う純粋なSpark環境で優れています。

Q: Icebergはどのようにしてデータ書き換えなしでパーティション進化を実現しますか？

Icebergはパーティション仕様をメタデータとして保存します。仕様が変更されると、新しいデータは新しいパーティショニングを使用し、既存データは元のレイアウトを保持します。クエリプランナーはすべてのパーティション仕様を読み取り、各ファイルグループに対して正しいプルーニングロジックを適用します。

Q: Delta Lakeのチェックポイントメカニズムを説明してください。

Delta Lakeはデフォルトで10コミットごとにチェックポイントファイルを作成します。チェックポイントはトランザクションログを単一のParquetファイルに統合し、読み取りを高速化します。_last_checkpointファイルは最新のチェックポイントを指し、リーダーはチェックポイントとその後のJSONコミットを読み取って状態を再構築します。

Q: Copy-on-WriteとMerge-on-Readの違いは何ですか？

Copy-on-Write（COW）は更新時にファイル全体を書き換えます。書き込みコストは高くなりますが、読み取りは高速です。Merge-on-Read（MOR）は差分を別々に書き込み、クエリ時にマージします。書き込みレイテンシは低くなりますが、読み取りオーバーヘッドが発生します。Icebergは両方をサポートし、Delta Lakeは主にCOWを使用しますが、最近のバージョンではソフトデリート用の削除ベクトルを採用しています。

面接前に理解を深めるために、SharpSkillのデータエンジニアリング面接問題でこれらのパターンを練習することをお勧めします。

移行パス：フォーマット間の変換

組織によってはフォーマット間の移行が必要になることがあります。両方とも変換ユーティリティをサポートしています。

# Sparkを使用してDeltaからIcebergに変換
spark.sql("""
    CALL catalog.system.snapshot(
        source_table => 'delta.`s3://bucket/delta_events`',
        table => 'analytics.events_iceberg'
    )
""")

# IcebergからDeltaに変換
from delta.tables import DeltaTable

iceberg_df = spark.read.format("iceberg").load("catalog.analytics.events")
iceberg_df.write.format("delta").save("s3://bucket/delta_events")

完全な移行には、スキーマ型、パーティショニングセマンティクス、ダウンストリームコンシューマーの互換性の慎重な検証が必要です。

結論

• Sparkネイティブワークロード、Databricks環境、Unity Catalogガバナンスが組織のニーズに合う場合はDelta Lakeを選択します
• マルチエンジンアーキテクチャ、パーティション進化要件、クラウド非依存デプロイメントの場合はIcebergを選択します
• 両フォーマットともACIDトランザクション、タイムトラベル、スキーマ進化を提供します。適切な選択は既存のインフラストラクチャとクエリエンジンの多様性に依存します
• 面接準備ではトランザクションログの内部構造、パーティションプルーニング最適化、COW vs MORのトレードオフをカバーする必要があります
• ファイルコンパクションとスナップショット期限切れ処理は、フォーマット選択に関わらず重要なメンテナンスタスクです