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 di migrazione sono disponibili per la migrazione di un data warehouse.

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 i dati dai sistemi transazionali, applicare le trasformazioni e poi scrivere i dati nel data warehouse. Ciascuna delle trasformazioni è descritta da una funzione e l'input per una determinata funzione è l'output della funzione o delle funzioni precedenti. Queste funzioni collegate sono descritte come un grafo, spesso definito grafo aciclico diretto (DAG), ovvero un grafo che segue una direzione (dall'origine alla destinazione) ed è aciclico: l'input di qualsiasi funzione non può dipendere dall'output di un'altra funzione a valle nel DAG. In altre parole, i loop non sono consentiti. Ogni nodo del grafico è una funzione e ogni bordo rappresenta i dati che passano da una funzione all'altra. Le funzioni iniziali sono origini o collegamenti ai sistemi di dati di origine. Le funzioni finali sono sink, 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 viene chiamato DAG del flusso di dati. Puoi anche utilizzare i DAG per orchestrare il movimento dei dati tra le pipeline di dati e altri sistemi. Questo utilizzo è denominato orchestrazione o DAG del flusso di controllo.

Quando eseguire la migrazione delle pipeline di dati

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

Da un lato, quando 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, stabilisci una copia incrementale dal vecchio al nuovo data warehouse per mantenere i dati sincronizzati. Infine, esegui la migrazione e la convalida dei processi a valle come script, query, dashboard e applicazioni aziendali.

A questo punto, le pipeline di dati upstream rimangono invariate e continuano a scrivere dati nel data warehouse esistente. Puoi includere di nuovo i casi d'uso di cui è stato eseguito il trasferimento nel backlog della migrazione per eseguire la migrazione completa in un'iterazione successiva.

D'altra parte, quando esegui la migrazione completa di un caso d'uso, viene eseguita la migrazione in Google Cloud delle pipeline di dati richieste per il caso d'uso. La migrazione completa richiede innanzitutto di eseguire il offload del 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 eseguito il trasferimento in precedenza.
• Esegui la migrazione completa di un caso d'uso da zero eseguendo prima il offload nella stessa Iterazione.

Una volta completata la migrazione di tutti i casi d'uso, puoi scegliere di disattivare il vecchio magazzino, un passaggio importante per ridurre i costi e gli oneri generali.

Come eseguire la migrazione delle pipeline di dati

Il resto di questo documento spiega come eseguire la migrazione delle pipeline di dati, incluso l'approccio e le procedure da utilizzare e le tecnologie da impiegare. Le opzioni 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. Puoi avere pipeline di dati batch o di dati in streaming. Le pipeline di dati in batch vengono eseguite sui dati raccolti in un determinato periodo di tempo (ad esempio una volta al giorno). Le pipeline di dati in 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 una procedura di estrazione, trasformazione e caricamento (ETL). 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 procedura ETL tipica.

Figura 1. Una procedura ETL tipica.

Una tipica pipeline di dati ETL estrae i dati da uno o più sistemi di origine (preferibilmente il meno possibile per evitare errori causati da problemi 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 dell'integrità dei dati e la creazione di dati aggregati o disaggregati. Per ulteriori informazioni, consulta la sezione Ciclo ETL reale.

È comune avere più pipeline di dati. La prima pipeline si concentra sulla copia dei dati dal sistema di origine al data warehouse. 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.

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

Nel diagramma, ciascuna pipeline di dati è considerata un sotto-DAG dell'orchestrazione con il DAG. Ogni DAG di orchestrazione comprende diverse pipeline di dati in linea con lo scopo più ampio, ad esempio la preparazione dei dati per un'unità aziendale in modo che gli analisti aziendali possano eseguire le loro dashboard o i loro report.

Estrazione, caricamento e trasformazione (ELT)

ELT è un'alternativa a ETL. Con ELT, la pipeline di dati è divisa in due parti. Innanzitutto, una tecnologia ELT estrae i dati dal sistema di origine e li carica nel data warehouse. 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.

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 nel data warehouse una volta e poi trasformati più volte per creare le diverse tabelle utilizzate a valle nei report e così via. Questi DAG a loro volta diventano 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 al cloud, è importante ricordare che i sistemi di data warehouse cloud come BigQuery sono tecnologie di elaborazione dati in parallelo massivo. Infatti, nel caso di BigQuery, puoi acquistare più risorse per supportare sia le crescenti richieste di ELT sia le query simultanee. Per ulteriori informazioni, consulta la sezione Introduzione all'ottimizzazione delle prestazioni delle query.

Estrazione e caricamento (EL)

Puoi utilizzare la procedura di estrazione e caricamento (EL) da sola o seguita da trasformazioni, nel qual caso diventa ELT. L'EL è menzionata separatamente perché sono disponibili diversi servizi automatici che eseguono questa attività, riducendo la necessità di creare la propria pipeline di dati di importazione. 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 CDC funziona con ELT.

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. Poi puoi utilizzare una query SQL per determinare la versione più recente prima di applicare ulteriori trasformazioni. Ecco un esempio:

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

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

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

Loop di feedback con pipeline di dati operativi

Le pipeline di dati operativi sono pipeline di elaborazione dati che prendono i dati il data warehouse, trasformarlo se necessario e scrivere il risultato sistemi operativi.

Sistemi operativi si riferisce 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.

Figura 5. Pattern per una pipeline di dati operativa.

L'esempio seguente descrive una pipeline di dati operativi che scrive i prezzi dei prodotti 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 end-to-end dei dati:

• I dati relativi ai prezzi sono disponibili da più origini. 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 li scrive nel data warehouse. In questo caso, la trasformazione è un calcolo complesso che coinvolge tutte le origini con l'obiettivo di produrre un prezzo base ottimale per ogni prodotto nel PCM.
• Infine, la pipeline operativa prende i prezzi base dai dati di magazzino, esegue piccole trasformazioni per adeguare i prezzi per le eventi e scrive i prezzi finali nel PCM.

Figura 6. Una pipeline di dati operativa che scrive i prezzi dei prodotti in una 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 delle pipeline di dati.

Reindirizzare le pipeline di dati in modo che scrivano in BigQuery

Nelle seguenti condizioni, ti consigliamo di valutare se una tecnologia che utilizzi offre un destinazione BigQuery integrata (connettore di scrittura):

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

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

• Informatica: Guida al connettore BigQuery
• Talend: Scrittura di dati in BigQuery

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.

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 funzionante

• Potrebbe essere necessario configurare i firewall per consentire il trasferimento dei dati in uscita da on-premise a BigQuery.
• Potrebbero essere necessarie modifiche alla rete per creare 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 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 per raggiungere BigQuery.

Questo approccio è simile all'approccio di reindirizzamento, ma anziché utilizzare un sink nativo che può scrivere in BigQuery, utilizzi un sink che può scrivere in un file system on-premise. Quando i dati sono nel file system, e copio i file in Cloud Storage. Per maggiori dettagli, consulta la panoramica delle opzioni di importazione per Cloud Storage e i criteri coinvolti nella scelta di un'opzione di importazione.

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

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

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 i dati trasformati 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 sono in Cloud Storage, utilizza un trasferimento Cloud Storage per pianificare i caricamenti ricorrenti da Cloud Storage a BigQuery. Alternative ai trasferimenti di Cloud Storage sono Trigger di Cloud Storage e Cloud Composer.

Nella Figura 8, tieni presente che è anche possibile per l'orchestrazione su Google Cloud utilizzare un modello pull recuperando i file utilizzando un protocollo come SFTP.

Esegui la migrazione delle pipeline ELT esistenti a BigQuery

Le pipeline ELT sono 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, ogni parte ha il suo approccio alla migrazione.

Per la parte che carica i dati nel data warehouse (la parte EL), puoi seguire le linee guida 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 da 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 pipeline di dati a Google Cloud, potresti voler eseguire la migrazione di alcuni job legacy scritti con un framework software open source come Apache Hadoop, Apache Spark o Apache Flink.

Dataproc ti consente di eseguire il deployment di cluster Hadoop e Spark completamente gestiti, veloci e facili da utilizzare in modo semplice ed economico. Dataproc si integra con il connettore BigQuery, una libreria Java che consente a Hadoop e Spark di scrivere direttamente dati in BigQuery utilizzando versioni astratte delle classi Apache Hadoop InputFormat e OutputFormat.

Dataproc semplifica la creazione 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 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 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 dalla complessità insita 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, ti consigliamo di creare la tua immagine Dataproc, di utilizzare alcune delle azioni di inizializzazione disponibili (ad esempio per Apache Flink), di scrivere la tua azione di inizializzazione o di specificare i requisiti dei pacchetti Python personalizzati.

Per iniziare, consulta le guide di avvio rapido di Dataproc e gli esempi di codice del connettore BigQuery. Consulta anche 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 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 stretto una partnership con Google Cloud per offrire il proprio software su Google Cloud Marketplace.
• Il fornitore di software di terze parti può essere eseguito su Kubernetes.
• Il software di terze parti viene eseguito su una o più macchine virtuali (VM).

Se il tuo software di terze parti fornisce una soluzione Cloud Marketplace, le operazioni necessarie sono le seguenti:

• Esegui il deployment del software di terze parti Console di Cloud Marketplace.
• Seleziona ed esegui la migrazione dei casi d'uso seguendo l'approccio iterativo spiegato in Eseguire la migrazione utilizzando un approccio iterativo.

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 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. Sono coinvolti i seguenti lavori:

• 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 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à. 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 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 tuo fornitore non offre funzionalità per la distribuzione delle attività a VM diverse, ti consigliamo di utilizzare un pattern di farming delle attività per distribuire il lavoro alle VM in un gruppo di istanze gestite. Il seguente diagramma illustra questo approccio.

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

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

• In modo automatico, utilizzando Cloud Scheduler, Cloud Composer o un trigger Cloud Storage quando arrivano nuovi dati in un bucket Cloud Storage.
• In modo programmatico, chiamando un endpoint Cloud o una funzione Cloud oppure utilizzando l'API Pub/Sub.
• manualmente, inserendo un nuovo messaggio in un argomento Pub/Sub con Google Cloud CLI.

In sostanza, tutti questi metodi inviano un messaggio a un indirizzo Argomento Pub/Sub. Crea un agente semplice da installare in ogni VM. L'agente ascolta uno o più 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 rispettare i termini di licenza appropriati per il funzionamento delle tue pipeline su Google Cloud.

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

In alcuni casi, puoi scegliere di riscrivere alcune delle pipeline di dati esistenti per utilizzare nuovi framework e servizi completamente gestiti su Google Cloud. Questa opzione 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 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.

Sviluppa le pipeline di dati nell'interfaccia utente di Cloud Data Fusion collegando le origini a trasformazioni, sink e altri nodi per formare un DAG. Quando 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 caricare un driver JDBC nell'istanza Cloud Data Fusion e configurarlo in modo da poterlo 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, aggregati, sink, collezionisti 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 un plug-in non esiste, puoi crearne uno utilizzando le API plug-in di Cloud Data Fusion. Per ulteriori informazioni, consulta la panoramica dei plug-in.

Con le pipeline Cloud Data Fusion puoi creare pipeline di dati sia in batch che in streaming. Fornendo l'accesso a log e metriche, le pipeline di dati offrono anche agli amministratori la possibilità di rendere operativi i flussi di lavoro di elaborazione dei dati senza bisogno di strumenti personalizzati.

Per iniziare, consulta 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 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 rimuove l'overhead operativo in quanto prestazioni, scalabilità, disponibilità, sicurezza e conformità vengono gestite automaticamente. In questo modo, puoi concentrarti sulla programmazione anziché sulla gestione dei cluster di server.

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

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

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

Orchestrazione e pianificazione

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

• 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 DAG secondario in un DAG più grande, che è un DAG di orchestrazione.

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

Dipendenze

Le dipendenze possono essere fan-in, in cui più pipeline di dati 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.

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 viene eseguita e 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.

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

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

Attività di migrazione necessarie

È 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'è in Google Cloud.
2. Nelle iterazioni successive, analizza le dipendenze e esegui il loro parallelismo, se possibile.
3. Infine, riorganizza l'orchestrazione estraendo le attività comuni 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 per l'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 la crescita delle vendite su base annua e mensile per diversi prodotti, in modo che il reparto marketing possa ottimizzare le proprie campagne pubblicitarie. Questa pipeline richiede i dati mensili sulle vendite precedentemente calcolati dalla pipeline di dati del conto economico.

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

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 i due casi d'uso, utili per il bilancio e la crescita delle vendite di marketing, e li ha inclusi nel backlog della migrazione. Quando 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 dei casi d'uso dipendenti, tra cui il caso d'uso per il marketing.

Il team di migrazione esegue la prima iterazione. La società sceglie di spostare su Google Cloud sia i casi d'uso relativi a profitti e perdite sia quelli di marketing utilizzando un approccio di reindirizzamento. Non apportano modifiche ai passaggi o all'orchestrazione della pipeline. 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.

Figura 13. Accelerare una pipeline di dati complessa utilizzando un reindirizzamento l'importanza di un approccio umile.

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

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 rivede i casi d'uso ed estrae il DAG secondario mensile delle vendite 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.

Figura 15. DAG di orchestrazione complessiva con ogni pipeline nel proprio sub-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:

• Dataflow: Consente di definire ogni pipeline di dati come DAG autonomo utilizzando Modello trasmettitore.
• Cloud Composer Consente di definire l'orchestrazione più ampia come una o più DAG Airflow.

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:

• Panoramica della migrazione
• Valutazione della migrazione
• Panoramica del trasferimento di schemi e dati
• Traduzione batch di SQL
• Traduzione SQL interattiva
• Sicurezza e governance dei dati
• Strumento di convalida dei dati

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

• Migrazione da Netezza
• Migrazione da Oracle
• Migrazione da Amazon Redshift
• Migrazione da Teradata
• Eseguire la migrazione da Snowflake