Delta Lakeとは｜Icebergとの違いとレイクハウス実装

Delta Lakeとは｜Parquetにログを重ねた保存層

Delta Lakeは、Parquetで保存されたデータに対して、トランザクションログによる一貫性を与えるオープンソースの保存層です。 Databricks発のプロジェクトで、現在はLinux Foundation傘下で開発されています。

よくある誤解から先に潰しておきます。Delta LakeはParquetを置き換えるものではありません。データ本体は普通のParquetファイルのままです。変わるのは「どのファイルが、いつの時点のテーブルを構成しているか」を記録する仕組みのほうです。

トランザクションログの中身

テーブルのディレクトリを開くと、データのParquetファイルと並んで_delta_logというディレクトリがあります。この中に、000000000000000000.json のような連番のJSONファイルが積み上がっていきます。

1つのJSONが1回のコミットに対応します。中身は「このファイルを追加した」「このファイルを削除した」という操作の記録です。読み取り側は、ログを順に適用して現在のテーブル状態を組み立てます。

ログが増えると再生コストが上がるため、一定間隔でチェックポイント（Parquet形式のスナップショット）が作られます。読み取りは直近のチェックポイントから再開できる仕組みです。

ACIDをどう実現しているか

Delta Lakeは楽観的並行制御を使います。書き込み側はまず現在のバージョンを読み、処理を行い、最後に「次の連番のログファイルを作れたら成功」という形でコミットします。

同じ連番を複数の書き込みが取り合った場合、先に作れたほうが勝ち、負けたほうはリトライします。つまりACIDの土台は「同じ名前のファイルを1つしか作らせない」というストレージ側の保証にあります。この前提が崩れるのがS3で、後述する実装上の最大の注意点になります。

ミニFAQ：Parquetのデータレイクから移行できますか

既存のParquetテーブルは CONVERT TO DELTA で変換できます。データファイルを書き直さずログを生成する方式のため、巨大なテーブルでも比較的短時間で済みます。ただし変換後はDelta対応エンジンからの読み取りが前提になるため、既存ジョブの対応状況を先に洗い出してください。

Delta Lakeの主要機能

使われる理由は、データレイクに「やり直し」と「部分更新」を持ち込める点に集約されます。

タイムトラベルとVACUUMの関係

ここは運用で必ず引っかかる箇所です。タイムトラベルで遡れる期間は、ログの保持期間と、削除済みファイルの保持期間の両方に縛られます。

公式ドキュメントによると、ログ保持（delta.logRetentionDuration）の既定は30日、削除済みファイル保持（delta.deletedFileRetentionDuration）の既定は7日です。VACUUMはこの後者を基準に物理ファイルを消します。

つまり既定のままVACUUMを回すと、7日より前のバージョンは実体が消えて復元できなくなります。「30日戻れるはず」と思い込んだまま保持設定を触ると、監査要件を満たせないことがあります。詳細はDelta Lake公式ドキュメント（テーブルバッチ読み書き）で確認してください。

小ファイルへの対処

ストリーミング取り込みや頻繁なMERGEは、小さなParquetを大量に生みます。対策はOPTIMIZEによるコンパクションです。

従来はZ-Orderでデータの並びを整えるのが定番でしたが、現在はLiquid Clustering（CLUSTER BY）という選択肢があります。公式ドキュメントでは、Delta Lake 3.1.0以降で利用可能、3.1ではプレビュー扱いで、3.2以降は正式機能と整理されています。クラスタリング列は統計が収集された列から最大4列まで、という制限も明記されています。

既存データを書き直さずにクラスタリング列を再定義できる点が、固定パーティションとの大きな違いです。

執筆時点のバージョンの現在地

技術選定の資料に使うなら、バージョンの前提を揃えてから比較してください。 以下は2026年11月時点でDelta Lakeのリリース一覧から確認できる状況です。

4.0では、Delta Standaloneとそれに依存するDelta Flink・Delta Hiveコネクタが4.x系のリリース対象から外れました。公式リリースノートでは、これらは保守モードで3.x系の重大な修正のみ、Delta Kernelへ移行していく方針が示されています。レガシーなFlink連携を含む構成の移行案件では、ここが見積りの分岐点になります。

なおバージョン名を出す以上は時間で陳腐化します。採用前に公式リリースノートで最新安定版とプレビュー区分を必ず確認してください。

Delta LakeとApache Icebergの違い

この章が本記事の中心です。Iceberg自体の仕様の詳細（メタデータ階層やカタログ層の論点）はApache Icebergとは｜テーブルフォーマットの仕組みと案件要件で扱っているため、ここではDelta側から見た差分に絞ります。

構造の違い：連番ログか、スナップショット階層か

Deltaは連番のコミットログを前から順に適用します。Icebergはスナップショット、マニフェストリスト、マニフェストという階層をたどってファイル集合を特定します。

結果として得意・不得意が変わります。Deltaは「直近の状態を素早く組み立てる」方向、Icebergは「巨大なテーブルでファイルの枝刈りを効かせる」方向に設計の重心があります。

仕様の進め方が根本的に違う

Icebergは仕様バージョンで進みます。Apache Iceberg公式のテーブル仕様では、v1・v2・v3が策定済みでコミュニティに採択済み、v4は現在策定中で正式採択されていないと明記されています。v3ではvariantやgeometryなどの型、行の系統追跡（Row Lineage）、バイナリのDeletion Vectorsが追加されました。

一方のDeltaは、テーブル機能（table features）という単位で機能を有効化します。バージョン番号を上げるのではなく、必要な機能だけをテーブルに付ける考え方です。

この違いは実務に響きます。Icebergは「このテーブルはv3だから、読み手もv3対応が必要」という判断になりますが、Deltaは「このテーブルはDeletion Vectorsを使っているか」という機能単位の確認になります。

比較表（判断に使う粒度で整理）

両者の機能差は年々縮んでいます。今の選定は「機能の優劣」ではなく「どのエンジンとカタログを中心に据えるか」で決まると考えたほうが実態に近くなります。

ミニFAQ：性能はどちらが速いですか

日本語で見かけるベンチマーク記事の多くは、Delta 1.x世代とIceberg 0.x世代を比べた古いものです。双方ともDeletion Vectorsや統計の持ち方が変わっているため、過去の数値をそのまま現在の判断材料にはできません。自社のクエリパターンで測り直すのが前提になります。

UniForm｜Deltaで書いてIcebergとして読む

UniFormは、Deltaテーブルを書きながら、Iceberg（またはHudi）のメタデータも同時に生成する機能です。 Iceberg対応ツールから同じデータを読めるようになります。

制限はバージョンで変わりやすい領域です。以下は現時点の公式ドキュメントに記載されている要件と制限で、導入前に最新版で再確認してください。

• 有効化にはcolumn mapping（物理的な列名とテーブル上の列名を切り離す機能）が必要で、テーブルプロトコルはminReaderVersion 2以上・minWriterVersion 7以上

• Iceberg向けの書き込みはDelta Lake 3.1以上、Hudi向けは3.2以上

• Iceberg・Hudiクライアントからは読み取りのみ。外部ライターが書き込むとデータ破損の危険がある

• Deletion Vectorsを有効にしたテーブルでは使えない

• Change Data FeedとDelta SharingはIceberg側では未対応

ここを読み違えると設計が壊れます。UniFormは「双方向の相互運用」ではなく「Deltaを正としたIceberg読み取りの提供」です。Iceberg側から更新したい要件があるなら、UniFormでは解けません。

レイクハウス実装の勘所

メダリオンアーキテクチャの組み方

ブロンズ（生データ）、シルバー（整形・名寄せ済み）、ゴールド（集計・用途別）の3層に分けるのが定番です。層ごとに役割を固定すると、再処理の範囲を限定できます。

層の設計やオーケストレーションの考え方は、Apache Airflowとは｜DAGの仕組み・dbt/Dagsterとの違い・案件単価やdbtとは｜データ変換(ELT)の仕組み・使い方・案件単価で扱っている内容と組み合わせると具体化しやすくなります。

S3で複数クラスタから書くときの制約

ここが実装で最も事故が起きる箇所です。 現時点のDelta Lake公式のストレージ設定ドキュメントには、S3は相互排他（mutual exclusion）を提供しないため、1つのライターだけがファイルを作成できることを保証する手段がない、と書かれています。

そのため既定のLogStore実装（S3SingleDriverLogStore）では、保証されるのは単一のSparkドライバ内での同時書き込みだけです。複数クラスタから同じテーブルに書くと、データ損失の危険があると明記されています。なおマネージドサービス側で独自のコミット調停を持つ環境もあるため、最終的には利用するランタイムのドキュメントもあわせて確認してください。

複数クラスタ書き込みを行う場合は、DynamoDBを使うS3DynamoDBLogStoreを設定します。専用JARとDynamoDBテーブルの用意が必要で、すべてのライターが同じLogStore実装・同じDynamoDBテーブル・同じリージョンを使っていなければ安全ではありません。「一部のバッチだけ別クラスタから書いている」といった構成が混ざっていると、前提が崩れます。

移行案件に入る初週は、どのジョブがどこからテーブルに書いているかを洗い出すところから始めると、この種の地雷を早く見つけられます。

運用の既定値まとめ

どちらを選ぶか｜ケース別の判断

判断軸は「中心に据えるエンジンとカタログ」の1点です。 以下は選定の目安で、要件次第で逆転します。

学習順でいえば、先にDelta Lakeで「ログとスナップショットで一貫性を作る」考え方を手で触って掴み、その後にIcebergのマニフェスト階層を読むと理解が早くなります。概念が共通しているので、2つ目は数日単位で輪郭を掴めます。

Databricksとは｜レイクハウスの仕組み・Snowflakeとの違い・案件単価は製品としての全体像、Apache Sparkとは｜分散処理の仕組み・Hadoopとの違い・案件単価は実行エンジン側の基礎にあたります。あわせて読むと、どこまでがDelta Lakeの責務かが整理できます。

フリーランス案件でDelta Lakeはどう見られるか

単独スキルとして募集されることはほとんどありません。 フリーランス向けエージェントの公開案件（データ基盤・データエンジニア系の募集）を見る限りでは、Databricks構築・運用やSparkによるデータ基盤開発の要件の中に、Delta Lakeの設計経験が並ぶ形が中心です。以下は公開されている募集要件を読んだ範囲での整理で、非公開案件や社内直請けの傾向までは含みません。

評価されやすいのは、機能を知っていることよりも、次のような判断ができることです。

• メダリオン層の切り方と再処理範囲を説明できる

• OPTIMIZEやVACUUMの実行計画を、復元要件とコストの両面から決められる

• DeltaとIcebergのどちらを採るかを、エンジン構成を根拠に説明できる

• 既存Parquet資産からの移行手順とリスクを事前に洗い出せる

単価の水準はレイヤー（取り込み・変換・BI）と商流で大きく変わります。レイヤー別の目安はデータ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキル、職種としての全体像はデータエンジニアとは？仕事内容・年収・将来性をわかりやすく解説で整理しています。いずれも公開案件ベースの目安であり、個別の提示額は経験・稼働・商流で動きます。

自分の経験でどの程度の単価を狙えるかを確かめたい場合は、無料のフリーランスエンジニア単価診断でおおよその市場水準を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？、複数案件から選ぶときの優先順位のつけ方は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位にまとめています。

Spark関連の募集状況はSparkの案件一覧から確認できます。

よくある失敗と対策

VACUUM実行でロールバックできなくなる

「30日戻れる」と思い込んだまま既定設定でVACUUMを回し、7日より前の復元ができなくなるパターンです。復元要件を先に決め、削除済みファイル保持をそこから逆算してください。

複数クラスタからS3に書いてログが壊れる

検証環境では再現せず、本番で散発的に壊れるため原因特定が遅れます。書き込み主体を棚卸しし、必要ならS3DynamoDBLogStoreへ統一します。中途半端に一部だけ導入するのが最も危険です。

UniFormを双方向と誤解した設計

Iceberg側から更新する前提で設計すると、実装段階で破綻します。要件定義の時点で「書き込みの正はDelta」と合意しておくことが必要です。

バージョン前提のずれ

Delta Spark 4.x系はSpark 4系が前提で、Scala 2.13向けの成果物が公開されています。Spark 3.5系を使い続ける現場では3.x系の保守リリースを追うことになります。PoCと本番で版を揃えておかないと、移行時に手戻りが出ます。

実践チェックリスト

着手前に以下を確認しておくと、設計のやり直しを減らせます。

1. テーブルを読み書きするエンジンを全て列挙したか（Spark以外の読み手の有無）

2. ストレージはS3か。複数クラスタから書く計画はあるか

3. 復元要件は何日分か。VACUUMと保持設定はそれに整合しているか

4. Deletion Vectorsを使うか。使うならUniFormは選択肢から外れる

5. 採用するDelta版と、対応するSpark版・Scala版を揃えたか

6. Flink連携が必要か。必要なら現在のコネクタの保守状況を確認したか

7. クラスタリング列の候補は統計収集対象になっているか（最大4列）

まとめ

Delta LakeはParquetにトランザクションログを重ねた保存層で、Icebergとの違いはメタデータの持ち方と仕様の進め方にあります。選定はエンジンとカタログの構成で決まります。

• 実体はParquet。ログとチェックポイントで一貫性を作る

• タイムトラベルの実効期間は削除済みファイル保持（既定7日）に縛られる

• Icebergは仕様バージョンで進み、v3まで採択済み、v4は策定中

• UniFormはDeltaを正としたIceberg読み取りの提供で、双方向ではない

• S3の既定構成は単一ドライバ前提。複数クラスタ書き込みは専用のLogStoreが必要

• 案件では単独スキルではなく、Databricks・Spark案件の中の設計判断として評価される

次のステップとしては、手元のクエリパターンでOPTIMIZEとクラスタリングの効き方を測ること、そして既存テーブルの書き込み主体を棚卸しすることをおすすめします。

参照した一次情報は次のとおりです。

• Delta Lake公式ドキュメント（テーブルバッチ読み書き）

• Delta Lake公式ドキュメント（ストレージ設定）

• Delta Lake公式ドキュメント（UniForm）

• Delta Lakeリリース一覧（GitHub）

• Apache Iceberg Table Spec

• Azure DatabricksのDelta Lakeとは（Microsoft Learn）