Lakehouse の仕組み

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

アーキテクチャ

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

  • ストレージ: Cloud Storage と BigQuery ストレージがストレージ レイヤとして機能します。Cloud Storage での高性能で相互運用可能なストレージには、Apache Iceberg が推奨されるオープン テーブル形式です。

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

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

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

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

リソース階層

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

  1. Lakehouse ランタイム カタログ: メタデータをホストする Google Cloud の最上位のリージョン サービス リソース。クエリエンジンをこのサービスに接続して基盤となるカタログを管理するには、Apache Iceberg REST カタログ エンドポイントなどの特定のカタログ エンドポイントを使用してクライアント アプリケーションを構成します。
  2. カタログ: ランタイム カタログ サービス内の論理コンテナ。プロジェクト/カタログ/名前空間/テーブル（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 テーブルと、レイクハウス アーキテクチャに移行する既存のワークロードに使用されます。

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

Lakehouse ランタイム カタログ

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

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

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

カタログ

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

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

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

名前空間

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

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

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

テーブル

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

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

推奨

  • Apache Iceberg テーブル: オープンソース エンジンから作成され、Cloud Storage に保存されている Apache Iceberg テーブル。これらは、Lakehouse ランタイム カタログの REST エンドポイントを介して、オープンな互換性と管理を提供します。2 つのテーブルが同じ場所を占有しないようにするには、カスタム テーブルパスを親名前空間パスの下にネストする必要があります。結果のテーブルの場所には、競合を防ぐためにランダムな文字列の接尾辞が自動的に付加されます。

    サポートされている表の形式

    Apache Iceberg V2 テーブル（一般提供版）と V3 テーブル（プレビュー版）がサポートされています。Iceberg V1 テーブルはサポートされていません。Lakehouse for Apache Iceberg で既存の V1 テーブルを使用する前に、サポートされているバージョンにアップグレードする必要があります。詳細については、Iceberg V1 テーブルを V2 にアップグレードするをご覧ください。

BigQuery でサポートされている

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

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

クエリ処理の順序

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 をゴールド消費レイヤに使用して、クエリのパフォーマンスと同時実行性を最大化します。
  • インタラクティブ ワークロードにセッション テンプレートを使用する: 探索的分析とノートブック作成には、セッション テンプレートを使用して、開発チーム全体で環境構成を標準化し、繰り返し設定を減らします。
  • カスタム バッチ識別子を割り当てる: 非インタラクティブなサーバーレス Apache Spark バッチ ワークロードを送信するときに、カスタム バッチ名とジョブ名を割り当てます。これにより、オブザーバビリティが向上し、Cloud Logging と Google Cloud コンソール内でジョブ実行をフィルタして追跡できます。
  • 診断ロギングを有効にする: 複雑なデータ エンジニアリング パイプラインの場合は、診断バンドルを有効にして、トラブルシューティングとサポートに役立つように、ドライバとエグゼキュータのログが保持されるようにします。

次のステップ