Panoramica del trasferimento di schemi 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 nel cloud è un processo complesso che richiede pianificazione, risorse e tempo. Per affrontare questa complessità, devi affrontare la migrazione dei data warehouse in modo graduale e iterativo. Eseguire più iterazioni della migrazione di schemi e dati può migliorare il risultato.

Processo di migrazione di schemi e dati

All'inizio del tuo percorso di migrazione, troverai sistemi a monte che alimentano il tuo data warehouse legacy e sistemi a valle che utilizzano questi dati in report, dashboard e come feed in altri processi.

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

Stato iniziale prima della migrazione.

Lo stato finale del percorso prevede l'esecuzione del maggior numero possibile di casi d'uso in BigQuery. Questo stato ti consente di ridurre al minimo l'uso del data warehouse legacy e, allo stesso tempo, di eliminarlo gradualmente. Hai il controllo di quali casi d'uso vengono migrati e quando, dando loro priorità durante la fase di preparazione e individuazione della migrazione.

Trasferisci dati e schema da on-premise a BigQuery

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

  1. Trasferisci le tabelle e configura e testa i processi a valle.

    • Trasferisci il gruppo di tabelle per ogni caso d'uso a 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.
    • Configura le versioni di test dei tuoi 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 a valle ora leggono da BigQuery come mostrato nei flussi etichettati come B. Altri leggono ancora dal data warehouse legacy, come mostrato nei flussi A.

    I processi a monte alimentano il warehouse legacy. Alcuni vanno ai processi downstream, altri ad BigQuery mediante BigQuery Data Transfer Service e da lì a diversi processi downstream.

  2. Configura alcuni processi a monte di test per scrivere dati nelle tabelle BigQuery anziché (o in aggiunta) al database legacy.

    Dopo il test, configura i processi a monte e a valle 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 Google Data Studio e Dataflow.

    A questo punto, hai tre flussi di dati:

    1. Eredità. I dati e i processi sono rimasti invariati e continueranno a essere incentrati sul data warehouse legacy.
    2. Offload. I processi a monte alimentano il tuo data warehouse legacy, i dati vengono trasferiti su BigQuery, quindi alimenta i processi a valle.
    3. Completata la migrazione. I processi a monte e a valle non scrivono o leggono più dal data warehouse legacy.

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

      Flusso di lavoro 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 eseguire questi passaggi finché tutti i tuoi casi d'uso non vengono completamente migrati in BigQuery. Quando selezioni i casi d'uso, puoi rivisitare quelli che sono rimasti nello stato "offload" per spostarli completamente sottoposti a migrazione. Per i casi d'uso di cui è stata eseguita la migrazione completa, valuta di continuare il processo di evoluzione seguendo le linee guida in Sviluppare lo schema in BigQuery.

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

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 è alla base della progettazione dei dati e influenza molti processi, sia a monte che a valle.

Una migrazione del data warehouse offre un'opportunità unica di far 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 tuo data warehouse durante le modifiche allo schema con interruzioni minime per i processi a monte e a valle.

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

A seconda della distanza che intendi raggiungere con l'evoluzione, potresti fermarti a un passaggio intermedio o continuare fino a quando il sistema non sarà completamente evoluto.

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

    Prima di continuare con i passaggi successivi, assicurati che i processi a monte e a valle del tuo caso d'uso siano già in scrittura e in lettura da BigQuery. Tuttavia, è anche possibile iniziare da uno stato intermedio in cui solo il processo di downstream sta leggendo 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 a monte e a valle scrivono e leggono dalle tabelle in BigQuery.

    I processi a monte vengono inseriti nelle tabelle BigQuery e da qui ai processi a valle.

  2. Applicare ottimizzazioni leggere.

    1. Ricrea le tabelle applicando il partizionamento e il clustering. Per questa attività, puoi utilizzare il metodo per la creazione di una tabella da un risultato di query. Per maggiori dettagli, consulta la Discussione e l'esempio per le tabelle partizionate e consulta la Discussione e l'Esempio per le tabelle in cluster.
    2. Reindirizza i processi a monte e a valle alle nuove tabelle.
  3. Crea viste della facciata.

    Se vuoi evolvere ulteriormente il tuo schema oltre le ottimizzazioni leggere, crea visualizzazioni della facciata per le tue 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 della facciata mascherano le tabelle sottostanti per nascondere la complessità causata dalle modifiche alle tabelle nei processi a valle.

    Le viste possono descrivere un nuovo schema, senza debiti tecnici, e progettato sulla base di nuovi scenari di importazione e consumo.

    Dietro le quinte, le tabelle e la definizione della query di visualizzazione possono cambiare. Tuttavia, le visualizzazioni astraggono queste modifiche come un dettaglio di implementazione interna del tuo data warehouse, e restituiscono sempre gli stessi risultati. Questo livello di astrazione delle visualizzazioni di facciata isola i sistemi a monte e a valle dai cambiamenti necessari per il tempo necessario e mostra le modifiche solo quando appropriato.

  4. Trasforma i processi a valle.

    Puoi trasformare alcuni dei tuoi processi downstream per leggere dalle visualizzazioni della facciata invece che dalle tabelle effettive. Questi processi trarranno già vantaggio dallo schema evoluto. È trasparente a questi processi che, sotto il cofano, le viste della facciata ricevono comunque i dati dallo schema BigQuery precedente, come mostrato nel diagramma seguente:

    I processi a monte sono inseriti in tabelle BigQuery. Alcuni feed nei processi downstream. Altri alimentano le visualizzazioni della facciata, che alimentano i processi evolutivi a valle.

    Abbiamo descritto prima la trasformazione del processo downstream. Questo consente di mostrare il valore aziendale più rapidamente, sotto forma di dashboard o report sottoposti a migrazione, rispetto alla trasformazione dei processi a monte che non sono visibili a stakeholder non tecnici. Tuttavia, è possibile avviare la trasformazione con i processi a monte. La priorità di queste attività dipende interamente dalle tue esigenze.

  5. Trasforma i processi a monte.

    Puoi trasformare alcuni dei tuoi processi a monte 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 della facciata. Alcune viste continueranno a eseguire query sullo schema precedente, mentre altre eseguiranno una query sulle tabelle appena create o eseguiranno un'operazione UNION su entrambi i tipi di traffico, come mostrato nel diagramma seguente:

    I processi a monte vengono inseriti in tabelle BigQuery, ma non più in processi a valle. Le tabelle BigQuery si inseriscono invece nelle viste della facciata, che a loro volta si inseriscono in processi a valle in evoluzione.

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

    Uno dei vantaggi delle viste facciata è che i processi a valle possono continuare la loro trasformazione in modo indipendente da questi cambiamenti di schema sottostanti e indipendentemente dai cambiamenti nei processi a monte.

  6. Completa il tuo caso d'uso.

    Infine, puoi trasformare i processi rimanenti a monte e a valle. Una volta che tutti questi elementi si sono evoluti per scrivere nelle nuove tabelle e leggerli dalle nuove viste della facciata, puoi modificare le definizioni delle query delle visualizzazioni della facciata in modo che non vengano più lette dallo schema precedente. Dopodiché, puoi recuperare le tabelle nel modello precedente dal flusso di dati. Il seguente diagramma mostra lo stato in cui le tabelle legacy non sono più utilizzate.

    I processi a monte originali non sono più in uso. Rimangono solo i processi evoluti a monte, che si riferiscono a tabelle evolute, che alimentano le visualizzazioni di facciata, che alimentano tutti i processi a valle.

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

    Nella configurazione finale, sia le tabelle BigQuery che le tabelle evolute vengono inserite in viste facciata, che sono l'unica origine per i processi a valle.

Esegui un trasferimento iniziale dello schema e dei dati

Questa sezione illustra alcune considerazioni pratiche per eseguire la migrazione di schema e dati da un data warehouse legacy 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 modificate per un nuovo schema.
  • Evitare di aggiungere un nuovo schema all'elenco del materiale di addestramento per il personale.
  • Puoi utilizzare gli strumenti automatici per eseguire lo schema e il trasferimento dei dati.

Inoltre, proof of concept (PoC) e altre attività di esplorazione dei dati che sfruttano le capacità del 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 vari approcci.

  • Per i data warehouse Amazon Redshift, Oracle e Teradata, puoi utilizzare BigQuery Data Transfer Service per caricare direttamente schema e dati dal sistema esistente in BigQuery. Cloud Storage viene ancora utilizzato per posizionare i dati in modo graduale nell'ambito del processo di migrazione.
  • Per qualsiasi data warehouse, puoi estrarre i file che contengono 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 tali file in BigQuery:

Per ulteriori considerazioni sulla scelta di un metodo di trasferimento dei dati, vedi 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 tuoi dati prima di caricarli in BigQuery, potrebbe essere necessario un passaggio per la trasformazione dei dati. La fase di trasformazione può essere eseguita on-premise o su Google Cloud:

  • Se il passaggio di trasformazione viene eseguito on-premise, valuta in che modo la capacità di calcolo e gli strumenti disponibili potrebbero limitare la velocità effettiva. Inoltre, se il processo di trasformazione arricchisce i dati, prendi in considerazione la necessità di tempi di trasferimento aggiuntivi o larghezza di banda di rete.
  • Se il passaggio di trasformazione viene eseguito in Google Cloud, consulta Caricare i dati utilizzando uno strumento ETL per ulteriori informazioni sulle opzioni.

Estrazione dello schema e dei dati di origine in file

Probabilmente la piattaforma di origine 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, in cui le informazioni sullo schema sono incorporate con i dati. Se scegli CSV o un formato dati semplice e delimitato, devi specificare lo schema separatamente. Il modo in cui esegui questa operazione dipende dal metodo di trasferimento dei dati che selezioni. 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 tua piattaforma di origine, copiali in uno spazio di archiviazione temporaneo nel tuo ambiente on-premise.

Caricare i file su Cloud Storage

A meno che non utilizzi BigQuery Data Transfer Service per caricare dati direttamente da un data warehouse Amazon Redshift, Oracle o Teradata esistente, devi caricare i file estratti in un bucket in Cloud Storage. A seconda della quantità di dati che intendi 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, ripristina dopo gli errori e cripta il traffico in transito per motivi di sicurezza.

  • 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 dati tramite la rete, riduci al minimo la latenza di rete scegliendo la località più vicina al data center. Se possibile, scegli la località del bucket in modo che corrisponda alla località del set di dati BigQuery.

Per informazioni dettagliate sulle best practice per lo spostamento di dati in Cloud Storage, inclusa la stima dei costi, consulta le 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 la pagina 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.

Caricare i dati con uno strumento ETL

Se i dati necessitano di un'ulteriore trasformazione quando vengono caricati in BigQuery, utilizza una delle seguenti opzioni:

  • Cloud Data Fusion Questo strumento crea in modo grafico pipeline di dati ETL/ELT completamente gestite utilizzando una libreria open source di connettori e trasformazioni preconfigurati.
  • Dataflow. Questo strumento definisce ed esegue trasformazioni e grafici di arricchimento di dati complessi utilizzando il modello Apache Beam. Dataflow è serverless e completamente gestito da Google e ti consente di accedere a una capacità di elaborazione praticamente senza limiti.
  • Dataproc: Viene eseguito 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 diagramma seguente 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, forse utilizzando il connettore Google BigQuery I/O di Apache Beam.

Il warehouse legacy 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 temporaneo 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 quando hai trasferito lo schema, il caricamento dei dati fa parte di un processo iterativo. Le iterazioni successive possono iniziare espandendo l'impatto dei dati trasferiti in BigQuery. Successivamente, possono reindirizzare i tuoi feed di dati a monte per eliminare la necessità di conservare il datastore legacy. Questi argomenti vengono trattati nella sezione successiva.

Convalidare i dati

Ora che i tuoi dati sono in BigQuery, puoi verificare l'esito positivo del trasferimento dei dati 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 di varie origini con il tuo target in BigQuery. Puoi specificare le aggregazioni che vuoi eseguire (ad esempio conteggio, somma, media) e le colonne a cui devono essere applicate. Per ulteriori informazioni, consulta la pagina Automatizzare la convalida dei dati con DVT.

Iterazione sul trasferimento iniziale

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

Un sottoinsieme dei tuoi dati è ora in BigQuery. Ti prepari ad aumentare l'impatto dei dati utilizzati in BigQuery e, di conseguenza, a ridurre la dipendenza dal data warehouse legacy.

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

Se utilizzi BigQuery Data Transfer Service, devi prima decidere quali tabelle spostare. A questo punto, crei un pattern per il nome della tabella per includere queste tabelle. Infine, imposti una pianificazione ricorrente per quando eseguire il trasferimento.

Se invece il tuo caso d'uso richiede l'accesso quasi immediato a nuovi dati, devi utilizzare un approccio di streaming. Sono disponibili due opzioni:

Nel breve termine, l'aumento dell'impatto dei tuoi dati BigQuery e dell'uso per il processo di downstream dovrebbe essere incentrato sul soddisfacimento dei tuoi casi d'uso con priorità massima, con l'obiettivo a medio termine di abbandonare la tua origine dati legacy. Pertanto, utilizza con attenzione le iterazioni iniziali. Non spendere molte risorse per perfezionare le pipeline di importazione dal tuo data warehouse legacy in BigQuery. In definitiva, dovrai adattare queste pipeline per non utilizzare più questa origine dati.

Ottimizza lo schema

La migrazione delle tabelle così come sono a BigQuery ti consente già di usufruire delle sue funzionalità uniche. Ad esempio, non è necessario ricreare gli indici, eseguire il riordinamento dei blocchi di dati (aspirapolvere) o ridurre il tempo di inattività o le prestazioni a causa degli upgrade della versione.

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

  • I problemi precedenti e il debito tecnico associati allo schema rimangono invariati.
  • Le ottimizzazioni delle query sono limitate e potrebbero essere necessarie se lo schema viene aggiornato in una fase successiva.
  • Non sfrutti al massimo 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 suddividere i dati in segmenti, chiamati partizioni, che semplificano la gestione e l'esecuzione di query sui dati. Puoi partizionare le tabelle in base a una 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ù efficaci 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, dovresti prendere in considerazione la creazione di tabelle partizionate anche se lo schema non è stato modificato.

Cluster

In BigQuery, non vengono utilizzati indici per eseguire query sui dati. Le prestazioni di BigQuery sono ottimizzate per via del modello sottostante, delle tecniche di archiviazione e di query e dell'architettura molto parallela. Quando esegui una query, più dati vengono elaborati, più macchine vengono aggiunte per eseguire la scansione dei 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, è disponibile 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 che hai specificato e posizionali in blocchi di dimensioni ottimali. Il clustering migliora le prestazioni delle query rispetto al 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 la scansione di dati non necessari e possono calcolare più rapidamente gli aggregati perché i blocchi concorrono alla colocation dei record con valori simili.

Esamina le query per verificare se sono presenti colonne utilizzate di frequente per filtrare e creare tabelle con il clustering in tali colonne. Il clustering richiede tabelle partizionate e viene definito al momento della creazione della tabella.

Denormalizzazione

La migrazione dei dati è un processo iterativo. Pertanto, dopo aver spostato il tuo schema iniziale nel cloud, eseguito ottimizzazioni leggere e testato alcuni casi d'uso principali, potrebbe essere opportuno esplorare ulteriori funzionalità che traggono vantaggio dalla progettazione sottostante di BigQuery. Sono inclusi i campi nidificati e ripetuti.

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

  • Schema stella. Si tratta di un modello denormalizzato, in cui una tabella di fatto raccoglie metriche come importo dell'ordine, sconto e quantità, insieme a un gruppo di chiavi. Queste chiavi appartengono a tabelle di dimensioni quali cliente, fornitore, area geografica e così via. Il grafico è simile a una stella, con la tabella dei fatti al centro circondata da tabelle di dimensioni.
  • Schema Fiocco di neve. È simile allo schema delle stelle, ma con le sue tabelle delle dimensioni normalizzate, che conferiscono allo schema l'aspetto di un fiocco di neve univoco.

BigQuery supporta sia gli schemi a stelle che i fiocchi di neve, ma la rappresentazione nativa dello schema 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.

Modificare lo schema per utilizzare campi nidificati e ripetuti è un'ottima scelta evolutiva. Riduce il numero di join necessari per le query e allinea il tuo schema alla rappresentazione dei dati interni di BigQuery. Internamente, BigQuery organizza i dati utilizzando il modello Dream e li archivia in un formato di archiviazione a colonne chiamato Condensatore.

Per decidere il miglior approccio di denormalizzazione per il tuo caso, considera 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 nella migrazione del data warehouse:

Puoi anche passare al passaggio da tecnologie di data warehouse specifiche a BigQuery: