Eksempler på spørringsdelegering
Denne artikkelen inneholder noen eksempelscenarioer for hvert av de tre mulige resultatene for spørringsdelegering. Den inneholder også noen forslag til hvordan du får mest mulig ut av spørringsdelegeringsmekanismen, og effekten den kan ha i spørringene.
Scenarioet
Tenk deg et scenario der du, ved hjelp av Wide World Importers-databasen for Azure Synapse Analytics SQL-database, har som oppgave å opprette en spørring i Power Query som kobler til fact_Sale
tabellen og henter de siste 10 salgene med bare følgende felt:
- Salgsnøkkel
- Kundenøkkel
- Fakturadatonøkkel
- Bekrivelse
- Antall
Merk
For demonstrasjonsformål bruker denne artikkelen databasen som er beskrevet i opplæringen om innlasting av Wide World Importers-databasen i Azure Synapse Analytics. Hovedforskjellen fact_Sale
i denne artikkelen er at tabellen bare inneholder data for året 2000, med totalt 3 644 356 rader.
Selv om resultatene kanskje ikke samsvarer nøyaktig med resultatene du får ved å følge opplæringen fra Azure Synapse Analytics-dokumentasjonen, er målet med denne artikkelen å vise frem kjernekonseptene og virkningen som spørringsdelegering kan ha i spørringene dine.
Denne artikkelen viser tre måter å oppnå samme utdata på med ulike nivåer av spørringsdelegering:
- Ingen spørringsdelegering
- Delvis spørringsdelegering
- Fullstendig spørringsdelegering
Ingen eksempel på spørringsdelegering
Viktig
Spørringer som utelukkende er avhengige av ustrukturerte datakilder eller som ikke har en databehandlingsmotor, for eksempel CSV- eller Excel-filer, har ikke funksjoner for spørringsdelegering. Dette betyr at Power Query evaluerer alle nødvendige datatransformasjoner ved hjelp av Power Query-motoren.
Når du har koblet til databasen og navigert til fact_Sale
tabellen, velger du transformeringen Behold nederste rader i Gruppen Reduser rader på Hjem-fanen.
Når du har valgt denne transformasjonen, vises en ny dialogboks. I denne nye dialogboksen kan du angi antall rader du vil beholde. I dette tilfellet skriver du inn verdien 10, og deretter velger du OK.
Tips
I dette tilfellet gir denne operasjonen resultatet av de siste ti salgene. I de fleste scenarioer anbefaler vi at du gir en mer eksplisitt logikk som definerer hvilke rader som vurderes sist, ved å bruke en sorteringsoperasjon i tabellen.
Deretter velger du Velg kolonnetransformeringen som ble funnet i Behandle kolonner-gruppen på Hjem-fanen . Deretter kan du velge kolonnene du vil beholde fra tabellen, og fjerne resten.
Til slutt, i dialogboksen Velg kolonner , velger du Sale Key
kolonnene , Customer Key
, Invoice Date Key
, Description
og Quantity
deretter velger du OK.
Følgende kodeeksempel er det fullstendige M-skriptet for spørringen du opprettet:
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 spørringsdelegering: Forstå spørringsevalueringen
Under Brukte trinn i redigeringsprogrammet for Power Query vil du legge merke til at spørringsdelegeringsindikatorene for lagrede nederste rader og Velg kolonner er merket som trinn som vil bli evaluert utenfor datakilden, eller med andre ord av Power Query-motoren.
Du kan høyreklikke det siste trinnet i spørringen, den som heter Velg kolonner, og velge alternativet som leser Vis spørringsplan. Målet med spørringsplanen er å gi deg en detaljert visning av hvordan spørringen kjøres. Hvis du vil lære mer om denne funksjonen, kan du gå til Spørringsplan.
Hver boks i det forrige bildet kalles en node. En node representerer operasjonsfordelingen for å oppfylle denne spørringen. Noder som representerer datakilder, for eksempel SQL Server i eksemplet ovenfor og Value.NativeQuery
noden, representerer hvilken del av spørringen som er lastet inn til datakilden. Resten av nodene, i dette tilfellet Table.LastN
og Table.SelectColumns
uthevet i rektanglet i det forrige bildet, evalueres av Power Query-motoren. Disse to nodene representerer de to transformeringene du har lagt til, Beholdt nederste rader og Velg kolonner. Resten av nodene representerer operasjoner som skjer på datakildenivå.
Hvis du vil se den nøyaktige forespørselen som sendes til datakilden, velger du Vis detaljer i Value.NativeQuery
noden.
Denne datakildeforespørselen er på det opprinnelige språket i datakilden. I dette tilfellet er dette språket SQL, og denne setningen representerer en forespørsel om alle radene og feltene fra tabellen fact_Sale
.
Ved å konsultere denne datakildeforespørselen kan du bedre forstå historien som spørringsplanen prøver å formidle:
Sql.Database
: Denne noden representerer datakildetilgangen. Koble til til databasen og sender metadataforespørsler for å forstå funksjonene.Value.NativeQuery
: Representerer forespørselen som ble generert av Power Query for å oppfylle spørringen. Power Query sender dataforespørslene i en opprinnelig SQL-setning til datakilden. I dette tilfellet representerer dette alle poster og felt (kolonner) fra tabellenfact_Sale
. I dette scenarioet er dette tilfellet uønsket, siden tabellen inneholder millioner av rader, og interessen er bare i de siste 10.Table.LastN
: Når Power Query mottar alle postene frafact_Sale
tabellen, bruker den Power Query-motoren til å filtrere tabellen og beholde bare de siste 10 radene.Table.SelectColumns
: Power Query bruker utdataeneTable.LastN
fra noden og bruker en ny transformering kaltTable.SelectColumns
, som velger de bestemte kolonnene du vil beholde fra en tabell.
For evalueringen måtte denne spørringen laste ned alle rader og felt fra tabellen fact_Sale
. Denne spørringen brukte i gjennomsnitt 6 minutter og ett sekund på å bli behandlet i en standard forekomst av Power BI-dataflyter (som står for evaluering og innlasting av data til dataflyter).
Eksempel på delvis spørringsdelegering
Når du har koblet til databasen og navigert til fact_Sale
tabellen, begynner du med å velge kolonnene du vil beholde fra tabellen. Velg Velg kolonnetransformeringen som ble funnet i Behandle kolonner-gruppen fra Hjem-fanen. Denne transformasjonen hjelper deg med å eksplisitt velge kolonnene du vil beholde fra tabellen, og fjerne resten.
Velg kolonnene , , Customer Key
, Description
Invoice Date Key
og kolonner i dialogboksen Velg kolonner, og Quantity
velg deretter OKSale Key
.
Nå oppretter du logikk som sorterer tabellen for å ha det siste salget nederst i tabellen. Sale Key
Velg kolonnen, som er primærnøkkelen og trinnvis sekvens eller indeks for tabellen. Sorter tabellen med bare dette feltet i stigende rekkefølge fra hurtigmenyen for kolonnen.
Deretter velger du hurtigmenyen for tabellen og velger Transformer de nederste radene .
Skriv inn verdien 10 i Behold nederste rader, og velg deretter OK.
Følgende kodeeksempel er det fullstendige M-skriptet for spørringen du opprettet:
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 spørringsdelegering: Forstå spørringsevalueringen
Når du kontrollerer den brukte trinnruten, ser du at spørringsdelegeringsindikatorene viser at den siste transformasjonen du la til, Kept bottom rows
er merket som et trinn som vil bli evaluert utenfor datakilden, eller med andre ord av Power Query-motoren.
Du kan høyreklikke det siste trinnet i spørringen, det som heter Kept bottom rows
, og velge alternativet Spørringsplan for bedre å forstå hvordan spørringen kan evalueres.
Hver boks i det forrige bildet kalles en node. En node representerer alle prosesser som må skje (fra venstre mot høyre) for at spørringen skal evalueres. Noen av disse nodene kan evalueres hos datakilden, mens andre, for eksempel noden for Table.LastN
, representert av trinnet Forholdte rader, evalueres ved hjelp av Power Query-motoren.
Hvis du vil se den nøyaktige forespørselen som sendes til datakilden, velger du Vis detaljer i Value.NativeQuery
noden.
Denne forespørselen er på det opprinnelige språket i datakilden. I dette tilfellet er dette språket SQL, og denne setningen representerer en forespørsel om alle radene, med bare de forespurte feltene fra fact_Sale
tabellen bestilt av Sale Key
feltet.
Ved å konsultere denne datakildeforespørselen kan du bedre forstå historien som hele spørringsplanen prøver å formidle. Rekkefølgen på nodene er en sekvensiell prosess som starter ved å be om dataene fra datakilden:
Sql.Database
: Koble til til databasen og sender metadataforespørsler for å forstå funksjonene.Value.NativeQuery
: Representerer forespørselen som ble generert av Power Query for å oppfylle spørringen. Power Query sender dataforespørslene i en opprinnelig SQL-setning til datakilden. I dette tilfellet representerer dette alle postene, med bare de forespurte feltene frafact_Sale
tabellen i databasen sortert i stigende rekkefølge etterSales Key
feltet.Table.LastN
: Når Power Query mottar alle postene frafact_Sale
tabellen, bruker den Power Query-motoren til å filtrere tabellen og beholde bare de siste 10 radene.
For evalueringen måtte denne spørringen laste ned alle rader og bare de nødvendige feltene fra tabellen fact_Sale
. Det tok i gjennomsnitt 3 minutter og 4 sekunder å bli behandlet i en standard forekomst av Power BI-dataflyter (som står for evaluering og innlasting av data til dataflyter).
Eksempel på fullstendig spørringsdelegering
Når du har koblet til databasen og navigert til fact_Sale
tabellen, begynner du med å velge kolonnene du vil beholde fra tabellen. Velg Velg kolonnetransformeringen som ble funnet i Behandle kolonner-gruppen fra Hjem-fanen. Denne transformasjonen hjelper deg med å eksplisitt velge kolonnene du vil beholde fra tabellen, og fjerne resten.
Velg Sale Key
kolonnene , , Customer Key
, Description
Invoice Date Key
og kolonner i Velg kolonner, og Quantity
velg deretter OK.
Nå oppretter du logikk som sorterer tabellen for å ha det siste salget øverst i tabellen. Sale Key
Velg kolonnen, som er primærnøkkelen og trinnvis sekvens eller indeks for tabellen. Sorter tabellen bare ved hjelp av dette feltet i synkende rekkefølge fra hurtigmenyen for kolonnen.
Deretter velger du hurtigmenyen for tabellen og velger Transformer de øverste radene .
Skriv inn verdien 10 i Behold øverste rader, og velg deretter OK.
Følgende kodeeksempel er det fullstendige M-skriptet for spørringen du opprettet:
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å fullstendig spørringsdelegering: Forstå spørringsevalueringen
Når du kontrollerer den brukte trinnruten, vil du legge merke til at spørringsdelegeringsindikatorene viser at transformeringene du har lagt til, Velg kolonner, Sorterte rader og Beholdt øverste rader, er merket som trinn som skal evalueres på datakilden.
Du kan høyreklikke det siste trinnet i spørringen, den som heter Beholdt øverste rader, og velge alternativet som leser spørringsplanen.
Denne forespørselen er på det opprinnelige språket i datakilden. I dette tilfellet er dette språket SQL, og denne setningen representerer en forespørsel om alle radene og feltene fra tabellen fact_Sale
.
Ved å konsultere denne datakildespørringen kan du bedre forstå historien som hele spørringsplanen prøver å formidle:
Sql.Database
: Koble til til databasen og sender metadataforespørsler for å forstå funksjonene.Value.NativeQuery
: Representerer forespørselen som ble generert av Power Query for å oppfylle spørringen. Power Query sender dataforespørslene i en opprinnelig SQL-setning til datakilden. I dette tilfellet representerer dette en forespørsel om bare de ti øverste postene ifact_Sale
tabellen, med bare de nødvendige feltene etter at de er sortert i synkende rekkefølge ved hjelp avSale Key
feltet.
Merk
Selv om det ikke finnes noen setningsdel som kan brukes til å VELGE de nederste radene i en tabell på T-SQL-språket, finnes det en TOP-setningsdel som henter de øverste radene i en tabell.
For evalueringen laster denne spørringen bare ned 10 rader, med bare feltene du ba om fra tabellen fact_Sale
. Denne spørringen brukte i gjennomsnitt 31 sekunder på å bli behandlet i en standard forekomst av Power BI-dataflyter (som står for evaluering og innlasting av data til dataflyter).
Ytelsessammenligning
Hvis du vil forstå hvilken innvirkning spørringsdelegering har i disse spørringene, kan du oppdatere spørringene, registrere tiden det tar å oppdatere hver spørring fullstendig og sammenligne dem. Denne artikkelen inneholder gjennomsnittlige oppdateringstidsberegninger som fanges opp ved hjelp av oppdateringsmekanikeren for Power BI-dataflyter, mens du kobler til et dedikert Azure Synapse Analytics-miljø med DW2000c som tjenestenivå.
Oppdateringstiden for hver spørring var som følger:
Eksempel | Etikett | Tid i sekunder |
---|---|---|
Ingen spørringsdelegering | Ingen | 361 |
Delvis spørringsdelegering | Delvis | 184 |
Fullstendig spørringsdelegering | Full | 31 |
Det er ofte slik at en spørring som brettes helt tilbake til datakilden, overgår lignende spørringer som ikke brettes helt tilbake til datakilden. Det kan være mange grunner til at dette er tilfelle. Disse årsakene spenner fra kompleksiteten til transformeringene som spørringen utfører, til spørringsoptimaliseringene som er implementert hos datakilden, for eksempel indekser og dedikert databehandling og nettverksressurser. Likevel er det to spesifikke nøkkelprosesser som spørringsdelegering prøver å bruke som minimerer virkningen som begge disse prosessene har med Power Query:
- Data under overføring
- Transformeringer utført av Power Query-motoren
Avsnittene nedenfor forklarer hvilken innvirkning disse to prosessene har i de tidligere nevnte spørringene.
Data under overføring
Når en spørring kjøres, prøver den å hente dataene fra datakilden som ett av de første trinnene. Hvilke data som hentes fra datakilden, defineres av spørringsdelegeringsmekanismen. Denne mekanismen identifiserer trinnene fra spørringen som kan avlastes til datakilden.
Tabellen nedenfor viser antall rader som er forespurt fra fact_Sale
tabellen i databasen. Tabellen inneholder også en kort beskrivelse av SQL-setningen som sendes for å be om slike data fra datakilden.
Eksempel | Etikett | Forespurte rader | Bekrivelse |
---|---|---|---|
Ingen spørringsdelegering | Ingen | 3644356 | Forespørsel om alle felt og alle poster fra tabellen fact_Sale |
Delvis spørringsdelegering | Delvis | 3644356 | Be om alle poster, men bare obligatoriske felt fra fact_Sale tabellen etter at den Sale Key ble sortert etter feltet |
Fullstendig spørringsdelegering | Full | 10 | Be om bare de nødvendige feltene og TOP 10-postene i fact_Sale tabellen etter å ha blitt sortert i synkende rekkefølge etter Sale Key feltet |
Når du ber om data fra en datakilde, må datakilden beregne resultatene for forespørselen og deretter sende dataene til anmoderen. Selv om databehandlingsressursene allerede er nevnt, kan nettverksressursene for å flytte dataene fra datakilden til Power Query, og deretter få Power Query til effektivt å motta dataene og klargjøre dem for transformasjonene som vil skje lokalt, ta litt tid, avhengig av størrelsen på dataene.
For eksemplene som vises, måtte Power Query be om over 3,6 millioner rader fra datakilden for eksempler på spørringsdelegering og delvis spørringsdelegering. For det fullstendige spørringsdelegeringseksempelet ba den bare om 10 rader. For de forespurte feltene ba ingen spørringsdelegeringseksemplet om alle tilgjengelige felt fra tabellen. Både den delvise spørringsdelegeringen og de fullstendige spørringsdelegeringseksempler sendte bare inn en forespørsel om nøyaktig de feltene de trengte.
Forsiktig!
Vi anbefaler at du implementerer trinnvise oppdateringsløsninger som bruker spørringsdelegering for spørringer eller tabeller med store mengder data. Ulike produktintegrasjoner av Power Query implementerer tidsavbrudd for å avslutte langvarige spørringer. Noen datakilder implementerer også tidsavbrudd på langvarige økter, og prøver å utføre dyre spørringer mot serverne sine. Mer informasjon: Bruke trinnvis oppdatering med dataflyter og trinnvis oppdatering for semantiske modeller
Transformeringer utført av Power Query-motoren
Denne artikkelen viser hvordan du kan bruke spørringsplanen til bedre å forstå hvordan spørringen kan evalueres. I spørringsplanen kan du se de nøyaktige nodene for transformeringsoperasjonene som skal utføres av Power Query-motoren.
Tabellen nedenfor viser nodene fra spørringsplanene for de forrige spørringene som ville blitt evaluert av Power Query-motoren.
Eksempel | Etikett | Transformeringsnoder i Power Query-motoren |
---|---|---|
Ingen spørringsdelegering | Ingen | Table.LastN , Table.SelectColumns |
Delvis spørringsdelegering | Delvis | Table.LastN |
Fullstendig spørringsdelegering | Full | — |
For eksemplene som vises i denne artikkelen, krever ikke det fullstendige spørringsdelegeringseksemplet noen transformeringer i Power Query-motoren, da den nødvendige utdatatabellen kommer direkte fra datakilden. De to andre spørringene krevde derimot at noen beregninger skulle skje på Power Query-motoren. På grunn av mengden data som må behandles av disse to spørringene, tar prosessen for disse eksemplene mer tid enn det fullstendige spørringsdelegeringseksempelet.
Transformeringer kan grupperes i følgende kategorier:
Type of Operator | Bekrivelse |
---|---|
Eksterne | Operatorer som er datakildenoder. Evalueringen av disse operatorene skjer utenfor Power Query. |
Streaming | Operatorer er direkteoperatorer. Med et enkelt filter kan for eksempel Table.SelectRows vanligvis filtrere resultatene etter hvert som de passerer gjennom operatoren, og trenger ikke å samle alle radene før du flytter dataene. Table.SelectColumns og Table.ReorderColumns er andre eksempler på denne typen operatorer. |
Full skanning | Operatorer som må samle inn alle radene før dataene kan gå videre til neste operator i kjeden. Hvis du for eksempel vil sortere data, må Power Query samle inn alle dataene. Andre eksempler på fullstendige skanneoperatorer er Table.Group , Table.NestedJoin og Table.Pivot . |
Tips
Selv om ikke alle transformasjoner er de samme fra et ytelsessynspunkt, er det vanligvis bedre å ha færre transformeringer.
Vurderinger og forslag
- Følg de anbefalte fremgangsmåtene når du oppretter en ny spørring, som angitt i Anbefalte fremgangsmåter i Power Query.
- Bruk spørringsdelegeringsindikatorene til å kontrollere hvilke trinn som hindrer spørringen i å brettes. Endre rekkefølgen på dem om nødvendig for å øke foldingen.
- Bruk spørringsplanen til å finne ut hvilke transformeringer som skjer i Power Query-motoren for et bestemt trinn. Vurder å endre den eksisterende spørringen ved å ordne trinnene på nytt. Kontroller deretter spørringsplanen for det siste trinnet i spørringen på nytt, og se om spørringsplanen ser bedre ut enn den forrige. Den nye spørringsplanen har for eksempel færre noder enn den forrige, og de fleste nodene er «Strømming»-noder og ikke «fullstendig skanning». For datakilder som støtter folding, representerer eventuelle noder i spørringsplanen annet enn
Value.NativeQuery
og datakildetilgangsnoder transformeringer som ikke ble brettet. - Når det er tilgjengelig, kan du bruke alternativet Vis opprinnelig spørring (eller Vis datakildespørring) for å sikre at spørringen kan brettes tilbake til datakilden. Hvis dette alternativet er deaktivert for trinnet, og du bruker en kilde som vanligvis aktiverer det, har du opprettet et trinn som stopper spørringsdelegering. Hvis du bruker en kilde som ikke støtter dette alternativet, kan du stole på spørringsdelegeringsindikatorene og spørringsplanen.
- Bruk diagnoseverktøyene for spørring til å forstå forespørslene som sendes til datakilden bedre når spørringsdelegeringsfunksjoner er tilgjengelige for koblingen.
- Når du kombinerer data hentet fra bruken av flere koblinger, prøver Power Query å sende så mye arbeid som mulig til begge datakildene, samtidig som de overholder personvernnivåene som er definert for hver datakilde.
- Les artikkelen om personvernnivåer for å beskytte spørringene mot å kjøre mot en brannmurfeil for personvern.
- Bruk andre verktøy til å kontrollere spørringsdelegering fra perspektivet til forespørselen som mottas av datakilden. Basert på eksemplet i denne artikkelen kan du bruke Microsoft SQL Server Profiler til å kontrollere forespørslene som sendes av Power Query og mottas av Microsoft SQL Server.
- Hvis du legger til et nytt trinn i en fullstendig brettet spørring og det nye trinnet også brettes, kan Power Query sende en ny forespørsel til datakilden i stedet for å bruke en bufret versjon av det forrige resultatet. I praksis kan denne prosessen føre til tilsynelatende enkle operasjoner på en liten mengde data som tar lengre tid å oppdatere i forhåndsvisningen enn forventet. Denne lengre oppdateringen skyldes at Power Query spør datakilden på nytt i stedet for å arbeide med en lokal kopi av dataene.