DirectQuery i Power BI

DirectQuery i Power BI lader dig beholde data i kilden og forespørge dem ved rapporttid i stedet for at importere dem. I denne artikel forklares det, hvornår du skal bruge DirectQuery, dets begrænsninger og alternativer som f.eks. hybridtabeller, Direct Lake og direkte forbindelser, så du kan vælge den rigtige tilstand.

I denne artikel beskrives:

• Power BI dataforbindelsestilstande og hvor DirectQuery passer ind
• Hvornår skal du bruge DirectQuery i forhold til import, hybridtabeller, Direct Lake eller en direkte forbindelse
• Begrænsninger, konsekvenser og overvejelser om ydeevne
• Anbefalinger til modellering og rapportdesign
• Diagnosticer og forbedre ydeevnen

Hurtig beslutningsvejledning

Følgende tabel opsummerer, hvilken Power BI-forbindelsestilstand du bør overveje baseret på dine behov. Brug den som en hurtig reference til at hjælpe med at vælge mellem import, DirectQuery, hybridtabeller, Direct Lake eller direkte forbindelser:

Power BI dataforbindelsestilstande

Power BI forbinder til mange datakilder:

• Onlinetjenester som Salesforce og Dynamics 365
• Databaser som SQL Server, PostgreSQL, MySQL, Oracle, Snowflake og Amazon Redshift
• Filer (Excel, CSV, JSON, Parquet)
• Big data og analysemotorer som Spark og Databricks
• Andre kilder som hjemmesider og Microsoft Exchange

Importer data fra disse kilder. Nogle understøtter også DirectQuery. For en vedligeholdt liste, se Power BI datakilder. DirectQuery-aktiverede kilder leverer typisk interaktiv aggregeret forespørgselsydeevne.

Brug import som standard. Den bruger Power BI's højtydende hukommelsesmotor og leverer det rigeste funktionssæt. Gå kun ud over import, når specifikke begrænsninger (ventetid, størrelse, styring, sikkerhed eller arkitektur) kræver det.

Moderne forbedringer – hybridtabeller, Direct Lake, automatiske sammenlægninger, sammensatte modeller og trinvis opdatering – reducerer, hvor ofte du har brug for ren DirectQuery.

I følgende afsnit beskrives import-, DirectQuery- og live-forbindelsestilstande. Resten af artiklen fokuserer på DirectQuery, samtidig med at alternative tilgange anerkendes.

Importér forbindelser

Når du importerer data:

• Hent datavalg definerer forespørgsler pr. tabelsæt. Du kan forme dem (filtrere, aggregere, joinføre), før de indlæses.
• Alle data, der er defineret af disse forespørgsler, indlæses i den semantiske models cache i hukommelsen.
• Opbygning af visualiseringer forespørger kun om de cachelagrede data – hurtigt og fuldt interaktivt.
• Visualiseringer afspejler ikke kildeændringer, før du opdaterer (importerer igen).
• Publicering uploader en semantisk model, der indeholder de importerede data. Du kan planlægge opdatering (hyppigheden afhænger af licensen) og har muligvis brug for en datagateway i det lokale miljø.
• Når du opretter eller åbner rapporter i tjenesten, bruges de importerede data.
• Fastgjorte dashboardfelter opdateres, når den semantiske model opdateres.

DirectQuery-forbindelser

Når du bruger DirectQuery:

• Hent data opretter en forbindelse til en understøttet kilde. For relationskilder kan du stadig vælge tabeller eller visninger. for flerdimensionelle kilder (f.eks. SAP BW) skal du vælge kildemodellen.
• Der importeres ingen data på indlæsningstidspunktet. Hver visualisering udløser en eller flere forespørgsler til den underliggende kilde.
• Ventetiden for visuel opdatering afhænger helt af den underliggende kildeydeevne (og netværks-/gatewayomkostninger, hvis det er relevant).
• Ændringer i kildedata vises kun efter handlinger, der forespørger igen (navigation, ændringer af udsnit/filter, manuel opdatering).
• Publicering opretter en semantisk modeldefinition (skema og metadata) uden importerede data.
• Rapporter i tjenesten forespørger kilden. Der kan være behov for en gateway til kilder i det lokale miljø.
• Dashboardfelter, der er baseret på DirectQuery-modeller, opdateres efter en tidsplan for at cachelagre feltresultater for hurtig åbning af dashboardet.
• Dashboardfelter viser resultaterne fra deres seneste planlagte opdatering, medmindre de opdateres manuelt.

Direkte forbindelser

En liveforbindelse forbinder Power BI direkte til en eksisterende semantisk model (for eksempel Analysis Services eller en anden offentliggjort Power BI-semantisk model). Det svarer til DirectQuery (ingen importerede data), men semantik (f.eks. rollehåndhævelse) håndteres af upstreammodellen. Når du opretter forbindelse live:

• Den fulde liste over eksterne modelfelter vises—ingen Power Query-forespørgselsdefinition.
• Live-forbindelser overfører altid brugerens identitet til Analysis Services eller Power BI-semantiske model til sikkerhedstrimning.
• Nogle modelleringsaktiviteter (f.eks. tilføjelse af beregnede tabeller) er ikke tilgængelige, fordi modellen er ekstern.

Hvor DirectQuery passer blandt nyere muligheder

DirectQuery var den primære løsning til meget store eller hurtigt skiftende data, som du ikke kunne importere effektivt. I dag:

• Hybridtabeller giver dig mulighed for at blande partitioner i hukommelsen og DirectQuery-partitioner i én tabel (seneste vs. historisk).
• Direct Lake (Fabric) giver næsten realtidsadgang til lakehouse-borde uden traditionel opdateringsomkostninger.
• Automatiske sammenlægninger og manuelle sammenlægningstabeller fremskynder hyppige forespørgsler.
• Trinvis opdatering med realtid gør det muligt for det seneste tidsvindue DirectQuery at hente, mens ældre data forbliver importeret.

Evaluer disse indstillinger, før du anvender en komplet DirectQuery-model.

For realtids, højvolumen tidsserie-arbejdsbelastninger på Microsoft Fabric er et almindeligt mønster DirectQuery til en Fabric KQL-database (Real-Time Intelligence) parret med kildeside-aggregationer og dynamiske M-parametre. Se Kusto-baserede kildeovervejelser for vejledning om denne arbejdsbyrde.

DirectQuery-use cases

DirectQuery er mest fordelagtigt, når:

• Data ændres for ofte til import (selv med trinvis opdatering og den maksimale planlagte opdateringsfrekvens), og du har brug for synlighed med lav ventetid.
• Begrænsninger for datamængde eller styring gør fuld indtagelse upraktisk.
• Kildehåndhævet sikkerhed (finkornede rækkeregler) skal forblive autoritativ via passthrough.
• Datasuverænitet eller lovgivningsmæssige regler begrænser vedvarende fulde kopier.
• Kilden er flerdimensionel eller målingscentreret (f.eks. SAP BW), og serverdefinerede målinger skal fortolkes pr. visualisering.

Data ændres ofte, og du har brug for rapportering i næsten realtid

Importerede modeller (Pro) kan planlægge op til 8 opdateringer pr. dag (plus on-demand/API-udløsere). Premium og PPU understøtter op til 48 planlagte opdateringer pr. dag plus trinvis opdatering og DirectQuery i realtid til den nyeste partition (Hybrid). Hvis den påkrævede ventetid stadig ikke kan opfyldes – eller fuld import ikke kan opfyldes – skal du bruge DirectQuery, Hybrid-tabeller eller Direct Lake. DirectQuery-dashboards kan opdatere felter så ofte som hvert 15. minut.

Data er store

Fuld import kan overstige hukommelse eller opdateringsvinduer. DirectQuery forespørger om data på stedet. Hvis kilden er for langsom til interaktiv ydeevne, skal du overveje:

• Importerer kun aggregerede eller filtrerede undersæt.
• Brug af trinvis opdatering og sammenlægninger.
• Brug af hybridtabeller eller Direct Lake til nylige segmenter og segmenter med høj værdi.

Se Large semantic models i Power BI Premium for håndtering af store data i hukommelsen.

Kildehåndhævet sikkerhed

Import er afhængig af Power BI-legitimationsoplysninger samt valgfri række-niveau sikkerhed (RLS) defineret i den semantiske model. DirectQuery kan (når det understøttes) overføre brugeridentitet (SSO), så kilden gennemtvinger sine egne sikkerhedsregler. Se Oversigt over single sign-on (SSO) for on-premises datagateways i Power BI.

Begrænsninger af datasuverænitet

Når regler kræver, at data forbliver inden for en kontrolleret grænse, begrænser DirectQuery fastholdte kopier. Visualiserings- og feltcaches kan stadig indeholde begrænsede aggregerede data.

Kilde med serverdefinerede målinger

Nogle systemer (f.eks. SAP BW) indeholder semantisk logik (målinger og hierarkier), som du løser på forespørgselstidspunktet. DirectQuery aktiverer opløsning pr. visualisering. Se DirectQuery og SAP BW samt DirectQuery og SAP HANA.

Kildespecifikke overvejelser (herunder PostgreSQL og MySQL)

Adfærd og ydeevne varierer fra motor til motor:

• PostgreSQL: Der skelnes mellem store og små bogstaver i anførselstegn. Sørg for passende b-træindekser på join- og filterkolonner. Undgå funktioner, der bryder forespørgselsdelegering tidligt. Kontrollér, om der er implicitte stik på tekst og numeriske joinforbindelser.
• MySQL: Brug ensartede sorteringer og SQL-tilstande. Opret sammensatte indekser til almindelige filter- og joinmønstre. Store TEXT søjler kan reducere foldning eller tvinge efterbehandling.
• Snefnug, BigQuery og Databricks: Elastisk skalering forbedrer samtidigheden, men ventetiden for koldstart kan påvirke den første forespørgsel. Send opvarmningspings eller planlæg periodisk aktivitet.
• Azure Synapse, SQL og Fabric Warehouse: Columnstore-indekser og caching af resultatmængder giver stærk acceleration. Par dem med automatiske sammenlægninger.
• Kusto-baserede kilder (Azure Data Explorer og Fabric KQL-databaser): Beskæring af projektion er vigtig. Vælg kun de nødvendige kolonner, og skub filtre tidligt. For tidsserietelemetri med høj volumen bruges kilde-side aggregering frem for klient-side gruppering: skub make-series, summarize, og series_decompose_anomalies til KQL-motoren og returner aggregerede resultater til visuelle data. Bekræft, at Power Query-trin foldes til native KQL, så opsummerede resultater — ikke rå begivenheder — returneres til Power BI.
• SAP BW og SAP HANA: Målopløsning og hierarkisemantik styrer forespørgselsmønstre. Undgå overlejringstransformationer, der blokerer foldning.

Bekræft forespørgselsfoldning (vælg View Native Query i Power Query-editor), så transformationerne bliver trykket ned.

DirectQuery-begrænsninger

Brug af DirectQuery har konsekvenser på tværs af konsistens, ydeevne, sikkerhed, transformationer, modellering og rapportering.

Generelle konsekvenser

Følgende generelle implikationer gælder, når man bruger DirectQuery i Power BI:

• Opdater for at se de nyeste data. Cachelagre (visualisering, felt, resultat) betyder, at en visualisering kan vise tidligere resultater, indtil den opdateres. Vælg Opdater for at gennemtvinge en ny forespørgsel af alle visualiseringer på en side.
• Visuelle elementer er ikke altid tidskonsistente. Forskellige visualiseringer (eller interne forespørgsler i én visualisering) kan udføres på lidt forskellige tidspunkter. Opdater siden, eller design aggregerede snapshots, hvis der kræves streng nøjagtighed på et bestemt tidspunkt.
• Skemaændringer kræver en opdatering af Power BI Desktop. Tjenesten registrerer ikke automatisk tabte eller omdøbte kolonner. Åbn modellen i Power BI Desktop og opdater for at afstemme modelmetadata.
• En million rækkers mellemliggende resultatgrænse. Enhver forespørgsel (eller mellemliggende handling), der returnerer mere end 1.000.000 rækker, mislykkes. Premium-kapaciteter kan hæve denne grænse – se Maks. antal mellemliggende rækkesæt.
• Ændring af lagringstilstand er begrænset. Du kan ikke globalt skifte en importmodel til DirectQuery. Se næste afsnit.

Ændring af lagringstilstande (Importer ↔ DirectQuery)

Du kan ikke skifte en hel importmodel til DirectQuery. I stedet:

• Føj en ny DirectQuery-forbindelse til den samme kilde, og knyt visualiseringer til nye tabeller.
• Opret en sammensat model: Behold importdimensioner, tilføj DirectQuery-faktatabeller (eller omvendt), og angiv eventuelt nogle tabeller til Dobbelt.
• Brug hybridtabeller (seneste DirectQuery-partitioner og historisk import) til optimering af varm og kold drift.
• Genopbyg med foldvenlige transformationer, hvis tidligere trin forhindrer DirectQuery.

Konsekvenser for ydeevne og belastning

Interaktiv ydeevne afhænger af kildens ventetid og samtidighed. Sigt efter almindelige visuelle opdateringstider under 5 sekunder; mere end 30 sekunder forringer brugervenligheden. Hver brugerhandling udløser forespørgsler. Et højt antal opdateringer af brugere, visualiseringer og felter kan skabe en betydelig belastning – planlæg kapaciteten i overensstemmelse hermed.

Sikkerhedsmæssige konsekvenser

Medmindre SSO er konfigureret, bruger DirectQuery konfigurerede gemte legitimationsoplysninger for alle fremvisere. Definer sikkerhed på rækkeniveau i den semantiske model efter behov. Flere kilder i sammensatte modeller kan flytte data mellem kilder; Vurder flytning af følsomme data – se Sikkerhedskonsekvenser.

Begrænsninger for datatransformation

Power Query folding er nødvendig for skalerbar ydeevne. Transformationer skal kondenseres til en enkelt oprindelig forespørgsel. Komplekse trin (ikke-foldbare handlinger, visse brugerdefinerede funktioner, procedurelogik i flere trin) kan forårsage fejl, der kræver forenkling eller skift til import. OLAP-kilder som SAP BW tillader ikke transformationer i forespørgsler, fordi hele den eksterne model er eksponeret. Kald til lagrede procedurer og almindelige tabeludtryk understøttes ikke på en måde, der gør det muligt at folde i DirectQuery.

Begrænsninger for udformning

De fleste forbedringer fungerer, men nogle funktioner er reduceret:

• Intet automatisk datohierarki (opret eksplicit datotabel).
• Tidspræcision begrænset til sekunder (fjern millisekunder ved kilden).
• Beregnede kolonner begrænset til udtryk på rækkeniveau, der foldes. Ikke-understøttede funktioner udeladt fra autofuldførelse.
• Ingen overordnede/underordnede PATH-funktioner.
• Klyngedannelse understøttes ikke.

Rapporteringsbegrænsninger

De fleste visualiseringer fungerer, hvis kilden er responsiv. Hold øje med disse begrænsninger og overvejelser om ydeevne:

• Lange tekstkolonner, der er længere end 32.764 tegn, understøttes ikke.
• Målingsfiltre, TopN-filtre, avancerede tekst-filtre, Mediander indeholder/begynder filtre, udsnit med flere valg og totaler/subtotaler (især med DistinctCount) kan tilføje ekstra forespørgsler eller forringe ydeevnen.
• Overvej at forenkle design eller deaktivere visse interaktioner.

Eksempel (målingsfilter):

DirectQuery-anbefalinger

Dette afsnit giver praktiske anbefalinger til design, optimering og fejlfinding af DirectQuery-modeller i Power BI. Følg disse retningslinjer for at forbedre ydeevnen, pålideligheden og brugeroplevelsen, når du arbejder med DirectQuery-forbindelser.

