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 つのレイヤで構成されます。
カタログ レイヤ:
- Iceberg のコアコンセプト: カタログは、最新のメタデータ ファイルへのポインタを維持することで、テーブルの現在の状態を保存します。このレイヤは、ACID 準拠とトランザクション分離を容易にし、同時書き込みが相互に干渉しないようにします。
- レイクハウスの実装: レイクハウス ランタイム カタログは、最上位のリージョン メタストア サービスとして機能します。このサービス内で、個々のカタログを作成してデータ階層を管理します。クライアント クエリエンジンは、Apache Iceberg REST カタログ エンドポイントなどの特定のエンドポイント カタログ タイプを使用して、これらのカタログに接続します。メタストアは、カタログ間のトランザクション コミット、ストレージ アクセス委任の認証情報ベンディング、ポインタ管理を管理します。
メタデータ レイヤ:
- Iceberg のコアコンセプト: このレイヤは、3 つのファイルタイプの階層を使用して、テーブル構造、スナップショット、ファイル ロケーションを追跡します。
- メタデータ ファイル: テーブルのスキーマ、パーティション仕様、スナップショット ポインタのログを保存します。
- マニフェスト リスト: マニフェスト ファイルのコレクションをグループ化して、テーブルの単一のスナップショットを表します。
- マニフェスト ファイル: 個々のファイルレベルでデータを追跡し、ファイルパス、パーティション情報、列レベルの統計情報（行数、最小値、最大値など）を保存します。これらは、クエリの最適化とパーティションのプルーニングに使用されます。
- レイクハウスの実装: カタログ コンテナ内で、データを論理的な名前空間（データセットに類似）とテーブルに整理します。各テーブルについて、レイクハウス ランタイム カタログは、マニフェスト リストとマニフェスト ファイルを指すルート
metadata.jsonファイルから始まる、基盤となる Iceberg メタデータ階層を生成して管理します。レイクハウス ランタイム カタログは、これらのファイルを指定されたウェアハウス ストレージの場所に直接保持します。
- Iceberg のコアコンセプト: このレイヤは、3 つのファイルタイプの階層を使用して、テーブル構造、スナップショット、ファイル ロケーションを追跡します。
データレイヤ:
- Iceberg のコア コンセプト: このコンポーネントは、実際の未加工データレコードが存在する基盤となるストレージです。通常、Parquet、ORC、Avro などの最適化された列ベースまたは行ベースのオープン ファイル形式で保存されます。
- Lakehouse の実装: Cloud Storage バケット（
gs://）をデータ ウェアハウスの保存場所として構成すると、テーブルで参照される物理データファイルがバケット内に安全に保存されます。Lakehouse ランタイム カタログは、ストレージ アクセス委任（認証情報のベンディング）を通じてアクセスを管理し、クライアント エンジンに有効期間の短いアクセス トークンを直接ベンディングします。これにより、エンジンは基盤となるバケットに対する広範な直接 IAM 権限を必要とせずに、データファイルを安全に読み書きできます。
クエリエンジンの互換性と構成
Lakehouse ランタイム カタログ内のデータを分析して管理するには、さまざまなオープンソースとエンタープライズ クエリエンジンを接続できます。既存のアーキテクチャとワークロードの要件に応じて、サポートされている複数のエンジンから選択し、適切なカタログ エンドポイントを構成できます。
サポートされているエンジン
レイクハウス ランタイム カタログは、Apache Spark、Apache Flink、Apache Hive、Trino などの複数のクエリ エンジンと互換性があります。次の表に、各エンジンのドキュメントへのリンクを示します。
| エンジン | ドキュメント |
|---|---|
| Apache Spark | クイックスタート: Spark と Iceberg REST カタログ エンドポイントで使用する |
| Apache Hive | Spark と Hive カタログで使用する |
| Apache Flink | Apache Flink で使用する |
| Trino | Trino で使用する |
カタログのタイプとエンドポイントの構成
Lakehouse ランタイム カタログのメタストアに接続するようにクライアント エンジンを構成する場合は、カタログ エンドポイント（Apache Iceberg REST カタログ エンドポイントや Apache Hive エンドポイントなど）を選択します。次の表に示すように、最適なオプションはユースケースによって異なります。
| ユースケース | 推奨事項 |
|---|---|
| オープンソース エンジンで Cloud Storage のデータにアクセスし、BigQuery や AlloyDB for PostgreSQL などの他のエンジンとの相互運用性を必要とする新しい Lakehouse ランタイム カタログ ユーザー。 | Apache Iceberg REST カタログ エンドポイントを使用します。 |
| Hive Metastore インターフェースに依存する Apache Hive または Spark ワークロードを実行しており、フルマネージドのメタストア サービスを必要とするユーザー。 | Apache Hive カタログ エンドポイントを使用します。 |
| BigQuery エンドポイント用のカスタム Apache Iceberg カタログで作成された現在のテーブルがある既存の Lakehouse ランタイム カタログ ユーザー。 | BigQuery エンドポイント用のカスタム Apache Iceberg カタログを引き続き使用しますが、新しいワークフローには Apache Iceberg REST カタログを使用します。BigQuery エンドポイント用のカスタム Apache Iceberg カタログで作成されたテーブルは、BigQuery カタログ フェデレーションを介して Apache Iceberg REST カタログ エンドポイントで表示されます。 |
Lakehouse ランタイム カタログの制限事項
Lakehouse ランタイム カタログのテーブルには次の制限が適用されます。
テーブルの管理
- Apache Iceberg V2 テーブルのみがサポートされています。Iceberg V1 テーブルはサポートされていません。既存の Iceberg V1 テーブルがある場合は、Lakehouse ランタイム カタログで使用する前に、V2 にアップグレードする必要があります（
ALTER TABLE catalog.schema.table SET TBLPROPERTIES ('format-version'='2');の実行や同様のエンジン オペレーションの使用など）。 - BigQuery データ定義言語（DDL）ステートメントまたはデータ操作言語（DML）ステートメントを使用して、Apache Iceberg REST カタログ エンドポイントでテーブルを作成または変更することはできません。これらのテーブルは BigQuery API（bq コマンドライン ツールまたはクライアント ライブラリを使用）を使用して変更できますが、外部エンジンと互換性のない変更が行われる可能性があります。
- Lakehouse ランタイム カタログのテーブルは、名前変更オペレーションや
ALTER TABLE ... RENAME TOSpark 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 カタログのエンドポイントについて理解する。