Dataklynging i Fabric Data Warehouse

Gjelder for:✅ Lager i Microsoft Fabric

Dataklynging er en teknikk som brukes for å organisere og lagre data basert på likhet. Dataklynging forbedrer spørringsytelsen og reduserer kostnadene for databehandling og lagringstilgang for spørringer ved å gruppere lignende poster sammen.

Slik fungerer det

Dataklynging fungerer ved å lagre rader med lignende verdier på tilstøtende steder under lagring. Dataklynging bruker en romutfyllende kurve for å organisere data på en måte som bevarer lokalitet over flere dimensjoner, noe som betyr at rader med lignende verdier over klyngingskolonner lagres fysisk tett sammen. Denne tilnærmingen forbedrer spørringsytelsen dramatisk ved å utføre filhopp og redusere antall filer som skannes.

I motsetning til konvensjonell leksikografisk rekkefølge, bruker dataklynging en sofistikert algoritme for å ta inn, hvor rader med lignende kolonneverdier holdes tett sammen, selv når en tabell er klynget av flere kolonner. Dette gjør dataklynging ideell for områdespørringer, filtre med høy kardinalitet og store tabeller med skjeve fordelinger, noe som resulterer i raskere lesinger, redusert I/O og mer effektiv ressursbruk.

Her er en forenklet konseptuell illustrasjon av dataklynging:

I dette diagrammet viser en tabell merket Source data rader blandet og uthevet i forskjellige farger for å representere grupperinger på destinasjon. En Ordered Table deles inn i tre filsegmenter, hvor hver grupperer rader etter lignende farger, noe som demonstrerer hvordan klynging organiserer data i optimaliserte lagringssegmenter basert på kolonneverdier.

Dataklyngemetadata er innebygd i manifestet under inntaket, noe som gjør at warehouse-motoren kan ta intelligente beslutninger om hvilke filer som skal få tilgang til under brukerforespørsler. Denne metadataen, kombinert med hvordan rader med lignende verdier lagres sammen, sikrer at spørringer med filterpredikater kan hoppe over hele filer og radgrupper som faller utenfor predikatets omfang. For eksempel: hvis en spørring kun retter seg mot 10% av en tabells data, sikrer klynging at kun filer som inneholder dataene innenfor filterets område blir skannet, noe som reduserer I/O- og databehandlingsforbruk. Større tabeller drar mer nytte av dataklynging, ettersom fordelene med filhopp øker med datavolumet.

Når bør man bruke dataklynging

Når du skal avgjøre om dataklynging kan være gunstig, bør du undersøke spørringsmønstre og tabellkarakteristikker i lageret. Dataklynging er mest effektiv når spørringer gjentatte ganger filtreres på spesifikke kolonner, og når de underliggende tabellene er store og inneholder data med middels til høy kardinalitet. Noen vanlige scenarier inkluderer:

• Gjentatte spørringer med WHERE filtre: Hvis arbeidsmengden inkluderer hyppige spørringer som filtrerer spesifikke kolonner, sikrer dataklynging at kun relevante filer skannet under leseforespørsler. Dette gjelder også når filtrene brukes gjentatte ganger i dashbord, rapporter eller planlagte jobber og sendes ned til lagermotoren som SQL-setninger.
• Større tabeller: dataklynging er mest effektiv når den brukes på store tabeller hvor det er kostbart å skanne hele datasettet. Ved å organisere rader med dataklynging kan warehouse-motoren hoppe over hele filer og radgrupper som ikke matcher spørringsfilteret, noe som kan redusere I/O- og beregningsbruk.
• Kolonner med middels til høy kardinalitet: kolonner med høyere kardinalitet (for eksempel: kolonner med mange distinkte verdier, som en ID eller en dato) drar mer nytte av dataklynging fordi de lar motoren isolere og samlokalisere lignende verdier. Dette muliggjør effektiv filhopping, spesielt for selektive spørringer. Kolonner med lav kardinalitet (for eksempel: kjønn, region) har av natur verdiene spredt over flere filer, noe som gir begrensede muligheter for filhopping.
• Selektive spørringer med snevert omfang: når spørringer vanligvis retter seg mot et lite datasett og kombineres med et WHERE-filter, sikrer dataklynging at kun filer som inneholder relevante rader leses.

Dataklynging skjer automatisk under datainntak, uavhengig av hvordan radene ble innhentet. Ingen brukeroperasjoner kreves etter at data er innhentet for å anvende dataklynging.

KLYNGE ETTER syntaks

Dataklynging defineres under tabellopprettelse, ved bruk av klausulen CLUSTER BY . Syntaksen er som følger:

CREATE TABLE (Transact-SQL) syntaks:

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

OPPRETT TABELL SOM SELECT (Transact-SQL) syntaks :

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

Klausulen CLUSTER BY krever at minst én kolonne spesifiseres for dataklynging, og maksimalt fire kolonner.

Å lage en tabell som bruker dataklynging med SELECT INTO støttes ikke.

Støtte for datatyper

Følgende tabell oppsummerer kolonnetyper som kan brukes i klausulen CLUSTER BY :

Kategori	Datatype	Dataklynging støttes
Eksakte numerikker	bit	Nei
Eksakte numerikker	bigint, int, smallint, desimal2, numerisk	Ja
Omtrentlige numerikker	flyt, ekte	Ja
Dato og klokkeslett	Dato, Dato, Tid2, Tid	Ja
Tegnstrenger1	Char	Ja
Tegnstrenger1	Varchar	Ja
LOB-typer	varchar(max),varbinær(max)	Nei
Binære strenger	varbinær,unikidentifikator	Nei

¹ For strengtyper (char/varchar) brukes kun de første 32 tegnene når kolonnestatistikk produseres. Som et resultat kan kolonner med verdier som inneholder lange prefikser ha begrensede fordeler ved dataklynging.

² For desimaltyper med presisjon større enn 18, blir predikatene ikke pushdown til lagring under spørringsutførelse. Hvis du bruker desimaltyper med dataklynging, foretrekk kolonner med lavere presisjon.

Kolonner med ikke-støttede datatyper kan fortsatt eksistere i en tabell som bruker dataklynging, men kan ikke brukes med CLUSTER BY.

Beste praksis for dataklynging

Dataklynging er mer effektivt når klyngekolonner velges basert på faktiske spørringsmønstre, spesielt de med middels til høy kardinalitet, og når rekkeviddepredikater brukes under spørringer.

Vurder følgende beste praksis når du bruker dataklynging:

• Dataklynging er mer effektivt på store tabeller.
• Når det er mulig, batch-inntasting og oppdateringer for å behandle et større antall rader samtidig, i stedet for å bruke mindre oppgaver. For optimal ytelse bør DML-operasjoner ha minst 1 million rader for å dra nytte av dataklynging. Etter påfølgende innsettinger, oppdateringer og slettinger kan datakomprimering konsolidere rader fra mindre filer til optimalt store filer.
• Velg kolonner med middels til høy kardinalitet for dataklynging, da de gir bedre resultater på grunn av deres distinkte verdifordeling. Kolonner med lav kardinalitet kan gi begrensede muligheter for filbeskjæring.
• Velg kolonner basert på hyppig bruk av WHERE predikater i dashbord, rapporter, planlagte jobber eller brukerforespørsler. Likhetsbetingelser for sammenføyning drar ikke nytte av dataklynging. For en oversikt over hvordan du bruker Query Insights for å hjelpe med å velge kolonner for dataklynging basert på din nåværende arbeidsmengde, se Veiledning: Bruk av dataklynging i Fabric Data Warehouse.
• Ikke bruk dataklynging med flere kolonner enn strengt nødvendig. Klynging med flere kolonner legger til kompleksitet i lagringen, øker overhead, og gir kanskje ikke fordeler med mindre alle kolonnene brukes sammen i spørringer med predikater.
• Kolonnerekkefølgen som brukes i CLUSTER BY er ikke viktig og endrer ikke hvordan radene lagres.
• Når du lager en tabell med dataklynging ved bruk av CREATE TABLE AS SELECT (CTAS) eller når du innhenter data med INSERT INTO ... SELECT, hold den utvalgte delen av disse setningene så enkel som mulig for optimal dataklyngingskvalitet.

Dataklynging kan redusere kostnadene betydelig under spørringer, hvis de er godt tilpasset spørringspredikatene. Imidlertid medfører datainntak flere tids- og kapasitetsenheter (CU) på en tabell som bruker dataklynging sammenlignet med en tilsvarende tabell med samme data uten dataklynging. Dette skjer fordi lagermotoren må bestille data under innhenting. Siden data som tas inn leses flere ganger, kan dataklynging redusere det totale beregningsforbruket til en gitt arbeidsmengde.

Systemvisninger

Dataklyngemetadata kan forespørres ved hjelp av sys.index_columns. Den viser alle kolonner som brukes i dataklynging, inkludert kolonneordinalet som brukes i klausulen CLUSTER BY .

Følgende spørring viser alle kolonner brukt i dataklynging på det nåværende lageret, og deres tabeller:

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;

Note

Kolonneordinalet vises kun til referanse som rekkefølgen brukt da CLUSTER BY tabellen ble definert. Som diskutert i Best Practices, påvirker ikke kolonnerekkefølgen ytelsen.

Begrensninger og bemerkninger

• Datainntaksytelsen kan forringes når tabeller inneholder store varchar-kolonner med svært varierende datastørrelser.
  • For eksempel, vurder en tabell med en varchar(200)- kolonne: hvis noen rader bare inneholder noen få tegn mens andre nærmer seg maksimal lengde, kan den betydelige variasjonen i datastørrelse påvirke inntakshastigheten negativt.
  • Dette problemet er kjent og vil bli tatt opp i en kommende utgivelse.
• IDENTITY kolonner kan ikke brukes med CLUSTER BY. Tabeller som inneholder en IDENTITY kolonne kan fortsatt brukes til dataklynging, gitt at den bruker forskjellige kolonner med CLUSTER BY.
• Dataklynging må defineres ved tabellopprettelse. Å konvertere en vanlig tabell til en med støttes CLUSTER BY ikke. På samme måte er det ikke tillatt å endre klyngekolonnene etter at en tabell er opprettet. Hvis ulike klyngekolonner er nødvendige, bruk CREATE TABLE AS SELECT eventuelt (CTAS) for å lage en ny tabell med ønskede klyngekolonner.
• I noen tilfeller kan dataklynging anvendes asynkront. I slike tilfeller reorganiseres dataene med en bakgrunnsoppgave, og tabellen kan hende at den ikke er fullt optimalisert når innspillingen er ferdig. Dette kan skje under følgende betingelser:
  • Når man bruker INSERT INTO ... SELECT or CREATE TABLE AS SELECT (CTAS) og sammenstillingen av kilde- og måltabellene er forskjellig.
  • Når man henter inn data fra ekstern data, er det komprimert CSV-format.
  • Når en inntakssetning har færre enn 1 million rader.
• Datainntak på dataklyngetabeller medfører overhead sammenlignet med en tabell med samme skjema som ikke bruker dataklynging. Dette skjer på grunn av ekstra beregning som trengs for å optimalisere lagring. Når klyngingskolonnen har en kasus-insensitiv sortering, forventes også mer overhead.
• Dataklynging kan gagne svartid på spørringer, forbruk av kapasitetsenheter (CU), eller begge deler.

Eksempler

En. Lag en klynget tabell for salgsdata

Dette eksempelet lager en enkel Sales tabell og bruker og CustomerID kolonnene SaleDate for dataklynging.

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

B. Lag en klynget tabell ved å bruke CREATE TABLE AS SELECT

Dette eksempelet brukes CREATE TABLE AS SELECT til å lage en kopi av den Sales eksisterende tabellen, med CLUSTER BY kolonnen SaleDate .

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

C. Se kolonnene som brukes for dataklynging i en gitt tabell

Dette eksempelet viser kolonnene som brukes til dataklynging i tabellen Sales .

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;

Resultater:

D. Sjekk effektiviteten av kolonnevalgene for dataklynging

Query Insights kan hjelpe med å evaluere effekten av dataklynging på arbeidsmengden din ved å sammenligne CPU-tid og data skannet mellom en gitt spørring og tilsvarende kjøring på en klynget kopi av den opprinnelige tabellen. Følgende eksempel illustrerer hvordan man kan hente ut den tildelte CPU-tiden og volumet av data som er skannet over disk, minne og fjernlagring for en spesifikk forespørsel.

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>'

Hvor <Query_Statement_ID> er den distribuerte setnings-ID-en til spørringen du vil evaluere.

Neste trinn:

Veiledning: Bruk av dataklynging i Fabric Data Warehouse

Relatert innhold

• Retningslinjer for ytelse i Fabric Data Warehouse
• Overvåk Fabric Data Warehouse