Def.：
Apache Icebergとは,データレイク上の大規模な分析データセットを扱うために設計された,オープンでトランザクション整合性を備えたテーブルフォーマット仕様である.
Apache Icebergは,データレイクに保存された膨大なデータファイル群を,1つの論理的なテーブルとして一貫して管理するためのメタデータ構造・スナップショット管理・操作ルールを定義している.
Icebergはデータファイルそのものの形式を規定するものではなく,既存の列指向フォーマット[Parquet, ORC, Avro等]を利用しつつ,それらを追跡・バージョン管理し,スキーマ進化・パーティション抽象化・ACIDトランザクションを実現することにより,効率的かつ安全なクエリ処理を可能にしている.
Apache Icebergは, Netflix社によって2017年頃に開発されたデータレイク管理のための新しいテーブルフォーマットである.当時のNetflixは, Hadoop上にHiveメタストアを利用して大規模なデータ分析基盤を構築していたが, 運用の拡大に伴い深刻な構造的問題を抱えていた.すなわち, スキーマ進化への脆弱性, 一貫性の欠如したクエリ結果, 膨大な小ファイル群によるメタデータ操作の遅延, さらにはSparkやPresto, Flinkといった異なるクエリエンジン間でテーブル構造が共有できないという根本的な互換性の欠如である.これらの問題を解決するために, Netflixは「データファイルの集合を一つのテーブルとして抽象化し, その構造を明示的なメタデータ層で管理する」という発想に基づいてIcebergを設計した.
Icebergの本質は, データそのものではなく「データをどのように追跡し, スナップショットとして扱うか」を定義する仕様にある.従来のHive表がHDFSディレクトリ構造とパーティションを暗黙的に対応づけていたのに対し, Icebergは明示的なメタデータファイルを持ち, そこにすべてのデータファイル, パーティション情報, スキーマ変更, スナップショットの履歴を記録する.これにより, Hiveが抱えていたスキーマ互換性やメタデータ更新の非整合性といった問題が根本的に解消され, ACIDトランザクションとスナップショット分離がデータレイク上で実現された.
Netflixはこの技術を2018年11月にApache Software Foundationへ寄贈し, Apache Incubatorプロジェクトとして受け入れられた.その後, 複数のクラウドベンダーやOSSコミュニティの支援を得て, 2020年5月にApacheのトップレベルプロジェクト[TLP]へと昇格した.この昇格は, データレイクアーキテクチャが「単なるファイル群」から「トランザクションを伴う論理的テーブル管理層」へと進化したことを象徴する出来事であった.
技術的観点から見ると, Icebergは階層的なメタデータ構造を中核に据える.最上位にあるメタデータファイル[metadata.json]は「現在有効なスナップショット」へのポインタを保持し, スナップショットは特定時点のテーブル状態を表現する.各スナップショットはマニフェストリスト[manifest list]を参照し, マニフェストリストは複数のマニフェストファイル[manifest file]を列挙する.マニフェストファイルには, ParquetやORC, Avroなどの実データファイルの位置, サイズ, 統計情報[最小値・最大値・NULL数など]が記録されており, これによってクエリエンジンは効率的にファイルをスキップできる.この設計により, Icebergは数万から数百万のファイルを持つ極めて大規模なテーブルでも, メタデータスキャンを一定時間で完了できる.また, この構造はクエリエンジンから独立しており, Spark, Flink, Trino, Presto, Hiveといった多様な計算基盤が同一のIcebergテーブルを共有可能である.
Icebergの主要な特徴は, スナップショットベースのバージョニング, アトミックな書き込み保証, スキーマおよびパーティション定義の進化, 隠れたパーティショニング[ユーザーがパーティションを意識せずクエリできる機能], そしてメタデータの階層化とキャッシュによる高速クエリにある.さらに, タイムトラベルクエリや増分読み取り, ロールバック機能も標準で提供される.これらの機能は, Delta LakeやApache Hudiと並ぶ「次世代データレイクテーブルフォーマット」の一角を形成するが, Icebergはとりわけ「エンジン非依存性」と「明確に定義されたオープン仕様」において独自の立場を築いた.その後, SnowflakeやGoogle BigLake, AWS Athena, DatabricksなどもIceberg互換を掲げるようになり, 事実上の標準仕様としての地位を確立しつつある.加えて, Icebergはクラウドストレージ[Amazon S3, Google Cloud Storage, Azure Blob Storage]との親和性が高く, オブジェクトストレージ特有の結果整合性の問題にも対処する設計となっている.
Spark, Trino等
Catalog Layer[カタログ管理層[とは, Icebergテーブルの存在と, そのテーブルに対応するルートメタデータファイル[metadata.json]の場所を管理する層である.カタログは「テーブル識別子[namespace + name]」と「そのテーブルの現在有効なメタデータファイルへの参照[ポインタ]」との対応関係を保持し, クエリエンジンがIcebergテーブルを発見し, スナップショットを解決するための入口となる.カタログはトランザクション的整合性を保証する役割も持ち, 複数のクライアントが同一テーブルに同時アクセスする際に, 衝突を防ぐ機構を提供する.
実装としては, Hive Catalog[Hive Metastoreを利用], Hadoop Catalog[ファイルシステムに直接保存], REST Catalog[HTTP経由の標準API], JDBC Catalog, AWS Glue Catalog, およびProject Nessieなどが存在する.これらはいずれもIceberg仕様に準拠した「カタログサービス」として動作し, テーブルの論理的な命名空間管理と, 物理的なメタデータ参照を統一的に扱うことを目的としている.
テーブルのスナップショット管理・スキーマ・パーティション・ファイルリストなどを保持する層である.
この層は, テーブルの論理構造と物理データの対応関係を定義し, トランザクション整合性・タイムトラベル・スキーマ進化を実現する.
Delta Lake[Databricks], Apache Hudi, Hive ACID Tables, Snowflake相当.
Parquet, ORC, Avro等
Amazon S3, Google Cloud Storage[GCS], Azure Data Lake Storage[ADLS Gen2], HDFS[Hadoop Distributed File System], MinIO等.
Mathematics is the language with which God has written the universe.