Quando partitiontables in Azure Databricks

Questo articolo offre una panoramica di come è possibile partitiontables in Azure Databricks e consigli specifici su quando è consigliabile usare il partizionamento per tables supportato da Delta Lake. A causa di funzionalità e ottimizzazioni predefinite, la maggior parte delle tables con meno di 1 TB di dati non richiede partizioni.

Azure Databricks usa Delta Lake per tutti i tables come impostazione predefinita. I seguenti consigli presumono che stiate lavorando con Delta Lake per tutti i casi relativi a tables.

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

È necessario partizionare i piccoli tables?

Databricks consiglia di non partitiontables che contiene meno di un terabyte di dati.

Quali sono le dimensioni minime per ogni partition in un table?

Databricks consiglia che tutte le partizioni contengano almeno un gigabyte di dati. Tables con meno partizioni di dimensioni maggiori tendono a ottenere prestazioni superiori tables con molte partizioni più piccole.

Usare il clustering del tempo di inserimento

Usando Delta Lake e Databricks Runtime 11.3 LTS o versione successiva, i tables non partizionati beneficiano automaticamente del clustering al momento dell'inserimento . Il tempo di inserimento offre vantaggi di query simili alle strategie di partizionamento in base ai campi datetime senza dover optimize o ottimizzare i dati.

Delta Lake e Parquet condividono strategie di partizionamento?

Delta Lake usa Parquet come formato principale per l'archiviazione dei dati, e alcune tables Delta con partizioni specificate dimostrano un'organizzazione simile a quella di Parquet tables archiviato 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 parte del protocollo Delta Lake e i carichi di lavoro non devono basarsi su questa strategia di partizionamento per interagire con Delta tables.

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 scegli di partition il table, prendere in considerazione i seguenti fatti prima di scegliere una strategia.

• Le transazioni non sono definite dai limiti partition. Delta Lake garantisce ACID tramite i log delle transazioni, pertanto non è necessario separare un batch di dati da un partition 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.

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

• L'ordine Z funziona in combinazione con il OPTIMIZE comando . Non è possibile combinare file tra i limiti partition e pertanto il clustering dell'ordine Z può verificarsi solo all'interno di un partition. Per i tablesnon partizionati, i file possono essere combinati nell'intero table.
• 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 i campi di cardinalità elevata e quelli che possono crescere all'infinito (ad esempio, i timestamp o l'ID cliente in transazioni o ordini table).
• 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, in particolare con tablesdi dimensioni molto grandi. Numerosi miglioramenti delle prestazioni relativi al partizionamento sono incentrati su tables di dimensioni 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 un table esistente basato su Parquet in un table Delta senza riscrivere i dati esistenti. Di conseguenza, molti clienti hanno tables 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.