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

Che cos'è una pipeline di dati?

In informatica, una pipeline di dati è un tipo di applicazione che elabora i dati attraverso una sequenza di passaggi di elaborazione collegati. Come concetto generale, le pipeline di dati possono essere applicate, ad esempio, al trasferimento di dati tra sistemi informativi, all'estrazione, trasformazione e 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 viene eseguito oppure come processo di streaming che viene eseguito continuamente ed elabora i dati man mano che diventano disponibili per la pipeline.

Nel contesto del data warehousing, le pipeline di dati vengono comunemente utilizzate per leggere i dati dai sistemi transazionali, applicare le trasformazioni e quindi scrivere i dati nel data warehouse. Ogni trasformazione è 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 grafo aciclico orientato (DAG), ovvero il grafico 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. Ogni nodo del grafico è una funzione e ogni bordo rappresenta il flusso di dati da una funzione all'altra. Le funzioni iniziali sono le origini o le connessioni ai sistemi di dati di origine. Le funzioni finali sono i sink o le connessioni ai sistemi di dati di destinazione.

Nel contesto delle pipeline di dati, le origini sono in genere sistemi transazionali, ad esempio un RDBMS, e il sink si connette a un data warehouse. Questo tipo di grafico è chiamato DAG del flusso di dati. Puoi anche utilizzare i DAG per orchestrare lo spostamento dei dati tra le pipeline di dati e altri sistemi. Questo utilizzo viene 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 eseguire l'offload o eseguire la migrazione completa.

Da un lato, quando esegui l'offload di un caso d'uso, non devi eseguire la migrazione delle relative pipeline di dati upstream in anticipo. Per prima cosa, esegui la migrazione dello schema e dei dati del caso d'uso dal data warehouse esistente a BigQuery. Successivamente, stabilisci 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 sono invariate e continuano a scrivere dati nel data warehouse esistente. Puoi includere di nuovo i casi d'uso scaricati nel backlog della migrazione per eseguire la migrazione completa in un'iterazione successiva.

D'altra parte, quando esegui la migrazione completa di un caso d'uso, le pipeline di dati upstream necessarie per il caso d'uso vengono migrate a Google Cloud. La migrazione completa richiede prima di scaricare il caso d'uso. Dopo la migrazione completa, 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:

  • Esegui l'offload solo del tuo caso d'uso.
  • Esegui la migrazione completa di un caso d'uso precedentemente scaricato.
  • Esegui la migrazione completa di un caso d'uso da zero scaricandolo prima nella stessa iterazione.

Una volta eseguita la migrazione completa 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

Il resto di questo documento spiega come eseguire la migrazione delle pipeline di dati, incluso l'approccio e le procedure da utilizzare e le tecnologie da impiegare. Le opzioni vanno dal riutilizzo delle pipeline di dati esistenti (reindirizzandole per il caricamento in 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 le più utilizzate nel data warehousing. Potresti avere pipeline di dati batch o pipeline di dati in streaming. Le pipeline di dati batch vengono eseguite sui dati raccolti in un periodo di tempo (ad esempio, una volta al giorno). Le pipeline di dati in streaming gestiscono gli eventi in tempo reale generati dai tuoi sistemi operativi, ad esempio le modifiche alle righe CDC generate dai tuoi database Online Transaction Processing (OLTP).

Estrazione, trasformazione e caricamento (ETL)

Nel contesto del data warehousing, le pipeline di dati spesso eseguono una procedura di estrazione, trasformazione e caricamento (ETL). 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 simultanee, anziché per preparare e trasformare i dati. Uno svantaggio dell'esecuzione della trasformazione 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), poi a un sink e infine a un data warehouse (caricamento)

Figura 1. Una procedura ETL tipica.

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, il controllo dell'integrità dei dati e la creazione di aggregazioni o disaggregazioni. Per maggiori informazioni, consulta la sezione 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 l'utilizzo in vari data mart, che sono sottoinsiemi del data warehouse incentrati su una specifica unità aziendale o su un focus aziendale.

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

Orchestratore (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 un'unità aziendale in modo che gli analisti aziendali possano eseguire i propri dashboard o report.

Estrazione, caricamento e trasformazione (ELT)

ELT è un'alternativa a ETL. Con ELT, la pipeline di dati è divisa 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 in cima al data warehouse eseguono le trasformazioni. Il vantaggio di questo approccio è che puoi utilizzare SQL per esprimere le trasformazioni; lo svantaggio è che potrebbe consumare risorse del data warehouse necessarie per le query simultanee. Per questo motivo, i batch ELT vengono spesso eseguiti di notte (o fuori orario 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, poi a un sink e infine a un data warehouse (caricamento).

Figura 3. Una procedura ELT tipica.

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 sola volta e poi trasformati più volte per creare le diverse tabelle utilizzate a valle nei report e così via. Questi DAG a loro volta diventano DAG secondari 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 cloud come BigQuery sono tecnologie di elaborazione dei dati massicciamente parallele. Infatti, nel caso di BigQuery, puoi acquistare più risorse per supportare sia le crescenti richieste di ELT sia le query simultanee. Per ulteriori informazioni, consulta Introduzione all'ottimizzazione del rendimento delle query.

Estrai e carica (EL)

Puoi utilizzare la procedura di estrazione e caricamento (EL) da sola o seguita da trasformazioni, nel qual caso diventa ELT. L'estrazione viene menzionata separatamente perché sono disponibili diversi servizi automatizzati che eseguono questa attività, riducendo la necessità di creare una pipeline di dati di importazione personalizzata. Per maggiori dettagli, vedi Che cos'è BigQuery Data Transfer Service?

Change Data Capture (CDC)

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

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

Flusso ETL che mostra singoli record con informazioni sulla versione assegnate all'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 modifiche downstream.

Per eseguire la parte EL, puoi elaborare i log del database utilizzando un software CDC come Datastream o strumenti open source come Debezium e scrivere i record in BigQuery utilizzando Dataflow. Poi puoi utilizzare una query SQL per determinare l'ultima versione 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 upstream e una buona separazione delle responsabilità, ad esempio:

  • I team dei sistemi di origine garantiscono la disponibilità dei log e la pubblicazione dei dati degli eventi.
  • Il team della piattaforma di dati garantisce che le regole di confronto di importazione dei record originali includano i timestamp nel data warehouse.
  • I team di data engineering e di analisi pianificano una serie di trasformazioni per popolare i data mart.

Cicli di feedback con pipeline di dati operativi

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

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

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

Pipeline ETL che alimenta il data warehouse e poi una pipeline operativa che alimenta nuovamente il 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 autorevole per le informazioni sui prodotti correlate 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 per regione del PCM, 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 fonti con l'obiettivo di produrre un prezzo base ottimale per ogni prodotto nel PCM.
  • Infine, la pipeline operativa prende i prezzi di base dal data warehouse, esegue trasformazioni leggere per adeguare i prezzi agli eventi stagionali e riscrive i prezzi finali nel PCM.

Sistema PCM che alimenta il 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 dei dati, GoogleSQL per definire le trasformazioni che vengono eseguite in BigQuery e Cloud Composer per orchestrare il flusso di dati end-to-end.

Scegliere un approccio di migrazione

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

Reindirizzare le pipeline di dati per scrivere in BigQuery

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

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

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

Se la tecnologia della pipeline di dati non supporta l'importazione dei 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.

Pipeline di dati che non può essere inserita nel sistema legacy e viene invece inserita in BigQuery.

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

A livello generale, il lavoro da svolgere riguarda la riscrittura o la riconfigurazione dell'ultima funzione della pipeline di dati per scrivere i dati in BigQuery. Tuttavia, hai a disposizione una serie di opzioni che potrebbero richiedere modifiche aggiuntive o nuovo lavoro, ad esempio:

Funzionale

  • Mapping dei dati: dato che lo schema della tabella del database di destinazione potrebbe cambiare, potrebbe essere necessario riconfigurare questi mapping.
  • Convalida delle metriche: devi convalidare sia i report storici sia quelli nuovi, perché sia lo schema sia le query potrebbero cambiare.

Non funzionante

  • Potrebbe essere necessario configurare i firewall per consentire il trasferimento dei dati in uscita da on-premise a BigQuery.
  • Potrebbero essere necessarie modifiche alla rete per creare ulteriore larghezza di banda, per gestire il trasferimento dei dati in uscita.

Reindirizzare le pipeline di dati utilizzando i file come veicolo intermedio

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

Questo approccio è simile a quello del reindirizzamento, ma anziché utilizzare un sink nativo che può scrivere in BigQuery, utilizzi un sink che può scrivere in un file system on-premise. Quando i dati si trovano nel file system, puoi copiare i file in Cloud Storage. Per maggiori dettagli, consulta la panoramica delle opzioni di importazione per Cloud Storage e i criteri da considerare per scegliere un'opzione di importazione.

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

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

Pipeline ETL che viene inserita in un file system anziché nel data warehouse legacy; il file system a sua volta viene inserito in Cloud Storage e da lì in 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 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 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, nota come sia anche possibile che l'orchestrazione su Google Cloud utilizzi un modello pull recuperando i file utilizzando un protocollo come SFTP.

Esegui la migrazione delle pipeline ELT esistenti a BigQuery

Le pipeline ELT sono costituite 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 utilizzati a valle. Quando esegui la migrazione delle pipeline ELT, ogni parte ha il suo approccio per la migrazione.

Per la parte che carica i dati nel data warehouse (la parte EL), puoi seguire le linee guida nella sezione reindirizzare le pipeline di dati, meno i suggerimenti 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 pipeline di dati a 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 ti consente di eseguire il deployment di cluster Hadoop e Spark completamente gestiti, veloci e facili da utilizzare in modo semplice ed economico. Dataproc si integra con il connettore BigQuery, una libreria Java che consente a Hadoop e Spark di scrivere direttamente i dati in BigQuery utilizzando versioni astratte delle classi Apache Hadoop InputFormat e OutputFormat.

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

  • Puoi utilizzare configurazioni del cluster diverse per i singoli job, eliminando l'onere amministrativo della gestione degli strumenti tra i job.
  • Puoi scalare i cluster in base a singoli job o gruppi di job.
  • Paghi solo le risorse quando vengono utilizzate dai tuoi job.
  • Non devi gestire i cluster nel tempo, perché vengono configurati di nuovo ogni volta che li utilizzi.
  • Non è necessario gestire un'infrastruttura separata per lo sviluppo, i test e la produzione. Puoi utilizzare le stesse definizioni per creare tutte le versioni diverse di un cluster di cui hai bisogno quando ti servono.

Quando esegui la migrazione dei job, ti consigliamo di adottare un approccio incrementale. Eseguendo la migrazione in modo 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 man mano 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 nel 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, potresti prendere in considerazione la creazione di una tua immagine Dataproc, l'utilizzo di alcune delle azioni di inizializzazione disponibili (ad esempio, per Apache Flink), la scrittura di un'azione di inizializzazione personalizzata o la specifica di requisiti personalizzati per i pacchetti Python.

Per iniziare, consulta le guide di avvio rapido di Dataproc e gli esempi di codice del connettore BigQuery.

Esegui nuovamente l'hosting delle 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 diverse alternative, a seconda delle funzionalità del software che utilizzi e anche a seconda dei termini di licenza, assistenza e manutenzione.

Le sezioni seguenti presentano alcune di queste alternative.

In linea generale, hai le seguenti alternative per eseguire il software di terze parti in Google Cloud, dalla meno alla più complessa:

  • Il tuo fornitore di software ha collaborato con Google Cloud per offrire il proprio software in Google Cloud Marketplace.
  • Il 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 sul 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 l'ambiente originale e il nuovo ambiente su Google Cloud.

Se il tuo fornitore non offre 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 coinvolte le seguenti attività:

  • Crea un cluster GKE seguendo i consigli del fornitore per assicurarti che il prodotto di terze parti possa sfruttare il parallelismo delle attività offerto 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 a BigQuery: panoramica.

Questa alternativa rappresenta una via di mezzo in termini di complessità. Sfrutta il supporto nativo del fornitore per Kubernetes per scalare e parallelizzare 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 suo software su un pool di VM per consentire lo scale out e la parallelizzazione del lavoro. Se il software del fornitore supporta in modo nativo la distribuzione del lavoro a più VM, utilizza le funzionalità fornite, raggruppando eventualmente le istanze VM in un gruppo di istanze gestite (MIG) per lo scale in e lo scale out in base alle esigenze.

La gestione della parallelizzazione del lavoro non è banale. Se il tuo fornitore non fornisce funzionalità per distribuire le attività a VM diverse, ti consigliamo di utilizzare un pattern di task farming per distribuire il lavoro alle VM in un MIG. Il seguente diagramma illustra questo approccio.

più input vanno a Pub/Sub, che crea argomenti. Gli argomenti vengono letti da diversi MIG.

Figura 9. Un gruppo di istanze gestite (MIG) con tre VM.

In questo diagramma, ogni VM nel MIG 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. Crea un semplice agente da installare in ogni VM. L'agente è in ascolto di uno o più argomenti Pub/Sub. Ogni volta che arriva un messaggio nell'argomento, l'agente lo estrae, avvia una pipeline nel software di terze parti e 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 affinché le pipeline funzionino su Google Cloud.

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

In alcuni casi, potresti scegliere di riscrivere alcune delle pipeline di dati esistenti per utilizzare nuovi framework e servizi completamente gestiti su Google Cloud. Questa opzione è adatta se le pipeline esistenti sono state implementate originariamente con tecnologie ora ritirate o se prevedi che il porting e la manutenzione continua di queste pipeline non modificate nel cloud sarebbero troppo impraticabili o costosi.

Le sezioni seguenti presentano 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, che si basa sul progetto open source CDAP, è un servizio di integrazione dei dati completamente gestito per creare e gestire pipeline di dati tramite un'interfaccia grafica.

Sviluppi 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, 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 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 nell'istanza Cloud Data Fusion e configurarlo in modo da poterlo utilizzare nelle 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, editor di avvisi, azioni e azioni post-esecuzione come componenti personalizzabili. I plug-in predefiniti offrono l'accesso a un'ampia gamma di origini dati. Se un plug-in non esiste, puoi crearne uno utilizzando le API plug-in di Cloud Data Fusion. Per ulteriori informazioni, consulta la panoramica dei plug-in.

Con le pipeline Cloud Data Fusion, puoi creare pipeline di dati sia in batch che in streaming. Fornendo l'accesso a log e metriche, le pipeline di dati offrono anche agli amministratori modi per rendere operativi i workflow di elaborazione dei dati senza la necessità 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 della 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, incluso un connettore per BigQuery. Apache Beam consente di trasformare e arricchire i dati in modalità flusso (in tempo reale) e batch (storici) con affidabilità ed espressività garantite.

L'approccio serverless di Dataflow elimina l'overhead operativo in quanto prestazioni, scalabilità, disponibilità, sicurezza e conformità vengono gestite automaticamente. 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 di portabilità per garantire la piena interoperabilità tra tutti gli SDK e i runner.

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

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

Orchestrazione e pianificazione

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

  • Zoom in: una pipeline di dati è di per sé un'orchestrazione di trasformazioni dei dati descritte da un DAG, che è un DAG di elaborazione dei dati.
  • Riduzione dello zoom: 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, ovvero un DAG di orchestrazione.

Questa configurazione è tipica del data warehousing. La figura 1 nella sezione ETL mostra un esempio di configurazione. Le sezioni seguenti si concentrano 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; fan-out, in cui una singola pipeline di dati ne attiva più di una; o spesso entrambe, come mostrato nel seguente diagramma.

Più pipeline etichettate A, B e C convergono nella pipeline D. La pipeline D si dirama nelle 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 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 ha creato i dati. Se questa prima pipeline riscontra problemi funzionali o non funzionali, gli errori vengono propagati alle pipeline di dati dipendenti, costringendole al meglio ad attendere o, nel peggiore dei casi, impedendo loro di essere eseguite, come mostrato nel seguente diagramma.

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

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

In Google Cloud, sono disponibili numerose risorse di calcolo e strumenti specializzati per consentirti di ottimizzare l'esecuzione delle pipeline e la loro orchestrazione. Le sezioni rimanenti trattano queste risorse e questi strumenti.

Lavoro di migrazione coinvolto

È consigliabile semplificare le esigenze di orchestrazione. L'orchestrazione aumenta di 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 parallelizzale se possibile.
  3. Infine, riorganizza l'orchestrazione estraendo le attività comuni in DAG separati.

La sezione successiva spiega questo metodo con un esempio pratico.

Un esempio pratico

Supponiamo che un'organizzazione abbia due pipeline correlate:

  • La prima pipeline calcola gli utili e le perdite (P&L) per l'intera organizzazione. Si tratta di una pipeline complessa che prevede molte trasformazioni. Una parte della pipeline consiste nel calcolare le vendite mensili, che vengono utilizzate nei passaggi di trasformazione successivi e infine scritte in una tabella.
  • La seconda pipeline calcola la crescita delle vendite anno su anno e mese su mese per diversi prodotti, in modo che il reparto marketing possa ottimizzare i propri sforzi per le campagne pubblicitarie. Questa pipeline ha bisogno dei dati sulle vendite mensili calcolati in precedenza dalla pipeline di dati P&L.

L'organizzazione considera la pipeline di dati P&L con una priorità maggiore rispetto alla pipeline di marketing. Purtroppo, poiché P&L è una pipeline di dati complessa, consuma una grande quantità di risorse, impedendo l'esecuzione simultanea di altre pipeline. Inoltre, se la pipeline P&L non va a buon fine, la pipeline di marketing e altre pipeline dipendenti non dispongono dei dati necessari per essere eseguite e devono attendere un nuovo tentativo di P&L. Il seguente diagramma illustra questa situazione.

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

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

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 di migrazione. Durante la pianificazione della successiva iterazione, l'organizzazione assegna la priorità al caso d'uso del conto economico e lo include nel backlog dell'iterazione perché è fortemente limitato dalle risorse on-premise attuali e causa regolarmente ritardi. Sono inclusi anche alcuni casi d'uso dipendenti, tra cui quello del marketing.

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

La pipeline del conto economico è la stessa di prima, ma non subisce ritardi.

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

Sebbene Google Cloud abbia contribuito a risolvere i problemi di conto economico non funzionante, i problemi funzionali persistono. 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 il rendimento 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 indipendentemente dal conto economico. Disporre di una potenza di calcolo sufficiente in Google Cloud consente a entrambe le pipeline di 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 in caso di problemi nella pipeline P&L.

Figura 14. Pipeline eseguite contemporaneamente utilizzando un sub-DAG.

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

In una terza iterazione, il team rivisita i casi d'uso ed estrae il DAG secondario delle vendite mensili in una pipeline indipendente. Quando la nuova pipeline delle vendite mensili è completata, viene attivata o si dirama nel conto economico, nella crescita del marketing e in altre pipeline dipendenti. Questa configurazione crea un nuovo DAG di orchestrazione complessivo, in cui ogni pipeline è uno dei suoi DAG secondari.

La pipeline delle vendite mensili è ora la prima, alimentando la pipeline del conto economico e quella di marketing.

Figura 15. DAG di orchestrazione generale con ogni pipeline nel proprio sub-DAG.

Nelle iterazioni successive, il team di migrazione può risolvere eventuali problemi funzionali rimanenti e migrare le pipeline per utilizzare i seguenti servizi gestiti daGoogle Cloud, tra gli altri:

Anche se Airflow supporta i DAG secondari in modo nativo, questa funzionalità potrebbe limitarne il rendimento 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 di più sulla migrazione da tecnologie di data warehouse specifiche a BigQuery: