このドキュメントでは、 Google Cloud内から Databricks Unity Catalog のデータを直接クエリするためのクロスクラウド接続を設定する方法について説明します。この機能により、外部データソースを既存の Google Cloud 環境と統合して、データ分析を統合できます。
その後、ボーダーレスな Lakehouse を使用して、フェデレーション データへのアクセスを管理できます。
始める前に
- Lakehouse の概要を確認して、Lakehouse がデータへのアクセスを管理する方法を理解します。
- クロスクラウド データへのアクセスを読んで、その仕組みを理解する。
- サポートされているカタログを確認して、サポートされている構成を確認します。
- リージョン Secret Manager シークレットの使用方法を理解する。これは、シークレットベースの認証を使用して Databricks Unity Catalog で Lakehouse を設定するために必要です。
- 省略可: Google Cloud VPC とリモート クラウド プロバイダの VPC(AWS など)間のプライベート相互接続を介してクエリをルーティングする場合は、リモート プロバイダのアクティブなアカウントがあることを確認し、Dedicated Cross-Cloud Interconnect または Partner Cross-Cloud Interconnect をプロビジョニングして、Cloud Router との BGP セッションを確立し、両方のクラウド環境で必要な IAM 権限があることを確認します。
- Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオで Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分も差し上げます。
-
Verify that billing is enabled for your Google Cloud project.
Enable the BigLake, Secret Manager APIs, if any are not already enabled.
Roles required to enable APIs
To enable APIs, you need the
serviceusage.services.enablepermission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.-
Verify that billing is enabled for your Google Cloud project.
Enable the BigLake, Secret Manager APIs, if any are not already enabled.
Roles required to enable APIs
To enable APIs, you need the
serviceusage.services.enablepermission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.
必要なロール
クロスクラウド アクセスの設定に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。
-
Lakehouse カタログを管理する: BigLake 管理者 (
roles/biglake.admin) -
シークレットの管理(シークレット ベースの認証を使用する場合): Secret Manager 管理者 (
roles/secretmanager.admin) -
プライベート相互接続を介してトラフィックをルーティングする(ユーザー): Compute ネットワーク管理者 (
roles/compute.networkAdmin) -
プライベート相互接続を介してトラフィックをルーティングする(カタログ サービス アカウント):
- Service Directory 閲覧者 (
roles/servicedirectory.viewer) - Service Directory PSC 承認済みサービス (
roles/servicedirectory.pscAuthorizedService)
- Service Directory 閲覧者 (
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
制限事項と考慮事項
このセクションでは、クロスクラウド データへのアクセスに関する制限事項と考慮事項について説明します。
- Cross-Cloud Interconnect でサポートされているクラウド プロバイダ: ボーダーレスなレイクハウスでプライベート相互接続を使用する場合、次のリモート クラウド プロバイダがサポートされています。アマゾン ウェブ サービス(AWS)。Dedicated Cross-Cloud Interconnect または Partner Cross-Cloud Interconnect を使用できます。
- ネットワーク ルーティング: プライベート相互接続(Dedicated CCI や Partner CCI など)が構成されていない場合、クエリは公共のインターネット経由でルーティングされます。これにより、リモート クラウド プロバイダからの下り(外向き)料金が増加し、パフォーマンスの予測が難しくなる可能性があります。
- Databricks Unity Catalog の構成:
- AWS の外部ロケーションまたは Google Cloudの外部ロケーションを使用する Databricks Unity Catalog のみがサポートされています。AWS のデフォルト ストレージまたは Google Cloudのデフォルト ストレージを使用する Unity Catalog はサポートされていません。
- Unity Catalog で使用されるメタストアで外部データアクセスを有効にする必要があります。これはデフォルトで無効になっています。
- 外部データアクセス用の認証情報のベンディングを有効にするには、ターゲット スキーマまたはカタログの Databricks サービス プリンシパルに
EXTERNAL USE SCHEMA権限を付与する必要があります。この権限がないと、バックグラウンドでのメタデータの更新とクエリの認証情報の提供が失敗します。
- 読み取り専用: Lakehouse の連携カタログは、リモート カタログの読み取り専用ビューです。リソースの操作(リソースの作成、更新、削除など)はサポートされていません。リモート カタログで直接実行する必要があります。
- データの更新速度: 連携カタログの
--refresh-intervalフラグによって、メタデータの同期頻度が決まります。値は0s(無効)または300s(5 分)以上にする必要があります。カタログのバックグラウンド メタデータの更新は、名前空間とテーブルのリソースが多いほど時間がかかることがあります。前回の更新がオーバーランした場合、現在の更新はスキップされますが、次の更新は次の間隔でスケジュールされます。 - Lakehouse キャッシュ: Lakehouse キャッシュは、すべてのクロスクラウド クエリで自動的に有効になります。データブロックを Google Cloudにローカルに保存することで、下り(外向き)費用を節約できます。顧客管理の暗号鍵(CMEK)はキャッシュ保存ではサポートされていません。キャッシュに保存されたデータは Google-owned and Google-managed encryption keysを使用して暗号化されます。クエリ内のテーブルに
constraints/gcp.restrictNonCmekServices組織のポリシーの制約が適用されている場合、そのクエリのキャッシュは自動的に無効になります。詳細については、インテリジェント キャッシュ保存をご覧ください。 - データ所在地とコンプライアンス: Google Cloud リージョンにフェデレーション カタログまたは接続を作成すると、キャッシュに保存されたデータがそのターゲット リージョンに保存されます。リモート クラウドデータが別の法域にある場合は、クロスリージョン キャッシュ保存が組織のデータ所在地と規制遵守の要件を満たしていることを確認してください。
全般的なワークフロー
クロスクラウド データにアクセスする一般的な手順は次のとおりです。
- Cross-Cloud Interconnect を設定する(省略可): Google Cloud VPC とリモート クラウド プロバイダの間にプライベート接続を構成します。
- 連携を設定する: 認証を構成し、Lakehouse に連携カタログを作成します。
- OpenID Connect(OIDC)(推奨): Lakehouse でリモート サービス プリンシパルのアプリケーション ID を指定して連携カタログを作成し、Lakehouse カタログ サービス アカウントの一意の ID を使用して Databricks で連携ポリシーを構成します。
- シークレットベースの認証: リモート カタログの認証情報を使用して Secret Manager でシークレットを作成します。次に、Lakehouse に連携カタログを作成し、カタログ サービス アカウントにシークレットへのアクセス権を付与します。
- 接続を確認する: Lakehouse がリモート カタログに正常に接続できることを確認します。
- データをクエリする: BigQuery または Managed Service for Apache Spark を使用して、連携データに対してクエリを実行します。レイクハウス キャッシュ保存は、下り(外向き)費用を削減するためにクエリで自動的に有効になります。詳細については、リモートデータにクエリを実行するをご覧ください。
- 権限を構成する: Identity and Access Management(IAM)を使用して、連携データを表示してクエリできるユーザーを管理します。
Cross-Cloud Interconnect を設定する(省略可)
リモート カタログへのクエリは、デフォルトで公共のインターネットを介して送信されます。セキュリティとコンプライアンスを強化し、予測可能なパフォーマンスを提供して、データ転送費用を削減するには、プライベート相互接続を使用します。これにより、 Google CloudVirtual Private Cloud(VPC)とリモート クラウド プロバイダのネットワーク(AWS など)の間に専用のプライベート ネットワーク接続が確立されます。
Google Cloud VPC とリモート クラウド プロバイダの VPC(AWS など)の間に、次のいずれかのプライベート相互接続オプションをプロビジョニングして構成できます。
- 専用 Cross-Cloud Interconnect: 専用の物理接続。
- Partner Cross-Cloud Interconnect: サポートされているサービス プロバイダを介した接続。
Google Cloud の Cloud Router とリモート クラウド プロバイダの VPC の間に BGP セッションを確立して、ルート交換を確実にします。
プライベート クエリを有効にするには、プライベート相互接続を介して Lakehouse からリモート ストレージ バケット(AWS Amazon S3 バケットなど)へのパスを構成する必要があります。このルーティングを構成するには、次の 2 つのアーキテクチャ フローがあります。
- 内部リージョン プロキシ ネットワーク ロードバランサのルーティング: このフローでは、Google Cloud 内部リージョン プロキシ ネットワーク ロードバランサを使用して、複数の AWS Elastic Network Interface(ENI)を指すハイブリッド接続ネットワーク エンドポイント グループ(NEG)にリクエストを分散します。このフローは、ロード バランシング、スケーラビリティ、高可用性に不可欠です。Partner CCI では必須であり、Dedicated CCI ではロード バランシング、スケーラビリティ、高可用性のために推奨されます。
- 直接エンドポイント ルーティング: このフローは、Service Directory を単一の AWS インターフェース VPC エンドポイントの IP アドレスに直接接続します。このフローは専用 CCI でのみ機能し、パートナー CCI ではサポートされていません。
アーキテクチャの要件に一致する構成フローを選択します。
内部リージョン プロキシ ネットワーク ロードバランサ
高可用性とロード バランシングのために複数の AWS ENI にリクエストを分散するように内部リージョン プロキシ ネットワーク ロードバランサを構成する手順は次のとおりです。
AWS ネットワークを構成する
まず、Amazon S3 VPC インターフェース エンドポイント(AWS PrivateLink)を作成します。
- AWS VPC コンソールで、Amazon S3 のインターフェース エンドポイントを作成します。
- サービス名に「
com.amazonaws.AWS_REGION.s3」を指定します。 - Direct Connect を介して Google Cloud VPC に接続されている VPC とサブネットを選択します。
- セキュリティ グループをエンドポイントに接続して、インバウンド アクセスを制御します。
- これにより、選択した各サブネットに Elastic Network Interface(ENI)がプロビジョニングされます。これらの ENI のプライベート IP アドレスをメモします。
次に、セキュリティ グループを構成します。
- Amazon S3 エンドポイント ENI に接続されているセキュリティ グループが、 Google Cloud VPC からのポート
443でのインバウンド TCP トラフィックを許可していることを確認します。これには、ヘルスチェックと転送されたトラフィックを許可するために、Google Cloud プロキシ専用サブネットの CIDR の範囲を含める必要があります。
Google Cloud ネットワーキングを構成する
設定を簡素化するには、次のコマンドを実行して内部ロードバランサを構成します。高度な構成または詳細については、ハイブリッド エンドポイント用に内部リージョン プロキシ ネットワーク ロードバランサを設定するをご覧ください。
gcloud compute networks subnets create PROXY_SUBNET_NAME \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=REGION \ --network=VPC_NETWORK \ --range=PROXY_SUBNET_RANGE
次のように置き換えます。
PROXY_SUBNET_NAME: プロキシ専用サブネットの名前。PROXY_SUBNET_RANGE: VPC ネットワーク内の未使用の CIDR の範囲(例:10.129.0.0/23)。
リージョン ヘルスチェックを作成します。
gcloud compute health-checks create tcp HEALTH_CHECK_NAME \ --region=REGION \ --port=443
次のように置き換えます。
HEALTH_CHECK_NAME: ヘルスチェックの名前。REGION: Google Cloud リージョン(例:us-east4)。
ハイブリッド接続ネットワーク エンドポイント グループ(NEG)を作成し、エンドポイントを追加します。
各ゾーンにハイブリッド NEG(
NON_GCP_PRIVATE_IP_PORT)を作成します。gcloud compute network-endpoint-groups create NEG_NAME \ --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \ --zone=ZONE \ --network=VPC_NETWORK
AWS ENI のプライベート IP アドレスを、対応するハイブリッド NEG に追加します。
gcloud compute network-endpoint-groups update NEG_NAME \ --zone=ZONE \ --add-endpoint="ip=AWS_S3_IP,port=443"
次のように置き換えます。
NEG_NAME: ハイブリッド NEG の名前。ZONE: Google Cloud ゾーン(例:us-east4-a)。このゾーンは、Cross-Cloud Interconnect VLAN アタッチメントのリージョン内に存在する必要があります。VPC_NETWORK: VPC ネットワークの名前。AWS_S3_IP: そのゾーンの AWS Amazon S3 VPC エンドポイント(ENI)のプライベート IP アドレス。
AWS ENI が複数のゾーンに分散されている場合は、これらのコマンドを繰り返して NEG を作成し、他のゾーンのエンドポイントを追加します。
バックエンド サービスを作成して構成します。
内部マネージド ロード バランシングを使用してリージョン バックエンド サービスを作成します。
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=TCP \ --region=REGION \ --health-checks=HEALTH_CHECK_NAME \ --health-checks-region=REGION
ハイブリッド NEG をバックエンド サービスに追加します。
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --region=REGION \ --network-endpoint-group=NEG_NAME \ --network-endpoint-group-zone=ZONE \ --balancing-mode=CONNECTION \ --max-connections=MAX_CONNECTIONS
次のように置き換えます。
BACKEND_SERVICE_NAME: バックエンド サービスの名前。NEG_NAME: 前の手順で作成したハイブリッド NEG の名前。ZONE: Google Cloud ゾーン(例:us-east4-a)。MAX_CONNECTIONS: バックエンドが処理する同時接続の最大数(例:100)。
作成したハイブリッド NEG ごとに
add-backendコマンドを繰り返します。ロードバランサのフロントエンドを構成します。
ターゲット TCP プロキシを作成します。
gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \ --backend-service=BACKEND_SERVICE_NAME \ --region=REGION
ターゲット プロキシにトラフィックをルーティングする転送ルールを作成します。
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=VPC_NETWORK \ --subnet=VPC_SUBNET \ --ports=443 \ --region=REGION \ --target-tcp-proxy=TARGET_PROXY_NAME \ --target-tcp-proxy-region=REGION \ --allow-global-access
次のように置き換えます。
TARGET_PROXY_NAME: ターゲット プロキシの名前。FORWARDING_RULE_NAME: 転送ルールの名前。VPC_SUBNET: VPC サブネットワークの名前。
ロードバランサの転送ルールを作成したら、割り当てられた内部 IP アドレスをメモします。これは ILB_IP_ADDRESS です。
Service Directory を構成する
ILB の IP アドレスを Service Directory に登録して、Lakehouse が検出できるようにします。
リモート クラウドの Namespace を作成します。
gcloud service-directory namespaces create NAMESPACE \ --project=PROJECT_ID \ --location=REGION
次のように置き換えます。
NAMESPACE: 名前空間の固有識別子。PROJECT_ID: 実際の Google Cloud プロジェクト ID。REGION: Google Cloud のリージョン。例:us-east4これは、フェデレーション カタログと同じリージョンにする必要があります。
Service Directory 名前空間にサービスを作成します。
gcloud service-directory services create SERVICE_NAME \ --namespace=NAMESPACE \ --project=PROJECT_ID \ --location=REGION
次のように置き換えます。
SERVICE_NAME: サービスの一意の識別子。
サービスで ILB のエンドポイントを作成します。
gcloud service-directory endpoints create ENDPOINT_NAME \ --project=PROJECT_ID \ --namespace=NAMESPACE \ --service=SERVICE_NAME \ --location=REGION \ --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \ --address=ILB_IP_ADDRESS \ --port=443
次のように置き換えます。
ENDPOINT_NAME: エンドポイントの固有識別子。PROJECT_NUMBER: Google Cloudプロジェクトの番号。--networkフラグでプロジェクト番号を使用します。ILB_IP_ADDRESS: ILB 転送ルールの内部 IP アドレス。
直接エンドポイント
トラフィックを単一の AWS Interface VPC エンドポイント IP アドレスに直接ルーティングするように Service Directory を構成する手順は次のとおりです。
- AWS VPC 内に Amazon S3 のインターフェース VPC エンドポイントを作成します。このエンドポイントの IP アドレスとポートをメモします。
リモート クラウドの名前空間を作成します。
gcloud service-directory namespaces create NAMESPACE \ --project=PROJECT_ID \ --location=REGION
次のように置き換えます。
NAMESPACE: 名前空間の固有識別子。PROJECT_ID: 実際の Google Cloud プロジェクト ID。REGION: Google Cloud のリージョン。例:us-east4これは、フェデレーション カタログと同じリージョンにする必要があります。
Service Directory 名前空間にサービスを作成します。
gcloud service-directory services create SERVICE_NAME \ --namespace=NAMESPACE \ --project=PROJECT_ID \ --location=REGION
次のように置き換えます。
SERVICE_NAME: サービスの固有識別子。
Amazon S3 インターフェース VPC エンドポイントのルーティング情報を含むエンドポイントをサービスに作成します。
gcloud service-directory endpoints create ENDPOINT_NAME \ --service=SERVICE_NAME \ --namespace=NAMESPACE \ --project=PROJECT_ID \ --location=REGION \ --address=S3_VPCE_IP_ADDRESS \ --port=S3_VPCE_PORT \ --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK
次のように置き換えます。
ENDPOINT_NAME: エンドポイントの固有識別子。S3_VPCE_IP_ADDRESS: Amazon S3 Interface VPC エンドポイントの IP アドレス。例:10.0.1.45S3_VPCE_PORT: Amazon S3 Interface VPC エンドポイントのポート番号。例:443PROJECT_NUMBER: Google Cloudプロジェクトの番号。--networkフラグでプロジェクト番号を使用します。VPC_NETWORK: プライベート相互接続に関連付けられている Google Cloud VPC ネットワーク名。
連携を設定する
データにクエリを実行するには、リモート Databricks Unity Catalog に接続する Lakehouse 連携カタログを設定する必要があります。
認証を構成する
連携では、Databricks サービス プリンシパルとしてリモート カタログを認証する必要があります。次のいずれかの認証オプションを選択します。
OIDC
OpenID Connect(OIDC)を使用すると、Databricks OAuth トークン連携を介してシークレットレス認証を行うことができます。
- Databricks アカウントに、ターゲット Unity Catalog への読み取りアクセス権と、ターゲット スキーマまたはカタログに対する
EXTERNAL USE SCHEMA権限を持つサービス プリンシパルを作成します。 - サービス プリンシパルのアプリケーション ID(UUID)を保存します。この値は後のステップで必要になります。
Secret ベース
このオプションでは、リージョン Secret Manager シークレットに安全に保存された OAuth クライアント ID とクライアント シークレットを使用します。
Databricks アカウントに、ターゲット Unity Catalog への読み取りアクセス権を持つサービス プリンシパルを作成します。
サービス プリンシパルの OAuth シークレットを生成します。
ペイロードを含む
credentials.jsonという名前の JSON ファイルを作成します。{ "client_id": "CLIENT_ID", "client_secret": "CLIENT_SECRET" }
次のように置き換えます。
CLIENT_ID: Databricks サービス プリンシパルの OAuth クライアント ID。CLIENT_SECRET: Databricks サービス プリンシパルの OAuth クライアント シークレット。
Secret Manager のリージョン エンドポイントを構成します。
デフォルトでは、Secret Manager はグローバル エンドポイントを使用します。ただし、Lakehouse では、シークレットが Lakehouse カタログと同じリージョンに保存されている必要があります。
gcloudCLI を使用してリージョン シークレットを操作するには、現在のセッションまたはプロファイルのデフォルトの API エンドポイントをオーバーライドする必要があります。例:secretmanager.us-east4.rep.googleapis.comgcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
次のように置き換えます。
REGION: Secret Manager のシークレットが保存されている Google Cloud リージョン。例:us-east4。接続性の問題を回避するには、Secret とカタログを同じリージョンに作成する必要があります。
ペイロードを Secret Manager にアップロードします。
gcloud secrets create DATABRICKS_SECRET_NAME \ --location="REGION" \ --project="PROJECT_ID" \ --data-file=credentials.json
次のように置き換えます。
DATABRICKS_SECRET_NAME: Databricks Secret の名前。PROJECT_ID: 実際の Google Cloud プロジェクト ID。
連携カタログを作成する
Google Cloud コンソールまたは gcloud CLI を使用して、連携カタログを作成します。
考慮事項:
AWS の外部ロケーションまたは Google Cloudの外部ロケーションを使用する Databricks Unity Catalog のみがサポートされています。AWS のデフォルト ストレージまたは Google Cloudのデフォルト ストレージを使用する Databricks Unity Catalog はサポートされていません。
Unity Catalog で使用される metastore で外部データアクセスを有効にする必要があります。これはデフォルトで無効になっています。
外部データアクセス用の認証情報ベンダーを有効にするには、ターゲット スキーマまたはカタログの Databricks サービス プリンシパルに
EXTERNAL USE SCHEMA権限を付与する必要があります。この権限がないと、バックグラウンドのメタデータの更新とクエリの認証情報のベンディングが失敗します。
コンソール
連携カタログを作成するには:
Google Cloud コンソールで、[Lakehouse] に移動します。
[ カタログを作成] をクリックします。
[連携カタログ] をクリックします。
[カタログの構成] セクションが表示されます。
[連携カタログのソース] で [Databricks(Unity)] を選択します。
[データのロケーション] で、連携カタログを作成する Lakehouse リージョンを選択します。例:
us-east4レイテンシを最小限に抑えるには(公共のインターネット経由でも)、リージョンを選択するときに次の操作を行います。- Unity Catalog が AWS にある場合は、AWS リージョンに最も近いGoogle Cloud リージョンを選択します。
- Unity Catalog が Google Cloudの場合は、まったく同じリージョンを選択します。
[続行] をクリックします。
[接続の詳細] セクションが表示されます。
[リモート カタログの詳細] セクションの [Unity インスタンス名] フィールドに、ターゲットの Databricks インスタンス名を入力します。例:
abcd.cloud.databricks.com。[Unity Catalog 名] フィールドに、連携するターゲット Databricks Unity Catalog の名前を入力します。
[認証方法] のオプションを選択します。
- [OIDC] に、サービス プリンシパルのアプリケーション ID を入力します。
- [シークレット] に、シークレットの名前を入力します。
projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME形式を使用します。
省略可: [Service Directory 名] フィールドに、Service Directory サービスへのパスを入力します。例:
projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAMEこれは、プライベート相互接続(Cross-Cloud Interconnect)を構成する場合にのみ必要です。[作成] をクリックします。
gcloud
OIDC
OIDC を使用する場合は、--unity-service-principal-application-id を指定する必要があります。
公共のインターネット(CCI なし)
CCI を構成しない場合、接続は公共のインターネット経由で安全に転送されます。
gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --primary-location="REGION" \ --catalog-type="federated" \ --federated-catalog-type="unity" \ --unity-service-principal-application-id="UNITY_SERVICE_PRINCIPAL_APPLICATION_ID" \ --unity-instance-name="UNITY_INSTANCE_NAME" \ --unity-catalog-name="UNITY_CATALOG_NAME" \ --refresh-interval="REFRESH_INTERVAL" \ --namespace-filters="NAMESPACE_FILTERS"
お客様所有(CCI)
プライベート インターコネクト(Dedicated CCI や Partner CCI など)を構成した場合は、Lakehouse がトラフィックをプライベートで転送できるように、Service Directory サービス参照を指定します。
gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --primary-location="REGION" \ --catalog-type="federated" \ --federated-catalog-type="unity" \ --unity-service-principal-application-id="UNITY_SERVICE_PRINCIPAL_APPLICATION_ID" \ --unity-instance-name="UNITY_INSTANCE_NAME" \ --unity-catalog-name="UNITY_CATALOG_NAME" \ --refresh-interval="REFRESH_INTERVAL" \ --namespace-filters="NAMESPACE_FILTERS" \ --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"
次のように置き換えます。
FEDERATED_CATALOG_NAME: 連携カタログの名前。PROJECT_ID: 実際の Google Cloud プロジェクト ID。REGION: 連携カタログが作成される Lakehouse リージョン。これは、Service Directory の名前空間およびリージョン シークレットと同じリージョンにする必要があります。レイテンシを最小限に抑えるには:- Unity Catalog が AWS にある場合は、AWS リージョンに最も近いGoogle Cloud リージョンを選択します。
- Unity Catalog が Google Cloudにある場合は、まったく同じリージョンを選択します。
UNITY_SERVICE_PRINCIPAL_APPLICATION_ID: Databricks サービス プリンシパルのアプリケーション ID(UUID)。UNITY_INSTANCE_NAME: ターゲット Databricks インスタンス名。例:abcd.cloud.databricks.com。UNITY_CATALOG_NAME: 連携するターゲット Databricks Unity Catalog の名前。REFRESH_INTERVAL: バックグラウンド メタデータの更新を実行する頻度を指定します。この値は期間として設定します(例:330s、5m30s)。NAMESPACE_FILTERS: 省略可。連携する名前空間のカンマ区切りのリスト。例:ns1,ns2省略すると、すべての Namespace が含まれます。- プライベート相互接続(CCI)を使用している場合:
SERVICE_DIRECTORY_NAMESPACE: プライベート相互接続の設定時に作成した Service Directory 名前空間。SERVICE_NAME: プライベート相互接続の設定時に作成した Service Directory サービス名。
Secret ベース
シークレット ベースの認証を使用する場合は、--secret-name を指定する必要があります。
公共のインターネット(CCI なし)
CCI を構成しない場合、接続は公共のインターネット経由で安全に転送されます。
gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --primary-location="REGION" \ --catalog-type="federated" \ --federated-catalog-type="unity" \ --secret-name="projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME" \ --unity-instance-name="UNITY_INSTANCE_NAME" \ --unity-catalog-name="UNITY_CATALOG_NAME" \ --refresh-interval="REFRESH_INTERVAL" \ --namespace-filters="NAMESPACE_FILTERS"
お客様所有(CCI)
プライベート インターコネクト(Dedicated CCI や Partner CCI など)を構成した場合は、Lakehouse がトラフィックをプライベートで転送できるように、Service Directory サービス参照を指定します。
gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --primary-location="REGION" \ --catalog-type="federated" \ --federated-catalog-type="unity" \ --secret-name="projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME" \ --unity-instance-name="UNITY_INSTANCE_NAME" \ --unity-catalog-name="UNITY_CATALOG_NAME" \ --refresh-interval="REFRESH_INTERVAL" \ --namespace-filters="NAMESPACE_FILTERS" \ --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"
次のように置き換えます。
FEDERATED_CATALOG_NAME: フェデレーション カタログの名前。PROJECT_ID: 実際の Google Cloud プロジェクト ID。REGION: 連携カタログが作成される Lakehouse リージョン。これは、Service Directory の名前空間およびリージョン シークレットと同じリージョンにする必要があります。レイテンシを最小限に抑えるには:- Unity Catalog が AWS にある場合は、AWS リージョンに最も近いGoogle Cloud リージョンを選択します。
- Unity Catalog が Google Cloudにある場合は、まったく同じリージョンを選択します。
DATABRICKS_SECRET_NAME: Databricks Secret の名前。UNITY_INSTANCE_NAME: ターゲット Databricks インスタンス名。例:abcd.cloud.databricks.com。UNITY_CATALOG_NAME: 連携するターゲット Databricks Unity Catalog の名前。REFRESH_INTERVAL: バックグラウンド メタデータの更新を実行する頻度を指定します。この値は期間として設定します(例:330s、5m30s)。NAMESPACE_FILTERS: 省略可。連携する名前空間のカンマ区切りのリスト。例:ns1,ns2省略すると、すべての Namespace が含まれます。- プライベート相互接続(CCI)を使用している場合:
SERVICE_DIRECTORY_NAMESPACE: プライベート相互接続の設定時に作成した Service Directory 名前空間。SERVICE_NAME: プライベート相互接続の設定時に作成した Service Directory サービス名。
認証の設定を完了する
選択した認証タイプを使用して認証プロセスを完了します。
OIDC
カタログが作成されると、Lakehouse はカタログに一意のサービス アカウントをプロビジョニングします。サービス アカウントの数値の一意の ID を取得し、それを使用して Databricks サービス プリンシパルの連携ポリシーを構成する必要があります。
Lakehouse カタログのサービス アカウントの数値形式の一意の ID を取得します。
gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --format='value(biglake-service-account-id)'
Databricks アカウントで、前に作成したサービス プリンシパルのフェデレーション ポリシーを構成します。次の値を使用します。
- 発行元 URL:
https://accounts.google.com - サブジェクト: 前の手順で取得した Lakehouse カタログ サービス アカウントの一意の数値 ID。
- 対象:
https://accounts.cloud.databricks.com
Databricks サービス プリンシパルに、ターゲット カタログとワークスペースに対する読み取り権限と、ターゲット スキーマまたはカタログに対する
EXTERNAL USE SCHEMA権限があることを確認します。- 発行元 URL:
Secret ベース
カタログが作成されると、Lakehouse はカタログの一意のサービス アカウントをプロビジョニングします(リソースの説明で biglake-service-account として返されます)。
このサービス アカウントに、先ほど作成したシークレットへのアクセス権を付与する必要があります。IAM ポリシーの伝播には数分かかることがあります。
カタログのサービス アカウントにシークレットへのアクセス権を付与します。
gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/ gcloud secrets add-iam-policy-binding DATABRICKS_SECRET_NAME \ --project="PROJECT_ID" \ --location="REGION" \ --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --format='value(biglake-service-account)')" \ --role="roles/secretmanager.secretAccessor"
連携カタログ サービス アカウントが Secret にアクセスできることを確認するには、次のコマンドを実行します。
gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/ gcloud secrets get-iam-policy DATABRICKS_SECRET_NAME \ --project="PROJECT_ID" \ --location="REGION"
出力で、biglake-service-account サービス アカウントに roles/secretmanager.secretAccessor ロールが割り当てられていることを確認します。
Databricks サービス プリンシパルに、ターゲット カタログとワークスペースに対する読み取りアクセス権と、ターゲット スキーマまたはカタログに対する EXTERNAL USE SCHEMA 権限があることを確認します。
プライベート相互接続の設定を完了する(Cross-Cloud Interconnect のみ)
プライベート相互接続(Dedicated または Partner CCI)を介してトラフィックをルーティングする場合は、Service Directory を介して接続を検出して認可する権限を Lakehouse カタログ サービス アカウントに付与する必要があります。
コンソール
Google Cloud コンソールで、[IAM] ページに移動します。
[アクセス権を付与](または [追加])をクリックします。
[新しいプリンシパル] フィールドに、Lakehouse カタログ サービス アカウントのメールアドレスを入力します。このメールアドレスは、カタログを記述することで取得できます(
gcloudタブを参照)。[ロール] メニューで、[Service Directory 閲覧者](
roles/servicedirectory.viewer)を選択します。[別のロールを追加] をクリックし、[Service Directory PSC 承認済みサービス](
roles/servicedirectory.pscAuthorizedService)を選択します。[保存] をクリックします。
gcloud
カタログのサービス アカウントに必要なロールを付与します。
# Grant Service Directory Viewer gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --format='value(biglake-service-account)')" \ --role="roles/servicedirectory.viewer" # Grant Service Directory PSC Authorized Service gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --format='value(biglake-service-account)')" \ --role="roles/servicedirectory.pscAuthorizedService"
接続を確認する
カタログのバックグラウンド メタデータの更新サイクルが正常に完了し、名前空間が同期されていることを確認します。
更新ステータスが成功を示していることを確認します。
gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID"
Namespace が同期されていることを確認します。
gcloud alpha biglake iceberg namespaces list \ --project="PROJECT_ID" \ --catalog="FEDERATED_CATALOG_NAME"