Zenn
📚

Apache Iceberg: The Definitive Guide Chapter5 Iceberg Catalogs 一部まとめ

2024/08/26に公開
DataEngineering
iceberg
tech

この記事について

SnowVillageで行われているApache Iceberg: The Definitive Guide [Book]の輪読会用にChapter5 Iceberg Catalogsの内容をまとめたものです。

要点

カタログの一般的な要件

  • Iceberg Catalogは、テーブルのリスト、作成、削除、存在確認、名前変更などの機能を実装する必要があります。
  • テーブルパスをメタデータファイルのファイルパスにマッピングすることが求められます。

本番環境での使用に推奨される追加の要件

  • 本番環境では、カタログがAtomicな操作をサポートし、同時に複数のライターがいる場合でもデータ損失を防ぐ必要があります。

さまざまなカタログの実装、利点と欠点

  1. Hadoopカタログ:

    • 利点: 外部システムが不要で、導入が簡単。
    • 欠点: 本番環境には推奨されない（データ損失のリスクあり）。

  2. Hiveカタログ:

    • 利点: 幅広いエンジンとツールとの互換性。
    • 欠点: 追加のサービスが必要で、マルチテーブルトランザクションをサポートしない。

  3. AWS Glueカタログ:

    • 利点: 管理されたサービスで、AWSサービスとの統合が強力。
    • 欠点: マルチテーブルトランザクションをサポートせず、AWSエコシステムに特化。

  4. Nessieカタログ:

    • 利点: データをコードのように管理でき、マルチテーブルトランザクションをサポート。
    • 欠点: 一部のエンジンとツールがサポートしていない。

  5. RESTカタログ:

    • 利点: 柔軟性が高く、マルチテーブルトランザクションをサポート。
    • 欠点: 自分でバックエンドサービスを運用する必要がある。

  6. JDBCカタログ:

    • 利点: 簡単に始められ、高可用性を確保しやすい。
    • 欠点: マルチテーブルトランザクションをサポートしない。

Sparkをカタログに設定する方法

  • 各カタログに対して、Spark SQLシェルを起動するための設定コードが提供されています。

カタログの移行を検討する状況

  • 実験や評価のために使用していたカタログから、本番用のカタログに移行したい場合。
  • 現在のカタログが持っていない追加機能を利用したい場合。
  • 環境の場所を変更する場合（例: オンプレミスからAWSへの移行）。

カタログから別のカタログへの移行方法

  • CLIツールを使用: Icebergカタログ移行ツールを使って、テーブルを一括移行することが可能。
  • エンジンを使用: Apache Sparkを使用して、ソースカタログとターゲットカタログを設定し、テーブルを移行する手順が提供されています。

Iceberg Catalogの一般的な要件


https://iceberg.apache.org/spec/#overview より引用

  • Icebergはcatalog interfaceを提供している
    • 既存のテーブルのリスト化、テーブルの作成、テーブルの削除、テーブルの存在確認、およびテーブルの名前変更を行うための関数群を実装する必要があるカタログインターフェース
    • このインターフェースは複数のカタログ実装によって実装されている
  • インターフェースで定義された関数を実装することに加えて、Icebergカタログとして機能するための主な高レベルの要件は、テーブルパス（例：db1.table1）を、そのテーブルの現在の状態を保持するメタデータファイルのファイルパスにマッピングすること
    • このマッピングは、カタログの実装によって異なる方法で行われる
    • Icebergカタログは、テーブルのメタデータファイルのバージョン管理や位置情報を適切にマッピングする必要があります。例えば、ファイルシステムをカタログとして使用する場合は、version-hint.textファイルにバージョン番号が記載され、Hive Metastoreを使用する場合は、metadata_locationというプロパティにメタデータファイルの場所が格納されます。

以上がIcebergカタログの一般的な要件。

本番環境での使用に推奨される要件

  • カタログが本番環境で使用されるためには、アトミック操作をサポートし、同時に複数のジョブが同じテーブルに書き込む際にデータ損失を防ぐ必要があります。これは、すべてのリーダーとライターが同じテーブルの状態を確認できるようにするために重要です。
  • 開発や実験の目的ではこの要件は必ずしも必要ではありませんが、本番環境ではデータ損失がビジネスに大きな影響を与える可能性があるため、非常に重要です。

カタログの比較

詳細な比較はIceberg カタログの概要・前提条件と、各種カタログの比較 #iceberg - Qiitaがよくまとめられている。

せっかくなので今回はとりわけ最近ホットなRESTカタログについて詳しく見ていきたい。

RESTカタログ

RESTカタログは、その名の通り、RESTfulサービスプロバイダーをIcebergカタログとして利用します。このアプローチは、RESTカタログが特定の実装ではなくインターフェースであるため、他の多くのカタログとは異なり、柔軟性が高いという興味深い特徴があります。RESTカタログインターフェースを実装するサービスは、テーブルのパスを現在のメタデータファイルにマッピングする方法を自由に選択できます。[1]


Iceberg Catalog as a Service - YouTube より

  • クライアントがRESTリクエストを送信: クライアントは、サーバー側のカタログに対してRESTリクエストを送信します。
  • サーバーの責任: サーバーは、そのリクエストに基づいてコミットを適用し、スナップショットポインタを更新する責任を負います。
  • 依存関係の最小化: カタログ固有の依存関係は、サーバー側のみで必要とされ、クライアント側には不要です。
  • 柔軟なサーバー実装: RESTカタログサーバーは、既存のIcebergカタログ実装をラップすることができ、さらに追加のサーバーサイドロジックを組み込むことも可能です。

この実装により、クライアントは軽量なRESTリクエストを介してIcebergカタログにアクセスでき、サーバー側でのカタログ操作や管理が容易になる一方で、柔軟性を持ちながら他のカタログ実装との統合も可能となります。

例えば、Catalog(Backend)の実装を頑張ることで、commitのconflictをハンドリングすることができたりする。

https://www.apachecon.com/acna2022/slides/02_Redai_Apache_Icebergs_REST.pdf より

おまけ: Snowflake Polaris Catalog

SnowVillageの輪読会なので、SnowflakeのPolaris Catalogについても触れておく。
https://polaris.io/#section/Quick-Start/Defining-a-Catalog

主要概念

  • カタログ: Iceberg テーブルを整理します。内部カタログ（Polaris によって管理）と外部カタログ（Snowflake などの他のプロバイダーによって管理）の2種類があります。内部カタログは読み書きが可能ですが、外部カタログは Polaris では読み取り専用です。

  • ネームスペース: カタログ内で Iceberg テーブルを論理的にグループ化するためのもので、ネストされた構造を持つことができます。

  • サービスプリンシパル: Polaris 内で作成されるエンティティで、カタログへの接続に使用する資格情報をカプセル化します。各サービスプリンシパルには、ユニークなクライアント ID とクライアントシークレットがあります。

  • サービス接続: Apache Spark や Snowflake などの REST 互換エンジンを表し、Polaris カタログと相互作用します。アクセスはロールベースのアクセス制御（RBAC）を通じて管理されます。

  • ストレージ構成: 外部クラウドストレージ（S3、GCS、Azure など）への接続に必要な IAM 資格情報を含みます。

セキュリティとアクセス制御

  • 資格情報の自動発行: Polaris は、クエリ実行中にクエリエンジンに一時的なストレージ資格情報を提供し、セキュリティを強化します。
  • IAM: 外部ストレージへの安全な接続を管理し、テーブルデータやメタデータへのアクセスを提供します。
  • アクセス制御: RBAC を通じて強制され、サービスプリンシパルがカタログ、ネームスペース、テーブルへのアクセスを中央で構成できるようにします。


ネストされた名前空間になっているのが特徴的

RESTカタログの将来

  • RESTカタログの次のイテレーションに関する議論を開始するために新しい提案が提出されました。この提案では多くの操作をクライアントからサーバー側に移行することを目的としているようです。カタログ実装は様々なツールでIcebergの操作を最適化することが求められると思われます。これによりカタログのより優れた拡張性が実現されると予想されます。

References

Apache Iceberg Catalog選択のポイント - Speaker Deck

Iceberg カタログの概要・前提条件と、各種カタログの比較 #iceberg - Qiita

Snowflake新機能： Iceberg Table と Polaris Catalog の仕組み

Iceberg Catalog as a Service - YouTube

Catalogs and the REST catalog – Tabular

https://www.apachecon.com/acna2022/slides/02_Redai_Apache_Icebergs_REST.pdf

脚注

  1. Catalogs and the REST catalog – Tabular ↩︎

GitHubで編集を提案

Discussion