Esegui la migrazione delle pipeline di dati

Questo documento descrive come eseguire la migrazione di pipeline di dati a monte, che caricano i dati nel tuo data warehouse. Puoi utilizzare questo documento per comprendere meglio cos'è una pipeline di dati, quali procedure e pattern può essere utilizzata da una pipeline e quali sono le opzioni e le tecnologie per la migrazione di un data warehouse.

Che cos'è una pipeline di dati?

Nell'informatica, una pipeline di dati è un tipo di applicazione che elabora i dati tramite una sequenza di fasi di elaborazione connesse. Come concetto generale, le pipeline di dati possono essere applicate, ad esempio, al trasferimento di dati tra sistemi informatici, estrazione, trasformazione e caricamento (ETL), arricchimento e 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 viene eseguito o come un processo di streaming che viene eseguito di continuo 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 scrivere i dati nel data warehouse. Ciascuna delle trasformazioni è descritta da una funzione e l'input di ogni funzione specifica è l'output della funzione o delle funzioni precedenti. Queste funzioni collegate sono descritte come un grafico, il cui grafico è spesso definito grafico aciclico diretto (DAG), ossia il grafico segue una direzione (dall'origine alla destinazione) e è aciclico. L'input di qualsiasi funzione non può dipendere dall'output di un'altra funzione a valle del 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 connessioni a sistemi di dati di origine. Le funzioni finali sono sink o connessioni a 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 è denominato DAG del flusso di dati. Puoi anche utilizzare i DAG per orchestrare lo spostamento dei dati tra pipeline di dati e altri sistemi. Questo utilizzo viene chiamato 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 offload o migrazione completa.

Da un lato, quando carichi un caso d'uso, non è necessario eseguire la migrazione preliminare delle pipeline di dati a monte. Esegui prima la migrazione dello schema e dei dati del caso d'uso dal data warehouse esistente a BigQuery. Quindi, stabilisci una copia incrementale dal vecchio al nuovo data warehouse per mantenere i dati sincronizzati. Infine, esegui la migrazione e la convalida di processi a valle come script, query, dashboard e applicazioni aziendali.

A questo punto, le pipeline di dati a monte sono invariate e stanno ancora scrivendo dati nel tuo data warehouse esistente. Puoi includere nuovamente i casi d'uso offload nel backlog della migrazione di cui eseguire la migrazione completa in un'iterazione successiva.

D'altra parte, quando esegui la migrazione completa di un caso d'uso, viene eseguita la migrazione delle pipeline di dati a monte necessarie per il caso d'uso in Google Cloud. La migrazione completa richiede innanzitutto il offload del caso d'uso. Dopo la migrazione completa, puoi ritirare le tabelle precedenti corrispondenti dal data warehouse on-premise perché i dati vengono importati direttamente in BigQuery.

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

  • Scarica il tuo caso d'uso.
  • Eseguire la migrazione completa di un caso d'uso precedentemente caricato.
  • Esegui la migrazione completa di un caso d'uso da zero liberandolo prima nella stessa iterazione.

Una volta eseguita la migrazione di tutti i casi d'uso, puoi scegliere di disattivare il vecchio magazzino, operazione importante per ridurre i costi generali e i costi generali.

Come eseguire la migrazione delle pipeline di dati

Nella parte rimanente di questo documento viene illustrato come eseguire la migrazione delle pipeline di dati, inclusi l'approccio e le procedure da utilizzare e le tecnologie da utilizzare. Le opzioni disponibili spaziano dalla ridistribuzione delle pipeline di dati esistenti (reindirizzandole al 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 in modalità flusso o pipeline di dati in modalità streaming. Le pipeline dei dati in batch vengono eseguite sui 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 nelle modifiche alle righe CDC generate dai database OOL (Online Transaction Processing).

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 della trasformazione eseguito al di fuori del datastore è che richiede l'apprendimento di strumenti e linguaggi aggiuntivi (diversi da SQL) per esprimere le trasformazioni.

Il seguente diagramma mostra una procedura ETL tipica.

Flusso che mostra l'origine (estrazione) verso una o più trasformazioni (trasformazione), quindi in un sink e infine in un data warehouse (carico)

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 dovuti a 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 aggregati o disaggregati. Per ulteriori informazioni, consulta Ciclo ETL reale.

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

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

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

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

Nel diagramma, ogni pipeline di dati è considerata un sub-DAG dell'orchestrazione DAG. Ogni DAG di orchestrazione comprende diverse pipeline di dati per allinearsi all'obiettivo più ampio, ad esempio preparando i dati per un'unità aziendale in modo che gli analisti aziendali possano eseguire le dashboard o i report.

Estrazione, caricamento e trasformazione (ELT)

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

Il seguente diagramma mostra una tipica procedura ELT.

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

Figura 3. In genere una procedura ELT.

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

Quando esegui la migrazione di pipeline di dati da un data warehouse on-premise congestionato al cloud, è importante ricordare che i sistemi di data warehouse su cloud come BigQuery sono tecnologie di elaborazione dei dati molto parallele. Di fatto, nel caso di BigQuery, puoi acquistare più risorse per supportare sia l'aumento delle richieste per ELT sia l'esecuzione di query in parallelo. Per scoprire di più, consulta Introduzione all'ottimizzazione del rendimento delle query.

Estrazione e caricamento (EL)

Puoi utilizzare la procedura extact e load (EL) da sola o seguita da trasformazioni, nel qual caso diventa ELT. EL è menzionata separatamente perché sono disponibili diversi servizi automatizzati per eseguire questa attività, riducendo la necessità di creare pipeline di dati di importazione. Per maggiori dettagli, consulta BigQuery Data Transfer Service.

Modificare l'acquisizione dei dati (CDC)

L'acquisizione dei dati (CDC) è uno dei diversi pattern di progettazione 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 sue modifiche da vari sistemi di origine nel corso del tempo.

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

Flusso ETL che mostra i singoli record con le informazioni sulla versione assegnate all'estrazione e i 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 a valle.

Per rendere efficace 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. 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 crei nuove pipeline di dati, valuta la possibilità di utilizzare il pattern CDC applicato come procedura ELT. Questo approccio garantisce una cronologia completa delle modifiche ai dati a monte e una buona segregazione delle responsabilità, ad esempio:

  • I team del sistema di origine garantiscono la disponibilità dei log e la pubblicazione dei propri eventi di dati.
  • Il team della piattaforma dati garantisce che la fascicolazione di importazione dei record originali includa timestamp nel data warehouse.
  • I team di data engineering e analisti pianificano una serie di trasformazioni per completare i loro data mart.

Feedback loop con pipeline di dati operativi

Le pipeline di dati operativi sono pipeline di elaborazione dati che raccolgono dati dal data warehouse, li trasformano se necessario e scrivono il risultato 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 prodotti (PCM) e così via. Poiché questi sistemi agiscono spesso come fonte di dati, le pipeline di dati operativi implementano un pattern di loop di feedback.

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

Pipeline ETL che inserisce il data warehouse in una pipeline operativa che poi rientra nel sistema di origine che fornisce la pipeline ETL.

Figura 5. Modello 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 autoritativo per le informazioni sui prodotti correlati alle vendite, come colori, canali di vendita, prezzo e stagionalità. Di seguito è riportato il flusso end-to-end dei dati:

  • I dati relativi ai prezzi sono disponibili da più fonti. Questi dati possono includere il prezzo corrente per regione dal PCM, i prezzi della concorrenza da un servizio di terze parti, la previsione della domanda e l'affidabilità del fornitore dai 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 del PCM.
  • Infine, la pipeline operativa prende i prezzi base dal datastore, esegue trasformazioni leggere per adattare i prezzi agli eventi stagionali e scrive i prezzi finali nella 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 implementare entrambe le funzionalità possono sovrapporsi. Ad esempio, puoi utilizzare Dataflow per definire ed eseguire tutti i DAG per l'elaborazione dei dati, SQL standard per definire le trasformazioni eseguite in BigQuery e Cloud Composer per orchestrare il flusso end-to-end dei dati.

Scelta di un approccio di 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, potresti valutare se una tecnologia che utilizzi offre un sink BigQuery incorporato (connettore di scrittura):

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

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

Se la tecnologia delle pipeline di dati non supporta l'importazione dei dati in BigQuery, valuta la possibilità di utilizzare una variazione su questo approccio che scriva i dati temporaneamente in file che vengono successivamente importati da BigQuery.

La pipeline di dati bloccata dal feed nel sistema precedente e feed in BigQuery.

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

A livello generale, il lavoro ha riguardato la riscrittura o la riconfigurazione, l'ultima funzione della pipeline di dati di scrivere dati in BigQuery. Tuttavia, devi affrontare una serie di opzioni che potrebbero richiedere ulteriori modifiche o nuove operazioni, ad esempio:

