アイスバーグカタログ：データエンジニア向けガイド

チュートリアル
AWS

Apache Icebergは柔軟性と拡張性を持つ大規模データセットの管理において人気の高い選択肢となっています。Icebergの機能の中心となるのがカタログであり、テーブルの組織、整合性、およびメタデータ管理には不可欠です。本記事では、Icebergカタログとは何か、さまざまな実装方法、ユースケース、および構成について探究し、異なるユースケースに最適なカタログソリューションの理解を提供します。

Icebergカタログとは何ですか？

Icebergにおいて、カタログはテーブルパスを管理し、テーブルの状態を表す現在のメタデータファイルを指し示す責任があります。このアーキテクチャは重要であり、すべてのリーダーとライターが同じテーブルの状態にアクセスすることを確実にすることで、原子性、整合性、および効率的なクエリを実現します。異なるカタログの実装では、このメタデータをファイルシステムから専門のメタストアサービスまでさまざまな方法で保存します。

Icebergカタログの主な責務

Icebergカタログの基本的な責務は次のとおりです：

  1. テーブルパスのマッピング：テーブルパス（例：”db.table”）を対応するメタデータファイルにリンクすること。
  2. 原子操作のサポート：同時読み書き中でも一貫したテーブル状態を確保すること。
  3. メタデータ管理：メタデータの保存と管理を行い、アクセス可能性と整合性を確保すること。

アイスバーグカタログは、さまざまなシステムアーキテクチャやストレージ要件に対応する多様な実装を提供します。これらの実装と、異なる環境に対する適合性を検討してみましょう。


アイスバーグカタログの種類

1. Hadoopカタログ

「Hadoopカタログ」は、通常、セットアップが最も簡単で、ファイルシステムのみを必要とします。このカタログは、ファイルのタイムスタンプに基づいてテーブルのディレクトリ内の最新のメタデータファイルを参照することでメタデータを管理します。ただし、ファイルレベルの原子操作に依存しているため（S3のような一部のストレージシステムにはその機能が欠けています）、同時書き込みが一般的な本番環境には適さない可能性があります。

設定例

HadoopカタログをApache Sparkで構成するには：

SQL

 

スパークジョブ自体でカタログを設定する別の方法：

SQL

 

上記の例では、カタログ名を「local」と設定しました。これはスパークの「spark.sql.catalog.local」に設定されているものです。これはお好みの名前にすることができます。

利点：

  • シンプルなセットアップ、外部メタストアは不要。
  • 開発およびテスト環境に最適。

欠点：

  • 単一のファイルシステムに制限（例：単一のS3バケット）。
  • 本番環境には推奨されません。

2. Hiveカタログ

ハイブカタログは、メタデータの場所を管理するためにHiveメタストアを活用しており、多くのビッグデータツールとの互換性があります。このカタログは、既存のHiveベースのインフラストラクチャとの統合や複数のクエリエンジンとの互換性から、広く生産環境で使用されています。

設定例

SparkでHiveカタログを使用するには：

SQL

 

利点：

  • 既存のビッグデータツールとの高い互換性。
  • オンプレミスとクラウドのセットアップにおいてクラウドに依存せず柔軟。

欠点：

  • Hiveメタストアの維持が必要で、運用の複雑さが増す可能性があります。
  • テーブル間の操作の原子性を制限するマルチテーブルトランザクションのサポートが欠如しています。

3. AWS Glueカタログ

AWS Glueカタログは、AWSが提供する管理されたメタデータカタログで、AWSエコシステムに多く投資している組織に最適です。これは、IcebergテーブルのメタデータをAWS Glue内のテーブルプロパティとして処理し、他のAWSサービスとのシームレスな統合を可能にします。

設定例

AWS GlueをIcebergと共にSparkで設定するには：

SQL

 

利点：

  • 管理されたサービスで、インフラストラクチャとメンテナンスの負荷を軽減します。
  • AWSサービスとの強力な統合。

欠点：

  • AWS特有であり、クロスクラウドの柔軟性が制限されます。
  • マルチテーブルトランザクションのサポートがありません。

4. プロジェクトネッシーカタログ

プロジェクトネッシーは「データをコードとして」扱うアプローチを提供し、データのバージョン管理を可能にします。Gitのようなブランチとタグ機能を備え、ネッシーはユーザーがソースコードに似た方法でデータブランチを管理できるようにします。これは、複数のテーブルと複数のステートメントのトランザクションのための堅牢なフレームワークを提供します。

設定例

ネッシーをカタログとして構成するには：

SQL

 

利点：

  • バージョン管理機能を持つ「データをコードとして」提供します。
  • 複数テーブルのトランザクションをサポートします。

欠点：

  • セルフホスティングが必要で、インフラの複雑さが増します。
  • HiveやAWS Glueと比べてツールのサポートが限られています。

5. JDBCカタログ

JDBCカタログは、PostgreSQLやMySQLのようなJDBC準拠のデータベースにメタデータを保存することを可能にします。このカタログはクラウドに依存せず、信頼性のあるRDBMSシステムを使用することで高可用性を確保します。

設定例

SQL

 

利点：

  • 既存のRDBMSインフラで簡単に設定できます。
  • 高可用性でクラウドに依存しません。

欠点：

  • 複数テーブルのトランザクションをサポートしていません。
  • すべてのアクセスツールに対してJDBCドライバへの依存が増えます。

6. スノーフレークカタログ

SnowflakeはApache Icebergテーブルの堅牢なサポートを提供し、ユーザーがSnowflakeのプラットフォームをIcebergのカタログとして活用できます。この統合によりSnowflakeのパフォーマンスとクエリセマンティクスがIcebergのオープンテーブル形式の柔軟性と組み合わさり、外部クラウドストレージに保存された大規模なデータセットの効率的な管理が可能です。詳細な構成については、Snowflakeのドキュメントを参照してください：link

メリット:

  • シームレスな統合: Snowflakeのパフォーマンスとクエリ機能をIcebergのオープンテーブル形式と組み合わせることで、効率的なデータ管理が容易になります。
  • 完全なプラットフォームサポート: ACIDトランザクション、スキーマの進化、タイムトラベルなどの機能を備え、包括的な読み取りおよび書き込みアクセスを提供します。
  • 簡素化されたメンテナンス: Snowflakeはコンパクションや運用オーバーヘッドの削減などのライフサイクルタスクを処理します。

デメリット:

  • クラウドおよびリージョンの制約: 外部ボリュームはSnowflakeアカウントと同じクラウドプロバイダーおよびリージョンにある必要があり、クロスクラウドまたはクロスリージョンの構成が制限されます。
  • データ形式の制限: Apache Parquetファイル形式のみをサポートし、すべての組織のデータ形式の選択と一致しない可能性があります。
  • サードパーティクライアントの制限: サードパーティクライアントがSnowflake管理のIcebergテーブル内のデータを変更するのを防ぎ、外部ツールに依存するワークフローに影響を及ぼす可能性があります。

7. RESTベースのカタログ

Icebergは、従来のカタログ実装に関連するいくつかの課題に対処するためにRESTベースのカタログをサポートしています。

従来のカタログに関する課題

  1. クライアント側の複雑さ: 従来のカタログは、各プログラミング言語（Java、Python、Rust、Go）に対してクライアント側の設定や依存関係を必要とすることが多く、異なるプログラミング言語や処理エンジン間での不整合を引き起こす可能性があります。詳細については、こちらをご覧ください。
  2. スケーラビリティの制約: クライアントレベルでメタデータやテーブル操作を管理することはボトルネックを引き起こし、大規模データ環境におけるパフォーマンスやスケーラビリティに影響を与える可能性があります。

RESTカタログの採用の利点

  • クライアント統合の簡素化: クライアントは標準のHTTPプロトコルを使用してRESTカタログと対話できるため、複雑な設定や依存関係が不要になります。
  • スケーラビリティ: RESTカタログのサーバーサイドアーキテクチャは、成長するデータセットや同時アクセスパターンに対応するスケーラブルなメタデータ管理を可能にします。
  • 柔軟性: 組織は、クライアントアプリケーションを変更せずに特定の要件を満たすようにRESTカタログをカスタマイズするためのカスタムカタログロジックをサーバーサイドに実装できます。

RESTカタログの複数の実装が登場しており、それぞれが特定の組織のニーズに対応しています:

  • Gravitino: Sparkや他の処理エンジンとの統合を容易にするオープンソースのIceberg RESTカタログサービスで、Icebergテーブルを管理するための簡単なセットアップを提供します。
  • Tabular: Icebergの機能を活用するためのRESTカタログインターフェースを提供するマネージドサービスで、カタログインフラストラクチャを管理する手間を省くことができます。詳細はこちらをご覧ください。
  • Apache Polaris: Apache Iceberg向けのオープンソースの完全機能を備えたカタログで、REST APIを実装して、Apache Doris、Apache Flink、Apache Spark、StarRocks、Trinoなどのプラットフォーム間でシームレスなマルチエンジンの相互運用性を確保しています。詳細はGitHubをご覧ください。

Icebergテーブルを使用してRESTカタログを試すための私のお気に入りでシンプルな方法の1つは、プレーンなJava REST実装を使用することです。GitHubのリンクはこちらをご覧ください。

結論

適切なApache Icebergカタログを選択することは、データ管理戦略を最適化するために重要です。ここに、決定をガイドする簡潔な概要をご紹介します:

  • Hadoopカタログ: シンプルさから開発およびテスト環境に最適です。ただし、本番シナリオでは同時書き込みによる整合性の問題が発生する可能性があります。
  • Hiveメタストアカタログ: 既存のHiveインフラストラクチャを持つ組織に最適です。さまざまなビッグデータツールとの互換性を提供し、複雑なデータ操作をサポートします。ただし、Hiveメタストアサービスの維持には運用上の複雑さが伴う場合があります。
  • AWS Glueカタログ: AWSエコシステムに大きな投資をしている方に最適です。AWSサービスとのシームレスな統合を提供し、自己管理型メタデータサービスの必要性を低減します。ただし、AWS固有のため、クロスクラウドの柔軟性が制限される可能性があります。
  • JDBCカタログ: メタデータストレージに関係データベースを好む環境に適しており、任意のJDBC準拠データベースの使用を可能にします。これにより柔軟性が提供され、既存のRDBMSインフラストラクチャを活用しますが、追加の依存関係を導入し、データベース接続の注意深い管理が必要となる場合があります。
  • RESTカタログ: カタログ操作に標準化されたAPIが必要なシナリオに最適です。さまざまな処理エンジンや言語間の相互運用性を向上させ、クライアントからカタログの実装の詳細を分離しますが、カタログ操作を処理するためのRESTサービスの設定が必要であり、初期設定の複雑さが追加される場合があります。
  • プロジェクトネッシーカタログ：これはGitに類似したデータのバージョン管理が必要な組織に最適です。ブランチ、タグ付け、マルチテーブルトランザクションをサポートしています。堅牢なデータ管理機能を提供しますが、Nessieサービスの展開と管理が必要で、運用上のオーバーヘッドが発生する可能性があります。

これらのカタログオプションとそれらの構成について理解することで、情報を元に適切な選択を行い、組織固有のニーズを満たすためにデータレイクまたはレイクハウスのセットアップを最適化できます。

Source:
https://dzone.com/articles/iceberg-catalogs-a-guide-for-data-engineers