Esegui la migrazione delle pipeline di dati

Questo documento descrive come eseguire la migrazione pipeline di dati a monte, che caricano i dati nel tuo 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 disponibili per un data warehouse migrazione.

Che cos'è una pipeline di dati?

Nel settore dell'informatica, pipeline di dati è un tipo di applicazione che elabora i dati attraverso una sequenza di fasi di elaborazione. In generale, le pipeline di dati possono essere applicate, ad esempio al trasferimento di dati tra sistemi di informazione, estrarre, trasformare e caricare (ETL), arricchimento dei dati e 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 provenienti da sistemi transazionali, applicare trasformazioni e scrivere dati e il data warehouse. Ognuna delle trasformazioni è descritta da una funzione e l'input per una determinata funzione è l'output della funzione precedente o funzioni. Queste funzioni collegate sono descritte come un grafico e il grafico spesso definito come Grafo diretto aciclico (DAG), ovvero il grafico segue una direzione (dall'origine alla destinazione) e è aciclico: l'input per qualsiasi funzione non può dipendere dall'output di un'altra funzione a valle nel DAG. In altre parole, i loop non sono consentiti. Ciascun nodo del grafico è una funzione e ogni bordo rappresenta il flusso di dati da una funzione all'altra. Le funzioni iniziali sono sorgenti o collegamenti con i 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 di solito sistemi transazionali, ad esempio RDBMS, e il sink si connette a un data warehouse. Questo tipo di grafico viene 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 è indicato come un'orchestrazione o un DAG di flusso di controllo.

Quando eseguire la migrazione delle pipeline di dati

Quando esegui la migrazione di un caso d'uso a BigQuery, puoi scegliere offload o eseguire la migrazione completa.

Da un lato, quando si scarica un caso d'uso, non è necessario eseguire la migrazione le pipeline di dati a monte in anticipo. Innanzitutto, esegui la migrazione dello schema 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. Al termine della migrazione, puoi ritirare le tabelle legacy corrispondenti dai dati on-premise poiché i dati vengono importati direttamente in BigQuery.

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

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

Una volta completata la migrazione di tutti i casi d'uso, puoi scegliere di disattivare magazzino, il che è un passo importante per ridurre i costi generali e i costi.

Come eseguire la migrazione delle pipeline di dati

Il resto di questo documento illustra come eseguire la migrazione delle pipeline di dati, 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 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, e la 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. Un aspetto negativo della trasformazione eseguita al di fuori dei dati di Google Cloud è che richiede l'apprendimento di strumenti e linguaggi aggiuntivi (diverso da SQL) per esprimere le trasformazioni.

Il seguente diagramma mostra una tipica procedura ETL.

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

Figura 1. Una tipica procedura ETL.

Una tipica pipeline di dati ETL estrae i dati da uno o più sistemi di origine (preferibilmente il meno possibile per evitare errori causati da problemi quali 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, vedi Ciclo ETL reale.

È comune avere più pipeline di dati. La prima pipeline si concentra copiando i 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 orchestrare che li rappresentano. Il seguente diagramma mostra come potrebbe essere questo processo di orchestrazione Mi piace.

Orchestrator (DAG) che gestisce due processi ETL (DAG secondari)

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

Nel diagramma, ciascuna pipeline di dati è considerata un sub-DAG dell'orchestrazione con il DAG. 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 ELT, la pipeline di dati è divisa 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. L'aspetto positivo di questo approccio è che puoi usare SQL per esprimere le trasformazioni; Lo svantaggio è che questo potrebbe e consumano le risorse del data warehouse necessarie per le query simultanee. Per Per questo motivo, i batch ELT spesso vengono eseguiti di notte (o al di fuori dei periodi di picco) le risorse di sistema del warehouse sono meno richieste.

Il seguente diagramma mostra una tipica procedura ELT.

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

Figura 3. Una tipica procedura ELT.

Quando adotti un approccio ELT, capita di separare l'estrazione e il caricamento in un DAG e le trasformazioni nei rispettivi DAG. I dati vengono caricati data warehouse una volta e poi trasformato più volte per creare utilizzate a valle nei report e così via. Questi DAG a loro volta diventano sub-DAG in un DAG di orchestrazione più grande (come mostrato sezione ETL).

Quando esegui la migrazione delle pipeline di dati da un data warehouse on-premise congestionato nel cloud, è importante ricordare che i sistemi di data warehouse su cloud come BigQuery sono tecnologie di elaborazione dei dati molto parallele. Nel Nel caso di BigQuery, puoi acquistare altre risorse supportano sia le crescenti richieste di ELT sia le query simultanee. Per ulteriori informazioni informazioni, consulta Introduzione all'ottimizzazione delle prestazioni delle query.

Estrai e carica (EL)

Puoi utilizzare la procedura Extact and Load (EL) autonomamente o seguita trasformazioni in ELT. In questo 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 vari pattern di progettazione di software utilizzati per tenere traccia delle modifiche ai dati. È spesso utilizzato nel data warehousing perché viene utilizzato per raccogliere e monitorare i dati e le relative modifiche dai vari sistemi di origine nel tempo.

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

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

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

CDC funziona bene con ELT perché vuoi archiviare il record originale prima le modifiche a valle.

Affinché la parte EL avvenga, puoi elaborare i log del database utilizzando il 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 la creazione di nuove pipeline di dati, valuta la possibilità di utilizzare la CDC pattern 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 del sistema di origine assicurano la disponibilità dei loro log e della loro pubblicazione dei loro eventi di dati.
  • Il team della piattaforma dati si assicura che la regola di confronto delle importazioni e includono i timestamp nel data warehouse.
  • I team di data engineering e analisti programmano una serie di trasformazioni per popolare i propri 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.

Sistemi operativi si riferiscono ai sistemi che elaborano le transazioni quotidiane dell'organizzazione, come come database OLTP, sistemi di gestione dei rapporti con i clienti (CRM), prodotti sistemi di gestione dei cataloghi (PCM) e così via. Perché questi sistemi spesso agiscono come una fonte di dati, le pipeline di dati operativi implementano un loop di feedback .

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

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

Figura 5. Pattern per una pipeline di dati operativa.

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

  • I dati relativi ai prezzi sono disponibili da più fonti. Questi dati possono includono il prezzo corrente per regione del PCM, i prezzi della concorrenza servizio di terze parti, previsione della domanda e affidabilità del fornitore, 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 produrre un prezzo base ottimale per ogni prodotto nel PCM.
  • Infine, la pipeline operativa prende i prezzi base dai dati di magazzino, esegue piccole trasformazioni per adeguare i prezzi per le eventi e scrive i prezzi finali nel PCM.

Inserimento del sistema PCM nel sistema ETL.

Figura 6. Una pipeline di dati operativa che scrive i prezzi dei prodotti in una Sistema PCM.

Una pipeline di dati operativa è un tipo di processo a valle, mentre i dati che implementano le pipeline ETL ELT o CDC sono processi upstream. Tuttavia, gli strumenti utilizzati per implementare entrambi che si sovrappongono. 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, valuta se la tecnologia che utilizzi offre un sink BigQuery integrato (connettore di scrittura):

  • Il data warehouse legacy è alimentato da pipeline di dati che eseguono ETL .
  • La logica di trasformazione viene eseguita prima che i dati archiviati 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 dati per BigQuery, valuta la possibilità di utilizzare variazione di questo approccio che scrive temporaneamente i dati in file che vengono successivamente importati in 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, devi affrontare una serie di opzioni che potrebbero richiedere ulteriori modifiche o lavori nuovi, ad esempio:

Funzionale

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

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 supportare il trasferimento di dati in uscita.

Reindirizza le pipeline di dati utilizzando i file come veicolo intermedio

Quando la tecnologia esistente della pipeline di dati on-premise non supporta Google o se non puoi utilizzare le API di Google, puoi utilizzare i file come veicolo intermedio che consente ai tuoi 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, e copio 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 legacy; il file system a sua volta alimenta Cloud Storage e da lì in 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 separati:

  1. Riutilizza l'orchestrazione della pipeline on-premise esistente per scrivere trasformati i dati nel file system. Estendi questa orchestrazione alla copia i file dal tuo file system on-premise a Cloud Storage, creare uno script aggiuntivo che viene 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. Alternative ai trasferimenti di Cloud Storage sono Trigger di 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 composte da due parti: quella che carica i dati nei tuoi dati il data warehouse e la parte che trasforma i dati mediante SQL in modo che consumate downstream. 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 utilizzare DTS per sostituire la pipeline EL.

Migrazione di pipeline di dati OSS esistenti a Dataproc

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

Dataproc consente di eseguire il deployment di cluster Hadoop e Spark veloci, facili da usare e completamente gestiti in un 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 offre diversi vantaggi:

  • Puoi utilizzare configurazioni di cluster diverse per singoli job, eliminando l'onere amministrativo della gestione degli strumenti tra i job.
  • Puoi scalare i cluster per adattarli a singoli job o gruppi di job.
  • Paghi solo per le risorse quando i tuoi job le utilizzano.
  • Non è necessario gestire i cluster nel tempo, perché sono sempre e configurazione a ogni utilizzo.
  • Non è necessario mantenere un'infrastruttura separata per lo sviluppo, test e produzione. Puoi utilizzare le stesse definizioni per creare più 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. Con la migrazione incrementale puoi:

  • Isola i singoli job nell'infrastruttura Hadoop esistente dal intrinseca in un ambiente maturo.
  • Esaminare ogni job in modo isolato per valutarne le esigenze e determinare il percorso migliore per la migrazione.
  • Gestisci i problemi imprevisti nel momento in cui si presentano senza ritardare le attività dipendenti.
  • Creare una proof of concept per ogni processo complesso senza influire dell'ambiente di produzione.
  • Sposta i tuoi job nel modello temporaneo consigliato in modo ponderato e deliberatamente.

Quando esegui la migrazione dei job Hadoop e Spark esistenti a Dataproc, puoi verificare che i tuoi job e le dipendenze sono coperte dal team di assistenza Versioni di Dataproc. Se devi installare software personalizzato, valuta creando una tua immagine Dataproc, usando alcuni dei modelli azioni di inizializzazione (ad esempio, per Apache Flink), scrivere una tua azione di inizializzazione oppure specificando i requisiti dei pacchetti Python personalizzati.

Per iniziare, consulta Dataproc guide rapide e ai 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.

Rehosting di pipeline di dati di terze parti per l'esecuzione su Google Cloud

Uno scenario comune durante la creazione di pipeline di dati on-premise è l'utilizzo software di terze parti per gestire l'esecuzione della pipeline e l'allocazione e risorse di calcolo.

Per spostare queste pipeline nel cloud, hai diverse alternative, a seconda dalle funzionalità del software che usi e anche in base i 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 è l'alternativa più semplice perché si onboarding delle pipeline di dati che cloud utilizzando la piattaforma familiare fornita dal tuo fornitore. Potresti anche essere utilizzare gli strumenti di proprietà del vostro fornitore per facilitare la migrazione tra il tuo ambiente originale e il tuo nuovo ambiente su Google Cloud.

Se il tuo fornitore non fornisce una soluzione 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 cluster GKE seguendo i consigli dei fornitori.
  • Seleziona ed esegui la migrazione dei tuoi casi d'uso seguendo l'approccio iterativo spiegate in Migrazione dei data warehouse in BigQuery: panoramica.

Questa alternativa offre una via di mezzo in termini di complessità. La creazione il supporto nativo del fornitore per Kubernetes, al fine di scalare parallelizza l'esecuzione delle pipeline. Tuttavia, richiede la creazione e gestire un cluster GKE.

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

Gestire la parallelizzazione dell'opera non è banale. Se il 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 vanno a Pub/Sub, che crea argomenti. Gli argomenti vengono letti da diversi gruppi di istanze gestite.

Figura 9. Un gruppo di istanze gestite con tre VM.

In questo diagramma, ogni VM nel gruppo di istanze gestite esegue il software della pipeline di terze parti. Puoi attivare l'esecuzione di una pipeline in diversi modi:

In sostanza, tutti questi metodi inviano un messaggio a un indirizzo Argomento Pub/Sub. Devi creare un agente semplice da installare su ogni VM. L'agente ascolta il messaggio o e altri argomenti Pub/Sub. Ogni volta che arriva un messaggio sull'argomento, estrae il messaggio dall'argomento e avvia una pipeline nell'account software e ne ascolta 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 garantire la conformità alle i termini di licenza appropriati per far funzionare le 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 funziona bene se le pipeline esistenti sono state implementate originariamente con tecnologie ora deprecate o, se prevedi che la portabilità sarebbe necessario continuare a mantenere le pipeline non modificate nel cloud. inattuabili o proibitivi in termini di costi.

Le sezioni seguenti presentano i servizi Google Cloud completamente gestiti che di eseguire trasformazioni avanzate dei dati 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 eseguire 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 offerta di lavoro Dataproc.

Quando utilizzi Cloud Data Fusion, puoi connetterti utilizzando i driver Java Database Connectivity (JDBC) per leggere i dati, trasformarlo e caricarlo 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 ulteriori dettagli, consulta la guida su utilizzando 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 una vasta gamma di dati fonti. Se non esiste un plug-in, puoi crearne uno personalizzato utilizzando la proprietà le API per i plug-in di Cloud Data Fusion. Per ulteriori informazioni, consulta Panoramica dei plug-in.

Con le pipeline di Cloud Data Fusion, puoi creare pipeline di dati in modalità flusso. 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 Panoramica concettuale di Cloud Data Fusion. Per esempi pratici, vedi il guida rapida e il tutorial sulla creazione di un pipeline delle 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 consente di trasformare e arricchire i dati sia in modalità flusso (in tempo reale) che modalità batch (storiche) con affidabilità ed espressività uguali.

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 il interfaccia a riga di comando, il SDK Java, o il 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 di query sui dati e pipeline da altri framework a Apache Beam e Dataflow, scopri di più Modello di programmazione Apache Beam e sfoglia la scheda Documentazione di Dataflow.

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

Orchestrazione e pianificazione

A livello generale, l'orchestrazione è il coordinamento automatizzato di più mentre la pianificazione si riferisce all'attivazione automatica delle attività 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.
  • Diminuisci lo zoom: quando una pipeline di dati dipende dall'output di altri dati pipeline, è necessaria l'orchestrazione di più pipeline. Ogni pipeline costituisce un DAG secondario in un DAG più grande, che è un DAG di orchestrazione.

Questa configurazione è tipica del data warehousing. 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 di 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 l'esecuzione funziona, come illustrato nel diagramma seguente.

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

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

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.

Impegno per la migrazione

È una best practice per 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'è su 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 prossima sezione spiega questo metodo con un esempio pratico.

Esempio pratico

Supponiamo che un'organizzazione abbia due pipeline correlate:

  • La prima pipeline calcola i profitti e le perdite (P&L) per all'intera organizzazione. È una pipeline complessa che coinvolge molte trasformazioni. Parte della pipeline consiste nel calcolo delle 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 aumento delle vendite di diversi prodotti in modo che il reparto marketing possa ottimizzare le iniziative della sua campagna pubblicitaria. Questa pipeline richiede i dati sulle vendite mensili calcolate in precedenza dalla pipeline di dati P&L.

L'organizzazione ritiene che la pipeline di dati P&L abbia una priorità maggiore rispetto la pipeline di marketing. Purtroppo, poiché P&L è 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 la situazione.

La pipeline P&L crea una "vendita mensile" l'artefatto richiesto per la pipeline di marketing. La pipeline P&L può riscontrare 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 pianifichi la prossima iterazione, l'organizzazione dà priorità il caso d'uso P&L la include nel backlog di iterazione perché è fortemente limitato dalle attuali risorse on-premise 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. Sceglie di spostare sia il rapporto P&L di marketing e marketing a Google Cloud utilizzando approccio di reindirizzamento. Non apportano modifiche ai passaggi o all'orchestrazione della pipeline. Un'importante la differenza è che ora la pipeline P&L può distruggere un computing quasi illimitato ed è quindi molto più veloce rispetto a quello on-premise. La pipeline scrive i dati mensili delle vendite in una tabella BigQuery che il team utilizzi della pipeline di crescita. 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 reindirizzamento l'importanza di un approccio umile.

Sebbene Google Cloud abbia aiutato a risolvere i problemi non funzionali di P&L, sussistono ancora problemi funzionali. 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 di marketing, in modo che possa essere eseguita indipendentemente dal rendimento. Avere una potenza di calcolo sufficiente in Google Cloud consente l'esecuzione di 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 se ci sono problemi nella pipeline P&L.

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

Lo svantaggio è che la duplicazione della logica sub-DAG crea la gestione del codice overhead, perché ora il team deve conservare entrambe le copie della logica sub-DAG in sincronizzare.

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 profitto, 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.

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

Figura 15. Orchestrazione complessiva del DAG con ogni pipeline nella propria un sotto-DAG.

Nelle iterazioni successive, il team di migrazione può risolvere ed eseguire la migrazione delle pipeline per 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. Di conseguenza sconsigliati. Al loro posto, utilizza DAG indipendenti con TriggerDagRunOperator operatore.

Passaggi successivi

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

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