データエンジニアが「イミュータブル」を理解すべき理由

はじめに

「イミュータブル（immutable）」とは、一度作成されたデータが変更されないという性質を指します。関数型プログラミングの世界では馴染み深い概念ですが、近年のデータエンジニアリングにおいても、この性質が設計の根幹に据えられるようになっています。

Snowflakeのマイクロパーティション、Delta Lakeのトランザクションログ、Apache Icebergのスナップショット。これらに共通するのは、データファイルを上書きしないという設計思想です。

本記事では、特定のプロダクトに依存しない汎用的な視点から、イミュータブルなデータ設計がなぜ重要なのか、そしてこの概念を理解していないとどのような問題に直面するのかを解説します。

対象読者

• データ基盤の設計・運用に関わるエンジニア
• データパイプラインの信頼性に課題を感じている方
• モダンデータスタックの「なぜそうなっているのか」を理解したい方

ミュータブルとイミュータブルの違い

まず、データの更新方法における2つのアプローチを整理します。

ミュータブル（Mutable）: 上書き型

従来のRDBMSに代表される方式です。UPDATE文を実行すると、既存の行が直接書き換えられます。

【UPDATE前】
| id | name   | status |
|----|--------|--------|
| 1  | 田中   | active |

UPDATE users SET status = 'inactive' WHERE id = 1;

【UPDATE後】
| id | name   | status   |
|----|--------|----------|
| 1  | 田中   | inactive |   ← 元の "active" は消失

この方式では「変更前の値がどうだったか」という情報が失われます。

イミュータブル（Immutable）: 追記型

一方、イミュータブルな設計では、既存のデータは一切変更しません。変更が必要な場合は、新しいバージョンのデータを追加し、どのバージョンが最新かをメタデータで管理します。

【初期状態】
File_v1: { id: 1, name: "田中", status: "active" }

UPDATE相当の操作 →

【更新後】
File_v1: { id: 1, name: "田中", status: "active" }     ← そのまま残る
File_v2: { id: 1, name: "田中", status: "inactive" }    ← 新規作成

メタデータ: "最新はFile_v2を参照せよ"

元のデータは物理的に残っており、メタデータの参照先を切り替えることで「更新」を表現します。

なぜデータエンジニアリングでイミュータブルが重要なのか

イミュータブルなデータ設計が重要である理由を、5つの観点から解説します。

1. 同時実行制御が安全になる

データ基盤では、複数のパイプラインやユーザーが同時にテーブルを読み書きします。ミュータブルなデータに対して同時にアクセスする場合、読み取りと書き込みの整合性を保つためにロック機構が必要です。

イミュータブルな設計では、既存のファイルが書き換わらないため、読み取り中のデータが途中で変わるということが起こりません。これはMVCC（Multi-Version Concurrency Control）の基盤となる考え方です。

【ミュータブルな場合】
読み取りクエリ → File_A を読み中...
書き込みジョブ → File_A を上書き中...  ← 競合！ロックが必要

【イミュータブルな場合】
読み取りクエリ → File_A を読み中...     ← File_Aは変わらないので安全
書き込みジョブ → File_B を新規作成     ← 別ファイルなので競合しない

ロック不要で安全に並行処理ができるということは、ウェアハウスやレイクハウスのスケーラビリティに直結します。

2. タイムトラベルとデータ復旧が可能になる

過去のバージョンのファイルが残っているということは、任意の時点のデータ状態を再現できるということです。これがいわゆる「タイムトラベル」機能の仕組みです。

タイムトラベルが実務で役立つ場面は多くあります。「昨日のETLジョブでデータを誤って上書きしてしまった」「先月末時点のデータで集計をやり直したい」「本番データのどの時点からデータ品質が崩れたか特定したい」といったケースです。

ミュータブルなシステムでは、こうした復旧のために別途バックアップやCDC（Change Data Capture）の仕組みを構築する必要があります。イミュータブルな設計では、これがアーキテクチャに組み込まれているため、追加の仕組みなしにデータ復旧が可能です。

3. パイプラインの冪等性と再実行性が担保される

データパイプラインにおいて「同じジョブを2回実行しても同じ結果になる」という冪等性（べきとうせい）は極めて重要です。

イミュータブルなデータ設計では、各処理ステップの入力と出力がバージョンで固定されるため、パイプラインの再実行が安全に行えます。入力データが変わらない以上、同じロジックを適用すれば同じ結果が得られます。

【イミュータブルなパイプライン】

入力: snapshot_v3 (固定)
  ↓ Transform処理
出力: result_v3 (固定)

再実行しても snapshot_v3 は変わらない → result_v3 も同じ

一方、ミュータブルなデータソースに対してパイプラインを再実行すると、実行タイミングによってソースデータが変わっている可能性があるため、結果の再現性が保証されません。

4. データリネージと監査が容易になる

イミュータブルなアーキテクチャでは、すべての変更が新しいバージョンとして記録されるため、「いつ、何が、どのように変わったか」の完全な履歴が残ります。

これは以下のような場面で特に価値を発揮します。

• データ品質の問題調査: 「このカラムの値がおかしくなったのはいつからか」をバージョン間の差分で特定できる
• コンプライアンス対応: 金融・医療など、データの変更履歴の保持が規制で求められる業界での監査証跡として機能する
• デバッグ: パイプラインのどのステップでデータが想定外の状態になったかを、各ステップの入出力バージョンを辿って追跡できる

5. クラウドオブジェクトストレージとの親和性が高い

現代のデータ基盤は、S3やGCS、Azure Blob Storageといったクラウドオブジェクトストレージをストレージレイヤーとして利用するケースがほとんどです。

オブジェクトストレージには重要な特性があります。ファイルの部分更新ができないという点です。1つのファイル（オブジェクト）を更新するには、ファイル全体を書き直す必要があります。つまり、オブジェクトストレージは本質的に「書いたら読むだけ」のワークロードに最適化されています。

イミュータブルなデータ設計は、この特性と自然に合致します。

【オブジェクトストレージの特性との対応】

✅ イミュータブル設計:
  新しいファイルをPUT → メタデータ更新 → 完了
  → オブジェクトストレージの得意パターン

❌ ミュータブル設計:
  既存ファイルを読み取り → 一部変更 → 全体を再PUT
  → 非効率。部分更新のオーバーヘッドが大きい

さらに、イミュータブルなファイルはキャッシュとの相性も良好です。ファイルの内容が変わらないことが保証されているため、一度キャッシュした結果を安全に再利用できます。

モダンデータスタックにおけるイミュータブル設計の実例

ここまでの原則が、実際のテクノロジーでどう実装されているかを概観します。

データウェアハウス

Snowflakeのマイクロパーティション、BigQueryの内部ストレージなど、クラウドDWHの多くはイミュータブルなストレージ単位を採用しています。UPDATEやDELETEが実行されると、変更対象のパーティションが新たに作り直され、元のパーティションは削除マーク付きで一定期間保持されます。この仕組みにより、タイムトラベルやゼロコピークローンが実現されています。

オープンテーブルフォーマット

Apache Iceberg、Delta Lake、Apache Hudiは、データレイク上でACIDトランザクションを実現するオープンテーブルフォーマットです。これらに共通する設計原則は、データファイル（通常はParquet形式）をイミュータブルに保ち、変更はメタデータレイヤーで管理するというアプローチです。

データの更新・削除を実現する方式として、主に2つのパターンがあります。

方式	仕組み	特徴
Copy-on-Write (CoW)	変更時に新しいデータファイルを丸ごと書き直す	読み取りが高速。書き込みコストが高い
Merge-on-Read (MoR)	変更差分を別ファイル（デリートファイル等）に記録し、読み取り時にマージ	書き込みが高速。読み取り時にマージコストが発生

いずれの方式でも、元のデータファイル自体は変更されません。このイミュータブル性があるからこそ、スナップショットベースのタイムトラベルやACIDトランザクションが可能になっています。

ストリーミング・イベント基盤

Apache Kafkaに代表されるイベントストリーミング基盤も、追記専用のイミュータブルなログ（append-only log）を核とした設計です。一度書き込まれたイベントは変更されず、コンシューマはオフセットを進めることでイベントを順次読み取ります。

イベントソーシングやCQRS（Command Query Responsibility Segregation）といったアーキテクチャパターンも、イミュータブルなイベント列からシステムの状態を再構築するという考え方に基づいています。

イミュータブルを理解していないと起こる問題

逆に、この概念を理解せずにデータ基盤を設計・運用すると、以下のような問題に直面しがちです。

ストレージコストの誤解

イミュータブルな仕組みでは、更新のたびに新しいファイルが作られるため、旧バージョンのファイルがストレージに蓄積します。タイムトラベルの保持期間や、古いスナップショットのクリーンアップ（バキューム、コンパクション）を適切に設定しないと、ストレージコストが想定以上に膨らみます。

「UPDATEを1行実行しただけなのにストレージ使用量が急増した」という問題は、イミュータブル性を理解していないと原因の特定が難しくなります。

小さなファイルの大量発生

頻繁なINSERTやUPDATEを行うと、小さなイミュータブルファイルが大量に生成される「スモールファイル問題」が発生します。小さなファイルが増えるとメタデータのオーバーヘッドが増大し、クエリパフォーマンスが低下します。

対策として、コンパクション（小さなファイルを統合して適切なサイズにまとめる処理）を定期的に実行する必要がありますが、これもイミュータブルな設計を理解していなければ「なぜ必要なのか」が分かりません。

パイプライン障害時の不適切な対応

ミュータブルなシステムの感覚で「とりあえず再実行」すると、イミュータブルな環境ではデータが重複する可能性があります。同じデータが2回書き込まれ、それぞれが独立したバージョンとして記録されるためです。

正しい対応は、タイムトラベルで障害前の状態に戻してから再実行するか、冪等性を担保した書き込み（MERGE文の活用など）を設計段階から組み込んでおくことです。

DMLの頻度設計ミス

イミュータブルな環境で1行ずつUPDATEを繰り返すと、更新のたびに新しいファイルが作成されるため、パフォーマンスとコストの両面で大きな問題になります。クラスタリングの劣化やリクラスタリングのコスト増にもつながります。

バッチ処理でまとめてDMLを実行する、マイクロバッチの粒度を適切に設計するといった工夫が必要です。

まとめ

イミュータブルという概念は、現代のデータエンジニアリングのほぼすべてのレイヤーに浸透しています。

レイヤー	イミュータブル性の現れ方
ストレージ	オブジェクトストレージのファイルは部分更新不可
テーブルフォーマット	Iceberg / Delta Lake / Hudi はデータファイルを不変に保つ
DWH	Snowflake / BigQuery 等はパーティションをイミュータブルに管理
ストリーミング	Kafkaのログは追記専用
パイプライン設計	冪等性・再現性はイミュータブルな入出力が前提

イミュータブル性を理解することで、タイムトラベルがなぜ可能なのか、コンパクションがなぜ必要なのか、ストレージコストがなぜ増えるのか、といったデータ基盤運用の「なぜ」に対する解像度が格段に上がります。

特定のプロダクトの操作方法を覚えることも大切ですが、その背後にあるイミュータブルという設計原則を理解しておくことで、プロダクトが変わっても通用する判断力が身につくはずです。

参考

• Michael L. Perry『The Art of Immutable Architecture』Apress, 2024
• What is Data Immutability? | Dremio
• 3 Design Principles for Engineering Data | Button
• Immutable Data Architectures | Dev3lop