Underliggende datakildeydeevne

Valider interaktive forespørgsler i grundlinjen. Hvis de er langsomme, inspicer forespørgsler ved at bruge Effektivitetsanalyse og optimer kildeskemaet (indekser, statistik og kolonnelagring, hvor det er relevant). Foretræk heltalsnøgler til joinforbindelser.

Modeldesign

• Hold Power Query-trinene simple og foldbare. Se ofte "Vis oprindelig forespørgsel".
• Start med enkle foranstaltninger og gentag derefter.
• Undgå joinforbindelser på kolonner med beregnede udtryk – materialiser dig i kilden, hvis det er nødvendigt.
• Undgå joinforbindelser på uniqueidentifier hvor kaster bryder indeksbrug; materialisere alternative nøgletyper.
• Skjul surrogat-/systemnøgler; Opret synlige aliaskolonner, hvis det er nødvendigt.
• Gennemse beregnede tabeller/kolonner, der kan producere ikke-foldbare udtryk.
• Begræns tovejsfiltre til kun at omfatte påkrævede tilfælde. Test påvirkningen af ydeevnen.
• Overvej Antag referentiel integritet for at aktivere INNER JOIN brug.
• Undgå relative datefiltre i Power Query. Implementer relativ logik i modellen eller rapportlaget i stedet.

Eksempel på filtrering:

Den oprindelige forespørgsel bruger en fast konstantdato:

Rapportdesign

Når du designer rapporter, der bruger DirectQuery, skal du overveje følgende bedste fremgangsmåder for at optimere brugervenlighed og ydeevne:

• Brug indstillinger for reduktion af forespørgsler (brug knappen Anvend til udsnit og filtre, og deaktiver tværgående fremhævning, hvor ventetiden skader oplevelsen).

  

• Anvend nøglefiltre tidligt for at reducere antallet af mellemliggende rækker og undgå at nå grænser.

• Begræns visualiseringer pr. side for at minimere parallelle og serialiserede forespørgsler.

• Deaktiver unødvendige interaktioner (krydsfiltrering eller fremhævning), hvis de udløser dyre kildeforespørgsler.

  

Maksimalt antal forbindelser

Juster DirectQuery-samtidighed pr. fil (standard 10) i Filindstillinger > og indstillinger > DirectQuery > for den aktuelle fil.

Højere værdier kan forbedre gennemløbet for mange visualiseringer, men de kan også øge kildebelastningen. Publiceret funktionsmåde afhænger også af tjeneste- eller kapacitetsgrænser.

Funktioner til afbødning af ydeevne

Brug disse funktioner til at forbedre DirectQuery-ydeevnen:

• Automatiske sammenlægninger og manuelle sammenlægningstabeller: Cache opsummerede data for at reducere kildeforespørgsler.
• Hybride tabeller: Vedligehold de seneste data via DirectQuery, historiske via import.
• Sammenlægningsbevidst målingsdesign: Sørg for, at DAX evalueres på aggregeringslaget, når det er muligt.
• Dynamiske M-parametre: Skub brugervalg ind i kildeprædikater tidligt.
• Cachelagring af forespørgsler og resultater (kapacitetsindstillinger): Genbrug de seneste resultatsæt til gentagne visualiseringer.
• Dobbelt lagringstilstand for tabeller med delte dimensioner: Reducer gentagne fjerndimensionsscanninger.

DirectQuery i Power BI-tjeneste

Alle DirectQuery-datakilder understøttes af Power BI Desktop. Kun et begrænset undersæt starter direkte fra tjenestens brugergrænseflade. Start i Power BI Desktop for rigere modellering og transformationskontrol. For den aktuelle liste over kilder, der er tilgængelige direkte i tjenesten, se Power BI datakilder.

Ydeevnen i tjenesten afhænger af:

• Antal samtidige brugere
• Visuel kompleksitet og antal pr. side
• Tilstedeværelse af sikkerhed på rækkeniveau (kan reducere genbrug af cache)
• Tidsplaner for opdatering af felter

Rapportér adfærd i Power BI-tjeneste

Når du åbner en rapportside, køres forespørgsler for hver visualisering (nogle gange flere pr. visualisering). Interaktioner (udsnitsændringer, tværgående fremhævning, filtre) kører forespørgslerne igen. Tjenesten cacher nogle resultater. Nøjagtige gentagne forespørgsler kan returneres med det samme, medmindre sikkerhedsgrænserne er forskellige.

Nuancer af kapacitet:

• Hurtig indsigt: Understøttes ikke for semantiske DirectQuery-modeller.
• Udforsk i Excel / Analyser i Excel: Understøttet, men kan føles langsommere. Overvej importtilstand eller aggregationer til tungt Excel-brug.
• hierarkier i Excel: Nogle DirectQuery-semantiske modelhierarkier ser ikke ens ud i Excel.

Opdatering af dashboard

DirectQuery-felter opdateres efter en tidsplan. Standarden er hver time, og du kan indstille den fra hvert 15. minut op til ugentligt. Med sikkerhed på rækkeniveau kører hver bruger separate feltforespørgsler. Et højt antal felter ganget med antallet af brugere og opdateringsfrekvensen kan skabe stor belastning – planlæg kapacitet, og overvej sammenlægninger.

Timeout for forespørgsel

Tjenesten gennemtvinger en timeout på 4 minutter pr. forespørgsel. Visualiseringer, der overskrider grænsen, mislykkes med en timeoutfejl. Sørg for, at underliggende kilder giver interaktiv ydeevne, før du vælger DirectQuery.

Ydeevnediagnosticering

Diagnosticer ydeevnen først i Power BI Desktop.

Brug Effektivitetsanalyse til at isolere langsomme visualiseringer. Fokuser på én problematisk visualisering ad gangen.

Brug SQL Server Profiler til at se forespørgsler

Power BI Desktop skriver sessionsspor, inklusive DirectQuery SQL for nogle kilder, til filen FlightRecorderCurrent.trc i brugerens AnalysisServicesWorkspaces-mappe.

Sådan finder du sporingen:

1. I Power BI Desktop vælger du Fil > Indstillinger og indstillinger > Indstillinger > Diagnostik.

2. Vælg Åbn mappen Crash Dump/Traces.

   

3. Gå et niveau op til AnalysisServicesWorkspaces, åbn den aktive arbejdsområdemappe, derefter Data, og find FlightRecorderCurrent.trc.

4. I SQL Server Profiler åbn filen: File > Åbn > Trace File.

Profiler viser grupperede hændelser:

Kolonner for begivenheder:

• Tekstdata: DAX (til Forespørgsel Begynd/Slut) eller Native SQL (til DirectQuery Begynd/Slut).
• Varighed (ms) og EndTime hjælper med at lokalisere langsomme faser.
• ActivityID grupperer relaterede hændelser.

Vejledning til optagelse:

• Hold sessionerne korte (≈10 sekunder med målrettede handlinger).
• Åbn sporingsfilen igen for at få vist hændelser, der er tømt for nylig.
• Undgå flere samtidige skrivebordsforekomster for at reducere forvirring.

Forstå formatet af forespørgsler

Power BI bruger ofte en underudvælgelse (afledt tabel) for hver refereret logisk tabel defineret af Power Query-trin.

Eksempel på forespørgselslogik:

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

Resulterende visualisering:

Genereret SQL med undervalg:

Undermarkeringsforespørgselsmønstre skader normalt ikke ydeevnen på understøttede programmer, fordi optimeringsprogrammer eliminerer ubrugte kolonner. Prioriter foldbarhed.

Relateret indhold

• Brug DirectQuery i Power BI Desktop
• DirectQuery og SAP HANA
• DirectQuery og SAP BW
• Brug DirectQuery til Power BI semantiske modeller og Analysis Services
• aggregeringer i Power BI
• Analyse af ydeevne
• Sammensatte modeller
• Oversigt over sikkerhed på rækkeniveau
• Single sign-on (SSO)