Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica del trasferimento di schemi e dati

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

La migrazione del data warehouse nel cloud è un processo complesso che richiede pianificazione, risorse e tempo. Per contenere questa complessità, occorre affrontare la migrazione del data warehouse 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, hai dei sistemi upstream che alimentano il tuo data warehouse esistente e dei sistemi downstream 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 quanti più casi d'uso possibile in esecuzione su BigQuery. Questo stato consente di ridurre al minimo l'uso del data warehouse esistente e di eliminarlo. Sei tu a controllare quali casi d'uso eseguire la migrazione e quando, dando la priorità a questi casi durante la fase di preparazione e individuazione 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. Dopodiché avvii le iterazioni della migrazione nella fase di execute. Per gestire le tue iterazioni durante l'esecuzione del tuo 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 sul trasferimento iniziale dei dati.
- Configurare 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 nei flussi con l'etichetta B. Altri continuano a leggere dal data warehouse esistente, come mostrato nei flussi con l'etichetta A.
Configurare alcuni processi upstream di test per scrivere dati nelle tabelle BigQuery anziché (o in aggiunta al) 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 sono invariati e sono ancora incentrati sul data warehouse esistente.
2. Scaricato. 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 e tre i flussi:
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 finché non avrai eseguito la migrazione completa di tutti i tuoi casi d'uso in BigQuery. Quando selezioni i casi d'uso, puoi rivedere quelli rimasti nello stato di download per spostarli alla 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 Evolvere lo schema in BigQuery.

Evolvere lo schema in BigQuery

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

Una migrazione del data warehouse rappresenta un'opportunità unica per far evolvere lo schema dopo il trasferimento a BigQuery. Questa sezione introduce le linee guida per l'evoluzione dello schema mediante 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 dei processi upstream e downstream.

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

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

Trasferisci 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 fase di scrittura e lettura 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 ottimizzazioni della luce.
1. Ricrea le tabelle applicando il partizionamento e il clustering. Per questa attività, puoi utilizzare il metodo per creare una tabella dal risultato di una query. Per maggiori dettagli, vedi la discussione ed esempio per le tabelle partizionate, oltre alla discussione ed esempio per le tabelle in cluster.
2. Reindirizza i processi upstream e downstream alle nuove tabelle.
Crea viste facciate.

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

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

Di fondo, le tabelle e la definizione delle query di visualizzazione stessa possono cambiare. Tuttavia, le visualizzazioni astraggono queste modifiche come dettagli di implementazione interna del data warehouse e restituiscono sempre gli stessi risultati. Questo livello di astrazione composto da viste di facciata isola i sistemi upstream e downstream dalle modifiche per tutto il tempo necessario e mostra le modifiche solo quando opportuno.
Trasforma i processi downstream.

Puoi trasformare alcuni dei tuoi processi downstream in modo che vengano letti dalle visualizzazioni facciata invece che dalle tabelle effettive. Questi processi trarranno già vantaggio dallo schema evoluto. È trasparente per questi processi che, in background, le viste frontali ricevono comunque i dati dallo schema BigQuery di origine, come mostrato nel seguente diagramma:

Per prima cosa, descriviamo la trasformazione del processo downstream. In questo modo puoi mostrare il valore aziendale più rapidamente, sotto forma di dashboard o report migrati, rispetto alla trasformazione dei processi a monte 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.
Trasforma i processi upstream.

Puoi trasformare alcuni dei tuoi processi upstream in modo che scrivano nel nuovo schema. Poiché le viste sono di sola lettura, crei tabelle in base al nuovo schema, quindi modifichi la definizione della query delle viste di facciata. Alcune viste continueranno a eseguire query sullo schema di origine, mentre altre eseguiranno query sulle tabelle appena create o eseguiranno un'operazione UNION SQL su entrambi, come mostrato nel seguente diagramma:

A questo punto, puoi sfruttare i campi nidificati e ripetuti quando crei le nuove tabelle. Ciò consente di denormalizzare ulteriormente il modello e di sfruttare direttamente i vantaggi diretti della rappresentazione a colonne sottostante di BigQuery.

Un vantaggio delle visualizzazioni di facciata è che i processi downstream possono continuare la loro trasformazione indipendentemente dalle modifiche allo schema sottostanti e indipendentemente dalle modifiche dei processi upstream.
Fai evolvere completamente il tuo caso d'uso.

Infine, puoi trasformare i restanti processi upstream e downstream. Dopo l'evoluzione di tutti questi elementi per scrivere nelle nuove tabelle e leggere dalle nuove viste frontali, puoi modificare le definizioni di query delle viste facciata in modo che non vengano più lette 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 facciate non aggregano campi o filtrano colonne, puoi configurare i processi downstream in modo che leggano dalle tabelle evolute e quindi ritirare le viste facciate 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 di schema e 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:

Non è necessario regolare le pipeline di dati che alimentano il data warehouse in base a un nuovo schema.
Eviterai di aggiungere un nuovo schema all'elenco dei materiali di formazione per il tuo personale.
Puoi utilizzare strumenti automatizzati per eseguire lo schema e il trasferimento dei dati.

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

Scegli un metodo di trasferimento

Puoi eseguire il trasferimento iniziale seguendo uno dei vari approcci disponibili.

Per i data warehouse Amazon Redshift e Teradata, puoi utilizzare BigQuery Data Transfer Service per caricare schema e dati direttamente dal tuo sistema esistente in BigQuery. Cloud Storage è ancora usato per organizzare i dati come parte del processo di migrazione.
Per qualsiasi data warehouse, puoi estrarre i file contenenti schema e dati, caricarli in Cloud Storage, 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 di dati, consulta Scegliere un metodo di importazione 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, puoi includere un passaggio per trasformare i dati. 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 di calcolo disponibili potrebbero limitare la velocità effettiva. Inoltre, se crittografa i dati durante il processo di trasformazione, valuta se hai bisogno di ulteriore tempo di trasferimento o larghezza di banda della rete.
Se trasformi i dati su Google Cloud, consulta Caricare i dati utilizzando uno strumento ETL per ulteriori informazioni sulle opzioni a tua disposizione.

Estrai lo schema e i dati esistenti in file

È probabile che la tua piattaforma esistente fornisca 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 di dati semplice e simile, devi specificare lo schema separatamente. Il modo in cui esegui questa operazione dipende dal metodo di trasferimento dei dati selezionato. Ad esempio, per il caricamento in batch, puoi specificare uno schema al momento del caricamento o consentire il rilevamento automatico dello schema in base ai contenuti del file CSV.

Quando estrai questi file dalla tua piattaforma esistente, copiali nello spazio di archiviazione gestione temporanea nell'ambiente esistente.

Carica i file su Cloud Storage

A meno che 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, riprende dopo gli 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 rete è limitata, puoi utilizzare le tecniche di compressione per limitare la dimensione dei dati o puoi modificare la connessione attuale a Google Cloud per aumentare la larghezza di banda.
Se non disponi di 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 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 ulteriori informazioni sui caricamenti pianificati a intervalli regolari, consulta Panoramica dei trasferimenti di Cloud Storage nella documentazione di BigQuery Data Transfer Service.

Carica i dati utilizzando uno strumento ETL

Se i dati richiedono un'ulteriore trasformazione man mano che 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 complesse trasformazioni di dati e grafici di arricchimento utilizzando il modello Apache Beam. Dataflow è serverless e completamente gestito da Google, con accesso a capacità di elaborazione praticamente illimitata.
Dataproc. Esegue il cluster Apache Spark e Apache Hadoop su un servizio cloud completamente gestito.
Strumenti di terze parti. Contatta uno dei nostri partners. Offrono scelte efficaci per esternalizzare la creazione di una pipeline di dati.

Il seguente diagramma mostra il pattern descritto in questa sezione. Lo strumento di trasferimento dei dati è gsutil 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. Lo strumento gsutil 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 efficaci funzionalità 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 l'ingombro dei dati trasferiti a BigQuery. Quindi puoi reindirizzare i feed di dati upstream a BigQuery per eliminare la necessità di mantenere in esecuzione il data warehouse esistente. Questi argomenti verranno approfonditi nella prossima sezione.

Convalida i dati

Ora che i tuoi dati sono in BigQuery, puoi verificare il successo del trasferimento con lo strumento di convalida dei dati (DVT). DVT è uno strumento dell'interfaccia a riga di comando Python open source 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 devono essere applicate. Per maggiori informazioni, consulta Automatizzare la convalida dei dati con 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 è 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 che scegli per le iterazioni successive dipende da quanto è importante per il tuo caso d'uso che i dati siano aggiornati al secondo attuale. Se i tuoi analisti di dati possono lavorare con i dati incorporati nel data warehouse a intervalli ricorrenti, ti consigliamo di utilizzare un'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. Quindi, crea un pattern del nome della tabella per includere queste tabelle. Infine, imposti una pianificazione ricorrente per l'esecuzione del trasferimento.

Se invece il tuo caso d'uso richiede l'accesso quasi immediato a nuovi dati, è necessario un approccio in modalità flusso. Puoi scegliere tra due opzioni:

Configurare una pipeline di carico con i prodotti Google Cloud. Google fornisce una serie di modelli Dataflow in modalità flusso per facilitare questa attività.
Utilizza una soluzione di uno dei nostri partners.

Nel breve periodo, l'aumento della traccia dei tuoi dati BigQuery e il loro utilizzo per il processo downstream dovrebbe essere incentrato sul soddisfare i tuoi casi d'uso con priorità massima, con l'obiettivo a medio termine di abbandonare il data warehouse esistente. Usa le iterazioni iniziali in modo appropriato e non spendere molte risorse per perfezionare le pipeline di importazione dal data warehouse esistente a BigQuery. In definitiva, dovrai adattare le pipeline in modo da non usare il data warehouse esistente.

Ottimizza lo schema

La semplice migrazione delle tabelle così come sono in BigQuery consente di sfruttare le sue funzionalità uniche. Ad esempio, non è necessario ricreare gli indici, eseguire il riordinamento dei blocchi di dati (vacuuming), né tempi di inattività o riduzione delle prestazioni a causa degli upgrade della versione.

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

I problemi esistenti e i debiti tecnici associati allo schema rimangono.
Le ottimizzazioni delle query sono limitate e potrebbe essere necessario ripetere l'operazione 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.

Durante il 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 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 avere prestazioni più elevate perché analizzano solo un sottoinsieme di 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 sottostante, dalle tecniche di archiviazione e query e dall'architettura molto parallela. Quando esegui una query, maggiore è il numero di dati elaborati e più macchine vengono aggiunte per scansionare i dati e aggregare i risultati contemporaneamente. Questa tecnica si adatta bene a set di dati di grandi dimensioni, mentre la ricreazione degli indici non è applicabile.

Tuttavia, c'è margine 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 non utilizzo del clustering. Con il clustering, BigQuery può stimare meglio il costo di esecuzione della query rispetto al clustering. Con le colonne in cluster, le query eliminano anche le analisi di dati non necessari e possono calcolare gli aggregati più rapidamente perché i blocchi collocano record con valori simili.

Esamina le query per individuare le colonne utilizzate spesso per l'applicazione di 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. Pertanto, dopo aver spostato lo schema iniziale nel cloud, eseguito le ottimizzazioni della luminosità e testato alcuni casi d'uso chiave, potrebbe essere il momento di esplorare funzionalità aggiuntive che traggono vantaggio dalla progettazione sottostante di BigQuery. Sono inclusi campi nidificati e ripetuti.

Gli schemi di data warehouse utilizzano storicamente i seguenti modelli:

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

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

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

Per decidere l'approccio di denormalizzazione migliore per il tuo caso, consulta le best practice per la denormalizzazione 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 come passare da tecnologie di data warehouse specifiche a BigQuery: