Modellazione dei dati

Questo articolo presenta considerazioni, avvertenze e consigli per la modellazione dei dati in Azure Databricks. È destinato agli utenti che configurano nuove tabelle o creano carichi di lavoro ETL, con particolare attenzione alla comprensione dei comportamenti di Azure Databricks che influenzano la trasformazione dei dati non elaborati in un nuovo modello di dati. Le decisioni di modellazione dei dati dipendono dal modo in cui l'organizzazione e i carichi di lavoro usano le tabelle. Il modello di dati scelto influisce sulle prestazioni delle query, sui costi di calcolo e sui costi di archiviazione. Include un'introduzione ai concetti fondamentali della progettazione di database con Azure Databricks.

Importante

Questo articolo si applica esclusivamente alle tabelle supportate da Delta Lake, che include tutte le tabelle gestite di Unity Catalog.

È possibile usare Azure Databricks per eseguire query su altre origini dati esterne, incluse le tabelle registrate con Lakehouse Federation. Ogni origine dati esterna presenta limitazioni, semantiche e garanzie transazionali diverse. Vedi Consultare i dati.

Concetti relativi alla gestione dei database

Una lakehouse creata con Azure Databricks condivide molti componenti e concetti con altri sistemi di data warehousing aziendali. Prendere in considerazione i concetti e le funzionalità seguenti durante la progettazione del modello di dati.

Transazioni in Azure Databricks

Azure Databricks definisce l'ambito delle transazioni in singole tabelle. Ciò significa che Azure Databricks non supporta istruzioni con più tabelle (dette anche transazioni con più istruzioni).

Per i carichi di lavoro di modellazione dei dati, ciò comporta la necessità di eseguire più transazioni indipendenti quando l'inserimento di un record di origine richiede di inserire o aggiornare righe in due o più tabelle. Ciascuna di queste transazioni può avere esito positivo o negativo indipendentemente dalle altre transazioni e le query downstream devono tollerare la discrepanza di stato a causa di transazioni non riuscite o ritardate.

Chiavi primarie ed esterne in Azure Databricks

Le chiavi primarie ed esterne sono informative e non vincolate. Questo modello è comune in molti sistemi di database basati sul cloud aziendale, ma differisce da molti sistemi di database relazionali tradizionali. Consultare Vincoli su Azure Databricks.

Join su Azure Databricks

I join possono causare colli di bottiglia nell'elaborazione in qualsiasi progettazione di database. Durante l'elaborazione dei dati in Azure Databricks, Query Optimizer cerca di ottimizzare il piano per i join, ma può avere difficoltà quando una singola query deve unire i risultati da molte tabelle. L'ottimizzatore può anche non riuscire a ignorare i record in una tabella quando i parametri di filtro si trovano in un campo in un'altra tabella, il che può comportare una scansione completa della tabella.

Consultare Usare join su Azure Databricks.

Nota

È possibile usare viste materializzate per calcolare in modo incrementale i risultati per alcune operazioni di join, ma altri join non sono compatibili con le viste materializzate. Vedere Viste materializzate.

Uso di tipi di dati annidati e complessi

Azure Databricks supporta l'uso di origini dati semistrutturate, tra cui JSON, Avro e ProtoBuff, e l'archiviazione di dati complessi come struct, stringhe JSON e mappe e matrici. Vedere Modello di dati semistrutturati.

Modelli di dati normalizzati

Azure Databricks può funzionare bene con qualsiasi modello di dati. Se si dispone di un modello di dati esistente che è necessario eseguire una query da o eseguire la migrazione ad Azure Databricks, è necessario valutare le prestazioni prima di riprogettare i dati.

Se si progetta un nuovo lakehouse o si aggiungono set di dati a un ambiente esistente, Azure Databricks sconsiglia l'uso di un modello fortemente normalizzato, ad esempio il terzo formato normale (3NF).

I modelli come lo schema star o lo schema snowflake funzionano bene in Azure Databricks, in quanto sono presenti meno join nelle query standard e meno chiavi da mantenere sincronizzate. Inoltre, la presenza di più campi dati in una singola tabella consente a Query Optimizer di ignorare grandi quantità di dati usando statistiche a livello di file. Per ulteriori informazioni sul data skipping, consultare Data skipping per Delta Lake.