Panoramica del trasferimento di schema e dati

Questo documento illustra i concetti e le attività per il trasferimento dello schema e dei dati dal data warehouse esistente a BigQuery.

La migrazione del data warehouse al cloud è un processo complesso che richiede pianificazione, risorse e tempo. Per gestire questa complessità, devi approcciare la migrazione del data warehouse in modo graduale e iterativo. L'esecuzione di diverse iterazioni della migrazione di schema e dati può migliorare il risultato.

Processo di migrazione di schema e dati

All'inizio del percorso di migrazione, hai sistemi upstream che alimentano il tuo data warehouse esistente e sistemi downstream che utilizzano questi dati in report, dashboard e come feed per altri processi.

Questo flusso generale di dati supporta molti casi d'uso di analisi, come mostrato nel seguente diagramma:

Stato iniziale prima della migrazione.

Lo stato finale del tuo percorso è avere il maggior numero possibile di casi d'uso in esecuzione su BigQuery. Questo stato ti consente di ridurre al minimo l'utilizzo del tuo data warehouse esistente e, infine, di eliminarlo gradualmente. Sei tu a decidere quali casi d'uso migrare e quando, assegnando loro la priorità durante la fase di preparazione e scoperta della migrazione.

Trasferisci lo schema e i dati in BigQuery

Nella fase di pianificazione della migrazione, identifichi i casi d'uso di cui vuoi eseguire la migrazione. Poi, avvia le iterazioni della migrazione nella fase di esecuzione. Per gestire le iterazioni durante l'esecuzione dell'ambiente di analisi con un'interruzione minima, segui questa procedura generale:

  1. Trasferisci le tabelle e configura e testa i processi downstream.

    • Trasferisci il gruppo di tabelle per ogni caso d'uso a BigQuery senza modifiche, utilizzando BigQuery Data Transfer Service o un altro strumento ETL. Per informazioni sugli strumenti, consulta la sezione Trasferimento iniziale dei dati.
    • Configura le versioni di test dei processi downstream per la lettura dalle tabelle BigQuery.

    Questo passaggio iniziale divide il flusso di dati. Il seguente diagramma mostra il flusso risultante. Alcuni sistemi downstream ora leggono da BigQuery, come mostrato dai flussi etichettati con B. Altri continuano a leggere dal data warehouse esistente, come mostrato nei flussi etichettati con A.

    I processi upstream alimentano il data warehouse esistente. Alcuni di questi dati vengono inviati a processi downstream, mentre altri vengono inviati a BigQuery tramite BigQuery Data Transfer Service e da lì a diversi processi downstream.

  2. Configura alcuni processi upstream di test per scrivere i dati nelle tabelle BigQuery anziché (o in aggiunta) nel data warehouse esistente.

    Dopo il test, configura i processi upstream e downstream di produzione per scrivere e leggere nelle tabelle BigQuery. Questi processi possono connettersi a BigQuery utilizzando l'API BigQuery e incorporare nuovi prodotti cloud come Data Studio e Dataflow.

    A questo punto, hai tre flussi di dati:

    1. Esistente. I dati e i processi rimangono invariati e sono ancora incentrati sul tuo data warehouse esistente.
    2. Offloaded. I processi upstream alimentano il tuo data warehouse esistente, i dati vengono trasferiti a BigQuery e poi alimentano i processi downstream.
    3. Migrazione completata. I processi upstream e downstream non scrivono o leggono più dal data warehouse esistente.

      Il seguente diagramma mostra un sistema con tutti e tre i flussi:

      Flusso di workload attraverso più percorsi.

  3. Seleziona altri casi d'uso per la migrazione, quindi vai al passaggio 1 per avviare una nuova iterazione di esecuzione. Continua a ripetere questi passaggi fino a quando tutti i tuoi casi d'uso non saranno stati completamente migrati in BigQuery. Quando selezioni i casi d'uso, puoi rivedere quelli che sono rimasti nello stato di offload per spostarli in uno stato di migrazione completa. Per i casi d'uso di cui è stata eseguita la migrazione completa, valuta la possibilità di continuare il processo di evoluzione seguendo le linee guida riportate in Evolvi lo schema in BigQuery.

    Passaggio finale dei casi d'uso di cui è stata eseguita la migrazione.

Evolvi lo schema in BigQuery

Lo schema del data warehouse definisce la struttura dei dati e le relazioni tra le entità di dati. Lo schema è al centro della progettazione dei dati e influenza molti processi, sia upstream che downstream.

La migrazione di un data warehouse offre un'opportunità unica per evolvere lo schema dopo lo spostamento in BigQuery. Questa sezione presenta le linee guida per l'evoluzione dello schema utilizzando una serie di passaggi. Queste linee guida ti aiutano a mantenere in esecuzione l'ambiente del data warehouse durante le modifiche allo schema con un'interruzione minima dei processi upstream e downstream.

I passaggi descritti in questa sezione si concentrano sulla trasformazione dello schema per un singolo caso d'uso.

A seconda di quanto vuoi spingerti oltre con l'evoluzione, puoi fermarti a un passaggio intermedio o continuare fino a quando il tuo sistema non sarà completamente evoluto.

  1. Trasferire un caso d'uso così com'è in BigQuery.

    Prima di procedere con i passaggi successivi, assicurati che i processi upstream e downstream del tuo caso d'uso stiano già scrivendo e leggendo da BigQuery. Tuttavia, è anche possibile iniziare da uno stato intermedio in cui solo il processo downstream legge da BigQuery. In questo scenario, applica solo le linee guida per la parte downstream. Il seguente diagramma illustra un caso d'uso in cui i processi upstream e downstream scrivono e leggono dalle tabelle in BigQuery.

    I processi upstream alimentano le tabelle BigQuery e da lì i processi downstream.

  2. Applica ottimizzazioni leggere.

    1. Ricrea le tabelle applicando il partizionamento e il clustering. Per questa attività, puoi utilizzare il metodo di creazione di una tabella da un risultato di query. Per maggiori dettagli, consulta la discussione e l'esempio per le tabelle partizionate e la discussione e l'esempio per le tabelle in cluster.
    2. Reindirizza i processi upstream e downstream alle nuove tabelle.

  3. Crea viste delle facciate.

    Se vuoi evolvere ulteriormente lo schema oltre alle ottimizzazioni di base, crea viste di facciata per le tabelle. Il pattern Facade è un metodo di progettazione che maschera il codice o le strutture sottostanti per nascondere la complessità. In questo caso, le viste facciata mascherano le tabelle sottostanti per nascondere la complessità causata dalle modifiche alle tabelle dai processi downstream.

    Le viste possono descrivere un nuovo schema, privo di debito tecnico e modellato tenendo conto di nuovi scenari di importazione e consumo.

    Dietro le quinte, le tabelle e la definizione della query di visualizzazione stessa possono cambiare. Tuttavia, le viste astraggono queste modifiche come dettaglio di implementazione interna del tuo data warehouse e restituiscono sempre gli stessi risultati. Questo livello di astrazione costituito da visualizzazioni di facciata isola i sistemi upstream e downstream dalle modifiche per tutto il tempo necessario e le mostra solo quando opportuno.

  4. Trasforma i processi downstream.

    Puoi trasformare alcuni dei tuoi processi downstream in modo che leggano dalle viste facciata anziché dalle tabelle effettive. Questi processi trarranno già vantaggio dallo schema evoluto. Per questi processi è trasparente che, in background, le viste di facciata ottengono comunque i dati dallo schema BigQuery di origine, come mostrato nel seguente diagramma:

    I processi upstream alimentano le tabelle BigQuery. Alcuni alimentano i processi downstream. Altri confluiscono in viste di facciata, che a loro volta confluiscono in processi downstream evoluti.

    Abbiamo descritto prima la trasformazione del processo downstream. In questo modo, puoi mostrare il valore aziendale più rapidamente, sotto forma di dashboard o report di cui è stata eseguita la migrazione, rispetto a quanto faresti se trasformassi i processi upstream che non sono visibili agli stakeholder non tecnici. Tuttavia, è possibile iniziare la trasformazione con i processi upstream. La priorità di queste attività dipende interamente dalle tue esigenze.

  5. Trasforma i processi upstream.

    Puoi trasformare alcuni dei tuoi processi upstream per scrivere nel nuovo schema. Poiché le viste sono di sola lettura, crei tabelle basate sul nuovo schema e poi modifichi la definizione della query delle viste di facciata. Alcune visualizzazioni continueranno a eseguire query sullo schema di origine, mentre altre eseguiranno query sulle tabelle appena create o eseguiranno un'operazione SQL UNION su entrambe, come mostrato nel seguente diagramma:

    I processi upstream alimentano le tabelle BigQuery, ma non alimentano più i processi downstream. Le tabelle BigQuery vengono invece inserite in viste di facciata, che a loro volta vengono inserite in processi downstream evoluti.

    A questo punto, puoi sfruttare i campi nidificati e ripetuti quando crei le nuove tabelle. In questo modo puoi denormalizzare ulteriormente il tuo modello e sfruttare direttamente la rappresentazione dei dati a colonne sottostante di BigQuery.

    Un vantaggio delle viste di facciata è che i processi downstream possono continuare la loro trasformazione indipendentemente da queste modifiche dello schema sottostante e dalle modifiche nei processi upstream.

  6. Sviluppare completamente il tuo caso d'uso.

    Infine, puoi trasformare i restanti processi upstream e downstream. Quando tutti questi elementi sono stati evoluti per scrivere nelle nuove tabelle e leggere dalle nuove viste di facciata, modifica le definizioni delle query delle viste di facciata in modo che non leggano più dallo schema di origine. Puoi quindi ritirare le tabelle nel modello di origine dal flusso di dati. Il seguente diagramma mostra lo stato in cui le tabelle di origine non vengono più utilizzate.

    I processi upstream originali non sono più in uso. Rimangono solo i processi upstream evoluti, che alimentano le tabelle evolute, che alimentano le viste di facciata, che alimentano tutti i processi downstream.

    Se le viste facciata non aggregano campi o colonne di filtro, puoi configurare i processi downstream in modo che leggano dalle tabelle evolute e poi ritirare le viste facciata per ridurre la complessità, come mostrato nel seguente diagramma:

    Nella configurazione finale, sia le tabelle BigQuery sia le tabelle evolute alimentano le viste facciata, che sono l'unica origine per i processi downstream.

Esegui un trasferimento iniziale dello schema e dei dati

Questa sezione illustra le considerazioni pratiche per la migrazione dello schema e dei dati da un data warehouse esistente a BigQuery.

Ti consigliamo di trasferire lo schema senza apportare modifiche durante le iterazioni iniziali della migrazione. In questo modo, potrai usufruire dei seguenti vantaggi:

  • Le pipeline di dati che alimentano il tuo data warehouse non devono essere modificate per un nuovo schema.
  • Eviti di aggiungere un nuovo schema all'elenco dei materiali di formazione per il tuo personale.
  • Puoi utilizzare strumenti automatizzati per eseguire il trasferimento di schemi e dati.

Inoltre, le proof of concept (PoC) e altre attività di esplorazione dei dati che sfruttano le funzionalità cloud possono procedere senza ostacoli, anche mentre la migrazione avviene in parallelo.

Scegli un metodo di trasferimento

Puoi eseguire il trasferimento iniziale utilizzando uno dei diversi approcci.

  • Per i data warehouse Amazon Redshift e Teradata, puoi utilizzare BigQuery Data Transfer Service per caricare lo schema e i dati direttamente dal sistema esistente in BigQuery. Cloud Storage viene comunque utilizzato per la gestione temporanea dei dati nell'ambito del processo di migrazione.
  • Per qualsiasi data warehouse, puoi estrarre i file che contengono lo schema e i dati, caricarli su Cloud Storage e quindi utilizzare una delle seguenti opzioni per caricare lo schema e i dati da questi file in BigQuery:

Per ulteriori considerazioni sulla scelta di un metodo di trasferimento dei dati, consulta Scelta di un metodo di importazione dati dati.

Valuta la trasformazione dei dati

A seconda del formato di estrazione dei dati e del fatto che tu voglia o meno tagliare o arricchire i dati prima di caricarli in BigQuery, potresti includere un passaggio per trasformarli. Puoi trasformare i dati nell'ambiente esistente o su Cloud de Confiance:

  • Se trasformi i dati nell'ambiente attuale, considera in che modo la capacità di calcolo e gli strumenti disponibili potrebbero limitare la velocità effettiva. Inoltre, se arricchisci i dati durante il processo di trasformazione, valuta se hai bisogno di più tempo per il trasferimento o di una maggiore larghezza di banda della rete.
  • Se trasformi i dati su Cloud de Confiance, consulta Carica i dati utilizzando uno strumento ETL per ulteriori informazioni sulle opzioni disponibili.

Estrai lo schema e i dati esistenti in file

La tua piattaforma esistente probabilmente fornisce uno strumento per esportare i dati in un formato indipendente dal fornitore, come Apache AVRO o CSV. Per ridurre la complessità del trasferimento, ti consigliamo di utilizzare AVRO, ORC o Parquet, in cui le informazioni sullo schema sono incorporate nei dati. Se scegli CSV o un formato dei dati delimitato semplice simile, devi specificare lo schema separatamente. La modalità di esecuzione dipende dal metodo di trasferimento dei dati selezionato. Ad esempio, per il caricamento collettivo, puoi specificare uno schema al momento del caricamento o consentire il rilevamento automatico dello schema in base ai contenuti del file CSV.

Man mano che estrai questi file dalla piattaforma esistente, copiali nello spazio di archiviazione di gestione temporanea nell'ambiente esistente.

Carica i file su Cloud Storage

A meno che tu non stia utilizzando BigQuery Data Transfer Service per caricare i dati direttamente da un data warehouse Amazon Redshift o Teradata esistente, devi caricare i file estratti in un bucket in Cloud Storage. A seconda della quantità di dati che stai trasferendo e della larghezza di banda di rete disponibile, puoi scegliere tra le seguenti opzioni di trasferimento:

  • Se i dati estratti si trovano in un altro provider cloud, utilizza Storage Transfer Service.

  • Se i dati si trovano in un ambiente on-premise o in una struttura di colocation con una buona larghezza di banda di rete, utilizza Google Cloud CLI. gcloud CLI supporta i caricamenti paralleli multi-thread, riprende dopo gli errori e cripta il traffico in transito per motivi di sicurezza.

    • Se non puoi utilizzare gcloud CLI, puoi provare uno strumento di terze parti di un partner di Google.
    • Se la larghezza di banda della rete è limitata, puoi utilizzare tecniche di compressione per limitare le dimensioni dei dati oppure puoi modificare la connessione attuale a Cloud de Confiance per aumentare la larghezza di banda.

  • Se non riesci a ottenere una larghezza di banda di rete sufficiente, puoi eseguire un trasferimento offline utilizzando un Transfer Appliance.

Quando crei il bucket Cloud Storage e trasferisci i dati tramite la rete, riduci al minimo la latenza di rete scegliendo la località più vicina al tuo data center. Se possibile, scegli la località del bucket in modo che corrisponda a quella del set di dati BigQuery.

Per informazioni dettagliate sulle best practice per lo spostamento dei dati in Cloud Storage, inclusa la stima dei costi, consulta Strategie per il trasferimento di set di big data.

Carica lo schema e i dati in BigQuery

Carica lo schema e i dati in BigQuery utilizzando una delle opzioni descritte in Scegli un metodo di trasferimento.

Per saperne di più sui caricamenti una tantum, consulta Introduzione al caricamento dei dati da Cloud Storage nella documentazione di BigQuery. Per saperne di più sui caricamenti pianificati a intervalli regolari, consulta Introduzione ai trasferimenti di dati di Cloud Storage nella documentazione di BigQuery Data Transfer Service.

Carica i dati utilizzando uno strumento ETL

Se i tuoi dati richiedono un'ulteriore trasformazione durante il caricamento in BigQuery, utilizza una delle seguenti opzioni:

  • Cloud Data Fusion. Questo strumento crea graficamente pipeline di dati ETL/ELT completamente gestite utilizzando una libreria open source di connettori e trasformazioni preconfigurati.
  • Dataflow. Questo strumento definisce ed esegue grafici complessi di trasformazione e arricchimento dei dati utilizzando il modello Apache Beam. Dataflow è serverless e completamente gestito da Google, il che ti consente di accedere a una capacità di elaborazione praticamente illimitata.
  • Managed Service for Apache Spark. In questo modo, il cluster Apache Spark e Apache Hadoop viene eseguito su un servizio cloud completamente gestito.
  • Strumenti di terze parti. Contatta uno dei nostri partner. Possono fornire scelte efficaci quando vuoi esternalizzare la creazione di una pipeline di dati.

Il seguente diagramma mostra il pattern descritto in questa sezione. Lo strumento di trasferimento dei dati è gcloud CLI e c'è un passaggio di trasformazione che sfrutta Dataflow e scrive direttamente in BigQuery, magari utilizzando il connettore I/O Google BigQuery integrato di Apache Beam.

Il data warehouse esistente copia i dati in uno spazio di archiviazione temporaneo on-premise. gcloud CLI copia i dati in un bucket Cloud Storage. Dataflow legge dal bucket di gestione temporanea e sposta i dati in BigQuery.

Dopo aver caricato un set iniziale di dati in BigQuery, puoi iniziare a sfruttare le potenti funzionalità di BigQuery.

Tuttavia, come per il trasferimento dello schema, il caricamento dei dati fa parte di un processo iterativo. Le iterazioni successive possono iniziare espandendo l'impatto dei dati trasferiti in BigQuery. In seguito, puoi cambiare percorso dei feed di dati upstream verso BigQuery per eliminare la necessità di mantenere in esecuzione il tuo data warehouse esistente. Questi argomenti vengono approfonditi nella sezione successiva.

Convalida i dati

Ora che i tuoi dati sono in BigQuery, puoi verificare l'esito positivo del trasferimento dei dati con lo Data Validation Tool (DVT). DVT è uno strumento open source con interfaccia a riga di comando Python che consente di confrontare i dati di varie origini con il target in BigQuery. Puoi specificare le aggregazioni da eseguire (ad esempio conteggio, somma, media) e le colonne a cui applicarle. Per saperne di più, consulta Automatizza la convalida dei dati con DVT.

Esegui l'iterazione del trasferimento iniziale

Questa sezione illustra come procedere dopo il trasferimento iniziale dei dati per sfruttare al meglio BigQuery.

Un sottoinsieme dei tuoi dati è ora in BigQuery. Ti stai preparando ad aumentare l'impronta dei dati utilizzati in BigQuery e, di conseguenza, a ridurre la dipendenza dal tuo data warehouse esistente.

Il metodo che scegli per le iterazioni successive dipende dall'importanza per il tuo caso d'uso di avere dati aggiornati al secondo corrente. Se i tuoi analisti di dati possono lavorare con dati incorporati nel data warehouse a intervalli ricorrenti, l'opzione pianificata è la soluzione migliore. Puoi creare trasferimenti pianificati in modo simile al trasferimento iniziale. Utilizzi BigQuery Data Transfer Service, altri strumenti ETL come Storage Transfer Service di Google o implementazioni di terze parti.

Se utilizzi BigQuery Data Transfer Service, devi prima decidere quali tabelle spostare. Poi, crea un pattern del nome della tabella per includere queste tabelle. Infine, imposti una pianificazione ricorrente per l'esecuzione del trasferimento.

D'altra parte, se il tuo caso d'uso richiede un accesso quasi istantaneo ai nuovi dati, devi adottare un approccio in modalità flusso. Sono disponibili due opzioni:

  • Configura una pipeline di caricamento con i prodotti Cloud de Confiance . Google fornisce un insieme di modelli Dataflow per flussi di dati per facilitare questa attività.
  • Utilizza una soluzione di uno dei nostri partner.

A breve termine, l'aumento dell'impatto dei dati BigQuery e del loro utilizzo per i processi downstream dovrebbe concentrarsi sulla soddisfazione dei casi d'uso con priorità più alta, con l'obiettivo a medio termine di abbandonare il data warehouse esistente. Utilizza le iterazioni iniziali con saggezza e non spendere molte risorse per perfezionare le pipeline di importazione dal tuo data warehouse esistente a BigQuery. In definitiva, dovrai adattare queste pipeline in modo che non utilizzino il data warehouse esistente.

Ottimizza lo schema

La semplice migrazione delle tabelle così come sono in BigQuery ti consente di sfruttare le sue funzionalità uniche. Ad esempio, non è necessario ricreare gli indici, riorganizzare i blocchi di dati (vacuuming) o prevedere tempi di inattività o un peggioramento delle prestazioni a causa degli upgrade di versione.

Tuttavia, mantenere intatto il modello di data warehouse oltre le iterazioni iniziali della migrazione presenta anche degli svantaggi:

  • I problemi esistenti e il debito tecnico associato allo schema rimangono.
  • Le ottimizzazioni delle query sono limitate e potrebbe essere necessario ripeterle se lo schema viene aggiornato in un secondo momento.
  • Non sfrutti appieno altre funzionalità di BigQuery, come i campi nidificati e ripetuti, il partizionamento e il clustering.

Mentre ti prepari a eseguire un trasferimento finale, ti consigliamo di migliorare le prestazioni del sistema applicando il partizionamento e il clustering alle tabelle che crei nello schema.

Partizionamento

BigQuery ti consente di dividere i dati in segmenti, chiamati partizioni, che semplificano e rendono più efficiente la gestione e l'esecuzione di query sui dati. Puoi partizionare le tabelle in base a una colonna TIMESTAMP o DATE oppure BigQuery può aggiungere pseudocolonne per partizionare automaticamente i dati durante l'importazione. Le query che coinvolgono partizioni più piccole possono essere più efficienti perché analizzano solo un sottoinsieme dei dati e possono ridurre i costi riducendo al minimo il numero di byte letti.

Il partizionamento non influisce sulla struttura esistente delle tabelle. Pertanto, ti consigliamo di creare tabelle partizionate anche se lo schema non viene modificato.

Clustering

In BigQuery non vengono utilizzati indici per eseguire query sui dati. Le prestazioni di BigQuery sono ottimizzate dal modello, dalle tecniche di archiviazione e query e dall'architettura massicciamente parallela sottostanti. Quando esegui una query, più dati vengono elaborati, più macchine vengono aggiunte per analizzare i dati e aggregare i risultati contemporaneamente. Questa tecnica si adatta bene a set di dati di grandi dimensioni, mentre la ricostruzione degli indici no.

Tuttavia, c'è spazio per un'ulteriore ottimizzazione delle query con tecniche come il clustering. Con il clustering, BigQuery ordina automaticamente i dati in base ai valori di alcune colonne specificate e li colloca in blocchi di dimensioni ottimali. Il clustering migliora le prestazioni delle query rispetto al mancato utilizzo del clustering. Con il clustering, BigQuery può stimare meglio il costo di esecuzione della query rispetto a quando non viene utilizzato. Con le colonne raggruppate in cluster, le query evitano anche le scansioni di dati non necessari e possono calcolare le aggregazioni più rapidamente perché i blocchi raggruppano i record con valori simili.

Esamina le query per individuare le colonne utilizzate di frequente per i filtri e crea le tabelle con il clustering su queste colonne. Per saperne di più sul clustering, consulta Introduzione alle tabelle in cluster.

Denormalizzazione

La migrazione dei dati è un processo iterativo. Pertanto, una volta spostato lo schema iniziale nel cloud, eseguite ottimizzazioni di base e testati alcuni casi d'uso chiave, potrebbe essere il momento di esplorare funzionalità aggiuntive che traggono vantaggio dalla progettazione di base di BigQuery. Questi includono campi nidificati e ripetuti.

Storicamente, gli schemi dei data warehouse utilizzano i seguenti modelli:

  • Schema a stella. Questo è un modello denormalizzato, in cui una tabella dei fatti raccoglie metriche come importo dell'ordine, sconto e quantità, insieme a un gruppo di chiavi. Queste chiavi appartengono a tabelle delle dimensioni come cliente, fornitore, regione e così via. Graficamente, il modello assomiglia a una stella, con la tabella dei fatti al centro circondata dalle tabelle delle dimensioni.
  • Schema Snowflake. È simile allo schema a stella, ma con le tabelle delle dimensioni normalizzate, il che conferisce allo schema l'aspetto di un fiocco di neve unico.

BigQuery supporta gli schemi a stella e a fiocco di neve, ma la sua rappresentazione nativa dello schema non è nessuna delle due. Utilizza invece campi nidificati e ripetuti per una rappresentazione più naturale dei dati. Per saperne di più, consulta lo schema di esempio nella documentazione di BigQuery.

Modificare lo schema per utilizzare campi nidificati e ripetuti è un'ottima scelta evolutiva. Riduce il numero di join richiesti per le query e allinea lo schema alla rappresentazione interna dei dati di BigQuery. Internamente, BigQuery organizza i dati utilizzando il modello Dremel e li archivia in un formato di archiviazione colonnare chiamato Capacitor.

Per decidere l'approccio di denormalizzazione migliore per il tuo caso, considera l'utilizzo di campi nidificati e ripetuti in BigQuery, nonché le tecniche per gestire le modifiche allo schema.

Passaggi successivi

Scopri di più sui seguenti passaggi della migrazione del data warehouse:

Puoi anche scoprire di più sul passaggio da tecnologie di data warehouse specifiche a BigQuery: