Trasforma dati
Questo articolo offre un'introduzione e una panoramica della trasformazione dei dati con Azure Databricks. La trasformazione dei dati, o la preparazione dei dati, è un passaggio chiave in tutti i carichi di lavoro di ingegneria, analisi e Machine Learning.
I modelli e i suggerimenti di esempio in questo articolo si concentrano sull'uso del lakehouse tables, supportato da Delta Lake. Poiché Delta Lake fornisce le garanzie ACID di un lakehouse di Databricks, è possibile osservare un comportamento diverso quando si usano dati in altri formati o sistemi dati.
Databricks consiglia di inserire dati in un lakehouse in uno stato non elaborato o quasi non elaborato e quindi di applicare trasformazioni e arricchimenti come passaggio di elaborazione separato. Questo modello è noto come architettura medallion. Vedere Che cos'è l'architettura lakehouse medallion?.
Se si sa che i dati da trasformare non sono ancora stati caricati in un lakehouse, vedere Inserire dati in una databricks lakehouse. Se si sta provando a trovare dati lakehouse per scrivere trasformazioni, vedere Individuare i dati.
Tutte le trasformazioni iniziano scrivendo una query batch o di streaming su un'origine dati. Se non si ha familiarità con l'esecuzione di query sui dati, vedere Eseguire query sui dati.
Dopo aver salvato i dati trasformati in un tableDelta, puoi usare tale table come una table di caratteristica per l'apprendimento automatico. Vedere Progettazione e gestione delle funzionalità.
Nota
Gli articoli qui illustrano le trasformazioni in Azure Databricks. Azure Databricks supporta anche connections a molte piattaforme comuni di preparazione dei dati. Vedere Connettersi ai partner di preparazione dei dati tramite Partner Connect.
Trasformazioni Spark e trasformazioni lakehouse
Questo articolo è incentrato sulla definizione delle tranformationi in relazione alla T in ETL o ELT. Il modello di elaborazione apache Spark usa anche la trasformazione della parola in modo correlato. Brevemente: in Apache Spark tutte le operazioni vengono definite come trasformazioni o azioni.
- Trasformazioni: aggiungere una logica di elaborazione al piano. Alcuni esempi includono la lettura di dati, join, aggregazioni e cast dei tipi.
- Azioni: attivare la logica di elaborazione per valutare e restituire un risultato. Gli esempi includono scritture, visualizzazione o anteprima dei risultati, memorizzazione nella cache manuale o recupero del numero di righe.
Apache Spark usa un modello di esecuzione differita, ovvero nessuno della logica definita da una raccolta di operazioni viene valutato fino a quando non viene attivata un'azione. Questo modello ha una ramificazione importante quando si definiscono le pipeline di elaborazione dati: usare solo le azioni per salvare i risultati in una destinazione table.
Poiché le azioni rappresentano un collo di bottiglia di elaborazione per l'ottimizzazione della logica, Azure Databricks ha aggiunto numerose ottimizzazioni oltre a quelle già presenti in Apache Spark per garantire un'esecuzione ottimale della logica. Queste ottimizzazioni considerano tutte le trasformazioni attivate da una determinata azione contemporaneamente e trovano il piano ottimale in base al layout fisico dei dati. La memorizzazione manuale nella cache dei dati o la restituzione dei risultati dell'anteprima nelle pipeline di produzione può interrompere queste ottimizzazioni e causare un aumento significativo dei costi e della latenza.
È quindi possibile definire una trasformazione lakehouse per essere una raccolta di operazioni applicate a una o più tables lakehouse che comportano un nuovo lakehouse table. Si noti che, mentre le trasformazioni come join e aggregazioni vengono illustrate separatamente, è possibile combinare molti di questi modelli in un unico passaggio di elaborazione e considerare attendibili gli ottimizzatori in Azure Databricks per trovare il piano più efficiente.
Quali sono le differenze tra lo streaming e l'elaborazione batch?
Mentre lo streaming e l'elaborazione batch usano gran parte della stessa sintassi in Azure Databricks, ognuno ha una propria semantica specifica.
L'elaborazione batch consente di definire istruzioni esplicite per elaborare una quantità fissa di dati statici e non modificati come singola operazione.
L'elaborazione del flusso consente di definire una query su un set di dati non associato e in continua crescita e quindi elaborare i dati in batch incrementali di piccole dimensioni.
Le operazioni batch in Azure Databricks usano Spark SQL o DataFrame, mentre l'elaborazione del flusso sfrutta structured streaming.
È possibile distinguere i comandi di Apache Spark batch da Structured Streaming esaminando le operazioni di lettura e scrittura, come illustrato nella tableseguente:
| Apache Spark | Structured Streaming | |
|---|---|---|
| Lettura | spark.read.load() |
spark.readStream.load() |
| Scrittura | spark.write.save() |
spark.writeStream.start() |
I views materializzati sono generalmente conformi alle garanzie di elaborazione batch, anche se Delta Live Tables viene usato per calcolare i risultati in modo incrementale, quando possibile. I risultati restituiti da una vista materializzata sono sempre equivalenti alla valutazione batch della logica, ma Azure Databricks cerca di elaborare questi risultati in modo incrementale, quando possibile.
Lo streaming tables calcola sempre i risultati in modo incrementale. Poiché molte origini dati di streaming mantengono i record solo per un periodo di ore o giorni, il modello di elaborazione usato dallo streaming tables presuppone che ogni batch di record di un'origine dati venga elaborato una sola volta.
Azure Databricks supporta l'uso di SQL per scrivere query di streaming nei casi d'uso seguenti:
- Definizione dello streaming tables in Unity Catalog utilizzando Databricks SQL.
- Definizione del codice sorgente per le pipeline Delta Live Tables.
Nota
È anche possibile dichiarare lo streaming tables in Delta Live Tables utilizzando il codice Python Structured Streaming.
Trasformazioni batch
Le trasformazioni batch operano su un set ben definito di risorse di dati in un momento specifico. Le trasformazioni batch possono essere operazioni monouso, ma spesso fanno parte di processi o pipeline pianificati eseguiti regolarmente per mantenere aggiornati i sistemi di produzione.
Trasformazioni incrementali
I modelli incrementali presuppongono generalmente che l'origine dati sia solo append e abbia un schemastabile. Gli articoli seguenti forniscono dettagli sulle sfumature delle trasformazioni incrementali sui tables che subiscono aggiornamenti, eliminazioni o cambiamenti dei schema:
- LE API APPLY CHANGES: Semplifica l'acquisizione di dati di modifica con Delta Live Tables
- Usare il feed di dati delle modifiche delta Lake in Azure Databricks
- Update Delta Lake tableschema
- Delta table letture e scritture in streaming
Trasformazioni in tempo reale
Delta Lake offre un accesso quasi in tempo reale a grandi quantità di dati per tutti gli utenti e le applicazioni che eseguono query sul lakehouse, ma a causa del sovraccarico con la scrittura di file e metadati nell'archiviazione di oggetti cloud, non è possibile raggiungere una latenza in tempo reale reale per molti carichi di lavoro che scrivono in sink Delta Lake.
Per le applicazioni di streaming a bassa latenza, Databricks consiglia di scegliere sistemi di origine e sink progettati per carichi di lavoro in tempo reale, ad esempio Kafka. È possibile usare Azure Databricks per arricchire i dati, incluse le aggregazioni, i join tra flussi e unire dati di streaming con dati delle dimensioni a modifica lenta archiviati nella lakehouse.