DirectQuery i Power BI

DirectQuery i Power BI lar deg beholde data i kilden og spørre dem ved rapporttid i stedet for å importere dem. Denne artikkelen forklarer når du skal bruke DirectQuery, begrensningene og alternativer som hybridtabeller, Direct Lake og live-tilkoblinger, slik at du kan velge riktig modus.

Denne artikkelen beskriver:

• Power BI datatilkoblingsmoduser og hvor DirectQuery passer inn
• Når du skal bruke DirectQuery kontra import, hybridtabeller, Direct Lake eller en live-tilkobling
• Begrensninger, implikasjoner og ytelseshensyn
• Anbefalinger for modellering og rapportutforming
• Diagnostiser og forbedre ytelsen

Rask beslutningsguide

Tabellen nedenfor oppsummerer hvilken Power BI-tilkoblingsmodus du bør vurdere basert på dine behov. Bruk den som en hurtigreferanse for å velge mellom import, DirectQuery, hybridtabeller, Direct Lake eller live-tilkoblinger:

Power BI-datatilkoblingsmoduser

Power BI kobles til mange datakilder:

• Nettjenester som Salesforce og Dynamics 365
• Databaser som SQL Server, PostgreSQL, MySQL, Oracle, Snowflake og Amazon Redshift
• Filer (Excel, CSV, JSON, Parquet)
• Stordata- og analysemotorer som Spark og Databricks
• Andre kilder som nettsider og Microsoft Exchange

Importer data fra disse kildene. Noen støtter også DirectQuery. For en vedlikeholdt liste, se Power BI datakilder. DirectQuery-aktiverte kilder leverer vanligvis interaktiv aggregert spørringsytelse.

Bruk import som standard. Den bruker Power BI sin høyytelses minnemotor og tilbyr det rikeste funksjonssettet. Gå utover import bare når bestemte begrensninger (ventetid, størrelse, styring, sikkerhet eller arkitektur) krever det.

Moderne forbedringer – hybridtabeller, Direct Lake, automatiske aggregasjoner, sammensatte modeller og trinnvis oppdatering – reduserer hvor ofte du trenger ren DirectQuery.

Avsnittene nedenfor dekker import-, DirectQuery- og live-tilkoblingsmoduser. Resten av artikkelen fokuserer på DirectQuery, samtidig som den anerkjenner alternative tilnærminger.

Importer tilkoblinger

Når du importerer data:

• Hent datavalg definerer spørringer per tabellsett. Du kan forme dem (filtrere, samle, sammenføye) før du laster dem inn.
• Alle data som er definert av disse spørringene, lastes inn i den semantiske modellens minnebuffer.
• Bygging av visualobjekter spør bare etter bufrede data – raskt og fullstendig interaktivt.
• Visualobjekter gjenspeiler ikke kildeendringer før du oppdaterer (importerer på nytt).
• Publisering laster opp en semantisk modell som inneholder de importerte dataene. Du kan planlegge oppdatering (frekvensen avhenger av lisensen) og kan trenge en lokal datagateway.
• Når du bygger eller åpner rapporter i tjenesten, brukes de importerte dataene.
• Festede instrumentbordfliser oppdateres når den semantiske modellen oppdateres.

DirectQuery-tilkoblinger

Når du bruker DirectQuery:

• Hent data oppretter en tilkobling til en støttet kilde. For relasjonskilder kan du fortsatt velge tabeller eller visninger. For flerdimensjonale kilder (for eksempel SAP BW) velger du kildemodellen.
• Ingen data importeres ved innlasting. Hvert visualobjekt utløser én eller flere spørringer til den underliggende kilden.
• Ventetiden for visuell oppdatering avhenger helt av den underliggende kildeytelsen (og nettverks-/gateway-overhead hvis aktuelt).
• Endringer i kildedata vises bare etter handlinger som spør på nytt (navigasjon, slicer-/filterendringer, manuell oppdatering).
• Publisering oppretter en semantisk modelldefinisjon (skjema og metadata) uten importerte data.
• Rapporter i tjenesten spør kilden. En gateway kan være nødvendig for lokale kilder.
• Instrumentbordfliser basert på DirectQuery-modeller oppdateres etter en tidsplan for å bufre flisresultater for rask åpning av instrumentbordet.
• Instrumentbordfliser viser resultatene fra den siste planlagte oppdateringen, med mindre de oppdateres manuelt.

Live-tilkoblinger

En levende tilkobling kobler Power BI direkte til en eksisterende semantisk modell (for eksempel Analysis Services eller en annen publisert Power BI-semantisk modell). Det ligner på DirectQuery (ingen importerte data), men semantikk (som rollehåndhevelse) håndteres av oppstrømsmodellen. Når du kobler til direkte:

• Den fullstendige listen over eksterne modellfelt vises—ingen Power Query-spørringsdefinisjon.
• Live-tilkoblinger overfører alltid brukerens identitet til Analysis Services eller Power BI semantic model for sikkerhetstrimming.
• Noen modelleringsaktiviteter (for eksempel å legge til beregnede tabeller) er ikke tilgjengelige fordi modellen er ekstern.

Hvor DirectQuery passer blant nyere alternativer

DirectQuery var den primære løsningen for svært store eller raskt skiftende data som du ikke kunne importere effektivt. I dag:

• Med hybridtabeller kan du blande minne- og DirectQuery-partisjoner i én tabell (nylig kontra historisk).
• Direct Lake (Fabric) gir nesten sanntids tilgang til lakehouse-bordene uten tradisjonell oppfriskningskostnad.
• Automatiske aggregasjoner og manuelle aggregasjonstabeller akseler hyppige spørringer.
• Trinnvis oppdatering med sanntid gjør at det nyeste tidsvinduet DirectQuery kan hente mens eldre data forblir importert.

Evaluer disse alternativene før du tar i bruk en fullstendig DirectQuery-modell.

For sanntids, høyvolum tidsserie-arbeidsbelastninger på Microsoft Fabric, er et vanlig mønster DirectQuery til en Fabric KQL-database (Real-Time Intelligence) kombinert med kildesideaggregeringer og dynamiske M-parametere. Se Kusto-baserte kildevurderinger for veiledning om denne arbeidsmengden.

Brukstilfeller for DirectQuery

DirectQuery er mest fordelaktig når:

• Data endres for ofte for import (selv med trinnvis oppdatering og maksimal planlagt oppdateringsfrekvens), og du trenger synlighet med lav ventetid.
• Datavolum eller styringsbegrensninger gjør fullstendig inntak upraktisk.
• Kildeforsterket sikkerhet (finkornede radregler) må forbli autoritativ via gjennomgang.
• Datasuverenitet eller forskriftsmessige regler begrenser vedvarende fullstendige kopier.
• Kilden er flerdimensjonal eller målsentrisk (for eksempel SAP BW), og serverdefinerte mål må løses per visualobjekt.

Data endres ofte, og du trenger rapportering i nær sanntid

Importerte modeller (Pro) kan planlegge opptil 8 oppdateringer per dag (pluss behovsbetingede/API-utløsere). Premium og PPU støtter opptil 48 planlagte oppdateringer per dag, pluss trinnvis oppdatering og sanntids DirectQuery for den nyeste partisjonen (hybrid). Hvis den nødvendige ventetiden fortsatt ikke kan oppfylles, eller hvis full import ikke kan oppfylles, kan du bruke DirectQuery, hybridtabeller eller Direct Lake. DirectQuery-instrumentbord kan oppdatere fliser så ofte som hvert 15.

Data er store

Full import kan overskride minne- eller oppdateringsvinduer. DirectQuery spør etter data på plass. Hvis kilden er for treg for interaktiv fremføring, bør du vurdere:

• Importerer bare aggregerte eller filtrerte delsett.
• Bruke trinnvis oppdatering og aggregasjoner.
• Bruke hybridtabeller eller Direct Lake for nylige segmenter og segmenter med høy verdi.

Se Store semantiske modeller i Power BI Premium for håndtering av store datamengder i minnet.

Kildeforsterket sikkerhet

Import baserer seg på Power BI-legitimasjon pluss valgfri radnivåsikkerhet (RLS) definert i den semantiske modellen. DirectQuery kan (når det støttes) sende brukeridentitet (SSO) slik at kilden håndhever sine egne sikkerhetsregler. Se Oversikt over single sign-on (SSO) for lokale datagatewayer i Power BI.

Begrensninger for datasuverenitet

Når forskrifter krever at data holder seg innenfor en kontrollert grense, begrenser DirectQuery vedvarende kopier. Hurtigbuffere for visualobjekter og fliser kan fortsatt inneholde begrensede aggregerte data.

Kilde med serverdefinerte mål

Noen systemer (for eksempel SAP BW) inneholder semantisk logikk (mål og hierarkier) som du løser på spørringstidspunktet. DirectQuery aktiverer per visuell oppløsning. Se DirectQuery og SAP BW og DirectQuery og SAP HANA.

Kildespesifikke hensyn (inkludert PostgreSQL og MySQL)

Oppførsel og ytelse varierer fra motor til motor:

• PostgreSQL: Identifikatorer i anførselstegn skiller mellom store og små bokstaver. Sørg for passende b-treindekser på sammenføynings- og filterkolonner. Unngå funksjoner som bryter spørringsdelegering tidlig. Se etter implisitte kast på tekst og numeriske sammenføyninger.
• MySQL: Bruk konsekvente sorteringer og SQL-moduser. Opprett sammensatte indekser for vanlige filter- og sammenføyningsmønstre. Store TEXT søyler kan redusere folding eller tvinge etterbehandling.
• Snowflake, BigQuery og Databricks: Elastisk skalering forbedrer samtidigheten, men ventetid for kaldstart kan påvirke den første spørringen. Send oppvarmingsping eller planlegg periodisk aktivitet.
• Azure Synapse, SQL og Fabric Warehouse: Columnstore-indekser og caching av resultatsett gir sterk akselerasjon. Par dem med automatiske aggregasjoner.
• Kusto-baserte kilder (Azure Data Explorer og Fabric KQL-databaser): Projeksjonsbeskjæring er viktig. Velg bare de nødvendige kolonnene og trykk filtre tidlig. For tidsserietelemetri med høyt volum, bruk kildesideaggregering i stedet for klientsidegruppering: skyv make-series, summarize, og series_decompose_anomalies til KQL-motoren og returner aggregerte resultater til visuelle data. Bekreft at Power Query-steg foldes til native KQL slik at oppsummerte resultater — ikke rå hendelser — returneres til Power BI.
• SAP BW og SAP HANA: Måloppløsning og hierarkisemantikk styrer spørringsmønstre. Unngå overleggstransformasjoner som blokkerer bretting.

Bekreft spørringsfolding (velg View Native Query i Power Query-redigering) slik at transformasjonene trykkes ned.

DirectQuery-begrensninger

Bruk av DirectQuery har implikasjoner på tvers av konsistens, ytelse, sikkerhet, transformasjoner, modellering og rapportering.

Generelle implikasjoner

Følgende generelle implikasjoner gjelder når man bruker DirectQuery i Power BI:

• Oppdater for å se de nyeste dataene. Hurtigbuffere (visualobjekt, flis, resultat) betyr at et visualobjekt kan vise tidligere resultater til det oppdateres. Velg Oppdater for å tvinge frem en ny spørring av alle visualobjekter på en side.
• Det visuelle er ikke alltid tidskonsekvent. Ulike visualobjekter (eller interne spørringer i ett visualobjekt) kan kjøres på litt forskjellige tidspunkter. Oppdater siden eller utform aggregerte øyeblikksbilder hvis det kreves streng nøyaktighet på tidspunktet.
• Skjemaendringer krever en oppfriskning av Power BI Desktop. Tjenesten oppdager ikke automatisk kolonner som er droppet eller har fått nytt navn. Åpne modellen i Power BI Desktop og oppdater for å avstemme modellmetadata.
• En million rader mellomliggende resultatgrense. Alle spørringer (eller mellomliggende operasjoner) som returnerer mer enn 1 000 000 rader, mislykkes. Premium-kapasiteter kan øke denne grensen – se Maks antall mellomliggende radsett.
• Endring av lagringsmodus er begrenset. Du kan ikke globalt bytte en modell med bare import til DirectQuery. Se neste avsnitt.

Endre lagringsmoduser (importere ↔ DirectQuery)

Du kan ikke veksle mellom en hel importmodell og DirectQuery. Isteden:

• Legg til en ny DirectQuery-tilkobling til samme kilde, og tilordne visualobjekter til nye tabeller.
• Opprett en sammensatt modell: behold importdimensjoner, legg til DirectQuery-faktatabeller (eller omvendt), og angi eventuelt noen tabeller til Dual.
• Bruk hybridtabeller (nylige DirectQuery-partisjoner og historisk import) for varm og kald optimalisering.
• Bygg på nytt med brettvennlige transformasjoner hvis tidligere trinn hindrer DirectQuery.

Ytelses- og belastningsimplikasjoner

Interaktiv ytelse avhenger av kildeventetid og samtidighet. Sikt på vanlige visuelle oppdateringstider under 5 sekunder; mer enn 30 sekunder forringer brukervennligheten. Hver brukerhandling utløser spørringer. Høyt antall brukere, visualobjekter og flisoppdateringer kan skape betydelig belastning – planlegg kapasiteten deretter.

Sikkerhetsimplikasjoner

Med mindre SSO er konfigurert, bruker DirectQuery konfigurert lagret legitimasjon for alle seere. Definer RLS i den semantiske modellen etter behov. Flere kilder i sammensatte modeller kan flytte data mellom kilder; Vurder sensitiv databevegelse – se Sikkerhetsimplikasjoner.

Begrensninger for datatransformasjon

Power Query folding er nødvendig for skalerbar ytelse. Transformasjoner må kondenseres til én enkelt opprinnelig spørring. Komplekse trinn (ikke-sammenleggbare operasjoner, visse egendefinerte funksjoner, flertrinns prosedyrelogikk) kan forårsake feil som krever forenkling eller bytte til import. OLAP-kilder som SAP BW tillater ikke transformasjoner i spørringen fordi hele den eksterne modellen er eksponert. Lagrede prosedyrekall og vanlige tabelluttrykk (CTE-er) støttes ikke på en måte som tillater folding i DirectQuery.

Modelleringsbegrensninger

De fleste suppleringer fungerer, men noen funksjoner er redusert:

• Ingen automatisk datohierarki (opprett eksplisitt datotabell).
• Tidspresisjon begrenset til sekunder (fjern millisekunder ved kilden).
• Beregnede kolonner begrenset til radnivåuttrykk som brettes. Funksjoner som ikke støttes, er utelatt fra autofullføring.
• Ingen overordnede/underordnede PATH-funksjoner.
• Klynger støttes ikke.

Rapporteringsbegrensninger

De fleste visualobjekter fungerer hvis kilden er responsiv. Se disse begrensningene og ytelseshensynene:

• Lange tekstkolonner som er lengre enn 32 764 tegn, støttes ikke.
• Målfiltre, TopN-filtre, Median, avansert tekst inneholder/begynner-filtre, slicere med flere valg og totaler/delsummer (spesielt med DistinctCount) kan legge til ekstra spørringer eller redusere ytelsen.
• Vurder å forenkle utformingen eller deaktivere visse interaksjoner.

Eksempel (målfilter):

DirectQuery-anbefalinger

Denne delen gir praktiske anbefalinger for design, optimalisering og feilsøking av DirectQuery-modeller i Power BI. Følg disse retningslinjene for å forbedre ytelsen, påliteligheten og brukeropplevelsen når du arbeider med DirectQuery-tilkoblinger.

Underliggende datakildeytelse

Valider interaktive spørringer for grunnlinjen. Hvis de er trege, inspiser spørringer ved å bruke Ytelsesanalyse og optimaliserer kildeskjemaet (indekser, statistikk og kolonnelagring der det er aktuelt). Foretrekk heltallsnøkler for sammenføyninger.

Modellutforming

• Hold Power Query-stegene enkle og sammenleggbare. Forhåndsvis "Vis opprinnelig spørring" ofte.
• Start med enkle tiltak og gjenta deretter.
• Unngå sammenføyninger i kolonner for beregnede uttrykk – materialiser i kilden om nødvendig.
• Unngå sammenføyninger på uniqueidentifier der kast bryter indeksbruk; materialisere alternative nøkkeltyper.
• Skjul surrogat-/systemnøkler; Opprett synlige aliaskolonner om nødvendig.
• Se gjennom beregnede tabeller/kolonner som kan produsere uttrykk som ikke kan brettes.
• Begrens toveisfiltre til bare obligatoriske tilfeller. Test ytelsespåvirkningen.
• Vurder Anta referanseintegritet for å aktivere INNER JOIN bruk.
• Unngå relative datofiltre i Power Query. Implementer relativ logikk i modell- eller rapportlaget i stedet.

Eksempel på filtrering:

Resulterende opprinnelig spørring bruker en fast litteral dato:

Rapportutforming

Når du utformer rapporter som bruker DirectQuery, bør du vurdere følgende anbefalte fremgangsmåter for å optimalisere brukervennlighet og ytelse:

• Bruk alternativer for spørringsreduksjon (bruk Bruk-knappen for slicere og filtre, og deaktiver kryssutheving der ventetiden skader opplevelsen).

  

• Bruk nøkkelfiltre tidlig for å redusere antall mellomliggende rader og unngå å nå grenser.

• Begrens visualobjekter per side for å minimere parallelle og serialiserte spørringer.

• Deaktiver unødvendige interaksjoner (kryssfiltrering eller utheving) hvis de utløser dyre kildespørringer.

  

Maksimalt antall tilkoblinger

Juster DirectQuery-samtidighet per fil (standard 10) i Filalternativer > og innstillinger > DirectQuery > for gjeldende fil.

Høyere verdier kan forbedre gjennomstrømmingen for mange visualobjekter, men de kan også øke kildebelastningen. Publisert virkemåte avhenger også av tjeneste- eller kapasitetsgrenser.

Funksjoner for ytelsesreduksjon

Bruk disse funksjonene til å forbedre DirectQuery-ytelsen:

• Automatiske aggregasjoner og manuelle aggregasjonstabeller: Bufre oppsummerte data for å redusere kildespørringer.
• Hybride tabeller: Vedlikehold nylige data via DirectQuery, historiske via import.
• Aggregasjonsavhengig målutforming: Sørg for at DAX evalueres på aggregasjonslaget når det er mulig.
• Dynamiske M-parametere: Skyv brukervalg inn i kildepredikater tidlig.
• Hurtigbufring av spørringer og resultater (kapasitetsinnstillinger): Bruk nylige resultatsett på nytt for gjentatte visualobjekter.
• Dobbel lagringsmodus for tabeller med delte dimensjoner: Reduser gjentatte eksterne dimensjonsskanninger.

DirectQuery i Power Bi-tjeneste

Alle DirectQuery-datakilder støttes gjennom Power BI Desktop. Bare et begrenset delsett starter direkte fra tjenestegrensesnittet. Start i Power BI Desktop for rikere modellering og transformasjonskontroll. For den nåværende listen over kilder tilgjengelig direkte i tjenesten, se Power BI datakilder.

Ytelsen i tjenesten avhenger av:

• Antall samtidige brukere
• Visuell kompleksitet og antall per side
• Tilstedeværelse av sikkerhet på radnivå (kan redusere gjenbruk av hurtigbuffer)
• Tidsplaner for oppdatering av fliser

Rapporter atferd i Power Bi-tjeneste

Når du åpner en rapportside, kjøres spørringer for hvert visualobjekt (noen ganger flere per visualobjekt). Samhandlinger (slicerendringer, kryssutheving, filtre) kjører spørringene på nytt. Tjenesten bufrer noen resultater. Eksakte gjentatte spørringer kan returneres umiddelbart med mindre sikkerhetsgrensene er forskjellige.

Kapasitet nyanser:

• Rask innsikt: Støttes ikke for DirectQuery-semantiske modeller.
• Utforsk i Excel / Analyser i Excel: Støttet, men kan føles tregere. Vurder importmodus eller aggregeringer for tung Excel-bruk.
• Hierarkier i Excel: Noen DirectQuery-semantiske modellhierarkier ser ikke like ut i Excel.

Oppdatering av instrumentbord

DirectQuery-fliser oppdateres etter en tidsplan. Standarden er hver time, og du kan angi den fra hvert 15. Med sikkerhet på radnivå kjører hver bruker separate flisspørringer. Et høyt antall fliser multiplisert med antall brukere og oppdateringsfrekvens kan skape stor belastning – planlegg kapasitet og vurder aggregasjoner.

Tidsavbrudd for spørring

Tjenesten håndhever et tidsavbrudd på 4 minutter per spørring. Visualobjekter som overskrider grensen, mislykkes med en tidsavbruddsfeil. Kontroller at underliggende kilder gir interaktiv ytelse før du velger DirectQuery.

Ytelsesdiagnose

Diagnostiser ytelsen først i Power BI Desktop.

Bruk ytelsesanalysen til å isolere trege visualobjekter. Fokuser på ett problematisk bilde om gangen.

Bruk SQL Server Profiler for å se spørringer

Power BI Desktop skriver sesjonsspor, inkludert DirectQuery SQL for noen kilder, til filen FlightRecorderCurrent.trc i brukerens AnalysisServicesWorkspaces-mappe.

Slik finner du sporet:

1. I Power BI Desktop velger du File > Options and settings > Options > Diagnostics.

2. Velg Åpne krasjdump/sporing-mappen.

   

3. Gå opp ett nivå til AnalysisServicesWorkspaces, åpne den aktive arbeidsområdemappen, deretter Data, og finn FlightRecorderCurrent.trc.

4. I SQL Server Profiler, åpne filen: File > Open > Trace File.

Profiler viser grupperte hendelser:

Kolonner for hendelser:

• Tekstdata: DAX (for begynnelse/slutt på spørring) eller opprinnelig SQL (for DirectQuery begynne/slutt).
• Varighet (ms) og EndTime hjelper deg med å finne langsomme stadier.
• ActivityID grupperer relaterte hendelser.

Veiledning for fangst:

• Hold øktene korte (≈10 sekunder med målrettede handlinger).
• Åpne sporingsfilen på nytt for å vise nylig tømte hendelser.
• Unngå flere samtidige skrivebordsforekomster for å redusere forvirring.

Forstå formatet på spørringer

Power BI bruker ofte en subselect (avledet tabell) for hver referert logisk tabell definert av Power Query-trinn.

Eksempel på spørringslogikk:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Resulterende visualobjekt:

Generert SQL med undervalg:

Undervalgsspørringsmønstre skader vanligvis ikke ytelsen på støttede motorer fordi optimaliserere eliminerer ubrukte kolonner. Prioriter sammenleggbarhet.

Relatert innhold

• Bruk DirectQuery i Power BI Desktop
• DirectQuery og SAP HANA
• DirectQuery og SAP BW
• Bruk DirectQuery for Power BI semantiske modeller og analysetjenester
• aggregeringer i Power BI
• Analyse av ytelse
• Sammensatte modeller
• Oversikt over sikkerhet på radnivå
• Enkel pålogging (SSO)