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 capire meglio cos'è una pipeline di dati, quali procedure e pattern può utilizzare una pipeline e quali opzioni e tecnologie sono disponibili per una migrazione del data warehouse.

Che cos'è una pipeline di dati?

Nel computing, una pipeline di dati è un tipo di applicazione che elabora i dati attraverso una sequenza di passaggi di elaborazione collegati. 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 oppure 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 solitamente utilizzate per leggere i dati da 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, spesso indicato come Directed Acyclic Graph (DAG), ovvero il grafo segue una direzione (dall'origine alla destinazione) ed è aciclico: l'input per qualsiasi funzione non può dipendere dall'output di un'altra funzione a valle nel DAG. In altre parole, i loop non sono consentiti. Ciascun nodo del grafico è una funzione e ogni bordo rappresenta i dati che passano da una funzione all'altra. Le funzioni iniziali sono sorgenti o connessioni ai sistemi di dati di origine. Le funzioni finali sono sink, o 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 è definito DAG del flusso di dati. Puoi usare i DAG anche per orchestrare lo spostamento dei dati tra pipeline di dati e altri sistemi. Questo utilizzo è indicato come orchestrazione o DAG di 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 offload o migrazione completa.

Da un lato, quando riduci il carico di un caso d'uso, non devi eseguire in anticipo la migrazione delle pipeline di dati a monte. Devi prima eseguire la migrazione dello schema e dei dati del caso d'uso dal 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 dei processi downstream come script, query, dashboard e applicazioni aziendali.

A questo punto, le pipeline di dati upstream non hanno subito modifiche e continuano a scrivere dati nel data warehouse esistente. Puoi includere nuovamente i casi d'uso scaricati nel backlog di migrazione in modo da eseguirne la migrazione completa in una successiva iterazione.

Quando esegui la migrazione completa di un caso d'uso, invece, le pipeline di dati upstream richieste per il caso d'uso vengono migrate in Google Cloud. 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, perché i dati vengono importati direttamente in BigQuery.

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

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

Dopo aver completato la migrazione di tutti i casi d'uso, puoi scegliere di disattivare il warehouse precedente, un passaggio importante per ridurre i costi generali e i costi.

Come eseguire la migrazione delle pipeline di dati

Il resto 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 (reindirizzandole per caricarle in BigQuery) alla riscrittura di 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 le più utilizzate nel data warehousing. Potresti avere pipeline di dati di dati in batch o pipeline di dati in flussi. 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 di elaborazione delle transazioni online (OLTP).

Estrai, trasforma e carica (ETL)

Nel contesto del data warehousing, le pipeline di dati spesso eseguono una procedura (ETL) di 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 eseguire query in parallelo, anziché per preparare e trasformare i dati. Uno svantaggio della trasformazione eseguita al di fuori del data warehouse è che richiede l'apprendimento di strumenti e linguaggi aggiuntivi (diversi da SQL) per esprimere le trasformazioni.

Il seguente diagramma mostra una tipica procedura ETL.

Flusso che mostra l'origine (estrazione) che va a una o più trasformazioni (trasformazione), quindi 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 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 si concentra sulla copia dei dati dal sistema di origine al data warehouse. Le pipeline successive applicano la logica di business e trasformano i dati per utilizzarli in vari data mart, che sono sottoinsiemi del data warehouse incentrati su una specifica unità aziendale o un obiettivo aziendale specifico.

Quando hai più pipeline di dati, devi orchestrarle. Il seguente diagramma mostra come potrebbe essere 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 sotto-DAG 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 un'unità aziendale in modo che i business analyst possano eseguire le proprie dashboard o i propri report.

Estrazione, caricamento e trasformazione (ELT)

ELT è un'alternativa all'ETL. Con ELT, la pipeline di dati è divisa in due parti. In primo luogo, una tecnologia ELT estrae i dati dal sistema di origine e li carica nel data warehouse. Poi, le trasformazioni sono eseguite dagli script SQL sopra il data warehouse. 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 del picco) 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 va a una o più trasformazioni (trasformazione), quindi 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 nel data warehouse una volta e poi trasformati più volte per creare le diverse tabelle che vengono utilizzate a valle nei report e così via. Questi DAG a loro volta diventano sub-DAG in un DAG di orchestrazione più grande (come mostrato nella sezione ETL).

Quando esegui la migrazione delle 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 dei dati molto parallele. Infatti, nel caso di BigQuery, puoi acquistare altre risorse per supportare sia le crescenti richieste di ELT sia le query in parallelo. Per ulteriori informazioni, consulta Introduzione all'ottimizzazione delle prestazioni delle query.

Estrai e carica (EL)

Puoi utilizzare la procedura EL (extact and load) autonomamente o seguita dalle trasformazioni. In questo caso diventa ELT. EL è menzionato separatamente perché sono disponibili diversi servizi automatizzati che eseguono questa attività, riducendo la necessità di creare la tua pipeline di dati di importazione. Per maggiori dettagli, consulta BigQuery Data Transfer Service.

Change Data Capture (CDC)

Change Data Capture (CDC) è uno dei vari pattern di progettazione di software utilizzati per tenere traccia delle modifiche ai dati. Viene 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 CDC funziona con ELT.

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

Figura 4. Come funziona il CDC con l'ELT.

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

Affinché la parte EL sia disponibile, puoi elaborare i log dei database utilizzando software CDC come Datastream o strumenti open source come Debezium e scrivendo i record in BigQuery utilizzando Dataflow. Quindi 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 la creazione di nuove pipeline di dati, valuta la possibilità di utilizzare il pattern CDC applicato come procedura ELT. Questo approccio garantisce una cronologia completa delle modifiche upstream dei dati e garantisce una buona separazione delle responsabilità, ad esempio:

  • I team del sistema di origine assicurano la disponibilità dei log e la pubblicazione degli eventi dei 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 compilare i data mart.

Ciclo di feedback con le pipeline di dati operative

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

I sistemi operativi si riferiscono a sistemi che elaborano le transazioni quotidiane dell'organizzazione, ad esempio database OLTP, sistemi di gestione dei rapporti con i clienti (CRM), sistemi di gestione dei cataloghi di 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 seguente diagramma.

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

Figura 5. Pattern per una pipeline di dati operativa.

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

  • I dati relativi ai prezzi sono disponibili da più fonti. Questi dati possono includere il prezzo attuale 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. La trasformazione in questo caso è 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 piccole trasformazioni per adeguare i prezzi per eventi stagionali e scrive di nuovo 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. Tuttavia, 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 che vengono eseguite in BigQuery e Cloud Composer per orchestrare il flusso di dati end-to-end.

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 scrivere 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 di archiviare i dati nel data warehouse.

I fornitori di software indipendenti (ISV) offrono tecnologie di elaborazione dati con i 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 che scrive temporaneamente i dati in file che vengono successivamente importati da BigQuery.

Pipeline di dati il cui feed è bloccato al sistema precedente e che viene invece alimentato a BigQuery.

Figura 7. Riscrivere o riconfigurare l'ultima funzione di una pipeline di dati per scrivere dati in BigQuery.

A livello generale, il lavoro consiste nel riscrivere, o riconfigurare, l'ultima funzione della pipeline di dati per scrivere dati in BigQuery. Tuttavia, devi affrontare una serie di opzioni che potrebbero richiedere ulteriori modifiche o lavori nuovi, ad esempio:

Funzionale

  • Mappature dei dati: dato che lo schema della tabella di database di destinazione potrebbe cambiare, potrebbe essere necessario riconfigurare queste mappature.
  • Convalida delle metriche: devi convalidare i report nuovi e storici, perché 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.
  • Potrebbe essere necessario apportare modifiche alla rete per creare larghezza di banda aggiuntiva per supportare il trasferimento di dati in uscita.

Reindirizza le pipeline di dati utilizzando i file come veicolo intermedio

Quando la tecnologia esistente della pipeline di dati on-premise non supporta le API di Google o se non puoi utilizzare le API di Google, puoi utilizzare i file come veicolo intermedio per consentire ai tuoi dati di raggiungere BigQuery.

Questo approccio è simile all'approccio di reindirizzamento, ma invece di utilizzare un sink nativo in grado di scrivere in BigQuery, puoi utilizzare un sink in grado di scrivere in un file system on-premise. Quando i dati sono nel file system, puoi copiarli in Cloud Storage. Per ulteriori dettagli, consulta la panoramica delle opzioni di importazione per Cloud Storage e i criteri relativi alla scelta di un'opzione di importazione.

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

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

Pipeline ETL che alimenta un file system invece che nel data warehouse legacy; il file system a sua volta invia 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 delle pipeline on-premise esistenti per scrivere i dati trasformati nel file system. Estendi questa orchestrazione per copiare i file dal tuo file system on-premise a Cloud Storage o 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 di Cloud Storage per pianificare 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, nota come è anche possibile per l'orchestrazione su Google Cloud utilizzare un modello 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 trasforma i dati utilizzando SQL, in modo che possano essere consumati downstream. Quando esegui la migrazione delle pipeline ELT, ciascuna di queste parti ha il proprio approccio alla migrazione.

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

Se le 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 di pipeline di dati OSS esistenti a Dataproc

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

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

Dataproc semplifica la creazione e l'eliminazione dei cluster, invece di utilizzare un unico cluster monolitico, può usare numerosi cluster temporanei. Questo approccio offre diversi vantaggi:

  • Puoi utilizzare diverse configurazioni di cluster per i singoli job, eliminando il carico amministrativo della gestione degli strumenti tra i 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 nuovo 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. Con la migrazione incrementale puoi:

  • Isola i singoli job nell'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 nel momento in cui si presentano senza ritardare le attività dipendenti.
  • Crea una proof of concept per ogni processo complesso senza influire sul tuo ambiente di produzione.
  • Sposta i tuoi job nel modello temporaneo consigliato in modo ponderato e deliberato.

Quando esegui la migrazione dei job Hadoop e Spark esistenti a Dataproc, puoi controllare che le dipendenze dei job siano coperte dalle versioni di Dataproc supportate. Se devi installare un software personalizzato, ti consigliamo di creare una tua immagine Dataproc, utilizzando alcune delle azioni di inizializzazione disponibili (ad esempio per Apache Flink), scrivendo la tua azione di inizializzazione o specificando i requisiti dei 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 è l'utilizzo di software di terze parti per gestire l'esecuzione della pipeline e l'allocazione delle risorse di calcolo.

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

Le sezioni seguenti presentano alcune di queste alternative.

A livello generale, per l'esecuzione del tuo software di terze parti in Google Cloud sono disponibili le seguenti alternative, 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 è l'alternativa 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 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. Si tratta del seguente lavoro:

  • 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 casi d'uso seguendo l'approccio iterativo descritto in Migrazione dei data warehouse in BigQuery: panoramica.

Questa alternativa offre una via di mezzo in termini di complessità. Sfrutta il supporto nativo del fornitore per Kubernetes per scalare e parallelare l'esecuzione delle 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 consentire 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 strutture fornite, possibilmente raggruppando le istanze VM in un gruppo di istanze gestite (MIG) per lo scale in e lo scale out in base alle esigenze.

Gestire la parallelizzazione dell'opera non è banale. Se il tuo fornitore non fornisce funzionalità per la distribuzione delle attività su VM diverse, ti consigliamo di utilizzare un pattern di attività di gestione 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 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. Devi creare un agente semplice da installare su ogni VM. L'agente ascolta 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 attende il completamento. Al termine della pipeline, l'agente recupera il messaggio successivo dagli argomenti che sta ascoltando.

In tutti gli scenari, ti consigliamo di collaborare con il tuo fornitore per rispettare i termini di licenza appropriati per il funzionamento delle tue pipeline in Google Cloud.

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

In alcuni casi, potresti scegliere di riscrivere alcune pipeline di dati esistenti per utilizzare nuovi framework e servizi completamente gestiti su Google Cloud. Questa opzione funziona bene se le pipeline esistenti sono state originariamente implementate con tecnologie ora deprecate o se prevedi che la portabilità e il proseguimento per mantenere le pipeline non modificate nel cloud sarebbero troppo poco pratiche o proibitivi in termini di costi.

Le sezioni seguenti presentano i servizi Google Cloud completamente gestiti che consentono di eseguire trasformazioni avanzate dei 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 creare e gestire le pipeline di dati tramite un'interfaccia grafica.

Puoi sviluppare le pipeline di dati nella UI di Cloud Data Fusion collegando le origini a trasformazioni, sink e altri nodi per formare un DAG. Quando esegui il deployment della pipeline di dati, lo strumento di pianificazione 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 a tua scelta (ad esempio, BigQuery), senza dover scrivere codice. Per farlo, devi caricare un driver JDBC sulla tua 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 i 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 offrono l'accesso a una vasta gamma di origini dati. Se non esiste un plug-in, puoi crearne uno 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 l'accesso a log e metriche, le pipeline di dati consentono agli amministratori di rendere operativi i flussi di lavoro di elaborazione dati senza bisogno di 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 una campagna 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 consente di trasformare e arricchire i dati sia in modalità flusso (in tempo reale) che batch (storico) con pari affidabilità ed espressività.

L'approccio serverless di Dataflow rimuove l'overhead operativo con prestazioni, scalabilità, disponibilità, sicurezza e conformità gestiti automaticamente. In questo modo puoi concentrarti sulla programmazione anziché gestire i cluster dei 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 di portabilità per offrire la piena interoperabilità tra tutti gli SDK e tutti i runner.

Se desideri 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 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 dello zoom: una pipeline di dati è di per sé un'orchestrazione delle trasformazioni dei dati descritte da un DAG, che è un DAG di elaborazione dati.
  • Diminuisci lo zoom: quando una pipeline di dati dipende dall'output di altre pipeline di dati, hai bisogno dell'orchestrazione di più pipeline. Ogni pipeline costituisce un DAG secondario in un DAG più grande, che è un DAG di orchestrazione.

Questa configurazione è tipica del data warehousing. La Figura 1 nella sezione ETL mostra un esempio di configurazione. Le seguenti sezioni si concentrano sull'orchestrazione di varie pipeline di dati.

Dipendenze

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

Più pipeline etichettate con A, B e C a ventaglio nella pipeline D. La pipeline D si dirama verso le pipeline E, F e G. Tutto questo viene 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 il risultato di 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 di dati che li ha creati. Se questa prima pipeline riscontra problemi funzionali o non funzionali, gli errori ricadono a cascata nelle pipeline di dati dipendenti, nella migliore delle ipotesi, costringendole ad attendere o, nel peggiore dei casi, impedendone del tutto l'esecuzione, come mostrato nel seguente diagramma.

La pipeline A riscontra un errore. Le pipeline B e C dipendono dall'output della pipeline A, quindi anche queste non vanno a buon fine.

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

In Google Cloud, hai a disposizione un'ampia gamma di risorse di calcolo e strumenti specializzati per ottimizzare l'esecuzione delle pipeline e la loro orchestrazione. Le sezioni rimanenti si riferiscono a queste risorse e strumenti.

Impegno per la migrazione

È una best practice per semplificare le 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 segue:

  1. In una prima iterazione, sposta l'orchestrazione così com'è su Google Cloud.
  2. Nelle iterazioni successive, analizza le dipendenze e caricale 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 per l'intera organizzazione. È una pipeline complessa che coinvolge molte trasformazioni. Parte della pipeline consiste nel 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 su base mensile per i diversi prodotti, in modo che il reparto marketing possa ottimizzare le iniziative della campagna pubblicitaria. Questa pipeline necessita dei dati sulle vendite mensili calcolati in precedenza dalla pipeline di dati P&L.

L'organizzazione considera che la pipeline dei dati di gestione e gestione abbia una priorità maggiore rispetto a quella di marketing. Purtroppo, poiché P&L è una pipeline di dati complessa e consuma una grande quantità di risorse, impedendo l'esecuzione contemporaneamente di altre pipeline. Inoltre, se la pipeline P&L non funziona, la pipeline di marketing e le altre pipeline dipendenti non dispongono dei dati necessari per l'esecuzione e devono attendere un nuovo tentativo di conto economico. Il seguente diagramma illustra questa situazione.

La pipeline P&L 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 bassa priorità.

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

Il team di migrazione esegue la prima iterazione. Ha scelto di trasferire in Google Cloud sia i casi d'uso relativi al rapporto economico che quelli di marketing, utilizzando un approccio di reindirizzamento. Non apportano modifiche ai passaggi o all'orchestrazione della pipeline. Un'importante differenza è che ora la pipeline P&L può smaltire una potenza di calcolo quasi illimitata e, di conseguenza, viene eseguita molto più velocemente rispetto all'ambiente on-premise. La pipeline scrive i dati mensili delle vendite in una tabella BigQuery utilizzata dalla pipeline per la crescita del marketing. Il seguente diagramma illustra queste modifiche.

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

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

Anche se Google Cloud ha aiutato a risolvere i problemi non funzionali di conto economico, i problemi funzionali permangono. Alcune attività non correlate che precedono il calcolo delle vendite mensili spesso causano errori che impediscono il calcolo e impediscono l'avvio delle pipeline dipendenti.

In una seconda iterazione, il team spera di migliorare le prestazioni includendo entrambi i casi d'uso nel backlog di iterazioni. 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 prossimo diagramma. Il team di migrazione copia il sub-DAG nella pipeline di marketing, in modo che possa essere eseguita in modo indipendente dal P&L. Potendo contare su una potenza di calcolo sufficiente in Google Cloud, entrambe le pipeline possono essere eseguite contemporaneamente.

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

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

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

In una terza iterazione, il team rivede i casi d'uso ed estrae il sub-DAG delle vendite mensili in una pipeline indipendente. Al termine della nuova pipeline di vendita mensile, si attiva o si concentra il conto economico, la crescita del marketing e altre pipeline dipendenti. Questa configurazione crea un nuovo DAG di orchestrazione complessiva, in cui ogni pipeline è uno dei suoi DAG secondari.

La pipeline di vendita mensile è ora la prima, alimentando la pipeline P&L e la pipeline di marketing.

Figura 15. Orchestrazione complessiva del DAG con ogni pipeline nel proprio sub-DAG.

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

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

Passaggi successivi

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

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