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 di servizi 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 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 origini dati esatte, incluse le tabelle cross-cloud, per analizzare i dati su più cloud da una singola conversazione.
  • Knowledge Catalog: utilizza le funzionalità di Knowledge Catalog per la profilazione dei dati e gli insight con le origini dati federate.

Casi d'uso

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

  • La riduzione dello spostamento dei dati ti consente di eseguire query sui dati archiviati in altri ambienti cloud direttamente, semplificando l'accesso ai dati e l'elaborazione.
  • 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.
  • L'AI e il machine learning senza confini ti consentono di applicare modelli di AI, agenti autonomi e machine learning direttamente ai dati remoti senza eseguirne la migrazione.

Come funziona l'accesso ai dati cross-cloud

Lakehouse esegue query sui dati remoti utilizzando la seguente procedura:

  1. Rilevamento dei metadati: Google Cloud's Lakehouse si connette ai cataloghi REST Apache Iceberg remoti, come Databricks Unity o AWS Glue. Lakehouse rileva i dati senza copiare alcun file. A seconda del provider del catalogo 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, CCI dedicata 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 questi segmenti di dati localmente in Google Cloud 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 provider di cataloghi remoti:

  • Databricks Unity Catalog: supportato su Amazon Web Services (AWS) e Google Cloud.
  • AWS Glue: supportato su Amazon Web Services (AWS).
  • Catalogo Snowflake Horizon: supportato su Amazon Web Services (AWS) e Google Cloud.
  • SAP Business Data Cloud (BDC): supportato tramite il connettore SAP BDC.

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 dei 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 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 internet pubblico o un'interconnessione privata dedicata.

Seleziona il metodo di trasporto che soddisfa i 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 internet pubblico.
  • Costi ridotti: costi in uscita potenzialmente inferiori da AWS rispetto all'uscita internet, soprattutto se combinati con la capacità di interconnessione privata.
  • Prestazioni coerenti: latenza e larghezza di banda della rete più prevedibili rispetto a internet pubblico.

Panoramica dell'architettura

Per abilitare le query private, configura un percorso da BigQuery al bucket Amazon S3 di AWS tramite l'interconnessione privata. Un componente chiave del Google Cloud Virtual Private Cloud (VPC) (VPC) è un bilanciatore del carico interno (ILB). L'ILB distribuisce le richieste da BigQuery agli endpoint privati di Amazon S3 all'interno del VPC AWS, che vengono sottoposti a provisioning utilizzando AWS PrivateLink.

L'utilizzo di un ILB con più interfacce di rete elastiche (ENI) come backend è essenziale per il bilanciamento del carico, la scalabilità e l'alta affidabilità. Questo vale sia se utilizzi CCI dedicata sia 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 di the Google Cloud ILB.
  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, ognuno dei quali punta all'indirizzo IP privato di un'ENI nel VPC AWS.
  5. Il traffico scorre dall'ILB, attraverso i NEG, attraverso l'interconnessione privata, fino alle ENI AWS.
  6. Le ENI AWS, che fanno parte di un endpoint di interfaccia VPC Amazon S3 (AWS PrivateLink), forniscono l'accesso privato al servizio Amazon S3.

Internet pubblico (senza CCI)

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

Quando esegui query sui dati tramite 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 i protocolli TLS standard su internet pubblico.
  • Costi di uscita: il trasferimento di dati comporta costi di uscita internet standard dal provider di servizi cloud remoto (ad esempio, AWS), che in genere sono superiori alle tariffe di uscita dell'interconnessione privata.
  • Latenza variabile: le prestazioni della 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 infrastruttura di rete aggiuntiva, peering VPC o configurazione di Service Directory in Google Cloud o nel provider di servizi cloud remoto.

Panoramica dell'architettura

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

Il flusso di lavoro delle query su internet pubblico segue questa procedura:

  1. BigQuery avvia una query su una tabella federata definita nel catalogo Lakehouse.
  2. Lakehouse esegue l'autenticazione in modo sicuro con il catalogo Apache Iceberg remoto utilizzando le credenziali archiviate in Secret Manager o nella federazione di 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 tramite internet pubblico utilizzando la crittografia TLS standard.
  5. Il servizio di archiviazione remota verifica la richiesta utilizzando le credenziali temporanee con ambito limitato fornite da Lakehouse e restituisce i blocchi di dati richiesti tramite internet pubblico a Google Cloud.

Passaggi successivi