Esegui la migrazione delle pipeline di dati

Questo documento descrive come eseguire la migrazione delle pipeline di dati upstream, che caricano i dati nel data warehouse. Puoi utilizzare questo documento per comprendere meglio che 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 ambito informatico, una pipeline di dati è un tipo di applicazione che elabora i dati tramite 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 al momento dell'esecuzione o come processo streaming che si esegue 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 poi scrivere i 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 collegate sono descritte come un grafo, spesso definito grafo aciclico diretto (DAG), ovvero un grafo che 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 origini o collegamenti ai sistemi di dati di origine. Le funzioni finali sono sink, ovvero collegamenti ai sistemi di dati di destinazione.

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

Da un lato, quando esegui il trasferimento di un caso d'uso, non devi eseguire la migrazione delle relative pipeline di dati a monte. Per prima cosa, esegui la migrazione dello schema e dei dati del caso d'uso dal tuo data warehouse esistente a BigQuery. Poi, stabilisci una copia incrementale dal vecchio al nuovo data warehouse per mantenere i dati sincronizzati. Infine, esegui la migrazione e la convalida dei processi a valle come script, query, dashboard e applicazioni aziendali.

A questo punto, le pipeline di dati upstream rimangono invariate e continuano a scrivere dati nel data warehouse esistente. Puoi includere di nuovo i casi d'uso di cui è stato eseguito il trasferimento 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 a monte richieste per il caso d'uso vengono migrate a Google Cloud. La migrazione completa richiede innanzitutto di eseguire il offload del 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 il offload solo del tuo caso d'uso.
  • Esegui la migrazione completa di un caso d'uso di cui è stato eseguito il trasferimento in precedenza.
  • Esegui la migrazione completa di un caso d'uso da zero eseguendo prima il offload nella stessa Iterazione.

Una volta completata la migrazione di tutti i casi d'uso, puoi scegliere di disattivare il vecchio magazzino, un passaggio importante per ridurre gli 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 (riassegnandole 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. Puoi avere pipeline di dati batch o di dati in streaming. Le pipeline di dati in batch vengono eseguite sui dati raccolti in un determinato periodo di tempo (ad esempio una volta al giorno). Le pipeline di dati in streaming gestiscono gli eventi in tempo reale generati dai sistemi operativi, ad esempio le modifiche alle righe nel 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 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 le query simultanee anziché per la preparazione e la trasformazione dei dati. Uno svantaggio dell'esecuzione della trasformazione al di fuori del data warehouse è che richiede di apprendere strumenti e linguaggi aggiuntivi (diversi da SQL) per esprimere le trasformazioni.

Il seguente diagramma mostra una procedura ETL tipica.

Flusso che mostra l'origine (estrazione) che passa a una o più trasformazioni (trasformazione), poi a un'area di destinazione 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 meno 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 dati aggregati o disaggregati. Per ulteriori 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 utilizzarli in vari data mart, che sono sottoinsiemi del data warehouse incentrati su un'unità o un'attività aziendale specifica.

Quando hai più pipeline di dati, devi orchestrarle. Il seguente diagramma mostra come potrebbe essere questa procedura 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 sotto-DAG del DAG di orchestrazione. Ogni DAG di orchestrazione comprende diverse pipeline di dati in linea con lo scopo più ampio, ad esempio la preparazione dei dati per un'unità aziendale in modo che gli analisti aziendali possano eseguire le loro dashboard o i loro report.

Estrazione, caricamento e trasformazione (ELT)

ELT è un'alternativa a ETL. Con l'ELT, la pipeline di dati è suddivisa in due parti. Innanzitutto, una tecnologia ELT estrae i dati dal sistema di origine e li carica nel data warehouse. In secondo luogo, gli script SQL sul data warehouse eseguono le trasformazioni. Il vantaggio di questo approccio è che puoi utilizzare SQL per esprimere le trasformazioni. Lo svantaggio è che questo potrebbe consumare le 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 procedura ELT tipica.

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

Figura 3. Una procedura ELT tipica.

Quando si adotta un approccio ELT, è comune separare l'estrazione e il caricamento in un DAG e le trasformazioni in DAG distinti. I dati vengono caricati nel data warehouse una volta e poi trasformati più volte per creare le diverse tabelle utilizzate a valle nei report e così via. A loro volta, questi DAG diventano sotto-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 cloud come BigQuery sono tecnologie di elaborazione dati in parallelo massivo. 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 la sezione Introduzione all'ottimizzazione delle prestazioni delle query.

Estrazione e caricamento (EL)

Puoi utilizzare la procedura di estrazione e caricamento (EL) da sola o seguita da trasformazioni, nel qual caso diventa ELT. L'EL è menzionata separatamente perché sono disponibili diversi servizi automatici che eseguono questa attività, limitando la necessità di creare la propria pipeline di dati di importazione. Per maggiori dettagli, consulta BigQuery Data Transfer Service.

Change Data Capture (CDC)

Change Data Capture (CDC) è uno dei diversi pattern di progettazione software utilizzati per monitorare le modifiche ai dati. Viene spesso utilizzato nei data warehousing perché questi vengono utilizzati 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 la CDC con ELT.

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

Figura 4. Come funziona CDC con ELT.

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

Per eseguire la parte di EL, puoi elaborare i log del database utilizzando 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 la versione più recente prima di applicare ulteriori trasformazioni. Ecco un esempio:

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

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

  • I team dei sistemi di origine assicurano la disponibilità dei log e la pubblicazione degli eventi dei dati.
  • Il team della piattaforma di dati si assicura che l'ordinamento dell'importazione dei record originali includa i timestamp nel data warehouse.
  • I team di data engineering e di analisi pianificano una serie di trasformazioni per compilare i data mart.

Loop di feedback con pipeline di dati operativi

Le pipeline di dati operativi sono pipeline di elaborazione dei dati che acquisiscono 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 database OLTP, sistemi di gestione dei rapporti con i clienti (CRM), sistemi di gestione del catalogo di prodotti (PCM) e così via. Poiché questi sistemi spesso fungono da 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 poi una pipeline operativa che reimmette nel 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 end-to-end dei dati:

  • I dati relativi ai prezzi sono disponibili da più origini. Questi dati possono includere il prezzo corrente per regione del PCM, i prezzi della concorrenza di un servizio di terze parti, la previsione della domanda e l'affidabilità dei fornitori dei sistemi interni e così via.
  • Una pipeline ETL estrae i dati dalle origini, li trasforma e li scrive 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 prende i prezzi base dal data warehouse, esegue trasformazioni leggere per adeguare i prezzi agli eventi stagionali e riscrivi 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 a valle, mentre le pipeline di dati che implementano ETL, ELT o CDC sono processi a monte. Tuttavia, gli strumenti utilizzati per implementarli 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 end-to-end dei dati.

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 in modo che scrivano in BigQuery

Nelle seguenti condizioni, ti consigliamo di valutare se una tecnologia che utilizzi offre un destinazione BigQuery integrata (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 indipendente (ISV) offrono tecnologie di elaborazione dei dati con connettori BigQuery, tra cui:

Se la tecnologia della pipeline di dati non supporta l'importazione dati in BigQuery, ti consigliamo di utilizzare una variazione di questo approccio che scriva temporaneamente i dati in file successivamente importati da BigQuery.

La pipeline di dati che non può essere inviata al sistema precedente, ma viene inviata a BigQuery.

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

A grandi linee, il lavoro consisteva nella riscrittura o nella 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

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

Non funzionante

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

Reindirizzare le pipeline di dati utilizzando i file come veicolo intermedio

Quando la tecnologia di pipeline di dati on-premise esistente 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 dati di raggiungere BigQuery.

Questo approccio è simile a quello di 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 sono nel file system, copia i file in Cloud Storage. Per maggiori dettagli, consulta la panoramica delle opzioni di importazione per Cloud Storage e i criteri coinvolti nella scelta di un'opzione di importazione.

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

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

Pipeline ETL che si inserisce in un file system anziché nel data warehouse precedente; il file system a sua volta si inserisce in Cloud Storage e da qui 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 distinti:

  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 o crea uno script aggiuntivo che venga eseguito regolarmente per eseguire il passaggio di copia.
  2. Quando i dati sono 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 gli attivatori Cloud Storage e Cloud Composer.

Nella Figura 8, tieni presente che è anche possibile per l'orchestrazione su Google Cloud utilizzare 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 li trasforma utilizzando SQL in modo che possano essere utilizzati a valle. Quando esegui la migrazione delle pipeline ELT, ogni parte ha il suo approccio alla migrazione.

Per la parte che carica i dati nel data warehouse (la parte EL), puoi seguire le linee guida riportate nella sezione Ridirezionare le pipeline di dati, tranne 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 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 dati in BigQuery utilizzando versioni astratte delle classi Apache Hadoop InputFormat e OutputFormat.

Dataproc semplifica la creazione ed eliminazione dei cluster, in modo che, anziché utilizzare un cluster monolitico, puoi utilizzare molti cluster effimeri. Questo approccio presenta diversi vantaggi:

  • Puoi utilizzare configurazioni del cluster diverse per i singoli job, eliminando il carico amministrativo della gestione degli strumenti nei vari job.
  • Puoi scalare i cluster in base ai singoli job o ai gruppi di job.
  • Paghi solo per le risorse quando vengono utilizzate dai tuoi job.
  • Non è necessario 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. Con la migrazione incrementale puoi:

  • Isola i singoli job nell'infrastruttura Hadoop esistente dalla complessità insita in 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 verificano senza ritardare le attività dipendenti.
  • Crea una proof of concept per ogni processo complesso senza influire sul tuo ambiente di produzione.
  • Sposta i 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 Dataproc supportate. Se devi installare software personalizzato, ti consigliamo di creare la tua immagine Dataproc, di utilizzare alcune delle azioni di inizializzazione disponibili (ad esempio per Apache Flink), di scrivere la tua azione di inizializzazione o di specificare i requisiti dei pacchetti Python personalizzati.

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

Eseguire il rehosting delle pipeline di dati di terze parti in modo che vengano eseguite su Google Cloud

Uno scenario comune per 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 sul cloud, hai a disposizione diverse alternative, a seconda delle funzionalità del software in uso e anche dei termini di licenza, assistenza e manutenzione.

Le sezioni seguenti presentano alcune di queste alternative.

A un livello generale, hai a disposizione le seguenti alternative per eseguire il software di terze parti in Google Cloud, dalla meno alla più complessa:

  • Il tuo fornitore di software ha stretto una partnership con Google Cloud per offrire il proprio software su 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, le attività necessarie sono le seguenti:

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 nuovo ambiente su Google Cloud.

Se il tuo fornitore non fornisce una soluzione del marketplace cloud, ma il suo prodotto è in grado di funzionare su Kubernetes, puoi utilizzare Google Kubernetes Engine (GKE) per ospitare le tue pipeline. Sono coinvolti i seguenti lavori:

  • Crea un cluster GKE seguendo i consigli del tuo fornitore per assicurarti che il prodotto di terze parti possa sfruttare la parallellizzazione delle attività offerta da Kubernetes.
  • Installa il software di terze parti sul tuo cluster GKE seguendo i consigli del fornitore.
  • Seleziona ed esegui la migrazione dei casi d'uso seguendo l'approccio iterativo spiegato 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 parallelizzare l'esecuzione delle pipeline. Tuttavia, devi creare e gestire un cluster GKE.

Se il tuo fornitore non supporta Kubernetes, devi installare il suo software su un pool di VM per abilitare il ridimensionamento e la parallelizzazione del lavoro. Se il software del fornitore supporta in modo nativo la distribuzione del lavoro su più VM, utilizza le funzionalità fornite, eventualmente raggruppando le istanze VM in un gruppo di istanze gestite (MIG) per eseguire il ridimensionamento in base alle esigenze.

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

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

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

In questo diagramma, ogni VM nel gruppo 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 agente semplice da installare in ogni VM. L'agente ascolta uno o più argomenti Pub/Sub. Ogni volta che un messaggio arriva nell'argomento, l'agente lo estrae 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 su Google Cloud.

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

In alcuni casi, puoi scegliere di riscrivere alcune delle pipeline di dati esistenti per utilizzare nuovi framework e servizi completamente gestiti su Google Cloud. Questa opzione è ideale se le pipeline esistenti sono state implementate inizialmente con tecnologie ora ritirate o se prevedi che il porting e il mantenimento di queste pipeline non modificate nel cloud siano troppo poco pratici o eccessivamente costosi.

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

Sviluppa le pipeline di dati nell'interfaccia utente 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 in parallelo che verranno eseguiti come job Apache Spark su Dataproc.

Quando utilizzi Cloud Data Fusion, puoi collegarti 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, aggregati, sink, collezionisti di errori, publisher 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 la possibilità di rendere operativi i loro flussi di lavoro di elaborazione dei 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 campagne di targeting.

Dataflow

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

L'approccio serverless di Dataflow rimuove 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 la interfaccia a riga di comando, l'SDK Java o l'SDK Python. Inoltre, stiamo sviluppando un framework di portabilità per garantire l'interoperabilità completa 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, consulta il modello di programmazione Apache Beam e la documentazione ufficiale di Dataflow.

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

Orchestrazione e pianificazione

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

  • Zoom in: una pipeline di dati è essa stessa un'orchestrazione di trasformazioni di dati descritte da un DAG, ovvero un DAG di elaborazione dei dati.
  • Zoom out: quando una pipeline di dati dipende dall'output di altre pipeline di dati, è necessaria l'orchestrazione di più pipeline. Ogni pipeline costituisce un sottoDAG 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 a convergenza, quando più pipeline di dati si fondono in un vertice di un DAG di orchestrazione; a divergenza, quando una singola pipeline di dati attiva altre più; o spesso entrambe, come mostrato nel seguente diagramma.

Più pipeline etichettate come A, B e C confluiscono nella pipeline D. La pipeline D si suddivide nelle pipeline E, F e G. Tutto questo viene 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 li ha creati. Se questa prima pipeline riscontra problemi funzionali o non funzionali, gli errori si propagano alle pipeline di dati dipendenti, nel migliore dei casi costringendole ad attendere o, nel peggiore, impedendo loro di funzionare, come mostrato nel seguente diagramma.

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

Figura 11. Gli errori che si verificano in una pipeline di dati impediscono l'esecuzione delle pipeline dipendenti.

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

Attività di migrazione necessarie

È 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'è in Google Cloud.
  2. Nelle iterazioni successive, analizza le dipendenze e esegui il loro parallelismo, se possibile.
  3. Infine, riorganizza l'orchestrazione estraendo le attività comuni nei rispettivi DAG.

La sezione successiva illustra 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 (utili e perdite) per l'intera organizzazione. Si tratta di una pipeline complessa che prevede molte trasformazioni. 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 su base annua e mensile per diversi prodotti, in modo che il reparto marketing possa ottimizzare le proprie campagne pubblicitarie. Questa pipeline richiede i dati mensili sulle vendite precedentemente calcolati dalla pipeline di dati del conto economico.

L'organizzazione considera la pipeline di dati P&L di priorità superiore rispetto alla pipeline di marketing. Purtroppo, poiché il profitto e il loss è una pipeline di dati complessa, consuma una grande quantità di risorse, impedendo l'esecuzione di altre pipeline contemporaneamente. Inoltre, se la pipeline del profitto e della perdita non va a buon fine, la pipeline di marketing e altre pipeline dipendenti non dispongono dei dati necessari per poter essere eseguite e devono attendere un nuovo tentativo per il profitto e la perdita. 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ò presentare ritardi e altri problemi.

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

L'organizzazione sta eseguendo la migrazione a BigQuery. Ha identificato i due casi d'uso, utili per il bilancio e la crescita delle vendite di marketing, e li ha inclusi nel backlog della migrazione. Quando pianifica la successiva iterazione, l'organizzazione dà la priorità al caso d'uso P&L e lo include nel backlog dell'iterazione perché è fortemente limitato dalle risorse on-premise attuali e causa regolarmente ritardi. Sono inclusi anche alcuni dei casi d'uso dipendenti, tra cui il caso d'uso per il marketing.

Il team di migrazione esegue la prima iterazione. La società sceglie di spostare su Google Cloud sia i casi d'uso relativi a profitti e perdite sia quelli di marketing 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ò disporre di una potenza di calcolo quasi illimitata e, di conseguenza, viene eseguita molto più velocemente rispetto alla versione on-premise. La pipeline scrive i dati mensili sulle 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. Accelerare una pipeline di dati complessa utilizzando un approccio di reindirizzamento.

Sebbene Google Cloud abbia risolto i problemi relativi al conto economico non funzionante, rimangono ancora problemi di funzionalità. Alcune attività non correlate che precedono il calcolo delle vendite mensili spesso causano errori che impediscono il calcolo e fanno sì che le pipeline dipendenti non possano essere avviate.

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 del conto economico. I passaggi costituiscono un sotto-DAG, come mostrato nel seguente diagramma. Il team di migrazione copia il DAG secondario nella pipeline di marketing in modo che possa essere eseguita indipendentemente dal profitto e dalle perdite. Avere una potenza di calcolo sufficiente in Google Cloud consente di eseguire entrambe le pipeline contemporaneamente.

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

Figura 14. Pipeline in esecuzione contemporaneamente utilizzando un sotto-DAG.

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

In una terza iterazione, il team rivede i casi d'uso ed estrae il DAG secondario mensile delle vendite in una pipeline indipendente. Al termine della nuova pipeline mensile delle vendite, viene attivata o suddivisa in profitti e perdite, crescita del marketing e altre pipeline dipendenti. Questa configurazione crea un nuovo DAG di orchestrazione complessivo, con ciascuna delle pipeline che rappresenta uno dei suoi sotto-DAG.

Ora la pipeline delle vendite mensili è la prima e alimenta la pipeline del profitto e della perdita e la pipeline di marketing.

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

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

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

Passaggi successivi

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

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