Organizzare i dataset nelle pipeline Lakeflow

Utilizza le pipeline Lakeflow per elaborare da uno a centinaia di set di dati in un'unica pipeline. Decidi quali dataset devono essere insieme in base a dominio, cadenza e dipendenze, e suddividi il lavoro in pipeline separate quando proprietà, latenza o scala differiscono.

Overview

Una decisione che non viene mai presentata in un tutorial diventa importante nelle reali implementazioni: quali tabelle appartengono insieme nella stessa pipeline, e quando qualcosa dovrebbe essere una pipeline a sé stante? Sbagliare è uno dei modi più comuni in cui le squadre si mettono in difficoltà. La classica modalità di guasto consiste nel riversare tutto in un'unica pipeline gigante e poi affrontare problemi di scala, concorrenza e raggio d'esplosione che sono dolorosi da risolvere.

Non esiste una risposta unica giusta, ma ci sono forze chiare che tirano in ogni direzione e un vincolo duro che vale la pena conoscere prima di progettare.

Linee guida

Raggruppate i dataset per dominio, cadenza condivisa e dipendenza, e suddivideteli in base ai confini di proprietà, di livello e di latenza. Mantieni il numero di set di dati aggiornabili in modo indipendente di una singola pipeline ben al di sotto del limite degli aggiornamenti paralleli.

Conosci il limite di concorrenza prima di progettare

Un singolo aggiornamento della pipeline attivato esegue al massimo 16 aggiornamenti del dataset in parallelo. Questa è la sorpresa più comune per i team che mettono tutto in un'unica pipeline: una volta che hai più di circa 16 dataset che potrebbero girare contemporaneamente, quelli extra si mettono in coda dietro i primi 16 invece di correre in parallelo, quindi il tempo totale di aggiornamento si allunga anche se c'è calcolo disponibile. Se hai decine di dataset indipendenti e ti interessa il tempo di aggiornamento effettivo, già questo è un motivo sufficiente per non stiparli tutti in un'unica pipeline.

Cosa dovrebbe essere nella stessa pipeline

Tieni insieme i dataset quando condividono struttura o pianificazione:

  • Dataset che costituiscono una catena di dipendenze o un unico dominio logico, come le tabelle bronzo, argento e oro per gli ordini. Mantenere insieme un grafo aciclico diretto connesso (DAG) permette alla pipeline di programmarlo, di fare checkpoint e aggiornarlo completamente come unità coerente, mantenendo la linea leggibile. Vedi Caricare ed elaborare i dati in modo incrementale con i flussi della pipeline Lakeflow.
  • Set di dati che condividono lo stesso requisito di aggiornamento e la stessa frequenza di esecuzione, ad esempio elementi che devono essere aggiornati insieme, in risposta allo stesso trigger, all’interno dello stesso limite di transazione.
  • Set di dati sufficientemente piccoli, nel complesso, da far sì che l'intero grafo rientri comodamente nel limite degli aggiornamenti paralleli e si aggiorni in un tempo accettabile.

Cosa dovrebbe essere in una pipeline separata

Separare i dataset quando differiscono per proprietà, livello o latenza:

  • Domini o team diversi. Una titolarità separata dovrebbe di solito significare pipeline separate, in modo che una modifica o un guasto di un team non blocchino la pipeline di un altro.
  • Livelli che vuoi scalare o programmare in modo indipendente. Una divisione ampiamente raccomandata è separare l'ingestione (bronzo) dalla trasformazione (argento e oro) in pipeline distinti, così che un'ingestione lenta o fallita non rallenti la trasformazione e ciascuna possa dimensionare il calcolo secondo le proprie esigenze.
  • Profili di latenza diversi. Un flusso continuo e a bassa latenza non dovrebbe condividere una pipeline con un’elaborazione batch eseguita una volta al giorno. Consultare Triggered vs. continuous pipeline mode (Modalità pipeline attivata e continua).
  • Set di dati che superano il limite degli aggiornamenti paralleli e che altrimenti andrebbero in coda.

Per eseguire un insieme di dataset in isolamento, consideriamo una pipeline autonoma. Vedi Oleodotti autonomi vs. Oleodotti Lakeflow.

Una regola pratica

Non usare di default una pipeline monolitica, e non frantumare ogni tabella in una pipeline a sé. Raggruppare per dominio + cadenza condivisa + dipendenza, suddividere in corrispondenza dei confini di responsabilità, layer e latenza, e mantenere il numero di set di dati aggiornabili in modo indipendente di qualsiasi singola pipeline ben al di sotto del limite degli aggiornamenti paralleli. In caso di dubbio, preferisci una manciata di pipeline di medie dimensioni allineate ai domini piuttosto che un’unica pipeline gigantesca. È molto più facile unire due piccoli gasdotti in seguito che dividere un monolite già in produzione.

Limitazioni

  • Un singolo aggiornamento attivato esegue al massimo 16 aggiornamenti del dataset in parallelo. I dataset che superano tale limite vengono messi in coda invece di venire eseguiti in parallelo, quindi una pipeline con decine di dataset indipendenti può richiedere più tempo per aggiornarsi anche quando sono disponibili risorse di calcolo.
  • La suddivisione in più pipeline comporta una perdita di visibilità end-to-end. Quando dividi, appoggiati alle tabelle di sistema (system.lakeflow.pipelines, system.lakeflow.job_run_timeline) e orchestra i pezzi insieme con un Lakeflow Job così ottieni comunque una singola vista end-to-end dell'intero flusso. Vedere Eseguire pipeline in un flusso di lavoro.

Risorse aggiuntive

  • Last updated on