Raggruppamento dei dati nel Magazzino Dati Fabric

si applica a:✅ Magazzino di dati in Microsoft Fabric

Il clustering di dati è una tecnica usata per organizzare e archiviare i dati in base alla somiglianza. Il clustering di dati migliora le prestazioni delle query e riduce i costi di accesso alle risorse di calcolo e archiviazione per le query raggruppando record simili.

Come funziona

Il clustering di dati funziona archiviando righe con valori simili in posizioni adiacenti nell'archiviazione durante l'inserimento. Il clustering di dati usa una curva di riempimento dello spazio per organizzare i dati in modo da mantenere la località in più dimensioni, ovvero le righe con valori simili tra le colonne di clustering vengono archiviate fisicamente vicine. Questo approccio migliora notevolmente le prestazioni delle query ignorando il file e riducendo il numero di file analizzati.

A differenza dell'ordinamento lessicografico convenzionale, il clustering di dati usa un algoritmo sofisticato per elaborare, mantenendo le righe con valori di colonna simili vicine, anche quando una tabella è raggruppata su diverse colonne. In questo modo, il clustering di dati è ideale per le query di intervallo, i filtri a cardinalità elevata e le tabelle di grandi dimensioni con distribuzioni asimmetriche, ottenendo letture più veloci, operazioni di I/O ridotte e un utilizzo delle risorse più efficiente.

Ecco una illustrazione concettuale semplificata del clustering di dati:

In questo diagramma, una tabella etichettata Source data mostra le righe miste ed evidenziate in colori diversi per rappresentare i gruppi di clustering sulla destinazione. Una tabella Ordered è suddivisa in tre segmenti di file, ognuno dei quali raggruppa le righe in base a colori simili, dimostrando in che modo il clustering organizza i dati in segmenti di archiviazione ottimizzati in base ai valori di colonna.

I metadati del clustering di dati sono incorporati nel file manifesto durante l'inserimento, consentendo al motore del magazzino dati di prendere decisioni intelligenti sui file a cui accedere durante le query degli utenti. Questi metadati, combinati con il modo in cui le righe con valori simili vengono archiviate insieme garantiscono che le query con predicati di filtro possano ignorare interi file e gruppi di righe che rientrano nell'ambito del predicato. Ad esempio: se una query è destinata solo a 10% di dati di una tabella, il clustering garantisce che vengano analizzati solo i file che contengono i dati all'interno dell'intervallo del filtro, riducendo l'I/O e il consumo di calcolo. Le tabelle più grandi traggono maggior vantaggio dal clustering di dati, poiché i benefici dello skipping dei file aumentano con il volume di dati.

Quando usare il clustering di dati

Quando si decide se il clustering di dati può essere utile, esaminare i modelli di query e le caratteristiche delle tabelle nel warehouse. Il clustering dei dati è più efficace quando le query filtrano ripetutamente su colonne specifiche e quando le tabelle sottostanti sono di grandi dimensioni e contengono dati di cardinalità medio-elevati. Alcuni scenari comuni includono:

Query ripetute con WHERE filtri: se il carico di lavoro include query frequenti che filtrano colonne specifiche, il clustering di dati garantisce che solo i file rilevanti vengano analizzati durante le query di lettura. Questo vale anche quando i filtri vengono usati ripetutamente nei dashboard, nei report o nei processi pianificati e inseriti nel motore di warehouse come istruzioni SQL.
Tabelle più grandi: il clustering di dati è più efficace quando viene applicato a tabelle di grandi dimensioni in cui l'analisi del set di dati completo è costosa. Organizzando le righe con il clustering di dati, il motore del warehouse può ignorare interi file e gruppi di righe che non corrispondono al filtro di query, riducendo così l'utilizzo di I/O e calcolo.
Colonne con cardinalità media-alta: le colonne con cardinalità più elevata ,ad esempio le colonne con molti valori distinti, ad esempio un ID o una data, traggono vantaggio dal clustering di dati perché consentono al motore di isolare e raggruppare valori simili. In questo modo è possibile ignorare i file in modo efficiente, soprattutto per le query selettive. Le colonne con cardinalità bassa (ad esempio: sesso, area) per natura hanno valori distribuiti in più file, offrendo quindi opportunità limitate per il file-skipping.
Query selettive con ambito ristretto: quando le query sono in genere destinate a un piccolo subset di dati e vengono combinate con un filtro WHERE, il clustering di dati garantisce che vengano letti solo i file che contengono le righe pertinenti.

Il clustering dei dati viene eseguito automaticamente durante l'inserimento dei dati, indipendentemente dalla modalità di inserimento delle righe. Non sono necessarie operazioni utente dopo l'inserimento dei dati per applicare il clustering dei dati.

Sintassi CLUSTER BY

Il clustering di dati viene definito durante la creazione della tabella usando la CLUSTER BY clausola . La sintassi è la seguente:

Sintassi CREATE TABLE (Transact-SQL):

CREATE TABLE { warehouse_name.schema_name.table_name | schema_name.table_name | table_name } (
 [ ,... n ] –- Column list
) WITH (CLUSTER BY [ ,... n ]);

Sintassi CREATE TABLE AS SELECT (Transact-SQL) :

CREATE TABLE { warehouse_name.schema_name.table_name | schema_name.table_name | table_name } (
) WITH (CLUSTER BY[ ,... n ])
AS <select_statement>;

La CLUSTER BY clausola richiede almeno una colonna da specificare per il clustering di dati e un massimo di quattro colonne.

La creazione di una tabella che usa il clustering di dati con SELECT INTO non è supportata.

Supporto dei tipi di dati

Nella tabella seguente sono riepilogati i tipi di colonna che possono essere usati nella CLUSTER BY clausola :

Categoria	Tipo di dati	Supporto per il clustering dei dati
Numeri esatti	bit	NO
Numeri esatti	bigint, int, smallint, decimal², numeric	Yes
Numeri approssimativi	galleggia,vero	Yes
Data e ora	date, datetime2, time	Yes
Stringhe di caratteri¹	char	Yes
Stringhe di caratteri¹	varchar	Yes
Tipi LOB	varchar(max), varbinary(max)	NO
Stringhe binarie	varbinary, uniqueidentifier	NO

¹ Per i tipi stringa (char/varchar), vengono usati solo i primi 32 caratteri quando vengono generate statistiche di colonna. Di conseguenza, le colonne con valori che contengono prefissi lunghi potrebbero avere vantaggi limitati con il clustering di dati.

² Per i tipi decimali con precisione maggiore di 18, i predicati non vengono inseriti nell'archiviazione durante l'esecuzione delle query. Se si utilizzano tipi decimali con clustering di dati, favorire le colonne con minore precisione.

Le colonne con tipi di dati non supportati possono essere ancora presenti in una tabella che usa il clustering di dati, ma non può essere usata con CLUSTER BY.

Procedure consigliate per il clustering dei dati

Il clustering di dati è più efficace quando si selezionano colonne di clustering in base ai modelli di query effettivi, in particolare quelli con cardinalità media-alta e quando i predicati di intervallo vengono usati durante le query.

Quando si utilizza il clustering dei dati, prendere in considerazione le seguenti migliori pratiche:

Il clustering di dati è più efficace nelle tabelle di grandi dimensioni.
Quando possibile, l'inserimento in batch e gli aggiornamenti per elaborare un numero maggiore di righe contemporaneamente, anziché usare attività più piccole. Per ottenere prestazioni ottimali, le operazioni DML devono avere almeno 1 milione di righe per trarre vantaggio dal clustering dei dati. Dopo inserimenti, aggiornamenti ed eliminazioni consecutivi, la compattazione dei dati può consolidare le righe da file più piccoli in quelle di dimensioni ottimali.
Scegliere le colonne con cardinalità media-alta per il clustering di dati, in quanto producono risultati migliori a causa della distribuzione di valori distinti. Le colonne con cardinalità bassa possono offrire opportunità limitate per l'eliminazione dei file.
Selezionare le colonne in base all'uso frequente dei WHERE predicati nei cruscotti, nei report, nei lavori pianificati o nelle query degli utenti. Le condizioni di join di uguaglianza non traggono vantaggio dal clustering dei dati. Per una panoramica su come utilizzare Query Insights per selezionare colonne per il clustering dei dati basato sul carico di lavoro attuale, vedere Esercitazione: Uso del clustering dei dati nel Data Warehouse di Fabric.
Non usare il clustering di dati per più colonne rispetto a quanto strettamente necessario. Il clustering a più colonne aggiunge complessità all'archiviazione, aggiunge sovraccarico e potrebbe non offrire vantaggi a meno che tutte le colonne non vengano usate insieme nelle query con predicati.
L'ordine di colonna usato in CLUSTER BY non è importante e non modifica la modalità di archiviazione delle righe.
Quando si crea una tabella con clustering di dati usando CREATE TABLE AS SELECT (CTAS) o si inseriscono dati con INSERT INTO ... SELECT, mantenere la parte selezionata di queste istruzioni il più semplice possibile per una qualità ottimale del clustering dei dati.

Il clustering di dati può ridurre significativamente i costi durante le query, se ben allineato ai predicati di query. Tuttavia, l'inserimento dati comporta più tempo e unità di capacità (CU) in una tabella che usa il clustering di dati rispetto a una tabella equivalente con gli stessi dati senza clustering di dati. Ciò si verifica perché il motore del warehouse deve ordinare i dati durante l'inserimento. Poiché i dati inseriti vengono letti più volte, il clustering di dati può ridurre il consumo di calcolo complessivo di un determinato carico di lavoro.

Visualizzazioni di sistema

È possibile eseguire query sui metadati del clustering di dati usando sys.index_columns. Mostra tutte le colonne usate nel clustering di dati, incluso l'ordine della colonna usato nella clausola CLUSTER BY.

La query seguente elenca tutte le colonne usate nel raggruppamento di dati nel magazzino corrente e le relative tabelle.

SELECT
    t.name AS table_name,
    c.name AS column_name,
    ic.data_clustering_ordinal AS clustering_ordinal
FROM sys.tables t
JOIN sys.columns c
    ON t.object_id = c.object_id
JOIN sys.index_columns ic
    ON c.object_id = ic.object_id
   AND c.column_id = ic.column_id
WHERE ic.data_clustering_ordinal > 0
ORDER BY
    t.name,
    ic.data_clustering_ordinal;

Annotazioni

L'ordinale di colonna viene visualizzato per riferimento solo come ordine utilizzato in CLUSTER BY quando è stata definita la tabella. Come illustrato in Procedure consigliate, l'ordine delle colonne non influisce sulle prestazioni.

Limitazioni e osservazioni

Le prestazioni di inserimento dati possono peggiorare quando le tabelle contengono colonne varchar di grandi dimensioni con dimensioni di dati altamente variabili.
- Si consideri, ad esempio, una tabella con una colonna varchar(200): se alcune righe contengono solo pochi caratteri mentre altre si avvicinano alla lunghezza massima, la varianza significativa delle dimensioni dei dati può influire negativamente sulla velocità di inserimento.
- Questo problema è noto e verrà risolto in una versione futura.
IDENTITY non è possibile usare colonne con CLUSTER BY. Le tabelle che contengono una IDENTITY colonna possono comunque essere usate per il clustering di dati, dato che usa colonne diverse con CLUSTER BY.
Il clustering di dati deve essere definito al momento della creazione della tabella. La conversione di una tabella normale in una con CLUSTER BY non è supportata. Analogamente, la modifica delle colonne di clustering dopo la creazione di una tabella non è consentita. Se sono necessarie colonne di clustering diverse, usare CREATE TABLE AS SELECT facoltativamente (CTAS) per creare una nuova tabella con le colonne di clustering desiderate.
In alcuni casi, il clustering dei dati potrebbe essere applicato in modo asincrono. In questi casi, i dati vengono riorganizzati con un'attività in background e la tabella potrebbe non essere completamente ottimizzata al termine dell'inserimento. Ciò può verificarsi nelle condizioni seguenti:
- Quando si usano INSERT INTO ... SELECT o CREATE TABLE AS SELECT (CTAS) e le regole di confronto delle tabelle di origine e di destinazione sono diverse.
- Quando si importano dati da fonti esterne in formato CSV compresso.
- Quando un'istruzione di inserimento ha meno di 1 milione di righe.
L'inserimento dati nelle tabelle di clustering di dati comporta un sovraccarico rispetto a una tabella con lo stesso schema che non usa il clustering di dati. Ciò si verifica a causa di calcoli aggiuntivi necessari per ottimizzare l'archiviazione. Quando la colonna di clustering presenta regole di confronto senza distinzione tra maiuscole e minuscole, si prevede un sovraccarico maggiore.
Il clustering di dati può trarre vantaggio dal tempo di risposta alle query, dal consumo di unità di capacità (CU) o da entrambi.

Esempi

A. Crea una tabella clusterizzata per i dati di vendita

Questo esempio crea una tabella semplice Sales e utilizza le colonne CustomerID e SaleDate per il raggruppamento dei dati.

CREATE TABLE Sales (
    SaleID INT,
    CustomerID INT,
    SaleDate DATE,
    Amount DECIMAL(10,2)
) WITH (CLUSTER BY (CustomerID, SaleDate))

B. Creare una tabella in cluster usando CREATE TABLE AS SELECT

Questo esempio usa CREATE TABLE AS SELECT per creare una copia della Sales tabella esistente, con CLUSTER BY la SaleDate colonna .

CREATE TABLE Sales_CTAS 
WITH (CLUSTER BY (SaleDate)) 
AS SELECT * FROM Sales

C. Visualizzare le colonne usate per Il clustering di dati in una determinata tabella

In questo esempio vengono elencate le colonne usate per il clustering di dati nella Sales tabella.

SELECT
    c.name AS column_name,
    ic.data_clustering_ordinal AS clustering_ordinal
FROM sys.tables t
JOIN sys.columns c
    ON t.object_id = c.object_id
JOIN sys.index_columns ic
    ON c.object_id = ic.object_id
   AND c.column_id = ic.column_id
WHERE 
    ic.data_clustering_ordinal > 0
   AND t.name = 'Sales'
ORDER BY
    t.name,
    ic.data_clustering_ordinal;

Risultati:

D. Controllare l'efficacia delle opzioni di colonna per il clustering di dati

Query Insights consente di valutare l'effetto del clustering dei dati sul carico di lavoro confrontando il tempo di elaborazione della CPU e i dati analizzati tra una determinata query e la sua esecuzione equivalente su una copia cluster della tabella originale. L'esempio seguente illustra come recuperare il tempo cpu allocato e il volume di dati analizzati su disco, memoria e archiviazione remota per una query specifica.

SELECT 
    allocated_cpu_time_ms, 
    data_scanned_disk_mb, 
    data_scanned_memory_mb, 
    data_scanned_remote_storage_mb
FROM 
    queryinsights.exec_requests_history 
WHERE 
     distributed_statement_id = '<Query_Statement_ID>'

Dove <Query_Statement_ID> è l'ID dell'istruzione distribuita della query che si desidera valutare.

Passo successivo

Tutorial: Utilizzo del clustering dei dati nel Data Warehouse di Fabric

Valutazione

Questa pagina ti è stata utile?

Last updated on 2025-11-19