Brug dataklynge i Fabric data warehouse (Forhåndsvisning)

Gælder for:✅ SQL Analytics-slutpunkt og warehouse i Microsoft Fabric

Vigtigt!

Denne funktion er i prøveversion.

Dataklyngedannelse i Fabric data warehouse organiserer data for hurtigere forespørgselsydelse og reduceret beregningsforbrug. Denne vejledning gennemgår trinene til at oprette tabeller med dataklynge, fra at oprette klyngetabeller til at kontrollere deres effektivitet.

Forudsætninger

  • En Microsoft Fabric-lejerkonto med et aktivt abonnement.
  • Sørg for, at du har et Arbejdsområde, der er aktiveret af Microsoft Fabric: Opret et arbejdsområde.
  • Sørg for, at du allerede har oprettet et lager. For at oprette et nyt lager, se Opret et lager i Microsoft Fabric.
  • Grundlæggende forståelse af T-SQL og forespørgsel af data.

Importere eksempeldata

Denne vejledning bruger NY Taxi-eksempeldatasættet. For at importere NY Taxi-dataene til dit lager. Brug tutorialen Load Sample data to data warehouse .

Opret en tabel med dataklyngedannelse

Til denne tutorial har vi brug for to kopier af NYTaxi-tabellen: den almindelige kopi af tabellen, som den er importeret fra tutorialen, og en kopi, der bruger data-clustering. Brug følgende kommando til at oprette en ny tabel med CREATE TABLE AS SELECT (CTAS), baseret på den oprindelige NYTaxi-tabel:

CREATE TABLE nyctlc_With_DataClustering 
WITH (CLUSTER BY (lpepPickupDatetime)) 
AS SELECT * FROM nyctlc

Notat

Eksemplet antager det tabelnavn, der gives til NY Taxi-datasættet i Load Sample data to data warehouse-tutorialen. Hvis du brugte et andet navn til din tabel, så juster kommandoen til at erstatte nyctlc den med dit tabelnavn.

Denne kommando opretter en nøjagtig kopi af den oprindelige NYTaxi-tabel, men med dataklynge på kolonnen lpepPickupDatetime . Dernæst bruger vi denne kolonne til forespørgsler.

Forespørg på data

Kør en forespørgsel på NYTaxi-tabellen, og gentag den samme forespørgsel på den NYTaxi_With_DataClustering tabel til sammenligning.

Notat

Til denne analyse er det fordelagtigt at se på cold cache-ydeevnen for begge kørsler – altså uden at bruge cache-funktionerne i Fabric data warehouse. Kør derfor hver forespørgsel præcis én gang, før du ser på resultaterne i Query Insights.

Vi bruger en forespørgsel, der ofte gentages i Warehouse. Denne forespørgsel beregner det gennemsnitlige takstbeløb pr. år mellem datoerne 2008-12-31 og 2014-06-30:

SELECT
    YEAR(lpepPickupDatetime), 
    AVG(fareAmount) as [Average Fare]
FROM 
    NYTaxi
WHERE 
    lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY 
    YEAR(lpepPickupDatetime)
ORDER BY 
    YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Regular');

Notat

Label-muligheden, der bruges i denne forespørgsel, er nyttig, når vi sammenligner forespørgselsdetaljerne i Regular tabellen med den, der senere bruger dataklynging ved hjælp af Query Insights-visninger.

Dernæst gentager vi den samme forespørgsel, men på den version af tabellen, der bruger dataklyngedannelse:

SELECT 
    YEAR(lpepPickupDatetime), 
    AVG(fareAmount) as [Average Fare]
FROM 
    NYTaxi_With_DataClustering
WHERE 
    lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY 
    YEAR(lpepPickupDatetime)
ORDER BY 
    YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Clustered');

Den anden forespørgsel bruger labelen Clustered , så vi senere kan identificere denne forespørgsel med Query Insights.

Tjek effektiviteten af dataklyngedannelse

Efter opsætning af clustering kan du vurdere dens effektivitet ved hjælp af Query Insights. Query Insights i Fabric data warehouse indsamler historiske forespørgselsudførelsesdata og samler dem til handlingsorienterede indsigter, såsom identifikation af langvarige eller ofte udførte forespørgsler.

I dette tilfælde bruger vi Query Insights til at sammenligne forskellen i de scannede data mellem de almindelige og de klyngede tilfælde.

Brug følgende forespørgsel:

SELECT 
    label, 
    submit_time, 
    row_count,
    total_elapsed_time_ms, 
    allocated_cpu_time_ms, 
    result_cache_hit, 
    data_scanned_disk_mb, 
    data_scanned_memory_mb, 
    data_scanned_remote_storage_mb, 
    command 
FROM 
    queryinsights.exec_requests_history 
WHERE 
    command LIKE '%NYTaxi%' 
    AND label IN ('Regular','Clustered')
ORDER BY 
    submit_time DESC;

Denne forespørgsel henter detaljer fra visningen exec_requests_history . For mere information, se queryinsights.exec_requests_history (Transact-SQL).

Forespørgslen filtrerer resultaterne på følgende måder:

  • Henter kun rækker, der indeholder teksten NYTaxi i kommandonavnet (som det blev brugt i testforespørgslerne)
  • Henter kun rækker, hvor labelværdien enten var regulær eller klynget

Notat

Det kan tage et par minutter, før dine forespørgselsdetaljer bliver tilgængelige i Query Insights. Hvis din Query Insights-forespørgsel ikke giver resultater, så prøv igen efter et par minutter.

Ved at køre denne forespørgsel ser vi følgende resultater:

Tabel, der sammenligner forespørgselsudførelsesmetrikker for to labels: Clustered og Regular. Regular-forespørgslen brugte flere ressourcer.

Begge forespørgsler har en rækketælling på 6 og lignende indsendelsestider. Forespørgslen Clustered viser total_elapsed_time_ms 1794, allocated_cpu_time_ms 1676 og data_scanned_remote_storage_mb 77.519. Forespørgslen Regular viser total_elapsed_time_ms 2651, allocated_cpu_time_ms 2600 og data_scanned_remote_storage_mb 177.700. Disse tal viser, at selvom begge forespørgsler gav de samme resultater, brugte Clustered versionen cirka 36% mindre CPU-tid end Regular versionen og scannede cirka 56% mindre data på disken. Der blev ikke brugt nogen cache i nogen af forespørgselskørslerne. Disse er væsentlige resultater, der hjælper med at reducere forespørgselseksekveringstid og forbrug, og gør kolonnen lpepPickupDatetime til en stærk kandidat til dataklyngedannelse.

Notat

Dette er en lille tabel med cirka 76 millioner rækker og 2 GB datavolumen. Selvom denne forespørgsel kun returnerer seks rækker i aggregeringen (én for hvert år i intervallet), scanner den cirka 8,3 millioner rækker i det angivne datoområde, før resultaterne aggregeres. Faktiske produktionsdata med større datamængder kan give mere betydningsfulde resultater. Dine resultater kan variere afhængigt af kapacitetsstørrelsen, cachede resultater eller samtidighed under forespørgslerne.

Vælg clustering columns fra din arbejdsbelastning

For produktionstabeller skal man bruge observerede forespørgselsmønstre i stedet for at gætte, hvilke kolonner der skal klynge. Færdighedenssqldw-cli operationskapacitet analyserer Query Insights-historikken, rangerer tilbagevendende forespørgselsmønstre efter fjerndata scannet og identificerer kolonner brugt i WHERE prædikater.

Før du starter, installer Skills for Fabric, sørg for at lageret har nylig forespørgselsaktivitet, og bekræft at du har rollen Bidragyder workspace eller højere. Åbn derefter GitHub Copilot CLI og brug en prompt som denne:

Use the sqldw-cli skill to recommend clustering columns for
<workspace-name>/<warehouse-name> based on the last seven days of workload.
Rank candidates by total remote data scanned, consider columns used in WHERE
predicates, and explain each column's cardinality and data type suitability.
Use read-only diagnostics.

Færdigheden identificerer de forespørgselsmønstre med størst scanningseffekt, udtrækker tabeller og filterkolonner fra disse forespørgsler og rangerer de klyngede kandidater. Gennemgå anbefalingerne med disse retningslinjer:

  • Foretræk kolonner, der gentagne gange filtrerer store tabeller og bruger mellem- til høje kardinalitetsværdier, såsom datoer eller identifikatorer.
  • Favor kolonner brugt i selektivt interval eller lighedsprædikater i klausulen WHERE .
  • Vælg ikke kolonner kun fordi de optræder under ligheds-join-betingelser. Disse forhold drager ikke fordel af dataklyngedannelse.
  • Brug højst fire klyngekolonner, og tilføj ikke flere kolonner end arbejdsbyrden kræver.

For eksempel, overvej et e-handelslager, hvor Sales.SalesOrder indeholder 1,5 milliarder rækker og Sales.OrderLine 6 milliarder rækker. Efter at have analyseret tilbagevendende forespørgsler, kan færdigheden give disse anbefalinger:

Tabel over anbefalinger til klyngedannelse. SalesOrder bruger OrderDate baseret på 428 forespørgselskørsler og 38 terabyte fjerndata scannet. OrderLine bruger ShipDate baseret på 612 forespørgselskørsler og 52 terabyte scannet.

Datokolonnerne er stærke kandidater, fordi de filtrerer de største tabeller, understøtter common range-prædikater og giver flere muligheder for filspring end kolonner med OrderStatus lav kardinalitet såsom eller SalesRegion.

Operationsfunktionen sqldw-cli er skrivebeskyttet. Den anbefaler kolonner, men opretter eller erstatter ikke tabeller. Efter du har gennemgået anbefalingen, brug CTAS til at lave en klynge-kopi af tabellen:

CREATE TABLE Sales.SalesOrder_clustered
WITH (CLUSTER BY (OrderDate))
AS
SELECT * FROM Sales.SalesOrder;

Sammenlign de klyngede og ikke-klyngede arbejdsbelastninger for at verificere effekten. Efter du har valideret den klyngede tabel, omdøb den oprindelige tabel og derefter den klyngede tabel til det oprindelige navn:

EXEC sp_rename 'Sales.SalesOrder', 'SalesOrder_old';
EXEC sp_rename 'Sales.SalesOrder_clustered', 'SalesOrder';

Den oprindelige tabel er stadig tilgængelig for Sales.SalesOrder_old rollback. Verificér afhængige arbejdsbelastninger og den nye tabel, før du fjerner den oprindelige tabel. Når du ikke længere har brug for rollback-kopien, så smid den ud:

DROP TABLE Sales.SalesOrder_old;

Relateret indhold

  • Last updated on