Panoramica: eseguire la migrazione dei data warehouse in BigQuery

Questo documento illustra i concetti generali applicabili 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 del data warehouse, utilizziamo la seguente terminologia:

Caso d'uso
Un caso d'uso è costituito da tutti i set di dati, dall'elaborazione dei dati e dalle interazioni di sistema e utente necessarie 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 consiste in:
  • Data pipelines che acquisiscono dati non elaborati da varie origini dati, ad esempio il database di gestione dei rapporti con i clienti (CRM).
  • I dati archiviati nel data warehouse.
  • Script e procedure per manipolare, elaborare e analizzare ulteriormente i dati.
  • Un'applicazione aziendale che legge o interagisce con i dati.
Workload
Un insieme di casi d'uso collegati e con dipendenze condivise. Ad esempio, un caso d'uso potrebbe avere le seguenti relazioni e dipendenze:
  • I report sugli acquisti possono essere utilizzati in modo indipendente ed è utile per comprendere le spese e richiedere sconti.
  • I report sulle vendite possono essere utilizzati singolarmente ed sono utili per pianificare le campagne di marketing.
  • Il report su utili e perdite, tuttavia, dipende sia dagli acquisti che 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 operativa o di un ciclo di feedback. Ad esempio, dopo che sono state calcolate o previste le variazioni di prezzo dei prodotti, una pipeline di dati operativi potrebbe aggiornare i nuovi prezzi dei prodotti in un database transazionale.
Procedura upstream
I sistemi di origine e le pipeline di dati che caricano i dati nel data warehouse.
Processo downstream
Gli script, le procedure e le applicazioni aziendali utilizzati per elaborare, interrogare e visualizzare i dati nel data warehouse.
Migrazione dell'offload
Una strategia di migrazione che mira 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. I casi d'uso vengono scaricati nel seguente modo:
  • Copia e sincronizzazione dello schema e dei dati dal data warehouse legacy.
  • Migrazione di script, procedure e applicazioni aziendali downstream.

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

Migrazione completa
Un approccio di migrazione simile a una migrazione di offload, ma invece di copiare e poi sincronizzare lo schema e i dati, configuri la migrazione in modo da importare i dati direttamente nel nuovo data warehouse su cloud dai sistemi di origine upstream. In altre parole, vengono migrate anche le pipeline di dati necessarie per il caso d'uso.
Enterprise Data Warehouse (EDW)
Un data warehouse costituito non solo da un database analitico, ma da più componenti e procedure analitiche critiche. Questi includono pipeline di dati, query e applicazioni aziendali necessari per soddisfare i carichi di lavoro dell'organizzazione.
Data warehouse su cloud (CDW)
Un data warehouse con le stesse caratteristiche di un EDW, ma in esecuzione su un servizio completamente gestito nel cloud, in questo caso, BigQuery.
Pipeline di 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 i dettagli, vedi Che cos'è una pipeline di dati? di questa serie.

Perché eseguire la migrazione a BigQuery?

Negli ultimi decenni, le organizzazioni hanno acquisito una grande esperienza nella scienza del data warehousing. Hanno applicato sempre più spesso l'analisi descrittiva a grandi quantità di dati archiviati, ottenendo informazioni sulle loro operazioni aziendali principali. La Business Intelligence (BI) convenzionale, incentrata su query, report e Online Analytical Processing, potrebbe essere stata un fattore differenziante in passato, in grado di determinare il successo o il fallimento di un'azienda, ma non è più sufficiente.

Oggi, le organizzazioni non solo devono comprendere gli eventi passati utilizzando l'analisi descrittiva, ma hanno bisogno dell'analisi predittiva, che spesso utilizza il machine learning (ML) per estrarre i pattern di dati e fare affermazioni probabilistiche sul futuro. L'obiettivo finale è sviluppare l'analisi prescrittiva che combini le lezioni del passato con le 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 spesso sono sistemi di elaborazione transazionale online (OLTP). Successivamente, 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 li archiviano in base a schemi rigidi, non sono adatti alla gestione di analisi in tempo reale o alla risposta a query spontanee. Google ha progettato BigQuery in parte in risposta a questi limiti intrinseci.

Le idee innovative vengono spesso rallentate dalle dimensioni e dalla complessità dell'organizzazione IT che implementa e gestisce questi data warehouse tradizionali. Per creare un'architettura di data warehouse scalabile, sicura e ad alta disponibilità possono volerci anni e investimenti sostanziali. BigQuery offre una sofisticata tecnologia software as a service (SaaS) che può essere utilizzata per le operazioni del data warehouse serverless. In questo modo puoi concentrarti sul tuo core business delegando la manutenzione dell'infrastruttura e lo sviluppo della piattaforma a Google Cloud.

BigQuery offre accesso all'archiviazione, all'elaborazione e all'analisi dei dati strutturati in modo scalabile, flessibile e conveniente. Queste caratteristiche sono essenziali quando i volumi di dati crescono in modo esponenziale, sia per rendere disponibili le risorse di archiviazione e di elaborazione in base alle esigenze sia per ottenere valore da tali dati. Inoltre, per le organizzazioni che stanno iniziando a utilizzare l'analisi dei big data e il machine learning e che vogliono evitare le potenziali complessità dei sistemi big data on-premise, BigQuery offre un modo pay-as-you-go 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, ottieni informazioni tempestive sul rendimento della tua attività, il che ti consente di modificare i processi per ottenere risultati migliori. Inoltre, l'esperienza dell'utente finale viene spesso arricchita con approfondimenti pertinenti ottenuti dall'analisi dei big data, come spieghiamo più avanti in questa serie.

Cosa e come eseguire la migrazione: il framework di migrazione

L'esecuzione di una migrazione può essere un'attività complessa e lunga. Pertanto, ti consigliamo di seguire un framework per organizzare e strutturare il lavoro di migrazione in fasi:

  1. Preparazione e individuazione: preparati per la migrazione con l'individuazione di carichi di lavoro e casi d'uso.
  2. Pianifica: dai la priorità ai casi d'uso, definisci le misure di successo e pianifica la migrazione.
  3. Esegui: esegui i passaggi per la migrazione, dalla valutazione alla convalida.

Preparare e scoprire

Nella fase iniziale, l'attenzione è rivolta alla preparazione e alla scoperta. Si tratta di offrire a te e ai tuoi stakeholder l'opportunità di scoprire in anticipo i casi d'uso esistenti e sollevare i primi dubbi. È importante anche condurre un'analisi iniziale dei vantaggi previsti. Questi includono miglioramenti delle prestazioni (ad esempio, una migliore concorrenza) e riduzioni del costo totale di proprietà (TCO). Questa fase è fondamentale per aiutarti a stabilire il valore della migrazione.

Un data warehouse in genere 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 rappresentanti di questi gruppi per comprendere bene quali casi d'uso esistono, se questi casi d'uso funzionano bene e se le parti interessate stanno pianificando nuovi casi d'uso.

La procedura della fase di scoperta è costituita dalle seguenti attività:

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

Per ottenere informazioni sui casi d'uso, puoi sviluppare un questionario per raccogliere informazioni da esperti in materia, utenti finali e stakeholder. 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 workload 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 di BI vengono attualmente utilizzati?
  • Quali sono i requisiti tecnici attuali relativi a esigenze operative, rendimento, autenticazione e larghezza di banda della 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 cicli di feedback, nonché i report e le dashboard di BI legacy a cui accedono gli utenti finali.

Data warehouse legacy, che mostra le origini dati (vendite, marketing, produzione, budget e così via) che alimentano il data warehouse. I report e le dashboard di BI sono processi downstream.

Piano

La fase di pianificazione consiste nel prendere l'input della fase di preparazione e rilevamento, valutarlo e utilizzarlo per pianificare la migrazione. Questa fase può essere suddivisa nelle seguenti attività:

  1. Catalogare e dare la priorità ai casi d'uso

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

  2. Definisci le misure di successo

    È utile definire misure di successo chiare, come gli indicatori chiave di prestazione (KPI), prima della migrazione. Le misure ti consentiranno di valutare l'esito della migrazione a ogni iterazione. In questo modo, potrai apportare miglioramenti al processo di migrazione nelle iterazioni successive.

  3. Crea una definizione di "fine"

    Con le migrazioni complesse, non è necessariamente ovvio quando hai terminato la migrazione di un determinato caso d'uso. Pertanto, devi delineare una definizione formale dello stato finale previsto. Questa definizione deve essere sufficientemente generica da poter essere applicata a tutti i casi d'uso che vuoi migrare. La definizione deve fungere da insieme di criteri minimi da considerare per la migrazione completa del caso d'uso. Questa definizione in genere include punti di controllo per assicurarsi che il caso d'uso sia stato integrato, testato e documentato.

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

    Dopo aver dato la priorità ai casi d'uso, puoi iniziare a pensarli per l'intero periodo della migrazione. Considera la migrazione del primo caso d'uso come proof of concept (PoC) per convalidare l'approccio di migrazione iniziale. Considera ciò che è realizzabile nelle prime settimane o mesi come stato a breve termine. In che modo i tuoi piani di migrazione influiranno sugli utenti? Avranno una soluzione ibrida o puoi eseguire la migrazione di un intero carico di lavoro per un sottoinsieme di utenti?

  5. Creare stime di tempo e costi

    Per garantire il successo di un progetto di migrazione, è importante produrre stime di tempo realistiche. Per raggiungere questo obiettivo, interagisci con tutte le parti interessate pertinenti per discutere della loro disponibilità e concordare il loro livello di coinvolgimento durante il progetto. In questo modo potrai stimare i costi della manodopera in modo più preciso. Per stimare i costi relativi al consumo previsto delle risorse cloud, consulta Stima dei costi di query e archiviazione 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 una migrazione complessa e di grandi dimensioni in autonomia se non hai esperienza precedente o non disponi di tutte le competenze tecniche richieste all'interno della tua organizzazione. Pertanto, ti consigliamo di identificare e coinvolgere un partner per la migrazione fin dall'inizio. Per ulteriori dettagli, consulta i nostri programmi global partner e servizi di consulenza.

Eseguire la migrazione utilizzando un approccio iterativo

Quando esegui la migrazione di un'operazione di data warehousing di grandi dimensioni al cloud, è una buona idea adottare un approccio iterativo. Pertanto, ti consigliamo di eseguire la transizione a BigQuery in modo iterativo. Dividere l'impegno di migrazione in iterazioni semplifica il processo complessivo, riduce i rischi e offre opportunità di apprendimento e miglioramento dopo ogni iterazione.

Un'iterazione è costituita da tutto il lavoro necessario per eseguire l'offload o la migrazione completa di uno o più casi d'uso correlati in un periodo di tempo limitato. Puoi considerare un'iterazione come un ciclo di sprint nella metodologia agile, costituito da una o più storie utente.

Per comodità e facilità di monitoraggio, potresti prendere in considerazione l'idea di associare un caso d'uso individuale a una o più user story. Ad esempio, considera la seguente storia utente: "In qualità di analista dei prezzi, voglio analizzare le variazioni di prezzo dei prodotti nell'ultimo anno per poter calcolare i prezzi futuri".

Il caso d'uso corrispondente potrebbe essere:

  • Importazione dei dati da un database transazionale che memorizza prodotti e prezzi.
  • Trasformando i dati in un'unica serie temporale per ogni prodotto e inserendo i valori mancanti.
  • Archiviazione dei risultati in una o più tabelle nel data warehouse.
  • Rendere disponibili i risultati tramite un notebook 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ù user story.

Un caso d'uso scaricato verrà probabilmente seguito da un'iterazione successiva per migrarlo completamente. In caso contrario, potresti comunque avere una dipendenza dal data warehouse legacy esistente, perché i dati vengono copiati da lì. La successiva migrazione completa è la differenza tra l'offload e una migrazione completa che non è stata preceduta da un offload, in altre parole, la migrazione della pipeline o delle pipeline di dati per estrarre, trasformare e caricare i dati nel data warehouse.

Dare la priorità ai casi d'uso

Il punto di partenza e di arrivo della migrazione dipende dalle esigenze specifiche della tua attività. Decidere l'ordine in cui migrare i casi d'uso è importante perché il successo iniziale durante una migrazione è fondamentale per continuare il percorso di adozione del cloud. Un errore in una fase iniziale può diventare un grave ostacolo per l'intero processo di migrazione. Potresti essere d'accordo con i vantaggi di Google Cloud e BigQuery, ma l'elaborazione di tutti i set di dati e delle pipeline di dati creati o gestiti nel tuo data warehouse legacy per diversi casi d'uso può essere complicata e richiedere molto tempo.

Sebbene non esista una risposta univoca, ci sono best practice che puoi utilizzare per valutare i tuoi casi d'uso on-premise e le applicazioni aziendali. Questo tipo di pianificazione iniziale può semplificare il processo di migrazione e l'intera transizione a BigQuery.

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

Approccio: sfruttare le opportunità attuali

Esamina le opportunità attuali che potrebbero aiutarti a massimizzare il ritorno sull'investimento di un caso d'uso specifico. Questo approccio è particolarmente utile se devi giustificare il valore aziendale della migrazione al cloud. Inoltre, offre l'opportunità di raccogliere punti dati aggiuntivi per valutare il costo totale della migrazione.

Ecco alcune domande di esempio da porre 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 che sono attualmente limitati dal data warehouse aziendale legacy?
  • Il tuo data warehouse aziendale esistente richiede un aggiornamento hardware o prevedi la necessità di espandere l'hardware? In questo caso, può essere vantaggioso eseguire l'offload dei casi d'uso in BigQuery prima piuttosto che dopo.

L'identificazione delle opportunità di migrazione può creare alcuni risultati rapidi che producono vantaggi tangibili e immediati per gli utenti e l'attività.

Approccio: esegui la migrazione prima dei carichi di lavoro analitici

Esegui la migrazione dei workload Online Analytical Processing (OLAP) prima dei workload Online Transaction Processing (OLTP). Un data warehouse è spesso l'unico posto nell'organizzazione in cui hai tutti i dati per creare una visione singola e globale delle operazioni dell'organizzazione. Pertanto, è normale che le organizzazioni abbiano alcune pipeline di dati che vengono reindirizzate ai sistemi transazionali per aggiornare lo stato o attivare processi, ad esempio per acquistare più scorte quando l'inventario di un prodotto è basso. I carichi di lavoro OLTP tendono a essere più complessi e hanno requisiti operativi e accordi sul livello del servizio (SLA) più rigorosi rispetto ai carichi di lavoro OLAP, quindi tende anche a essere più facile eseguire la migrazione prima dei carichi di lavoro OLAP.

Approccio: concentrati sull'esperienza utente

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

  • Un dipendente del back office che riceve un avviso nell'app mobile relativo alle scorte in esaurimento.
  • Un cliente online che potrebbe trarre vantaggio dal sapere che spendendo un altro euro potrebbe accedere al livello di premio successivo.
  • Un infermiere che riceve un avviso sui parametri vitali di un paziente sul suo smartwatch, il che gli consente di intraprendere la migliore linea di condotta consultando la cronologia dei trattamenti del paziente sul suo tablet.

Puoi anche migliorare l'esperienza utente con l'analisi predittiva e prescrittiva. A questo scopo, puoi utilizzare BigQuery ML, Vertex AI AutoML tabulare o i modelli preaddestrati di Google per l'analisi delle immagini, l'analisi dei video, il riconoscimento vocale, il linguaggio naturale e la traduzione. In alternativa, puoi pubblicare il modello addestrato personalizzato utilizzando Vertex AI per casi d'uso personalizzati in base alle esigenze della tua attività. Ciò potrebbe comportare quanto segue:

  • Consigliare un prodotto in base alle tendenze di mercato e al comportamento di acquisto degli utenti.
  • Previsione di un ritardo del volo.
  • Rilevamento di attività fraudolente.
  • Segnalazione di contenuti inappropriati.
  • Altre idee innovative che potrebbero distinguere la tua app dalla concorrenza.
Approccio: dai la priorità ai casi d'uso meno rischiosi

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

  • Qual è la criticità aziendale di questo caso d'uso?
  • 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 è la 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 le sensibilità ai tempi di inattività e alla latenza per l'accesso al set di dati sottostante?
  • Esistono proprietari di linee di business desiderosi e disposti a eseguire la migrazione del loro caso d'uso in anticipo?

L'esame di 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. Gli asset a basso rischio devono essere sottoposti a migrazione per primi, mentre quelli a rischio più elevato devono essere migrati in un secondo momento.

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 workload e procedere con la migrazione in iterazioni.

Un'iterazione può essere costituita da un singolo caso d'uso, da alcuni casi d'uso separati o da un numero di casi d'uso relativi a un singolo carico di lavoro. La scelta di una di queste opzioni per l'iterazione dipende dall'interconnettività dei casi d'uso, da eventuali dipendenze condivise e dalle risorse disponibili per svolgere il lavoro.

Una migrazione in genere prevede i seguenti passaggi:

Processo di migrazione in sette passaggi.

Questi passaggi sono descritti in modo più dettagliato 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 a 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 necessario per consentire l'esecuzione dei casi d'uso su Google Cloud. La configurazione può includere la configurazione di progetti, rete, virtual private cloud (VPC) e governance dei dati.Google Cloud Inoltre, è necessario sviluppare una buona comprensione della situazione attuale, ovvero di ciò che funziona e ciò che non funziona. In questo modo, puoi comprendere i requisiti per il tuo impegno di migrazione. Puoi utilizzare la funzionalità di valutazione della migrazione di BigQuery per facilitare questo passaggio.

La governance dei dati è un solido approccio alla gestione dei dati durante il loro ciclo di vita, dall'acquisizione all'utilizzo e allo smaltimento. Il tuo programma di governance dei dati delinea chiaramente norme, procedure, responsabilità e controlli relativi alle attività sui dati. Questo programma contribuisce a garantire che le informazioni vengano raccolte, gestite, utilizzate e diffuse in modo da soddisfare sia l'integrità dei dati sia le esigenze di sicurezza della tua organizzazione. Inoltre, aiuta i dipendenti a scoprire e utilizzare i dati al massimo del loro potenziale.

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

2. Eseguire la migrazione di schema e dati

Lo schema del data warehouse definisce la struttura dei dati e le relazioni tra le entità di dati. Lo schema è al centro della progettazione dei dati e influenza molti processi, sia upstream che downstream.

La documentazione relativa al trasferimento di schema e dati fornisce informazioni dettagliate su come spostare i dati in BigQuery e consigli per aggiornare lo schema in modo da sfruttare appieno le funzionalità di BigQuery.

3. Tradurre le query

Utilizza la traduzione SQL batch per migrare il codice SQL in blocco o la traduzione SQL interattiva per tradurre query ad hoc.

Alcuni data warehouse legacy includono estensioni dello standard SQL per abilitare la funzionalità per il loro prodotto. BigQuery non supporta queste estensioni proprietarie; al contrario, è conforme allo standard ANSI/ISO SQL:2011. Ciò significa che alcune query potrebbero comunque richiedere il refactoring manuale se i traduttori SQL non riescono a interpretarle.

4. Migrazione delle applicazioni aziendali

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

Per scoprire di più sulle opzioni di analisi quando lavori con BigQuery, consulta Panoramica dell'analisi di BigQuery. Questo argomento fornisce una panoramica degli strumenti di reporting e analisi che puoi utilizzare per ottenere approfondimenti interessanti dai tuoi dati.

La sezione sui cicli di feedback nella documentazione della pipeline di dati descrive come utilizzare una pipeline di dati per creare un ciclo di feedback per il provisioning dei sistemi upstream.

5. Eseguire la migrazione delle pipeline di dati

La documentazione relativa alle pipeline di dati presenta procedure, pattern e tecnologie per eseguire la migrazione delle pipeline di dati legacy a 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 più ampia del data warehouse.

6. Ottimizza le prestazioni

BigQuery elabora i dati in modo efficiente sia per i set di dati di piccole dimensioni sia per quelli nell'ordine dei petabyte. Con l'aiuto di BigQuery, i tuoi job di analisi dei dati dovrebbero funzionare bene senza modifiche nel data warehouse di cui è stata eseguita la migrazione. Se ritieni che in determinate circostanze il rendimento delle query non corrisponda alle tue aspettative, consulta Introduzione all'ottimizzazione del rendimento delle query per indicazioni.

7. Verifica e convalida

Al termine di ogni iterazione, verifica che la migrazione dello scenario d'uso sia andata a buon fine controllando che:

  • I dati e lo schema sono stati migrati completamente.
  • I problemi di governance dei dati sono stati completamente soddisfatti e testati.
  • Sono state stabilite procedure e automazione di manutenzione e monitoraggio.
  • Le query sono state tradotte correttamente.
  • Le pipeline di dati migrate funzionano come previsto.
  • Le applicazioni aziendali sono configurate correttamente per accedere ai dati e alle query migrati.

Puoi iniziare a utilizzare lo strumento di convalida dei dati, uno strumento CLI Python open source che confronta i dati degli ambienti di origine e di destinazione per assicurarsi che corrispondano. Supporta più tipi di connessione e funzionalità di convalida a più livelli.

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

Una volta convalidata l'iterazione, puoi rilasciare lo scenario d'uso migrato in produzione e dare 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 poterle applicare nella successiva e accelerare la migrazione.

Riepilogo dell'impegno per la 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 dati dai sistemi di origine, integrarsi con le applicazioni aziendali e fornire l'accesso utente richiesto. È importante sottolineare che il diagramma mostra anche che i dati vengono sincronizzati dal data warehouse a BigQuery. In questo modo, i casi d'uso possono essere scaricati per tutta la durata dell'impegno di migrazione.

Riepilogo del processo di migrazione.

Supponendo che tu voglia eseguire la migrazione completa dal data warehouse a BigQuery, lo stato finale della migrazione è il seguente:

Stato finale della migrazione, che mostra varie origini dati che alimentano BigQuery, che a sua volta è l'origine per l'analisi dei dati.

Passaggi successivi