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 for Apache Iceberg の主要コンポーネントである Lakehouse ランタイム カタログは、データ 管理と分析にいくつかのメリットをもたらします。これには、サーバーレス アーキテクチャ、オープン API を使用したエンジン 間の相互運用性、統合されたユーザー エクスペリエンス、BigQuery との併用時の高性能な 分析、ストリーミング、AI などがあります。これらのメリットについて詳しくは、Lakehouse とは をご覧ください。
サポートされているエンジン
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 アーキテクチャと 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 準拠とトランザクション分離を容易にし、同時書き込みが相互に干渉しないようにします。
- Lakehouse の実装: Lakehouse ランタイム カタログ は、最上位の リージョン メタストア サービスとして機能します。このサービス内で、個々の カタログを作成してデータ階層を管理します。クライアント クエリエンジンは、 Apache Iceberg REST カタログ エンドポイントなどの特定のエンドポイント カタログ タイプを使用して、これらのカタログに接続します。メタストアは、トランザクションのコミット、ストレージ アクセス委任の認証情報の提供、カタログ間のポインタ管理を管理します。
メタデータ レイヤ:
- Iceberg のコアコンセプト: このレイヤは、次の 3 種類のファイルの階層を使用して、テーブル構造、
スナップショット、ファイル ロケーションを追跡します:
- メタデータ ファイル: テーブルのスキーマ、パーティション仕様、 スナップショット ポインタのログを保存します。
- マニフェスト リスト: マニフェスト ファイルのコレクションを グループ化して、テーブルの単一のスナップショットを表します。
- マニフェスト ファイル: 個々のファイルレベルでデータを追跡し、 ファイルパス、パーティション情報、列レベルの統計情報（ 行数、最小値、最大値など）を保存します。これらは、 クエリの最適化とパーティションのプルーニングに使用されます。
- Lakehouse の実装: カタログ コンテナ内で、
データを論理的な 名前空間 （データセットと同様）と
テーブル に整理します。テーブルごとに、Lakehouse ランタイム カタログは、マニフェスト リストとマニフェスト ファイルを指すルート
metadata.jsonファイルから始まる、基盤となる Iceberg メタデータ階層を生成して管理します。Lakehouse ランタイム カタログは、これらのファイルを指定されたウェアハウス ストレージ ロケーションに直接保存します。
- Iceberg のコアコンセプト: このレイヤは、次の 3 種類のファイルの階層を使用して、テーブル構造、
スナップショット、ファイル ロケーションを追跡します:
データレイヤ:
- Iceberg のコアコンセプト: このコンポーネントは、 実際の未加工データ レコードが存在する基盤となるストレージです。通常、最適化された列ベースまたは 行ベースのオープン ファイル形式 (Parquet、ORC、Avro など) で保存されます。
- Lakehouse の実装: ストレージ ロケーション
ウェアハウスは、
gs://パスを持つ Cloud Storage バケットです。テーブルで参照される物理データファイルは、バケットに安全に保存されます。Lakehouse ランタイム カタログはストレージ アクセスを委任するため、クライアント エンジンは、直接的で広範な IAM バケット権限を必要とせずに、これらのデータファイルを読み書きできます。
Lakehouse ランタイム カタログの制限事項
Lakehouse ランタイム カタログのテーブルには次の制限が適用されます。
テーブル管理
- 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 カタログ エンドポイントについて理解する。