Eksempler på forespørgselsdelegering

Denne artikel indeholder nogle eksempelscenarier for hvert af de tre mulige resultater for forespørgselsdelegering. Den indeholder også nogle forslag til, hvordan du får mest muligt ud af forespørgselsdelegeringsmekanismen og den effekt, det kan have i dine forespørgsler.

Scenariet

Forestil dig et scenarie, hvor du skal oprette en forespørgsel i Power Query, der opretter forbindelse til tabellen og henter de sidste 10 salg med kun følgende felter, ved hjælp af databasen Wide World Importers til fact_Sale Azure Synapse Analytics SQL-databasen:

• Salgsnøgle
• Kundenøgle
• Fakturadatonøgle
• Beskrivelse
• Antal

Bemærk

Til demonstrationsformål bruger denne artikel den database, der er beskrevet i selvstudiet om indlæsning af Wide World Importers-databasen i Azure Synapse Analytics. Den største forskel i denne artikel er, at fact_Sale tabellen kun indeholder data for år 2000 med i alt 3.644.356 rækker.

Selvom resultaterne muligvis ikke stemmer nøjagtigt overens med de resultater, du får ved at følge selvstudiet fra dokumentationen til Azure Synapse Analytics, er målet med denne artikel at vise de kernebegreber og den indvirkning, som forespørgselsdelegering kan have i dine forespørgsler.

I denne artikel vises tre måder at opnå det samme output på med forskellige niveauer af forespørgselsdelegering:

• Ingen forespørgselsdelegering
• Delvis forespørgselsdelegering
• Fuld forespørgselsdelegering

Eksempel på ingen forespørgselsdelegering

Vigtigt

Forespørgsler, der udelukkende er afhængige af ustrukturerede datakilder, eller som ikke har et beregningsprogram, f.eks. CSV- eller Excel-filer, har ikke forespørgselsdelegeringsfunktioner. Det betyder, at Power Query evaluerer alle de påkrævede datatransformationer ved hjælp af Power Query-programmet.

Når du har oprettet forbindelse til databasen og navigeret til tabellenfact_Sale, skal du vælge transformeringen Bevar nederste rækker, der findes i gruppen Reducer rækker under fanen Hjem.

Når du har valgt denne transformering, vises der en ny dialogboks. I denne nye dialogboks kan du angive det antal rækker, du vil beholde. I dette tilfælde skal du angive værdien 10 og derefter vælge OK.

Tip

I dette tilfælde giver udførelse af denne handling resultatet af de sidste ti salg. I de fleste scenarier anbefaler vi, at du angiver en mere eksplicit logik, der definerer, hvilke rækker der anses for sidst, ved at anvende en sorteringshandling i tabellen.

Derefter skal du vælge transformeringen Vælg kolonner , der findes i gruppen Administrer kolonner under fanen Hjem . Du kan derefter vælge de kolonner, du vil beholde fra tabellen, og fjerne resten.

I dialogboksen Vælg kolonner skal du vælge kolonnerne Sale Key, Customer Key, Invoice Date KeyDescriptionog Quantity og derefter vælge OK.

Følgende kodeeksempel er det fulde M-script for den forespørgsel, du har oprettet:

let
  Source = Sql.Database(ServerName, DatabaseName),
  Navigation = Source{[Schema = "wwi", Item = "fact_Sale"]}[Data],
  #"Kept bottom rows" = Table.LastN(Navigation, 10),
  #"Choose columns" = Table.SelectColumns(#"Kept bottom rows", {"Sale Key", "Customer Key", "Invoice Date Key", "Description", "Quantity"})
in
  #"Choose columns""

Ingen forespørgselsdelegering: Forståelse af forespørgselsevalueringen

Under Anvendte trin i Power Query-editor kan du se, at indikatorerne for forespørgselsdelegering for nederste rækker og Vælg kolonner er markeret som trin, der evalueres uden for datakilden eller med andre ord af Power Query-programmet.

Du kan højreklikke på det sidste trin i forespørgslen med navnet Vælg kolonner og vælge den indstilling, der læser Vis forespørgselsplan. Målet med forespørgselsplanen er at give dig en detaljeret visning af, hvordan din forespørgsel køres. Hvis du vil vide mere om denne funktion, skal du gå til Forespørgselsplan.

Hvert felt i det forrige billede kaldes en node. En node repræsenterer den handlingsopdeling, der skal opfylde denne forespørgsel. Noder, der repræsenterer datakilder, f.eks. SQL Server i eksemplet ovenfor og noden Value.NativeQuery , repræsenterer, hvilken del af forespørgslen der er indlæst i datakilden. Resten af noderne, i dette tilfælde Table.LastN og Table.SelectColumns fremhævet i rektanglet på det forrige billede, evalueres af Power Query-programmet. Disse to noder repræsenterer de to transformationer, du har tilføjet, Beholdt nederste rækker og Vælg kolonner. Resten af noderne repræsenterer handlinger, der sker på datakildeniveau.

Hvis du vil se den nøjagtige anmodning, der sendes til din datakilde, skal du vælge Få vist detaljer i noden Value.NativeQuery .

Denne datakildeanmodning er på datakildens oprindelige sprog. I dette tilfælde er dette sprog SQL, og denne sætning repræsenterer en anmodning for alle rækker og felter fra tabellen fact_Sale .

Hvis du konsulterer denne anmodning om datakilde, kan det hjælpe dig med bedre at forstå den historie, som forespørgselsplanen forsøger at formidle:

• Sql.Database: Denne node repræsenterer datakildeadgangen. Forbind til databasen og sender metadataanmodninger for at forstå dens egenskaber.
• Value.NativeQuery: Repræsenterer den anmodning, der blev genereret af Power Query for at opfylde forespørgslen. Power Query sender dataanmodningerne i en oprindelig SQL-sætning til datakilden. I dette tilfælde repræsenterer det alle poster og felter (kolonner) fra tabellen fact_Sale . I dette scenarie er dette tilfælde uønsket, da tabellen indeholder millioner af rækker, og interessen kun er i de sidste 10.
• Table.LastN: Når Power Query modtager alle poster fra tabellen fact_Sale , bruges Power Query-programmet til at filtrere tabellen og kun beholde de sidste 10 rækker.
• Table.SelectColumns: Power Query bruger outputtet fra noden Table.LastN og anvender en ny transformering kaldet Table.SelectColumns, som vælger de specifikke kolonner, du vil beholde fra en tabel.

Denne forespørgsel skulle downloade alle rækker og felter fra tabellen for at kunne evaluere den fact_Sale . Denne forespørgsel tog i gennemsnit 6 minutter og 1 sekund at blive behandlet i en standardforekomst af Power BI-dataflow (som står for evaluering og indlæsning af data til dataflow).

Eksempel på delvis forespørgselsdelegering

Når du har oprettet forbindelse til databasen og navigeret til tabellen fact_Sale , skal du starte med at vælge de kolonner, du vil beholde fra tabellen. Vælg transformeringen Vælg kolonner, der findes i gruppen Administrer kolonner under fanen Hjem. Denne transformering hjælper dig med eksplicit at vælge de kolonner, du vil beholde fra tabellen, og fjerne resten.

I dialogboksen Vælg kolonner skal du vælge kolonnerne Sale Key, Customer Key, Invoice Date Key, Descriptionog Quantity og derefter vælge OK.

Du opretter nu logik, der sorterer tabellen, så den har det sidste salg nederst i tabellen. Vælg den Sale Key kolonne, som er den primære nøgle og den trinvise sekvens eller det trinvise indeks for tabellen. Sortér tabellen ved kun at bruge dette felt i stigende rækkefølge i genvejsmenuen for kolonnen.

Derefter skal du vælge den kontekstafhængige menu i tabellen og vælge transformeringen Bevar nederste rækker .

Angiv værdien 10 i Bevar nederste rækker, og vælg derefter OK.

Følgende kodeeksempel er det fulde M-script for den forespørgsel, du har oprettet:

let
  Source = Sql.Database(ServerName, DatabaseName),
  Navigation = Source{[Schema = "wwi", Item = "fact_Sale"]}[Data],
  #"Choose columns" = Table.SelectColumns(Navigation, {"Sale Key", "Customer Key", "Invoice Date Key", "Description", "Quantity"}),
  #"Sorted rows" = Table.Sort(#"Choose columns", {{"Sale Key", Order.Ascending}}),
  #"Kept bottom rows" = Table.LastN(#"Sorted rows", 10)
in
  #"Kept bottom rows"

Eksempel på delvis forespørgselsdelegering: Forståelse af forespørgselsevalueringen

Hvis du kontrollerer ruden anvendte trin, kan du se, at indikatorerne for forespørgselsdelegering viser, at den seneste transformering, du har tilføjet, Kept bottom rowser markeret som et trin, der evalueres uden for datakilden eller med andre ord af Power Query-programmet.

Du kan højreklikke på det sidste trin i forespørgslen, det med navnet Kept bottom rows, og vælge indstillingen Forespørgselsplan for bedre at forstå, hvordan forespørgslen kan evalueres.

Hvert felt i det forrige billede kaldes en node. En node repræsenterer alle de processer, der skal udføres (fra venstre mod højre), for at forespørgslen kan evalueres. Nogle af disse noder kan evalueres i din datakilde, mens andre, f.eks. noden for Table.LastN, repræsenteret af trinnet Beholdt nederste rækker , evalueres ved hjælp af Power Query-programmet.

Hvis du vil se den nøjagtige anmodning, der sendes til din datakilde, skal du vælge Få vist detaljer i noden Value.NativeQuery .

Denne anmodning er på datakildens oprindelige sprog. I dette tilfælde er dette sprog SQL, og denne sætning repræsenterer en anmodning for alle rækkerne, hvor det kun er de ønskede felter fra tabellen fact_Sale , der er sorteret efter feltet Sale Key .

Hvis du konsulterer denne anmodning om datakilde, kan det hjælpe dig med bedre at forstå den historie, som hele forespørgselsplanen forsøger at formidle. Noderækkefølgen er en sekventiel proces, der starter med at anmode om dataene fra datakilden:

• Sql.Database: Forbind til databasen og sender metadataanmodninger for at forstå dens egenskaber.
• Value.NativeQuery: Repræsenterer den anmodning, der blev genereret af Power Query for at opfylde forespørgslen. Power Query sender dataanmodningerne i en oprindelig SQL-sætning til datakilden. I dette tilfælde repræsenterer det alle poster, hvor det kun er de ønskede felter fra tabellen fact_Sale i databasen, der er sorteret i stigende rækkefølge efter feltet Sales Key .
• Table.LastN: Når Power Query modtager alle poster fra tabellen fact_Sale , bruges Power Query-programmet til at filtrere tabellen og kun beholde de sidste 10 rækker.

I forbindelse med evalueringen skulle denne forespørgsel hente alle rækker og kun de påkrævede felter fra tabellen fact_Sale . Det tog i gennemsnit 3 minutter og 4 sekunder at blive behandlet i en standardforekomst af Power BI-dataflow (som står for evaluering og indlæsning af data til dataflow).

Eksempel på fuld forespørgselsdelegering

Når du har oprettet forbindelse til databasen og navigeret til tabellen fact_Sale , skal du starte med at vælge de kolonner, du vil beholde fra tabellen. Vælg transformeringen Vælg kolonner, der findes i gruppen Administrer kolonner under fanen Hjem. Denne transformering hjælper dig med eksplicit at vælge de kolonner, du vil beholde fra tabellen, og fjerne resten.

Vælg kolonnerne Sale Key, Customer Key, Invoice Date Key, Descriptionog Quantity i Vælg kolonner, og vælg derefter OK.

Du opretter nu logik, der sorterer tabellen, så den har det sidste salg øverst i tabellen. Vælg den Sale Key kolonne, som er den primære nøgle og den trinvise sekvens eller det trinvise indeks for tabellen. Sortér kun tabellen ved hjælp af dette felt i faldende rækkefølge fra genvejsmenuen for kolonnen.

Derefter skal du vælge den kontekstafhængige menu i tabellen og vælge transformeringen Bevar de øverste rækker .

Angiv værdien 10 i Bevar de øverste rækker, og vælg derefter OK.

Følgende kodeeksempel er det fulde M-script for den forespørgsel, du har oprettet:

let
  Source = Sql.Database(ServerName, DatabaseName),
  Navigation = Source{[Schema = "wwi", Item = "fact_Sale"]}[Data],
  #"Choose columns" = Table.SelectColumns(Navigation, {"Sale Key", "Customer Key", "Invoice Date Key", "Description", "Quantity"}),
  #"Sorted rows" = Table.Sort(#"Choose columns", {{"Sale Key", Order.Descending}}),
  #"Kept top rows" = Table.FirstN(#"Sorted rows", 10)
in
  #"Kept top rows"

Eksempel på fuld forespørgselsdelegering: Forståelse af forespørgselsevalueringen

Når du kontrollerer ruden anvendte trin, kan du se, at indikatorerne for forespørgselsdelegering viser, at de transformeringer, du har tilføjet, Vælg kolonner, Sorterede rækker og Bevarede øverste rækker, er markeret som trin, der evalueres i datakilden.

Du kan højreklikke på det sidste trin i forespørgslen, som hedder Bevarede øverste rækker, og vælge den indstilling, der læser Forespørgselsplan.

Denne anmodning er på datakildens oprindelige sprog. I dette tilfælde er dette sprog SQL, og denne sætning repræsenterer en anmodning for alle rækker og felter fra tabellen fact_Sale .

Når du konsulterer denne datakildeforespørgsel, kan det hjælpe dig med bedre at forstå den historie, som hele forespørgselsplanen forsøger at formidle:

• Sql.Database: Forbind til databasen og sender metadataanmodninger for at forstå dens egenskaber.
• Value.NativeQuery: Repræsenterer den anmodning, der blev genereret af Power Query for at opfylde forespørgslen. Power Query sender dataanmodningerne i en oprindelig SQL-sætning til datakilden. I dette tilfælde repræsenterer det kun en anmodning om de ti øverste poster i fact_Sale tabellen, hvor det kun er de obligatoriske felter, der er sorteret i faldende rækkefølge ved hjælp af feltet Sale Key .

Bemærk

Selvom der ikke er nogen delsætning, der kan bruges til at VÆLGE de nederste rækker i en tabel på T-SQL-sproget, er der en TOP-delsætning, der henter de øverste rækker i en tabel.

I forbindelse med evalueringen henter denne forespørgsel kun 10 rækker med kun de felter, du har anmodet om, fra tabellen fact_Sale . Denne forespørgsel tog i gennemsnit 31 sekunder at blive behandlet i en standardforekomst af Power BI-dataflow (som står for evaluering og indlæsning af data til dataflow).

Sammenligning af ydeevne

For bedre at forstå den indvirkning, som forespørgselsdelegering har i disse forespørgsler, kan du opdatere dine forespørgsler, registrere den tid, det tager at opdatere hver forespørgsel fuldt ud, og sammenligne dem. For nemheds skyld indeholder denne artikel de gennemsnitlige opdateringstidspunkter, der registreres ved hjælp af mekanikken til opdatering af Power BI-dataflow, mens du opretter forbindelse til et dedikeret Azure Synapse Analytics-miljø med DW2000c som tjenesteniveau.

Opdateringstiden for hver forespørgsel var som følger:

Eksempel	Mærkat	Tid i sekunder
Ingen forespørgselsdelegering	Ingen	361
Delvis forespørgselsdelegering	Delvis	184
Fuld forespørgselsdelegering	Fuld	31

Det er ofte tilfældet, at en forespørgsel, der foldes helt tilbage til datakilden, udkonkurrerer lignende forespørgsler, der ikke kan foldes helt tilbage til datakilden. Der kan være mange grunde til, at dette er tilfældet. Disse årsager spænder fra kompleksiteten af de transformationer, som din forespørgsel udfører, til de forespørgselsoptimeringer, der implementeres i datakilden, f.eks. indekser og dedikeret databehandling og netværksressourcer. Der er stadig to specifikke vigtige processer, som forespørgselsdelegering forsøger at bruge, som minimerer den påvirkning, som begge disse processer har med Power Query:

• Data i transit
• Transformeringer udført af Power Query-programmet

I følgende afsnit forklares den påvirkning, som disse to processer har i de tidligere nævnte forespørgsler.

Data i transit

Når en forespørgsel udføres, forsøger den at hente dataene fra datakilden som et af de første trin. Hvilke data der hentes fra datakilden, defineres af forespørgselsdelegeringsmekanismen. Denne mekanisme identificerer de trin fra forespørgslen, der kan indlæses i datakilden.

I følgende tabel vises det antal rækker, der anmodes om fra fact_Sale tabellen i databasen. Tabellen indeholder også en kort beskrivelse af den SQL-sætning, der sendes for at anmode om sådanne data fra datakilden.

Eksempel	Mærkat	Anmodede rækker	Beskrivelse
Ingen forespørgselsdelegering	Ingen	3644356	Anmodning om alle felter og alle poster fra tabellen fact_Sale
Delvis forespørgselsdelegering	Delvis	3644356	Anmodning om alle poster, men kun obligatoriske felter fra tabellenfact_Sale, efter at den er sorteret efter feltet Sale Key
Fuld forespørgselsdelegering	Fuld	10	Anmod kun om de obligatoriske felter og top 10-poster i fact_Sale tabellen, efter at de er sorteret i faldende rækkefølge efter feltet Sale Key

Når du anmoder om data fra en datakilde, skal datakilden beregne resultaterne for anmodningen og derefter sende dataene til anmoderen. Selvom beregningsressourcerne allerede er blevet nævnt, kan netværksressourcerne til at flytte dataene fra datakilden til Power Query og derefter få Power Query til effektivt at modtage dataene og forberede dem til de transformationer, der sker lokalt, afhængigt af dataenes størrelse.

I forbindelse med de viste eksempler skulle Power Query anmode om mere end 3,6 millioner rækker fra datakilden for eksemplerne uden forespørgselsdelegering og delvis forespørgselsdelegering. I det fulde eksempel på forespørgselsdelegering anmodede den kun om 10 rækker. I forbindelse med de anmodede felter anmodede eksemplet om ingen forespørgselsdelegering alle tilgængelige felter fra tabellen. Både den delvise forespørgselsdelegering og de fulde eksempler på forespørgselsdelegering sendte kun en anmodning om præcis de felter, de havde brug for.

Advarsel

Vi anbefaler, at du implementerer løsninger til trinvis opdatering, der udnytter forespørgselsdelegering til forespørgsler eller tabeller med store mængder data. Forskellige produktintegrationer af Power Query implementerer timeout for at afslutte langvarige forespørgsler. Nogle datakilder implementerer også timeout på langvarige sessioner og forsøger at udføre dyre forespørgsler på deres servere. Flere oplysninger: Brug af trinvis opdatering med dataflow og trinvis opdatering af semantiske modeller

Transformeringer udført af Power Query-programmet

I denne artikel blev det vist, hvordan du kan bruge forespørgselsplanen til bedre at forstå, hvordan din forespørgsel kan evalueres. I forespørgselsplanen kan du se de nøjagtige noder for de transformationshandlinger, der udføres af Power Query-programmet.

I følgende tabel vises noderne fra forespørgselsplanerne for de tidligere forespørgsler, der ville være blevet evalueret af Power Query-programmet.

Eksempel	Mærkat	Transformeringsnoder i Power Query-programmet
Ingen forespørgselsdelegering	Ingen	Table.LastN, Table.SelectColumns
Delvis forespørgselsdelegering	Delvis	Table.LastN
Fuld forespørgselsdelegering	Fuld	—

I forbindelse med de eksempler, der vises i denne artikel, kræver det fulde eksempel på forespørgselsdelegering ikke nogen transformationer i Power Query-programmet, da den påkrævede outputtabel kommer direkte fra datakilden. I modsætning hertil krævede de to andre forespørgsler, at der skulle udføres en beregning i Power Query-programmet. På grund af den mængde data, der skal behandles af disse to forespørgsler, tager processen for disse eksempler mere tid end det fulde eksempel på forespørgselsdelegering.

Transformeringer kan grupperes i følgende kategorier:

Operatortype	Beskrivelse
Fjernbetjening	Operatorer, der er datakildenoder. Evalueringen af disse operatorer sker uden for Power Query.
Streaming	Operatorer er pass-through-operatorer. Med et simpelt filter kan du f.eks. normalt filtrere resultaterne, Table.SelectRows når de passerer gennem operatoren, og de behøver ikke at indsamle alle rækker, før du flytter dataene. Table.SelectColumns og Table.ReorderColumns er andre eksempler på denne type operatorer.
Fuld scanning	Operatorer, der skal indsamle alle rækkerne, før dataene kan gå videre til den næste operator i kæden. Hvis du f.eks. vil sortere data, skal Power Query indsamle alle dataene. Andre eksempler på komplette scanningsoperatorer er Table.Group, Table.NestedJoinog Table.Pivot.

Tip

Selvom det ikke er alle transformeringer, der er ens set ud fra et performance-synspunkt, er det i de fleste tilfælde bedre at have færre transformationer.

Overvejelser og forslag

• Følg de bedste fremgangsmåder, når du opretter en ny forespørgsel, som angivet i Bedste fremgangsmåder i Power Query.
• Brug indikatorerne for forespørgselsdelegering til at kontrollere, hvilke trin der forhindrer, at forespørgslen foldes. Omarranger dem, hvis det er nødvendigt for at øge foldningen.
• Brug forespørgselsplanen til at bestemme, hvilke transformationer der sker i Power Query-programmet for et bestemt trin. Overvej at ændre din eksisterende forespørgsel ved at arrangere dine trin igen. Kontrollér derefter forespørgselsplanen for det sidste trin i forespørgslen igen, og se, om forespørgselsplanen ser bedre ud end den forrige. Den nye forespørgselsplan har f.eks. færre noder end den forrige, og de fleste noder er "Streaming"-noder og ikke "fuld scanning". For datakilder, der understøtter foldning, repræsenterer alle noder i forespørgselsplanen, bortset fra Value.NativeQuery adgangsnoder for datakilder, transformeringer, der ikke blev foldet.
• Når den er tilgængelig, kan du bruge indstillingen Vis oprindelig forespørgsel (eller Vis datakildeforespørgsel) til at sikre, at din forespørgsel kan foldes tilbage til datakilden. Hvis denne indstilling er deaktiveret for dit trin, og du bruger en kilde, der normalt aktiverer den, har du oprettet et trin, der stopper forespørgselsdelegering. Hvis du bruger en kilde, der ikke understøtter denne indstilling, kan du stole på indikatorerne for forespørgselsdelegering og forespørgselsplan.
• Brug værktøjerne til forespørgselsdiagnosticering til bedre at forstå de anmodninger, der sendes til din datakilde, når forespørgselsdelegeringsfunktioner er tilgængelige for connectoren.
• Når du kombinerer datakilder fra brugen af flere connectors, forsøger Power Query at pushe så meget arbejde som muligt til begge datakilder, samtidig med at de overholder de niveauer for beskyttelse af personlige oplysninger, der er defineret for hver datakilde.
• Læs artiklen om niveauer for beskyttelse af personlige oplysninger for at beskytte dine forespørgsler mod at køre mod en fejl i Firewall til beskyttelse af personlige oplysninger.
• Brug andre værktøjer til at kontrollere forespørgselsdelegering ud fra den anmodning, der modtages af datakilden. Baseret på eksemplet i denne artikel kan du bruge Microsoft SQL Server Profiler til at kontrollere de anmodninger, der sendes af Power Query og modtages af Microsoft SQL Server.
• Hvis du føjer et nyt trin til en fuldt foldet forespørgsel, og det nye trin også foldes, kan Power Query sende en ny anmodning til datakilden i stedet for at bruge en cachelagret version af det forrige resultat. I praksis kan denne proces resultere i tilsyneladende simple handlinger på en lille mængde data, der tager længere tid at opdatere i prøveversionen end forventet. Denne længere opdatering skyldes, at Power Query genforespørger datakilden i stedet for at fjerne en lokal kopi af dataene.