Panoramica: eseguire la migrazione dei data warehouse in BigQuery

Questo documento illustra i concetti generali che si applicano a qualsiasi tecnologia di data warehousing e descrive un framework che puoi utilizzare per organizzare e strutturare la migrazione a BigQuery.

Terminologia

Quando parliamo di migrazione dei data warehouse, utilizziamo la seguente terminologia:

Caso d'uso

Un caso d'uso comprende tutti i set di dati, l'elaborazione dei dati e le interazioni tra utenti e sistemi necessari per ottenere valore aziendale, ad esempio il monitoraggio dei volumi di vendita di un prodotto nel tempo. Nel data warehousing, il caso d'uso spesso è costituito da:

• Data pipelines che importano dati non elaborati da varie origini dati, come il database di gestione dei rapporti con i clienti (CRM).
• I dati archiviati nel data warehouse.
• Script e procedure per manipolare ed elaborare e analizzare ulteriormente i dati.
• Un'applicazione aziendale che legge o interagisce con i dati.

Carico di lavoro

Un insieme di casi d'uso connessi e con dipendenze condivise. Ad esempio, un caso d'uso potrebbe avere le seguenti relazioni e dipendenze:

• I report sugli acquisti possono essere autonomi ed è utile per comprendere le spese e richiedere sconti.
• La generazione di report sulle vendite può essere autonoma ed è utile per la pianificazione di campagne di marketing.
• La generazione di report su profitti e perdite, tuttavia, dipende sia dagli acquisti sia dalle vendite ed è utile per determinare il valore dell'azienda.

Applicazione aziendale

Un sistema con cui interagiscono gli utenti finali, ad esempio un report visivo o una dashboard. Un'applicazione aziendale può anche assumere la forma di una pipeline di dati operativi o di un ciclo di feedback. Ad esempio, dopo che le variazioni dei prezzi dei prodotti sono state calcolate o previste, una pipeline di dati operativi potrebbe aggiornare i nuovi prezzi dei prodotti in un database transazionale.

Processo upstream

I sistemi di origine e le pipeline di dati che caricano i dati nel data warehouse.

Processo downstream

Script, procedure e applicazioni aziendali utilizzati per elaborare, eseguire query e visualizzare i dati nel data warehouse.

Scarica migrazione

Una strategia di migrazione finalizzata a far funzionare il caso d'uso per l'utente finale nel nuovo ambiente il più rapidamente possibile o a sfruttare la capacità aggiuntiva disponibile nel nuovo ambiente. L'offload dei casi d'uso viene eseguito come segue:

• Copia e quindi sincronizzazione dello schema e dei dati dal data warehouse legacy.
• Migrazione di script, procedure e applicazioni aziendali a valle.

L'offload della migrazione può aumentare la complessità e il lavoro coinvolti nella migrazione delle pipeline di dati.

Migrazione completa

Un approccio di migrazione simile all'offload della migrazione, ma invece di copiare e quindi sincronizzare lo schema e i dati, puoi configurare la migrazione per importare i dati direttamente nel nuovo data warehouse su cloud dai sistemi di origine upstream. In altre parole, viene eseguita la migrazione anche delle pipeline di dati richieste per il caso d'uso.

Data warehouse aziendale (EDW)

Un data warehouse costituito non solo da un database analitico, ma anche da più procedure e componenti analitici critici. tra cui pipeline di dati, query e applicazioni aziendali necessarie per soddisfare i carichi di lavoro dell'organizzazione.

Data warehouse su cloud (CDW)

Un data warehouse con le stesse caratteristiche di un EDW, ma eseguito su un servizio completamente gestito nel cloud, in questo caso BigQuery.

Pipeline dati

Un processo che collega i sistemi di dati tramite una serie di funzioni e attività che eseguono vari tipi di trasformazione dei dati. Per maggiori dettagli, consulta Che cos'è una pipeline di dati? di questa serie.

Perché eseguire la migrazione a BigQuery?

Negli ultimi decenni, le organizzazioni hanno padroneggiato la scienza del data warehouse. Hanno applicato sempre più l'analisi descrittiva a grandi quantità di dati archiviati, ottenendo insight sulle loro operazioni aziendali principali. La business intelligence (BI) convenzionale, incentrata su query, report ed elaborazione analitica online, potrebbe essere stato un fattore di differenziazione in passato, creando o abbattendo un'azienda, ma non è più sufficiente.

Oggi le organizzazioni non solo hanno bisogno di comprendere gli eventi passati utilizzando l'analisi descrittiva, ma hanno bisogno anche dell'analisi predittiva, che spesso utilizza il machine learning (ML) per estrarre pattern di dati e fare affermazioni probabilistiche sul futuro. L'obiettivo principale è sviluppare analisi prescrittive che combinano lezioni del passato con previsioni sul futuro per guidare automaticamente le azioni in tempo reale.

Le pratiche tradizionali di data warehouse acquisiscono dati non elaborati da varie origini, che sono spesso sistemi di elaborazione transazionale online (OLTP). Quindi, un sottoinsieme di dati viene estratto in batch, trasformato in base a uno schema definito e caricato nel data warehouse. Poiché i data warehouse tradizionali acquisiscono un sottoinsieme di dati in batch e archiviano i dati in base a schemi rigidi, non sono adatti per la gestione dell'analisi in tempo reale o per la risposta a query spontanee. Google ha progettato BigQuery in parte in risposta a queste limitazioni intrinseche.

Le idee innovative sono spesso rallentate dalle dimensioni e dalla complessità dell'organizzazione IT che implementa e gestisce questi data warehouse tradizionali. La creazione di un'architettura di data warehouse scalabile, ad alta disponibilità e sicura può richiedere anni e investimenti considerevoli. BigQuery offre una sofisticata tecnologia Software as a Service (SaaS) che può essere utilizzata per le operazioni di data warehouse serverless. Questo ti consente di concentrarti sul miglioramento della tua attività principale delega a Google Cloud la manutenzione dell'infrastruttura e lo sviluppo della piattaforma.

BigQuery offre accesso a archiviazione, elaborazione e analisi dei dati strutturati, scalabili, flessibili e convenienti. Queste caratteristiche sono essenziali quando i volumi di dati crescono in modo esponenziale, per rendere disponibili le risorse di archiviazione ed elaborazione in base alle esigenze e per ottenere valore da questi dati. Inoltre, per le organizzazioni che hanno appena iniziato con l'analisi dei big data e il machine learning e che vogliono evitare le potenziali complessità dei sistemi di big data on-premise, BigQuery offre un metodo di pagamento a consumo per sperimentare i servizi gestiti.

Con BigQuery puoi trovare risposte a problemi precedentemente intrattabili, applicare il machine learning per scoprire pattern di dati emergenti e testare nuove ipotesi. Di conseguenza, puoi disporre di insight tempestivi sulle prestazioni della tua azienda, che ti consentono di modificare i processi per ottenere risultati migliori. Inoltre, l'esperienza dell'utente finale è spesso arricchita da insight pertinenti ricavati dall'analisi dei big data, come spiegheremo più avanti in questa serie.

Cosa e come eseguire la migrazione: il framework di migrazione

Eseguire una migrazione può essere un'impresa complessa e lunga. Pertanto, ti consigliamo di aderire a un framework per organizzare e strutturare il lavoro di migrazione in più fasi:

1. Preparati e scopri: preparati per la migrazione con l'individuazione del carico di lavoro e dei casi d'uso.
2. Pianifica: assegna priorità ai casi d'uso, definisci le misure di successo e pianifica la migrazione.
3. Esegui: ripeti tutti i passaggi della migrazione, dalla valutazione alla convalida.

Preparati e scopri

Nella fase iniziale, l'attenzione è concentrata sulla preparazione e sulla scoperta. Si tratta di offrire a te e ai tuoi stakeholder un'opportunità iniziale per scoprire i casi d'uso esistenti e sollevare le preoccupazioni iniziali. È importante anche condurre un'analisi iniziale dei vantaggi previsti. Questi includono miglioramenti in termini di prestazioni (ad esempio, maggiore contemporaneità) e riduzioni del costo totale di proprietà (TCO). Questa fase è fondamentale per stabilire il valore della migrazione.

In genere un data warehouse supporta un'ampia gamma di casi d'uso e ha un gran numero di stakeholder, dagli analisti di dati ai responsabili delle decisioni aziendali. Ti consigliamo di coinvolgere i rappresentanti di questi gruppi per capire bene quali casi d'uso esistono, se hanno un buon rendimento e se le parti interessate stanno pianificando nuovi casi d'uso.

Il processo della fase di rilevamento consiste nelle seguenti attività:

1. Esamina la proposta di valore di BigQuery e confrontala con quella del tuo data warehouse legacy.
2. Eseguire un'analisi iniziale del TCO.
3. Stabilisci quali casi d'uso sono interessati dalla migrazione.
4. Modellare le caratteristiche dei set di dati e delle pipeline di dati sottostanti di cui vuoi eseguire la migrazione per identificare le dipendenze.

Per ottenere insight sui casi d'uso, puoi sviluppare un questionario per raccogliere informazioni dagli esperti in materia (SME), dagli utenti finali e dalle parti interessate. Il questionario deve raccogliere le seguenti informazioni:

• Qual è l'obiettivo del caso d'uso? Qual è il valore dell'attività?
• Quali sono i requisiti non funzionali? Aggiornamento dei dati, utilizzo simultaneo e così via.
• Il caso d'uso fa parte di un carico di lavoro più grande? Dipende da altri casi d'uso?
• Quali set di dati, tabelle e schemi sono alla base del caso d'uso?
• Cosa sai delle pipeline di dati che alimentano questi set di dati?
• Quali strumenti, report e dashboard BI vengono attualmente utilizzati?
• Quali sono gli attuali requisiti tecnici in merito a esigenze operative, prestazioni, autenticazione e larghezza di banda di rete?

Il seguente diagramma mostra un'architettura legacy di alto livello prima della migrazione. Illustra il catalogo delle origini dati disponibili, le pipeline di dati legacy, le pipeline operative legacy e i loop di feedback, nonché i report e le dashboard BI legacy a cui gli utenti finali accedono.

Piano

La fase di pianificazione prevede l'acquisizione dell'input dalla fase di preparazione e individuazione, la valutazione dell'input e il relativo utilizzo per pianificare la migrazione. Questa fase può essere suddivisa nelle seguenti attività:

1. Cataloga e assegna priorità ai casi d'uso

   Ti consigliamo di suddividere il processo di migrazione in iterazioni. Cataloga i casi d'uso nuovi ed esistenti e assegni loro una priorità. Per maggiori dettagli, consulta le sezioni Eseguire la migrazione con un approccio iterativo e Assegnare priorità ai casi d'uso di questo documento.

2. Definire gli indicatori di successo

   È utile definire misure chiare di successo come gli indicatori chiave di prestazione (KPI) prima della migrazione. Le tue misure ti consentiranno di valutare il successo della migrazione a ogni iterazione. Questo, a sua volta, ti consente di apportare miglioramenti al processo di migrazione nelle iterazioni successive.

3. Creare una definizione di "completato"

   Nel caso delle migrazioni complesse, non è necessariamente chiaro quando hai completato la migrazione di un determinato caso d'uso. Pertanto, devi delineare una definizione formale dello stato finale previsto. Questa definizione dovrebbe essere abbastanza generica da poter essere applicata a tutti i casi d'uso di cui vuoi eseguire la migrazione. La definizione dovrebbe fungere da insieme di criteri minimi per considerare il caso d'uso da sottoporre a migrazione completa. Questa definizione in genere include checkpoint per garantire che il caso d'uso sia stato integrato, testato e documentato.

4. Progettare e proporre una proof of concept (PDC), uno stato a breve termine e uno stato finale ideale

   Dopo aver assegnato la priorità ai casi d'uso, puoi iniziare a considerarli durante l'intero periodo della migrazione. Considera la prima migrazione dei casi d'uso come proof of concept (PDC) per convalidare l'approccio di migrazione iniziale. Considera ciò che è possibile raggiungere nelle prime settimane o nei primi mesi come stato a breve termine. In che modo i piani di migrazione influiscono sugli utenti? Avranno una soluzione ibrida o è possibile eseguire prima la migrazione di un intero carico di lavoro per un sottoinsieme di utenti?

5. Crea stime di tempi e costi

   Per garantire il successo del progetto di migrazione, è importante produrre stime dei tempi realistiche. Per raggiungere questo obiettivo, coinvolgi tutti gli stakeholder per discutere della loro disponibilità e concordare il loro livello di coinvolgimento nel corso del progetto. Questo ti aiuterà a stimare i costi di manodopera in modo più accurato. Per stimare i costi relativi al consumo previsto delle risorse cloud, vedi Stima dei costi di archiviazione e query e Introduzione al controllo dei costi di BigQuery nella documentazione di BigQuery.

6. Identificare e coinvolgere un partner per la migrazione

   La documentazione di BigQuery descrive molti strumenti e risorse che puoi utilizzare per eseguire la migrazione. Tuttavia, può essere difficile eseguire in autonomia una migrazione complessa e di grandi dimensioni se non hai esperienza o non hai tutte le competenze tecniche necessarie all'interno della tua organizzazione. Ti consigliamo quindi di identificare e coinvolgere un partner per la migrazione. Per ulteriori dettagli, consulta i nostri programmi per partner globali e servizi di consulenza.

Eseguire la migrazione utilizzando un approccio iterativo

Quando si esegue la migrazione di un'operazione di data warehousing di grandi dimensioni nel cloud, è consigliabile adottare un approccio iterativo. Ti consigliamo quindi di eseguire la transizione a BigQuery in diverse iterazioni. La suddivisione dello sforzo di migrazione in iterazioni semplifica il processo complessivo, riduce i rischi e offre opportunità di apprendimento e di miglioramento dopo ogni iterazione.

Un'iterazione è composta da tutto il lavoro necessario per trasferire o eseguire la migrazione completa di uno o più casi d'uso correlati entro un periodo di tempo limite. Un'iterazione può essere considerata come un ciclo sprint nella metodologia agile, composta da una o più storie di utenti.

Per praticità e facilità di tracciamento, puoi considerare l'idea di associare un caso d'uso singolo a una o più storie utente. Prendiamo ad esempio la seguente storia utente: "In qualità di analista dei prezzi, voglio analizzare le variazioni di prezzo dei prodotti nel corso dell'ultimo anno per calcolare i prezzi futuri".

Il caso d'uso corrispondente potrebbe essere:

• Importazione dei dati da un database transazionale che archivia prodotti e prezzi.
• Trasformare i dati in un'unica serie temporale per ogni prodotto e inserire eventuali valori mancanti.
• Archiviazione dei risultati in una o più tabelle del data warehouse.
• Rendere i risultati disponibili tramite un blocco note Python (l'applicazione aziendale).

Il valore aziendale di questo caso d'uso è supportare l'analisi dei prezzi.

Come per la maggior parte dei casi d'uso, questo caso d'uso probabilmente supporterà più storie utente.

È probabile che un caso d'uso offline sia seguito da un'iterazione successiva per eseguire la migrazione completa del caso d'uso. In caso contrario, potresti avere ancora una dipendenza dal data warehouse legacy esistente, perché i dati vengono copiati da lì. La migrazione completa successiva è il delta tra l'offload e una migrazione completa che non è stata preceduta da un offload, in altre parole la migrazione delle pipeline di dati per estrarre, trasformare e caricare i dati nel data warehouse.

Dai priorità ai casi d'uso

Il punto di inizio e di fine della migrazione dipende dalle esigenze specifiche della tua attività. Decidere l'ordine in cui eseguire la migrazione dei casi d'uso è importante perché il successo tempestivo durante una migrazione è fondamentale per continuare il percorso di adozione del cloud. Un errore in una fase iniziale può diventare un grave peggioramento dello sforzo di migrazione complessivo. Potresti aver già usufruito dei vantaggi di Google Cloud e BigQuery, ma l'elaborazione di tutti i set di dati e delle pipeline di dati che sono stati creati o gestiti nel tuo data warehouse legacy per casi d'uso diversi può essere un'operazione complessa e dispendiosa in termini di tempo.

Sebbene non esista una risposta valida per tutti, esistono delle best practice che puoi utilizzare quando valuti i tuoi casi d'uso e le applicazioni aziendali on-premise. Questo tipo di pianificazione anticipata può semplificare il processo di migrazione e l'intera transizione a BigQuery.

Le seguenti sezioni esplorano i possibili approcci per dare priorità ai casi d'uso.

Approccio: sfruttare le opportunità attuali

Osserva le opportunità attuali che potrebbero aiutarti a massimizzare il ritorno sull'investimento di un caso d'uso specifico. Questo approccio è particolarmente utile se si è sotto pressione per giustificare il valore aziendale della migrazione al cloud. Offre inoltre l'opportunità di raccogliere punti dati aggiuntivi per valutare il costo totale della migrazione.

Ecco alcuni esempi di domande da porsi per aiutarti a identificare i casi d'uso a cui dare la priorità:

• Il caso d'uso è costituito da set di dati o pipeline di dati attualmente limitati dal data warehouse aziendale legacy?
• Il data warehouse aziendale esistente richiede un aggiornamento hardware o prevedi la necessità di espandere l'hardware? In tal caso, potrebbe essere interessante trasferire i casi d'uso a BigQuery il prima possibile.

L'identificazione delle opportunità di migrazione consente di ottenere vantaggi rapidi che apportano benefici tangibili e immediati per gli utenti e l'azienda.

Approccio: prima migrazione dei carichi di lavoro analitici

Esegui la migrazione dei carichi di lavoro di elaborazione analitica online (OLAP) prima dei carichi di lavoro di elaborazione delle transazioni online (OLTP). Un data warehouse è spesso l'unico posto nell'organizzazione in cui sono disponibili tutti i dati per creare un'unica visualizzazione globale delle operazioni dell'organizzazione. Di conseguenza, è frequente che le organizzazioni dispongano di alcune pipeline di dati che si rimettono in funzione nei sistemi transazionali per aggiornare lo stato o attivare i processi, ad esempio per acquistare più articoli quando l'inventario di un prodotto è ridotto. I carichi di lavoro OLTP tendono a essere più complessi e hanno requisiti operativi e accordi sul livello del servizio (SLA) più rigidi rispetto ai carichi di lavoro OLAP. Di conseguenza, tende a essere più semplice eseguire prima la migrazione dei carichi di lavoro OLAP.

Approccio: attenzione all'esperienza utente

Identifica le opportunità per migliorare l'esperienza utente eseguendo la migrazione di set di dati specifici e abilitando nuovi tipi di analisi avanzate. Ad esempio, un modo per migliorare l'esperienza utente è l'analisi in tempo reale. Puoi creare esperienze utente sofisticate basate su un flusso di dati in tempo reale quando è unito ai dati storici. Ad esempio:

• Un dipendente di back office che ha ricevuto un avviso sulla sua app mobile per la disponibilità in esaurimento.
• Un cliente online che potrebbe trarre vantaggio dalla consapevolezza che, spendendo un altro dollaro, potrebbe passare al livello premio successivo.
• Infermiere avvisato sui parametri vitali di un paziente sullo smartwatch, in modo da poter agire nel modo migliore visualizzando la cronologia del trattamento del paziente sul tablet.

Puoi anche migliorare l'esperienza utente con analisi predittive e prescrittive. A questo scopo, puoi utilizzare BigQuery ML, la tabella AutoML di Vertex AI o i modelli preaddestrati di Google per analisi delle immagini, analisi video, riconoscimento vocale, linguaggio naturale e traduzione. In alternativa, puoi pubblicare il tuo modello con addestramento personalizzato utilizzando Vertex AI per i casi d'uso su misura per le tue esigenze aziendali. Ciò potrebbe comportare quanto segue:

• Consigliare un prodotto in base alle tendenze del mercato e al comportamento di acquisto degli utenti.
• Previsione del ritardo di un volo.
• Rilevamento di attività fraudolente.
• Segnalare contenuti inappropriati.
• Altre idee innovative che potrebbero distinguere la tua app dalla concorrenza.

Approccio: dare priorità ai casi d'uso meno pericolosi

Ci sono una serie di domande che l'IT può porre per valutare quali casi d'uso sono i meno rischiosi da migrare, il che li rende più interessanti per la migrazione nelle prime fasi della migrazione. Ad esempio:

• Qual è l'importanza di questo caso d'uso per l'attività?
• Un numero elevato di dipendenti o clienti dipende dal caso d'uso?
• Qual è l'ambiente di destinazione (ad esempio sviluppo o produzione) per il caso d'uso?
• Qual è il grado di comprensione del caso d'uso da parte del nostro team IT?
• Quante dipendenze e integrazioni ha il caso d'uso?
• Il nostro team IT dispone di una documentazione adeguata, aggiornata e completa per il caso d'uso?
• Quali sono i requisiti operativi (SLA) per il caso d'uso?
• Quali sono i requisiti di conformità legali o governativi per il caso d'uso?
• Quali sono i livelli di inattività e latenza per l'accesso al set di dati sottostante?
• Ci sono proprietari di linee di business desiderosi e disposti a migrare il loro caso d'uso prima?

Analizzare questo elenco di domande può aiutarti a classificare i set di dati e le pipeline di dati dal rischio più basso a quello più alto. Devi prima eseguire la migrazione degli asset a basso rischio, mentre quelli a rischio più elevato dovrebbero venire in seguito.

Esegui

Dopo aver raccolto informazioni sui tuoi sistemi legacy e creato un backlog prioritario di casi d'uso, puoi raggruppare i casi d'uso in carichi di lavoro e procedere con la migrazione in iterazioni.

Un'iterazione può essere composta da un singolo caso d'uso, da alcuni casi d'uso distinti o da una serie di casi d'uso relativi a un singolo carico di lavoro. La scelta delle opzioni per l'iterazione dipende dall'interconnettività dei casi d'uso, dalle eventuali dipendenze condivise e dalle risorse a tua disposizione per eseguire queste operazioni.

Una migrazione in genere prevede i seguenti passaggi:

Questi passaggi sono descritti in maggiore dettaglio nelle sezioni seguenti. Potrebbe non essere necessario eseguire tutti questi passaggi in ogni iterazione. Ad esempio, in un'iterazione potresti decidere di concentrarti sulla copia di alcuni dati dal data warehouse legacy in BigQuery. Al contrario, in un'iterazione successiva potresti concentrarti sulla modifica della pipeline di importazione da un'origine dati originale direttamente a BigQuery.

1. Configurazione e governance dei dati

La configurazione è il lavoro di base richiesta per consentire l'esecuzione dei casi d'uso su Google Cloud. La configurazione può includere la configurazione dei progetti Google Cloud, della rete, del VPC (Virtual Private Cloud) e della governance dei dati. Inoltre, devi capire bene dove ti trovi oggi, cosa funziona e cosa no. Questo ti aiuta a comprendere i requisiti per la tua migrazione. Per assisterti in questo passaggio, puoi utilizzare la funzionalità di valutazione della migrazione di BigQuery.

La governance dei dati è un solido approccio alla gestione dei dati durante il loro ciclo di vita, dall'acquisizione all'uso fino allo smaltimento. Il programma di governance dei dati definisce chiaramente criteri, procedure, responsabilità e controlli relativi alle attività sui dati. Questo programma aiuta a garantire che le informazioni vengano raccolte, gestite, utilizzate e diffuse in modo da soddisfare l'integrità dei dati e le esigenze di sicurezza della tua organizzazione. Inoltre, consente ai tuoi dipendenti di scoprire e utilizzare i dati al massimo delle loro potenzialità.

La documentazione sulla governance dei dati ti aiuta a comprendere la governance dei dati e i controlli di cui hai bisogno durante la migrazione del data warehouse on-premise a BigQuery.

2. Esegui la migrazione di schema e dati

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

La documentazione sul trasferimento di schemi e dati fornisce informazioni dettagliate su come spostare i dati in BigQuery e suggerimenti per l'aggiornamento dello schema per sfruttare appieno le funzionalità di BigQuery.

3. Traduci le query

Utilizza la traduzione SQL in gruppo per eseguire la migrazione collettiva del codice SQL oppure la traduzione SQL interattiva per tradurre le query ad hoc.

Alcuni data warehouse legacy includono estensioni allo standard SQL per abilitare le funzionalità del loro prodotto. BigQuery non supporta queste estensioni proprietarie, ma è conforme allo standard ANSI/ISO SQL:2011. Ciò significa che alcune query potrebbero comunque richiedere il refactoring manuale se i traduttori SQL non sono in grado di interpretarle.

4. Esegui la migrazione delle applicazioni aziendali

Le applicazioni aziendali possono assumere molte forme: dalle dashboard alle applicazioni personalizzate, fino alle pipeline di dati operativi che forniscono loop di feedback ai sistemi transazionali.

Per saperne di più sulle opzioni di analisi quando si lavora con BigQuery, consulta Panoramica dell'analisi di BigQuery. Questo argomento fornisce una panoramica degli strumenti di generazione di report e analisi che puoi utilizzare per ottenere informazioni interessanti dai tuoi dati.

La sezione sui loop di feedback nella documentazione relativa alla pipeline di dati descrive come utilizzare una pipeline di dati per creare un loop di feedback ed eseguire il provisioning di sistemi upstream.

5. Esegui la migrazione delle pipeline di dati

La documentazione sulle pipeline di dati presenta procedure, pattern e tecnologie per la migrazione delle tue pipeline di dati legacy in Google Cloud. Ti aiuta a capire cos'è una pipeline di dati, quali procedure e pattern può utilizzare e quali opzioni e tecnologie di migrazione sono disponibili in relazione alla migrazione di data warehouse di maggiori dimensioni.

6. Ottimizzazione del rendimento

BigQuery elabora i dati in modo efficiente sia per set di dati di piccole dimensioni che per quelli di petabyte. Con l'aiuto di BigQuery, i job di analisi dei dati dovrebbero funzionare correttamente senza modifiche nel data warehouse appena sottoposto a migrazione. Se noti che in determinate circostanze le prestazioni delle query non corrispondono alle tue aspettative, consulta Introduzione all'ottimizzazione delle prestazioni delle query per istruzioni.

7. Verifica e convalida

Al termine di ogni iterazione, verifica che la migrazione del caso d'uso sia riuscita verificando che:

• La migrazione dei dati e dello schema è stata completata.
• I problemi di governance dei dati sono stati completamente soddisfatti e testati.
• Sono state stabilite le procedure di manutenzione e monitoraggio e l'automazione.
• Le query sono state tradotte correttamente.
• Le pipeline di dati migrate funzionano come previsto.
• Le applicazioni aziendali sono configurate correttamente per l'accesso ai dati e alle query di cui è stata eseguita la migrazione.

Puoi iniziare con lo strumento di convalida dei dati, uno strumento open source dell'interfaccia a riga di comando di Python che confronta i dati degli ambienti di origine e di destinazione per assicurarsi che corrispondano. Supporta più tipi di connessione, oltre a funzionalità di convalida multilivello.

È anche una buona idea misurare l'impatto della migrazione dei casi d'uso, ad esempio in termini di miglioramento delle prestazioni, riduzione dei costi o apertura di nuove opportunità tecniche o di business. Quindi puoi quantificare in modo più accurato il valore del ritorno sull'investimento e confrontarlo con i criteri di successo dell'iterazione.

Dopo la convalida dell'iterazione, puoi rilasciare il caso d'uso di cui è stata eseguita la migrazione in produzione e concedere agli utenti l'accesso ai set di dati e alle applicazioni aziendali migrati.

Infine, prendi appunti e documenta le lezioni apprese da questa iterazione, in modo da poter applicare queste lezioni nella prossima iterazione e accelerare la migrazione.

Riepilogo dell'impegno di migrazione

Durante la migrazione, esegui sia il data warehouse legacy sia BigQuery, come descritto in questo documento. L'architettura di riferimento nel seguente diagramma evidenzia che entrambi i data warehouse offrono funzionalità e percorsi simili: entrambi possono importare dai sistemi di origine, integrarsi con le applicazioni aziendali e fornire l'accesso utente richiesto. È importante sottolineare anche che i dati sono sincronizzati dal data warehouse a BigQuery. Ciò consente di scaricare i casi d'uso per l'intera durata dell'attività di migrazione.

Supponendo che l'intento sia la migrazione completa dal data warehouse a BigQuery, lo stato finale della migrazione sarà il seguente:

Passaggi successivi

Scopri di più sui seguenti passaggi nella migrazione del data warehouse:

• Valutazione della migrazione
• Panoramica del trasferimento di schemi e dati
• pipeline di dati
• Traduzione SQL batch
• Traduzione SQL interattiva
• Sicurezza e governance dei dati
• Strumento di convalida dei dati

Puoi anche scoprire come passare da tecnologie di data warehouse specifiche a BigQuery:

• Migrazione da Netezza
• Migrazione da Oracle
• Migrazione da Amazon Redshift
• Migrazione da Teradata
• Migrazione da Snowflake