Del via

Hjælp til DirectQuery-model i Power BI Desktop

  • Artikel

Denne artikel henvender sig til datamodeludviklere af Power BI DirectQuery-modeller, der er udviklet ved hjælp af enten Power BI Desktop eller Power BI-tjeneste. Den beskriver DirectQuery-use cases, begrænsninger og vejledning. Vejledningen er specifikt designet til at hjælpe dig med at afgøre, om DirectQuery er den rette tilstand for din model, og til at forbedre ydeevnen af dine rapporter baseret på DirectQuery-modeller. Denne artikel gælder for DirectQuery-modeller, der hostes i Power BI-tjeneste eller Power BI-rapportserver.

Denne artikel er ikke beregnet til at give en komplet diskussion om DirectQuery-modeldesign. Du kan finde en introduktion i artiklen DirectQuery-modeller i Power BI Desktop . Hvis du vil have en dybere diskussion, skal du se whitepaperet DirectQuery i SQL Server 2016 Analysis Services . Vær opmærksom på, at dette whitepaper beskriver brugen af DirectQuery i SQL Server Analysis Services. Meget af indholdet gælder dog stadig for Power BI DirectQuery-modeller.

Bemærk

Du kan finde overvejelser, når du bruger DirectQuery-lagringstilstand til Dataverse, i Vejledning til Udformning af Power BI til Power Platform.

Denne artikel dækker ikke direkte sammensatte modeller. En sammensat model består af mindst én DirectQuery-kilde og muligvis mere. Den vejledning, der er beskrevet i denne artikel, er stadig relevant – i det mindste delvist – for design af sammensatte modeller. Konsekvenserne ved at kombinere importtabeller med DirectQuery-tabeller er dog ikke omfattet af denne artikel. Du kan få mere at vide under Brug sammensatte modeller i Power BI Desktop.

Det er vigtigt at forstå, at DirectQuery-modeller pålægger Power BI-miljøet (Power BI-tjeneste eller Power BI-rapportserver) en anden arbejdsbelastning og også de underliggende datakilder. Hvis du finder ud af, at DirectQuery er den rette designtilgang, anbefaler vi, at du engagerer de rette personer i projektet. Vi kan ofte se, at en vellykket Installation af DirectQuery-model er resultatet af et team af it-teknikere, der arbejder tæt sammen. Teamet består normalt af modeludviklere og administratorer af kildedatabasen. Det kan også omfatte dataarkitekter og data warehouse- og ETL-udviklere. Optimeringer skal ofte anvendes direkte på datakilden for at opnå gode ydeevneresultater.

Optimer datakildens ydeevne

Kilden til relationsdatabasen kan optimeres på flere måder, som beskrevet på følgende punktopstilling.

Bemærk

Vi forstår, at det ikke er alle modeludviklere, der har tilladelser eller færdigheder til at optimere en relationsdatabase. Selvom det er det foretrukne lag til at forberede dataene til en DirectQuery-model, kan nogle optimeringer også opnås i modeldesignet uden at ændre kildedatabasen. De bedste optimeringsresultater opnås dog ofte ved at anvende optimeringer på kildedatabasen.

  • Sørg for, at dataintegriteten er fuldført: Det er især vigtigt, at tabeller af dimensionstypen indeholder en kolonne med entydige værdier (dimensionsnøgle), der er knyttet til tabeller af faktatypen. Det er også vigtigt, at dimensionskolonner af faktatypen indeholder gyldige dimensionsværdiværdier. De gør det muligt at konfigurere mere effektive modelrelationer, der forventer matchende værdier på begge sider af relationer. Når kildedataene mangler integritet, anbefales det, at der tilføjes en "ukendt" dimensionspost for effektivt at reparere dataene. Du kan f.eks. føje en række til tabellen Product for at repræsentere et ukendt produkt og derefter tildele den en nøgle uden for området, f.eks. -1. Hvis rækker i tabellen Sales indeholder en manglende produktnøgleværdi, skal du erstatte dem med -1. Det sikrer, at alle salgsproduktnøgleværdier har en tilsvarende række i tabellen Product.

  • Tilføj indekser: Definer relevante indekser – i tabeller eller visninger – for at understøtte effektiv hentning af data til den forventede filtrering og gruppering af rapportvisualiseringer. I forbindelse med SQL Server-, Azure SQL Database- eller Azure Synapse Analytics-kilder (tidligere SQL Data Warehouse) skal du se SQL Server Index Architecture and Design Guide for at få nyttige oplysninger om vejledning til indeksdesign. Du kan se flygtige SQL Server- eller Azure SQL Database-kilder under Kom i gang med Columnstore for at få driftsanalyser i realtid.

  • Design distribuerede tabeller: I forbindelse med Azure Synapse Analytics-kilder (tidligere SQL Data Warehouse), der bruger MPP-arkitektur (Massively Parallel Processing), kan du overveje at konfigurere store tabeller af faktatypen som hash-distribuerede tabeller og tabeller af dimensionstypen, der skal replikeres på tværs af alle beregningsnoderne. Du kan finde flere oplysninger under Vejledning til design af distribuerede tabeller i Azure Synapse Analytics (tidligere SQL Data Warehouse).

  • Sørg for, at de påkrævede datatransformationer materialiseres: For SQL Server-datakilder for relationsdatabasen (og andre kilder til relationsdatabaser) kan beregnede kolonner føjes til tabeller. Disse kolonner er baseret på et udtryk, f.eks . Quantity ganget med UnitPrice. Beregnede kolonner kan bevares (materialiseres), og som almindelige kolonner kan de nogle gange indekseres. Du kan få flere oplysninger under Indekser for beregnede kolonner.

    Overvej også indekserede visninger, der på forhånd kan aggregere faktatabeldata på et højere niveau. Hvis tabellen Sales f.eks. gemmer data på ordrelinjeniveau, kan du oprette en visning for at opsummere disse data. Visningen kan være baseret på en SELECT-sætning, der grupperer dataene i tabellen Sales efter dato (på månedsniveau), kunde, produkt og opsummerer målingsværdier, f.eks. salg, antal osv. Visningen kan derefter indekseres. Du kan se sql Server- eller Azure SQL Database-kilder under Opret indekserede visninger.

  • Materialiser en datotabel: Et almindeligt modelkrav omfatter tilføjelse af en datotabel for at understøtte tidsbaseret filtrering. Hvis du vil understøtte kendte tidsbaserede filtre i din organisation, skal du oprette en tabel i kildedatabasen og sikre, at den indlæses med et interval af datoer, der omfatter datoerne i faktatabellen. Sørg også for, at den indeholder kolonner til nyttige tidsperioder, f.eks. år, kvartal, måned, uge osv.

Optimer modeldesign

En DirectQuery-model kan optimeres på mange måder, som beskrevet på følgende punktopstilling.

  • Undgå komplekse Power Query-forespørgsler: Et effektivt modeldesign kan opnås ved at fjerne behovet for Power Query-forespørgsler for at anvende transformationer. Det betyder, at hver forespørgsel knyttes til en enkelt kildetabel eller -visning for relationsdatabasen. Du kan få vist en repræsentation af den faktiske SQL-forespørgselssætning for et anvendt trin i Power Query ved at vælge indstillingen Vis oprindelig forespørgsel .

    Skærmbillede af Power BI Desktop, der viser indstillingen

    Skærmbillede af Power BI Desktop, der viser vinduet Oprindelig forespørgsel. En forespørgselssætning joinforbinder to kildetabeller.

  • Undersøg brugen af beregnede kolonner og ændringer af datatyper: DirectQuery-modeller understøtter tilføjelse af beregninger og Power Query-trin for at konvertere datatyper. En bedre ydeevne opnås dog ofte ved at materialisere transformationsresultaterne i kilden til relationsdatabasen, når det er muligt.

  • Brug ikke relativ datofiltrering i Power Query: Det er muligt at definere relativ datofiltrering i en Power Query-forespørgsel. Hvis du f.eks. vil hente til de salgsordrer, der blev oprettet i det sidste år (i forhold til dags dato). Denne type filter oversættes til en ineffektiv oprindelig forespørgsel på følgende måde:

    …
from [dbo].[Sales] as [_]
where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and [_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))

    En bedre designtilgang er at inkludere kolonner med relativ tid i datotabellen. Disse kolonner gemmer forskydningsværdier i forhold til den aktuelle dato. I kolonnen RelativeYear repræsenterer værdien nul f.eks. det aktuelle år, -1 repræsenterer forrige år osv. Helst materialiseres kolonnen RelativeYear i datotabellen. Selvom den er mindre effektiv, kan den også tilføjes som en modelberegnet kolonne baseret på udtrykket ved hjælp af DAX-funktionerne TODAY og DATE .

  • Hold målinger enkle: I det mindste indledningsvist anbefales det at begrænse målinger til simple aggregeringer. Aggregeringsfunktionerne omfatter SUM, COUNT, MIN, MAX og AVERAGE. Hvis målingerne derefter er tilstrækkeligt dynamiske, kan du eksperimentere med mere komplekse målinger, men være opmærksom på ydeevnen for hver enkelt. Selvom DAX-funktionen CALCULATE kan bruges til at producere avancerede målingsudtryk, der manipulerer filterkontekst, kan de generere dyre oprindelige forespørgsler, der ikke fungerer godt.

  • Undgå relationer for beregnede kolonner: Modelrelationer kan kun relatere en enkelt kolonne i én tabel til en enkelt kolonne i en anden tabel. Nogle gange er det dog nødvendigt at relatere tabeller ved hjælp af flere kolonner. Tabellerne Sales og Geography er f.eks. relateret af to kolonner: CountryRegion og City. Hvis du vil oprette en relation mellem tabellerne, kræves der en enkelt kolonne, og i tabellen Geography skal kolonnen indeholde entydige værdier. Dette resultat kan opnås ved at sammenkæde land/område og by med en bindestregsseparator.

    Den kombinerede kolonne kan oprettes med enten en brugerdefineret Power Query-kolonne eller i modellen som en beregnet kolonne. Det bør dog undgås, da beregningsudtrykket integreres i kildeforespørgslerne. Det er ikke kun ineffektivt, det forhindrer ofte brugen af indeks. Tilføj i stedet materialiserede kolonner i kilden til relationsdatabasen, og overvej at indeksere dem. Du kan også overveje at føje surrogatnøglekolonner til tabeller af dimensionstypen, hvilket er en almindelig praksis i design af relationsdata warehouses.

    Der er én undtagelse til denne vejledning, og den vedrører brugen af DAX-funktionen COMBINEVALUES . Formålet med denne funktion er at understøtte modelrelationer med flere kolonner. I stedet for at generere et udtryk, som relationen bruger, genereres der et prædikat for SQL Join med flere kolonner.

  • Undgå relationer på kolonner med "Entydigt id": Power BI understøtter ikke datatypen entydigt id (GUID) oprindeligt. Når du definerer en relation mellem kolonner af denne type, genererer Power BI en kildeforespørgsel med en joinforbindelse, der involverer en cast. Denne datakonvertering i forespørgselstid resulterer ofte i dårlig ydeevne. Indtil dette tilfælde er optimeret, er den eneste løsning at materialisere kolonner af en alternativ datatype i den underliggende database.

  • Skjul kolonnen med relationer på én side: En-sidens kolonne i en relation skal skjules. (Det er normalt den primære nøglekolonne i tabeller af dimensionstypen). Når den er skjult, er den ikke tilgængelig i ruden Felter og kan derfor ikke bruges til at konfigurere en visualisering. Kolonnen på mange sider kan forblive synlig, hvis det er nyttigt at gruppere eller filtrere rapporter efter kolonneværdierne. Overvej f.eks. en model, hvor der findes en relation mellem tabellerne Sales og Product . Relationskolonnerne indeholder værdier for produktvarevarenummer (lagerenhed). Hvis produkt-SKU'en skal føjes til visualiseringer, skal den kun være synlig i tabellen Sales . Når denne kolonne bruges til at filtrere eller gruppere i en visualisering, genererer Power BI en forespørgsel, der ikke behøver at joinforbinde tabellerne Salg og Produkt .

  • Angiv relationer for at gennemtvinge integritet: Egenskaben Antag referentiel integritet for DirectQuery-relationer bestemmer, om Power BI genererer kildeforespørgsler ved hjælp af en indre joinforbindelse i stedet for en ydre joinforbindelse. Det forbedrer generelt forespørgselsydeevnen, selvom det afhænger af specifikationerne for kilden til relationsdatabasen. Du kan finde flere oplysninger under Antag indstillinger for referentiel integritet i Power BI Desktop.

  • Undgå brug af tovejsfiltrering af relationer: Brug af tovejsfiltrering af relationer kan føre til forespørgselssætninger, der ikke fungerer korrekt. Brug kun denne relationsfunktion, når det er nødvendigt, og det er normalt tilfældet, når du implementerer en mange til mange-relation på tværs af en brotabel. Du kan få flere oplysninger under Relationer med en mange til mange-kardinalitet i Power BI Desktop.

  • Begræns parallelle forespørgsler: Du kan angive det maksimale antal forbindelser, DirectQuery åbner for hver underliggende datakilde. Den styrer antallet af forespørgsler, der sendes samtidigt til datakilden.

    • Indstillingen er kun aktiveret, når der er mindst én DirectQuery-kilde i modellen. Værdien gælder for alle DirectQuery-kilder og for alle nye DirectQuery-kilder, der føjes til modellen.
    • Hvis du øger værdien For maksimalt antal forbindelser pr. datakilde , sikrer du, at der kan sendes flere forespørgsler (op til det maksimalt angivne antal) til den underliggende datakilde, hvilket er nyttigt, når der er mange visualiseringer på en enkelt side, eller mange brugere får adgang til en rapport på samme tid. Når det maksimale antal forbindelser er nået, sættes yderligere forespørgsler i kø, indtil en forbindelse bliver tilgængelig. Hvis du øger denne grænse, medfører det større belastning af den underliggende datakilde, så indstillingen garanteres ikke at forbedre den overordnede ydeevne.
    • Når modellen publiceres i Power BI, afhænger det maksimale antal samtidige forespørgsler, der sendes til den underliggende datakilde, også af miljøet. Forskellige miljøer (f.eks. Power BI, Power BI Premium eller Power BI-rapportserver) kan hver især pålægge forskellige begrænsninger for gennemløb. Du kan få flere oplysninger om begrænsninger for kapacitetsressourcer i Microsoft Fabric-kapacitetslicenser og Konfigurer og administrer kapaciteter i Power BI Premium.

Vigtigt

Denne artikel henviser til tider Power BI Premium eller dens kapacitetsabonnementer (P-SKU'er). Vær opmærksom på, at Microsoft i øjeblikket konsoliderer købsmuligheder og udfaser Power BI Premium pr. kapacitets-SKU'er. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.

Du kan få flere oplysninger under Vigtige opdateringer, der kommer til Power BI Premium-licenser og Ofte stillede spørgsmål om Power BI Premium.

Optimer rapportdesign

Rapporter, der er baseret på en semantisk DirectQuery-model, kan optimeres på mange måder, som beskrevet på følgende punktopstilling.

  • Aktivér teknikker til reduktion af forespørgsler: Power BI Desktop-indstillinger omfatter siden Reduktion af forespørgsler. Denne side indeholder tre nyttige indstillinger. Det er muligt at deaktivere krydsfremhævning og krydsfiltrering som standard, selvom det kan tilsidesættes ved at redigere interaktioner. Det er også muligt at få vist knappen Anvend på udsnit og filtre. Udsnits- eller filterindstillingerne anvendes ikke, før rapportbrugeren klikker på knappen. Hvis du aktiverer disse indstillinger, anbefaler vi, at du gør det, første gang du opretter rapporten.
  • Anvend filtre først: Når du først designer rapporter, anbefaler vi, at du anvender relevante filtre – på rapport-, side- eller visualiseringsniveau – før du knytter felter til visualiseringsfelterne. I stedet for f.eks. at trække målingerne CountryRegion og Sales og derefter filtrere efter et bestemt år skal du først anvende filteret på feltet År. Det skyldes, at hvert trin i opbygningen af en visualisering sender en forespørgsel, og selvom det er muligt at foretage en anden ændring, før den første forespørgsel er fuldført, medfører den stadig unødvendig belastning på den underliggende datakilde. Ved at anvende filtre tidligt gør det generelt disse mellemliggende forespørgsler billigere og hurtigere. Hvis du ikke anvender filtre tidligt, kan det også resultere i en overskridelse af grænsen på 1 million rækker, som beskrevet i om DirectQuery.
  • Begræns antallet af visualiseringer på en side: Når en rapportside åbnes (og når der anvendes sidefiltre), opdateres alle visualiseringerne på en side. Der er dog en grænse for antallet af forespørgsler, der kan sendes parallelt, som pålægges af Power BI-miljøet og indstillingen Maksimalt antal forbindelser pr. datakildemodel , som beskrevet ovenfor. Så i takt med at antallet af sidevisualiseringer stiger, er der større risiko for, at de opdateres serielt. Det øger den tid, det tager at opdatere hele siden, og det øger også risikoen for, at visualiseringer kan vise uoverensstemmende resultater (for flygtige datakilder). Af disse årsager anbefales det at begrænse antallet af visualiseringer på en hvilken som helst side og i stedet have mere enkle sider. Hvis du erstatter flere kortvisualiseringer med en enkelt kortvisualisering med flere rækker, kan du opnå et lignende sidelayout.
  • Slå interaktion mellem visualiseringer fra: Interaktioner med tværgående fremhævning og krydsfiltrering kræver, at der sendes forespørgsler til den underliggende kilde. Medmindre disse interaktioner er nødvendige, anbefales det, at de slås fra, hvis den tid, det tager at reagere på brugernes valg, vil være urimelig lang. Disse interaktioner kan slås fra, enten for hele rapporten (som beskrevet ovenfor for indstillinger for reduktion af forespørgsler) eller fra sag til sag. Du kan få flere oplysninger under Sådan krydsfiltrerer visualiseringer hinanden i en Power BI-rapport.

Ud over ovenstående liste over optimeringsteknikker kan hver af følgende rapporteringsfunktioner bidrage til problemer med ydeevnen:

  • Målingsfiltre: Visualiseringer, der indeholder målinger (eller samlinger af kolonner), kan have filtre anvendt på disse målinger. I visualiseringen nedenfor kan du f.eks. se Salg efter kategori, men kun for kategorier med et salg på mere end 15 millioner USD.

    Skærmbillede af Power BI Desktop, der viser tabeldata med anvendte filtre.

    Det kan resultere i, at der sendes to forespørgsler til den underliggende kilde:

    • Den første forespørgsel henter de kategorier, der opfylder betingelsen (Salg > 15 mio. USD)
    • Den anden forespørgsel henter derefter de nødvendige data til visualiseringen og føjer de kategorier, der opfylder betingelsen, til WHERE-delsætningen

    Den fungerer generelt fint, hvis der er hundreder eller tusinder af kategorier, som i dette eksempel. Ydeevnen kan dog forringes, hvis antallet af kategorier er meget større (og forespørgslen mislykkes faktisk, hvis der er mere end 1 million kategorier, der opfylder betingelsen på grund af den grænse på 1 million rækker, der er beskrevet ovenfor).

  • TopN-filtre: Avancerede filtre kan defineres til kun at filtrere på de øverste (eller nederste) N-værdier rangeret efter en måling. Hvis du f.eks. kun vil have vist de fem øverste kategorier i ovenstående visualisering. Ligesom målingsfiltrene medfører det også, at der sendes to forespørgsler til den underliggende datakilde. Den første forespørgsel returnerer dog alle kategorier fra den underliggende kilde, og derefter bestemmes det øverste N på baggrund af de returnerede resultater. Afhængigt af kardinaliteten for den involverede kolonne kan det medføre problemer med ydeevnen (eller forespørgselsfejl på grund af grænsen på 1 million rækker).

  • Median: Generelt sendes alle sammenlægninger (Sum, Count Distinct osv.) til den underliggende kilde. Det er dog ikke tilfældet for Median, da denne samling ikke understøttes af den underliggende kilde. I sådanne tilfælde hentes detaljerede data fra den underliggende kilde, og Power BI evaluerer medianen fra de returnerede resultater. Det er fint, når medianen skal beregnes for et relativt lille antal resultater, men der vil opstå problemer med ydeevnen (eller forespørgselsfejl på grund af grænsen på 1 million rækker), hvis kardinaliteten er stor. Medianbefolkningen for land/område kan f.eks. være rimelig, men medianens salgspris er muligvis ikke.

  • Udsnit med flere markeringer: Det kan medføre problemer med ydeevnen at tillade flere markeringer i udsnit og filtre. Det skyldes, at når brugeren vælger flere udsnitselementer (f.eks. opbygning af de 10 produkter, de er interesseret i), medfører hvert nyt valg, at der sendes en ny forespørgsel til den underliggende kilde. Selvom brugeren kan vælge det næste element, før forespørgslen er fuldført, resulterer det i ekstra belastning på den underliggende kilde. Denne situation kan undgås ved at vise knappen Anvend som beskrevet ovenfor i teknikkerne til reduktion af forespørgsler.

  • Visuelle totaler: Tabeller og matrixer viser som standard totaler og subtotaler. I mange tilfælde skal der sendes yderligere forespørgsler til den underliggende kilde for at hente værdierne for totalerne. Den gælder, når du bruger Count Distinct- eller Median-aggregeringer og i alle tilfælde, når du bruger DirectQuery via SAP HANA eller SAP Business Warehouse. Sådanne totaler skal slås fra (ved hjælp af ruden Format), hvis det ikke er nødvendigt.

Konvertér til en sammensat model

Fordelene ved import- og DirectQuery-modeller kan kombineres til en enkelt model ved at konfigurere lagringstilstanden for modeltabellerne. Tabellagringstilstanden kan være Import eller DirectQuery eller begge dele, der kaldes Dual. Når en model indeholder tabeller med forskellige lagringstilstande, kaldes den en sammensat model. Du kan få mere at vide under Brug sammensatte modeller i Power BI Desktop.

Der er mange forbedringer af funktionalitet og ydeevne, der kan opnås ved at konvertere en DirectQuery-model til en sammensat model. En sammensat model kan integrere mere end én DirectQuery-kilde, og den kan også indeholde sammenlægninger. Sammenlægningstabeller kan føjes til DirectQuery-tabeller for at importere en opsummeret repræsentation af tabellen. De kan opnå dramatiske forbedringer af ydeevnen, når visualiseringer forespørger samlinger på højere niveau. Du kan få flere oplysninger under Sammenlægninger i Power BI Desktop.

Oplær brugere

Det er vigtigt at oplære dine brugere i, hvordan de effektivt arbejder med rapporter, der er baseret på semantiske DirectQuery-modeller. Rapportforfatterne skal oplæres i det indhold, der er beskrevet i afsnittet Optimer rapportdesign .

Vi anbefaler, at du uddanner dine rapportforbrugere om dine rapporter, der er baseret på Semantiske DirectQuery-modeller. Det kan være nyttigt for dem at forstå den generelle dataarkitektur, herunder eventuelle relevante begrænsninger, der er beskrevet i denne artikel. Giv dem besked om at forvente, at opdateringssvar og interaktiv filtrering til tider kan være langsom. Når rapportbrugere forstår, hvorfor der sker forringelse af ydeevnen, er der mindre sandsynlighed for, at de mister tilliden til rapporterne og dataene.

Når du leverer rapporter om flygtige datakilder, skal du sørge for at oplære rapportbrugere i brugen af knappen Opdater. Fortæl dem også, at det kan være muligt at se inkonsekvente resultater, og at en opdatering af rapporten kan løse eventuelle uoverensstemmelser på rapportsiden.

Relateret indhold

Du kan finde flere oplysninger om DirectQuery i følgende ressourcer: