Modernizzazione di SQL ETL nel Lakehouse con pattern dichiarativi

Databricks sta portando l'ETL dichiarativo nei flussi di lavoro di data warehousing in Lakehouse, semplificando la logica di trasformazione complessa per i professionisti SQL negli ambienti familiari in cui già operano.

Questo fa parte di una strategia più ampia per introdurre il modello di esecuzione dichiarativo alla base di Apache Spark™ Declarative Pipelines in un numero maggiore di esperienze di creazione in Databricks. Invece di dover lavorare in un ambiente dedicato orientato alle pipeline, gli utenti SQL possono ora definire pattern ETL comuni direttamente all'interno delle loro query SQL in Databricks Lakehouse.

Semplificare i pattern ETL ricorrenti in Lakehouse

L'ETL SQL dichiarativo su Databricks non è una novità. Oggi, migliaia di utenti SQL-first si affidano già a primitive dichiarative come le Viste materializzate e le Tabelle di streaming per semplificare le trasformazioni ricorrenti, mantenere aggiornate le tabelle a valle e accelerare i carichi di lavoro BI.

Molti pattern ETL ricorrenti sono facili da descrivere ma difficili da gestire, poiché richiedono logica SQL personalizzata, pianificazione manuale e strumenti di orchestrazione. Questi pattern includono l'aggiunta di nuovi record, l'applicazione di modifiche CDC e l'aggiornamento dei soli dati modificati.

Le primitive dichiarative funzionano perché consentono agli utenti di descrivere la tabella o la vista desiderata, invece di codificare manualmente ogni passaggio necessario per mantenerla aggiornata. Databricks gestisce la pianificazione, l'aggiornamento e l'elaborazione incrementale ove applicabile, evitando agli utenti di dover scrivere manualmente la logica per mantenere aggiornate le tabelle.

Ora stiamo estendendo lo stesso approccio dichiarativo oltre il Lakeflow Pipelines Editor a un numero maggiore di pattern ETL ricorrenti per i professionisti del data warehouse e di SQL. Ora, gli utenti di Lakehouse possono definire il pattern ETL desiderato, ad esempio direttamente nell'Editor SQL, mentre Databricks gestisce l'elaborazione incrementale, la logica di aggiornamento, la pianificazione e l'orchestrazione necessarie per eseguirlo in modo affidabile.

Le prime primitive dichiarative disponibili in Lakehouse

Le prime operazioni dichiarative disponibili nell'Editor SQL di Lakehouse si associano a tre pattern ETL ricorrenti comuni: aggiornamenti append-only, change data capture e sovrascritture batch.

Molti di questi pattern sono già disponibili tramite API dichiarative come AUTO CDC in Lakeflow; la novità qui consiste nel renderli accessibili direttamente in Lakehouse per gli analisti SQL.

Questi flussi possono essere aggiornati in base a una pianificazione, attivati da aggiornamenti a monte, eseguiti su richiesta o orchestrati tramite task SQL in Jobs.

Aggiornamenti append-only

Gli aggiornamenti append-only sono il pattern standard alla base di molte tabelle di streaming attuali, utilizzati per aggiungere in modo incrementale nuovi record da una sorgente a una tabella di destinazione. Sono comunemente usati per i carichi di lavoro di ingestion, come il caricamento di nuovi record dallo storage di oggetti cloud con Auto Loader.

Invece di scrivere e pianificare ripetutamente la logica di inserimento, gli utenti SQL possono definire un semplice flusso APPEND che tiene traccia automaticamente dei dati nuovi rispetto a quelli già elaborati nella sorgente. Databricks gestisce il tracciamento dello stato e aggiunge in modo incrementale i nuovi record man mano che arrivano, gestendo automaticamente la pipeline serverless sottostante.

Ciò offre agli utenti SQL un modo semplice per rendere operativi i processi di inserimento in stile append, senza dover creare, pianificare o gestire manualmente una pipeline separata.

Scopri come definire i flussi APPEND in Lakehouse.

Change Data Capture

Le pipeline CDC sono tra i pattern più comuni, e più complessi, nell'ETL SQL. I team utilizzano spesso MERGE INTO per elaborare inserimenti, aggiornamenti ed eliminazioni, ma i dati CDC possono arrivare non in ordine, richiedendo logica aggiuntiva per evitare risultati errati.

AUTO CDC consente agli utenti SQL di definire la logica CDC con poche righe di codice dichiarativo in Lakehouse. Con AUTO CDC, è facile specificare chiavi, sequenziamento, gestione delle eliminazioni e se memorizzare i risultati come SCD Tipo 1 o SCD Tipo 2, senza dover scrivere manualmente complesse pipeline di merge.

“In bsport, SQL AUTO CDC ci ha fornito un modo molto più semplice e modulare per gestire l'ingestion dei dati in Databricks. Scollegando i caricamenti delle tabelle da una singola pipeline, abbiamo migliorato la disponibilità e la freschezza dei dati su tutta la nostra piattaforma. Ci consente di elaborare i dati di terze parti in modo indipendente, il che ci offre una migliore gestione dei guasti, riduce la complessità dell'orchestrazione e rende l'intera configurazione più facile da gestire e scalare. Per il nostro team, questo ha creato un flusso di lavoro basato su SQL più pulito e flessibile, con una maggiore affidabilità in produzione.”—Adrien Marteau, Head of Data, bsport

Scopri come creare flussi AUTO CDC per SCD Tipo 1 e Tipo 2.

Sovrascritture batch

Alcuni carichi di lavoro ETL batch devono solo aggiornare un sottoinsieme specifico di dati, come un intervallo di date, una partizione o un segmento di business. Tradizionalmente, i team gestiscono spesso questo aspetto con costosi ricalcoli completi o logiche di sovrascrittura personalizzate.

I flussi REPLACE WHERE introducono in Lakehouse un pattern dichiarativo per il ricalcolo batch incrementale mirato. Gli utenti definiscono un predicato sulla tabella di destinazione e Databricks aggiorna automaticamente quell'area. Con Enzyme, il motore di incrementalizzazione automatica di Databricks, Databricks è in grado di identificare ed elaborare, ove possibile, solo i dati modificati all'interno del predicato specificato, anziché ricalcolare l'intera tabella di destinazione o riscrivere l'intera porzione corrispondente.

Nei test di benchmark di Lakehouse, REPLACE WHERE basato su Enzyme è stato eseguito 3,4 volte più velocemente e con un costo inferiore di 2,5 volte rispetto al REPLACE WHERE tradizionale. Questo è utile per la rielaborazione selettiva, l'evoluzione dello schema, i backfill e l'iterazione su una finestra temporale ridotta di dati prima di elaborare un intervallo storico più ampio.

Scopri come utilizzare i flussi REPLACE WHERE per aggiornare un sottoinsieme mirato di una tabella (e leggi il blog della community qui).

In sintesi: perché questo è importante per i professionisti SQL

Modernizzare l'ETL non richiede una riscrittura totale o un impegno assoluto verso framework di pipeline complessi. L'introduzione della semantica dichiarativa nelle operazioni SQL esistenti di Lakehouse consente di combinare il codice esistente con l'SQL dichiarativo modernizzato dove ha più senso.

È possibile mantenere le query SQL procedurali esistenti e ottimizzate per i task personalizzati, integrando al contempo in modo trasparente operazioni dichiarative come l'ingestion append-only, AUTO CDC o le sovrascritture batch mirate per i pattern ricorrenti che richiedono molta manutenzione. Questo offre il meglio di entrambi i mondi: il controllo completo sulla logica SQL tradizionale insieme alla gestione automatizzata dello stato, alla gestione delle dipendenze e all'evoluzione dello schema dove desiderato, il tutto direttamente all'interno di Lakehouse.

Dalle primitive dichiarative alle pipeline dichiarative complete

L'integrazione di primitive dichiarative nei flussi di lavoro SQL quotidiani fornisce un punto di partenza pratico e a basso attrito per la gestione di singole tabelle e della logica incrementale. Man mano che il progetto cresce in scala e complessità, il flusso di lavoro di sviluppo può evolversi naturalmente di conseguenza.

Per i team che gestiscono più trasformazioni correlate, dipendenze condivise e flussi di lavoro di produzione, il Lakeflow Pipelines Editor offre un'esperienza di sviluppo più ricca e orientata ai progetti per l'ETL dichiarativo, con supporto per lo sviluppo multi-file, la gestione delle dipendenze, la visualizzazione delle pipeline, la convalida integrata e la distribuzione in produzione.

Questo è particolarmente utile per i team che gestiscono molte trasformazioni correlate tra domini, prodotti dati o unità aziendali. Invece di mantenere script scollegati o centralizzare tutta la logica in un unico grande progetto, i team possono organizzare i flussi dichiarativi in pipeline governate e di proprietà del team su Databricks. Con Unity Catalog, ogni team può basarsi su asset di dati condivisi, gestire i permessi in modo coerente e comprendere la lineage tra le pipeline e i consumatori a valle.

I professionisti SQL possono iniziare con i flussi dichiarativi nel familiare Editor SQL, per poi passare al Pipelines Editor quando necessitano di un ambiente più strutturato per progetti più ampi, una gestione più approfondita delle pipeline e lo sviluppo basato sul team.

Scopri di più sulla creazione di flussi di lavoro ETL dichiarativi con il Lakeflow Pipelines Editor.

Usa Genie Code per iniziare più rapidamente

Genie Code rende più facile per i professionisti SQL scoprire e applicare questi pattern ETL dichiarativi nei workflow che già utilizzano. Invece di partire da una pagina vuota o di tradurre manualmente il codice SQL esistente in un pattern pronto per la produzione, gli utenti possono chiedere a Genie Code di aiutarli a generare, spiegare e perfezionare i flussi dichiarativi.

Ad esempio, un utente che lavora con dati CDC può chiedere a Genie Code di aiutarlo a creare un flusso AUTO CDC, inclusi le chiavi appropriate, la colonna di sequenza, la gestione delle eliminazioni e il comportamento SCD di Tipo 1 o Tipo 2. Un utente che lavora con logiche batch ricorrenti può chiedere a Genie Code di aiutarlo a convertire la logica di sovrascrittura esistente in un flusso incrementale REPLACE WHERE.

Man mano che l'ETL dichiarativo diventa disponibile in un numero maggiore di esperienze di authoring, Genie Code può aiutare a guidare gli utenti verso il pattern dichiarativo più adatto all'attività da svolgere.

Per iniziare, esplora la documentazione collegata in ciascuna sezione precedente - e usa Genie Code nell'Editor SQL per identificare dove i flussi APPEND, i flussi AUTO CDC o i flussi REPLACE WHERE possono semplificare la tua logica ETL esistente.

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