Quando partizionare le tabelle in Azure Databricks

La maggior parte delle tabelle in Azure Databricks con meno di 100 TB di dati non richiede il partizionamento. Azure Databricks usa Delta Lake per tutte le tabelle per impostazione predefinita e raggruppa automaticamente i dati in tabelle non partizionate in base al tempo di inserimento, in modo da ottenere prestazioni simili al partizionamento senza ottimizzazione manuale. Si consideri una strategia di partizionamento personalizzata solo quando supera queste impostazioni predefinite. Vedi Usare il clustering del tempo di inserimento.

Strategie di partizionamento personalizzate

Gli utenti avanzati di Apache Spark e Delta Lake potrebbero individuare una strategia di partizionamento che offre prestazioni migliori rispetto al clustering predefinito in base al momento di inserimento.

Prima di usare strategie di partizionamento personalizzate, Databricks consiglia il clustering liquido per tutte le tabelle e l'ottimizzazione predittiva per le tabelle gestite di Unity Catalog. Vedere Usare il clustering liquido per le tabelle e l'ottimizzazione predittiva per le tabelle gestite di Unity Catalog.

Per convertire una tabella Delta Lake partizionata esistente al clustering liquido, usa ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Il clustering liquido funziona sia per le colonne di cardinalità bassa che per le colonne ad alta cardinalità ed evita i limiti di partizione fissi e i problemi di file di piccole dimensioni comuni con il partizionamento statico. Vedi Convertire una tabella partizionata in un clustering liquido.

Tipi di dati supportati per le colonne di partizione

Il partizionamento supporta questi tipi di dati per le colonne di partizione:

• Date
• Timestamp:
• TimestampNTZ
• Intervallo
• String
• Binary
• Boolean
• Intero, Lungo, Corto, Byte
• Virgola mobile, Doppio, Decimale

Le colonne di partizione devono essere colonne di primo livello. Non è possibile partizionare in base a una delle opzioni seguenti:

• Tipi complessi, ad esempio StructType, MapType, ArrayTypeo VariantType
• Campi della struct, ad esempio struct_col.field. Delta Lake considera un campo struct in PARTITIONED BY come espressione anziché come riferimento a una colonna.

Per organizzare una tabella in base a un campo struct, usare invece il clustering liquido, che riconosce un campo struct come chiave di clustering. Il clustering liquido è l'unico modo per saltare i dati in un campo di una struct senza prima estrarlo in una colonna di primo livello. Vedere Usare clustering liquido per le tabelle.

Consigli per le dimensioni minime

È probabile che il partizionamento al di sotto di queste dimensioni minime influisca negativamente sulle prestazioni delle query anziché migliorarlo. Quando si decide se partizionare una tabella, tenere presente quanto segue:

• Per le tabelle:
  • Con meno di 1 TB di dati, non partizionare.
  • Con più di 1 TB a 100 TB di dati, usare il clustering liquido anziché il partizionamento. Il partizionamento influisce probabilmente negativamente sulle prestazioni più spesso di quanto sia utile.
  • Con 100 TB o più di dati, il partizionamento potrebbe migliorare le prestazioni, ma Databricks consiglia di usare prima il clustering liquido e verificare i miglioramenti delle prestazioni.
• Per le partizioni, verificare che ogni partizione contenga almeno 1 GB 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 ingestione

Con Delta Lake, le tabelle non partizionate usano automaticamente il clustering in base all'ora di acquisizione. L’ora di ingestione consente di migliorare le prestazioni delle query in modo simile alle strategie di partizionamento basate su campi datetime, senza dover ottimizzare o regolare manualmente i propri dati.

Compatibilità del partizionamento tra Delta Lake e Parquet

Delta Lake usa Parquet per l'archiviazione dei dati e alcune tabelle Delta Lake partizionate hanno layout di dati simili 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 Lake.

Databricks consiglia di interagire con i dati archiviati in Delta Lake usando client e API ufficialmente supportati. Molte funzionalità di Delta Lake interrompono i presupposti sul layout dei dati che potrebbero essere stati usati con Parquet, Hive o persino versioni precedenti del protocollo Delta Lake.

Partizionamento di Delta Lake a confronto con altri data lake

Le tecniche di partizionamento utili in altre tecnologie di open source (ad esempio Apache Spark, Parquet, Hive e Hadoop) non sono sempre valide per Azure Databricks. Se si sceglie di partizionare la tabella, tenere presente quanto segue:

• Le transazioni non sono definite dai limiti della partizione. Poiché Delta Lake garantisce ACID tramite i log delle transazioni, non è necessario separare un batch di dati da una partizione per garantire l'atomicità.
• I cluster di calcolo di Azure Databricks non hanno la località dei dati associata ai supporti fisici. I dati inseriti nel lakehouse vengono archiviati nello storage di oggetti nel 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.

Ordine Z e partizioni

È possibile usare gli indici dell'ordine Z insieme alle partizioni per velocizzare le query su set di dati di grandi dimensioni. La maggior parte delle tabelle usa il clustering del tempo di inserimento per evitare di dover ottimizzare l'ordine Z e le partizioni.

Tenere presenti le regole seguenti quando si pianifica una strategia di ottimizzazione delle query in base ai limiti delle partizioni e all'ordine Z:

• L'ordine Z richiede 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 quelli con cardinalità elevata e quelli che possono crescere all'infinito (ad esempio, timestamp o ID cliente in una tabella di transazioni o ordini).
• Non è possibile ordinare Z nei campi utilizzati per il partizionamento.

Come Azure Databricks ottimizza le partizioni esistenti

Molti clienti eseguono la migrazione a Delta Lake da data lake basati su Parquet, ad esempio usando l'istruzione CONVERT TO DELTA per convertire una tabella basata su Parquet esistente in una tabella Delta Lake senza riscrivere i dati esistenti. Poiché la conversione non riscrive i dati esistenti, le tabelle di grandi dimensioni potrebbero ereditare strategie di partizionamento precedenti.

Alcune ottimizzazioni di Databricks usano queste partizioni quando possibile, riducendo gli effetti negativi sulle prestazioni per le strategie di partizionamento non ottimizzate per Delta Lake.

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