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 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 più iterazioni della migrazione di schema e dati può migliorare il risultato.

Procedura 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.

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 il controllo su quali casi d'uso vengono migrati e quando, assegnandoli una priorità durante la fase di preparazione e scoperta della 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 iterazioni durante l'esecuzione dell'ambiente di analisi con un'interruzione minima, segui questa procedura di alto livello:

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 delle tue procedure a valle in modo che leggano dalle tabelle BigQuery.
Questo passaggio iniziale suddivide il flusso di dati. Il seguente diagramma mostra il flusso risultante. Alcuni sistemi a valle ora leggono da 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 le procedure di produzione upstream e downstream per scrivere e leggere 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. Offloaded. Le procedure a monte alimentano il tuo data warehouse esistente, i dati vengono trasferiti a BigQuery e poi alimentano le procedure a valle.
3. Migrazione completata. Le procedure a monte e a valle 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, quindi vai al passaggio 1 per avviare una nuova iterazione di esecuzione. Continua a eseguire l'iterazione di questi passaggi finché non hai eseguito la migrazione completa di tutti i casi d'uso 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 completata la migrazione, ti consigliamo di continuare il processo di evoluzione seguendo le linee guida riportate in Evolvere 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 del design dei dati e influisce su molti processi, sia a monte che a valle.

La migrazione di un data warehouse offre un'opportunità unica per far evolvere lo schema dopo il trasferimento a BigQuery. Questa sezione illustra le linee guida per far evolvere lo schema seguendo 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 spingerti con l'evoluzione, puoi fermarti a un passaggio intermedio o continuare fino a quando il sistema non sarà completamente evoluto.

Trasferisci un caso d'uso così com'è in 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 leggere.
1. Ricrea le tabelle applicando il 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 della facciata.

Se vuoi evolvere ulteriormente lo schema oltre le ottimizzazioni leggere, crea viste di 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 visualizzazioni della facciata mascherano le tabelle sottostanti per nascondere la complessità causata dalle modifiche delle tabelle dalle procedure a valle.

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 a valle.

Puoi trasformare alcune delle tue procedure a valle in modo che leggano dalle visualizzazioni della facciata 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. In questo modo, puoi mostrare il valore aziendale più rapidamente, sotto forma di dashboard o report di cui è stata eseguita la migrazione, rispetto a quanto faresti se trasformassi i processi a monte non visibili agli stakeholder non tecnici. Tuttavia, è possibile avviare la trasformazione con le procedure a monte. La priorità di queste attività dipende interamente dalle tue esigenze.
Trasforma i processi a monte.

Puoi trasformare alcune delle tue procedure a monte in modo che scrivano nel nuovo schema. Poiché le viste sono di sola lettura, devi creare tabelle in base al nuovo schema e poi modificare 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 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 visualizzazioni della facciata è che i processi a valle possono continuare la loro trasformazione indipendentemente da queste modifiche dello schema sottostante e dalle modifiche dei processi a monte.
Sviluppare completamente il caso d'uso.

Infine, puoi trasformare le rimanenti operazioni upstream e downstream. 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 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 campi o colonne di filtro, puoi configurare le procedure a valle in modo che leggano dalle tabelle evolute e 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 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 automatici per eseguire il trasferimento dello schema e dei dati.

Inoltre, le prove di concetto (PoC) e altre attività di esplorazione dei dati che sfruttano le funzionalità del cloud possono procedere senza ostacoli, anche durante la migrazione 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 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 contenenti lo schema e i dati, caricarli su Cloud Storage e utilizzare una delle seguenti opzioni per caricare lo schema e i dati da questi file in BigQuery:

Per ulteriori considerazioni sulla scelta di un metodo di trasferimento dei dati, consulta Scegliere un metodo di importazione dati 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 attuale, valuta in che modo la capacità di calcolo e gli strumenti disponibili potrebbero limitare il throughput. Inoltre, se cripti i dati durante il processo di trasformazione, valuta se hai bisogno di tempi di trasferimento o larghezza di banda della rete aggiuntivi.
Se trasformi i dati su Google Cloud, consulta Carica i dati utilizzando uno strumento ETL per approfondire le 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, consigliamo di utilizzare AVRO, ORC o Parquet, dove le informazioni dello schema sono incorporate nei dati. Se scegli CSV o un formato di dati delimitati semplice simile, devi specificare lo schema separatamente. La procedura varia a seconda del 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 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. Gcloud CLI supporta i caricamenti paralleli multithread, riprende dopo gli errori e cripta il traffico in transito per motivi di sicurezza.
- Se non riesci a utilizzare la gcloud CLI, puoi provare uno strumento di terza parte 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 posizione del bucket in modo che corrisponda a quella del set di dati BigQuery.

Per informazioni dettagliate sulle best practice per spostare i 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 discusse 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 saperne di più sui caricamenti pianificati a intervalli regolari, consulta la 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 durante il caricamento 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 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. Il cluster Apache Spark e Apache Hadoop viene eseguito su un servizio cloud completamente gestito.
Strumenti di terze parti. Contatta uno dei nostri partner. Possono offrire 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 è la CLI gcloud e esiste un passaggio di trasformazione che sfrutta Dataflow e scrive direttamente in BigQuery, magari utilizzando il connettore Google BigQuery I/O integrato in Apache Beam.

Il data warehouse esistente copia i dati in uno spazio di archiviazione temporaneo on-premise. La 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 in BigQuery. In seguito, puoi reindirizzare i feed di dati a monte a BigQuery per eliminare la necessità di mantenere in esecuzione il data warehouse esistente. Questi argomenti vengono trattati nella sezione successiva.

Convalida i dati

Ora che i dati sono in BigQuery, puoi verificare l'esito positivo del trasferimento 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 il tuo target in BigQuery. Puoi specificare le aggregazioni da eseguire (ad es. conteggio, somma, media) e le colonne a cui applicarle. Per ulteriori informazioni, consulta Automatizzare la convalida dei dati con la funzionalità 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 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 sia importante per il tuo caso d'uso avere dati aggiornati al secondo corrente. Se i tuoi analisti dei 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. 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 termine, l'aumento dell'impronta dei dati BigQuery e il loro utilizzo per i processi a valle devono essere incentrati 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 spendere molte risorse per perfezionare le pipeline di importazione dal tuo data warehouse esistente a BigQuery. Alla fine, dovrai adattare queste pipeline in modo da non utilizzare il data warehouse esistente.

Ottimizza lo schema

Eseguire la migrazione delle tabelle così come sono in BigQuery ti consente di sfruttare le sue funzionalità 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 invariato il modello del data warehouse oltre le iterazioni iniziali della migrazione presenta anche degli svantaggi:

I problemi esistenti e il debito tecnico associato allo schema rimangono invariati.
Le ottimizzazioni delle query sono limitate e potrebbero dover essere rifatte se lo schema viene aggiornato in un secondo momento.
Non puoi sfruttare appieno altre funzionalità di BigQuery, come 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 suddividere le tabelle in base a una colonna TIMESTAMP o DATE oppure BigQuery può aggiungere pseudocolonne per suddividere automaticamente i dati durante l'importazione. Le query che coinvolgono partizioni più piccole possono essere più performanti perché analizzano solo un sottoinsieme di dati e possono ridurre i costi riducendo al minimo il numero di byte letti.

La suddivisione in partizioni non influisce sulla struttura esistente delle tabelle. Pertanto, dovresti valutare la possibilità 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 suo modello di base, dalle tecniche di archiviazione e query e dall'architettura massively parallel. Quando esegui una query, più dati vengono elaborati, più macchine vengono aggiunte per analizzare i dati e aggregare i risultati contemporaneamente. Questa tecnica è scalabile per set di dati enormi, mentre la ricostruzione degli indici non lo è.

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 all'utilizzo di un cluster. Con il clustering, BigQuery può stimare meglio il costo dell'esecuzione della query rispetto a un caso in cui non è presente il clustering. Con le colonne raggruppate, le query eliminano anche le scansioni di dati non necessari e possono calcolare gli aggregati più velocemente perché i blocchi collocano insieme i record con valori simili.

Esamina le query per individuare le colonne utilizzate di frequente per i filtri e crea le tue tabelle con il clustering su queste colonne. Per ulteriori informazioni sul clustering, consulta Introduzione alle tabelle clusterizzate.

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 i campi nidificati e ripetuti.

In passato, gli schemi dei data warehouse utilizzavano 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 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 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 in modo da utilizzare campi nidificati e ripetuti è un'ottima scelta evolutiva. Riduce il numero di join richiesti per le query e allinea lo schema alla rappresentazione dei dati interni di BigQuery. All'interno, 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 la tua situazione, valuta la possibilità di utilizzare campi nidificati e ripetuti in BigQuery, nonché le tecniche per gestire le modifiche dello 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: