Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Note
In Databricks Runtime 13.3 e versioni successive Databricks consiglia di usare il clustering liquido per il layout di tabella. Il clustering non è compatibile con l'ordinamento Z. Vedere Usare clustering liquido per le tabelle.
Le statistiche per il data skipping vengono raccolte automaticamente quando si scrivono dati in una tabella Delta Lake o in una tabella Apache Iceberg gestita. Azure Databricks usa statistiche per file (valori minimi e massimi, conteggi null e record totali) in fase di query per ignorare i file irrilevanti e velocizzare le query.
Dovresti avere statistiche raccolte per le colonne utilizzate nelle ZORDER istruzioni. Vedere Che cos'è l'ordinamento Z?.
Specificare le colonne delle statistiche
Per le tabelle esterne di Unity Catalog, le statistiche vengono raccolte nelle prime 32 colonne definite nello schema di tabella per impostazione predefinita. Per le tabelle gestite di Unity Catalog, le statistiche di salto dei file vengono scelte in modo intelligente usando l'ottimizzazione predittiva e non hanno un limite di 32 colonne. L'ottimizzazione predittiva esegue ANALYZEautomaticamente , un comando per la raccolta di statistiche. Databricks consiglia di abilitare l'ottimizzazione predittiva per tutte le tabelle gestite di Unity Catalog per semplificare la manutenzione dei dati e ridurre i costi di archiviazione. Consulta Ottimizzazione predittiva per le tabelle gestite di Unity Catalog.
Se non si usa l'ottimizzazione predittiva, è possibile modificare il comportamento che limita le raccolte statistiche a 32 colonne impostando una delle proprietà della tabella seguenti:
| Proprietà della Tabella | Databricks Runtime è supportato | Description |
|---|---|---|
dataSkippingNumIndexedCols |
Tutte le versioni supportate di Databricks Runtime | Aumentare o ridurre il numero di colonne in cui vengono raccolte le statistiche. Dipende dall'ordine delle colonne. |
dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS e versioni successive | Specificare un elenco di nomi di colonna per i quali vengono raccolte le statistiche. "Sostituisce dataSkippingNumIndexedCols." |
Le proprietà della tabella possono essere impostate durante la creazione di tabelle o con ALTER TABLE istruzioni . Vedere Informazioni di riferimento sulle proprietà della tabella. Nell'esempio seguente viene eseguito l'override del comportamento predefinito della raccolta di statistiche per impostare la raccolta di statistiche sulle colonne denominate:
Delta Lake
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')
Tabella Iceberg
ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')
L'aggiornamento di queste proprietà non ricompila automaticamente le statistiche per i dati esistenti. Influisce invece sul comportamento della raccolta di statistiche future durante l'aggiunta o l'aggiornamento dei dati nella tabella. Le statistiche non vengono usate per le colonne non incluse nell'elenco corrente di colonne statistiche.
In Databricks Runtime 14.3 LTS e versioni successive, se sono state modificate le proprietà della tabella o sono state modificate le colonne specificate per le statistiche, è possibile attivare manualmente la ricomputazione delle statistiche per una tabella usando il comando seguente:
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
Note
Le stringhe lunghe vengono troncate durante la raccolta di statistiche. È possibile scegliere di escludere colonne stringa lunghe dalla raccolta di statistiche, soprattutto se le colonne non vengono usate di frequente per filtrare le query.
Che cos'è l'ordinamento Z?
Note
Databricks consiglia di usare il clustering liquido per tutte le nuove tabelle. Non è possibile usare ZORDER in combinazione con il clustering liquido. Vedere Usare clustering liquido per le tabelle.
L'ordinamento Z è una tecnica per la colocazione di informazioni correlate nello stesso set di file. Gli algoritmi di data-skipping di Azure Databricks usano automaticamente questa co-località. Questo comportamento riduce la quantità di dati da leggere. Per ordinare i dati Z, specificare le colonne da ordinare nella ZORDER BY clausola :
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
Se si prevede che una colonna venga comunemente usata nei predicati di query e se tale colonna ha cardinalità elevata , ovvero un numero elevato di valori distinti, usare ZORDER BY.
È possibile specificare più colonne per ZORDER BY come elenco delimitato da virgole. Tuttavia, l'efficacia scende con ogni colonna aggiuntiva.
Databricks consiglia di non usare ZORDER BY nelle colonne che non dispongono di statistiche raccolte perché non è inefficace e usa risorse di calcolo non necessarie. L’esclusione dei dati richiede statistiche a livello di colonna, come minimo, massimo e conteggio. È possibile configurare la raccolta di statistiche per determinate colonne riordinando le colonne nello schema oppure aumentando il numero di colonne per raccogliere statistiche.
Note
L'ordinamento Z non è idempotente , ma mira a essere un'operazione incrementale. Non è garantito che il tempo necessario per l'ordinamento Z si riduca nel corso di più esecuzioni. Tuttavia, se non sono stati aggiunti nuovi dati a una partizione appena ordinata Z, un altro ordinamento Z di tale partizione non ha alcun effetto.
L'ordinamento Z mira a produrre file di dati uniformemente bilanciati rispetto al numero di tuple, ma non necessariamente alle dimensioni dei dati nell'archiviazione. Sebbene le dimensioni dei file e il numero di tuple siano correlati, possono verificarsi situazioni in cui questa correlazione non sussiste, alterando i tempi delle operazioni di ottimizzazione.
Ad esempio, se si
ZORDER BYdata e i record più recenti sono tutti molto più grandi (ad esempio array o valori stringa più lunghi) rispetto a quelli precedenti,OPTIMIZEla durata delle attività del job e le dimensioni dei file risultanti potrebbero risultare alterate. Si tratta, tuttavia, solo di un problema per ilOPTIMIZEcomando stesso. È probabile che non abbia effetti negativi sulle query successive.