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?

Nel campo dell'informatica, pipeline di dati è un tipo di applicazione che elabora i dati attraverso una sequenza di fasi di elaborazione. 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 sono gestiti come un processo batch che esegue ed elabora i dati quando vengono eseguiti come un processo di flussi di dati che viene eseguito continuamente ed elabora i dati così come sono disponibile 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. Ciascun nodo del grafico è una funzione e ogni bordo rappresenta il flusso di dati da una funzione all'altra. Le funzioni iniziali sono origini o collegamenti ai sistemi di dati di origine. Le funzioni finali sono sink, o collegamenti con i 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 i dati il movimento tra 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 offload o eseguire 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 creare una copia incrementale dal vecchio al nuovo data warehouse per mantenere sincronizzati con i dati. Infine, esegui la migrazione e la convalida dei processi downstream come script, query, dashboard e applicazioni aziendali.

A questo punto, le pipeline di dati upstream non sono state modificate e stanno ancora scrivendo i dati nel tuo data warehouse esistente. Puoi includere i casi d'uso scaricati in eseguire di nuovo la migrazione completa del backlog iterazione.

D'altra parte, quando esegui la migrazione completa di un caso d'uso, viene eseguita la migrazione in Google Cloud delle pipeline di dati richieste per il caso d'uso. Completo per la migrazione richiede prima di tutto 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 il offload solo del tuo caso d'uso.
  • Esegui la migrazione completa di un caso d'uso di cui è stato precedentemente eseguito l'offload.
  • Esegui la migrazione completa di un caso d'uso da zero 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 illustra come eseguire la migrazione delle pipeline di dati, tra cui l'approccio e le procedure da usare e le tecnologie da impiegare. Le opzioni variano dal riutilizzo di pipeline di dati esistenti (reindirizzandole al caricamento a BigQuery) per riscrivere le pipeline di dati in modo da e i vantaggi dei 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. Tu potrebbe avere pipeline di dati in batch o pipeline di dati in flussi. Dati in batch le pipeline vengono eseguite su dati raccolti in un periodo di tempo (ad esempio, una volta al giorno). Le pipeline di dati in modalità flusso gestiscono gli eventi in tempo reale generati dai tuoi sistemi operativi, ad esempio CDC modifiche alle righe generate dai database di elaborazione delle transazioni online (OLTP).

Estrai, trasforma e carica (ETL)

Nel contesto del data warehousing, le pipeline di dati spesso eseguono un'estrazione, con una procedura ETL (Transform and Load). le tecnologie ETL vengono eseguite al di fuori dei dati un data warehouse, il che significa che le risorse del data warehouse utilizzata principalmente per le query in parallelo, invece che per la preparazione e la trasformazione e i dati di Google Cloud. 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 va a una o più trasformazioni (trasformazione), quindi a un sink e infine a un data warehouse (caricamento)

Figura 1. Una tipica procedura ETL.

Una tipica pipeline di dati ETL estrae i dati da uno o più sistemi di origine (preferibilmente il 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 dei dati l'integrità e creare 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. Pipeline successive applicare la logica di business e trasformare i dati per l'uso in vari data mart, ovvero sottoinsiemi del data warehouse incentrati su una specifica unità aziendale obiettivo aziendale.

Quando hai più pipeline di dati, devi orchestrarle. Il seguente diagramma mostra come potrebbe essere questo processo di orchestrazione Mi piace.

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 per allinearsi uno scopo più ampio, ad esempio preparare i dati per un'unità aziendale in modo che i business analyst possono eseguire le proprie dashboard o i propri report.

Estrazione, caricamento e trasformazione (ELT)

ELT è un'alternativa all'ETL. Con l'ELT, la pipeline di dati è suddivisa in due parti. In primo luogo, una tecnologia ELT estrae i dati dal sistema di origine e lo carica nel data warehouse. Secondo, gli script SQL sopra i dati nel warehouse di eseguire le trasformazioni. Il vantaggio di questo approccio è che puoi utilizzare SQL per esprimere le trasformazioni; il rovescio della medaglia è che questo potrebbe consumare risorse del data warehouse necessarie per le query simultanee. Per questo motivo, i batch ELT vengono spesso eseguiti durante la 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 va a una o più trasformazioni (trasformazione), quindi a un sink 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 nei rispettivi DAG. 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 maggiori informazioni informazioni, consulta Introduzione all'ottimizzazione delle prestazioni 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. EL è menzionata separatamente perché sono disponibili vari servizi automatici che eseguono riducendo la necessità di creare i propri dati di importazione. una pipeline o un blocco note personalizzato. Per ulteriori dettagli, vedi 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 warehouse 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 ELT perché vuoi archiviare il record originale prima le 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. Quindi puoi utilizzare una query SQL per determinare la versione più recente prima per l'applicazione di 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. In questo modo, avrai a disposizione cronologia completa delle modifiche dei dati a monte e fornisce una buona separazione dei 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.

Ciclo di feedback con le pipeline di dati operative

Le pipeline di dati operativi sono pipeline di elaborazione dati che prendono i dati il data warehouse, trasformarlo se necessario e scrivere il risultato 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 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 seguente diagramma.

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

Figura 5. Pattern per una pipeline di dati operativi.

L'esempio seguente descrive una pipeline di dati operativi che scrive un prodotto 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 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 scrive il risultato nel data warehouse. In questo caso, la trasformazione è un calcolo complesso che coinvolge tutte le origini con l'obiettivo di produrre un prezzo base ottimale per ogni prodotto nel PCM.
  • Infine, la pipeline operativa prende i prezzi base dal data warehouse, esegue trasformazioni leggere per adeguare i prezzi agli eventi stagionali e riscrivi i prezzi finali nel PCM.

Inserimento del sistema PCM nel sistema ETL.

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

Una pipeline di dati operativi è un tipo di processo 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 dati, GoogleSQL per definire le trasformazioni da eseguire all'interno di BigQuery Cloud Composer per orchestrare il flusso di dati end-to-end.

Scelta di un approccio alla migrazione

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

Reindirizza le pipeline di dati per scrivere 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.

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

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

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

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

A livello generale, il lavoro consiste nel riscrivere, o riconfigurare, l'ultima funzione della pipeline di dati per scrivere dati in BigQuery. Tuttavia, hai a disposizione una serie di opzioni che potrebbero richiedere modifiche aggiuntive o nuovo lavoro, ad esempio:

Funzionale

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

Non funzionale

  • Potrebbe essere necessario configurare firewall per consentire il trasferimento di dati in uscita da on-premise a BigQuery.
  • Potrebbero essere necessarie modifiche alla rete per creare larghezza di banda aggiuntiva per gestire il trasferimento di 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 al reindirizzamento, ma invece di utilizzare una un sink nativo in grado di scrivere in BigQuery, devi utilizzare un sink che scrivere in un file system on-premise. Quando i dati sono nel file system, copia i file in Cloud Storage. Per ulteriori dettagli, consulta Panoramica delle opzioni di importazione per Cloud Storage e i criteri necessari per scegliere un'opzione di importazione.

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

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

Pipeline ETL che alimenta un file system anziché il data warehouse precedente; il file system a sua volta alimenta Cloud Storage e da qui BigQuery.

Figura 8. Reindirizzamento delle pipeline di dati utilizzando i file come intermedio veicolo.

Per quanto riguarda l'orchestrazione della pipeline ETL, devi eseguire due passaggi distinti:

  1. Riutilizza l'orchestrazione della pipeline on-premise esistente per scrivere trasformati i dati 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 si trovano in Cloud Storage, utilizza una Trasferimento di Cloud Storage per pianificare caricamenti ricorrenti da Cloud Storage in BigQuery. Le alternative ai trasferimenti di Cloud Storage sono gli attivatori Cloud Storage e Cloud Composer.

Nella Figura 8, nota come sia possibile anche per l'orchestrazione a Google Cloud di utilizzare un modello pull recuperando i file tramite 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, ciascuna di queste parti ha i propri il proprio approccio alla migrazione.

Per la parte che carica i dati nel data warehouse (la parte EL), puoi seguire le linee guida in pipeline di dati di reindirizzamento meno i consigli sulle trasformazioni, che non fanno parte di una una pipeline o un blocco note personalizzato.

Se le tue origini dati sono supportate BigQuery Data Transfer Service (DTS) direttamente o tramite integrazioni di terze parti, puoi usare DTS per sostituire la tua pipeline EL.

Migrazione di pipeline di dati OSS esistenti a Dataproc

Quando esegui la migrazione della tua pipeline di dati su Google Cloud, potrebbe essere utile eseguire la migrazione di alcuni job legacy scritti con un software open source un framework simile 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 a BigQuery utilizzando versioni astratte di Apache Hadoop InputFormat e OutputFormat .

Dataproc semplifica la creazione e l'eliminazione dei cluster in modo che puoi usare molti cluster temporanei invece di un unico cluster monolitico. 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.
  • Creare una proof of concept per ogni processo complesso senza influire dell'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, valuta creando una tua immagine Dataproc, usando alcune delle soluzioni azioni di inizializzazione (ad esempio, per Apache Flink), scrivere una tua azione di inizializzazione oppure specificando i requisiti del pacchetto Python personalizzato.

Per iniziare, consulta le guide di avvio rapido di Dataproc e gli esempi di codice del connettore BigQuery. Consulta anche le guide su migrazione di job Hadoop da on-premise a Dataproc e migrazione dei job Apache Spark 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 che utilizzi e anche dei termini di licenza, assistenza e manutenzione.

Le sezioni seguenti presentano alcune di queste alternative.

A livello generale, hai le seguenti alternative per l'esecuzione dei tuoi software di terze parti in Google Cloud, dal meno al più complesso:

  • Il tuo fornitore di software ha collaborato con Google Cloud per offrire il proprio software Google Cloud Marketplace.
  • Il tuo fornitore di software di terze parti può essere eseguito su Kubernetes
  • Il software di terze parti viene eseguito su una o più macchine virtuali (VM).

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

Questa alternativa è la più semplice perché l'onboarding delle pipeline di dati avviene nel cloud utilizzando la piattaforma familiare del 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 di Cloud Marketplace, ma può essere eseguito su Kubernetes, puoi utilizzare Google Kubernetes Engine (GKE) per ospitare le tue pipeline. Si tratta del seguente lavoro:

  • Crea un cluster GKE seguendo i consigli del fornitore per fare in modo che Il prodotto di terze parti può sfruttare il caricamento in contemporanea delle attività Kubernetes offre.
  • 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.

Gestire la parallelizzazione dell'opera non è banale. Se il fornitore non per fornire funzionalità per la distribuzione di attività su VM diverse, consigliamo di usare un pattern di attività di gestione per distribuire il lavoro alle VM in un gruppo di istanze gestite. Il seguente diagramma illustra questo approccio.

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

Figura 9. Un gruppo di istanze gestite 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. Quando la pipeline viene completata, 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, potresti scegliere di riscrivere alcune pipeline di dati esistenti di 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 sezioni seguenti 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 su modelli open source CDAP progetto, è un servizio di integrazione dei dati completamente gestito per la creazione e la gestione tramite un'interfaccia grafica.

Puoi sviluppare le pipeline di dati nella UI di Cloud Data Fusion connettendo da 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 avere per caricare un driver JDBC sull'istanza Cloud Data Fusion e configurarla in modo da poterla 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, 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 Panoramica dei plug-in.

Con le pipeline Cloud Data Fusion puoi creare pipeline di dati sia in batch che in streaming. Fornendo accesso a log, metriche, dati le pipeline offrono anche agli amministratori modi per rendere operativi i loro dati l'elaborazione dei flussi di lavoro 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 Apache Beam di job su larga scala. Apache Beam è un framework open source che fornisce un ricco set di windowing e primitive di analisi delle sessioni, nonché un ecosistema di risorse e connettori sink, tra cui 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 elimina l'overhead operativo con prestazioni, scalabilità, disponibilità, sicurezza e conformità automaticamente. Questo ti permette di concentrarti sulla programmazione anziché sulla gestione cluster.

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

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 di Dataflow. e tutorial.

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.

  • Aumento dello zoom: una pipeline di dati è di per sé un'orchestrazione di dati trasformazioni descritte da un DAG, che è un DAG di elaborazione 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. Figura 1 nella Sezione ETL mostra un esempio di impostazione. Le seguenti sezioni si concentrano sull'orchestrazione diverse pipeline di dati.

Dipendenze

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

Più pipeline etichettate con A, B e C a ventaglio nella pipeline D. La pipeline D si dirama verso le pipeline E, F e G. Tutto questo viene orchestrato da un DAG di orchestrazione.

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

In ambienti non ottimali, alcune dipendenze sono il risultato di limitazioni la quantità di risorse disponibili. Ad esempio, una pipeline di dati esegue produce alcuni dati comuni come sottoprodotto. Altre pipeline di dati dipendono da questo dati comuni semplicemente per evitare di ricalcolarli, ma non sono correlati ai dati che ha creato i dati. Se questa prima pipeline incontra o non funzionali, gli guasti si applicano ai dati dipendenti le pipeline, nella migliore delle ipotesi, obbligarle ad attendere o, nel peggiore dei casi, impedirne il funzionamento funziona, come illustrato nel diagramma seguente.

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

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

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

Attività di migrazione necessarie

È consigliabile semplificare le esigenze di orchestrazione. La tua orchestrazione aumenta la complessità con il numero di dipendenze tra i dati pipeline di dati. La migrazione a Google Cloud offre l'opportunità di esaminare dei DAG di orchestrazione, identificare le dipendenze e determinare come per ottimizzare queste dipendenze.

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 caricale in contemporanea se fattibile.
  3. Infine, riorganizza l'orchestrazione estraendo le attività comuni in i propri 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. È una pipeline complessa che coinvolge 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 i dati su base annua e mensile di crescita delle vendite di diversi prodotti in modo che il reparto marketing possa ottimizzare le iniziative della sua campagna pubblicitaria. 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 P&L non funziona, la pipeline di marketing e altre pipeline dipendenti non hanno i dati necessari per l'esecuzione, deve attendere un nuovo tentativo di P&L. Il seguente diagramma illustra questa situazione.

La pipeline P&L crea una "vendita mensile" l'artefatto richiesto per la pipeline di marketing. La pipeline P&L può presentare ritardi e altri problemi.

Figura 12. Le pipeline di dati complesse possono impedire a pipeline a bassa priorità in esecuzione.

L'organizzazione sta eseguendo la migrazione a BigQuery. Ha identificato due casi d'uso (P&L e crescita delle vendite di marketing) e li ha inclusi nella migrazione arretrato. 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 casi d'uso dipendenti, tra questi il caso d'uso del 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. Un'importante la differenza è che ora la pipeline P&L può disporre di risorse di computing quasi illimitate ed è quindi molto più veloce rispetto a quello 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 impedire l'avvio delle pipeline dipendenti.

In una seconda iterazione, il team spera di migliorare le prestazioni includendo sia e i casi d'uso nel backlog di iterazione. Il team identifica i passaggi della pipeline da 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 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, quindi la pipeline di marketing non è più interessata in caso di problemi nella pipeline P&L.

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

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 riesamina i casi d'uso ed estrae i dati mensili di vendita tramite DAG in una pipeline indipendente. Quando le nuove vendite mensili una pipeline completa, innesca o favorisce il ritorno economico, la crescita del marketing da altre pipeline dipendenti. Questa configurazione crea un nuovo insieme di orchestrazione dei dati, in cui ciascuna pipeline è uno dei suoi DAG secondari.

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 DAG secondari in modo nativo, questa funzionalità potrebbe limitare le sue prestazioni. Di conseguenza sconsigliati. Al loro posto, utilizza DAG indipendenti con TriggerDagRunOperator dell'operatore telefonico.

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: