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 in BigQuery.

La migrazione del data warehouse nel cloud è un processo complesso che richiede pianificazione, risorse e tempo. Per contenere questa complessità, devi affrontare i dati della migrazione del 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 di avvio prima della migrazione.

Lo stato finale del tuo percorso è avere il maggior numero possibile di casi d'uso basato su BigQuery. Questo stato consente di ridurre al minimo l'uso dal tuo data warehouse esistente per poi 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 pianificazione fase della migrazione, devi identificare i casi d'uso di cui vuoi eseguire la migrazione. Successivamente, avvii le iterazioni della migrazione esegui durante la fase di sviluppo. 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 downstream.
- Trasferisci il gruppo di tabelle per ogni caso d'uso in BigQuery senza alcuna modifica, grazie a BigQuery Data Transfer Service o un altro strumento ETL. Per informazioni sugli strumenti, consulta 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 ancora leggono dal data warehouse esistente, come mostrato nei flussi con l'etichetta A.
Configura alcuni processi upstream di test in cui scrivere i dati o in aggiunta alle tabelle BigQuery esistenti e il data warehouse.

Dopo il test, configura la produzione upstream e downstream di scrittura e lettura nelle tabelle BigQuery. Questi possono connettersi a BigQuery utilizzando 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 rimasti invariati e sono ancora incentrati sul un data warehouse esistente.
2. Scaricato. 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 nuovo 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 rivisita quelle che sono rimaste in stato di offload per spostarle completamente di cui è stata eseguita la migrazione. 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.

Evolvere lo schema in BigQuery

Lo schema del data warehouse definisce il modo in cui sono strutturati i dati e i relazioni tra le entità 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 dell'ambiente di data warehouse in esecuzione durante le modifiche allo schema con l'interruzione dei processi upstream e downstream.

I passaggi di questa sezione sono incentrati sulla trasformazione dello schema per un uso singolo per verificare se è così.

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 gli asset upstream e i processi downstream del tuo caso d'uso scrivono e leggono già in BigQuery. Tuttavia, puoi anche iniziare da una stato intermedio in cui solo il processo downstream legge in 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 in BigQuery.
Applica ottimizzazioni della luce.
1. Ricrea le tabelle, applicando partizionamento e il clustering. Per questa attività, puoi utilizzare il metodo per creare una tabella da una query o il risultato finale. Per maggiori dettagli, consulta Discussione e esempio per le tabelle partizionate e controlla discussione e esempio per le tabelle in cluster.
2. Reindirizza i processi upstream e downstream 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 di facciata maschera le tabelle sottostanti nascondendo la complessità causata dalle modifiche alle tabelle dei processi downstream.

Le viste possono descrivere un nuovo schema, privo di problemi tecnici, e modellati tenendo a mente nuovi scenari di importazione e consumo.

Di base, le tabelle e la definizione delle query di visualizzazione stessa possono modifica. Ma le opinioni astraevano questi cambiamenti come dettagli di implementazione del data warehouse e restituiscono sempre gli stessi risultati. Questo strato di astrazione delle viste facciate isola i sistemi upstream e downstream dai cambiamenti 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 sfruttano già lo schema evoluto. È trasparente per questi in base ai quali le viste di facciata continuano a raccogliere i dati lo schema BigQuery di origine, come mostrato di seguito diagramma:

Per prima cosa, descriviamo la trasformazione del processo downstream. Ciò consente più rapidamente il valore della tua attività, 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 alcuni dei tuoi processi upstream in modo che scrivano nel nuovo . Poiché le visualizzazioni sono di sola lettura, le tabelle vengono create in base al nuovo e modifica la definizione della query delle viste di facciata. Alcune viste continuerà a eseguire query sullo schema di origine, mentre altre eseguiranno query sullo schema di origine, o eseguire un'operazione SQL UNION su entrambe, come mostrato in diagramma seguente:

A questo punto, puoi sfruttare campi nidificati e ripetuti quando crei le nuove tabelle. In questo modo puoi denormalizzare ulteriormente e sfruttare direttamente BigQuery sottostante a colonne rappresentazione dei dati.

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

Infine, puoi trasformare i restanti upstream e downstream i processi di machine learning. Quando tutti questi aspetti si evolvono per scrivere nelle nuove tabelle per leggere dalle nuove viste frontali, devi modificare le definizioni della query per non leggere 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 di facciata 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 alcuna modifica durante la fase iniziale iterazioni della migrazione. Questo offre i seguenti vantaggi:

Le pipeline di dati che alimentano il data warehouse non devono essere modificati in base a un nuovo schema.
Eviterai di aggiungere un nuovo schema all'elenco del materiale di addestramento 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 è ancora utilizzato come parte 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 di se vuoi tagliare o modificare arricchire i tuoi dati prima di caricarli in BigQuery potresti includere un passaggio per trasformare i dati. Puoi trasformare esistenti nell'ambiente o su Google Cloud:

Se trasformi i dati nell'ambiente attuale, considera come la capacità di calcolo e gli strumenti di calcolo disponibili potrebbero limitare la velocità effettiva. 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 una 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 in batch, 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 esistente, copiali la gestione temporanea dell'archiviazione 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, devi caricare i file estratti in un bucket in Cloud Storage. In base quantità di dati da trasferire e la 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 Google Cloud CLI. gcloud CLI supporta i caricamenti paralleli a più thread, 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 puoi modificare le dimensioni una connessione a Google Cloud aumenta la larghezza di banda.
Se non disponi di una larghezza di banda di rete sufficiente, puoi eseguire una trasferimento offline tramite un Transfer Appliance.

Quando crei il bucket Cloud Storage e trasferisci i dati attraverso la rete, minimizza la latenza di 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 lo spostamento dei dati Cloud Storage, inclusa la stima dei costi, consulta Strategie per trasferire set di big data.

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 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 devono essere ulteriormente trasformati durante il caricamento 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 e arricchimento dei dati grafici utilizzando Apache Beam model. Dataflow è serverless e completamente gestito Google, che dà accesso a una capacità di elaborazione praticamente illimitata.
Dataproc. Esegue i cluster Apache Spark e Apache Hadoop su una piattaforma completamente gestito di Google Cloud.
Strumenti di terze parti. Contatta uno dei nostri partner. Ti offrono scelte efficaci per esternalizzare di una pipeline di dati.

Il seguente diagramma mostra il pattern descritto in questa sezione. I dati che lo strumento di trasferimento gsutil, una versione legacy di gcloud CLI ed è disponibile 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. 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 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 dai dati trasferiti a 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 esempio contare, somma, media) e le colonne a cui devono essere applicate. Per ulteriori informazioni, vedi Automatizza la convalida dei dati con DVT.

Ripeti il trasferimento iniziale

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

Un sottoinsieme dei tuoi dati ora è in BigQuery. Ti stai preparando per: aumentare la quantità di dati utilizzati in BigQuery e per ridurre la dipendenza dal 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. Puoi utilizzare BigQuery Data Transfer Service, altri strumenti ETL come l'ambiente Storage Transfer Service, o di terze parti implementazioni.

Se utilizzi BigQuery Data Transfer Service, devi prima decidere quali tabelle spostare. Poi crei un pattern per i nomi delle tabelle per includerle. Infine, imposti e la pianificazione periodica di quando eseguire il trasferimento.

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

Configurare una pipeline di carico con i prodotti Google Cloud. Google fornisce un insieme di modelli Dataflow di flussi di dati per facilitare questa attività.
Utilizza una soluzione di uno dei nostri partner.

Nel breve termine, aumentare l'impatto delle tue 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 appropriato 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 creazione di indici, riordinamento dei blocchi di dati (vacuuming) o tempi di inattività un peggioramento delle prestazioni dovuto agli 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 sfrutti appieno le altre funzionalità di BigQuery, ad esempio campi nidificati e ripetuti, partizionamento e clustering.

Mentre procedi con il trasferimento finale, ti consigliamo di migliorare le prestazioni del sistema applicando il partizionamento e il clustering alle tabelle che crei nel tuo schema.

Partizionamento

BigQuery ti consente di dividere i dati in segmenti, partizioni, che rendono più semplice ed efficiente 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 quali nel clustering. Con il clustering, BigQuery ordina automaticamente i dati in base a i valori di alcune colonne da te specificate e collocarli in una posizione ottimale o blocchi di dimensioni ridotte. 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 in cluster, eliminano le scansioni di dati non necessari e possono calcolare i dati 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 i tuoi con clustering in queste colonne. Il clustering richiede tabelle partizionate ed è definito anche al momento della creazione della tabella.

Denormalizzazione

La migrazione dei dati è un processo iterativo. Di conseguenza, dopo aver spostato lo schema iniziale nel cloud, hai eseguito ottimizzazioni e testato alcuni casi d'uso chiave, potrebbe essere il momento funzionalità aggiuntive che traggono vantaggio dalla progettazione di base in 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, lo sconto e la quantità dell'ordine, 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 Snowflake. È simile allo schema a stella, ma con le sue tabelle delle dimensioni normalizzato, che conferisce allo schema l'aspetto di un fiocco di neve unico.

BigQuery supporta gli schemi a stella e a fiocco di neve, ma la rappresentazione nativa dello schema non è nessuna delle due. 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 tue query, e allinea lo schema ai dati interni di BigQuery una rappresentazione visiva. 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: