Google CloudがLakehouse runtime catalogの構成例を紹介、3つの外部カタログにあるデータを移行せず照会する接続手順を提示

Lakehouse runtime catalogを使う構成でできること

BigQueryとborderless Lakehouseは、オープンなApache Iceberg REST catalog仕様を基盤にしています。データを計算エンジンへ移す代わりに、Google Cloudの計算処理と生成AIをデータのある場所へ持ち込む構成です。^[1]

提供状態の指定がない構成例では、Lakehouse runtime catalogは、他のクラウドからメタデータを同期します。BigQueryや外部のオープンソースエンジンは、Apache Iceberg REST catalogエンドポイントを通じ、移行していないデータを照会できます。

図1　Lakehouse runtime catalogの構成例でできること

接続先の例は、Databricks Unity CatalogやSnowflake Horizon Catalog、AWS Glue Data Catalogです。3つともApache Iceberg REST catalog仕様に対応するため、同じ接続パターンを適用できます。

構成例では、3つの外部カタログにまたがるデータは、1つのクエリで結合できます。データを移行しないまま、BigQueryの会話型分析で自然言語を使える構成です。

フェデレーションクエリ実行時の分離

フェデレーションクエリの実行時、Lakehouse runtime catalogはメタデータの同期とストレージへのアクセスを分けます。利用者が定義した更新スケジュールに基づき、リモートのカタログからスキーマやスナップショットのポインター、テーブル定義を定期的に同期します。

図2　メタデータ同期と直接読み取りの違い

データの読み取りは、互換性のあるエンジンがAmazon S3などのリモートのオブジェクトストレージからParquetデータファイルを直接読む形です。読み取りには、リモートのプラットフォームが発行する一時的な資格情報を使います。

クエリ処理の実行場所

クエリの処理を担うのは、BigQueryやManaged Service for Apache SparkなどのGoogle Cloudの計算資源です。実行中に、リモートのDatabricksクラスターやSnowflakeの仮想ウェアハウス、AWSの計算インスタンスは呼び出されません。

図3　クエリ実行時に使われる計算資源

フェデレーションカタログの設定手順

フェデレーションカタログの認証は、3段階の手順に従います。Google Cloudでフェデレーションカタログを作成し、構成から自動生成のサービスアカウントを取得したうえで、リモートのプラットフォームでアクセス権を付与します。^[1]

接続完了には、Databricksのサービスプリンシパルに、Issuer URLがhttps://accounts.google.comのフェデレーションポリシーが必要です。Subjectはdescribeコマンドが返す数値のsubject ID、Audiencesはhttps://accounts.cloud.databricks.comです。

図4　認証の3段階と接続を完了する操作

以降は、Databricks Unity Catalogを連携先にする場合の手順を扱います。まずDatabricks側でカタログとテーブルを準備し、その後にGoogle Cloud側でカタログを作成します。

Databricks側の事前準備

Unity Catalogでの連携アクセスには、対象のスキーマとDatabricksに登録済みの外部ロケーションとの関連付けが必要です。Databricks SQL workspaceで実行するコード例の主な操作と補足は、以下の通りです。

外部エンジンがテーブルを読む前に、Databricksのメタストア管理者がメタストアの詳細タブでExternal data accessを有効にする必要があります。Databricks Service Principalは、Databricks Admin accountのUser Managementで作成し、UUIDを控えます。

フェデレーションカタログの作成

次に、gcloudコマンドラインツールを使い、Google Cloud内にフェデレーションカタログを作成します。作成には、DatabricksのワークスペースURLと、サービスプリンシパルのアプリケーションIDが必要です。

図5　カタログ作成コマンドの主な指定

作成コマンドの例は、次の通りです。

export GCP_PROJECT_ID="my-lakehouse-project"
export GCP_REGION="us-central1"

gcloud alpha biglake iceberg catalogs create dbx_retail_db \
  --project="$GCP_PROJECT_ID" \
  --primary-location="$GCP_REGION" \
  --catalog-type="federated" \
  --federated-catalog-type="unity" \
  --unity-instance-name="dbc-xxxxxxxx-xxxx.cloud.databricks.com" \
  --unity-catalog-name="dbx_retail_db" \
  --unity-service-principal-application-id="6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx" \
  --refresh-interval="300s"

公式資料からの抜粋：Cross-cloud conversational analytics made simple with open standards（Connect Databricks to BigQuery）。対象版・範囲：gcloud alphaコマンドによる構成例（提供状態の指定なし）。

上記のコードでは、--catalog-typeにfederated、--federated-catalog-typeにunityを指定しています。--primary-locationにはus-central1を渡し、--refresh-intervalは300sとする例です。

作成後は、カタログをdescribeして、割り当てられたサービスアカウントを表示します。コード例でのdescribeの実行方法は、以下の通りです。

gcloud alpha biglake iceberg catalogs describe dbx_retail_db \
  --project="$GCP_PROJECT_ID"

公式資料からの抜粋：Cross-cloud conversational analytics made simple with open standards（Connect Databricks to BigQuery）。対象版・範囲：gcloud alphaコマンドによる構成例（提供状態の指定なし）。

上記のコードでは、describeの対象にdbx_retail_dbを指定し、--projectに$GCP_PROJECT_IDを渡しています。返される構成には、Subjectに入れる数値のsubject IDも含まれます。

Databricks側の権限設定

Databricksに戻り、サービスプリンシパルにUSE CATALOGやUSE SCHEMA、SELECTなどの権限を付与します。外部データアクセス用の資格情報を発行するには、対象のスキーマかカタログでEXTERNAL USE SCHEMA権限の付与が必要です。

図6　サービスプリンシパルに付与する権限

最後に、Databricksのサービスプリンシパルにフェデレーションポリシーを設定し、Issuer URLにhttps://accounts.google.comを指定します。Subjectはdescribeコマンドが返す数値のsubject ID、Audiencesはhttps://accounts.cloud.databricks.comです。

図7　フェデレーションポリシーの設定値

Subjectに入れる値は、カタログのdescribeコマンドが返す数値のsubject IDです。Audiencesには、httpsで始まるaccounts.cloud.databricks.comのURLを指定します。

Lakehouse runtime catalogを使う構成例の範囲

今回の構成例では、外部エンジンがテーブルを読む前に、Databricksのメタストア管理者がExternal data accessを有効にする必要があります。提供状態や課金、対応リージョンの一覧は、今回の構成例には含まれていません。^[1]

図8　構成例で示された設定と確認事項

カタログ作成のコマンド例は、gcloud alphaを使い、リージョンにus-central1を指定する構成です。東京や大阪のリージョンで構成したい場合は、対応リージョンと提供状態を利用前に確かめます。

Databricks Unity Catalogと接続する場合は、External data accessを有効にするメタストア管理者の操作を先に確かめます。AWS GlueとSnowflakeの設定は、Google Cloudの構成例の付録で扱われる内容です。

従来の抽出パイプライン方式との違い

Google Cloudは、分析やAIで組織全体の文脈が必要な場合、複雑な抽出パイプラインで中央へコピーするか分断された報告を受け入れるかの選択が生じるとしています。従来の構成の対処法は、定期的な抽出パイプラインでリモートのデータセットを中央のステージング用ウェアハウスへコピーする方式です。^[1]

図9　コピー型構成とフェデレーションクエリ実行時の違い

この方式について、Google Cloudは同期の遅れや継続的な保存費用、変動するネットワークegress料金が生じると評価しています。上流でスキーマが変わるとパイプラインが壊れ、チームは同期していないダッシュボード間の指標の照合に何時間も費やします。

抽出パイプラインから移る場合、同期する対象はデータセットからメタデータに変わり、データはリモートのストレージから直接読み取る形です。このため、リモート側の権限設定と、ストレージの読み取りにかかる課金条件を事前に確かめます。