Funzione

  • Mappature dei dati: poiché lo schema della tabella di database di destinazione potrebbe cambiare, potrebbe essere necessario riconfigurare le mappature.
  • 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 traffico in uscita dai dati on-premise verso BigQuery.
  • Potrebbero essere necessarie modifiche alla rete per creare larghezza di banda aggiuntiva, per supportare il traffico in uscita dai dati.

Reindirizza le pipeline di dati utilizzando i file come veicolo intermedio

Se l'attuale tecnologia della pipeline di dati on-premise non supporta le API di Google o se ti è limitato l'uso delle API di Google, puoi utilizzare i file come veicolo intermedio per i dati per raggiungere BigQuery.

Questo approccio è simile all'approccio basato sul reindirizzamento, ma anziché 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 tuoi dati sono nel tuo file system, copi i file in Cloud Storage. Per maggiori dettagli, consulta la panoramica delle opzioni di importazione per Cloud Storage e i criteri inclusi nella 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 collettivo dei dati.

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

Pipeline ETL che invia i dati a un file system anziché al data warehouse legacy; il file system a sua volta carica il feed in Cloud Storage e poi passa a BigQuery.

Figura 8. Reindirizzamento delle pipeline di dati utilizzando i file come mezzo 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 tuo 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 di Cloud Storage per pianificare i caricamenti ricorrenti da Cloud Storage a BigQuery. Le alternative ai trasferimenti di Cloud Storage sono attivatori di Cloud Storage e Cloud Composer.

Nella Figura 8, puoi notare come sia possibile per l'orchestrazione su Google Cloud utilizzare un modello pull recuperando i file usando 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 tuo data warehouse e la parte che li trasforma utilizzando SQL in modo che possa essere consumata a valle. Quando esegui la migrazione delle pipeline ELT, ognuna di queste parti ha il proprio approccio per la migrazione.

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

Se le tue origini dati sono supportate da BigQuery Data Transfer Service (DTS) direttamente o tramite integrazioni di terze parti, puoi utilizzare DTS per sostituire la tua pipeline EL. Una soluzione Five mostra in che modo i connettori Fivetran possono aiutarti durante la migrazione, estraendo automaticamente i dati dalle tue origini, normalizzando e applicando una leggera pulizia ai dati e quindi inviandoli a BigQuery.

Migrazione di pipeline di dati OSS esistenti a Dataproc

Quando esegui la migrazione della pipeline di dati in Google Cloud, può essere opportuno eseguire la migrazione di alcuni job legacy scritti con un framework software open source come Apache Hadoop, Apache Spark o Apache Flink.

Dataproc consente di eseguire il deployment di cluster Hadoop e Spark gestiti, veloci e facili da usare in modo semplice e conveniente. 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 InputFormat e OutputFormat di Apache Hadoop.

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

  • Puoi utilizzare diverse configurazioni dei cluster per i singoli job, eliminando l'onere amministrativo della gestione degli strumenti tra i job.
  • Puoi scalare i cluster in base ai singoli job o gruppi di job.
  • Paghi solo per le risorse che 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 sviluppo, test e produzione. Puoi utilizzare le stesse definizioni per creare tutte le diverse versioni di un cluster che ti servono, quando ne hai bisogno.

Quando esegui la migrazione dei job, ti consigliamo di adottare un approccio incrementale. La migrazione incrementale consente di:

  • Isolare i singoli job nell'infrastruttura Hadoop esistente dalla complessità intrinseca in un ambiente maturo.
  • Esaminare ogni job in maniera isolata per valutare le sue esigenze e determinare il percorso migliore per la migrazione.
  • Gestisci i problemi imprevisti che si verificano senza ritardare le attività dipendenti.
  • Crea una proof of concept per ogni processo complesso senza influire sull'ambiente di produzione.
  • Sposta i job nel modello temporaneo consigliato in modo intelligente e ponderato.

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

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

Ospitare pipeline di dati di terze parti da eseguire 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 trasferire queste pipeline nel cloud, hai a disposizione diverse alternative, a seconda delle funzionalità del software che utilizzi e anche a seconda dei termini di licenza, assistenza e manutenzione.

Le seguenti sezioni presentano alcune di queste alternative.

A livello generale, hai le seguenti alternative per eseguire il tuo software di terze parti in Google Cloud, dal meno complesso al più complesso:

  • 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 in Kubernetes.
  • Il software di terze parti viene eseguito su una o più macchine virtuali (VM).

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

Questa alternativa è la più semplice perché esegui l'onboarding delle tue 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 quello nuovo su Google Cloud.

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

  • Crea un cluster GKE seguendo i consigli del tuo fornitore, per assicurarti che il prodotto di terze parti possa sfruttare il caricamento delle attività offerto da Kubernetes.
  • Installa il software di terze parti sul 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 su BigQuery: panoramica.

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

Se il tuo fornitore non supporta Kubernetes, devi installare il suo software su un pool di VM per abilitare lo scale out e il caricamento in contemporanea del lavoro. Se il software del tuo fornitore supporta in modo nativo la distribuzione del lavoro a diverse VM, utilizza le strutture fornite, raggruppando eventuali istanze VM in un gruppo di istanze gestite (MIG) per fare lo scale in e lo scale out in base alle esigenze.

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

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

Figura 9. Un gruppo di istanze gestite (MIG) 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. Crei un semplice agente da installare in ogni VM. L'agente è in ascolto di uno o più argomenti Pub/Sub. Ogni volta che un messaggio arriva nell'argomento, l'agente estrae il messaggio dall'argomento, avvia una pipeline nel software di terze parti e ne ascolta il completamento. Al 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 tue 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 tue pipeline di dati esistenti per utilizzare nuovi framework e servizi completamente gestiti su Google Cloud. Questa opzione è utile se le pipeline esistenti sono state implementate in origine con tecnologie deprecate o se prevedi che la portabilità e la continuità di mantenere tali pipeline non modificate nel cloud sarebbero troppo irpratiche o proibitive.

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

Cloud Data Fusion

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

Le pipeline di dati vengono sviluppate nell'interfaccia utente di Cloud Data Fusion connettendo le origini a trasformazioni, sink e altri nodi per formare un DAG. Quando esegui il deployment della pipeline di dati, 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 Cloud Data Fusion e configurarlo in modo da poterlo utilizzare nelle tue pipeline di dati. Per ulteriori dettagli, consulta la guida all'utilizzo dei driver JDBC con Cloud Data Fusion.

Cloud Data Fusion espone plug-in per origini, trasformazioni, aggregazioni, sink, raccoglitori di errori, publisher degli avvisi, azioni e azioni post-esecuzione come componenti personalizzabili. I plug-in predefiniti consentono l'accesso a un'ampia gamma di origini dati. Se un plug-in non esiste, puoi creare il tuo plug-in utilizzando le API plug-in 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 offrono anche agli amministratori modi per 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 per le 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 offre un set all'avanguardia di primitive per finestre e analisi delle sessioni, nonché un ecosistema di connettori di origine e sink, tra cui un connettore per BigQuery. Apache Beam ti consente di trasformare e arricchire i dati in modalità flusso (in tempo reale) e batch (cronologica) con uguale affidabilità ed espressività.

L'approccio serverless di Dataflow rimuove l'overhead operativo con prestazioni, scalabilità, disponibilità, sicurezza e conformità gestite automaticamente. Ciò ti consente di concentrarti sulla programmazione anziché sulla gestione dei cluster di server.

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

Se vuoi eseguire la migrazione di query e pipeline di dati da altri framework ad Apache Beam e Dataflow, leggi informazioni sul modello di programmazione 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 per pianificazione si intende l'attivazione automatica del lavoro di orchestrazione.

  • Aumenta lo zoom: una pipeline di dati è di per sé un'orchestrazione di trasformazioni di dati descritte da un DAG, che è un DAG per l'elaborazione dei dati.
  • Diminuisci lo zoom: quando una pipeline di dati dipende dall'output di altre pipeline di dati, è necessaria l'orchestrazione di più pipeline. Ogni pipeline rappresenta un DAG secondario in un DAG più grande, che è un DAG di orchestrazione.

Questa configurazione è tipica nel data warehousing. La Figura 1 della sezione EET mostra un esempio di configurazione. Le seguenti sezioni si concentrano sull'orchestrazione di diverse pipeline di dati.

Dipendenze

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

Più pipeline etichettate A, B e C si connettono alla pipeline D. La pipeline D si estende alle pipeline E, F e G. Tutto questo è orchestrato da un DAG di orchestrazione.

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

In ambienti non ottimali, alcune dipendenze sono dovute a limitazioni nella quantità di risorse disponibili. Ad esempio, una pipeline di dati esegue e produce alcuni dati comuni come sottoprodotto. Altre pipeline di dati dipendono da questi dati comuni semplicemente per evitare di ricalcolarli, ma non sono correlati alla pipeline di dati che ha creato i dati. Se questa prima pipeline presenta problemi funzionali o non funzionali, gli errori passano a livello di pipeline di dati dipendenti, nella migliore delle ipotesi, obbligandoli ad attendere o, peggio, a impedirne l'esecuzione, come mostrato nel diagramma seguente.

Si verifica un errore nella pipeline A. Le pipeline B e C dipendono dall'output della pipeline A, quindi si arrestano in modo errato.

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

In Google Cloud, hai a disposizione un'ampia gamma di risorse di calcolo e strumenti specializzati per consentirti di ottimizzare l'esecuzione delle tue pipeline e della loro orchestrazione. Le sezioni seguenti illustrano queste risorse e questi strumenti.

Lavori di migrazione coinvolti

È una best practice 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 un'opportunità di esaminare i tuoi DAG di orchestrazione, identificare le tue dipendenze e determinare come ottimizzarle.

Ti consigliamo di ottimizzare le dipendenze in modo incrementale, procedendo come segue:

  1. Con una prima iterazione, sposta l'orchestrazione così come è in Google Cloud.
  2. Nelle iterazioni successive, analizza le tue dipendenze e caricale in contemporanea, se possibile.
  3. Infine, riorganizza la tua orchestrazione estraendo attività comuni nei propri DAG.

Nella sezione successiva viene illustrato questo metodo con un esempio pratico.

Un esempio pratico

Supponiamo che un'organizzazione abbia due pipeline correlate:

  • La prima pipeline calcola i profitti e le perdite (P&amp) L per l'intera organizzazione. Si tratta di una pipeline complessa che comporta molte trasformazioni. Parte della pipeline consiste nel calcolare le vendite mensili, che vengono utilizzate nei passaggi di trasformazione successivi e alla fine scritte in una tabella.
  • La seconda pipeline calcola la crescita su base annua e mensile delle vendite per i diversi prodotti, in modo che il reparto marketing possa ottimizzare le sue attività relative alle campagne pubblicitarie. Questa pipeline richiede i dati sulle vendite mensili calcolati in precedenza dalla pipeline di dati P&L.

L'organizzazione considera la pipeline di dati P&L 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&amp non riesce, la pipeline di marketing e le altre pipeline dipendenti non dispongono dei dati richiesti per poter essere eseguite e devono attendere un nuovo tentativo di P&L. Il seguente diagramma illustra questa situazione.

La pipeline P&L crea un "artefatto di vendita mensile" necessario per la pipeline di marketing. La pipeline P&amp potrebbe riscontrare ritardi e altri problemi.

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

È in corso la migrazione a BigQuery dell'organizzazione. che ha identificato i due casi d'uso, P&amp 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 P&L e la include nel backlog di iterazione perché è gravemente limitata dalle attuali risorse on-premise e causa regolarmente ritardi. Sono inclusi anche alcuni dei casi d'uso dipendenti, tra cui il caso d'uso di marketing.

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

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

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

Sebbene Google Cloud abbia contribuito alla risoluzione dei problemi di P&amp non funzionali, i problemi di funzionamento rimangono invariati. Alcune attività non correlate che precedono il calcolo delle vendite mensili spesso causano errori che impediscono tale calcolo e rendono impossibile l'avvio delle pipeline dipendenti.

Con una seconda iterazione, il team spera di migliorare le prestazioni includendo entrambi i casi d'uso nel backlog di iterazione. Il team identifica i passaggi della pipeline per calcolare le vendite mensili nella pipeline P&L. I passaggi costituiscono un sub-DAG, come mostrato nel diagramma successivo. Il team di migrazione copia il sub-DAG nella pipeline di marketing in modo che possa essere eseguito indipendentemente da P&L. Avere una potenza di calcolo sufficiente in Google Cloud consente a entrambe le pipeline di essere eseguite contemporaneamente.

La pipeline P&amp 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&amp.L.

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

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

Con una terza iterazione, il team riesamina i casi d'uso ed estrae il sub-DAG delle vendite mensili in una pipeline indipendente. Quando la nuova pipeline di vendita mensile sarà disponibile, si attiverà o si diffonderà nel P&amp, nella crescita del marketing e in altre pipeline dipendenti. Questa configurazione crea un nuovo DAG di orchestrazione generale, in cui ogni pipeline è uno dei suoi DAG secondari.

La pipeline di vendita mensile è ora la prima a essere integrata nella pipeline P&amp e a quella di marketing.

Figura 15. DAG complessivo di orchestrazione con ciascuna pipeline nel proprio DAG secondario.

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

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

Passaggi successivi

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

Puoi anche passare al passaggio da tecnologie di data warehouse specifiche a BigQuery: