Summary:
カタログは,分散データ処理におけるメタデータ管理の要である.初期のデータウェアハウスにおいては,テーブルスキーマや位置情報はリレーショナルデータベース[RDBMS]内部のシステムカタログに保持されていた.クエリエンジンが内部カタログに問い合わせることで,テーブルの存在,カラム構造,データ型,インデックス情報,統計情報などを得ることができた.このモデルでは,メタデータとデータが一体的に管理され,ACID特性によってスキーマとデータの整合性は自動的に保証されていた.
ビッグデータ時代の到来により,Hadoopを代表とする分散ファイルシステム上に生データを蓄積し,複数のクエリエンジンからアクセスする必要が生じた.ここで生まれたのがApache HiveのMetastoreである.Hive Metastoreは,HDFSに保存されたParquet,ORC,Avroといったファイル群に対して,テーブル名,カラム定義,データ型,パーティション構造,ストレージ形式,SerDe[Serializer/Deserializer]情報といったメタデータを一元的に管理する仕組みを提供した.Metastoreは背後でRDBMS[MySQL,PostgreSQLなど]を使用してメタデータを永続化し,Thrift APIを通じてアクセス可能であった.これにより,Spark,Presto[現Trino],Impala,Athenaなどの多様なエンジンがHive互換のカタログとして利用できるようになった.この統一メタデータ基盤は,エンジンの多様化と相互運用性を支える鍵となった.
しかし,Hive Metastoreは静的スキーマモデルに依存しており,スキーマ進化[Schema Evolution],バージョン管理,スナップショット分離,ACIDトランザクション,タイムトラベル,マルチエンジン並行性といった現代的ニーズに応えるには限界があった.これらの課題に応じて,Apache Iceberg,Delta Lake,Apache Hudiといった新しいテーブルフォーマット[Table Format]が登場し,それぞれが高度なメタデータ管理機構を内包した.
Icebergでは,テーブルの全体像がテーブルメタデータ,スナップショット,マニフェストリスト,マニフェストファイル,データファイルという階層的なメタデータ構造として明示的に管理される.テーブルメタデータにはスキーマ,パーティション仕様,ソート順序が含まれ,スナップショットは特定の時点でのテーブル状態を表し,マニフェストリストはスナップショットに含まれるマニフェストファイルの一覧を管理し,マニフェストファイルは実際のデータファイルの詳細情報[パス,行数,カラム統計など]を保持する.この構造は,ファイルシステム上にJSON[メタデータ]やAvro形式[マニフェスト]として保存され,カタログ層から論理的に参照される.
Icebergにおいて,カタログは「テーブル名→メタデータファイルの場所」へのマッピングを提供する役割を担う.カタログの実装には,既存のHive Metastoreを拡張したもの,AWS Glue Data Catalog,Nessie,REST Catalogがあり,特にREST CatalogはHTTPベースのAPIにより言語非依存な操作性とエンジン間の統一的なインターフェースを可能にする.REST Catalogを実装する代表例がApache Software Foundationによって開発されたApache Polarisである[元々はSnowflake Labsが開発].PolarisはIceberg仕様に完全準拠し,テーブルの作成,削除,スキーマ更新,スナップショットの取得といった操作をRESTfulに提供するとともに,マルチテナント対応と細粒度のアクセス制御を実現する.これにより,Spark,Trino,Flink,Starburst Galaxyなど異なるエンジンから同一のカタログを利用した一貫性のある読み書きが可能となる.
現代のData Lakehouseアーキテクチャにおいて,カタログは単なるメタデータの格納庫にとどまらず,データガバナンス,スキーマの互換性管理,変更追跡,セキュリティ,アクセス制御,データ系譜[Data Lineage]の追跡を包括的に取り扱う統治機構として位置づけられている.エンジンの多様化,データガバナンスの要求強化,マルチクラウド環境の複雑性,リアルタイム処理とバッチ処理の統合に応じて,カタログの設計も継続的に進化してきた.
Mathematics is the language with which God has written the universe.