Dataklyngedannelse i Fabric Data Warehouse

Gælder for:✅ Warehouse i Microsoft Fabric

Dataklyngedannelse er en teknik, der bruges til at organisere og gemme data baseret på lighed. Dataklyngedannelse forbedrer forespørgselsydelsen og reducerer omkostninger til adgang til beregning og lagring for forespørgsler ved at gruppere lignende poster sammen.

Sådan virker det

Dataklynge fungerer ved at gemme rækker med lignende værdier på tilstødende steder under indlæsning. Dataklyngedannelse bruger en pladsfyldende kurve til at organisere data på en måde, der bevarer lokalitet på tværs af flere dimensioner, hvilket betyder, at rækker med lignende værdier på tværs af klyngningskolonner lagres fysisk tæt sammen. Denne tilgang forbedrer forespørgselsydelsen markant ved at udføre filspring og reducere antallet af filer, der scannes.

I modsætning til konventionel leksikografisk rækkefølge bruger dataklynge en sofistikeret algoritme til at indtage, hvor rækker med lignende kolonneværdier holdes tæt sammen, selv når en tabel er klynget af flere kolonner. Dette gør dataklynge ideelt til intervalforespørgsler, filtre med høj kardinalitet og store tabeller med skæve fordelinger, hvilket resulterer i hurtigere læsninger, reduceret I/O og mere effektiv ressourceudnyttelse.

Her er en forenklet konceptuel illustration af dataklyngedannelse:

I dette diagram viser en tabel mærket Source data rækker blandet og fremhævet i forskellige farver for at repræsentere klyngegrupperinger på destinationen. En Ordered Table er opdelt i tre filsegmenter, hvor hver grupperer rækker efter lignende farver, hvilket demonstrerer, hvordan klyngedannelse organiserer data i optimerede lagringssegmenter baseret på kolonneværdier.

Dataklyngemetadata indlejres i manifestet under indlæsning, hvilket gør det muligt for warehouse-motoren at træffe intelligente beslutninger om, hvilke filer der skal tilgås under brugerforespørgsler. Disse metadata, kombineret med hvordan rækker med lignende værdier gemmes sammen, sikrer, at forespørgsler med filterprædikater kan springe hele filer og rækkegrupper over, der ligger uden for prædikatets område. For eksempel: hvis en forespørgsel kun retter sig mod 10% af en tabels data, sikrer klyngedannelse, at kun filer, der indeholder data inden for filterets område, scannes, hvilket reducerer I/O- og beregningsforbrug. Større tabeller drager større fordel af dataklyngedannelse, da fordelene ved filspringning skalerer med datavolumen.

Hvornår skal man bruge dataklyngedannelse

Når du skal beslutte, om dataklynge kan være gavnligt, bør du undersøge forespørgselsmønstre og tabelkarakteristika i lageret. Dataklyngedannelse er mest effektiv, når forespørgsler gentagne gange filtreres på specifikke kolonner, og når de underliggende tabeller er store og indeholder data med mellem- til høj kardinalitet. Nogle almindelige scenarier inkluderer:

• Gentagne forespørgsler med WHERE filtre: Hvis arbejdsbyrden inkluderer hyppige forespørgsler, der filtrerer specifikke kolonner, sikrer dataklyngedannelse, at kun relevante filer scannes under læseforespørgsler. Dette gælder også, når filtrene gentagne gange bruges i dashboards, rapporter eller planlagte jobs og sendes ned til warehouse-motoren som SQL-sætninger.
• Større tabeller: dataklynge er mest effektiv, når det anvendes på store tabeller, hvor scanning af hele datasættet er dyrt. Ved at organisere rækker med dataklynge kan warehouse-motoren springe hele filer og rækkegrupper over, der ikke matcher forespørgselsfilteret, hvilket kan reducere I/O- og beregningsforbrug.
• Kolonner med mellem- til høj kardinalitet: kolonner med højere kardinalitet (for eksempel kolonner med mange forskellige værdier, såsom et ID eller en dato) drager større fordel af dataklyngedannelse, fordi de tillader motoren at isolere og samlokalisere lignende værdier. Dette muliggør effektiv filspringning, især for selektive forespørgsler. Kolonner med lav kardinalitet (for eksempel: køn, region) har af natur deres værdier spredt over flere filer, hvilket giver begrænsede muligheder for filspring.
• Selektive forespørgsler med snævert omfang: når forespørgsler typisk retter sig mod et lille datasæt og kombineres med et WHERE-filter, sikrer dataklynge, at kun filer, der indeholder de relevante rækker, læses.

Dataklynge sker automatisk under dataindlæsning, uanset hvordan rækkerne blev indlæst. Der kræves ingen brugeroperationer efter dataindsamling for at anvende dataklyngedannelse.

KLYNGE EFTER syntaks

Dataklynge defineres under tabeloprettelsen ved brug af 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 ]);

OPRET TABEL 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 kræver, at mindst én kolonne specificeres for dataklyngedannelse, og maksimalt fire kolonner.

Oprettelse af en tabel, der bruger data-clustering med SELECT INTO , understøttes ikke.

Datatypeunderstøttelse

Følgende tabel opsummerer kolonnetyper, der kan bruges i klausulen CLUSTER BY :

Kategori	Datatype	Dataklyngedannelse understøttet
Eksakte numeriske forhold	bit	Nej
Eksakte numeriske forhold	Bigynt, int, småint, decimal2, numerisk	Ja
Omtrentlige numerikker	flyde, ægte	Ja
Dato og klokkeslæt	Dato, DatoTid2, Tid	Ja
Tegnstrenge1	Char	Ja
Tegnstrenge1	Varchar	Ja
LOB-typer	varchar(max),varbinær(max)	Nej
Binære strenge	varbinær,unikidentifikator	Nej

¹ For strengtyper (char/varchar) bruges kun de første 32 tegn, når kolonnestatistikker produceres. Som følge heraf kan kolonner med værdier, der indeholder lange præfikser, have begrænsede fordele ved dataklyngedannelse.

² For decimaltyper med præcision over 18 bliver prædikater ikke pushdown-nedprioriteret til lagring under forespørgselskørsel. Hvis du bruger decimaltyper med dataklynge, foretræk kolonner med mindre præcision.

Kolonner med ikke-understøttede datatyper kan stadig eksistere i en tabel, der bruger dataklyngedannelse, men kan ikke bruges med CLUSTER BY.

Best practice med dataklyngedannelse

Dataklyngning er mere effektiv, når klyngningskolonner vælges baseret på faktiske forespørgselsmønstre, især dem med mellem- til høj kardinalitet, og når intervalprædikater anvendes under forespørgsler.

Overvej følgende bedste praksis, når du bruger dataklyngedannelse:

• Dataklyngedannelse er mere effektiv på store tabeller.
• Når det er muligt, batch-indlæsning og opdateringer for at behandle et større antal rækker ad gangen, i stedet for at bruge mindre opgaver. For optimal ydeevne bør DML-operationer have mindst 1 million rækker for at drage fordel af dataklyngedannelse. Efter på hinanden følgende indsættelser, opdateringer og sletninger kan datakomprimering konsolidere rækker fra mindre filer til optimalt store.
• Vælg kolonner med mellem- til høj kardinalitet til dataklyngedannelse, da de giver bedre resultater på grund af deres forskellige værdifordeling. Kolonner med lav kardinalitet kan give begrænsede muligheder for filbeskæring.
• Vælg kolonner baseret på hyppig brug af WHERE prædikater i dashboards, rapporter, planlagte jobs eller brugerforespørgsler. Equality join-betingelser drager ikke fordel af dataklynge. For et overblik over, hvordan du bruger Query Insights til at hjælpe med at vælge kolonner til dataklyngedannelse baseret på din nuværende arbejdsbyrde, se Tutorial: Using Data Clustering in Fabric Data Warehouse.
• Brug ikke data-clustering med flere kolonner end strengt nødvendigt. Flerkolonne-klyngedannelse tilføjer kompleksitet til lagringen, øger overhead og giver måske ikke fordele, medmindre alle kolonner bruges sammen i forespørgsler med prædikater.
• Kolonnerækkefølgen, der bruges i CLUSTER BY , er ikke vigtig og ændrer ikke, hvordan rækker gemmes.
• Når du opretter en tabel med dataklyngning ved brug af CREATE TABLE AS SELECT (CTAS) eller indtager data med INSERT INTO ... SELECT, hold select-delen af disse sætninger så enkel som muligt for optimal dataklyngekvalitet.

Dataklyngedannelse kan markant reducere omkostningerne under forespørgsler, hvis de er godt tilpasset forespørgselsprædikaterne. Dog medfører dataindlæsning flere tids- og kapacitetsenheder (CU) på en tabel, der bruger dataklyngedannelse, sammenlignet med en tilsvarende tabel med de samme data uden dataklyngedannelse. Dette sker, fordi warehouse-motoren skal bestille data under indtastningen. Da data, der indlæses, læses flere gange, kan dataklyngedannelse reducere det samlede beregningsforbrug for en given arbejdsbyrde.

Systemvisninger

Dataklyngemetadata kan forespørges ved hjælp af sys.index_columns. Den viser alle kolonner, der bruges i dataklyngedannelse, inklusive kolonneordinaltalet, der bruges i klausulen CLUSTER BY .

Følgende forespørgsel viser alle kolonner, der bruges i dataklynge på det aktuelle lager, samt 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;

Notat

Kolonneordinalet vises kun til reference som den rækkefølge, der blev brugt da CLUSTER BY tabellen blev defineret. Som diskuteret i Best Practices, påvirker kolonnerækkefølgen ikke ydeevnen.

Begrænsninger og bemærkninger

• Dataindlæsningsydelsen kan forringes, når tabeller indeholder store varchar-kolonner med meget variable datastørrelser.
  • For eksempel, overvej en tabel med en varchar(200)- kolonne: hvis nogle rækker kun indeholder få tegn, mens andre nærmer sig maksimal længde, kan den betydelige varians i datastørrelsen have negativ indvirkning på indlæsningshastigheden.
  • Dette problem er kendt og vil blive adresseret i en kommende udgivelse.
• IDENTITY kolonner kan ikke bruges med CLUSTER BY. Tabeller, der indeholder en IDENTITY kolonne, kan stadig bruges til dataklynge, forudsat at den bruger forskellige kolonner med CLUSTER BY.
• Dataklynge skal defineres ved oprettelse af tabel. At konvertere en almindelig tabel til en med CLUSTER BY understøttes ikke. Ligeledes er det ikke tilladt at ændre de klyngede kolonner efter at en tabel er oprettet. Hvis der er behov for forskellige klyngekolonner, kan du eventuelt bruge CREATE TABLE AS SELECT (CTAS) til at oprette en ny tabel med de ønskede klyngekolonner.
• I nogle tilfælde kan dataklyngedannelse anvendes asynkront. I sådanne tilfælde omorganiseres data med en baggrundsopgave, og tabellen kan være utilstrækkeligt optimeret, når indlæsningen er færdig. Dette kan ske under følgende betingelser:
  • Når man bruger INSERT INTO ... SELECT eller CREATE TABLE AS SELECT (CTAS) og er sammenstillingen af kilde- og måltabellerne forskellig.
  • Når man indfører data fra eksterne data, der er i komprimeret CSV-format.
  • Når en indskrivningssætning har færre end 1 million rækker.
• Dataindlæsning på dataklyngetabeller medfører en overhead sammenlignet med en tabel med samme skema, som ikke bruger dataklynge. Dette sker på grund af ekstra beregning, der kræves for at optimere lagringen. Når klyngekolonnen har en kasus-insensitiv kollation, forventes der også mere overhead.
• Dataklyngedannelse kan gavne svartiden på forespørgsler, forbruget af kapacitetsenheder (CU) eller begge dele.

Eksempler

A. Opret en klyngetabel til salgsdata

Dette eksempel skaber en simpel Sales tabel og bruger og CustomerID kolonnerne SaleDate til dataklyngedannelse.

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

B. Opret en klyngetabel ved hjælp af CREATE TABLE AS SELECT

Dette eksempel bruges CREATE TABLE AS SELECT til at oprette en kopi af den Sales eksisterende tabel med CLUSTER BY kolonnen SaleDate .

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

C. Se kolonnerne, der bruges til dataklyngedannelse i en given tabel

Dette eksempel viser kolonnerne, der bruges til dataklyngedannelse 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. Tjek effektiviteten af kolonnevalgene til dataklyngedannelse

Query Insights kan hjælpe med at evaluere effekten af dataklyngedannelse på din arbejdsbyrde ved at sammenligne CPU-tid og data, der scannes mellem en given forespørgsel, og dens tilsvarende kørsel på en klyngebaseret kopi af den oprindelige tabel. Følgende eksempel illustrerer, hvordan man henter den tildelte CPU-tid og mængden af data, der er scannet på disk, hukommelse og fjernlagring for en specifik forespørgsel.

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 det distribuerede statement-ID for den forespørgsel, du vil evaluere.

Næste trin

Vejledning: Brug af dataklyngedannelse i Fabric Data Warehouse

Relateret indhold

• Retningslinjer for ydeevne i Fabric Data Warehouse
• Overvåg Fabric Data Warehouse