Modellazione dei dati

Le decisioni di modellazione dei dati dipendono dal modo in cui l'organizzazione e i carichi di lavoro usano le tabelle e il modello scelto influisce sulle prestazioni delle query, sui costi di calcolo e sui costi di archiviazione. Questa pagina illustra i comportamenti Azure Databricks che influenzano la modellazione dei dati, per gli utenti che configurano nuove tabelle o creano carichi di lavoro ETL.

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

Di default, Azure Databricks applica le transazioni a singole tabelle. 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.

Le tabelle con commit del catalogo abilitati possono partecipare alle transazioni che si estendono su più istruzioni e più tabelle. Vedere Transazioni.

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 Protobuf 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 altre informazioni sull'omissione dei dati, vedere Ignorare i dati.