Esegui la migrazione delle pipeline di dati

Questo documento descrive come eseguire la migrazione delle pipeline di dati upstream, che caricano i dati nel data warehouse. Puoi utilizzare questo documento per comprendere meglio cos'è una pipeline di dati, quali procedure e pattern può utilizzare una pipeline e quali opzioni e tecnologie di migrazione sono disponibili per una migrazione del data warehouse.

Che cos'è una pipeline di dati?

In ambito informatico, una pipeline di dati è un tipo di applicazione che elabora i dati tramite una sequenza di passaggi di elaborazione connessi. In linea generale, le pipeline di dati possono essere applicate, ad esempio, al trasferimento di dati tra sistemi informativi, all'estrazione, alla trasformazione e al caricamento (ETL), all'arricchimento dei dati e all'analisi dei dati in tempo reale. In genere, le pipeline di dati vengono gestite come processo batch che esegue ed elabora i dati quando vengono eseguiti o come processo flusso in esecuzione continua ed elabora i dati non appena diventano disponibili per la pipeline.

Nel contesto del data warehousing, le pipeline di dati vengono comunemente utilizzate per leggere i dati dei sistemi transazionali, applicare trasformazioni e quindi scrivere dati nel data warehouse. Ognuna delle trasformazioni è descritta da una funzione e l'input per una determinata funzione è l'output della funzione o delle funzioni precedenti. Queste funzioni connesse sono descritte come un grafico e questo grafico è spesso indicato come Grafico aciclico diretto (DAG), ovvero il grafico segue una direzione (dall'origine alla destinazione) ed è aciclico, l'input di qualsiasi funzione non può dipendere dall'output di un'altra funzione a valle nel DAG. In altre parole, i loop non sono consentiti. Ogni nodo del grafico è una funzione e ogni bordo rappresenta i dati che passano da una funzione all'altra. Le funzioni iniziali sono le sorgenti o le connessioni ai sistemi di dati di origine. Le funzioni finali sono i sink, ovvero le connessioni ai sistemi di dati di destinazione.

Nel contesto delle pipeline di dati, le origini sono solitamente sistemi transazionali, ad esempio un RDBMS, e il sink si connette a un data warehouse. Questo tipo di grafico è denominato DAG del flusso di dati. Puoi anche utilizzare i DAG per orchestrare lo spostamento dei dati tra pipeline di dati e altri sistemi. Questo utilizzo è definito orchestrazione o DAG del flusso di controllo.

Quando eseguire la migrazione delle pipeline di dati

Quando esegui la migrazione di un caso d'uso a BigQuery, puoi scegliere di trasferire il carico o eseguire la migrazione completa.

Da un lato, quando esegui l'offload di un caso d'uso, non è necessario eseguire preventivamente la migrazione delle pipeline di dati upstream. Prima esegui la migrazione dello schema dei casi d'uso e dei dati dal tuo data warehouse esistente a BigQuery. Quindi stabilirai una copia incrementale dal vecchio al nuovo data warehouse per mantenere i dati sincronizzati. Infine, esegui la migrazione e la convalida di processi downstream come script, query, dashboard e applicazioni aziendali.

A questo punto, le pipeline di dati upstream sono invariate e stanno ancora scrivendo dati nel data warehouse esistente. Puoi includere di nuovo i casi d'uso con carico offline nel backlog della migrazione affinché la migrazione completa venga eseguita in una successiva iterazione.

Quando invece esegui la migrazione completa di un caso d'uso, viene eseguita la migrazione a Google Cloud delle pipeline di dati upstream necessarie per quel caso d'uso. La migrazione completa richiede prima l'offload del caso d'uso. Dopo la migrazione completa, puoi deprecare le tabelle legacy corrispondenti dal datawarehouse on-premise perché i dati vengono importati direttamente in BigQuery.

Durante un'iterazione, puoi scegliere una delle seguenti opzioni:

  • Scarica solo il tuo caso d'uso.
  • Esegui la migrazione completa di un caso d'uso di cui è stato eseguito l'offload in precedenza.
  • Esegui la migrazione completa di un caso d'uso da zero scaricandolo prima nella stessa iterazione.

Una volta completata la migrazione di tutti i casi d'uso, puoi scegliere di disattivare il data warehouse precedente, un passaggio importante per ridurre le spese generali e i costi.

Come eseguire la migrazione delle pipeline di dati

La parte restante di questo documento illustra come eseguire la migrazione delle pipeline di dati, tra cui l'approccio e le procedure da utilizzare e le tecnologie da utilizzare. Le opzioni spaziano dal riutilizzo delle pipeline di dati esistenti (reindirizzandole al caricamento su BigQuery) alla riscrittura delle pipeline dei dati per sfruttare i servizi gestiti da Google Cloud.

Procedure e pattern per le pipeline di dati

Puoi utilizzare le pipeline di dati per eseguire una serie di procedure e pattern. Queste pipeline sono le più utilizzate nel data warehousing. Potresti avere pipeline di dati in batch o pipeline di dati in flusso. Le pipeline di dati in batch vengono eseguite sui dati raccolti in un determinato periodo di tempo (ad esempio, una volta al giorno). Le pipeline di dati in modalità flusso gestiscono gli eventi in tempo reale generati dai sistemi operativi, ad esempio le modifiche alle righe CDC generate dai database OLTP (Online Transaction Processing).

Estrazione, trasformazione e caricamento (ETL)

Nell'ambito del data warehousing, le pipeline di dati spesso eseguono una procedura ETL (estrazione, trasformazione e caricamento). Le tecnologie ETL vengono eseguite al di fuori del data warehouse, il che significa che le risorse del data warehouse possono essere utilizzate principalmente per query in parallelo, anziché per preparare e trasformare i dati. Uno svantaggio della trasformazione eseguita al di fuori del datawarehouse è che richiede l'apprendimento di strumenti e linguaggi aggiuntivi (diversi da SQL) per esprimere le trasformazioni.

Il seguente diagramma mostra una procedura ETL tipica.

Flusso che mostra l'origine (estrazione) che passa a una o più trasformazioni (trasformazione), poi a un sink e infine a un data warehouse (caricamento)

Figura 1. Una tipica procedura ETL.

Una tipica pipeline di dati ETL estrae i dati da uno o più sistemi di origine (preferibilmente il minor numero possibile per evitare errori causati da problemi come sistemi non disponibili). La pipeline esegue quindi una serie di trasformazioni, tra cui la pulizia dei dati, l'applicazione di regole aziendali, la verifica dell'integrità dei dati e la creazione di aggregati o disaggregati. Per ulteriori informazioni, consulta la sezione Ciclo ETL reale.

È comune avere più pipeline di dati. La prima pipeline è incentrata sulla copia dei dati dal sistema di origine al data warehouse. Le pipeline successive applicano la logica di business e trasformano i dati per l'utilizzo in vari data mart, che sono sottoinsiemi del data warehouse incentrati su una specifica business unit o focus aziendale.

Quando hai più pipeline di dati, devi orchestrarle. Il seguente diagramma mostra il possibile aspetto di questo processo di orchestrazione.

Orchestrator (DAG) che gestisce due processi ETL (DAG secondari)

Figura 2. Processo di orchestrazione per più pipeline di dati.

Nel diagramma, ogni pipeline di dati è considerata un DAG secondario del DAG di orchestrazione. Ogni DAG di orchestrazione comprende diverse pipeline di dati per allinearsi all'obiettivo più ampio, ad esempio la preparazione dei dati per una business unit in modo che gli analisti aziendali possano eseguire dashboard o report.

Estrazione, caricamento e trasformazione (ELT)

ELT è un'alternativa all'ETL. Con ELT, la pipeline di dati è suddivisa in due parti. Innanzitutto, una tecnologia ELT estrae i dati dal sistema di origine e li carica nel data warehouse. In secondo luogo, gli script SQL al di sopra del datawarehouse eseguono le trasformazioni. L'aspetto positivo di questo approccio è che puoi utilizzare SQL per esprimere le trasformazioni; lo svantaggio è che ciò potrebbe consumare risorse del data warehouse necessarie per le query in parallelo. Per questo motivo, i batch ELT vengono spesso eseguiti durante la notte (o al di fuori delle ore di punta) quando le risorse di sistema del data warehouse sono meno richieste.

Il seguente diagramma mostra una tipica procedura ELT.

Flusso che mostra l'origine (estrazione) che passa a una o più trasformazioni (trasformazione), poi a un sink e infine a un data warehouse (caricamento).

Figura 3. Una tipica procedura ELT.

Quando adotti un approccio ELT, è comune separare l'estrazione e il caricamento in un unico DAG e le trasformazioni nei rispettivi DAG. I dati vengono caricati una volta nel data warehouse e poi trasformati più volte per creare le diverse tabelle utilizzate a valle nei report e così via. A loro volta, questi DAG diventano DAG secondari in un DAG di orchestrazione più ampio (come mostrato nella sezione ETL).

Quando esegui la migrazione di pipeline di dati da un data warehouse on-premise congestionato al cloud, è importante ricordare che i sistemi di data warehouse su cloud, come BigQuery, sono tecnologie di elaborazione dati a elevata parallelismo. Infatti, nel caso di BigQuery, puoi acquistare più risorse per supportare sia una domanda crescente di ELT sia query in parallelo. Per ulteriori informazioni, consulta la pagina Introduzione all'ottimizzazione delle prestazioni delle query.

Estrai e carica (EL)

Puoi utilizzare la procedura di estensione e caricamento (EL) da sola o seguita da trasformazioni, nel qual caso diventa ELT. EL è menzionata separatamente perché sono disponibili diversi servizi automatizzati che eseguono questa attività, riducendo la necessità di creare una tua pipeline di dati di importazione. Per ulteriori dettagli, consulta BigQuery Data Transfer Service.

Change Data Capture (CDC)

Change Data Capture (CDC) è uno dei numerosi pattern di progettazione del software utilizzati per tenere traccia delle modifiche ai dati. È spesso utilizzato nel data warehousing perché il data warehouse viene utilizzato per raccogliere e monitorare i dati e le relative modifiche da vari sistemi di origine nel tempo.

Il seguente diagramma mostra un esempio di come funziona CDC con ELT.

Flusso ETL che mostra i singoli record con informazioni sulla versione assegnate al momento dell'estrazione e timestamp aggiunti al caricamento.

Figura 4. Come funziona CDC con ELT.

CDC funziona bene con ELT perché vuoi archiviare il record originale prima di apportare eventuali modifiche a valle.

Per completare la parte EL, puoi elaborare i log del database utilizzando un software CDC come Datastream o strumenti open source come Debezium e scrivendo i record in BigQuery utilizzando Dataflow. Poi puoi utilizzare una query SQL per determinare la versione più recente prima di applicare ulteriori trasformazioni. Ecco un esempio:

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY RECORD KEY
      ORDER BY EVENT TIMESTAMP DESC
    ) AS rank
  FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1

Quando esegui il refactoring o crei nuove pipeline di dati, valuta la possibilità di utilizzare il pattern CDC applicato come procedura ELT. Questo approccio garantisce una cronologia completa delle modifiche ai dati a monte e offre una buona separazione delle responsabilità, ad esempio:

  • I team del sistema di origine assicurano la disponibilità dei log e la pubblicazione degli eventi di dati.
  • Il team della piattaforma dati si assicura che le regole di confronto per l'importazione dei record originali includano i timestamp nel data warehouse.
  • I team di data engineering e analisti pianificano una serie di trasformazioni per completare i loro data mart.

Cicli di feedback con pipeline di dati operativi

Le pipeline di dati operativi sono pipeline di elaborazione dati che prendono i dati dal data warehouse, li trasformano, se necessario, e scrivono il risultato in sistemi operativi.

I sistemi operativi si riferiscono ai sistemi che elaborano le transazioni quotidiane dell'organizzazione, ad esempio database OLTP, sistemi di gestione dei rapporti con i clienti (CRM), sistemi di gestione del catalogo dei prodotti (PCM) e così via. Poiché questi sistemi agiscono spesso come origine di dati, le pipeline di dati operativi implementano un pattern di feedback loop.

Il pattern della pipeline dei dati operativi è mostrato nel diagramma seguente.

Pipeline ETL che alimenta la data warehouse ETL e quindi una pipeline operativa che alimenta il sistema di origine.

Figura 5. Pattern per una pipeline di dati operativi.

L'esempio seguente descrive una pipeline di dati operativi che scrive i prezzi dei prodotti in un sistema PCM. Un sistema PCM è il sistema ufficiale per le informazioni sui prodotti relative alle vendite, come colori, canali di vendita, prezzo e stagionalità. Ecco il flusso end-to-end dei dati:

  • I dati relativi ai prezzi sono disponibili da più origini. Questi dati possono includere il prezzo corrente del PCM per regione, i prezzi di un servizio di terze parti offerti dalla concorrenza, la previsione della domanda e l'affidabilità dei fornitori da sistemi interni e così via.
  • Una pipeline ETL estrae i dati dalle origini, li trasforma e scrive il risultato nel data warehouse. In questo caso, la trasformazione è un calcolo complesso che coinvolge tutte le origini con l'obiettivo di produrre un prezzo base ottimale per ogni prodotto nel PCM.
  • Infine, la pipeline operativa acquisisce i prezzi base dal datawarehouse, esegue trasformazioni leggere per adeguare i prezzi degli eventi stagionali e scrive i prezzi finali nel PCM.

Sistema PCM con ingresso nel sistema ETL.

Figura 6. Una pipeline di dati operativi che scrive i prezzi dei prodotti in un sistema PCM.

Una pipeline di dati operativa è un tipo di processo downstream, mentre le pipeline di dati che implementano l'ETL, l'ELT o il CDC sono processi upstream. Ciononostante, gli strumenti utilizzati per implementare entrambi possono sovrapporsi. Ad esempio, puoi utilizzare Dataflow per definire ed eseguire tutti i DAG di elaborazione dati, GoogleSQL per definire le trasformazioni eseguite all'interno di BigQuery e Cloud Composer orchestrare il flusso end-to-end dei dati.

Scelta di un approccio alla migrazione

Questa sezione descrive i diversi approcci che puoi adottare per eseguire la migrazione delle pipeline di dati.

Reindirizza le pipeline di dati per la scrittura in BigQuery

Nelle seguenti condizioni, puoi valutare se una tecnologia che utilizzi offre un sink BigQuery integrato (connettore di scrittura):

  • Il data warehouse legacy è alimentato da pipeline di dati che eseguono una procedura ETL.
  • La logica di trasformazione viene eseguita prima che i dati siano archiviati nel data warehouse.

Fornitori di software indipendenti (ISV) offrono tecnologie di elaborazione dati con connettori BigQuery, tra cui:

Se la tecnologia della pipeline di dati non supporta l'importazione dati in BigQuery, valuta l'utilizzo di una variante di questo approccio per scrivere temporaneamente i dati in file che vengono successivamente importati da BigQuery.

La pipeline di dati di cui è stato bloccato l'invio al sistema legacy e che invece invia a BigQuery.

Figura 7. Riscrittura, o riconfigurazione, dell'ultima funzione di una pipeline di dati per scrivere dati in BigQuery.

A livello generale, il lavoro prevede la riscrittura, o riconfigurazione, dell'ultima funzione della pipeline di dati per scrivere dati in BigQuery. Tuttavia, sono disponibili diverse opzioni che potrebbero richiedere modifiche aggiuntive o nuove operazioni, ad esempio:

Funzionale

  • Mappature dei dati: poiché lo schema della tabella del database di destinazione potrebbe cambiare, potresti dover riconfigurare queste mappature.
  • Convalida delle metriche: devi convalidare sia i report nuovi sia quelli storici, perché sia lo schema sia le query potrebbero cambiare.

Non funzionante

  • Potrebbe essere necessario configurare firewall per consentire il trasferimento di dati in uscita dall'ambiente on-premise a BigQuery.
  • Potrebbero essere necessarie modifiche alla rete per creare ulteriore larghezza di banda e consentire il trasferimento di dati in uscita.

Reindirizza le pipeline di dati utilizzando i file come veicolo intermedio

Se la tecnologia della pipeline di dati on-premise esistente non supporta le API di Google o se l'utilizzo delle API di Google è limitato, puoi utilizzare i file come mezzo intermedio per raggiungere BigQuery con i tuoi dati.

Questo approccio è simile a quello del reindirizzamento, ma invece di utilizzare un sink nativo in grado di scrivere in BigQuery, utilizzerai un sink in grado di scrivere in un file system on-premise. Quando i dati si trovano nel file system, puoi copiarli in Cloud Storage. Per ulteriori dettagli, consulta la panoramica delle opzioni di importazione per Cloud Storage e i criteri coinvolti nella scelta di un'opzione di importazione.

Il passaggio finale consiste nel caricare i dati da Cloud Storage in BigQuery seguendo le linee guida riportate in Caricamento in batch dei dati.

Il seguente diagramma mostra l'approccio descritto in questa sezione.

Pipeline ETL che alimenta un file system anziché un data warehouse legacy; il file system a sua volta invia i dati a Cloud Storage e da lì a BigQuery.

Figura 8. Reindirizzamento delle pipeline di dati utilizzando i file come veicolo intermedio.

Per quanto riguarda l'orchestrazione della pipeline ETL, devi eseguire due passaggi separati:

  1. Riutilizza l'orchestrazione della pipeline on-premise esistente per scrivere i dati trasformati nel file system. Estendi questa orchestrazione per copiare i file dal tuo file system on-premise in Cloud Storage oppure crea uno script aggiuntivo che viene eseguito regolarmente per eseguire il passaggio di copia.
  2. Quando i dati si trovano in Cloud Storage, utilizza un trasferimento su Cloud Storage per pianificare i caricamenti ricorrenti da Cloud Storage a BigQuery. Le alternative ai trasferimenti di Cloud Storage sono Trigger di Cloud Storage e Cloud Composer.

Nella Figura 8, osserva come è possibile anche per l'orchestrazione su Google Cloud utilizzare un modello di pull recuperando i file tramite un protocollo come SFTP.

Esegui la migrazione delle pipeline ELT esistenti a BigQuery

Le pipeline ELT sono composte da due parti: la parte che carica i dati nel data warehouse e la parte che li trasforma utilizzando SQL in modo che possano essere consumati a valle. Quando esegui la migrazione di pipeline ELT, ognuna di queste parti ha il proprio approccio alla migrazione.

Per la parte che carica i dati nel tuo data warehouse (la parte EL), puoi seguire le linee guida nella sezione pipeline di dati di reindirizzamento, senza i consigli sulle trasformazioni, che non fanno parte di una pipeline EL.

Se le tue origini dati sono supportate da BigQuery Data Transfer Service (DTS) direttamente o tramite integrazioni di terze parti, puoi utilizzare DTS per sostituire la tua pipeline EL. Una soluzione di Fivetran mostra in che modo i connettori Fivetran possono aiutarti durante la migrazione, estraendo automaticamente i dati dalle origini, normalizzandoli e pulindoli leggermente per poi indirizzandoli a BigQuery.

Migrazione delle pipeline di dati OSS esistenti a Dataproc

Quando esegui la migrazione della tua pipeline di dati su Google Cloud, potresti voler eseguire la migrazione di alcuni job legacy scritti con un framework software open source come Apache Hadoop, Apache Spark o Apache Flink.

Dataproc consente di eseguire il deployment di cluster Hadoop e Spark veloci, facili da usare e completamente gestiti in modo semplice ed economico. Dataproc si integra con il connettore BigQuery, una libreria Java che consente a Hadoop e Spark di scrivere dati direttamente in BigQuery utilizzando versioni astratte delle classi Apache Hadoop InputFormat e OutputFormat.

Dataproc semplifica la creazione e l'eliminazione di cluster in modo che invece di utilizzare un unico cluster monolitico, puoi utilizzarne molti altri. Questo approccio presenta diversi vantaggi:

  • Puoi utilizzare diverse configurazioni dei cluster per singoli job, eliminando il carico amministrativo della gestione degli strumenti per più job.
  • Puoi scalare i cluster per adattarli a singoli job o gruppi di job.
  • Paghi solo per le risorse quando sono utilizzate dai tuoi job.
  • Non è necessario gestire i cluster nel tempo, perché sono appena configurati ogni volta che li utilizzi.
  • Non è necessario mantenere un'infrastruttura separata per sviluppo, test e produzione. Puoi utilizzare le stesse definizioni per creare tutte le versioni diverse di un cluster che ti servono, quando ne hai bisogno.

Quando esegui la migrazione dei job, ti consigliamo di adottare un approccio incrementale. Eseguendo la migrazione in modo incrementale, puoi:

  • Isola i singoli job nella tua infrastruttura Hadoop esistente dalla complessità inerente a un ambiente maturo.
  • Esamina ogni job in modo isolato per valutarne le esigenze e determinare il percorso migliore per la migrazione.
  • Gestisci i problemi imprevisti che si presentano senza ritardare le attività dipendenti.
  • Crea una proof of concept per ogni processo complesso senza influire sull'ambiente di produzione.
  • Sposta i tuoi job al modello temporaneo consigliato in modo ponderato e deliberato.

Quando esegui la migrazione dei job Hadoop e Spark esistenti a Dataproc, puoi verificare che le dipendenze dei job siano coperte dalle versioni di Dataproc supportate. Se devi installare software personalizzato, ti consigliamo di creare una tua immagine Dataproc, utilizzando alcune delle azioni di inizializzazione disponibili (ad esempio per Apache Flink), scrivere la tua azione di inizializzazione o specificare i requisiti del pacchetto Python personalizzato.

Per iniziare, consulta le guide rapide di Dataproc e gli esempi di codice del connettore BigQuery. Consulta anche le guide sulla migrazione dei job Hadoop da on-premise a Dataproc e sulla migrazione dei job Apache Spark a Dataproc.

Rehosting di pipeline di dati di terze parti in modo che vengano eseguite su Google Cloud

Uno scenario comune durante la creazione di pipeline di dati on-premise consiste nell'utilizzare software di terze parti per gestire l'esecuzione della pipeline e l'allocazione delle risorse di computing.

Per spostare queste pipeline nel cloud, hai diverse alternative a seconda delle funzionalità del software che stai utilizzando e dei termini di licenza, assistenza e manutenzione.

Le seguenti sezioni presentano alcune di queste alternative.

A livello generale, hai a disposizione le seguenti alternative per l'esecuzione del tuo software di terze parti in Google Cloud, dalla meno complessa alla più complessa:

  • Il tuo fornitore di software ha collaborato con Google Cloud per offrire il proprio software in Google Cloud Marketplace.
  • Il tuo fornitore di software di terze parti può essere eseguito su Kubernetes.
  • Il software di terze parti viene eseguito su una o più macchine virtuali (VM).

Se il tuo software di terze parti fornisce una soluzione Cloud Marketplace, il lavoro da svolgere è il seguente:

Questa alternativa è la più semplice perché esegui l'onboarding delle pipeline di dati nel cloud utilizzando la piattaforma familiare fornita dal tuo fornitore. Potresti anche essere in grado di utilizzare gli strumenti proprietari del tuo fornitore per facilitare la migrazione tra il tuo ambiente originale e il tuo nuovo ambiente su Google Cloud.

Se il tuo fornitore non fornisce una soluzione Cloud Marketplace, ma il suo prodotto può essere eseguito su Kubernetes, puoi utilizzare Google Kubernetes Engine (GKE) per ospitare le tue pipeline. Sono previste le seguenti attività:

  • Crea un cluster GKE seguendo i consigli del tuo fornitore per assicurarti che il prodotto di terze parti possa sfruttare la parallelizzazione delle attività offerta da Kubernetes.
  • Installa il software di terze parti sul tuo cluster GKE seguendo i consigli del fornitore.
  • Seleziona ed esegui la migrazione dei tuoi casi d'uso seguendo l'approccio iterativo spiegato in Migrazione dei data warehouse in BigQuery: panoramica.

Questa alternativa fornisce una via di mezzo in termini di complessità. Sfrutta il supporto nativo del fornitore per Kubernetes al fine di scalare e parallelizzare l'esecuzione delle tue pipeline. Tuttavia, richiede la creazione e la gestione di un cluster GKE.

Se il tuo fornitore non supporta Kubernetes, devi installare il software su un pool di VM per abilitare lo scale out e il caricamento in contemporanea del lavoro. Se il software del tuo fornitore supporta in modo nativo la distribuzione del lavoro su più VM, utilizza le funzionalità fornite, possibilmente raggruppando le istanze VM in un gruppo di istanze gestite (MIG) per lo scale in e lo scale out secondo le esigenze.

Gestire il caricamento in contemporanea del lavoro non è banale. Se il tuo fornitore non fornisce funzionalità per la distribuzione di attività a VM diverse, ti consigliamo di utilizzare un pattern di gestione delle attività per distribuire il lavoro alle VM in un gruppo di istanze gestite. Il seguente diagramma illustra questo approccio.

più input vanno a Pub/Sub, che crea gli argomenti. Gli argomenti vengono letti da diversi gruppi di istanze gestite.

Figura 9. Un gruppo di istanze gestite con tre VM.

In questo diagramma, ogni VM nel gruppo di istanze gestite esegue il software della pipeline di terze parti. Puoi attivare l'esecuzione di una pipeline in diversi modi:

In sostanza, tutti questi metodi inviano un messaggio a un argomento Pub/Sub predefinito. Creerai un agente semplice da installare su ogni VM. L'agente è in ascolto di uno o più argomenti Pub/Sub. Ogni volta che arriva un messaggio nell'argomento, l'agente esegue il pull del messaggio dall'argomento, avvia una pipeline nel software di terze parti e ne monitora il completamento. Al termine della pipeline, l'agente recupera il messaggio successivo dagli argomenti in ascolto.

In tutti gli scenari, consigliamo di collaborare con il fornitore per rispettare i termini di licenza appropriati affinché le tue pipeline funzionino su Google Cloud.

Riscrivi le pipeline di dati per utilizzare i servizi gestiti da Google Cloud

In alcuni casi, potresti scegliere di riscrivere alcune delle tue pipeline di dati esistenti per utilizzare nuovi framework e servizi completamente gestiti su Google Cloud. Questa opzione è adatta se le tue pipeline esistenti sono state originariamente implementate con tecnologie ora deprecate o se prevedi che il porting e il mantenimento di pipeline non modificate nel cloud sarebbero troppo pratici o proibitivi in termini di costi.

Le seguenti sezioni presentano i servizi Google Cloud completamente gestiti che consentono di eseguire trasformazioni avanzate di dati su larga scala: Cloud Data Fusion e Dataflow.

Cloud Data Fusion

Cloud Data Fusion, basato sul progetto open source CDAP, è un servizio di integrazione dei dati completamente gestito per la creazione e la gestione di pipeline di dati attraverso un'interfaccia grafica.

Puoi sviluppare le pipeline di dati nell'interfaccia utente di Cloud Data Fusion connettendo le origini a trasformazioni, sink e altri nodi per formare un DAG. Quando esegui il deployment della pipeline di dati, il pianificatore di Cloud Data Fusion trasforma questo DAG in una serie di calcoli paralleli che verranno eseguiti come job Apache Spark su Dataproc.

Quando utilizzi Cloud Data Fusion, puoi connetterti al database di un sistema di origine utilizzando i driver JDBC (Java Database Connectivity) per leggere i dati, trasformarli e caricarli in una destinazione di tua scelta (ad esempio, BigQuery), senza dover scrivere codice. Per farlo, devi caricare un driver JDBC nella tua istanza di Cloud Data Fusion e configurarlo in modo da poterlo utilizzare nelle tue pipeline di dati. Per maggiori dettagli, consulta la guida sull'utilizzo dei driver JDBC con Cloud Data Fusion.

Cloud Data Fusion espone plug-in per origini, trasformazioni, aggregazioni, sink, raccoglitori di errori, publisher di avvisi, azioni e azioni post-esecuzione come componenti personalizzabili. I plug-in predefiniti consentono di accedere a una vasta gamma di origini dati. Se non esiste un plug-in, puoi crearne uno personalizzato utilizzando le API per i plug-in di Cloud Data Fusion. Per ulteriori informazioni, consulta la Panoramica dei plug-in.

Con le pipeline di Cloud Data Fusion, puoi creare pipeline di dati sia in batch che in flussi. Fornendo l'accesso a log e metriche, le pipeline di dati permettono agli amministratori di rendere operativi i flussi di lavoro di elaborazione dati senza dover ricorrere a strumenti personalizzati.

Per iniziare, consulta la panoramica concettuale di Cloud Data Fusion. Per esempi pratici, consulta la guida rapida e il tutorial sulla creazione di una pipeline di campagne di targeting.

Dataflow

Dataflow è un servizio completamente gestito per l'esecuzione di job Apache Beam su larga scala. Apache Beam è un framework open source che fornisce un ricco set di primitive per windowing e analisi delle sessioni, nonché un ecosistema di connettori di origine e sink, tra cui un connettore per BigQuery. Apache Beam ti consente di trasformare e arricchire i dati in modalità flusso (in tempo reale) e batch (storica) con lo stesso livello di affidabilità ed espressività.

L'approccio serverless di Dataflow elimina l'overhead operativo grazie alla gestione automatica di prestazioni, scalabilità, disponibilità, sicurezza e conformità. In questo modo puoi concentrarti sulla programmazione anziché sulla gestione dei cluster di server.

Puoi inviare job Dataflow in diversi modi tramite l'interfaccia a riga di comando, l'SDK Java o l'SDK Python. Inoltre, stiamo sviluppando un framework per la portabilità per offrire la piena interoperabilità tra tutti gli SDK e i runner.

Se vuoi eseguire la migrazione di query e pipeline di dati da altri framework ad Apache Beam e Dataflow, leggi informazioni sul modello di programmazione di Apache Beam e consulta la documentazione ufficiale di Dataflow.

Per esempi pratici, consulta le guide rapide e i tutorial di Dataflow.

Orchestrazione e pianificazione

A livello generale, l'orchestrazione è il coordinamento automatico di diversi sistemi, mentre la pianificazione si riferisce all'attivazione automatica del lavoro di orchestrazione.

  • Aumento: una pipeline di dati è di per sé un'orchestrazione delle trasformazioni dei dati descritte da un DAG, ovvero un DAG di elaborazione dei dati.
  • Zoom indietro: quando una pipeline di dati dipende dall'output di altre pipeline di dati, devi eseguire l'orchestrazione di più pipeline. Ogni pipeline costituisce un DAG secondario in un DAG più grande, ovvero un DAG di orchestrazione.

Questa configurazione è tipica nel data warehousing. La Figura 1 nella sezione ETL mostra una configurazione di esempio. Le seguenti sezioni sono incentrate sull'orchestrazione di diverse pipeline di dati.

Dipendenze

Le dipendenze possono essere fan-in, in cui più pipeline di dati vengono unite in un vertice di un DAG di orchestrazione; il fan-out, in cui una singola pipeline di dati attiva altre pipeline o spesso entrambe, come mostrato nel diagramma seguente.

Più pipeline etichettate A, B e C con ventola nella pipeline D. La pipeline D si sviluppa verso le pipeline E, F e G. Tutto questo è orchestrato da un DAG di orchestrazione.

Figura 10. Dipendenze di fan-in e fan-out utilizzate in combinazione.

In ambienti non ottimali, alcune dipendenze sono dovute a limitazioni nella quantità di risorse disponibili. Ad esempio, una pipeline di dati viene eseguita e produce alcuni dati comuni come sottoprodotto. Altre pipeline di dati dipendono da questi dati comuni semplicemente per evitare di ricalcolarli, ma non sono correlate alla pipeline dei dati che ha creato i dati. Se questa prima pipeline riscontra problemi funzionali o non funzionanti, gli errori si propagano a cascata nelle pipeline di dati dipendenti, nel migliore dei casi forzando l'attesa, o nel peggiore dei casi, impedendone l'esecuzione, come mostrato nel diagramma seguente.

Si è verificato un errore nella pipeline A. Le pipeline B e C dipendono dall'output della pipeline A, quindi non riescono.

Figura 11. Gli errori a cascata di una pipeline di dati impediscono l'esecuzione delle pipeline dipendenti.

In Google Cloud, è disponibile una vasta gamma di risorse di calcolo e strumenti specializzati per consentirti di ottimizzare l'esecuzione delle tue pipeline e la loro orchestrazione. Le sezioni rimanenti trattano di questi strumenti e risorse.

Lavoro di migrazione coinvolto

È una best practice per semplificare le tue esigenze di orchestrazione. L'orchestrazione aumenta in complessità con il numero di dipendenze tra le pipeline dei dati. La migrazione a Google Cloud offre l'opportunità di esaminare i DAG di orchestrazione, identificare le dipendenze e determinare come ottimizzarle.

Ti consigliamo di ottimizzare le dipendenze in modo incrementale, come indicato di seguito:

  1. In una prima iterazione, sposta l'orchestrazione su Google Cloud così com'è.
  2. Nelle iterazioni successive, analizza le dipendenze e pubblicale in contemporanea, se possibile.
  3. Infine, riorganizza l'orchestrazione estraendo le attività comuni nei rispettivi DAG.

La prossima sezione spiega questo metodo con un esempio pratico.

Esempio pratico

Supponiamo che un'organizzazione abbia due pipeline correlate:

  • La prima pipeline calcola i profitti e le perdite (P&L) per l'intera organizzazione. È una pipeline complessa che prevede molte trasformazioni. Parte della pipeline è costituita dal calcolo delle vendite mensili, che vengono utilizzate nelle fasi di trasformazione successive e alla fine scritte in una tabella.
  • La seconda pipeline calcola la crescita delle vendite su base annua e mensile per i diversi prodotti, in modo che il reparto marketing possa ottimizzare la gestione delle campagne pubblicitarie. Questa pipeline richiede i dati delle vendite mensili precedentemente calcolati dalla pipeline dei dati P&L.

L'organizzazione ritiene che la pipeline dei dati P&L abbia una priorità maggiore rispetto alla pipeline di marketing. Sfortunatamente, poiché si tratta di una pipeline di dati complessa, consuma una grande quantità di risorse, impedendo l'esecuzione contemporanea di altre pipeline. Inoltre, in caso di errore della pipeline di marketing e di altre pipeline dipendenti, non dispongono dei dati richiesti per l'esecuzione e devono attendere un nuovo tentativo di pagamento. Il seguente diagramma illustra questa situazione.

La pipeline di risparmio crea un artefatto "vendite mensili" necessario per la pipeline di marketing. La pipeline P&L può riscontrare ritardi e altri problemi.

Figura 12. Le pipeline di dati complesse possono impedire l'esecuzione di pipeline a priorità inferiore.

L'organizzazione sta eseguendo la migrazione a BigQuery. Ha identificato i due casi d'uso (P&L e crescita delle vendite marketing) e li ha inclusi nel backlog della migrazione. Durante la pianificazione dell'iterazione successiva, l'organizzazione assegna una priorità al caso d'uso di P&L e lo include nel backlog di iterazione perché è gravemente limitata dalle attuali risorse on-premise e causa regolarmente ritardi. Sono inclusi anche alcuni dei casi d'uso dipendenti, inclusi il caso d'uso di marketing.

Il team di migrazione esegue la prima iterazione. Sceglie di trasferire i casi d'uso di P&L e marketing su Google Cloud utilizzando un approccio di reindirizzamento. Non apportano modifiche ai passaggi o all'orchestrazione della pipeline. Una differenza importante è che ora la pipeline P&L può distruggere una potenza di calcolo quasi illimitata, e quindi viene eseguita molto più velocemente rispetto a quella on-premise. La pipeline scrive i dati sulle vendite mensili in una tabella BigQuery utilizzata dalla pipeline di crescita del marketing. Il seguente diagramma illustra queste modifiche.

La pipeline P&L è la stessa di prima, ma non presenta ritardi.

Figura 13. Accelerare una pipeline di dati complessa utilizzando un approccio di reindirizzamento.

Sebbene Google Cloud abbia contribuito a risolvere i problemi economici e non funzionali, i problemi funzionali persistono ancora. Alcune attività non correlate che precedono il calcolo delle vendite mensili spesso causano errori che impediscono questo calcolo e comportano l'impossibilità di avviare le pipeline dipendenti.

In una seconda iterazione, il team spera di migliorare le prestazioni includendo entrambi i casi d'uso nell'arretrato di iterazione. Il team identifica i passaggi della pipeline per calcolare le vendite mensili nella pipeline P&L. I passaggi costituiscono un DAG secondario, come mostrato nel diagramma successivo. Il team di migrazione copia il DAG secondario nella pipeline di marketing, in modo che la pipeline possa essere eseguita indipendentemente dal costo e dall'attività. Una potenza di calcolo sufficiente in Google Cloud consente a entrambe le pipeline di essere eseguite contemporaneamente.

La pipeline di P&L e la pipeline di marketing ora vengono eseguite come DAG secondari separati, quindi la pipeline di marketing non è più interessata in caso di problemi.

Figura 14. Pipeline in esecuzione contemporaneamente tramite un DAG secondario.

Lo svantaggio è che la duplicazione della logica dei DAG secondari crea un overhead per la gestione del codice, perché ora il team deve mantenere sincronizzate entrambe le copie della logica dei DAG secondari.

In una terza iterazione, il team riesamina i casi d'uso ed estrae il DAG secondario delle vendite mensili in una pipeline indipendente. Al termine della nuova pipeline mensile di vendita, si attiva o si estende al P&L, alla crescita del marketing e ad altre pipeline dipendenti. Questa configurazione crea un nuovo DAG di orchestrazione complessiva, in cui ciascuna delle pipeline fa parte dei relativi DAG secondari.

La pipeline di vendita mensile è la prima e alimenta la pipeline di P&L e di marketing.

Figura 15. DAG di orchestrazione complessiva con ogni pipeline nel proprio DAG secondario.

Nelle iterazioni successive, il team di migrazione può risolvere eventuali problemi funzionali rimanenti ed eseguire la migrazione delle pipeline per utilizzare i seguenti servizi gestiti da Google Cloud, tra gli altri:

Anche se Airflow supporta i DAG secondari in modo nativo, questa funzionalità potrebbe limitarne le prestazioni ed è quindi sconsigliata. Al loro posto, utilizza DAG indipendenti con l'operatore TriggerDagRunOperator.

Passaggi successivi

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

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