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

次のステップ