Panoramica del trasferimento di schemi e dati

Questo documento descrive i concetti e le attività per trasferire lo schema e i 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 affrontare la migrazione del data warehouse in modo graduale e iterativo. Eseguire 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.

L'obiettivo finale è avere il maggior numero possibile di casi d'uso in esecuzione su BigQuery. Questo stato ti consente di ridurre al minimo l'utilizzo del data warehouse esistente e di eliminarlo gradualmente. Sei tu a decidere quali casi d'uso vengono migrati e quando, dando la priorità a quelli più importanti durante la fase di preparazione e scoperta della migrazione.

Trasferire schema e dati in BigQuery

Nella fase di pianificazione della migrazione, identifichi i casi d'uso di cui vuoi eseguire la migrazione. Quindi, avvia le iterazioni della migrazione nella fase Esegui. Per gestire le iterazioni durante l'esecuzione dell'ambiente di analisi con interruzioni minime, segui questa procedura di alto livello:

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 in modo che leggano 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 con B. Altri continuano a leggere dal data warehouse esistente, come mostrato nei flussi etichettati con A.
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 Looker 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. Eseguito l'offload. I processi upstream alimentano il data warehouse esistente, i dati vengono scaricati in BigQuery e poi alimentano i processi downstream.
3. Completamente migrato. I processi upstream e downstream non scrivono né leggono più dal data warehouse esistente.
  Il seguente diagramma mostra un sistema con tutti e tre questi flussi:
Seleziona altri casi d'uso per la migrazione, poi vai al passaggio 1 per avviare una nuova iterazione di esecuzione. Continua a ripetere questi passaggi finché tutti i tuoi casi d'uso non sono 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 completamente migrati, valuta la possibilità di continuare il processo di evoluzione seguendo le linee guida riportate in Evolvere lo schema in BigQuery.

Evolvere 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 il trasferimento a BigQuery. Questa sezione introduce 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 interruzioni minime ai 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 avanti con l'evoluzione, potresti fermarti a un passaggio intermedio o continuare finché il sistema non è completamente evoluto.

Trasferisci un caso d'uso così com'è a 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.
Applica le ottimizzazioni della luce.
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, nonché la discussione e l'esempio per le tabelle in cluster.
2. Reindirizza i processi upstream e downstream alle nuove tabelle.
Crea prospetti.

Se vuoi sviluppare ulteriormente lo schema oltre le ottimizzazioni leggere, crea viste facciata per le tabelle. Il pattern facciata è 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 visualizzazioni possono descrivere un nuovo schema, privo di debito tecnico e modellato tenendo presenti nuovi scenari di importazione e utilizzo.

A livello interno, le tabelle e la definizione della query di visualizzazione possono cambiare. Tuttavia, le viste astraggono queste modifiche come dettaglio di implementazione interna del data warehouse e restituiscono sempre gli stessi risultati. Questo livello di astrazione costituito da viste facciata isola i sistemi a monte e a valle dalle modifiche per tutto il tempo necessario e mostra le modifiche solo quando è opportuno.
Trasformare 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, internamente, le visualizzazioni facciata continuano a recuperare i dati dallo schema BigQuery di origine, come mostrato nel seguente diagramma:

Abbiamo descritto prima la trasformazione del processo a valle. In questo modo puoi mostrare più rapidamente il valore aziendale sotto forma di dashboard o report migrati, rispetto a quando trasformi 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.
Trasformare 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 poi modifichi la definizione della query delle viste facciata. Alcune visualizzazioni eseguiranno ancora 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 colonnare sottostante dei dati di BigQuery.

Un vantaggio delle viste facciata è che i processi downstream possono continuare la loro trasformazione indipendentemente da queste modifiche dello schema sottostanti e indipendentemente dalle modifiche nei processi upstream.
Evolvi completamente il tuo caso d'uso.

Infine, puoi trasformare i processi upstream e downstream rimanenti. Quando tutti questi elementi sono stati sviluppati per scrivere nelle nuove tabelle e per leggere dalle nuove viste facciata, modifichi le definizioni delle query delle viste 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.

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

Esegui 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 apportare modifiche durante le iterazioni iniziali della migrazione. In questo modo, avrai i seguenti vantaggi:

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

Inoltre, le prove di concetto 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 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 ancora utilizzato per preparare i 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 poi 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, vedi Scegliere un metodo di importazione dati dati.

Valuta 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, potresti includere un passaggio per trasformarli. Puoi trasformare i dati nell'ambiente esistente o su Google Cloud:

Se trasformi i dati nell'ambiente corrente, considera in che modo la capacità di calcolo e gli strumenti disponibili potrebbero limitare la velocità effettiva. Inoltre, se arricchisci i dati durante la trasformazione, valuta se hai bisogno di ulteriore tempo di trasferimento o larghezza di banda di rete.
Se trasformi i dati su Google Cloud, consulta Caricare i dati utilizzando uno strumento ETL per maggiori informazioni sulle opzioni disponibili.

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, ad esempio 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 di dati delimitati semplice simile, devi specificare lo schema separatamente. La modalità di esecuzione dipende dal metodo di trasferimento dei dati selezionato. Ad esempio, per il caricamento batch, puoi specificare uno schema al tempo di 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 su 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 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. La gcloud CLI supporta caricamenti paralleli multithread, riprende dopo gli errori e cripta il traffico in transito per motivi di sicurezza.
- Se non riesci a utilizzare gcloud CLI, puoi provare uno strumento di terze parti di un partner 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 corrente in Google Cloud per aumentare la larghezza di banda.
Se non riesci a ottenere una larghezza di banda 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 il trasferimento dei dati in Cloud Storage, inclusa la stima dei costi, consulta Strategie per il trasferimento di set di dati di grandi dimensioni.

Carica lo schema e i dati in BigQuery

Carica lo schema e i dati in BigQuery utilizzando una delle opzioni descritte in Scegliere 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 saperne di più sui caricamenti pianificati a intervalli regolari, consulta Panoramica dei trasferimenti di Cloud Storage nella documentazione di BigQuery Data Transfer Service.

Carica 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 trasformazioni e connettori 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 per Apache Spark. Esegue il cluster Apache Spark e Apache Hadoop 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 è l'interfaccia a riga di comando gcloud e c'è un passaggio di trasformazione che sfrutta Dataflow e scrive direttamente in BigQuery, magari utilizzando il connettore Google BigQuery I/O 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 staging e sposta i dati in BigQuery.

Dopo aver caricato un insieme 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'impronta dei dati trasferiti a BigQuery. Poi puoi reindirizzare i feed di dati upstream a BigQuery per eliminare la necessità di mantenere in esecuzione il data warehouse esistente. Questi argomenti vengono approfonditi nella sezione successiva.

Convalidare i dati

Ora che i dati si trovano in BigQuery, puoi verificare l'esito positivo del trasferimento dei dati con lo strumento di convalida dei dati (DVT). DVT è uno strumento CLI Python open source che consente di confrontare i dati di varie origini con la destinazione in BigQuery. Puoi specificare le aggregazioni da eseguire (ad esempio conteggio, somma, media) e le colonne a cui devono essere applicate. Per saperne di più, consulta Automatizzare la convalida dei dati con DVT.

Esegui l'iterazione sul trasferimento iniziale

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

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

Il metodo scelto per le iterazioni successive dipende dall'importanza per il tuo caso d'uso di avere dati aggiornati al secondo corrente. Se i tuoi analisti dei dati possono lavorare con i dati incorporati nel data warehouse a intervalli ricorrenti, un'opzione pianificata è la soluzione ideale. 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 di nomi di tabelle per includere queste tabelle. Infine, imposta 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, hai bisogno di un approccio di streaming. Sono disponibili due opzioni:

Configura una pipeline di caricamento con Google Cloud prodotti. Google fornisce un insieme di modelli di streaming Dataflow per facilitare questa attività.
Utilizza una soluzione di uno dei nostri partner.

Nel breve termine, l'aumento dell'impronta dei dati BigQuery e del loro utilizzo per i processi downstream deve concentrarsi sulla soddisfazione dei casi d'uso di massima priorità, con l'obiettivo a medio termine di abbandonare il data warehouse esistente. Utilizza le iterazioni iniziali in modo saggio e non sprecare molte risorse per perfezionare le pipeline di importazione dal data warehouse esistente a BigQuery. In definitiva, dovrai adattare queste pipeline in modo che non utilizzino il data warehouse esistente.

Ottimizzare lo schema

La semplice migrazione delle tabelle così come sono a BigQuery ti consente di sfruttare le sue funzionalità uniche. Ad esempio, non è necessario ricostruire gli indici, riorganizzare i blocchi di dati (pulizia) o prevedere tempi di inattività o degrado 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 potrebbero dover essere rifatte se lo schema viene aggiornato in un secondo momento.
Non sfrutti appieno altre funzionalità di BigQuery, come campi nidificati e ripetuti, partizionamento e clustering.

Man mano che ti avvicini al 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ù efficienti 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, dovresti prendere in considerazione la creazione di 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 è facilmente scalabile a set di dati enormi, mentre la ricostruzione degli indici non lo è.

Tuttavia, è possibile ottimizzare ulteriormente le 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 a quando non viene utilizzato. Con il clustering, BigQuery può stimare meglio il costo di esecuzione della query rispetto a una query senza clustering. Con le colonne in cluster, le query eliminano anche le scansioni di dati non necessari e possono calcolare gli aggregati più rapidamente perché i blocchi posizionano i record con valori simili.

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

Denormalizzazione

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

Storicamente, gli schemi dei data warehouse hanno utilizzato i seguenti modelli:

Schema a stella. Si tratta di 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 a fiocco di neve. È 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 dello schema nativo non è nessuna delle due. Utilizza invece campi nidificati e ripetuti per una rappresentazione più naturale dei dati. Per ulteriori informazioni, 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 a colonne chiamato Capacitor.

Per decidere l'approccio di denormalizzazione migliore per il tuo caso, valuta 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 specifiche di data warehouse a BigQuery: