Informazioni sull'accesso ai dati cross-cloud

La funzionalità di accesso ai dati cross-cloud consente di eseguire query sui dati archiviati in altri provider cloud direttamente da Google Cloud senza eseguire la migrazione dei file o creare pipeline ETL complesse con Cross-Cloud Interconnect.

Nell'ambito di Lakehouse senza confini, questa funzionalità ti consente di eseguire analisi unificate e applicare l'AI ai tuoi set di dati distribuiti utilizzando BigQuery, ambienti Apache Spark autonomi o Managed Service for Apache Spark.

Oltre alle query analitiche, puoi utilizzare i dati federati per insight e governance basati sull'AI:

  • Analisi conversazionale: Crea agenti specializzati basati sulle tue fonti di dati esatte, incluse tabelle cross-cloud, per analizzare i dati su più cloud da un'unica conversazione.
  • Knowledge Catalog: utilizza le funzionalità di Knowledge Catalog per la profilazione e gli approfondimenti dei dati con origini dati federate.

Casi d'uso

Lakehouse supporta diversi casi d'uso chiave per accedere ai dati di più provider cloud:

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

Come funziona l'accesso ai dati cross-cloud

Le query Lakehouse recuperano i dati remoti utilizzando la seguente procedura:

  1. Rilevamento dei metadati: Google Cloudil Lakehouse si connette a cataloghi REST Apache Iceberg remoti, come Databricks Unity o AWS Glue. Lakehouse rileva i dati senza copiare alcun file. A seconda del provider di cataloghi remoto, Lakehouse esegue l'autenticazione in modo sicuro tramite Secret Manager o la federazione di token OpenID Connect con Google come provider di identità (federazione di token OIDC).
  2. Trasporto sicuro:la scelta di instradare il traffico su un interconnessione privata (ad esempio Dedicated CCI o Partner Interconnect) riduce significativamente i costi di trasferimento dei dati rispetto a internet pubblico e rende la latenza altamente prevedibile.
  3. Esecuzione ottimizzata: quando le query leggono i dati dai cloud remoti, Lakehouse memorizza temporaneamente nella cache locale questi segmenti di dati all'interno di Google Cloud su uno spazio di archiviazione specializzato. Le query successive utilizzano la cache locale, il che evita una parte significativa dei costi di uscita cross-cloud.

Cataloghi supportati

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

Concetti principali

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

Livello metadati

Il livello dei metadati si connette agli endpoint remoti del catalogo REST di Apache Iceberg per sincronizzare i metadati delle risorse Iceberg (spazio dei nomi, tabella) in base a un intervallo di aggiornamento. Lakehouse esegue l'autenticazione in modo sicuro con le credenziali OAuth archiviate in Secret Manager o nella federazione di 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 di Amazon Web Services (AWS) tramite un'interconnessione cross-cloud 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 vengono trasferiti tramite una connessione di rete privata tra Google Cloud e AWS, evitando la rete internet pubblica.
  • Costi ridotti: potenzialmente tariffe in uscita inferiori da AWS rispetto all'uscita da internet, soprattutto se combinato con la capacità di interconnessione privata.
  • Rendimento coerente:latenza di rete e larghezza di banda più prevedibili rispetto a internet pubblico.

Panoramica dell'architettura

Per abilitare le query private, configura un percorso da BigQuery al tuo bucket AWS Amazon S3 tramite l'interconnessione privata. Un componente chiave di Google Cloud Virtual Private Cloud (VPC) è 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, che vengono sottoposti a provisioning utilizzando AWS PrivateLink.

L'utilizzo di un bilanciatore del carico interno con più interfacce di rete elastiche (ENI) come backend è essenziale per il bilanciamento del carico, la scalabilità e l'alta affidabilità. Ciò vale sia che utilizzi Dedicated Interconnect 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 del bilanciamento del carico interno Google Cloud .
  3. L'ILB riceve le richieste da BigQuery e le distribuisce ai backend configurati.
  4. I backend del bilanciatore del carico interno sono gruppi di endpoint di rete (NEG) di connettività ibrida, ognuno dei quali punta all'indirizzo IP privato di un'interfaccia di rete in AWS VPC.
  5. Il traffico scorre dall'ILB, attraverso i NEG, attraverso l'interconnessione privata, fino alle ENI AWS.
  6. Le interfacce di rete AWS, parte di un endpoint VPC di interfaccia Amazon S3 (AWS PrivateLink), forniscono l'accesso privato al servizio Amazon S3.

Internet pubblico (nessun CCI)

Se non configuri un interconnessione privata, le query al catalogo remoto vengono inviate tramite la rete internet pubblica per impostazione predefinita.

Quando esegui query sui dati su internet pubblico, considera 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 di uscita:il trasferimento di dati comporta addebiti standard per l'uscita da internet dal tuo provider cloud remoto (ad esempio AWS), che sono in genere superiori alle tariffe di uscita dell'interconnessione privata.
  • Latenza variabile:le prestazioni di rete, la larghezza di banda e la latenza dipendono dal routing e dalla congestione di internet pubblico, con conseguenti tempi di esecuzione delle query meno prevedibili rispetto a un interconnessione privata dedicata.
  • Configurazione semplificata:non richiede infrastrutture di rete aggiuntive, peering VPC o configurazione di Service Directory in Google Cloud o nel tuo provider di servizi cloud remoto.

Panoramica dell'architettura

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

Il flusso di lavoro della query internet pubblica segue questo processo:

  1. BigQuery avvia una query su una tabella federata definita nel catalogo Lakehouse.
  2. Lakehouse si autentica in modo sicuro con il 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 su internet pubblico per identificare i file di dati sottostanti pertinenti (ad esempio in AWS Amazon S3).
  4. Le richieste di accesso ai dati per gli oggetti sottostanti vengono inviate direttamente da Google Cloud su internet pubblico utilizzando la crittografia TLS standard.
  5. Il servizio di archiviazione remota verifica la richiesta utilizzando credenziali temporanee con ambito fornite da Lakehouse e restituisce i blocchi di dati richiesti su internet pubblico a Google Cloud.

Memorizzazione nella cache intelligente

Quando esegui query sui dati cloud remoti, Lakehouse memorizza automaticamente nella cache i blocchi di dati recuperati localmente entro Google Cloud. La memorizzazione nella cache viene attivata automaticamente per tutte le query cross-cloud per ridurre al minimo le tariffe di uscita dai provider di servizi cloud remoti. Le query successive che hanno come target i dati memorizzati nella cache vengono lette direttamente dallo spazio di archiviazione Google Cloud locale anziché recuperare nuovamente i dati nei cloud.

Risparmi sui costi del traffico in uscita

Durante l'esecuzione della query iniziale, Lakehouse recupera i blocchi di dati richiesti dal provider di servizi cloud remoto e popola la cache locale. Le query successive che hanno come target gli stessi blocchi di dati vengono lette direttamente dalla cache Google Cloud locale anziché recuperare nuovamente i dati tra i cloud.

Per i carichi di lavoro con pattern di query ripetuti sullo stesso set di dati, la memorizzazione nella cache riduce le tariffe di uscita cross-cloud gestendo le richieste di dati dall'archiviazione locale. Il risparmio effettivo sui costi in uscita dipende da fattori quali i pattern di accesso alle query, i tassi di modifica dei dati e la conservazione della cache nella regione di destinazione. Google Cloud

Verificare l'utilizzo della cache e i risparmi sui costi in uscita nelle statistiche dei job

Per verificare i tassi di successo della cache e il risparmio sui costi in uscita per una query, esamina le statistiche della query nella console o nell'API BigQuery (JobStatistics2). Poiché una query può fare riferimento a dati di più provider, le statistiche del job forniscono un campo object_storage_stats (objectStorageStats) ripetuto con una voce per ogni provider cloud a cui è stato eseguito l'accesso durante l'esecuzione.

Ogni voce object_storage_stats riporta le seguenti metriche:

  • cloud_provider (cloudProvider): il provider di servizi cloud che ospita lo spazio di archiviazione degli oggetti (ad esempio, AWS o AZURE).
  • cache_bytes_read (cacheBytesRead): il numero totale di byte letti dalla cache Google Cloud locale, evitando una lettura dell'archiviazione di oggetti remota.
  • object_storage_bytes_read (objectStorageBytesRead): il totale dei byte letti direttamente dallo spazio di archiviazione degli oggetti del provider cloud remoto.

Considerazioni sulla residenza dei dati e sulla giurisdizione

La creazione di un catalogo o di una connessione federata in una regione Google Cloud memorizza i dati memorizzati nella cache localmente all'interno di quella regione di destinazione.

Se i dati del cloud remoto si trovano in una regione geografica o giurisdizione diversa (ad esempio, AWS Amazon S3 nell'Unione Europea accoppiato al calcolo BigQuery in us-east4), l'interrogazione cross-cloud archivia copie memorizzate nella cache dei dati remoti inattivi nella regione Google Cloud di destinazione. L'utente o l'amministratore che crea la connessione o il catalogo deve assicurarsi che la memorizzazione nella cache tra giurisdizioni diverse sia conforme ai requisiti di residenza dei dati, sovranità e conformità dei dati della propria organizzazione.

Supporto della crittografia e di CMEK

Le chiavi di crittografia gestite dal cliente (CMEK) non sono supportate per la memorizzazione nella cache di Lakehouse. Tutti i blocchi di dati memorizzati nella cache sono criptati at-rest utilizzandoGoogle-owned and Google-managed encryption keyspredefinito.

Se la tua organizzazione applica il vincolo di policy dell'organizzazione Limitare i servizi non CMEK (constraints/gcp.restrictNonCmekServices), Lakehouse disattiva automaticamente la memorizzazione nella cache per le query che accedono a tabelle con limitazioni. Le query vengono comunque eseguite correttamente, ma non memorizzano nella cache i blocchi di dati né usufruiscono dei risparmi in uscita correlati alla cache.

Passaggi successivi