Panoramica del trasferimento di schemi e dati

Questo documento illustra i concetti e le attività per trasferire lo schema e i dati dal data warehouse esistente a BigQuery.

La migrazione del data warehouse nel cloud è un processo complesso che richiede pianificazione, risorse e tempo. Per gestire questa complessità, devi affrontare la migrazione del datawarehouse in modo graduale e iterativo. Eseguire diverse iterazioni della migrazione dello schema e dei dati può migliorare il risultato.

Processo di migrazione di schemi e dati

All'inizio del percorso di migrazione, disponi di sistemi upstream che alimentano il data warehouse esistente e sistemi a valle che utilizzano i dati nei report, nelle 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 di avvio prima della migrazione.

Lo stato finale del tuo percorso è avere il maggior numero possibile di casi d'uso in esecuzione su BigQuery. Questo stato consente di ridurre al minimo l'utilizzo del data warehouse esistente per poi eliminarlo gradualmente. Puoi controllare quali casi d'uso vengono migrati e quando, dando la priorità durante la fase di preparazione e scoperta della migrazione.

Trasferisci schema e dati in BigQuery

Nella fase di pianificazione della migrazione, devi identificare i casi d'uso di cui vuoi eseguire la migrazione. Poi avvia le iterazioni della migrazione nella fase di execute. Per gestire le iterazioni durante l'esecuzione dell'ambiente di analisi con interruzioni minime, segui questo processo generale:

Trasferisci le tabelle e configura e testa i processi downstream.
- Trasferisci il gruppo di tabelle per ogni caso d'uso in BigQuery senza alcuna modifica utilizzando BigQuery Data Transfer Service o un altro strumento ETL. Per informazioni sugli strumenti, consulta la sezione Trasferimento iniziale dei dati.
- Configura 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 nei flussi etichettati come B. Altre continuano a leggere dal data warehouse esistente, come mostrato nei flussi etichettati come A.
Configurare alcuni processi upstream di test per scrivere dati nelle tabelle BigQuery al posto di (o in aggiunta al) data warehouse esistente.

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

A questo punto, hai tre flussi di dati:
1. Esistente. I dati e i processi sono rimasti invariati e ancora incentrati sul data warehouse esistente.
2. Offload. I processi upstream alimentano il data warehouse esistente, i dati vengono scaricati in BigQuery e poi alimentano i processi downstream.
3. Migrazione completa. I processi upstream e downstream non scrivono o leggono più dal data warehouse esistente.
  Il seguente diagramma mostra un sistema con tutti questi tre flussi:
Seleziona altri casi d'uso per la migrazione, quindi vai al passaggio 1 per avviare una nuova iterazione di esecuzione. Continua a eseguire l'iterazione seguendo questi passaggi finché non sarà stata eseguita la migrazione completa di tutti i tuoi casi d'uso in BigQuery. Quando selezioni i casi d'uso, puoi esaminare di nuovo quelli che sono rimasti nello stato con stato offload per eseguire la migrazione completa. Per i casi d'uso per cui viene eseguita la migrazione completa, valuta la possibilità di continuare il processo di evoluzione seguendo le linee guida riportate nella sezione Evolvere lo schema in BigQuery.

Evoluzione dello schema in BigQuery

Lo schema di data warehouse definisce il modo in cui sono strutturati i dati e definisce le relazioni tra le entità di dati. Lo schema è il fulcro della progettazione dei dati e influenza molti processi, sia a monte che a valle.

La migrazione di un data warehouse offre un'opportunità unica per far evolvere lo schema dopo lo spostamento a BigQuery. Questa sezione introduce le linee guida per l'evoluzione dello schema tramite una serie di passaggi. Queste linee guida ti aiutano a mantenere l'ambiente di data warehouse in esecuzione durante le modifiche allo schema con interruzioni minime per i processi upstream e downstream.

I passaggi di questa sezione sono incentrati sulla trasformazione dello schema per un singolo caso d'uso.

A seconda di quanto vuoi proseguire nell'evoluzione, potresti fermarti a un passaggio intermedio o continuare fino a quando il tuo sistema non sarà completamente evoluto.

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

Prima di continuare con i passaggi successivi, assicurati che i processi upstream e downstream del tuo caso d'uso siano già in scrittura e in lettura da BigQuery. Tuttavia, è anche possibile partire da uno stato intermedio in cui solo il processo downstream legge da BigQuery. In questo scenario, applica solo le linee guida per la parte a valle. Il seguente diagramma illustra un caso d'uso in cui i processi upstream e downstream scrivono e leggono dalle tabelle di BigQuery.
Applicare 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 della query. Per maggiori dettagli, consulta la discussione e l'esempio per le tabelle partizionate e consulta Discussione ed esempio per le tabelle in cluster.
2. Reindirizza i processi upstream e downstream alle nuove tabelle.
Crea viste delle facciate.

Se vuoi evolvere ulteriormente il tuo schema al di là delle ottimizzazioni semplici, crea viste della facciata per le tue tabelle. Il pattern della facciata è un metodo di progettazione che maschera il codice o le strutture sottostanti per nascondere complessità. In questo caso, le viste delle tabelle mascherano le tabelle sottostanti per nascondere la complessità causata dalle modifiche alle tabelle dovute ai processi downstream.

Le viste possono descrivere un nuovo schema, privo di debito tecnico e modellato in base a nuovi scenari di importazione e consumo.

In background, le tabelle e la definizione della query di visualizzazione possono cambiare. Tuttavia, le viste astraggono queste modifiche come dettaglio di implementazione interno del data warehouse e restituiscono sempre gli stessi risultati. Questo livello di astrazione costituito dalle viste delle facciate isola i sistemi a monte e a valle dalle modifiche per tutto il tempo necessario e segnala le modifiche solo quando opportuno.
Trasforma i processi downstream.

Puoi trasformare alcuni dei processi downstream per leggere dalle viste della facciata anziché dalle tabelle effettive. Questi processi beneficeranno già dello schema evoluto. È trasparente a questi processi che in background le viste delle facciate recuperano comunque i dati dallo schema BigQuery di origine, come mostrato nel seguente schema:

Abbiamo descritto per prima cosa 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 alla trasformazione di processi upstream che non sono visibili agli stakeholder non tecnici. Tuttavia, puoi avviare la trasformazione con i processi upstream. La priorità di queste attività dipende completamente dalle tue esigenze.
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 in base al nuovo schema e, successivamente, modifichi la definizione della query delle viste delle facciate. Alcune viste 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 diagramma seguente:

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

Un vantaggio delle viste Facciate è che i processi downstream possono continuare la loro trasformazione in modo indipendente dalle modifiche allo schema sottostanti e dalle modifiche nei processi upstream.
Sviluppa completamente il tuo caso d'uso.

Infine, puoi trasformare i restanti processi upstream e downstream. Una volta evolute tutte queste metriche per scriverle nelle nuove tabelle e leggere dalle nuove viste delle facciate, ne modifichiamo le definizioni 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.

Se le viste delle facciate non aggregano i campi o filtrano le colonne, puoi configurare i processi downstream per leggere dalle tabelle evolute e poi ritirare le visualizzazioni delle facciate per ridurre la complessità, come mostrato nel diagramma seguente:

Eseguire un trasferimento iniziale dello schema e dei dati

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

Ti consigliamo di trasferire lo schema senza alcuna modifica durante le iterazioni iniziali della migrazione. Questo offre i seguenti vantaggi:

Le pipeline di dati che alimentano il tuo data warehouse non devono essere regolate per un nuovo schema.
Non aggiungere un nuovo schema all'elenco del materiale di formazione per il tuo personale.
Puoi utilizzare strumenti automatizzati per eseguire il trasferimento di schemi e dati.

Inoltre, i proof of concept (PDC) 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 effettuare il trasferimento iniziale utilizzando uno dei diversi approcci.

Per i data warehouse di Amazon Redshift e Teradata, puoi utilizzare BigQuery Data Transfer Service per caricare lo schema e i dati direttamente dal tuo sistema esistente in BigQuery. Cloud Storage è ancora utilizzato per archiviare i dati nell'ambito del processo di migrazione.
Per qualsiasi data warehouse, puoi estrarre i file contenenti il tuo schema e i tuoi dati, caricarli in 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 Scegliere un metodo di importazione dati.

Considera la trasformazione dei dati

A seconda del formato di estrazione dei dati e se vuoi tagliare o arricchire i dati prima di caricarli in BigQuery, puoi includere un passaggio per trasformarli. Puoi trasformare i dati nell'ambiente esistente o su Google Cloud:

Se trasformi i dati nell'ambiente attuale, valuta in che modo la capacità di calcolo e gli strumenti disponibili potrebbero limitare la velocità effettiva. Inoltre, se stai criptando i dati durante il processo di trasformazione, valuta se hai bisogno di tempo di trasferimento aggiuntivo o larghezza di banda della rete.
Se trasformi i dati su Google Cloud, consulta Caricare dati con uno strumento ETL per saperne di più sulle opzioni a tua disposizione.

Estrai lo schema e i dati esistenti nei 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, consigliamo di utilizzare AVRO, ORC o Parquet, dove le informazioni sullo schema sono incorporate nei dati. Se scegli CSV o un formato dati semplice e delimitato simile, devi specificare lo schema separatamente. La modalità dipende dal metodo di trasferimento dei dati selezionato. Ad esempio, per il caricamento in gruppo, 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 tua piattaforma esistente, copiali nello spazio di archiviazione gestione temporanea nel tuo ambiente esistente.

Carica i file in Cloud Storage

A meno che tu non utilizzi 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 da trasferire 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 cloud provider, 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 lo strumento gsutil. Lo strumento gsutil supporta i caricamenti paralleli multi-thread, si ripristina in caso di errori e cripta il traffico in transito per motivi di sicurezza.
- Se non puoi utilizzare gsutil, puoi provare uno strumento di terze parti di un partner di Google.
- Se la larghezza di banda della tua rete è limitata, puoi utilizzare le tecniche di compressione per limitare la dimensione dei dati oppure modificare la connessione attuale a Google Cloud per aumentare la larghezza di banda.
Se non riesci a raggiungere una larghezza di banda di rete sufficiente, puoi eseguire un trasferimento offline utilizzando Transfer Appliance.

Quando crei il bucket Cloud Storage e trasferisci i dati attraverso 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 illustrate in Scegli un metodo di trasferimento.

Per ulteriori informazioni sui caricamenti una tantum, consulta Introduzione al caricamento dei dati da Cloud Storage nella documentazione di BigQuery. Per ulteriori informazioni sui caricamenti pianificati a intervalli regolari, consulta la Panoramica dei trasferimenti di Cloud Storage nella documentazione di BigQuery Data Transfer Service.

Carica dati con uno strumento ETL

Se i dati richiedono ulteriori trasformazioni quando vengono caricati 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 trasformazioni e connettori preconfigurati.
Dataflow. Questo strumento definisce ed esegue trasformazioni di dati e grafici di arricchimento complessi utilizzando il modello Apache Beam. Dataflow è serverless e completamente gestito da Google, permettendoti di accedere a una capacità di elaborazione praticamente illimitata.
Dataproc. Viene eseguito il cluster Apache Spark e Apache Hadoop su un servizio cloud completamente gestito.
Strumenti di terze parti. Contatta uno dei nostri partners. 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 dati è gsutil ed è previsto un passaggio di trasformazione che sfrutta Dataflow e scrive direttamente in BigQuery, ad esempio 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. Lo strumento gsutil copia i dati in un bucket Cloud Storage. Dataflow legge il bucket gestione temporanea e sposta i dati in BigQuery.

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

Tuttavia, come quando hai trasferito lo schema, il caricamento dei dati fa parte di un processo iterativo. Le iterazioni successive possono iniziare espandendo la portata dei dati da trasferire a BigQuery. In seguito, puoi reindirizzare i feed di dati upstream a BigQuery per eliminare la necessità di mantenere in esecuzione il data warehouse esistente. Questi argomenti vengono trattati nella prossima sezione.

Convalidare i dati

Ora che i dati sono in BigQuery, puoi verificare l'esito positivo del trasferimento dei dati con lo strumento di convalida dei dati (DVT). DVT è uno strumento open source con interfaccia a riga di comando Python che consente di confrontare i dati provenienti da varie origini con il tuo target in BigQuery. Puoi specificare quali aggregazioni vuoi eseguire (ad esempio conteggio, somma, media) e le colonne a cui applicarle. Per ulteriori informazioni, consulta Automatizzare la convalida dei dati con la DVT.

Ripeti il trasferimento iniziale

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

Un sottoinsieme dei tuoi dati è ora disponibile in BigQuery. Ti stai preparando ad aumentare l'impatto dei dati utilizzati in BigQuery e quindi a ridurre la dipendenza dal data warehouse esistente.

Il metodo che scegli per le iterazioni successive dipende da quanto è importante per il tuo caso d'uso aggiornare i dati al secondo attuale. Se i tuoi analisti di dati possono lavorare con dati incorporati nel data warehouse a intervalli ricorrenti, scegli l'opzione pianificata. Puoi creare trasferimenti pianificati in modo simile al trasferimento iniziale. Puoi utilizzare 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 crei un pattern di nome per la tabella per includerle. Infine, devi impostare una pianificazione ricorrente per l'esecuzione del trasferimento.

D'altra parte, se il tuo caso d'uso richiede un accesso quasi istantaneo a nuovi dati, hai bisogno di un approccio in modalità flusso. Puoi scegliere tra due opzioni:

Configura una pipeline di carico con i prodotti Google Cloud. Google fornisce una serie di modelli Dataflow per i flussi di dati per facilitare questa attività.
Utilizza una soluzione di uno dei nostri partners.

Nel breve termine, l'aumento dell'impatto dei dati BigQuery e l'utilizzo dei dati per i processi downstream dovrebbe essere incentrato sulla soddisfazione dei tuoi casi d'uso prioritari, con l'obiettivo a medio termine di spostare il tuo data warehouse esistente. Utilizza le iterazioni iniziali in modo appropriato e non perdere molte risorse per perfezionare le pipeline di importazione dal data warehouse esistente in BigQuery. In definitiva, dovrai adattare le pipeline in modo che non utilizzino il data warehouse esistente.

Ottimizza lo schema

Basta eseguire la migrazione delle tabelle così come sono in BigQuery, per sfruttare le sue caratteristiche uniche. Ad esempio, non è necessario ricreare gli indici, eseguire il riordinamento dei blocchi di dati (aspirazione dei dati) o eventuali tempi di inattività o peggioramenti delle prestazioni dovuti agli upgrade delle versioni.

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 associati allo schema rimangono.
Le ottimizzazioni delle query sono limitate e potrebbero essere necessarie di nuovo se lo schema viene aggiornato in una fase successiva.
Non puoi sfruttare appieno le altre funzionalità di BigQuery, come i campi nidificati e ripetuti, il partizionamento e il clustering.

Mentre ti avvicini al trasferimento finale, ti consigliamo di migliorare le prestazioni del sistema applicando il partizionamento e il clustering alle tabelle create nello schema.

Partizionamento

BigQuery ti consente di suddividere i dati in segmenti, chiamati partizioni, che rendono più semplice ed 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 pseudo-colonne per partizionare automaticamente i dati durante l'importazione. Le query che coinvolgono partizioni più piccole possono essere più performanti 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. Di conseguenza, ti consigliamo di creare tabelle partizionate anche se il tuo schema non viene modificato.

Clustering

In BigQuery, non viene utilizzato alcun indice per eseguire query sui dati. Le prestazioni di BigQuery sono ottimizzate dal modello sottostante, dalle tecniche di archiviazione e query e dall'architettura a parallelismo massivo. Quando esegui una query, maggiore è la quantità di dati elaborati, più macchine vengono aggiunte per analizzare i dati e aggregare i risultati contemporaneamente. Questa tecnica consente di scalare in modo ottimale in set di dati di grandi dimensioni, al contrario della ricostruzione degli indici.

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 da te 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 al fatto che non sia possibile eseguire il clustering. Con le colonne in cluster, le query eliminano anche le analisi dei dati non necessari e possono calcolare più velocemente i dati aggregati perché i blocchi collocano record con valori simili.

Esamina le tue query per individuare le colonne utilizzate di frequente per i filtri e crea le tue tabelle con il clustering su queste colonne. Il clustering richiede tabelle partizionate ed è definito anche al momento della creazione della tabella.

Denormalizzazione

La migrazione dei dati è un processo iterativo. Di conseguenza, una volta spostato lo schema iniziale nel cloud, eseguito ottimizzazioni semplici e testato 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.

In passato, gli schemi di data warehouse utilizzavano i seguenti modelli:

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

BigQuery supporta sia gli schemi a stella che quelli a fiocco di neve, ma la sua rappresentazione dello schema nativa non è nessuno di questi due. Utilizza campi nidificati e ripetuti per una rappresentazione più naturale dei dati. Per ulteriori informazioni, consulta lo schema di esempio nella documentazione di BigQuery.

La modifica dello schema per utilizzare campi nidificati e ripetuti è un'eccellente scelta evolutiva. Riduce il numero di join necessari per le query e allinea lo schema alla rappresentazione interna dei dati di BigQuery. Internamente, BigQuery organizza i dati utilizzando il modello di Dremel e li archivia in un formato di archiviazione a colonne chiamato condensatore.

Per decidere il miglior approccio di denormalizzazione per il tuo caso, consulta le best practice per la denormalizzazione in BigQuery e le tecniche per gestire le modifiche allo schema.

Passaggi successivi

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

Puoi anche scoprire come passare da tecnologie di data warehouse specifiche a BigQuery: