Come scegliere tra Lakehouse, Spark Declarative Pipelines o PySpark e quando combinarli
di Rafael Aielo
Il tuo team ha centinaia di stored procedure, un paio di scheduler, autorizzazioni sparse tra ruoli e schemi e la scadenza del rinnovo del cloud data warehouse che si avvicina. Nessuno è d'accordo su cosa migrare per primo. Alcuni vogliono riscrivere tutto in PySpark. Altri vogliono spostare l'SQL così com'è e considerarlo fatto. Persi nella conversazione: i metadati, la lineage e le autorizzazioni che si spostano con il codice, oltre all'opportunità di consolidarli lungo il percorso.
Nessuno dei due estremi funziona. I team che riescono a migrare con successo il data warehouse analizzano ogni singolo workload e scelgono lo strumento giusto per il lavoro da svolgere. Questo post suggerisce un framework decisionale per la selezione: quando utilizzare Lakehouse (Databricks SQL), Spark Declarative Pipelines o PySpark, e come suddividere il lavoro in fasi per fornire risultati concreti invece di bloccarsi sulla pianificazione.
Su Databricks, puoi migrare le pipeline ETL in tre modi principali, spesso utilizzati insieme.
Questo è il percorso più diretto per i team che utilizzano molto l'SQL. Copre uno spettro da semplice a complesso. Viene eseguito su SQL warehouse, che sono accelerati da Photon per impostazione predefinita e completamente compatibili con ANSI e Spark SQL (%sql). Scegli Serverless per workload variabili o imprevedibili (avvio rapido, scalabilità a zero, pagamento al secondo). Scegli Classic per workload stabili o quando hai bisogno di controlli di rete o di costo specifici.
Un semplice task SQL:
Quando la logica richiede il controllo del flusso (condizionali), cicli, variabili, gestione degli errori o esecuzione guidata da parametri, le stored procedure offrono quel livello procedurale. Sono gestite tramite Unity Catalog e possono essere chiamate da Workflows con parametri.
La regola empirica: se il tuo codice legacy è una singola istruzione SQL, migralo come task SQL. Se ha una logica procedurale (variabili, cicli, parametri, gestione degli errori), racchiudilo in una stored procedure, gestita da Unity Catalog e richiamabile da Workflows. Non racchiudere un semplice SQL in una procedura solo perché il sistema originale lo richiedeva.
Che fa parte di Lakeflow, adotta un approccio diverso. Dichiari cosa dovrebbe produrre la tua pipeline e l'engine gestisce l'ordine di esecuzione, i tentativi e la scalabilità. Ottieni vincoli di qualità dei dati integrati, risoluzione automatica delle dipendenze e batch e streaming unificati nella stessa definizione.
Dietro le quinte, Enzyme decide quando aggiornare in modo incrementale rispetto al ricalcolo completo delle tabelle derivate. L'autoscaling adatta la capacità alle variazioni del volume dei dati senza ottimizzazione manuale. Aziende come Block si affidano a questo modello dichiarativo per semplificare l'orchestrazione delle pipeline con la crescita dell'utilizzo.
Che ti offrono il pieno controllo. Vengono eseguiti su cluster di job e gestiscono i workload che non sono adatti a un SQL Warehouse o a una pipeline dichiarativa.
Scegli PySpark quando il workload richiede una logica di business complessa, feature engineering per ML, integrazioni API o convalida personalizzata. L'esempio seguente valuta le transazioni con un modello registrato in Unity Catalog:
Scegli Spark SQL in un notebook quando il linguaggio è ancora SQL ma il workload potrebbe superare le capacità di un SQL Warehouse: tabelle molto grandi, shuffle pesanti, ETL batch a lungo termine in cui desideri un controllo esplicito su partizionamento, join broadcast o caching.
Abilita Photon sul cluster di job per attività SQL o DataFrame ad alta intensità di calcolo: join di grandi dimensioni, aggregazioni, funzioni window, scansioni su grandi tabelle colonnari. Photon è un motore nativo e vettorizzato che accelera questi pattern senza modifiche al codice, inclusi gli UDF di Pandas (basati su Arrow). Evita Photon quando prevalgono gli UDF Python a livello di riga, i dataset sono piccoli o il job è puramente di I/O.
I notebook si integrano bene anche nelle pipeline ibride: ingestione in SDP, arricchimento in un task del notebook.
La tabella seguente è un punto di partenza per i confronti all'interno del team, non una regola rigida.
| Criteri | Lakehouse (task e stored procedure) | Spark Declarative Pipelines | PySpark + notebook Spark SQL |
|---|---|---|---|
| Profilo del team | Team incentrati su SQL, DBA, ingegneri DW | Data engineer e team SQL che creano pipeline gestite | Sviluppatori Python/Spark, ingegneri ML |
| Tipo di logica | ETL SQL: task semplici per singole istruzioni, stored procedure per logica procedurale | Pipeline dichiarative, CDC, SCD | Logica complessa, UDF personalizzati, preparazione ML |
| Velocità di migrazione SQL | Elevata per workload di tipo SQL ANSI | Media: riprogettazione della pipeline, ma riutilizzo di SQL | Variabile: potrebbe richiedere un refactoring significativo |
| Orchestrazione della pipeline | Workflows con task SQL o procedura CALL | Integrata nelle pipeline | Workflows con task di notebook |
| Batch vs. streaming | Principalmente batch | Batch e streaming unificati | Batch e streaming tramite Structured Streaming |
| Qualità dei dati | Controlli SQL manuali | Vincoli dichiarativi | Convalida personalizzata nel codice |
Trova il tuo team nella colonna e la complessità del tuo workload nella riga. La cella suggerisce da dove iniziare.
| Complessità del workload | Team SQL-first | Team ibrido | Team code-first |
|---|---|---|---|
| Bassa (caricamenti batch, aggregazioni, MERGE) | Task SQL in Workflows | Task SQL o SDP | PySpark o SDP |
| Media (pipeline a più fasi, CDC, qualità dei dati) | Stored procedure o SDP | SDP | SDP o PySpark |
| Alta (preparazione ML, UDF personalizzati, API, logica di business complessa) | SDP + supporto PySpark | PySpark + SDP per l'ingestione | PySpark |
Invece di decidere "quale approccio adottare per tutto", stabilisci "cosa fare dopo" in ogni fase.
Fase 1 — Valutazione. Raccogli le metriche dal tuo data warehouse legacy: tempo di CPU, tempo di esecuzione, frequenza, tabelle di origine e di destinazione. Classifica i carichi di lavoro in base alla complessità. Utilizza strumenti di migrazione, quando possibile, per creare un inventario valutato in base al valore rispetto alla difficoltà. Dove trovare questi dati dipende dalla sorgente. Su Teradata, interroga DBC.QryLog. Su SQL Server, usa sys.dm_exec_query_stats. Su Oracle, i report AWR. Su Snowflake, QUERY_HISTORY. I dettagli possono variare. Se disponi già di uno strumento di integrazione, puoi sfruttare i suoi metadati per identificare le relazioni tra le tabelle, oppure affidarti a un LLM per creare questa lineage. L'output è una mappa, non un piano di riscrittura. L'obiettivo rimane lo stesso: classificare i carichi di lavoro in base al consumo di risorse e al livello di dipendenza per sapere da dove iniziare. Se eseguita bene, questa valutazione richiede pochi giorni utilizzando gli strumenti di migrazione, anziché settimane di scripting manuale.
Fase 2 — Risultati rapidi. Scegli carichi di lavoro che uniscono un basso rischio di migrazione a casi d'uso ad alta visibilità aziendale. Ciò potrebbe significare iniziare con pesanti job SQL facili da convertire, o con pipeline di reporting che presentino presto la nuova piattaforma agli stakeholder. Le istruzioni semplici diventeranno task SQL in Workflows. La logica procedurale diventa stored procedure. Utilizza transpiler e conversioni assistite dall'AI per la traduzione iniziale. Esegui entrambi i sistemi in parallelo e confronta il numero di righe, i checksum e i record di esempio. L'obiettivo è creare fiducia, sia a livello tecnico che organizzativo.
Walgreens, ad esempio, ha dismesso il Teradata on-premises in una migrazione graduale e ora elabora circa 40.000 eventi di dati al secondo sul lakehouse, ottimizzando la supply chain in quasi 9.000 negozi.
Fase 3 — Modernizzazione. Ora riprogetta le pipeline che vale la pena modernizzare. I candidati ideali: flussi in cui i vincoli di qualità dei dati e la lineage riducono i controlli manuali, job batch che beneficiano di tabelle di streaming e CDC, pipeline in cui le viste materializzate riducono la complessità, e i metadati, i permessi e l'audit che prima risiedevano in strumenti separati, ora consolidati in Unity Catalog. Un pattern comune consiste nel mantenere la procedura legacy come fallback mentre la nuova pipeline viene eseguita in parallelo fino al superamento della convalida. Le pipeline modernizzate spesso riducono le finestre batch da ore a minuti ed eliminano la necessità di strumenti di DQ separati.
Fase 4 — Ottimizzazione. Consolida le pipeline ETL ridondanti che esistevano solo per aggirare i limiti dei vecchi DW. Sposta i punti critici complessi su PySpark quando questo semplifica la logica. Rivedi i confini tra batch e streaming ora che disponi di un motore unificato. È qui che la migrazione ripaga: la piattaforma legacy è spenta, le pipeline ridondanti sono eliminate e l'architettura viene eseguita su un unico sistema invece di due.
Gli strumenti di migrazione automatizzano il lavoro meccanico ma non sostituiscono le decisioni architetturali. Tre ruoli tipici:
Un approccio pragmatico: lascia che gli strumenti coprano il 60-80% della conversione iniziale e riserva il tempo degli ingegneri per i pattern che desideri effettivamente modernizzare. In questo modo si evita un porting uno-a-uno del debito tecnico.
Le migrazioni di successo dismettono attivamente i sistemi, non si limitano a convertire il codice: server di pianificazione standalone, framework DQ personalizzati, strumenti separati di lineage e metadati, compilatori di stored procedure specifici del fornitore e sistemi di convalida artigianali. La migrazione non è completata finché questi sistemi non vengono spenti e i relativi costi azzerati.
Se l'ETL SQL rimane frammentato tra motori, livelli e strumenti, la piattaforma rimarrà frammentata, anche se i dati risiedono in formati aperti.
Non esiste un unico modo corretto per migrare le pipeline di dati. Il lakehouse ti consente di raggiungere l'obiettivo rapidamente: task semplici per logiche semplici, stored procedure quando hai bisogno di un controllo procedurale. SDP ti offre pipeline ETL moderne con qualità e lineage integrate. I notebook gestiscono il resto, sia che tu scelga PySpark o Spark SQL.
Esplora la Guida alla migrazione di Databricks per procedure dettagliate tecniche, o provala tu stesso con la Databricks Free Edition.
(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale
Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.