Apache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理

「iceberg parquet 違い」で検索して比較表を探しても、そもそも両者は同じ土俵で比べる対象ではありません。Parquetは1ファイルの中身を列指向で並べる「ファイルフォーマット」、Apache Icebergは複数のParquetファイルを1つのテーブルとして束ねる「テーブルフォーマット」です。層が違うため、正しくは「どちらを選ぶか」ではなく「Parquetの上にIcebergを載せて併用する」関係になります。この記事では、両者の位置づけの違い、機能差、従来のHiveテーブルや他のテーブルフォーマット（Delta Lake等）との違い、そして判断基準までを整理します。

まとめ：ここだけ押さえれば違いはわかる

• 比較する層が違う：Parquet＝ファイルフォーマット（データの物理的な格納方式）、Iceberg＝テーブルフォーマット（多数のファイルをテーブルとして管理するメタデータの層）。
• 競合ではなく併用：Icebergは内部のデータファイルにParquetを使う。実体は「Icebergメタデータ ＋ Parquetデータファイル」で、二者択一ではない。
• Icebergが足すもの：ACIDトランザクション、スキーマエボリューション、タイムトラベル（スナップショット）、パーティションの隠蔽・進化。Parquet単体には無い「テーブルとしての振る舞い」。
• 本当の選択軸：Iceberg対Parquetではなく、Iceberg対Delta Lake対Apache Hudiという「テーブルフォーマット同士」の比較。
• 判断の目安：単発の分析ファイルならParquet単体で十分。更新・削除・複数エンジンからの同時アクセス・履歴参照が必要ならIceberg。

ParquetとIcebergは比較する層が違う

両者を混同しやすいのは、どちらもデータ分析基盤（データレイク・レイクハウス）で名前を聞くからです。しかし担当する仕事の階層が異なります。Parquetが「1枚1枚のファイルをどう書くか」を決め、Icebergが「その大量のファイルをどうテーブルとして扱うか」を決めます。

Parquetとは（列指向のファイルフォーマット）

Apache Parquetは、分析ワークロード向けに最適化された列指向（カラムナ）のファイルフォーマットです。読み方は「パーケット」。行ではなく列単位でデータをまとめて格納するため、「特定カラムだけを集計する」ような分析クエリで、必要な列だけを読み出せてスキャン量を抑えられます。列ごとに型がそろうため圧縮も効きやすく、CSVやJSONに比べてファイルサイズとスキャン速度で有利です。ただしParquetが定義するのはあくまで1ファイル内の並び方であり、「複数ファイルをまたいだ1つのテーブル」という概念は持ちません。

Apache Icebergとは（オープンなテーブルフォーマット）

Apache Icebergは、データレイク上の大量のデータファイルを1つのテーブルとして管理するためのオープンテーブルフォーマットです。どのファイルがテーブルに属し、各ファイルにどんな列・パーティション・統計があるかを、メタデータファイル（マニフェスト）で追跡します。ディレクトリ配下のファイル一覧に頼る従来方式と違い、テーブルを構成する個々のデータファイルを明示的に追跡する点が本質です。これにより、後述するACIDや履歴管理が成立します。

両者の関係：IcebergはParquetを「中身」に使う

重要なのは、Icebergが特定のファイルフォーマットに縛られない設計だという点です。Icebergテーブルの実データは、通常Parquet（ほかにAvro・ORCも選択可能）のファイルとして格納され、Icebergはそれらを指すメタデータを重ねます。つまり典型的な構成は次のように、メタデータ層とデータ層に分かれます。

my_table/
+-- metadata/        ← Iceberg が管理（テーブル定義・スナップショット・マニフェスト）
|   +-- v3.metadata.json
|   +-- snap-xxxx.avro
+-- data/            ← 実データ。中身は Parquet ファイル
    +-- 00000-0-xxxx.parquet
    +-- 00001-0-xxxx.parquet

この構造がわかれば、「IcebergとParquetのどちらが速い・優れている」という問いが成り立たないことも見えてきます。Parquetは物理的な格納を、Icebergはその上のテーブル運用を担う、役割分担の関係です。

機能で見るParquetとIcebergの違い

層が違うと言っても、「結局Icebergを載せると何ができるようになるのか」が知りたいはずです。Parquet単体との差を機能で並べると次のとおりです。

ACIDトランザクションのサポート

Parquetはファイル単位のため、複数の書き込みが同時に走ると「途中まで書けたファイル」が読まれる恐れがあります。Icebergはスナップショットとアトミックなコミットで一貫性を担保し、コミットが完了して初めて新しいファイル群がテーブルに反映されます。Sparkなど複数の書き込みが並行しても、読み手は常に一貫したスナップショットを見ます。これが「データレイクにデータウェアハウス並みの信頼性を持ち込む」と言われる中核です。

スキーマエボリューション（Parquetとの差が大きい点）

Parquetでも列の追加・削除はある程度できますが、ネスト構造の変更やパーティション定義の更新には弱いのが実情です。Icebergは各列に一意のIDを割り当てて管理するため、列名の変更・順序変更・型の拡張・列の追加削除を、既存データを書き直さずに安全に行えます。IDで対応づけるので、列名を変えても過去データが壊れません。運用中のテーブルにカラムを足すような場面で差が出ます。

Icebergと従来のテーブル形式（Hive）の違い

「アイスバーグテーブルは従来のテーブル形式とどう違うのか」も検索の多い論点です。ここでの「従来のテーブル形式」とは、多くの場合Hiveテーブル（ディレクトリ単位でパーティションを管理する方式）を指します。Hive方式は、あるパーティションのデータをディレクトリ配下のファイル一覧（ls）で把握するため、ファイル数が増えると一覧取得が重くなり、書き込み途中の状態が見えたり、パーティション列の変更が難しかったりします。

Icebergは前述のとおり、テーブルに属するファイルをメタデータで明示的に追跡します。ディレクトリのリスト操作に依存しないため大規模でもプランニングが速く、コミット単位で原子的に切り替わるので中途半端な状態が見えません。パーティションも物理配置から切り離して定義でき、後から変更できます。「Iceberg対従来テーブル形式」の違いは、このファイル追跡方式（メタデータ管理か、ディレクトリ一覧か）に集約されます。

Iceberg・Delta Lake・Hudiの違い（本当の選択軸はここ）

「iceberg parquet 違い」で本当に比較を迷っている場合、選択肢は多くのケースでParquetではなく他のテーブルフォーマットです。テーブルフォーマットにはIcebergのほかにDelta LakeとApache Hudiがあり、どれもParquetを内部データに使いつつ、その上でACIDや履歴管理を提供します。つまり「Parquetか否か」ではなく「どのテーブルフォーマットでParquet群を束ねるか」が実際の判断になります。

• Apache Iceberg：エンジン中立で、Spark・Trino・Flink・Snowflake・DuckDB等の幅広いエンジンから読み書きできる。マルチエンジン前提の基盤で採用が進む。
• Delta Lake：Databricks発。Sparkとの結合が強く、Databricks環境で扱いやすい。仕組みや使いどころはDelta Lakeがデータレイクの信頼性課題を解く理由で整理しています。
• Apache Hudi：ストリーミングでの頻繁なUpsert（更新挿入）に強みがあり、CDC的な取り込みで選ばれやすい。

3者は機能面で近づいており、決め手は「自社が使うクエリエンジンとの相性」「既存基盤（Databricks中心かマルチクラウドか）」になることが多いです。エンジン中立性を重視するならIcebergが選ばれやすく、そのカタログ運用にはApache Icebergに対応するオープンソースカタログApache Polarisのような選択肢もあります。

いつParquet単体で足り、いつIcebergが要るか

層が違う以上、「常にIcebergが正解」ではありません。オーバーヘッド（メタデータ管理・カタログ運用）を払う価値があるかで判断します。次のような使い分けが現実的です。

• Parquet単体で十分：一度書いたら基本的に更新しない、単発のバッチ出力や機械学習の学習データ、1つのエンジンから読むだけ——といった「追記も更新もほぼ発生しない」ケース。テーブル管理の仕組みを足す必要がありません。
• Icebergを使うべき：レコードの更新・削除が発生する、複数のエンジン（例：Sparkで書きTrinoで読む）から同じデータを扱う、書き込み中でも読み手に一貫した状態を見せたい、過去時点のデータを参照・巻き戻したい、運用中にスキーマを変えたい——のいずれかに当てはまるとき。

迷ったときの起点はシンプルです。「このデータは後から書き換わるか、複数のエンジンから触られるか」がイエスなら、Parquetファイル群をIcebergで束ねる。ノーなら、まずParquetのまま置いてよい。ローカルやアドホックにParquet/Icebergを試すなら、組み込み分析データベースDuckDBや分散SQLクエリエンジンTrinoから読むのが手軽です。

Iceberg v3で何が変わったか（2026年時点の最新仕様）

Icebergは仕様（フォーマットバージョン）が進化しており、比較の前提も更新されています。フォーマット仕様v3は主要プラットフォームで利用が広がり、SnowflakeではGA（2026年5月7日）、DatabricksではRuntime 18.0以降で対応が進む段階です。実装のApache Icebergは1.11系（2026年5月リリース）が最新で、Apache Spark 4.1・Flink 2.1への対応やテーブル暗号化の内蔵が加わりました。変動が速い領域のため、採用時は必ず公式のリリースノートで最新版を確認してください。

v3で追加された主な機能は次のとおりで、Parquet単体との差はさらに広がっています。

• Deletion Vectors（削除ベクトル）：削除をビットマップで表現し、v2の位置指定削除ファイルより高速に行削除を反映。
• Row Lineage（行の来歴）：行単位で更新履歴を追跡できる。
• VARIANT型：半構造化データ（JSON的なデータ）をそのまま扱える型を追加。
• デフォルト列値・ナノ秒タイムスタンプ・地理空間型（geometry/geography）などの型・機能拡張。

よくある質問

Parquetの読み方は？

「パーケット」と読みます。木の寄せ木張り（parquet flooring）が語源で、データを規則正しく並べて格納するイメージです。

IcebergとParquetはどちらを選ぶべきですか？

二者択一ではありません。Parquetはファイルの格納方式、Icebergはそのファイル群をテーブルとして管理する層で、通常はIcebergテーブルの中身としてParquetを使います。「テーブルとしての更新・履歴・複数エンジン対応が要るか」でIcebergを載せるかどうかを判断します。

Icebergは従来のテーブル形式とどう違いますか？

従来のHiveテーブルはディレクトリ配下のファイル一覧でデータを把握しますが、Icebergはテーブルに属するファイルをメタデータで明示的に追跡します。これにより大規模でも高速で、書き込みが原子的に反映され、パーティションを後から変更できます。

IcebergはParquet以外のファイル形式も使えますか？

使えます。Icebergはファイルフォーマットに依存しない設計で、データファイルにParquetのほかAvroやORCも選べます。実運用ではParquetが最も一般的です。

Icebergのスキーマエボリューションとは何ですか？

既存データを書き直さずに、列の追加・削除・改名・型拡張・並べ替えを安全に行える仕組みです。各列に一意のIDを割り当てて管理するため、列名を変えても過去データとの対応が壊れません。

関連記事

• Delta Lakeがデータレイクの信頼性課題を解く理由（もう一つの主要テーブルフォーマット）
• Apache Polaris：Apache Icebergに対応するオープンソースカタログ
• 分散SQLクエリエンジンTrinoとは
• 組み込み分析データベースDuckDBとは