はじめに
データレイクにACIDトランザクションをもたらすオープンテーブルフォーマットとして、Delta LakeとApache Icebergは非常に人気があります。どちらも分析に最適化されたParquet形式でデータを保存しますが、メタデータの管理方法やトランザクションログの構造は大きく異なります。
この記事では、Azure Data Lake Storage (ADLS) 上でそれぞれのテーブルを作成・データ挿入した際の実際のフォルダ構成をスクリーンショットベースで比較し、初心者でもイメージしやすいように解説します。さらに、Microsoft FabricのLakehouseショートカット機能を使って、IcebergテーブルをDelta形式で扱うハイブリッドなケースの場合の実態も画像で紹介します。
Delta Lakeの実態（ファイルフォーマット）
Delta Lakeテーブルでは、Parquet形式でデータを保存し、変更履歴は_delta_log/というフォルダに格納されます。
- part-0000...snappy.parquet：実際のデータファイル
- delta_log/00000000000000000000.json：初回のトランザクションログ
- delta_log/00000000000000001000.checkpoint.crc：定期的に書かれるチェックポイントファイル（読み込み最適化のため）
各トランザクション（INSERT、UPDATE、DELETEなど）ごとにJSON形式のログファイルが追加され、これにより時系列の変更履歴（＝タイムトラベル）が可能になります。
Icebergの実態（ファイルフォーマット）
空の状態（CREATE ICEBERG TABLE後）の実態
IcebergもデータはParquet形式で保存しますが、トランザクションログの仕組みが異なり、metadata/という専用フォルダでスナップショットを管理します。
空のテーブル作成直後：
- metadata/00000-.metadata.json：初期スキーマを記録したJSON
データを挿入後（INSERT INTO後）の実態
- data/：Parquetデータファイル格納フォルダ（例：snow__0_1.parquet）
- metadata/00001-.metadata.json：新しいスナップショットを記録
- manifest.avro：どのParquetファイルが含まれているかを示すAvroファイル
▽参考：ADLSにIcebergテーブルを作る手順
Icebergテーブルに対してFabricLHでショートカットし、Delta Lake変換したとき
Microsoft FabricのLakehouseでは、ADLS上のIcebergテーブルにショートカットを作成することで、Delta形式のように扱うことができます。
新たに _delta_log/ フォルダが仮想的に作られる（実際のストレージには存在せず、OneLakeメタデータ内で管理）
生成されるファイル例：
-
00000000000000000000.json：現時点のIcebergスナップショットをDelta形式で記録したログ
-
latest_conversion_log.txt：変換に関する情報（成功・失敗など）
このように、元のIcebergのmetadataフォルダは保持されたまま、Delta Lakeの形式が「追加」されます。
delta_logの中身は以下
▽参考：Icebergへのショートカット