Esegui la migrazione delle pipeline di dati

Questo documento descrive come eseguire la migrazione delle pipeline di dati upstream, che caricano dati nel data warehouse. Puoi utilizzare questo documento per comprendere meglio che 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 di data warehouse.

Che cos'è una pipeline di dati?

Nel settore dell'informatica, una pipeline di dati è un tipo di applicazione che elabora i dati tramite una sequenza di fasi di elaborazione collegate. In linea di massima, 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 un processo batch che esegue ed elabora i dati quando vengono eseguiti o come un processo di 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 di una determinata funzione è l'output della funzione o delle funzioni precedenti. Queste funzioni collegate sono descritte come un grafico e questo grafico è spesso indicato come Grafico diretto aciclico (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 di solito 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 è indicato come 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 eseguire l'offload o di eseguire la migrazione completa.

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

A questo punto, le pipeline di dati a monte non sono state modificate e stanno ancora scrivendo dati nel data warehouse esistente. Puoi includere di nuovo i casi d'uso offline nel backlog della migrazione in modo che ne venga eseguita la migrazione completa in un'iterazione successiva.

Quando invece esegui la migrazione completa di un caso d'uso, viene eseguita la migrazione a Google Cloud delle pipeline di dati a monte richieste per il caso d'uso. La migrazione completa richiede prima di scaricare il caso d'uso. Al termine della migrazione, puoi ritirare le tabelle legacy corrispondenti dal data warehouse on-premise poiché 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 era stato precedentemente eseguito l'offload.
  • Esegui la migrazione completa di un caso d'uso da zero trasferendolo prima nella stessa iterazione.

Una volta completata la migrazione di tutti i casi d'uso, puoi scegliere di disattivare il vecchio warehouse, un passaggio importante per ridurre l'overhead 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, compresi l'approccio e le procedure da utilizzare e le tecnologie da utilizzare. Le opzioni spaziano dal riutilizzo delle pipeline di dati esistenti (reinserendo il loro caricamento su BigQuery) alla riscrittura delle pipeline di 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 quelle 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 su dati raccolti in un 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 Online Transaction Processing (OLTP).

Estrazione, trasformazione e caricamento (ETL)

Nel contesto 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, invece che per la preparazione e la trasformazione dei dati. Uno svantaggio della trasformazione eseguita al di fuori del data warehouse è che richiede l'apprendimento di strumenti e linguaggi aggiuntivi (diversi dall'SQL) per esprimere le trasformazioni.

Il seguente diagramma mostra una tipica procedura ETL.

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 meno possibile per evitare errori causati da problemi come i sistemi non disponibili). La pipeline esegue quindi una serie di trasformazioni, tra cui la pulizia dei dati, l'applicazione di regole aziendali, il controllo dell'integrità dei dati e la creazione di aggregati o disaggregati. Per ulteriori informazioni, consulta 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 obiettivo aziendale.

Quando disponi di più pipeline di dati, devi orchestrarle. Il seguente diagramma mostra l'aspetto di questo processo di orchestrazione.

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

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 a un obiettivo più ampio, ad esempio preparare i 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. In primo luogo, una tecnologia ELT estrae i dati dal sistema di origine e li carica nel data warehouse. Secondariamente, gli script SQL oltre al data warehouse eseguono le trasformazioni. L'aspetto positivo di questo approccio è che puoi utilizzare SQL per esprimere le trasformazioni; lo svantaggio è che questo potrebbe consumare risorse del data warehouse necessarie per le query in parallelo. Per questo motivo, i batch ELT spesso vengono 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 DAG e le trasformazioni nei rispettivi DAG. I dati vengono caricati una sola volta nel data warehouse e poi trasformati più volte per creare le diverse tabelle utilizzate a valle del reporting e così via. Questi DAG a loro volta diventano sotto-DAG 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 parallelismo massivo. Infatti, nel caso di BigQuery, puoi acquistare più risorse per supportare sia le crescenti richieste di ELT sia l'esecuzione di query in parallelo. Per ulteriori informazioni, consulta l'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 viene menzionato separatamente perché sono disponibili diversi servizi automatizzati che eseguono questa attività, riducendo la necessità di creare una propria 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é 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 usare 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 la creazione di nuove pipeline di dati, valuta l'utilizzo del pattern CDC applicato come procedura ELT. Questo approccio garantisce una cronologia completa delle modifiche dei dati a monte e fornisce 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 che si occupa della piattaforma dati si assicura che le regole di confronto delle importazioni dei record originali includano i timestamp nel data warehouse.
  • I team di data engineering e analisti programmano una serie di trasformazioni per popolare i data mart.

Loop 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 nei sistemi operativi.

I sistemi operativi fanno riferimento 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 fonte di dati, le pipeline di dati operativi implementano un pattern di loop di feedback.

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

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

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 di dati:

  • I dati relativi ai prezzi sono disponibili da più origini. Questi dati possono includere il prezzo corrente del PCM per regione, i prezzi della concorrenza di un servizio di terze parti, 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 preleva i prezzi base dal data warehouse, esegue trasformazioni leggere per adeguare i prezzi degli eventi stagionali e reinserisce i prezzi finali nel PCM.

Inserimento del sistema PCM nel sistema ETL.

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

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

Scegliere 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 condizioni seguenti, potresti 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 la possibilità di utilizzare una variante di questo approccio, che scrive temporaneamente i dati in file che vengono successivamente importati da BigQuery.

La pipeline di dati bloccata non fornisce l'accesso al sistema legacy e, invece, invia dati 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 prevedeva la riscrittura o la riconfigurazione dell'ultima funzione della pipeline di dati per scrivere dati in BigQuery. Tuttavia, hai a disposizione una serie di opzioni che potrebbero richiedere ulteriori modifiche o nuove modifiche, 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 il report storico sia quello nuovo, poiché sia lo schema sia le query potrebbero cambiare.

Non funzionale

  • Potrebbe essere necessario configurare firewall per consentire il trasferimento di dati in uscita da on-premise a BigQuery.
  • Potrebbero essere necessarie modifiche alla rete per creare una larghezza di banda aggiuntiva e supportare il trasferimento di dati in uscita.

Reindirizza le pipeline di dati utilizzando i file come veicolo intermedio

Se la tecnologia delle 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 consentire ai tuoi dati di raggiungere BigQuery.

Questo approccio è simile al reindirizzamento, ma invece di utilizzare un sink nativo in grado di scrivere in BigQuery, ne utilizzerai un sink in grado di scrivere in un file system on-premise. Quando i dati si trovano nel file system, puoi copiarli su Cloud Storage. Per maggiori dettagli, consulta la panoramica delle opzioni di importazione per Cloud Storage e i criteri associati alla 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 in un file system invece che nel data warehouse legacy; il file system a sua volta alimenta Cloud Storage e da lì a BigQuery.

Figura 8. Reindirizzare le 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 delle 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 sono in Cloud Storage, utilizza un trasferimento da Cloud Storage per pianificare i caricamenti ricorrenti da Cloud Storage a BigQuery. Le alternative ai trasferimenti di Cloud Storage sono i trigger di Cloud Storage e Cloud Composer.

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

Esegui la migrazione a BigQuery delle pipeline ELT esistenti

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, ciascuna di queste parti adotta un 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 Reindirizzamento delle pipeline di dati, meno 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 pipeline EL.

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 utilizzare 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 InputFormat e OutputFormat Apache Hadoop.

Dataproc semplifica la creazione e l'eliminazione dei cluster in modo che, anziché utilizzare un unico cluster monolitico, ne puoi utilizzare molti. Questo approccio presenta diversi vantaggi:

  • Puoi utilizzare configurazioni di cluster diverse per i 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 i tuoi job le utilizzano.
  • Non è necessario gestire i cluster nel tempo perché vengono configurati di recente ogni volta che li utilizzi.
  • Non è necessario mantenere un'infrastruttura separata per sviluppo, test e produzione. Puoi usare le stesse definizioni per creare tutte le versioni di un cluster che ti servono, quando ne hai bisogno.

Quando esegui la migrazione dei job, ti consigliamo di adottare un approccio incrementale. Eseguendo una migrazione incrementale, puoi fare quanto segue:

  • Isola i singoli job nella tua infrastruttura Hadoop esistente dalla complessità intrinseca di 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 non appena si presentano senza ritardare le attività dipendenti.
  • Crea un proof of concept per ogni processo complesso senza influire sull'ambiente di produzione.
  • Sposta i 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 un'azione di inizializzazione personalizzata o specificare requisiti per i pacchetti Python personalizzati.

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 per l'esecuzione su Google Cloud

Uno scenario comune durante la creazione di pipeline di dati on-premise consiste nell'utilizzo di 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 di 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 suo software in Google Cloud Marketplace.
  • Il tuo fornitore di software di terze parti può eseguire 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 necessario è 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 è in grado di essere eseguito su Kubernetes, puoi utilizzare Google Kubernetes Engine (GKE) per ospitare le tue pipeline. Sono coinvolti i seguenti lavori:

  • Crea un cluster GKE seguendo i suggerimenti del tuo fornitore per assicurarti che il prodotto di terze parti possa sfruttare il caricamento in contemporanea delle attività offerto da Kubernetes.
  • Installa il software di terze parti sul tuo cluster GKE seguendo i suggerimenti 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, magari raggruppando le istanze VM in un gruppo di istanze gestite per lo scale in e lo scale out in base alle 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 semplice agente da installare in ogni VM. L'agente ascolta uno o più argomenti Pub/Sub. Ogni volta che un messaggio arriva nell'argomento, l'agente estrae il messaggio dall'argomento, avvia una pipeline nel software di terze parti e ne ascolta il completamento. Al completamento della pipeline, l'agente recupera il messaggio successivo dagli argomenti che sta ascoltando.

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

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

In alcuni casi, potresti decidere di riscrivere alcune pipeline di dati esistenti per utilizzare nuovi framework e servizi completamente gestiti su Google Cloud. Questa opzione funziona bene se le tue pipeline esistenti sono state originariamente implementate con tecnologie ora deprecate o se prevedi che il porting e il mantenimento di queste 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 ti consentono di eseguire trasformazioni avanzate dei dati su larga scala: Cloud Data Fusion e Dataflow.

Cloud Data Fusion

Cloud Data Fusion, basato sul progetto CDAP open source, è un servizio di integrazione dei dati completamente gestito per la creazione e la gestione di pipeline di dati tramite 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 planner 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 Java Database Connectivity (JDBC) per leggere i dati, trasformarli e caricarli in una destinazione di tua scelta (ad esempio, BigQuery), senza dover scrivere codice. A questo scopo, devi caricare un driver JDBC nell'istanza di Cloud Data Fusion e configurarlo in modo da poterlo utilizzare nelle tue pipeline di dati. Per ulteriori 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 crearlo utilizzando le API 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 in modalità flusso e batch. Fornendo accesso a log e metriche, le pipeline di dati consentono agli amministratori di rendere operativi i flussi di lavoro di elaborazione dati senza utilizzare 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 per una campagna con targeting.

Dataflow

Dataflow è un servizio completamente gestito per l'esecuzione di job Apache Beam su larga scala. Apache Beam è un framework open source che offre 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 consente di trasformare e arricchire i dati sia in modalità flusso (in tempo reale) che batch (storico) con gli stessi livelli 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 i job Dataflow in diversi modi tramite l'interfaccia a riga di comando, l'SDK Java o l'SDK Python. Inoltre, stiamo sviluppando un framework di portabilità per offrire la completa interoperabilità tra tutti gli SDK e i runner.

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

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

Orchestrazione e pianificazione

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

  • Aumento dello zoom: una pipeline di dati è di per sé un'orchestrazione di trasformazioni dei dati descritte da un DAG, ovvero un DAG di elaborazione dati.
  • Zoom indietro: quando una pipeline di dati dipende dall'output di altre pipeline di dati, è necessaria l'orchestrazione di più pipeline. Ogni pipeline costituisce un DAG secondario in un DAG più grande, che è 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 più pipeline di dati o spesso entrambe, come mostrato nel diagramma seguente.

Più pipeline etichettate A, B e C con ventola nella pipeline D. Le pipeline D si sviluppano sulle pipeline E, F e G. Tutto questo è orchestrato da un DAG di orchestrazione.

Figura 10. Dipendenze 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 esegue 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 in questa prima pipeline si verificano problemi funzionali o non funzionanti, gli errori si estendono alle pipeline di dati dipendenti, nella migliore delle ipotesi, costringendoli ad attendere 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 hanno esito negativo.

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

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

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 di 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 così com'è su Google Cloud.
  2. Nelle iterazioni successive, analizza le dipendenze e, se possibile, caricale in contemporanea.
  3. Infine, riorganizza l'orchestrazione estraendo le attività comuni nei rispettivi DAG.

La prossima sezione spiega questo metodo con un esempio pratico.

Un esempio pratico

Supponiamo che un'organizzazione abbia due pipeline correlate:

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

L'organizzazione ritiene che la pipeline di dati P&L abbia una priorità maggiore rispetto alla pipeline di marketing. Sfortunatamente, poiché è una pipeline di dati complessa, consuma una grande quantità di risorse, impedendo l'esecuzione contemporaneamente di altre pipeline. Inoltre, se la pipeline di P&L ha esito negativo, la pipeline di marketing e le altre pipeline dipendenti non dispongono dei dati richiesti per poter essere eseguite e devono attendere un nuovo tentativo di P&L. Il seguente diagramma illustra questa situazione.

La pipeline P&L crea un artefatto relativo alle vendite mensili necessario per la pipeline di marketing. La pipeline P&L può presentare 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 (ricavato economico e commerciale) 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 limitato dalle attuali risorse on-premise e causa regolarmente ritardi. Sono inclusi anche alcuni casi d'uso dipendenti, tra cui il caso d'uso del marketing.

Il team di migrazione esegue la prima iterazione. Sceglie di trasferire i casi d'uso di P&L e marketing a 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, di conseguenza, viene eseguita molto più velocemente che on-premise. La pipeline scrive i dati sulle vendite mensili in una tabella BigQuery utilizzata dalla pipeline di crescita del marketing. Il diagramma seguente 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 non funzionanti di P&L, i problemi funzionali persistono. Alcune attività non correlate che precedono il calcolo delle vendite mensili spesso causano errori che ne impediscono l'esecuzione 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 nel backlog dell'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 possa essere eseguita in modo indipendente. Una potenza di calcolo sufficiente in Google Cloud consente l'esecuzione contemporanea di entrambe le pipeline.

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 utilizzando un DAG secondario.

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

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

La pipeline di vendita mensile è ora la prima, alimentando la pipeline P&L e la pipeline 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 limitare le sue prestazioni ed è quindi scoraggiata. Al loro posto, utilizza DAG indipendenti con l'operatore TriggerDagRunOperator.

Passaggi successivi

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

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