Quando partizionare le tabelle in Azure Databricks

Nota

Databricks consiglia di usare il clustering liquido per tutte le nuove tabelle Delta. Vedere Usare il clustering liquido per le tabelle Delta.

I cluster liquidi vengono talvolta definiti anche "partizioni liquide". Questo articolo si riferisce solo al partizionamento delta legacy e non al clustering liquido.

Questo articolo offre una panoramica di come è possibile partizionare le tabelle in Azure Databricks e raccomandazioni specifiche relative all'uso del partizionamento per le tabelle supportate da Delta Lake. A causa di funzionalità e ottimizzazioni predefinite, la maggior parte delle tabelle con meno di 1 TB di dati non richiede partizioni.

Azure Databricks usa Delta Lake per tutte le tabelle per impostazione predefinita. I consigli seguenti presuppongono che si stia lavorando con Delta Lake per tutte le tabelle.

In Databricks Runtime 11.3 LTS e versioni successive Azure Databricks raggruppa automaticamente i dati in tabelle non partizionate in base al tempo di inserimento. Vedere Usare il clustering del tempo di inserimento.

Le tabelle di piccole dimensioni devono essere partizionate?

Databricks consiglia di non partizionare le tabelle che contengono meno di un terabyte di dati.

Quali sono le dimensioni minime per ogni partizione in una tabella?

Databricks consiglia che tutte le partizioni contengano almeno un gigabyte di dati. Le tabelle con meno partizioni di dimensioni maggiori tendono a superare le prestazioni delle tabelle con molte partizioni più piccole.

Usare il clustering del tempo di inserimento

Usando Delta Lake e Databricks Runtime 11.3 LTS o versione successiva, le tabelle non partizionate che si creano traggono vantaggio automaticamente dal clustering tempo di inserimento. Il tempo di inserimento offre vantaggi di query simili alle strategie di partizionamento in base ai campi datetime senza dover ottimizzare o ottimizzare i dati.

Nota

Per mantenere il clustering del tempo di inserimento quando si esegue un numero elevato di modifiche usando UPDATE istruzioni o MERGE in una tabella, Databricks consiglia di eseguire OPTIMIZE con ZORDER BY usando una colonna che corrisponde all'ordine di inserimento. Ad esempio, potrebbe trattarsi di una colonna contenente un timestamp dell'evento o una data di creazione.

Delta Lake e Parquet condividono strategie di partizionamento?

Delta Lake usa Parquet come formato principale per l'archiviazione dei dati e alcune tabelle Delta con partizioni specificate illustrano l'organizzazione simile alle tabelle Parquet archiviate con Apache Spark. Apache Spark usa il partizionamento in stile Hive durante il salvataggio dei dati in formato Parquet. Il partizionamento in stile Hive non fa parte del protocollo Delta Lake e i carichi di lavoro non devono basarsi su questa strategia di partizionamento per interagire con le tabelle Delta.

Molte funzionalità di Delta Lake interrompono i presupposti sul layout dei dati che potrebbero essere stati trasferiti da parquet, Hive o persino versioni precedenti del protocollo Delta Lake. È consigliabile interagire sempre con i dati archiviati in Delta Lake usando client e API ufficialmente supportati.

In che modo le partizioni Delta Lake sono diverse dalle partizioni in altri data lake?

Anche se Azure Databricks e Delta Lake si basano su tecnologie open source come Apache Spark, Parquet, Hive e Hadoop, le motivazioni e le strategie di partizionamento utili in queste tecnologie in genere non sono valide per Azure Databricks. Se si sceglie di partizionare la tabella, prendere in considerazione i fatti seguenti prima di scegliere una strategia:

• Le transazioni non sono definite dai limiti della partizione. Delta Lake garantisce l'acid tramite i log delle transazioni, pertanto non è necessario separare un batch di dati da una partizione per garantire l'individuazione atomica.
• I cluster di calcolo di Azure Databricks non hanno la località dei dati associata ai supporti fisici. I dati inseriti nel lakehouse vengono archiviati nell'archiviazione di oggetti cloud. Mentre i dati vengono memorizzati nella cache nell'archiviazione su disco locale durante l'elaborazione dei dati, Azure Databricks usa statistiche basate su file per identificare la quantità minima di dati per il caricamento parallelo.

Come funzionano le partizioni e l'ordine Z?

È possibile usare gli indici dell'ordine Z insieme alle partizioni per velocizzare le query su set di dati di grandi dimensioni.

Nota

La maggior parte delle tabelle può sfruttare il clustering del tempo di inserimento per evitare la necessità di preoccuparsi dell'ottimizzazione dell'ordine Z e della partizione.

Le regole seguenti sono importanti da tenere presenti durante la pianificazione di una strategia di ottimizzazione delle query in base ai limiti delle partizioni e all'ordine Z:

• L'ordine Z funziona in combinazione con il OPTIMIZE comando . Non è possibile combinare i file attraverso i limiti delle partizioni e quindi il clustering dell'ordine Z può verificarsi solo all'interno di una partizione. Per le tabelle non partizionate, i file possono essere combinati nell'intera tabella.
• Il partizionamento funziona correttamente solo per i campi di cardinalità bassa o nota (ad esempio, i campi di data o le posizioni fisiche), ma non per i campi con cardinalità elevata, ad esempio timestamp. L'ordine Z funziona per tutti i campi, inclusi campi e campi di cardinalità elevata che possono aumentare all'infinito (ad esempio, timestamp o ID cliente in una tabella transazioni o ordini).
• Non è possibile ordinare Z nei campi utilizzati per il partizionamento.

Se le partizioni sono così cattive, perché alcune funzionalità di Azure Databricks le usano?

Le partizioni possono essere utili, soprattutto per tabelle molto grandi. Molti miglioramenti delle prestazioni relativi al partizionamento sono incentrati su tabelle molto grandi (centinaia di terabyte o superiori).

Molti clienti esecuno la migrazione a Delta Lake da data lake basati su Parquet. L'istruzione CONVERT TO DELTA consente di convertire una tabella basata su Parquet esistente in una tabella Delta senza riscrivere i dati esistenti. Di conseguenza, molti clienti dispongono di tabelle di grandi dimensioni che ereditano strategie di partizionamento precedenti. Alcune ottimizzazioni sviluppate da Databricks cercano di sfruttare queste partizioni quando possibile, riducendo alcuni potenziali svantaggi per le strategie di partizionamento non ottimizzate per Delta Lake.

Delta Lake e Apache Spark sono tecnologie open source. Anche se Databricks continua a introdurre funzionalità che riducono la dipendenza dal partizionamento, la community open source potrebbe continuare a creare nuove funzionalità che aggiungono complessità.

È possibile ottenere prestazioni migliori per le ottimizzazioni predefinite di Azure Databricks con il partizionamento personalizzato?

Alcuni utenti esperti di Apache Spark e Delta Lake potrebbero essere in grado di progettare e implementare un modello che offre prestazioni migliori rispetto al clustering del tempo di inserimento. L'implementazione di uno stato di partizionamento non valido può avere ripercussioni molto negative sulle prestazioni downstream e potrebbe richiedere una riscrittura completa dei dati da correggere. Databricks consiglia alla maggior parte degli utenti di usare le impostazioni predefinite per evitare di introdurre inefficienze costose.