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 lo schema e i dati dal tuo 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 data warehouse in modo graduale e iterativo. Eseguire diverse iterazioni di schema e migrazione 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 i sistemi downstream che utilizzano questi dati report, dashboard e feed ad altri processi.

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

Stato iniziale prima della migrazione.

Lo stato finale del tuo percorso è avere il maggior numero possibile di casi d'uso eseguiti su BigQuery. Questo stato ti consente di ridurre al minimo l'utilizzo del tuo data warehouse esistente e di eliminarlo gradualmente. Hai tu il controllo quali casi d'uso vengono migrati e quando, assegnando loro la priorità durante preparare e scoprire durante la fase di migrazione.

Trasferisci schema e dati in BigQuery

Nella fase di pianificazione della migrazione, identifica i casi d'uso di cui vuoi eseguire la migrazione. Quindi avvia le iterazioni di migrazione nella fase di esecuzione. Per gestire le tue iterazioni durante l'esecuzione del tuo ambiente di analisi con minimo, segui questa procedura generale:

Trasferisci le tabelle e configura e testa i processi a valle.
- Trasferisci il gruppo di tabelle per ogni caso d'uso in BigQuery senza modifiche, 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 processi downstream da cui leggere le tabelle BigQuery.
Questo passaggio iniziale divide il flusso di dati. Il seguente diagramma mostra del flusso risultante. Alcuni sistemi downstream ora leggono BigQuery come mostrato nei flussi etichettati B. Altri continuano a leggere dal data warehouse esistente, come mostrato nei flussi etichettati A.
Configura alcune procedure di test a monte per scrivere i dati nelle tabelle BigQuery anziché (o in aggiunta) nel data warehouse esistente.

Dopo il test, configura la produzione upstream e downstream di scrittura e lettura nelle tabelle BigQuery. Queste procedure 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 le procedure rimangono invariati e continuano a essere incentrati sul data warehouse esistente.
2. Offload. I processi a monte alimentano il data warehouse esistente, i dati vengono è stato scaricato in BigQuery e poi alimenta i processi downstream.
3. Migrazione completa. I processi upstream e downstream non scrivono o per leggere 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 fino a quando tutti i tuoi casi d'uso non saranno completamente è stata eseguita la migrazione in BigQuery. Quando selezioni i casi d'uso, puoi rivedere quelli che sono rimasti nello stato di offload per spostarli in quelli completamente migrati. Per i casi d'uso di cui è stata eseguita la migrazione completa, valuta la possibilità di continuare il processo evolutivo seguendo le linee guida Migliora lo schema in BigQuery.

Eseguire l'evoluzione dello 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 dei tuoi dati progettazione e influenza molti processi, sia a monte che a valle.

Una migrazione del data warehouse rappresenta un'opportunità unica per sviluppare lo schema dopo il trasferimento in BigQuery. Questa sezione introduce le linee guida per l'evoluzione dello schema tramite una serie di passaggi. Queste linee guida ti aiutano a mantenere attivo il tuo ambiente di data warehouse durante le modifiche dello schema con un'interruzione minima delle procedure a monte e a valle.

I passaggi descritti in questa sezione riguardano la trasformazione dello schema per un singolo caso d'uso.

A seconda di quanto vuoi procedere con l'evoluzione, potresti fermarti a un passaggio intermedio oppure continuare fino all'evoluzione completa del sistema.

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

Prima di continuare con i passaggi successivi, assicurati che le procedure a monte e a valle 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 a valle legge da BigQuery. In questo caso, applica solo le linee guida per la parte a valle. Il seguente diagramma illustra un caso d'uso in cui i processi a monte e a valle scrivono e leggono da tabelle in BigQuery.
Applica ottimizzazioni della luce.
1. Ricrea le tabelle, applicando partizionamento e il clustering. Per questa operazione, puoi utilizzare il metodo per creare una tabella da un risultato della query. Per maggiori dettagli, consulta la discussione e l'esempio per le tabelle partizionate e la discussione e l'esempio per le tabelle cluster.
2. Reindirizza le procedure a monte e a valle alle nuove tabelle.
Crea viste facciate.

Se vuoi sviluppare ulteriormente il tuo schema oltre le ottimizzazioni semplici, Crea visualizzazioni per facciate per le tabelle. La pattern della facciata è un metodo di progettazione che maschera il codice o le strutture sottostanti per nascondere complessità. In questo caso, la vista facciata maschera le tabelle sottostanti nascondendo la complessità causata dalle modifiche alle tabelle dei processi downstream.

Le visualizzazioni possono descrivere un nuovo schema, privo di debiti tecnici e modellato tenendo conto di nuovi scenari di importazione e utilizzo.

Dietro le quinte, le tabelle e la definizione della query della visualizzazione stessa possono cambiare. Tuttavia, le visualizzazioni estraggono queste modifiche come dettagli di implementazione interna del data warehouse e restituiscono sempre gli stessi risultati. Questo livello di astrazione costituito da visualizzazioni di facciata isola i sistemi a monte e a valle 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 anziché dalle tabelle effettive. Questi processi trarranno già vantaggio dallo schema evoluto. Queste operazioni sono trasparenti per le visualizzazioni della facciata, che continuano a ricevere i dati dallo schema BigQuery di origine, come mostrato nel seguente diagramma:

Abbiamo descritto innanzitutto la trasformazione del processo a valle. Ciò consente più rapidamente il valore aziendale, sotto forma di dashboard solo se trasformassi i processi upstream che non sono visibili stakeholder non tecnici. Tuttavia, è possibile avviare la trasformazione con i tuoi processi upstream. La priorità di questi delle attività dipende completamente dalle tue esigenze.
Trasforma i processi upstream.

Puoi trasformare alcune delle tue procedure a monte per scrivere nel nuovo schema. Poiché le viste sono di sola lettura, crei tabelle in base al nuovo schema e poi modifichi la definizione di query delle viste della facciata. Alcune visualizzazioni eseguiranno comunque query sullo schema di origine, mentre altre eseguiranno query sulle tabelle appena create o eseguiranno un'operazione UNION SQL su entrambe, come mostrato nel seguente diagramma:

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

Un vantaggio delle visualizzazioni della facciata è che le tue procedure a valle possono continuare la loro trasformazione indipendentemente da queste modifiche dello schema sottostante e dalle modifiche nelle procedure a monte.
Sviluppare completamente il tuo caso d'uso.

Infine, puoi trasformare i restanti upstream e downstream i processi di machine learning. Quando tutte queste modifiche sono state apportate per scrivere nelle nuove tabelle e leggere dalle nuove viste di facciata, modifica le definizioni delle query delle viste di facciata in modo che non leggano più dallo schema di origine. Puoi quindi le tabelle nel modello di origine dal flusso di dati. Le seguenti mostra lo stato in cui le tabelle di origine non vengono più utilizzate.

Se le viste facciata non aggregano campi o filtrano colonne, puoi configurare i processi downstream per la lettura dalle tabelle evolute quindi ritira le viste facciate per ridurre la complessità, come mostrato diagramma seguente:

Esegui un trasferimento iniziale dello schema e dei dati

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

Ti consigliamo di trasferire lo schema senza modifiche durante le prime iterazioni della migrazione. Questo offre i seguenti vantaggi:

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

Inoltre, sono disponibili anche proof of concept (PDC) e altre attività di esplorazione dei dati. che sfruttano le funzionalità del cloud possono procedere senza ostacoli, anche mentre 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 viene comunque utilizzato per eseguire la gestione temporanea dei dati nell'ambito del processo di migrazione.
Per qualsiasi data warehouse, puoi estrarre i file che contengono il tuo schema caricare i dati su Cloud Storage, quindi utilizzare una delle le seguenti opzioni per caricare lo schema e i dati di questi file BigQuery:

Per ulteriori considerazioni sulla scelta di un metodo di trasferimento di dati, consulta Scelta di 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, potresti includere un passaggio per trasformarli. Puoi trasformare esistenti nell'ambiente 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 il throughput. Inoltre, se codifichi i dati durante la trasformazione di trasferimento, considera se ti serviranno tempi di trasferimento aggiuntivi o e la larghezza di banda.
Se trasformi i dati su Google Cloud, vedi Caricare dati utilizzando uno strumento ETL per ulteriori informazioni sulle opzioni a tua disposizione.

Estrai lo schema e i dati esistenti in file

La tua piattaforma esistente probabilmente fornisce uno strumento per esportare i dati in un formato indipendente dal fornitore come Apache Avro o CSV. Per ridurre la complessità del trasferimento, ti consigliamo di utilizzare AVRO, ORC o Parquet in cui le informazioni sullo schema sono incorporate nei dati. Se scegli CSV o simile formato di dati delimitato da semplice, 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 collettivo, puoi specificare uno schema al momento del caricamento o consentire il rilevamento automatico dello schema in base ai contenuti del file CSV.

Mentre estrai questi file dalla tua piattaforma esistente, copiali nello spazio di archiviazione intermedio 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 cloud provider, utilizza Storage Transfer Service.
Se i dati si trovano in un ambiente on-premise o in una struttura di colocation che abbia una buona larghezza di banda di rete, utilizza Google Cloud CLI. L'interfaccia a riga di comando gcloud supporta i 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 un di terze parti di un partner di Google.
- Se la larghezza di banda della rete è limitata, puoi utilizzare tecniche di compressione per limitare le dimensioni dei dati oppure modificare la connessione attuale a Google Cloud per aumentare la larghezza di banda.
Se non riesci a ottenere una larghezza di banda di rete sufficiente, puoi eseguire un trasferimento offline utilizzando un Transfer Appliance.

Quando crei il bucket Cloud Storage e trasferisci i dati tramite la rete, riduci al minimo la latenza della rete scegliendo la località più vicina al tuo 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 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 discussi in Scegliere un metodo di trasferimento.

Per ulteriori informazioni sui caricamenti una tantum, consulta la sezione 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 con uno strumento ETL

Se i dati devono essere ulteriormente trasformati durante il caricamento 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 trasformazioni e connettori preconfigurati.
Dataflow. Questo strumento definisce ed esegue trasformazioni e schemi di arricchimento dei dati complessi 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.
Dataproc. Esegue i cluster Apache Spark e Apache Hadoop su un ambiente completamente gestito di Google Cloud.
Strumenti di terze parti. Contatta uno dei nostri partner. Ti consentono di prendere decisioni efficaci per esternalizzare di una pipeline di dati.

Il seguente diagramma mostra il pattern descritto in questa sezione. I dati di trasferimento è lo strumento gcloud CLI, e c'è una trasformazione che sfrutta Dataflow e scrive direttamente in BigQuery, magari usando la soluzione Apache Beam integrata Connettore Google BigQuery I/O.

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

Dopo aver caricato un set iniziale di dati in BigQuery, puoi iniziare a sfruttare i vantaggi Potenti funzionalità di BigQuery.

Tuttavia, come quando hai trasferito lo schema, il caricamento dei dati fa parte di una su un processo iterativo. Le iterazioni successive possono iniziare espandendo l'impronta i dati da trasferire in BigQuery. Poi puoi reindirizzare i tuoi feed di dati upstream in BigQuery per eliminare mantenendo in esecuzione il data warehouse esistente. Approfondisci questi argomenti nella prossima sezione.

Convalida i dati

Ora che i dati sono in BigQuery, puoi verificarne l'efficacia del trasferimento di dati Strumento di convalida dei dati (DVT). DVT è uno strumento di interfaccia a riga di comando Python open source che consente di confrontare da varie origini al tuo target in BigQuery. Puoi specificare le aggregazioni da eseguire (ad es. conteggio, somma, media) e le colonne a cui applicarle. Per ulteriori informazioni, vedi Automatizza la convalida dei dati con DVT.

Esegui l'iterazione sul trasferimento iniziale

Questa sezione spiega 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 a aumentare l'impronta dei dati utilizzati in BigQuery e quindi a ridurre la dipendenza dal tuo data warehouse esistente.

Il metodo scelto per le iterazioni successive dipende da quanto è importante per il tuo caso d'uso di aggiornare i dati al secondo. Se i tuoi dati gli analisti possono lavorare con i dati incorporati nel data warehouse a intervalli ricorrenti, un'opzione programmata è la scelta giusta. Puoi creare i trasferimenti programmati in modo simile al trasbordo 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 per i nomi delle tabelle da includere. Infine, imposta una programmazione ricorrente per l'esecuzione del trasferimento.

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

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

Nel breve periodo, l'aumento dell'impatto delle risorse BigQuery e il loro utilizzo per i processi downstream devono concentrarsi sul soddisfare casi d'uso prioritari, con l'obiettivo a medio termine di rimuovere i dati esistenti warehouse. Usa le iterazioni iniziali in modo accorto e non spendere molti le risorse che perfezionano le pipeline di importazione dal data warehouse esistente in BigQuery. In definitiva, dovrai adattare le pipeline di non usare il data warehouse esistente.

Ottimizza lo schema

La semplice migrazione delle tabelle così come sono a BigQuery ti consente sfruttarne le funzioni uniche. Ad esempio, non è necessario ricostruire gli indici, riorganizzare i blocchi di dati (vacuuming) o interrompere il servizio o riscontrare un calo delle prestazioni a causa degli 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 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 sfrutti appieno le altre funzionalità di BigQuery, ad esempio campi nidificati e ripetuti, partizionamento e clustering.

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

Partizionamento

BigQuery ti consente di suddividere i dati in segmenti, chiamati partizioni, che semplificano e rendono più efficienti la gestione e l'esecuzione di query sui dati. Puoi a partizionare le tabelle in base a TIMESTAMP o DATE colonna oppure BigQuery può aggiungere pseudocolonne alla finestra partizionare i dati durante l'importazione. Query che coinvolgono partizioni più piccole possono essere più performanti perché analizzano solo un sottoinsieme dei dati 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 il tuo schema non è modificato.

Clustering

In BigQuery non vengono utilizzati indici per eseguire query sui dati. Le prestazioni di BigQuery sono ottimizzate dall'entità del modello, delle tecniche di archiviazione e di query e dell'architettura a parallelismo massivo. Quando esegui una query, maggiore è la quantità di dati elaborati, più macchine vengono aggiunte per scansionare i dati e aggregare i risultati contemporaneamente. Questa tecnica si adatta bene a set di dati enormi, mentre la ricreazione 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 specificate e li colloca in blocchi di dimensioni ottimali. Il clustering migliora le prestazioni delle query rispetto al non utilizzo per il clustering. Con il clustering, BigQuery può stimare meglio anziché eseguire il clustering in meno tempo. Con le colonne raggruppate, le query eliminano anche le analisi dei dati non necessari e possono calcolare gli aggregati più velocemente perché i blocchi raggruppano i record con valori simili.

Esamina le query per individuare le colonne utilizzate più di frequente per l'applicazione di filtri e crea i tuoi con clustering in queste colonne. Il clustering richiede tabelle partizionate e viene definito anche al momento della creazione della tabella.

Denormalizzazione

La migrazione dei dati è un processo iterativo. Pertanto, dopo aver spostato lo schema iniziale sul cloud, eseguito ottimizzazioni leggere e testato alcuni casi d'uso chiave, potrebbe essere il momento di esplorare funzionalità aggiuntive che beneficiano del design di base di BigQuery. Sono inclusi campi nidificati e ripetuti.

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

Schema a Speciali. 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. Questi le chiavi appartengono a tabelle di dimensioni come cliente, fornitore, regione attiva. Dal punto di vista grafico, il modello assomiglia a una stella, con la tabella dei fatti nel al centro, circondata da tabelle delle dimensioni.
Schema di Snowflake. È simile allo schema a stella, ma con le tabelle delle dimensioni normalizzate, che conferisce 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 dello schema nativo non è né uno né l'altro. Utilizza campi nidificati e ripetuti per una rappresentazione più naturale dei dati. Per ulteriori informazioni, vedi il schema di esempio nella documentazione di BigQuery.

Modificare lo schema per utilizzare campi nidificati e ripetuti è un'ottima cosa una scelta evolutiva. 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 Modello Dremel e la archivia in un formato di archiviazione a colonne denominato Condensatore.

Per decidere l'approccio di denormalizzazione migliore per il tuo caso, considera il best practice per la denormalizzazione in BigQuery, nonché le tecniche per la gestione delle 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 a BigQuery: