Informazioni sull'accesso ai dati cross-cloud

La funzionalità di accesso ai dati cross-cloud ti consente di eseguire query sui dati archiviati in altri provider cloud direttamente da Google Cloud senza migrare i file o creare pipeline ETL complesse. Le query possono essere instradate tramite la rete internet pubblica o utilizzare Cross-Cloud Interconnect per il trasporto su rete privata.

Nell'ambito del lakehouse senza confini, questa funzionalità unifica i workload di analisi e AI nei tuoi set di dati distribuiti tramite BigQuery, ambienti Apache Spark autonomi o Managed Service for Apache Spark.

Oltre a eseguire query analitiche, puoi creare agenti di analisi conversazionale basati sulle tue tabelle distribuite, incluse le origini cross-cloud, per analizzare i dati su più cloud da un'unica conversazione. Puoi anche utilizzare Knowledge Catalog per la profilazione dei dati e gli insight su piattaforme remote.

Casi d'uso

Lakehouse supporta diversi casi d'uso chiave per l'accesso ai dati su più provider cloud:

  • La riduzione dello spostamento dei dati ti consente di eseguire query sui dati archiviati in altri ambienti cloud direttamente, semplificando l'accesso e l'elaborazione dei dati.
  • L'analisi unificata ti consente di eseguire analisi avanzate con funzionalità coerenti e ottimizzazione dell'hardware su tutti i tuoi dati, indipendentemente da dove si trovano.
  • AI e ML senza confini ti consente di applicare modelli di AI, agenti autonomi e machine learning direttamente ai tuoi dati remoti senza migrarli.

Architettura

Il seguente diagramma illustra l'architettura di accesso ai dati cross-cloud di Lakehouse:

Architettura dell'accesso ai dati cross-cloud di Lakehouse tra Google Cloud, Amazon Web Services (AWS) e partner SaaS.
L'architettura di Lakehouse connette i motori di analisi e AI Google Cloud a cataloghi cloud esterni, archivi di oggetti e partner SaaS.

Il diagramma precedente illustra l'architettura in Google Cloud e negli ambienti cloud e SaaS esterni:

  • Google Cloud: fornisce AI, governance, analisi e accesso ai dati cross-cloud tra set di dati remoti:
    • Agenti ed esperienze AI: crea agenti autonomi in Conversational Analytics e Gemini Enterprise che cercano dati e significato semantico in Knowledge Catalog ed eseguono query tramite motori di analisi ed elaborazione.
    • Knowledge Catalog: offre governance unificata e derivazione dei dati, oltre a insight sui dati, profilazione e prodotti di dati, sincronizzando i metadati e la derivazione da Lakehouse.
    • Motori di analisi ed elaborazione: esegue i workload di BigQuery SQL, BigQuery AI e Looker o elabora i dati remoti con Managed Service for Apache Spark e i motori aperti (Apache Spark, Apache Flink e Trino) risolvendo i metadati e leggendo le tabelle tramite Lakehouse.
    • Accesso ai dati cross-cloud di Lakehouse: esegue query sui dati remoti in loco senza migrazione dei file o pipeline ETL:
      • Sincronizzazione dei metadati: rileva e sincronizza i metadati delle tabelle su Apache Iceberg REST e Delta Sharing utilizzando il catalogo di runtime Lakehouse, autentica tramite OpenID Connect (OIDC) o Secret Manager e fornisce credenziali temporanee con ambito.
      • Funzionalità cross-cloud (AWS): memorizza nella cache i blocchi di dati letti in Google Cloud utilizzando una cache read-through a livello di blocco (Memorizzazione intelligente nella cache (cache locale)) e instrada il traffico su Dedicated Cross-Cloud Interconnect (CCI), Partner Interconnect o internet (con TLS) utilizzando il trasporto di rete cross-cloud.
  • Origini dati cloud e SaaS esterne: ospita i cataloghi remoti, i cloud di dati SaaS e l'archiviazione di oggetti:
    • Cataloghi cloud e SaaS esterni: sincronizza i metadati dai cataloghi di dati cloud (AWS Glue Data Catalog su AWS, Databricks Unity Catalog e Snowflake Horizon Catalog su AWS o Google Cloud) e dai cloud di dati SaaS (Salesforce Data Cloud, Workday Data Lake su AWS oGoogle Cloude SAP Business Data Cloud (BDC)) tramite l'API REST Iceberg e Delta Sharing (per SAP BDC).
    • Archiviazione di oggetti cloud esterni (AWS): archivia le tabelle Apache Iceberg (file di dati Parquet) e le tabelle Amazon S3 in Amazon S3 per letture con blocco dirette su CCI o su internet (con TLS).

Come funziona l'accesso ai dati cross-cloud

Lakehouse esegue query sui dati remoti utilizzando il seguente processo:

  1. Rilevamento dei metadati: il lakehouse di Google Cloud si connette ai cataloghi REST Apache Iceberg remoti, come Databricks Unity Catalog o AWS Glue. Lakehouse rileva i dati senza copiare alcun file. A seconda del provider del catalogo remoto, Lakehouse si autentica in modo sicuro tramite Secret Manager o la federazione di token OIDC con Google come provider di identità.
  2. Trasporto sicuro: la scelta di instradare il traffico su un'interconnessione privata (ad esempio, Dedicated CCI o Partner Interconnect) riduce notevolmente i costi di trasferimento dei dati rispetto alla rete internet pubblica e rende la latenza altamente prevedibile.
  3. Esecuzione ottimizzata: quando attivi la memorizzazione nella cache cross-cloud sul tuo catalogo o sulla tua connessione federati, Lakehouse memorizza nella cache i blocchi di file recuperati localmente nella regione di esecuzione delle query Google Cloud . Le query successive che hanno come target gli stessi blocchi di file leggono direttamente dalla cache locale anziché recuperare nuovamente i file dal cloud remoto, il che contribuisce a ridurre i costi del traffico in uscita tra cloud e migliora le prestazioni delle query.

Cataloghi supportati

Lakehouse supporta l'esecuzione di query sui dati dei seguenti provider di cataloghi remoti:

Concetti principali

Questa sezione descrive i componenti chiave essenziali per l'utilizzo della funzionalità di accesso ai dati cross-cloud.

Livello dei metadati

Il livello di metadati si connette agli endpoint del catalogo REST Apache Iceberg remoto per sincronizzare i metadati delle risorse Iceberg (spazio dei nomi, tabella) in base a un intervallo di aggiornamento. Lakehouse si autentica in modo sicuro con le credenziali OAuth archiviate in Secret Manager o con la federazione dei token OIDC.

Livello di trasporto

Il livello di trasporto consente a BigQuery e ai motori open source di eseguire query sui dati utilizzando i metadati sincronizzati dal livello dei metadati. Per alcuni tipi di cataloghi remoti, Lakehouse supporta l'esecuzione di query sui dati tramite la rete internet pubblica o un'interconnessione privata dedicata.

Seleziona il metodo di trasporto che corrisponde ai tuoi requisiti di architettura e sicurezza:

Di proprietà del cliente (CCI)

Puoi configurare BigQuery per eseguire query sui dati archiviati nei bucket Amazon S3 o nei container Azure Data Lake Storage Gen2 (ADLS Gen2) su una connessione Cross-Cloud Interconnect privata utilizzando Dedicated Cross-Cloud Interconnect o Partner Cross-Cloud Interconnect.

L'utilizzo di un'interconnessione privata offre i seguenti vantaggi:

  • Maggiore sicurezza: i dati viaggiano attraverso una connessione di rete privata tra Google Cloud e AWS o Azure, evitando la rete internet pubblica.
  • Costi ridotti: potenziali addebiti per il traffico in uscita da AWS o Azure inferiori rispetto al traffico in uscita verso internet, soprattutto se combinati con la capacità di interconnessione privata.
  • Prestazioni costanti: latenza e larghezza di banda della rete più prevedibili rispetto alla rete internet pubblica.

Panoramica dell'architettura

Per abilitare le query private, configura un percorso da BigQuery al tuo bucket Amazon S3 o container ADLS Gen2 tramite la tua interconnessione privata. Un componente chiave del Virtual Private Cloud (VPC)Google Cloud è un bilanciatore del carico interno (ILB). L'ILB distribuisce le richieste da BigQuery agli endpoint privati per Amazon S3 all'interno del tuo VPC AWS (di cui è stato eseguito il provisioning utilizzando AWS PrivateLink) o per ADLS Gen2 all'interno della tua rete virtuale Azure (VNet), di cui è stato eseguito il provisioning utilizzando Azure Private Link.

L'utilizzo di un ILB con più interfacce di rete elastiche (ENI) o schede di interfaccia di rete (NIC) come backend è essenziale per il bilanciamento del carico, la scalabilità e l'alta affidabilità. Questo vale sia che utilizzi Dedicated CCI o Partner Interconnect.

Il flusso di lavoro delle query private segue questa procedura:

  1. BigQuery utilizza una connessione configurata con un servizio Service Directory.
  2. Service Directory risolve il nome del servizio nell'indirizzo IP interno dell'ILB Google Cloud .
  3. L'ILB riceve le richieste da BigQuery e le distribuisce ai backend configurati.
  4. I backend ILB sono gruppi di endpoint di rete (NEG) di connettività ibrida, ciascuno dei quali punta all'indirizzo IP privato di un ENI nel tuo VPC AWS o di una NIC nella tua rete virtuale Azure.
  5. Il traffico passa dall'ILB, attraverso i NEG, tramite l'interconnessione privata, agli ENI AWS o alle NIC Azure.
  6. Le ENI AWS, parte di un endpoint dell'interfaccia VPC Amazon S3 (AWS PrivateLink), o le NIC Azure, parte di un endpoint privato ADLS Gen2 (Azure Private Link), forniscono l'accesso privato al servizio Amazon S3 o ADLS Gen2.

Internet pubblico (senza CCI)

Se non configuri un'interconnessione privata, per impostazione predefinita le query al catalogo remoto vengono inviate tramite l'internet pubblico.

Quando esegui query sui dati tramite l'internet pubblico, tieni presente le seguenti implicazioni:

  • Crittografia standard: le richieste di accesso ai dati e i trasferimenti di dati vengono criptati in transito utilizzando protocolli TLS standard su internet pubblico.
  • Costi in uscita: il trasferimento di dati comporta addebiti standard per il traffico in uscita verso internet dal tuo cloud provider remoto (ad esempio AWS o Azure), che in genere sono superiori alle tariffe per il traffico in uscita di Interconnessione privata.
  • Latenza variabile: le prestazioni, la larghezza di banda e la latenza della rete dipendono dal routing e dalla congestione della rete internet pubblica, il che si traduce in tempi di esecuzione delle query meno prevedibili rispetto a un'interconnessione privata dedicata.
  • Configurazione semplificata: non richiede un'infrastruttura di networking aggiuntiva, il peering VPC o la configurazione di Service Directory in Google Cloud o nel tuo provider cloud remoto.

Panoramica dell'architettura

Quando esegui query sui dati tramite l'internet pubblico, Lakehouse si connette direttamente agli endpoint di archiviazione di oggetti e catalogo remoti senza richiedere un'infrastruttura di rete cloud privata Google Cloud o remota.

Il flusso di lavoro per le query su internet pubblico segue questo processo:

  1. BigQuery avvia una query su una tabella remota definita nel catalogo Lakehouse.
  2. Lakehouse si autentica in modo sicuro con il tuo catalogo Apache Iceberg remoto utilizzando le credenziali archiviate in Secret Manager o la federazione dei token OIDC.
  3. Lakehouse recupera i metadati della tabella e i file manifest tramite l'internet pubblico per identificare i file di dati sottostanti pertinenti (ad esempio in Amazon S3 o ADLS Gen2).
  4. Le richieste di accesso ai dati per gli oggetti sottostanti vengono inviate direttamente daGoogle Cloud tramite la rete internet pubblica utilizzando la crittografia TLS standard.
  5. Il servizio di archiviazione remoto verifica la richiesta utilizzando credenziali temporanee con ambito fornite da Lakehouse e restituisce i blocchi di file richiesti tramite la rete internet pubblica a Google Cloud.

Memorizzazione nella cache intelligente

Per ridurre i costi del traffico in uscita tra cloud e accelerare le query che leggono gli stessi blocchi di file, puoi attivare la memorizzazione nella cache tra cloud sui tuoi cataloghi federati Lakehouse e sulle connessioni tra cloud BigQuery senza costi aggiuntivi.

Quando attivi la memorizzazione nella cache cross-cloud, Lakehouse memorizza nella cache i blocchi di file recuperati da Amazon S3 o Azure Blob Storage localmente all'interno della regione di esecuzione delle query Google Cloud . Le query successive, incluse query diverse che hanno come target gli stessi blocchi di file, leggono direttamente dalla cache locale anziché recuperare nuovamente i file dal cloud remoto.

Google gestisce automaticamente la capacità, la conservazione e l'eliminazione della cache. I risparmi effettivi sui costi in uscita dipendono dai pattern di query, dalla frequenza con cui cambiano i file di origine e dalla conservazione della cache nella regione Google Clouddi destinazione. Prima di fornire i dati memorizzati nella cache, ogni query verifica i metadati e le autorizzazioni di accesso con l'origine di archiviazione remota, in modo da non leggere dati obsoleti o ignorare le autorizzazioni revocate.

La memorizzazione nella cache cross-cloud è disattivata per impostazione predefinita. Puoi attivare o disattivare la memorizzazione nella cache quando crei o aggiorni un catalogo federato Lakehouse o una connessione cross-cloud BigQuery. Per le istruzioni di configurazione, consulta la guida alla configurazione del tuo provider di catalogo supportato o Crea connessioni cross-cloud.

Verifica l'utilizzo della cache e il risparmio sui costi in uscita

Per verificare le percentuali di successo della cache e misurare i risparmi sui costi in uscita, controlla i dettagli del job nella console BigQuery o il campo objectStorageStats (object_storage_stats) nelle statistiche del job di query JobStatistics2 di BigQuery:

  • cloudProvider (cloud_provider): il cloud provider che ospita l'archivio di oggetti (ad esempio AWS o AZURE).
  • cacheBytesRead (cache_bytes_read): i byte totali letti dalla cache Google Cloud locale, evitando una lettura dello spazio di archiviazione degli oggetti remoto.
  • objectStorageBytesRead (object_storage_bytes_read): i byte totali letti direttamente dallo spazio di archiviazione degli oggetti del provider cloud.

Per istruzioni su come recuperare queste metriche utilizzando lo strumento a riga di comando bq, consulta Monitora l'utilizzo della cache e i risparmi sui costi in uscita.

Considerazioni sulla residenza dei dati e sulla giurisdizione

Quando attivi la memorizzazione nella cache cross-cloud, Lakehouse archivia temporaneamente le copie memorizzate nella cache dei file remoti at-rest nella regione Google Cloud in cui viene eseguita la query. Prima di abilitare la memorizzazione nella cache per i file che si trovano in un'altra regione geografica o giurisdizione (ad esempio, Amazon S3 o Azure Blob Storage nell'Unione Europea con query da us-east4), verifica che l'archiviazione di copie temporanee memorizzate nella cache nella regioneGoogle Cloud di destinazione soddisfi i requisiti di residenza dei dati e di conformità della tua organizzazione.

Supporto della crittografia e delle CMEK

I dati memorizzati nella cache vengono criptati at-rest utilizzando la chiaveGoogle-owned and Google-managed encryption keyspredefinita. Le chiavi di crittografia gestite dal cliente (CMEK) non sono supportate per la memorizzazione nella cache cross-cloud.

Se la tua organizzazione applica il vincolo della policy dell'organizzazione Limita i servizi non CMEK (constraints/gcp.restrictNonCmekServices), Lakehouse disattiva automaticamente la memorizzazione nella cache per le query che accedono alle tabelle limitate. Le query vengono comunque eseguite, ma leggono direttamente dallo spazio di archiviazione remoto senza memorizzare nella cache i blocchi di file.

Modalità di identità

Lakehouse supporta due modalità di identità per l'accesso ai dati cross-cloud:

  • Identità del servizio (predefinita): sia l'aggiornamento dei metadati in background sia le query vengono eseguiti utilizzando il account di servizio del catalogo, che può essere configurato con l'autenticazione OIDC (consigliata) o basata su secret.

  • Federazione delle identità utente: l'aggiornamento dei metadati in background viene eseguito utilizzando il account di servizio del catalogo, ma le query vengono eseguite utilizzando l'identità dell'utente finale e vengono propagate al catalogo remoto. In questo modo, il catalogo remoto può attribuire le query di Google Cloud agli utenti finali, consentendo l'applicazione delle autorizzazioni e la generazione di audit log. La federazione delle identità deve essere configurata nel catalogo remoto.

Passaggi successivi