Lakehouse ランタイム カタログについて

Lakehouse for Apache Iceberg は、Google Cloud上のマネージド データ レイクハウス プラットフォームです。このプラットフォーム内では、Lakehouse ランタイム カタログがフルマネージドのサーバーレス メタストア サービスとして機能します。データ レイクハウスの信頼できる唯一の情報源を提供し、Apache Spark、Apache Flink、Apache Hive、BigQuery などの複数のエンジンがファイルをコピーせずにテーブルとメタデータを共有できるようにします。

クエリエンジンをメタストアに接続するには、Apache Iceberg REST カタログ エンドポイントなどの特定のカタログ タイプを使用してクライアントを構成します。このエンドポイントは、テーブル メタデータを管理し、Cloud Storage バケットでサポートされているストレージ ロケーション ウェアハウスを使用して、基盤となるメタデータとデータファイルを保存します。カタログ タイプの選択の詳細については、カタログ タイプとエンドポイント構成をご覧ください。

Lakehouse ランタイム カタログは、ストレージ アクセス委任（認証情報ベンディングとも呼ばれます）をサポートしています。これにより、Cloud Storage バケットへの直接アクセスが不要になり、セキュリティが強化されます。また、統合されたガバナンス、リネージ、データ品質を実現するために Knowledge Catalog と統合されています。テーブルが Lakehouse ランタイム カタログに登録されると、対応するエントリがビジネス メタデータ カタログ（ナレッジ カタログ）に自動的に登録され、ファイルを移動またはコピーすることなく、一貫したデータ検出とガバナンスが保証されます。

主な機能

Lakehouse for Apache Iceberg の主要コンポーネントであるレイクハウス ランタイム カタログは、サーバーレス アーキテクチャ、オープン API によるエンジン相互運用性、統合されたユーザー エクスペリエンス、BigQuery との併用による高性能な分析、ストリーミング、AI など、データ管理と分析にいくつかのメリットをもたらします。これらのメリットの詳細については、Lakehouse とはをご覧ください。

Lakehouse と Google Cloudの統合方法

Lakehouse がデータを管理する方法については、Lakehouse for Apache Iceberg アーキテクチャが Google Cloud サービスと統合される仕組みをご覧ください。Apache Iceberg は、データをモノリシック テーブルに保存しません。代わりに、メタデータ ファイルのレイヤード アーキテクチャを使用して、データファイルを ACID トランザクションをサポートするまとまりのあるテーブル構造に整理します。

次の図は、Managed Service for Apache Spark などのコンピューティング エンジンが Lakehouse ランタイム カタログを使用してテーブル メタデータを管理し、Cloud Storage で基盤となる Parquet データファイルを直接読み書きする方法を示しています。

Lakehouse for Apache Iceberg を使用する場合、技術アーキテクチャは次の 3 つのレイヤで構成されます。

1. カタログ レイヤ:

   • Iceberg のコアコンセプト: カタログは、最新のメタデータ ファイルへのポインタを維持することで、テーブルの現在の状態を保存します。このレイヤは、ACID 準拠とトランザクション分離を容易にし、同時書き込みが互いに干渉しないようにします。
   • Lakehouse の実装: Lakehouse ランタイム カタログは、最上位のリージョン メタストア サービスとして機能します。このサービス内で、個々のカタログを作成してデータ階層を管理します。クライアント クエリエンジンは、Apache Iceberg REST カタログ エンドポイントなどの特定のエンドポイント カタログ タイプを使用して、これらのカタログに接続します。メタストアは、トランザクションの commit、ストレージ アクセス委任の認証情報の提供、カタログ間のポインタ管理を行います。

2. メタデータ レイヤ:

   • Iceberg のコアコンセプト: このレイヤは、3 つのファイルタイプの階層を使用して、テーブル構造、スナップショット、ファイル ロケーションを追跡します。
     • メタデータ ファイル: テーブルのスキーマ、パーティション仕様、スナップショット ポインタのログを保存します。
     • マニフェスト リスト: マニフェスト ファイルのコレクションをグループ化して、テーブルの単一のスナップショットを表します。
     • マニフェスト ファイル: 個々のファイルレベルでデータを追跡し、ファイルパス、パーティション情報、列レベルの統計情報（行数、最小値、最大値など）を保存します。これらは、クエリの最適化とパーティションのプルーニングに使用されます。
   • Lakehouse の実装: カタログ コンテナ内で、データを論理的な名前空間（データセットと同様）とテーブルに整理します。テーブルごとに、Lakehouse ランタイム カタログは、マニフェスト リストとマニフェスト ファイルを指すルート metadata.json ファイルから始まる、基盤となる Iceberg メタデータ階層を生成して管理します。Lakehouse ランタイム カタログは、これらのファイルを指定されたウェアハウス ストレージの場所に直接保持します。

3. データレイヤ:

   • Iceberg のコア コンセプト: このコンポーネントは、実際の未加工データレコードが存在する基盤となるストレージです。通常、Parquet、ORC、Avro などの最適化された列ベースまたは行ベースのオープン ファイル形式で保存されます。
   • Lakehouse の実装: Cloud Storage バケット（gs://）をデータ ウェアハウスの保存場所として構成すると、テーブルで参照される物理データファイルがバケット内に安全に保存されます。Lakehouse ランタイム カタログは、ストレージ アクセス委任（認証情報のベンディング）を通じてアクセスを管理し、クライアント エンジンに有効期間の短いアクセス トークンを直接ベンディングします。これにより、エンジンは基盤となるバケットに対する広範な直接 IAM 権限を必要とせずに、データファイルを安全に読み書きできます。

Lakehouse で Apache Iceberg REST Catalog API を実装する方法

Lakehouse ランタイム カタログは、オープンソースの Apache Iceberg REST Catalog API を実装して、名前空間とテーブルを管理します。また、カタログ管理専用の拡張機能 API も提供します。

クライアント クエリ エンジンは、これらの標準 REST カタログ API を使用してメタストアとやり取りします。Google Cloud リソースとエンドポイントの詳細については、Lakehouse REST API リファレンスをご覧ください。

これらのリソースは、Google Cloud コンソール、gcloud CLI、REST API、または Terraform を使用して作成、構成、管理できます。詳しくは次のページをご覧ください。

• Iceberg REST カタログ リソースを管理する
• Lakehouse Iceberg REST カタログ テーブルを管理する
• Lakehouse で Terraform を使用する

クエリエンジンの互換性と構成

Lakehouse ランタイム カタログのデータを分析して管理するには、さまざまなオープンソースとエンタープライズ クエリエンジンを接続します。既存のアーキテクチャとワークロードの要件に応じて、サポートされている複数のエンジンから選択し、適切なカタログ エンドポイントを構成できます。

サポートされているエンジン

Lakehouse ランタイム カタログは、Apache Spark、Apache Flink、Apache Hive、Trino などの複数のクエリエンジンと互換性があります。次の表に、各エンジンのドキュメントへのリンクを示します。

カタログのタイプとエンドポイントの構成

Lakehouse ランタイム カタログのメタストアに接続するようにクライアント エンジンを構成する場合は、カタログ エンドポイント（Apache Iceberg REST カタログ エンドポイントや Apache Hive エンドポイントなど）を選択します。次の表に示すように、最適なオプションはユースケースによって異なります。

Lakehouse ランタイム カタログの制限事項

Lakehouse ランタイム カタログのテーブルには次の制限が適用されます。

テーブルの管理

• Apache Iceberg V2 テーブル（一般提供）と V3 テーブル（プレビュー）がサポートされています。Iceberg V1 テーブルはサポートされていません。Lakehouse ランタイム カタログで既存の V1 テーブルを使用する前に、サポートされているバージョンにアップグレードする必要があります。詳細については、Iceberg V1 テーブルを V2 にアップグレードするをご覧ください。
• BigQuery データ定義言語（DDL）ステートメントまたはデータ操作言語（DML）ステートメントを使用して、Apache Iceberg REST カタログ エンドポイントでテーブルを作成または変更することはできません。これらのテーブルは BigQuery API（bq コマンドライン ツールまたはクライアント ライブラリを使用）を使用して変更できますが、外部エンジンと互換性のない変更が行われる可能性があります。
• Lakehouse ランタイム カタログのテーブルは、名前変更オペレーションや ALTER TABLE ... RENAME TO Spark SQL ステートメントをサポートしていません。
• Lakehouse ランタイム カタログのテーブルは、クラスタリングをサポートしていません。
• Lakehouse ランタイム カタログのテーブルは、柔軟な列名をサポートしていません。
• Lakehouse ランタイム カタログは Apache Iceberg ビューをサポートしていません。

クエリ

• BigQuery エンジンの Lakehouse ランタイム カタログ内のテーブルに対するクエリのパフォーマンスは、標準的な BigQuery テーブルのデータに対するクエリよりも低速になる可能性があります。一般的に、クエリの速度は Cloud Storage からデータを読み取る処理と同等になります。
• Lakehouse ランタイム カタログのテーブルを使用するクエリの BigQuery ドライランで、行が返されても、下限 0 バイトと報告される場合があります。これは、完全なクエリが実行されるまで、テーブルから処理されるデータの量を特定できないためです。クエリを実行すると、このデータの処理に費用がかかります。
• ワイルドカード テーブルのクエリで、Lakehouse ランタイム カタログのテーブルを参照することはできません。

API とメタデータ

• tabledata.list メソッドを使用して、Lakehouse ランタイム カタログのテーブルからデータを取得することはできません。代わりに、クエリ結果を BigQuery テーブルに保存し、そのテーブルで tabledata.list メソッドを使用できます。
• Lakehouse ランタイム カタログのテーブルのテーブル ストレージ統計情報の表示はサポートされていません。

割り当てと上限

• BigQuery の Lakehouse ランタイム カタログ内のテーブルには、標準テーブルと同じ割り当てと上限が適用されます。

BigLake metastore（クラシック）との違い

Lakehouse ランタイム カタログと BigLake metastore（クラシック）の主な違いは次のとおりです。

• Lakehouse ランタイム カタログは、Spark などのオープンソース エンジンとの直接統合をサポートしているため、メタデータの保存とジョブの実行時の冗長性を軽減できます。Lakehouse ランタイム カタログのテーブルには、複数のオープンソース エンジンと BigQuery から直接アクセスできます。
• Lakehouse ランタイム カタログは Apache Iceberg REST カタログ エンドポイントをサポートしていますが、BigLake metastore（クラシック）はサポートしていません。

次のステップ

• Apache Iceberg REST カタログのエンドポイントについて理解する。