Configura Lakehouse cross-cloud per Snowflake

Anteprima

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Nota: per ricevere assistenza durante l'anteprima, invia un'email all'indirizzo [e-mail].

Questo documento descrive come configurare un lakehouse cross-cloud per interrogare i dati di un catalogo Snowflake (Snowflake Horizon) direttamente in Google Cloud. Questa funzionalità unifica l'analisi dei dati integrando le sorgenti di dati esterne con l'ambiente Google Cloudesistente.

Successivamente, puoi utilizzare Lakehouse per gestire l'accesso ai tuoi dati federati.

Prima di iniziare

1. Consulta la panoramica di Lakehouse per capire come Lakehouse gestisce l'accesso ai dati.
2. Leggi l'articolo Informazioni su Lakehouse cross-cloud per capire come funziona.
3. Esamina i cataloghi supportati per verificare i requisiti relativi alle posizioni esterne e le configurazioni supportate.
4. Scopri come utilizzare i secret regionali di Secret Manager. Questo è necessario per configurare un Lakehouse cross-cloud con Snowflake utilizzando l'autenticazione basata su secret.
5. Se utilizzi l'autenticazione basata su secret, genera un token di accesso personale (PAT) all'interno dell'ambiente Snowflake Horizon che disponga dell'accesso in lettura al catalogo di destinazione. Questo processo non rientra nell'ambito di questa documentazione.
6. Se utilizzi la federazione delle identità per i workload, assicurati di avere accesso all'interfaccia utente dell'account Snowflake con privilegi ACCOUNTADMIN per il provisioning degli utenti di servizio.
7. (Facoltativo) Se prevedi di instradare le query su un interconnessione privata tra il tuo VPC Google Cloud e il VPC del tuo provider cloud remoto (ad esempio AWS), assicurati di avere un account attivo con il tuo provider remoto, esegui il provisioning di un'interconnessione cross-cloud dedicata o di un'interconnessione cross-cloud partner, stabilisci sessioni BGP con router Cloud e verifica di disporre delle autorizzazioni Identity and Access Management (IAM) richieste in entrambi gli ambienti cloud.
Accedi al tuo account Google Cloud . Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. 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.

Enable the APIs

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. 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.

Enable the APIs

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per configurare Lakehouse cross-cloud, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

• Gestisci i cataloghi lakehouse: BigLake Admin (roles/biglake.admin)
• Gestisci i secret: Secret Manager Admin (roles/secretmanager.admin)
• Instrada il traffico tramite l'interconnessione privata: Compute Network Admin (roles/compute.networkAdmin), Service Directory Viewer (roles/servicedirectory.viewer) e Service Directory PSC Authorized Service (roles/servicedirectory.pscAuthorizedService)

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Attenzione: per seguire il principio del privilegio minimo ed evitare di concedere l'accesso a tutti i secret del progetto, chiedi a un amministratore di Secret Manager di creare il secret per te e di concederti le autorizzazioni per modificare solo quel secret specifico per Lakehouse cross-cloud.

Dettagli del catalogo supportati

Questa guida fornisce istruzioni per configurare Lakehouse cross-cloud con un catalogo Snowflake (Snowflake Horizon) su Amazon Web Services (AWS) e Google Cloud. Per informazioni dettagliate sui requisiti delle posizioni esterne e sulle configurazioni supportate, vedi Cataloghi supportati.

Limitazioni e considerazioni

Questa sezione elenca le limitazioni e le considerazioni per l'utilizzo di Lakehouse cross-cloud.

• Provider cloud supportati:l'utilizzo di un interconnessione privata con il tuo cross-cloud Lakehouse è supportato con i seguenti provider cloud remoti: Amazon Web Services (AWS). Puoi utilizzare un Dedicated Cross-Cloud Interconnect o un Partner Cross-Cloud Interconnect.
• Routing di rete:se non è configurata un'interconnessione privata (ad esempio Dedicated CCI o Partner CCI), le query vengono instradate su internet pubblico. Ciò può comportare tariffe per il traffico in uscita più elevate dal tuo cloud provider remoto e prestazioni meno prevedibili.
• Aggiornamento dei dati:il flag --refresh-interval per il catalogo federato determina la frequenza di sincronizzazione dei metadati. Un intervallo più breve fornisce dati più recenti, ma può comportare costi API aggiuntivi da parte del fornitore del catalogo remoto.
• Report sulle metriche Iceberg: il report sulle metriche Iceberg non è disponibile per i cataloghi federati. Imposta la proprietà rest-metrics-reporting-enabled su false nel client Iceberg quando accedi a un catalogo federato.

Flusso di lavoro generale

Per configurare e utilizzare Lakehouse cross-cloud, segui questi passaggi generali:

• (Facoltativo) Configura Cross-Cloud Interconnect: configura una connessione privata tra il tuo VPC Google Cloud e il tuo provider di servizi cloud remoto.
• Configura la federazione:configura l'autenticazione e crea un catalogo federato in Lakehouse.
  • Autenticazione basata su secret (PAT): crea un secret in Secret Manager con le credenziali del catalogo remoto. Poi, crea un catalogo federato in Lakehouse e concedi alaccount di serviziot del catalogo l'accesso al secret.
  • Federazione delle identità per i workload (WIF): crea un catalogo federato in Lakehouse specificando il ruolo Snowflake richiesto. Poi, collega l'IDaccount di serviziot del catalogo a un utente di servizio in Snowflake. L'utente del servizio Snowflake deve disporre delle autorizzazioni di utilizzo sul catalogo Snowflake remoto.
• Verifica la connessione: verifica che Lakehouse possa connettersi correttamente al catalogo remoto.
• Esegui query sui dati:esegui query sui dati federati utilizzando BigQuery o Managed Service for Apache Spark. Per saperne di più, consulta Utilizzare Lakehouse cross-cloud.
• Configura le autorizzazioni:utilizza IAM per gestire chi può visualizzare ed eseguire query sui dati federati.

Configura Cross-Cloud Interconnect (facoltativo)

Per impostazione predefinita, le query al catalogo remoto vengono inviate tramite la rete internet pubblica. Per migliorare la sicurezza e la conformità, fornire prestazioni prevedibili e ridurre i costi di trasferimento dei dati, utilizza un interconnessione privata. In questo modo viene stabilita una connessione di rete privata dedicata tra la tua Google Cloud Virtual Private Cloud (VPC) e la rete del tuo provider di servizi cloud remoto (ad esempio AWS).

Puoi eseguire il provisioning e configurare una delle seguenti opzioni di interconnessione privata tra il tuo Google Cloud VPC e il VPC del tuo provider di servizi cloud remoto (ad esempio AWS):

• Cross-Cloud Interconnect dedicato: una connessione fisica dedicata.
• Partner Cross-Cloud Interconnect: una connessione tramite un fornitore di servizi supportato.

Stabilisci sessioni BGP tra il tuo router Cloud in Google Cloud e il VPC del tuo fornitore di servizi cloud remoto per garantire lo scambio di route.

Per abilitare le query private, devi configurare un percorso da Lakehouse al bucket di archiviazione remoto (ad esempio, un bucket AWS Amazon S3) tramite l'interconnessione privata. Esistono due flussi architetturali che puoi seguire per configurare questo routing:

• Routing del bilanciatore del carico di rete proxy interno regionale: questo flusso utilizza un bilanciatore del carico di rete proxy interno regionaleGoogle Cloud per distribuire le richieste tra i gruppi di endpoint di rete (NEG) di connettività ibrida che puntano a più interfacce di rete elastiche (ENI) AWS. Questo flusso è essenziale per il bilanciamento del carico, la scalabilità e l'alta affidabilità. È obbligatorio per l'interconnessione interaziendale partner e consigliato per l'interconnessione interaziendale dedicata per il bilanciamento del carico, la scalabilità e l'alta affidabilità.
• Routing diretto degli endpoint: questo flusso connette Service Directory direttamente a un singolo indirizzo IP dell'endpoint VPC di interfaccia AWS. Questo flusso funziona solo per l'API CCI dedicata e non è supportato per l'API CCI partner.

Seleziona il flusso di configurazione che corrisponde ai requisiti dell'architettura:

Bilanciatore del carico di rete proxy interno regionale

Per configurare un bilanciatore del carico di rete proxy interno regionale per distribuire le richieste su più interfacce di rete AWS per alta affidabilità e bilanciamento del carico, segui questi passaggi:

Configura la rete AWS

Innanzitutto, crea un endpoint VPC di interfaccia Amazon S3 (AWS PrivateLink):

1. Nella console AWS VPC, crea un endpoint di interfaccia per Amazon S3.
2. Per il nome del servizio, specifica com.amazonaws.AWS_REGION.s3.
3. Seleziona il VPC e le subnet connessi tramite Direct Connect al tuo VPC Google Cloud .
4. Collega i gruppi di sicurezza all'endpoint per controllare l'accesso in entrata.
5. Vengono eseguito il provisioning delle interfacce di rete elastiche (ENI) in ogni subnet selezionata. Prendi nota degli indirizzi IP privati di queste interfacce di rete.

Poi, configura i gruppi di sicurezza:

• Assicurati che il gruppo o i gruppi di sicurezza collegati alle ENI dell'endpoint Amazon S3 consentano il traffico TCP in entrata sulla porta 443 dal tuo VPC Google Cloud . Deve includere l'intervallo CIDR della tua subnetGoogle Cloud proxy-only per consentire i controlli di integrità e il traffico inoltrato.

Configurare Google Cloud il networking

Importante :devi eseguire il deployment di tutte le risorse Google Cloud in questa sezione (controllo di integrità, NEG ibridi, servizio di backend e bilanciatore del carico) esattamente nella stessa regione in cui si trova il collegamento VLAN Cross-Cloud Interconnect. Se si trovano in regioni diverse, il traffico non verrà instradato allo spazio di archiviazione remoto.

Per semplificare la configurazione, esegui i seguenti comandi per configurare il bilanciatore del carico interno. Per configurazioni avanzate o maggiori dettagli, vedi Configurare un bilanciatore del carico di rete proxy interno regionale per endpoint ibridi.

Nota: prima di iniziare, assicurati di aver configurato una subnet solo proxy nella rete VPC nella regione. Se non ne hai uno, esegui il seguente comando per crearlo:

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

Sostituisci quanto segue:

• PROXY_SUBNET_NAME: un nome per la subnet solo proxy.
• PROXY_SUBNET_RANGE: un intervallo CIDR non utilizzato all'interno della rete VPC (ad esempio, 10.129.0.0/23).

Importante: router Cloud non annuncia automaticamente le subnet solo proxy utilizzando BGP. Devi configurare manualmente il router Cloud per annunciare l'intervallo CIDR della subnet solo proxy alla tua rete remota (ad esempio AWS) utilizzando annunci di route personalizzati. In questo modo, il traffico di risposta dallo spazio di archiviazione remoto può essere indirizzato nuovamente al bilanciatore del carico.

1. Crea un controllo di integrità a livello di regione:

   gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
       --region=REGION \
       --port=443

   Sostituisci quanto segue:

   • HEALTH_CHECK_NAME: un nome per il controllo di integrità.
   • REGION: la Google Cloud regione (ad esempio, us-east4).

2. Crea gruppi di endpoint di rete (NEG) con connettività ibrida e aggiungi endpoint:

   Crea un NEG ibrido (NON_GCP_PRIVATE_IP_PORT) per ogni zona:

   gcloud compute network-endpoint-groups create NEG_NAME \
       --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
       --zone=ZONE \
       --network=VPC_NETWORK

   Aggiungi l'indirizzo IP privato della tua ENI AWS al NEG ibrido corrispondente:

   gcloud compute network-endpoint-groups update NEG_NAME \
       --zone=ZONE \
       --add-endpoint="ip=AWS_S3_IP,port=443"

   Sostituisci quanto segue:

   • NEG_NAME: un nome per il NEG ibrido.
   • ZONE: la zona Google Cloud (ad esempio us-east4-a). Questa zona deve trovarsi all'interno della regione del collegamento VLAN Cross-Cloud Interconnect.
   • VPC_NETWORK: il nome della tua rete VPC.
   • AWS_S3_IP: l'indirizzo IP privato dell'interfaccia di rete (ENI) dell'endpoint VPC AWS Amazon S3 in quella zona.

   Ripeti questi comandi per creare NEG e aggiungere endpoint per altre zone se le tue ENI AWS sono distribuite in più zone.

3. Crea e configura il servizio di backend:

   Crea un servizio di backend regionale con bilanciamento del carico gestito interno:

   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

   Aggiungi i NEG ibridi al servizio di backend:

   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

   Sostituisci quanto segue:

   • BACKEND_SERVICE_NAME: un nome per il servizio di backend.
   • NEG_NAME: il nome del NEG ibrido creato nel passaggio precedente.
   • ZONE: la zona Google Cloud (ad esempio, us-east4-a).
   • MAX_CONNECTIONS: il numero massimo di connessioni simultanee che il backend deve gestire (ad esempio, 100).

   Ripeti il comando add-backend per ogni NEG ibrida che hai creato.

4. Configura il frontend del bilanciatore del carico:

   Crea un proxy TCP di destinazione:

   gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
       --backend-service=BACKEND_SERVICE_NAME \
       --region=REGION

   Crea una regola di forwarding per instradare il traffico al proxy di destinazione:

   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

   Sostituisci quanto segue:

   • TARGET_PROXY_NAME: un nome per il proxy di destinazione.
   • FORWARDING_RULE_NAME: un nome per la regola di forwarding.
   • VPC_SUBNET: il nome della tua subnet VPC.

Dopo aver creato la regola di forwarding per il bilanciatore del carico, prendi nota dell'indirizzo IP interno assegnato. Questo è il tuo ILB_IP_ADDRESS.

Configurare Service Directory

Registra l'indirizzo IP del bilanciamento del carico interno in Service Directory, in modo che Lakehouse possa rilevarlo.

1. Crea uno spazio dei nomi per il tuo cloud remoto:

   gcloud service-directory namespaces create NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Sostituisci quanto segue:

   • NAMESPACE: un identificatore univoco per il tuo spazio dei nomi.
   • PROJECT_ID: il tuo Google Cloud ID progetto.
   • REGION: la Google Cloud regione. Ad esempio, us-east4. Deve trovarsi nella stessa regione del catalogo federato.

2. Crea un servizio nello spazio dei nomi Service Directory:

   gcloud service-directory services create SERVICE_NAME \
       --namespace=NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Sostituisci quanto segue:

   • SERVICE_NAME: un identificatore univoco per il tuo servizio.

3. Crea un endpoint per il bilanciatore del carico interno nel servizio:

   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

   Sostituisci quanto segue:

   • ENDPOINT_NAME: un identificatore univoco per l'endpoint.
   • PROJECT_NUMBER: il tuo Google Cloud numero di progetto. Utilizza il numero del progetto nel flag --network.
   • ILB_IP_ADDRESS: l'indirizzo IP interno della regola di forwarding del bilanciamento del carico interno.

Endpoint diretto

Per configurare Service Directory in modo da instradare il traffico direttamente a un singolo indirizzo IP dell'endpoint VPC di interfaccia AWS, segui questi passaggi:

1. Crea un endpoint VPC di interfaccia per Amazon S3 all'interno del tuo VPC AWS. Prendi nota dell'indirizzo IP e della porta di questo endpoint.

2. Crea uno spazio dei nomi per il tuo cloud remoto:

   gcloud service-directory namespaces create NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Sostituisci quanto segue:

   • NAMESPACE: un identificatore univoco per il tuo spazio dei nomi.
   • PROJECT_ID: il tuo Google Cloud ID progetto.
   • REGION: la Google Cloud regione. Ad esempio, us-east4. Deve trovarsi nella stessa regione del catalogo federato.

3. Crea un servizio nello spazio dei nomi Service Directory:

   gcloud service-directory services create SERVICE_NAME \
       --namespace=NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Sostituisci quanto segue:

   • SERVICE_NAME: un identificatore univoco per il tuo servizio.

4. Crea un endpoint nel servizio contenente le informazioni di routing per l'endpoint VPC di interfaccia Amazon S3:

   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

   Sostituisci quanto segue:

   • ENDPOINT_NAME: un identificatore univoco per l'endpoint.
   • S3_VPCE_IP_ADDRESS: l'indirizzo IP dell'endpoint VPC di interfaccia Amazon S3. Ad esempio, 10.0.1.45.
   • S3_VPCE_PORT: il numero di porta dell'endpoint VPC di interfaccia Amazon S3. Ad esempio, 443.
   • PROJECT_NUMBER: il tuo Google Cloud numero di progetto. Utilizza il numero del progetto nel flag --network.
   • VPC_NETWORK: il nome della rete VPC associata al tuo interconnessione privata. Google Cloud

Configura la federazione

Per eseguire query sui dati, devi configurare un catalogo federato Lakehouse che si connette al catalogo Snowflake remoto. Seleziona il metodo di autenticazione:

Basato su secret (PAT)

Configura l'autenticazione

La federazione richiede le credenziali per accedere al catalogo Snowflake remoto. Per Snowflake Horizon, devi utilizzare un token di accesso personale (PAT), ovvero un token di lunga durata generato da Snowflake, insieme al ruolo Snowflake specifico richiesto per la sessione.

Crea un secret in Secret Manager regionale per archiviare le credenziali:

1. Crea un file JSON denominato credentials.json con il payload:

     {
       "client_secret": "SNOWFLAKE_PAT_TOKEN",
       "scope": "session:role:SNOWFLAKE_ROLE"
     }
     

   Sostituisci quanto segue:

   • SNOWFLAKE_PAT_TOKEN: il tuo token di accesso personale (PAT) Snowflake.
   • SNOWFLAKE_ROLE: il ruolo Snowflake specifico richiesto per la sessione. Ad esempio, ICEBERG_VIEW.
   Nota: il parametro client_id non è necessario per le configurazioni di Snowflake Horizon perché l'autenticazione viene gestita interamente dal token PAT e dall'ambito.

2. Configura l'endpoint regionale per Secret Manager:

   Per impostazione predefinita, Secret Manager utilizza un endpoint globale. Tuttavia, Lakehouse cross-cloud richiede che i segreti vengano archiviati nella stessa regione del catalogo Lakehouse. Per interagire con i secret regionali utilizzando l'interfaccia a riga di comando gcloud, devi sostituire l'endpoint API predefinito per la sessione o il profilo corrente. Per evitare problemi di connettività, il secret e il catalogo devono essere creati nella stessa regione.

     gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
     

   Sostituisci quanto segue:

   • REGION: la regione Google Cloud in cui è archiviato il secret di Secret Manager. Ad esempio: us-east4. Per evitare problemi di connettività, il secret e il catalogo devono essere creati nella stessa regione.

3. Carica il payload in Secret Manager:

     gcloud secrets create SNOWFLAKE_SECRET_NAME \
       --location="REGION" \
       --project="PROJECT_ID" \
       --data-file=credentials.json
     

   Sostituisci quanto segue:

   • SNOWFLAKE_SECRET_NAME: un nome per il secret Snowflake.
   • PROJECT_ID: il tuo ID progetto Google Cloud .

   Crea un catalogo federato

   Crea il catalogo federato utilizzando il comando gcloud alpha biglake iceberg catalogs create.

   Rete internet pubblica (nessun CCI)

   Se non configuri CCI, la connessione passa in modo sicuro attraverso la rete internet pubblica.

     gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
         --project="PROJECT_ID" \
         --primary-location="REGION" \
         --catalog-type="federated" \
         --federated-catalog-type="snowflake" \
         --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
         --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
         --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
         --refresh-interval="REFRESH_INTERVAL" \
         --namespace-filters="NAMESPACE_FILTERS"
     

   Sostituisci quanto segue:

   • PROJECT_ID: il tuo ID progetto Google Cloud .
   • REGION: la regione Lakehouse in cui viene creato il catalogo federato. Ad esempio, us-east4. Per ridurre al minimo la latenza, seleziona la regione Google Cloud più vicina alla tua regione Snowflake.
   • SNOWFLAKE_SECRET_NAME: il nome del secret Snowflake.
   • SNOWFLAKE_ACCOUNT_IDENTIFIER: l'identificatore del tuo account Snowflake (ad esempio, my_org-my_account).
   • SNOWFLAKE_WAREHOUSE: il nome del catalogo Snowflake con cui vuoi eseguire la federazione.
   • REFRESH_INTERVAL: (facoltativo) specifica la frequenza di aggiornamento delle informazioni del catalogo. Imposta questo valore come durata, ad esempio, 330s o 5m30s. Intervalli più brevi aggiornano i dati più spesso, ma possono costare di più in chiamate API. Intervalli più lunghi possono costare meno, ma i dati su cui viene eseguita la query potrebbero non riflettere il set di dati più recente. Se omesso o se il valore è impostato su 0s, l'aggiornamento dei metadati in background non verrà avviato. Rimarrà disattivato finché l'intervallo di aggiornamento non viene aggiornato a un valore positivo.
   • NAMESPACE_FILTERS: (Facoltativo) un elenco separato da virgole di spazi dei nomi da federare. Ad esempio, ns1,ns2. Se omesso, verranno inclusi tutti gli spazi dei nomi.

   Di proprietà del cliente (CCI)

   Se hai configurato un'interconnessione privata (ad esempio Dedicated CCI o Partner CCI), fornisci il riferimento all'endpoint Service Directory in modo che Lakehouse indirizzi il traffico in modo privato.

     gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
         --project="PROJECT_ID" \
         --primary-location="REGION" \
         --catalog-type="federated" \
         --federated-catalog-type="snowflake" \
         --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
         --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
         --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
         --refresh-interval="REFRESH_INTERVAL" \
         --namespace-filters="NAMESPACE_FILTERS" \
         --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"
     

   Sostituisci quanto segue:

   • PROJECT_ID: il tuo ID progetto Google Cloud .
   • REGION: la regione Lakehouse in cui viene creato il catalogo federato. Nota: deve essere la stessa regione dello spazio dei nomi di Service Directory e del secret regionale.
   • SNOWFLAKE_SECRET_NAME: il nome del secret Snowflake.
   • SNOWFLAKE_ACCOUNT_IDENTIFIER: l'identificatore del tuo account Snowflake.
   • SNOWFLAKE_WAREHOUSE: il nome del catalogo Snowflake con cui vuoi eseguire la federazione
   • REFRESH_INTERVAL: (facoltativo) specifica la frequenza di aggiornamento delle informazioni del catalogo.
   • NAMESPACE_FILTERS: (Facoltativo) un elenco separato da virgole di spazi dei nomi da federare.
   • NAMESPACE: lo spazio dei nomi di Service Directory che hai creato durante la configurazione dell'interconnessione privata.
   • SERVICE_NAME: il nome del servizio Service Directory che hai creato durante la configurazione dell'interconnessione privata.
   • ENDPOINT_NAME: il nome dell'endpoint Service Directory che hai creato durante la configurazione dell'interconnessione privata.

   Completa la configurazione dell'autenticazione

   Quando viene creato il catalogo, Lakehouse esegue il provisioning di un account di servizio univoco (restituito come biglake-service-account nella descrizione della risorsa).

   Devi concedere a questo account di servizio l'autorizzazione per accedere al secret che hai creato in precedenza. Tieni presente che la propagazione dei criteri IAM può richiedere alcuni minuti.

   Concedi all'account di servizio del catalogo l'autorizzazione per accedere al secret:

   gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
   gcloud secrets add-iam-policy-binding SNOWFLAKE_SECRET_NAME \
     --project="PROJECT_ID" \
     --location="REGION" \
     --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
         --project="PROJECT_ID" \
         --location="REGION" \
         --format='value(biglake-service-account)')" \
     --role="roles/secretmanager.secretAccessor"

   Per verificare che il account di servizio di catalogo federato abbia accesso al secret, esegui questo comando:

   gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
   gcloud secrets get-iam-policy SNOWFLAKE_SECRET_NAME \
       --project="PROJECT_ID" \
       --location="REGION"

   Nell'output, verifica che al account di servizio biglake-service-account sia assegnato il ruolo roles/secretmanager.secretAccessor.

Federazione delle identità per i workload

La federazione delle identità per i workload (WIF) evita l'utilizzo di secret di lunga durata collegando un account di servizio Lakehouse direttamente a un service user Snowflake.

Crea un catalogo federato

Crea il catalogo federato utilizzando la console Google Cloud , l'API REST Lakehouse o la CLIgcloud. Devi specificare il ruolo Snowflake da utilizzare.

Console

Per creare un catalogo federato utilizzando l'autenticazione basata su secret:

1. Nella console Google Cloud , vai a Lakehouse.

   Vai a Lakehouse

2. Fai clic su Crea catalogo.

3. Fai clic su Catalogo federato.

   Vengono visualizzati i dettagli della Configurazione catalogo.

4. Per Origine del catalogo federato, seleziona Snowflake Horizon.

5. Per Posizione dei dati, seleziona la regione Lakehouse in cui vuoi creare il catalogo federato. Ad esempio, us-east4. Per ridurre al minimo la latenza (anche su internet pubblico), procedi nel seguente modo quando selezioni una regione:

   • Se il catalogo Snowflake si trova su AWS, seleziona la regioneGoogle Cloud più vicina alla tua regione AWS.

6. Fai clic su Continua.

   Vengono visualizzati i dettagli Dettagli connessione.

7. Nella sezione Dettagli catalogo remoto, nel campo Identificatore dell'account Snowflake, inserisci l'identificatore dell'account Snowflake. Ad esempio my_org-my_account.

8. Nel campo Warehouse Snowflake, inserisci il nome del tuo warehouse Snowflake.

9. In Secret, inserisci il nome del secret. Utilizza il formato seguente: projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.

10. (Facoltativo) Nel campo Nome di Service Directory, inserisci il percorso del servizio o dell'endpoint Service Directory. Questo è necessario solo se stai configurando un interconnessione privata (Cross-Cloud Interconnect).

11. Fai clic su Crea.

API REST

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  -d '{
    "catalog-type": "CATALOG_TYPE_FEDERATED",
    "federated-catalog-options": {
      "snowflake-catalog-info": {
        "account-identifier": "SNOWFLAKE_ACCOUNT_IDENTIFIER",
        "warehouse": "SNOWFLAKE_WAREHOUSE",
        "snowflake-role": "SNOWFLAKE_ROLE"
      },
      "refresh-options": {
        "refresh-schedule": {
          "refresh-interval": "REFRESH_INTERVAL"
        }
      }
    }
}' \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION"

gcloud CLI

Rete internet pubblica (nessun CCI)

    gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
        --project="PROJECT_ID" \
        --primary-location="REGION" \
        --catalog-type="federated" \
        --federated-catalog-type="snowflake" \
        --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
        --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
        --snowflake-role="SNOWFLAKE_ROLE" \
        --refresh-interval="REFRESH_INTERVAL" \
        --namespace-filters="NAMESPACE_FILTERS"
    

Di proprietà del cliente (CCI)

Se hai configurato un interconnessione privata, fornisci il riferimento al servizio Service Directory in modo che Lakehouse instradi il traffico in modo privato.

    gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
        --project="PROJECT_ID" \
        --primary-location="REGION" \
        --catalog-type="federated" \
        --federated-catalog-type="snowflake" \
        --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
        --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
        --snowflake-role="SNOWFLAKE_ROLE" \
        --refresh-interval="REFRESH_INTERVAL" \
        --namespace-filters="NAMESPACE_FILTERS" \
        --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"
    

Sostituisci quanto segue:

• PROJECT_ID: il tuo ID progetto Google Cloud .
• SNOWFLAKE_ACCOUNT_IDENTIFIER: l'identificatore del tuo account Snowflake.
• SNOWFLAKE_WAREHOUSE: il nome del catalogo Snowflake con cui vuoi eseguire la federazione.
• SNOWFLAKE_ROLE: il ruolo Snowflake specifico richiesto per la sessione. Ad esempio, ICEBERG_VIEW.
• FEDERATED_CATALOG_NAME: un nome per il catalogo federato Lakehouse.
• REGION: la regione Lakehouse in cui viene creato il catalogo federato.
• REFRESH_INTERVAL: (facoltativo) specifica la frequenza di aggiornamento delle informazioni del catalogo. Ad esempio, 300s.
• NAMESPACE_FILTERS: (Facoltativo) un elenco separato da virgole di spazi dei nomi da federare. Ad esempio, ns1,ns2. Se omesso, verranno inclusi tutti gli spazi dei nomi.
• NAMESPACE: lo spazio dei nomi del servizio Service Directory.
• SERVICE_NAME: il nome del servizio Service Directory.
• ENDPOINT_NAME: il nome dell'endpoint Service Directory.

Collega l'identità in Snowflake

Dopo aver creato il catalogo, devi collegare l'identità del account di servizio a un utente di servizio in Snowflake.

1. Estrai l'ID service account Lakehouse (Subject) dai dettagli del catalogo.

   Puoi ottenerlo dalla risposta JSON del comando di creazione (campo biglake-service-account-id).

   In alternativa, puoi eseguire il comando describe sul catalogo per ottenere il valore:

   gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
   --project="PROJECT_ID"

   Cerca biglake-service-account-id nell'output.

2. Accedi all'istanza di gestione Snowflake ed esegui il seguente script per stabilire la relazione di attendibilità con l'identità di servizio Lakehouse:

   USE ROLE ACCOUNTADMIN;
   
   CREATE USER SNOWFLAKE_SERVICE_USER
   TYPE = SERVICE
   WORKLOAD_IDENTITY = (
     TYPE = GCP
     SUBJECT = 'LAKEHOUSE_SERVICE_ACCOUNT_ID'
   )
   DEFAULT_ROLE = SNOWFLAKE_ROLE
   COMMENT = 'Service user for Lakehouse federation over WIF';
   
   -- Also explicitly GRANT permissions to the role
   GRANT ROLE SNOWFLAKE_ROLE TO USER SNOWFLAKE_SERVICE_USER;

   Sostituisci quanto segue:

   • SNOWFLAKE_SERVICE_USER: un nome per il nuovo utente di servizio in Snowflake.
   • LAKEHOUSE_SERVICE_ACCOUNT_ID: l'ID service account estratto nel passaggio precedente.
   • SNOWFLAKE_ROLE: il ruolo Snowflake (deve corrispondere al ruolo specificato durante la creazione del catalogo).

Verificare la connessione

Verifica che il ciclo di aggiornamento dei metadati in background del catalogo sia stato completato correttamente e che gli spazi dei nomi siano sincronizzati.

gcloud CLI

1. Verifica che lo stato di aggiornamento indichi esito positivo:

   gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
     --project="PROJECT_ID" \
     --location="REGION"

2. Verifica che gli schemi del database remoto vengano visualizzati come spazi dei nomi sincronizzati:

   gcloud alpha biglake iceberg namespaces list \
     --catalog="FEDERATED_CATALOG_NAME" \
     --project="PROJECT_ID" \
     --location="REGION"

API REST

1. Verifica lo stato di sincronizzazione della federazione dei cataloghi:

   curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json" \
     -H "x-goog-user-project: PROJECT_ID" \
     "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME"

2. Elenca gli spazi dei nomi sincronizzati:

   curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json" \
     -H "x-goog-user-project: PROJECT_ID" \
     "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces"

3. Elenca le tabelle in uno spazio dei nomi sincronizzato:

   curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json" \
     -H "x-goog-user-project: PROJECT_ID" \
     "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces/NAMESPACE_NAME/tables"

Passaggi successivi

• Utilizza Lakehouse cross-cloud ed esegui query sulle tabelle.
• Risolvi i problemi relativi a Lakehouse cross-cloud.