ボーダーレス Lakehouse の仕組み

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

アーキテクチャ

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

  • ストレージ: Cloud Storage と BigQuery ストレージがストレージ レイヤとして機能します。Cloud Storage での高性能で相互運用可能なストレージには、Apache Iceberg が推奨されるオープン テーブル形式です。ボーダレスな Lakehouse を使用すると、データは Google Cloudに存在する必要がなくなります。サポートされているリモート カタログにクロスクラウド接続（プレビュー）を設定すると、Amazon S3 などの他のクラウド ストレージ システムにデータを保持し、ファイルを移行したり ETL パイプラインを構築したりすることなく、データをクエリできます。

  • カタログ: 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. カタログ: ランタイム カタログ サービス内の論理コンテナ。プロジェクト/カタログ/名前空間/テーブル（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 metastore（HMS）インターフェースに依存するオープンソース ワークロードの互換性を提供します。これにより、 Google Cloudのフルマネージド メタストア サービスに対して Apache Hive または Spark ワークロードを実行できます。

Lakehouse ランタイム カタログ

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

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

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

カタログ

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

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

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

名前空間

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

Namespace の主な特徴は次のとおりです。

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

テーブル

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

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

推奨

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

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

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

BigQuery でサポートされている

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

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

クエリ処理のシーケンス

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

  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 コンソール内でジョブ実行をフィルタして追跡できます。
  • 診断ロギングを有効にする: 複雑なデータ エンジニアリング パイプラインの場合は、診断バンドルを有効にして、トラブルシューティングとサポートに役立つように、ドライバとエグゼキュータのログが保持されるようにします。

次のステップ