Lakehouse の仕組み

Lakehouse for Apache Iceberg の技術アーキテクチャは、メタデータ管理を一元化し、特定のパスでクエリを処理することで、エンジン間の相互運用をサポートします。

アーキテクチャ

Google Cloud の Lakehouse は、次の技術コンポーネントで構成されています。

  • ストレージ: Cloud Storage と BigQuery ストレージがストレージ レイヤとして機能します。Cloud Storage で高性能で相互運用可能なストレージを実現するには、Apache Iceberg をオープン テーブル形式として使用することをおすすめします。

  • カタログ: Lakehouse ランタイム カタログは、メタデータを管理するための信頼できる唯一の情報源を提供します。Apache Iceberg REST カタログ エンドポイントなど、さまざまな互換性オプションを使用して、複数のエンジン間でメタデータの検出を一元化します。テーブルをカタログに登録すると、ビジネス メタデータ Knowledge Catalog にエントリが自動的に登録されます。

  • クエリエンジン: BigQuery とオープンソース エンジン（Apache Spark、Apache Flink、Trino など）は、Lakehouse ランタイム カタログに接続することでシームレスに相互運用できます。Managed Service for Apache Spark などのコンピューティング エンジンは、実行の最適化によりオープンソースの Apache Spark を活用して、ワークロードの移植性を確保し、ベンダー ロックインを回避します。

  • ガバナンス: Knowledge Catalog は、レイクハウス全体で一元化されたセキュリティ、リネージ、ガバナンス ポリシーを提供します。

  • データの書き込みと分析ツール: 統合されたエンジンとツールは、データの取り込みと分析に複数のパスを提供し、データ サイエンティストとアナリストの両方に対して一貫したデータアクセスを保証します。

リソース階層

Google Cloud の Lakehouse は、Apache Iceberg 標準と標準データベースのコンセプトに沿った階層を使用してデータを整理します。この構造により、Lakehouse ランタイム カタログは論理 ID を物理ストレージ パスにマッピングできます。このリソース階層を操作してクエリエンジンをカタログに接続するには、以下で説明するように特定のエンドポイントを使用します。

  1. Lakehouse ランタイム カタログ: メタデータをホストする Google Cloud の最上位の リージョン サービス リソース。クエリエンジンをこのサービスに接続して基盤となるカタログを管理するには、Apache Iceberg REST カタログ エンドポイントなどの特定のカタログ エンドポイントを使用してクライアント アプリケーションを構成します。
  2. カタログ: ランタイム カタログ サービス内の論理コンテナ。Project/Catalog/Namespace/Table（P.C.N.T）の命名構造では、クエリを実行する特定のカタログ インスタンスを表します。
  3. 名前空間: カタログ内のテーブルの論理グループ。 BigQuery に慣れているユーザーにとって、名前空間は機能的に データセットと似ています。
  4. テーブル: Cloud Storage 内のデータを指す特定のエンティティ。テーブル メタデータには、スキーマ、パーティショニング情報、Apache Iceberg metadata.json ファイルを介した現在のテーブル状態へのポインタが含まれます。

サポートされているエンドポイント

Lakehouse ランタイム カタログには、Cloud Storage と BigQuery 間でデータを接続するためのエンドポイントがいくつか用意されています。

  • Apache Iceberg REST カタログ エンドポイント: Apache Spark、Apache Flink、Trino などのオープンソース エンジンとの幅広い互換性を実現する標準の REST インターフェース を提供します。これは新しいワークロードにおすすめのインターフェースで、読み取りと書き込みの完全な相互運用性を提供します。

  • BigQuery エンドポイント用のカスタム Apache Iceberg カタログ: エンジンが BigQuery カタログと直接相互運用できるようにします。このインターフェースは、主に BigQuery で管理される Apache Iceberg テーブル と、 Lakehouse アーキテクチャに移行する既存のワークロードに使用されます。

  • Apache Hive カタログ エンドポイント: Apache Hive メタストア（HMS）インターフェースに依存するオープンソース ワークロードとの互換性を提供します。これにより、 でフルマネージドのメタストア サービスに対して Apache Hive または Spark ワークロードを実行できます。 Google Cloud

Lakehouse ランタイム カタログ

リソース階層内では、Lakehouse ランタイム カタログ は の最上位のリージョン メタデータ サービスとして機能します Google Cloud。個々のカタログ インスタンスをホストするルート コンテナとして機能し、異なるクエリエンジン間でメタデータの検出を一元化します。

主な機能、 サポートされているエンジン、エンドポイント構成、制限事項など、メタストア サービスの詳細については、Lakehouse ランタイム カタログについてをご覧ください。

カタログ

カタログは、単一の Cloud Storage ウェアハウス バケットに支えられた論理メタストア コンテナです。Project.Catalog.Namespace.Table（P.C.N.T）の命名構造では、カタログはオープン テーブル メタデータをクエリエンジンに接続する一意のメタストア インスタンスを表します。

カタログの主な特徴は次のとおりです。

  • ストレージの関連付け: 1 つのカタログを 1 つの Cloud Storage バケットにのみ関連付けることができます。
  • リージョン レプリケーション: カタログのリージョンは、基盤となる Cloud Storage バケットのリージョンと自動的に一致します。
  • アクセス委任: 管理者は、カタログで認証情報ベンダーを有効にしてアクセスを委任できます。これにより、ユーザーにバケットの直接権限を付与する代わりに、有効期間の短い、範囲が限定された認証情報を自動生成できます。

名前空間

名前空間は、カタログ内のテーブルの論理グループであり、データベース、スキーマ、BigQuery データセットと同様に機能します。テーブルのアクセス制御を整理して管理するための構造を提供します。

名前空間の主な特徴は次のとおりです。

  • リージョン: 名前空間を作成すると、親カタログと同じリージョンが自動的に使用されます。
  • ネストの制限: ネストされた名前空間（サブ名前空間）はサポートされていません。
  • セキュリティ境界: 名前空間レベルで IAM ロールを付与して、その名前空間に含まれるすべてのテーブルへのアクセスを管理できます。

テーブル

Google Cloud の Lakehouse を使用して構築する場合、次のテーブルタイプから選択できます。

Lakehouse ランタイム カタログでサポートされているテーブル

推奨

  • Apache Iceberg テーブル: オープンソース エンジンから作成され、Cloud Storage に保存される Apache Iceberg テーブル。Lakehouse ランタイム カタログ REST エンドポイントを介して、オープンな互換性と管理を提供します。

BigQuery でサポートされているテーブル

  • Apache Iceberg テーブル: BigQuery によって作成および管理される Apache Iceberg テーブル。これらのテーブルのメタデータは BigQuery カタログに保存され、テーブルデータと物理メタデータは Cloud Storage に保存されます。
  • ネイティブ テーブル: BigQuery によって完全に管理されるテーブル。Lakehouse ランタイム カタログに接続して、オープンソース エンジンとの相互運用を可能にできます。
  • 外部テーブル: Lakehouse ランタイム カタログの外部にあるテーブル。データとメタデータは自己管理されます。Cloud Storage、Amazon S3、Azure Blob Storage に保存されたデータの接続を介して、アクセス権の委任をサポートします。

これらのオプションの詳細な比較については、テーブルの概要をご覧ください。

サポートされているテーブル形式

Apache Iceberg V2 テーブルのみがサポートされています。Iceberg V1 テーブルはサポートされていません。既存の Iceberg V1 テーブルがある場合は、Lakehouse for Apache Iceberg で使用する前に、V2 にアップグレードする必要があります（たとえば、ALTER TABLE catalog.schema.table SET TBLPROPERTIES ('format-version'='2'); を実行するか、同様のエンジン オペレーションを使用します）。

クエリ処理シーケンス

Google Cloud の Lakehouse テーブルにクエリを送信すると、リクエストは特定のパスをたどって、データが処理される前にポリシーを適用し、メタデータを取得します。

  1. 送信: Apache Spark、Trino、BigQuery などの互換性のあるエンジンに SQL クエリを送信します。
  2. メタデータ リクエスト: エンジンは、テーブルとそのメタデータの場所を特定するために、Lakehouse ランタイム カタログからテーブル メタデータをリクエストします。
  3. 承認: 使用しているエンドポイントで サポートされている場合、カタログは Identity and Access Management（IAM）ときめ細かいセキュリティ ポリシーに対してリクエストを検証します。
  4. メタデータ レスポンス: カタログはメタデータを返します。認証情報ベンダーが有効になっている場合は、安全なストレージ アクセスに役立つ有効期間の短いトークンも提供します。
  5. データ取得: エンジンはメタデータとオプションのトークンを使用して、Cloud Storage からデータファイルを直接読み取ります。
  6. 実行: エンジンはデータを処理して結果を返します。

ベスト プラクティス

Google Cloud でデータ レイクハウスを設計して運用する場合は、次のベスト プラクティスを検討してください。

  • メダリオン アーキテクチャを採用する: データ ウェアハウスを段階的な論理レイヤに構造化します（ブロンズは未加工の取り込み、シルバーはクレンジングおよび適合化されたデータ、ゴールドはキュレートされたビジネスレベルの集計）。ゴールドの消費レイヤには BigQuery を使用して、クエリ パフォーマンスと同時実行性を最大化します。
  • インタラクティブ ワークロードにセッション テンプレートを使用する: 探索的分析とノートブック作成には、セッション テンプレートを使用して開発チーム全体で環境構成を標準化し、繰り返しの設定を減らします。
  • カスタム バッチ ID を割り当てる: 非インタラクティブなサーバーレス Apache Spark バッチ ワークロードを送信する場合は、カスタム バッチ名とジョブ名を割り当てます。これによりオブザーバビリティが向上し、Cloud Logging と Google Cloud コンソール内でジョブの実行をフィルタして追跡しやすくなります。
  • 診断ロギングを有効にする: 複雑なデータ エンジニアリング パイプラインの場合は、診断バンドルを有効にして、トラブルシューティングとサポートを簡素化するためにドライバとエグゼキュータのログが保持されるようにします。

次のステップ