Pipeline dichiarative di Spark: perché l'ingegneria dei dati deve diventare dichiarativa end-to-end

I team di data ingegneria sono sotto pressione per fornire dati di qualità superiore più velocemente, ma il lavoro di creazione e gestione delle pipeline sta diventando più difficile, non più facile. Abbiamo intervistato centinaia di data engineer e studiato milioni di carichi di lavoro reali, scoprendo qualcosa di sorprendente: i data engineer trascorrono la maggior parte del loro tempo non a scrivere codice, ma a occuparsi dell'onere operativo generato dall'unione di diversi strumenti. Il motivo è semplice: i framework di data engineering esistenti costringono i data engineer a gestire manualmente l'orchestrazione, l'elaborazione incrementale dei dati, la qualità dei dati e i backfill, tutte attività comuni per le pipeline di produzione. Con l'aumento dei volumi di dati e dei casi d'uso, questo onere operativo si aggrava, trasformando l'ingegneria dei dati in un collo di bottiglia per l'azienda anziché in un acceleratore.

Non è la prima volta che il settore industriale si scontra con questo ostacolo. L'elaborazione dei dati nelle fasi iniziali richiedeva la scrittura di un nuovo programma per ogni domanda, un approccio che non era scalabile. SQL ha cambiato le cose rendendo le singole query dichiarative: si specifica quale risultato si desidera e il motore capisce come calcolarlo. I database SQL sono oggi alla base di ogni azienda.

Ma l'ingegneria dei dati non consiste nell'eseguire una singola query. Le pipeline aggiornano ripetutamente più set di dati interdipendenti nel tempo. Poiché i motori SQL si fermano al confine della query, tutto ciò che va oltre (elaborazione incrementale, gestione delle dipendenze, backfill, qualità dei dati, tentativi) deve ancora essere assemblato manualmente. Su larga scala, il ragionamento sull'ordine di esecuzione, il parallelismo e le modalità di errore diventa rapidamente la principale fonte di complessità.

Ciò che manca è un modo per dichiarare la pipeline nel suo complesso. Spark Declarative Pipelines (SDP) estendono l'elaborazione dichiarativa dei dati dalle singole query a intere pipeline, consentendo ad Apache Spark di pianificarle ed eseguirle end-to-end. Invece di spostare manualmente i dati tra i passaggi, si dichiara quali set di dati si desidera che esistano e SDP è responsabile di come mantenerli corretti nel tempo. Ad esempio, in una pipeline che calcola le vendite settimanali, SDP deduce le dipendenze tra i set di dati, crea un unico piano di esecuzione e aggiorna i risultati nell'ordine corretto. Elabora automaticamente solo i dati nuovi o modificati, esprime le regole sulla qualità dei dati inline e gestisce i backfill e i dati in arrivo in ritardo senza intervento manuale. Poiché SDP comprende la semantica delle query, è in grado di convalidare le pipeline in anticipo, eseguirle in parallelo in modo sicuro e ripristinarle correttamente in caso di errori, tutte funzionalità che richiedono API dichiarative di prima classe e sensibili alle pipeline, integrate direttamente in Apache Spark.

L'ingegneria dei dati dichiarativa end-to-end in SDP offre notevoli vantaggi:

• Maggiore produttività: i data engineer possono concentrarsi sulla scrittura della logica di business invece che sul glue code.
• Costi inferiori: il framework gestisce automaticamente l'orchestrazione e l'elaborazione incrementale dei dati, rendendolo più conveniente rispetto alle pipeline scritte a mano.
• Minore carico operativo: i casi d'uso comuni come i backfill, la qualità dei dati e i nuovi tentativi sono integrati e automatizzati.

Per illustrare i vantaggi del data engineering dichiarativo end-to-end, partiamo da una pipeline di vendita settimanale scritta in PySpark. Poiché PySpark non è dichiarativo end-to-end, dobbiamo codificare manualmente l'ordine di esecuzione, l'elaborazione incrementale e la logica di qualità dei dati e affidarci a un orchestratore esterno come Airflow per i nuovi tentativi, gli avvisi e il monitoraggio (omessi per brevità).

Questa pipeline, espressa come progetto SQL dbt, presenta molte delle stesse limitazioni: dobbiamo ancora codificare manualmente l'elaborazione incrementale dei dati, la qualità dei dati viene gestita separatamente e dobbiamo ancora affidarci a un orchestratore come Airflow per i nuovi tentativi e la gestione degli errori:

Riscriviamo questa pipeline in SDP per esplorarne i vantaggi. Per prima cosa, installiamo SDP e creiamo una nuova pipeline:

Successivamente, definisci la tua pipeline con il codice seguente. Nota che commentiamo l'API di aspettativa sulla qualità dei dati expect_or_drop poiché stiamo lavorando con la community per renderla open source:

Per eseguire la pipeline, digita il seguente comando nel tuo terminale:

Possiamo anche convalidare la nostra pipeline in anticipo senza eseguirla con questo comando: è utile per individuare errori di sintassi e mancate corrispondenze dello schema:

I backfill diventano molto più semplici: per eseguire il backfill della tabella raw_sales, esegui questo comando:

Il codice è molto più semplice: solo 20 righe che forniscono tutto ciò che le versioni PySpark e dbt richiedono a strumenti esterni di fornire. Otteniamo anche questi potenti vantaggi:

• Elaborazione incrementale automatica dei dati. Il framework tiene traccia dei dati che sono stati elaborati e legge solo i record nuovi o modificati. Nessuna query MAX, nessun file di checkpoint, nessuna logica condizionale necessaria.
• Qualità dei dati integrata. Il decoratore @dp.expect_or_drop mette automaticamente in quarantena i record non validi. In PySpark, abbiamo suddiviso e scritto manualmente i record buoni/cattivi in tabelle separate. In dbt, erano necessari un modello separato e una gestione manuale.
• Tracciamento automatico delle dipendenze. Il framework rileva che weekly_sales dipende da raw_sales e orchestra automaticamente l'ordine di esecuzione. Non è necessario alcun orchestratore esterno.
• Tentativi e monitoraggio integrati. Il framework gestisce gli errori e fornisce l'osservabilità tramite un'interfaccia utente integrata. Non sono richiesti strumenti esterni.

SDP in Apache Spark 4.1 ha le seguenti funzionalità che lo rendono un'ottima scelta per le pipeline di dati:

• API Python e SQL per la definizione di set di dati
• Supporto per query batch e in streaming
• Tracciamento automatico delle dipendenze tra set di dati e aggiornamenti paralleli efficienti
• CLI per creare lo scaffolding, convalidare ed eseguire pipeline in locale o in produzione

Siamo entusiasti della roadmap di SDP, che viene sviluppata apertamente con la community di Spark. Le prossime release di Spark si baseranno su queste fondamenta con il supporto per l'esecuzione continua e un'elaborazione incrementale più efficiente. Prevediamo anche di integrare in SDP funzionalità di base come il Change Data Capture (CDC), sulla base di casi d'uso reali e del feedback della community. Il nostro obiettivo è rendere SDP una base condivisa ed estensibile per la creazione di pipeline batch e di streaming affidabili in tutto l'ecosistema Spark.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale