DirectQuery in Power BI

In Power BI Desktop of de Power BI-service kunt u op verschillende manieren verbinding maken met veel verschillende gegevensbronnen. U kunt gegevens importeren in Power BI. Dit is de meest voorkomende manier om gegevens op te halen. U kunt ook rechtstreeks verbinding maken met sommige gegevens in de oorspronkelijke bronopslagplaats, die DirectQuery wordt genoemd. In dit artikel worden voornamelijk DirectQuery-mogelijkheden besproken.

In dit artikel wordt het volgende beschreven:

• De verschillende opties voor Power BI-gegevensconnectiviteit.
• Richtlijnen voor het gebruik van DirectQuery in plaats van importeren.
• Beperkingen en gevolgen van het gebruik van DirectQuery.
• Aanbevelingen voor het gebruik van DirectQuery.
• Prestatieproblemen met DirectQuery vaststellen.

Het artikel richt zich op de DirectQuery-werkstroom wanneer u een rapport maakt in Power BI Desktop, maar behandelt ook het maken van verbinding via DirectQuery in de Power BI-service.

Notitie

DirectQuery is ook een functie van SQL Server Analysis Services. Deze functie deelt veel details met DirectQuery in Power BI, maar er zijn ook belangrijke verschillen. In dit artikel wordt voornamelijk DirectQuery behandeld met Power BI, niet met SQL Server Analysis Services.

Zie Samengestelde modellen gebruiken in Power BI Desktop) voor meer informatie over het gebruik van DirectQuery met SQL Server Analysis Services. U kunt ook de PDF DirectQuery downloaden in SQL Server 2016 Analysis Services.

Power BI-modi voor gegevensconnectiviteit

Power BI maakt verbinding met een groot aantal verschillende gegevensbronnen, zoals:

• Onlineservices zoals Salesforce en Dynamics 365.
• Databases zoals SQL Server, Access en Amazon Redshift.
• Eenvoudige bestanden in Excel, JSON en andere indelingen.
• Andere gegevensbronnen, zoals Spark, websites en Microsoft Exchange.

U kunt gegevens uit deze bronnen importeren in Power BI. Voor sommige bronnen kunt u ook verbinding maken met DirectQuery. Zie Power BI-gegevensbronnen voor een overzicht van de bronnen die DirectQuery ondersteunen. DirectQuery-bronnen zijn voornamelijk bronnen die goede interactieve queryprestaties kunnen leveren.

U moet waar mogelijk gegevens importeren in Power BI. Importeren maakt gebruik van de krachtige query-engine van Power BI en biedt een zeer interactieve, volledig functionele ervaring.

Als u niet aan uw doelstellingen kunt voldoen door gegevens te importeren, bijvoorbeeld als de gegevens regelmatig worden gewijzigd en rapporten de meest recente gegevens moeten weerspiegelen, kunt u DirectQuery gebruiken. DirectQuery is alleen haalbaar wanneer de onderliggende gegevensbron interactieve queryresultaten kan bieden in minder dan vijf seconden voor een typische statistische query en de gegenereerde querybelasting kan verwerken. Houd zorgvuldig rekening met de beperkingen en gevolgen van het gebruik van DirectQuery.

Power BI-import- en DirectQuery-mogelijkheden ontwikkelen zich in de loop van de tijd. Wijzigingen die meer flexibiliteit bieden bij het gebruik van geïmporteerde gegevens, kunnen u vaker importeren en enkele nadelen van het gebruik van DirectQuery elimineren. Ongeacht verbeteringen is de prestaties van de onderliggende gegevensbron een belangrijke overweging bij het gebruik van DirectQuery. Als een onderliggende gegevensbron traag is, blijft het gebruik van DirectQuery voor die bron onfeilbaar.

In de volgende secties worden deze drie opties beschreven voor het maken van verbinding met gegevens: importeren, DirectQuery en liveverbindingen. De rest van het artikel is gericht op DirectQuery.

Verbindingen importeren

Wanneer u verbinding maakt met een gegevensbron zoals SQL Server en gegevens importeert in Power BI Desktop, zijn de volgende connectiviteitsvoorwaarden aanwezig:

• Wanneer u in eerste instantie Get-gegevens gebruikt, definieert elke set tabellen die u selecteert een query die een set gegevens retourneert. U kunt deze query's bewerken voordat u de gegevens laadt, bijvoorbeeld om filters toe te passen, de gegevens samen te voegen of verschillende tabellen samen te voegen.

• Bij het laden worden alle gegevens die door de query's zijn gedefinieerd, geïmporteerd in de Power BI-cache.

• Door een visual te bouwen in Power BI Desktop worden de gegevens in de cache opgevraagd. De Power BI-winkel zorgt ervoor dat de query snel is en dat alle wijzigingen in de visual onmiddellijk worden weergegeven.

• Visuals weerspiegelen geen wijzigingen in de onderliggende gegevens in het gegevensarchief. U moet opnieuw importeren om de gegevens te vernieuwen.

• Als u het rapport publiceert naar het Power BI-service als een PBIX-bestand, wordt een semantisch model gemaakt en geüpload dat de geïmporteerde gegevens bevat. Vervolgens kunt u het vernieuwen van gegevens plannen om de gegevens bijvoorbeeld dagelijks opnieuw te importeren. Afhankelijk van de locatie van de oorspronkelijke gegevensbron kan het nodig zijn om een on-premises gegevensgateway te configureren voor het vernieuwen.

• Als u een bestaand rapport opent of een nieuw rapport maakt in de Power BI-service worden de geïmporteerde gegevens opnieuw opgevraagd, waardoor interactiviteit wordt gegarandeerd.

• U kunt visuals of volledige rapportpagina's vastmaken als dashboardtegels in de Power BI-service. De tegels worden automatisch vernieuwd wanneer het onderliggende semantische model wordt vernieuwd.

DirectQuery-verbindingen

Wanneer u DirectQuery gebruikt om verbinding te maken met een gegevensbron in Power BI Desktop, zijn de volgende voorwaarden voor gegevensverbinding aanwezig:

• U gebruikt Gegevens ophalen om de bron te selecteren. Voor relationele bronnen kunt u nog steeds een set tabellen selecteren waarmee een query wordt gedefinieerd die een set gegevens logisch retourneert. Voor multidimensionale bronnen, zoals SAP Business Warehouse (SAP BW), selecteert u alleen de bron.

• Bij het laden worden er geen gegevens geïmporteerd in het Power BI-archief. Wanneer u een visual bouwt, verzendt Power BI Desktop query's naar de onderliggende gegevensbron om de benodigde gegevens op te halen. De tijd die nodig is om de visual te vernieuwen, is afhankelijk van hoe de onderliggende gegevensbron presteert.

• Wijzigingen in de onderliggende gegevens worden niet direct doorgevoerd in bestaande visuals. Het is nog steeds nodig om te vernieuwen. Power BI Desktop verzendt de benodigde query's voor elke visual opnieuw en werkt de visual indien nodig bij.

• Als u het rapport publiceert naar de Power BI-service een semantisch model maakt en uploadt, hetzelfde als voor importeren. Dit semantische model bevat echter geen gegevens.

• Als u een bestaand rapport opent of een nieuw rapport maakt in de Power BI-service wordt de onderliggende gegevensbron opgevraagd om de benodigde gegevens op te halen. Afhankelijk van de locatie van de oorspronkelijke gegevensbron kan het nodig zijn om een on-premises gegevensgateway te configureren om de gegevens op te halen.

• U kunt visuals of volledige rapportpagina's vastmaken als dashboardtegels. Om ervoor te zorgen dat het openen van een dashboard snel verloopt, worden de tegels automatisch vernieuwd volgens een schema, bijvoorbeeld elk uur. U kunt de vernieuwingsfrequentie bepalen, afhankelijk van hoe vaak de gegevens veranderen en het belang van het weergeven van de meest recente gegevens.

• Wanneer u een dashboard opent, weerspiegelen de tegels de gegevens op het moment van de laatste vernieuwing, niet noodzakelijkerwijs de meest recente wijzigingen in de onderliggende bron. U kunt een geopend dashboard vernieuwen om ervoor te zorgen dat het actueel is.

Liveverbindingen

Wanneer u verbinding maakt met SQL Server Analysis Services, kunt u ervoor kiezen om de gegevens te importeren of een liveverbinding met het geselecteerde gegevensmodel te gebruiken. Het gebruik van een liveverbinding is vergelijkbaar met DirectQuery. Er worden geen gegevens geïmporteerd en de onderliggende gegevensbron wordt opgevraagd om visuals te vernieuwen.

Wanneer u bijvoorbeeld importeren gebruikt om verbinding te maken met SQL Server Analysis Services, definieert u een query op basis van de externe SQL Server Analysis Services-bron en importeert u de gegevens. Als u live verbinding maakt, definieert u geen query en wordt het hele externe model weergegeven in de lijst met velden.

Deze situatie is ook van toepassing wanneer u verbinding maakt met de volgende bronnen, behalve dat er geen optie is om de gegevens te importeren:

• Semantische Power BI-modellen, bijvoorbeeld verbinding maken met een semantisch Power BI-model dat al naar de service is gepubliceerd, om er een nieuw rapport over te maken.

• Microsoft Dataverse.

Wanneer u SQL Server Analysis Services-rapporten publiceert die gebruikmaken van liveverbindingen, is het gedrag in de Power BI-service vergelijkbaar met DirectQuery-rapporten op de volgende manieren:

• Het openen van een bestaand rapport of het ontwerpen van een nieuw rapport in de Power BI-service voert een query uit op de onderliggende SQL Server Analysis Services-bron, waarvoor mogelijk een on-premises gegevensgateway is vereist.

• Dashboardtegels worden automatisch vernieuwd volgens een schema, zoals elk uur.

Een liveverbinding verschilt ook op verschillende manieren van DirectQuery. Liveverbindingen geven bijvoorbeeld altijd de identiteit door van de gebruiker die het rapport opent naar de onderliggende SQL Server Analysis Services-bron.

DirectQuery-gebruiksvoorbeelden

Het maken van verbinding met DirectQuery kan handig zijn in de volgende scenario's. In verschillende gevallen is het noodzakelijk of nuttig om de gegevens op de oorspronkelijke bronlocatie te laten staan.

DirectQuery in Power BI biedt de grootste voordelen in de volgende scenario's:

• De gegevens worden regelmatig gewijzigd en u hebt bijna realtime rapportage nodig.
• U moet grote gegevens verwerken zonder dat u vooraf hoeft te aggregeren.
• De onderliggende bron definieert en past beveiligingsregels toe.
• Beperkingen voor gegevenssoevereine zijn van toepassing.
• De bron is een multidimensionale bron met metingen, zoals SAP BW.

Gegevens worden regelmatig gewijzigd en u hebt bijna realtime rapportage nodig

U kunt modellen met geïmporteerde gegevens maximaal één keer per uur vernieuwen of vaker met Power BI Pro- of Power BI Premium-abonnementen. Als de gegevens voortdurend veranderen en rapporten de meest recente gegevens moeten weergeven, kan het importeren met geplande vernieuwing mogelijk niet aan uw behoeften voldoen. U kunt gegevens rechtstreeks naar Power BI streamen, hoewel er limieten zijn voor de gegevensvolumes die voor dit geval worden ondersteund.

Het gebruik van DirectQuery betekent dat bij het openen of vernieuwen van een rapport of dashboard altijd de meest recente gegevens in de bron worden weergegeven. De dashboardtegels kunnen ook vaker worden bijgewerkt, zo vaak als elke 15 minuten.

Gegevens zijn erg groot

Als de gegevens erg groot zijn, is het niet haalbaar om alle gegevens te importeren. DirectQuery vereist geen grote overdracht van gegevens, omdat er query's worden uitgevoerd op gegevens. Grote gegevens kunnen echter ook de prestaties van query's tegen die onderliggende bron te traag maken.

U hoeft niet altijd volledige, gedetailleerde gegevens te importeren. Met de Power Query-editor kunt u eenvoudig gegevens vooraf aggregeren tijdens het importeren. Technisch gezien is het mogelijk om exact de geaggregeerde gegevens te importeren die u nodig hebt voor elke visual. Hoewel DirectQuery de eenvoudigste benadering is voor grote gegevens, kan het importeren van geaggregeerde gegevens een oplossing bieden als de onderliggende gegevensbron te traag is voor DirectQuery.

Deze details hebben betrekking op het gebruik van Power BI alleen. Zie grote semantische modellen in Power BI Premium voor meer informatie over het gebruik van grote modellen in Power BI. Er is geen beperking voor hoe vaak de gegevens kunnen worden vernieuwd.

De onderliggende bron definieert beveiligingsregels

Wanneer u gegevens importeert, maakt Power BI verbinding met de gegevensbron met behulp van de Power BI Desktop-referenties van de huidige gebruiker of de referenties die zijn geconfigureerd voor geplande vernieuwing vanuit het Power BI-service. Bij het publiceren en delen van rapporten met geïmporteerde gegevens moet u ervoor zorgen dat u alleen deelt met gebruikers die de gegevens mogen zien of moet u beveiliging op rijniveau definiëren als onderdeel van het semantische model.

Met DirectQuery kunnen de referenties van een rapportviewer worden doorgegeven aan de onderliggende bron, waarmee beveiligingsregels worden toegepast. DirectQuery ondersteunt eenmalige aanmelding (SSO) bij Azure SQL-gegevensbronnen en via een gegevensgateway naar on-premises SQL-servers. Zie Overzicht van eenmalige aanmelding (SSO) voor on-premises gegevensgateways in Power BI voor meer informatie.

Beperkingen voor gegevenssoevereine zijn van toepassing

Sommige organisaties hebben beleidsregels voor gegevenssoevereine, wat betekent dat gegevens de organisatie-premises niet kunnen verlaten. Deze gegevens bevatten problemen voor oplossingen op basis van het importeren van gegevens. Met DirectQuery blijven de gegevens op de onderliggende bronlocatie. Zelfs met DirectQuery bewaart de Power BI-service echter enkele caches met gegevens op het niveau van de visual, vanwege geplande vernieuwing van tegels.

De onderliggende gegevensbron maakt gebruik van metingen

Een onderliggende gegevensbron, zoals SAP HANA of SAP BW, bevat metingen. Metingen betekenen dat geïmporteerde gegevens zich al op een bepaald aggregatieniveau bevinden, zoals gedefinieerd door de query. Een visual die vraagt om gegevens op een aggregaties op een hoger niveau, zoals TotalSales per Jaar, voegt de geaggregeerde waarde verder samen. Deze aggregatie is prima voor additieve metingen, zoals Sum en Min, maar kan een probleem zijn voor niet-additieve metingen, zoals Average en DistinctCount.

Voor het eenvoudig ophalen van de juiste geaggregeerde gegevens die rechtstreeks vanuit de bron nodig zijn voor een visual, moeten query's per visual worden verzonden, zoals in DirectQuery. Wanneer u verbinding maakt met SAP BW, kunt u directQuery kiezen voor deze behandeling van metingen. Zie DirectQuery en SAP BW voor meer informatie.

DirectQuery via SAP HANA behandelt momenteel gegevens op dezelfde manier als een relationele bron en produceert gedrag dat vergelijkbaar is met importeren. Zie DirectQuery en SAP HANA voor meer informatie.

Beperkingen voor DirectQuery

Het gebruik van DirectQuery heeft mogelijk negatieve gevolgen. Sommige van deze beperkingen verschillen enigszins, afhankelijk van de exacte bron die u gebruikt. De volgende secties bevatten algemene implicaties van het gebruik van DirectQuery en beperkingen met betrekking tot prestaties, beveiliging, transformaties, modellering en rapportage.

Algemene implicaties

Enkele algemene gevolgen en beperkingen van het gebruik van DirectQuery volgen:

• Als de gegevens worden gewijzigd, moet u vernieuwen om de meest recente gegevens weer te geven. Gezien het gebruik van caches is er geen garantie dat visuals altijd de meest recente gegevens weergeven. Een visual kan bijvoorbeeld transacties in de afgelopen dag weergeven. Een slicerwijziging kan de visual vernieuwen om transacties voor de afgelopen twee dagen weer te geven, inclusief recente, nieuw aangekomen transacties. Maar het retourneren van de slicer naar de oorspronkelijke waarde kan ertoe leiden dat de vorige waarde in de cache opnieuw wordt weergegeven. Selecteer Vernieuwen om alle caches te wissen en alle visuals op de pagina te vernieuwen om de meest recente gegevens weer te geven.

• Als gegevens worden gewijzigd, is er geen garantie voor consistentie tussen visuals. Verschillende visuals, ongeacht op dezelfde pagina of op verschillende pagina's, kunnen op verschillende momenten worden vernieuwd. Als de gegevens in de onderliggende bron worden gewijzigd, is er geen garantie dat elke visual de gegevens op hetzelfde moment weergeeft.

  Aangezien er meer dan één query vereist is voor één visual, bijvoorbeeld om de details en totalen te verkrijgen, is zelfs consistentie binnen één visual niet gegarandeerd. Om deze consistentie te garanderen, is de overhead van het vernieuwen van alle visuals vereist wanneer een visual wordt vernieuwd, samen met het gebruik van dure functies zoals isolatie van momentopnamen in de onderliggende gegevensbron.

  U kunt dit probleem in grote mate verhelpen door Vernieuwen te selecteren om alle visuals op de pagina te vernieuwen. Zelfs voor de importmodus is er een vergelijkbaar probleem met het onderhouden van consistentie wanneer u gegevens uit meer dan één tabel importeert.

• U moet vernieuwen in Power BI Desktop om schemawijzigingen weer te geven. Nadat een rapport is gepubliceerd, vernieuwt u vernieuwen in de Power BI-service de visuals in het rapport vernieuwt. Maar als het onderliggende bronschema verandert, wordt de Power BI-service de lijst met beschikbare velden niet automatisch bijgewerkt. Als tabellen of kolommen uit de onderliggende bron worden verwijderd, kan dit leiden tot een queryfout bij het vernieuwen. Als u de velden in het model wilt bijwerken om de wijzigingen weer te geven, moet u het rapport openen in Power BI Desktop en vernieuwen kiezen.

• Een limiet van 1 miljoen rijen kan worden geretourneerd voor elke query. Er is een vaste limiet van 1 miljoen rijen die in één query naar de onderliggende bron kunnen worden geretourneerd. Deze limiet heeft over het algemeen geen praktische gevolgen en visuals geven niet zoveel punten weer. De limiet kan echter optreden in gevallen waarin Power BI de verzonden query's niet volledig optimaliseert en een tussenliggend resultaat aanvraagt dat de limiet overschrijdt.

  De limiet kan ook optreden tijdens het bouwen van een visual, op het pad naar een redelijkere eindstatus. Als u bijvoorbeeld Klant en TotalSalesQuantity opgeeft, kan deze limiet worden bereikt als er meer dan 1 miljoen klanten zijn, totdat u een filter toepast. De fout die wordt geretourneerd, is: de resultatenset van een query naar een externe gegevensbron heeft de maximaal toegestane grootte van 1000000 rijen overschreden.

  Notitie

  Met Premium-capaciteiten kunt u de limiet van één miljoen rijen overschrijden. Zie Maximumaantal tussenliggende rijen voor meer informatie.

• U kunt een model niet wijzigen van importeren in de DirectQuery-modus. U kunt een model overschakelen van de DirectQuery-modus naar de importmodus als u alle benodigde gegevens importeert. Het is niet mogelijk om terug te schakelen naar de DirectQuery-modus, voornamelijk vanwege de functieset die de DirectQuery-modus niet ondersteunt. Voor multidimensionale bronnen zoals SAP BW kunt u ook niet overschakelen van DirectQuery naar de importmodus vanwege de verschillende behandeling van externe metingen.

Gevolgen voor prestaties en belasting

Wanneer u DirectQuery gebruikt, is de algehele ervaring afhankelijk van de prestaties van de onderliggende gegevensbron. Als het vernieuwen van elke visual, bijvoorbeeld na het wijzigen van een slicerwaarde, minder dan vijf seconden duurt, is de ervaring redelijk, hoewel deze mogelijk traag is vergeleken met het onmiddellijke antwoord met geïmporteerde gegevens. Als de traagheid van de bron ervoor zorgt dat afzonderlijke visuals langer dan tientallen seconden duren om te vernieuwen, wordt de ervaring onredelijk slecht. Er is mogelijk zelfs een time-out opgetreden voor query's.

Naast de prestaties van de onderliggende bron, heeft de belasting die op de bron wordt geplaatst ook invloed op de prestaties. Elke gebruiker die een gedeeld rapport opent en elke dashboardtegel die wordt vernieuwd, verzendt ten minste één query per visual naar de onderliggende bron. De bron moet in staat zijn om een dergelijke querybelasting af te handelen zonder redelijke prestaties te behouden.

Gevolgen voor beveiliging

Tenzij de onderliggende gegevensbron gebruikmaakt van eenmalige aanmelding, gebruikt een DirectQuery-rapport altijd dezelfde vaste referenties om verbinding te maken met de bron zodra deze is gepubliceerd naar het Power BI-service. Onmiddellijk nadat u een DirectQuery-rapport hebt gepubliceerd, moet u de referenties configureren die de gebruiker moet gebruiken. Totdat u de referenties configureert, wordt er een fout weergegeven wanneer u het rapport probeert te openen in de Power BI-service.

Zodra u de gebruikersreferenties hebt opgegeven, gebruikt Power BI deze referenties voor degene die het rapport opent, hetzelfde als voor geïmporteerde gegevens. Elke gebruiker ziet dezelfde gegevens, tenzij beveiliging op rijniveau is gedefinieerd als onderdeel van het rapport. U moet dezelfde aandacht besteden aan het delen van het rapport als voor geïmporteerde gegevens, zelfs als er beveiligingsregels zijn gedefinieerd in de onderliggende bron.

• Verbinding maken met semantische Power BI-modellen en Analysis Services in de DirectQuery-modus maakt altijd gebruik van eenmalige aanmelding, dus de beveiliging is vergelijkbaar met liveverbindingen met Analysis Services.

• Alternatieve referenties worden niet ondersteund bij het maken van DirectQuery-verbindingen met SQL Server vanuit Power BI Desktop. U kunt uw huidige Windows-referenties of databasereferenties gebruiken.

• U kunt meerdere gegevensbronnen in een DirectQuery-model gebruiken met behulp van samengestelde modellen. Wanneer u meerdere gegevensbronnen gebruikt, is het belangrijk om inzicht te krijgen in de beveiligingseffecten van hoe gegevens heen en weer worden verplaatst tussen de onderliggende gegevensbronnen.

Beperkingen voor gegevenstransformatie

DirectQuery beperkt de gegevenstransformaties die u binnen Power Query-editor kunt toepassen. Met geïmporteerde gegevens kunt u eenvoudig een geavanceerde set transformaties toepassen om de gegevens op te schonen en opnieuw vorm te geven voordat u deze gebruikt om visuals te maken. U kunt bijvoorbeeld JSON-documenten parseren of gegevens van een kolom naar een rijformulier draaien. Deze transformaties zijn beperkter in DirectQuery.

Wanneer u verbinding maakt met een OLAP-bron (online analytical processing), zoals SAP BW, kunt u geen transformaties definiëren en wordt het hele externe model uit de bron gehaald. Voor relationele bronnen zoals SQL Server kunt u nog steeds een set transformaties per query definiëren, maar deze transformaties zijn om prestatieredenen beperkt.

Transformaties moeten worden toegepast op elke query op de onderliggende bron, in plaats van één keer bij het vernieuwen van gegevens. Transformaties moeten redelijk kunnen worden omgezet in één systeemeigen query. Als u een transformatie gebruikt die te complex is, krijgt u een foutmelding dat deze moet worden verwijderd of dat het verbindingsmodel moet worden overgeschakeld naar importeren.

Het dialoogvenster Gegevens ophalen of Power Query-editor ook subselecties gebruiken binnen de query's die ze genereren en verzenden om gegevens voor een visual op te halen. Query's die zijn gedefinieerd in Power Query-editor moeten geldig zijn binnen deze context. Het is met name niet mogelijk om een query te gebruiken met algemene tabelexpressies, noch een query die opgeslagen procedures aanroept.

Modelleringsbeperkingen

De term modellering in deze context betekent het verfijnen en verrijken van onbewerkte gegevens als onderdeel van het ontwerpen van een rapport met behulp van de gegevens. Voorbeelden van modellering zijn:

• Relaties tussen tabellen definiëren.
• Nieuwe berekeningen toevoegen, zoals berekende kolommen en metingen.
• De naam van kolommen en metingen wijzigen en verbergen.
• Hiërarchieën definiëren.
• Kolomopmaak, standaardsamenvatting en sorteervolgorde definiëren.
• Groeperings- of clusterwaarden.

U kunt nog steeds veel van deze modelverrijkingen maken wanneer u DirectQuery gebruikt en het principe gebruiken om de onbewerkte gegevens te verrijken om later verbruik te verbeteren. Sommige modelleringsmogelijkheden zijn echter niet beschikbaar of zijn beperkt met DirectQuery. De beperkingen worden toegepast om prestatieproblemen te voorkomen.

De volgende beperkingen zijn gebruikelijk voor alle DirectQuery-bronnen. Er kunnen meer beperkingen van toepassing zijn op afzonderlijke bronnen.

• Geen ingebouwde datumhiërarchie: bij geïmporteerde gegevens heeft elke datum/datum/tijd-kolom ook standaard een ingebouwde datumhiërarchie beschikbaar. Als u bijvoorbeeld een tabel met verkooporders importeert die een kolom OrderDatum bevat en u OrderDatum in een visual gebruikt, kunt u het juiste datumniveau kiezen dat u wilt gebruiken, zoals jaar, maand of dag. Deze ingebouwde datumhiërarchie is niet beschikbaar met DirectQuery. Als er een datumtabel beschikbaar is in de onderliggende gegevensbron, zoals gebruikelijk is in veel datawarehouses, kunt u de time intelligence-functies van Data Analysis Expressions (DAX) zoals gebruikelijk gebruiken.

• Ondersteuning voor datum/tijd alleen tot het niveau seconden: Voor semantische modellen die tijdkolommen gebruiken, geeft Power BI query's alleen tot aan het detailniveau van de seconden aan de onderliggende DirectQuery-bron, niet milliseconden. Verwijder millisecondengegevens uit de bronkolommen.

• Beperkingen in berekende kolommen: berekende kolommen kunnen alleen intra-rij zijn, dat wil gezegd dat ze alleen kunnen verwijzen naar waarden van andere kolommen van dezelfde tabel, zonder statistische functies te gebruiken. Bovendien zijn de toegestane DAX-scalaire functies, zoals LEFT(), beperkt tot die functies die naar de onderliggende bron kunnen worden gepusht. De functies variëren, afhankelijk van de exacte mogelijkheden van de bron. Functies die niet worden ondersteund, worden niet weergegeven in automatisch aanvullen bij het ontwerpen van de DAX-query voor een berekende kolom en resulteren in een fout als deze wordt gebruikt.

• Geen ondersteuning voor bovenliggende en onderliggende DAX-functies: wanneer in de DirectQuery-modus, is het niet mogelijk om de familie van DAX PATH() functies te gebruiken die meestal bovenliggende/onderliggende structuren verwerken, zoals grafieken van accounts of werknemershiërarchieën.

• Geen clustering: wanneer u DirectQuery gebruikt, kunt u de clusterfunctie niet gebruiken om automatisch groepen te vinden.

Rapportagebeperkingen

Bijna alle rapportagemogelijkheden worden ondersteund voor DirectQuery-modellen. Zolang de onderliggende bron een geschikt prestatieniveau biedt, kunt u dezelfde set visualisaties gebruiken als voor geïmporteerde gegevens.

Een algemene beperking is dat de maximale lengte van gegevens in een tekstkolom voor semantische DirectQuery-modellen 32.764 tekens is. Rapportage over langere teksten resulteert in een fout.

De volgende power BI-rapportagemogelijkheden kunnen prestatieproblemen veroorzaken in directQuery-rapporten:

• Maateenheidfilters: visuals die gebruikmaken van metingen of aggregaties van kolommen kunnen filters in deze metingen bevatten. In de volgende afbeelding ziet u bijvoorbeeld SalesAmount per categorie, maar alleen voor categorieën met meer dan 20 miljoen verkoop.

  

  Deze methode zorgt ervoor dat twee query's naar de onderliggende bron worden verzonden:

  • De eerste query haalt de categorieën op die voldoen aan de voorwaarde SalesAmount groter dan 20 miljoen.
  • Met de tweede query worden de benodigde gegevens opgehaald voor de visual, waaronder de categorieën die aan de WHERE voorwaarde voldoen.

  Deze benadering werkt over het algemeen goed als er honderden of duizenden categorieën zijn, zoals in dit voorbeeld. Prestaties kunnen afnemen als het aantal categorieën veel groter is. De query mislukt als er meer dan een miljoen categorieën zijn.

• TopN-filters: u kunt geavanceerde filters definiëren om alleen te filteren op de hoogste of laagste N waarden gerangschikt op een bepaalde meting. Filters kunnen bijvoorbeeld de top 10 categorieën bevatten. Met deze methode worden nogmaals twee query's naar de onderliggende bron verzonden. De eerste query retourneert echter alle categorieën uit de onderliggende bron en vervolgens worden de TopN categorieën bepaald op basis van de geretourneerde resultaten. Afhankelijk van de kardinaliteit van de betrokken kolom kan deze aanpak leiden tot prestatieproblemen of queryfouten vanwege de limiet van één miljoen rijen voor queryresultaten.

• Mediaan: elke aggregatie, zoals Sum of Count Distinct, wordt naar de onderliggende bron gepusht. De median statistische functie wordt echter meestal niet ondersteund door de onderliggende bron. Hiervoor medianworden de detailgegevens opgehaald uit de onderliggende bron en wordt de mediaan berekend op basis van de geretourneerde resultaten. Deze methode is redelijk voor het berekenen van de mediaan over een relatief klein aantal resultaten.

  Prestatieproblemen of queryfouten kunnen optreden als de kardinaliteit groot is vanwege de limiet van één miljoen rijen. Het kan bijvoorbeeld redelijk zijn om query's uit te voeren op mediaanland/regiopopulatie , maar de mediaanverkoopprijs is mogelijk niet redelijk.

• Geavanceerde tekstfilters zoals 'contains': Geavanceerd filteren op een tekstkolom maakt filters zoals contains en begins with. Deze filters kunnen leiden tot verminderde prestaties voor sommige gegevensbronnen. Gebruik met name het standaardfilter contains niet als u een exacte overeenkomst nodig hebt. Hoewel de resultaten mogelijk hetzelfde zijn, afhankelijk van de werkelijke gegevens, kunnen de prestaties drastisch verschillen vanwege indexen.

• Slicers met meerdere selecties: slicers staan standaard slechts één selectie toe. Het toestaan van meervoudige selectie in filters kan prestatieproblemen veroorzaken. Als de gebruiker bijvoorbeeld 10 producten van belang selecteert, resulteert elke nieuwe selectie in query's die naar de bron worden verzonden. Hoewel de gebruiker het volgende item kan selecteren voordat de query is voltooid, leidt deze benadering tot extra belasting van de onderliggende bron.

• Totalen voor tabelvisuals: in tabellen en matrices worden standaard totalen en subtotalen weergegeven. In veel gevallen moeten afzonderlijke query's naar de onderliggende bron worden verzonden om de waarden voor dergelijke totalen op te halen. Deze vereiste is van toepassing wanneer u aggregatie gebruikt DistinctCount of in alle gevallen waarin DirectQuery via SAP BW of SAP HANA wordt gebruikt. U kunt dergelijke totalen uitschakelen met behulp van het deelvenster Opmaak .

Aanbevelingen voor DirectQuery

Deze sectie bevat richtlijnen op hoog niveau voor het gebruik van DirectQuery, gezien de implicaties ervan.

Prestaties van onderliggende gegevensbronnen

Valideer dat eenvoudige visuals binnen vijf seconden worden vernieuwd, wat een redelijke interactieve ervaring biedt. Als het vernieuwen van visuals langer dan 30 seconden duurt, is het waarschijnlijk dat verdere problemen na de publicatie van het rapport de oplossing onwerkbaar maken.

Als query's traag zijn, bekijkt u de query's die naar de onderliggende bron worden verzonden en de reden voor de trage prestaties. Zie Prestatiediagnose voor meer informatie.

Dit artikel heeft geen betrekking op het brede scala aan aanbevelingen voor databaseoptimalisatie in de volledige set mogelijke onderliggende bronnen. De volgende standaarddatabaseprocedures zijn van toepassing op de meeste situaties:

• Voor betere prestaties baseert u relaties op kolommen met gehele getallen in plaats van kolommen van andere gegevenstypen samen te voegen.

• Maak de juiste indexen. Het maken van een index betekent over het algemeen het gebruik van kolomopslagindexen in bronnen die deze ondersteunen, bijvoorbeeld SQL Server.

• Werk alle benodigde statistieken in de bron bij.

Modelontwerp

Wanneer u het model definieert, volgt u deze richtlijnen:

• Vermijd complexe query's in Power Query-editor. Power Query-editor vertaalt een complexe query in één SQL-query. De ene query wordt weergegeven in de subselectie van elke query die naar die tabel wordt verzonden. Als deze query complex is, kan dit leiden tot prestatieproblemen voor elke verzonden query. U kunt de werkelijke SQL-query voor een reeks stappen ophalen door met de rechtermuisknop te klikken op de laatste stap onder Toegepaste stappen in Power Query-editor en systeemeigen query weergeven te kiezen.

• Houd metingen eenvoudig. Beperk in eerste instantie metingen tot eenvoudige aggregaties. Als de metingen op een bevredigende manier werken, kunt u complexere metingen definiëren, maar let op prestaties.

• Vermijd relaties voor berekende kolommen. In databases waarvoor u joins met meerdere kolommen moet uitvoeren, staat Power BI geen relaties toe op meerdere kolommen als primaire sleutel of refererende sleutel. De algemene tijdelijke oplossing is het samenvoegen van de kolommen met behulp van een berekende kolom en het baseren van de join op die kolom.

  Deze tijdelijke oplossing is redelijk voor geïmporteerde gegevens, maar voor DirectQuery resulteert dit in een join in een expressie. Dit resultaat voorkomt meestal het gebruik van indexen en leidt tot slechte prestaties. De enige tijdelijke oplossing is om de meerdere kolommen daadwerkelijk te materialiseren in één kolom in de onderliggende gegevensbron.

• Vermijd relaties in 'uniqueidentifier'-kolommen. Power BI biedt geen systeemeigen ondersteuning voor een uniqueidentifier gegevenstype. Het definiëren van een relatie tussen uniqueidentifier kolommen resulteert in een query met een join waarbij een cast is betrokken. Deze aanpak leidt vaak tot slechte prestaties. De enige tijdelijke oplossing is het materialiseren van kolommen van een alternatief type in de onderliggende gegevensbron.

• Verberg de kolom 'aan' voor relaties. De to kolom met relaties is meestal de primaire sleutel in de to tabel. Deze kolom moet worden verborgen, maar als deze verborgen is, wordt deze niet weergegeven in de lijst met velden en kan deze niet worden gebruikt in visuals. Vaak zijn de kolommen waarop relaties zijn gebaseerd eigenlijk systeemkolommen, bijvoorbeeld surrogaatsleutels in een datawarehouse. Het is nog steeds het beste om dergelijke kolommen te verbergen.

  Als de kolom betekenis heeft, introduceert u een berekende kolom die zichtbaar is en die een eenvoudige expressie heeft die gelijk is aan de primaire sleutel, bijvoorbeeld:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Bekijk alle berekende kolommen en wijzigingen in het gegevenstype. U kunt berekende tabellen gebruiken wanneer u DirectQuery gebruikt met samengestelde modellen. Deze mogelijkheden zijn niet noodzakelijkerwijs schadelijk, maar resulteren in query's die expressies bevatten in plaats van eenvoudige verwijzingen naar kolommen. Deze query's kunnen ertoe leiden dat indexen niet worden gebruikt.

• Vermijd kruislings filteren in twee richtingen op relaties. Het gebruik van kruislings filteren in twee richtingen kan leiden tot queryinstructies die niet goed presteren. Zie Kruislings filteren in twee richtingen inschakelen voor DirectQuery in Power BI Desktop of het bidirectionele kruislings filteren in twee richtingen downloaden. De voorbeelden in het document zijn voor SQL Server Analysis Services, maar de fundamentele punten zijn ook van toepassing op Power BI.

• Experimenteer met het instellen van referentiële integriteit aannemen. Met de instelling Referentiële integriteit aannemen voor relaties kunnen query's in plaats OUTER JOIN van instructies worden gebruiktINNER JOIN. Deze richtlijnen verbeteren over het algemeen de prestaties van query's, hoewel deze afhankelijk zijn van de specifieke kenmerken van de gegevensbron.

• Gebruik de relatieve datumfiltering niet in Power Query-editor. Het is mogelijk om relatieve datumfiltering in Power Query-editor te definiëren. U kunt bijvoorbeeld filteren op de rijen waarin de datum zich in de afgelopen 14 dagen bevindt.

  

  Dit filter wordt echter omgezet in een filter op basis van een vaste datum, zoals het tijdstip waarop de query is gemaakt, zoals u kunt zien in de systeemeigen query.

  

  Deze gegevens zijn waarschijnlijk niet wat u wilt. Als u wilt controleren of het filter wordt toegepast op basis van de datum op het moment dat het rapport wordt uitgevoerd, past u het datumfilter in het rapport toe. U kunt een berekende kolom maken die het aantal dagen geleden berekent met behulp van de DAX DATE() functie en die berekende kolom in het filter gebruiken.

Rapportontwerp

Wanneer u een rapport maakt dat gebruikmaakt van een DirectQuery-verbinding, volgt u deze richtlijnen:

• Overweeg het gebruik van opties voor het verminderen van query's: Power BI biedt rapportopties om minder query's te verzenden en om bepaalde interacties uit te schakelen die een slechte ervaring veroorzaken als het lang duurt voordat de resulterende query's worden uitgevoerd. Deze opties zijn van toepassing wanneer u met uw rapport werkt in Power BI Desktop en ook van toepassing wanneer gebruikers het rapport gebruiken in de Power BI-service.

  Als u deze opties wilt openen in Power BI Desktop, gaat u naar Opties voor bestanden>en instellingen> en selecteert u Queryreductie.

  

  Met selecties op het scherm Queryreductie kunt u een knop Toepassen weergeven voor slicers of filterselecties. Er worden geen query's verzonden totdat u de knop Toepassen op het filter of de slicer selecteert. De query's gebruiken vervolgens uw selecties om de gegevens te filteren. Met deze knop kunt u verschillende slicer- en filterselecties maken voordat u deze toepast.

• Pas eerst filters toe: Pas altijd alle toepasselijke filters toe aan het begin van het bouwen van een visual. In plaats van bijvoorbeeld te slepen in TotalSalesAmount en ProductName en vervolgens te filteren op een bepaald jaar, past u het filter toe op Year aan het begin.

  Elke stap van het bouwen van een visual verzendt een query. Hoewel het mogelijk is om een andere wijziging aan te brengen voordat de eerste query is voltooid, blijft deze methode onnodig belast met de onderliggende bron. Het vroeg toepassen van filters maakt deze tussenliggende query's doorgaans goedkoper. Als u filters niet vroeg kunt toepassen, kan dit resulteren in het bereiken van de limiet van één miljoen rijen.

• Beperk het aantal visuals op een pagina: wanneer u een pagina opent of een slicer of filter op paginaniveau wijzigt, worden alle visuals op de pagina vernieuwd. Er is een limiet voor het aantal parallelle query's. Naarmate het aantal visuals toeneemt, worden sommige visuals serieel vernieuwd, waardoor de tijd die nodig is om de pagina te vernieuwen, toeneemt. Daarom kunt u het beste het aantal visuals op één pagina beperken en in plaats daarvan meer eenvoudigere pagina's hebben.

• Overweeg interactie tussen visuals uit te schakelen: visualisaties op een rapportpagina kunnen standaard worden gebruikt om de andere visualisaties op de pagina kruislings te filteren en kruislings te markeren. Als u bijvoorbeeld 1999 selecteert in het cirkeldiagram, wordt het kolomdiagram kruislings gemarkeerd om de verkoop per categorie voor 1999 weer te geven.

  

  Voor kruislings filteren en kruislings markeren in DirectQuery moeten query's worden verzonden naar de onderliggende bron. U moet deze interactie uitschakelen als de tijd die nodig is om te reageren op selecties van gebruikers onredelijk lang is.

  U kunt de instellingen voor het verminderen van query's gebruiken om kruislings markeren in uw rapport of per geval uit te schakelen. Zie Hoe visuals elkaar kruislings filteren in een Power BI-rapport voor meer informatie.

Maximum aantal verbindingen

U kunt het maximum aantal verbindingen instellen dat DirectQuery wordt geopend voor elke onderliggende gegevensbron, waarmee het aantal query's wordt bepaald dat gelijktijdig naar elke gegevensbron wordt verzonden.

DirectQuery opent een standaard maximumaantal van 10 gelijktijdige verbindingen. Als u het maximumaantal voor het huidige bestand in Power BI Desktop wilt wijzigen, gaat u naar Bestandsopties>en instellingenopties> en selecteert u DirectQuery in de sectie Huidig bestand van het linkerdeelvenster.

De instelling is alleen ingeschakeld wanneer er ten minste één DirectQuery-bron in het huidige rapport aanwezig is. De waarde is van toepassing op alle DirectQuery-bronnen en op nieuwe DirectQuery-bronnen die aan dat rapport worden toegevoegd.

Als u het maximum aantal verbindingen per gegevensbron verhoogt, kunt u meer query's verzenden, tot het maximumaantal dat is opgegeven, naar de onderliggende gegevensbron. Deze benadering is handig wanneer veel visuals zich op één pagina bevinden of veel gebruikers tegelijkertijd toegang hebben tot een rapport. Zodra het maximum aantal verbindingen is bereikt, worden verdere query's in de wachtrij geplaatst totdat er een verbinding beschikbaar is. Een hogere limiet resulteert in meer belasting van de onderliggende bron, dus de instelling is niet gegarandeerd om de algehele prestaties te verbeteren.

Zodra u een rapport naar de Power BI-service publiceert, is het maximum aantal gelijktijdige query's ook afhankelijk van vaste limieten die zijn ingesteld voor de doelomgeving waarin het rapport wordt gepubliceerd. Power BI, Power BI Premium en Power BI Report Server leggen verschillende limieten op. De onderstaande tabel bevat de bovengrens van de actieve verbindingen per gegevensbron voor elke Power BI-omgeving. Deze limieten gelden voor cloudgegevensbronnen en on-premises gegevensbronnen, zoals SQL Server, Oracle en Teradata.

Omgeving	Bovengrens per gegevensbron
Power BI Pro	10 actieve verbindingen
Power BI Premium	Afhankelijk van Semantische model-SKU-beperking
Power BI Report Server	10 actieve verbindingen

Notitie

Het maximum aantal DirectQuery-verbindingen is van toepassing op alle DirectQuery-bronnen wanneer u verbeterde metagegevens inschakelt. Dit is de standaardinstelling voor alle modellen die zijn gemaakt in Power BI Desktop.

DirectQuery in de Power BI-service

Alle DirectQuery-gegevensbronnen worden ondersteund vanuit Power BI Desktop en sommige bronnen zijn ook rechtstreeks vanuit de Power BI-service beschikbaar. Een zakelijke gebruiker kan Power BI gebruiken om verbinding te maken met hun gegevens in Salesforce, bijvoorbeeld en direct een dashboard te krijgen zonder Power BI Desktop te gebruiken.

Alleen de volgende twee DirectQuery-bronnen zijn rechtstreeks beschikbaar in de Power BI-service:

• Spark
• Azure Synapse Analytics (voorheen Azure SQL Data Warehouse)

Zelfs voor deze twee bronnen is het nog steeds het beste om DirectQuery-gebruik in Power BI Desktop te starten. Hoewel het in eerste instantie eenvoudig is om de verbinding in de Power BI-service te maken, zijn er beperkingen voor het verder verbeteren van het resulterende rapport. In de service is het bijvoorbeeld niet mogelijk om berekeningen te maken of veel analytische functies te gebruiken of de metagegevens te vernieuwen om wijzigingen in het onderliggende schema weer te geven.

De prestaties van een DirectQuery-rapport in de Power BI-service zijn afhankelijk van de mate van belasting van de onderliggende gegevensbron. De belasting is afhankelijk van:

• Het aantal gebruikers dat het rapport en dashboard deelt.
• De complexiteit van het rapport.
• Of het rapport beveiliging op rijniveau definieert.

Gedrag van rapporten in de Power BI-service

Wanneer u een rapport opent in de Power BI-service, worden alle visuals op de momenteel zichtbare pagina vernieuwd. Voor elke visual is ten minste één query vereist voor de onderliggende gegevensbron. Voor sommige visuals is mogelijk meer dan één query vereist. Een visual kan bijvoorbeeld geaggregeerde waarden uit twee verschillende feitentabellen weergeven of een complexere meting bevatten, of totalen van een niet-additieve meting bevatten, zoals Count Distinct. Als u naar een nieuwe pagina gaat, worden deze visuals vernieuwd. Vernieuwen verzendt een nieuwe set query's naar de onderliggende bron.

Elke interactie van gebruikers in het rapport kan ertoe leiden dat visuals worden vernieuwd. Als u bijvoorbeeld een andere waarde op een slicer selecteert, moet u een nieuwe set query's verzenden om alle betrokken visuals te vernieuwen. Hetzelfde geldt voor het selecteren van een visual om andere visuals kruislings te markeren of een filter te wijzigen. Op dezelfde manier moeten query's worden verzonden voor elke stap op het pad om de uiteindelijke visual te produceren.

Er is een aantal caches van resultaten. Het vernieuwen van een visual is onmiddellijk als precies dezelfde resultaten zijn verkregen. Als beveiliging op rijniveau is gedefinieerd, worden deze caches niet gedeeld tussen gebruikers.

Het gebruik van DirectQuery legt enkele belangrijke beperkingen op in sommige van de mogelijkheden die de Power BI-service biedt voor gepubliceerde rapporten:

• Snelle inzichten worden niet ondersteund: Snelle inzichten in Power BI doorzoeken verschillende subsets van uw semantische model terwijl u een set geavanceerde algoritmen toepast om potentieel interessante inzichten te ontdekken. Omdat snelle inzichten query's met hoge prestaties vereisen, is deze functie niet beschikbaar op semantische modellen die DirectQuery gebruiken.

• Het gebruik van Verkennen in Excel resulteert in slechte prestaties: u kunt een semantisch model verkennen met behulp van de functie Verkennen in Excel , waarmee u draaitabellen en draaigrafieken in Excel kunt maken. Deze mogelijkheid wordt ondersteund voor semantische modellen die DirectQuery gebruiken, maar de prestaties zijn langzamer dan het maken van visuals in Power BI. Als het gebruik van Excel belangrijk is voor uw scenario's, moet u rekening houden met dit probleem bij het bepalen of u DirectQuery wilt gebruiken.

• In Excel worden geen hiërarchieën weergegeven: wanneer u bijvoorbeeld Analyseren in Excel gebruikt, worden in Excel geen hiërarchieën weergegeven die zijn gedefinieerd in Azure Analysis Services-modellen of semantische Power BI-modellen die DirectQuery gebruiken.

Dashboard vernieuwen

In de Power BI-service kunt u afzonderlijke visuals of hele pagina's als tegels vastmaken aan dashboards. Tegels die zijn gebaseerd op semantische DirectQuery-modellen worden automatisch vernieuwd door query's te verzenden naar de onderliggende gegevensbronnen volgens een schema. Standaard worden semantische modellen elk uur vernieuwd, maar u kunt de vernieuwingsschema-intervallen tussen wekelijks en elke 15 minuten configureren als onderdeel van de instellingen voor het semantische model.

Als er geen beveiliging op rijniveau is gedefinieerd in het model, wordt elke tegel eenmaal vernieuwd en worden de resultaten gedeeld door alle gebruikers. Als u beveiliging op rijniveau gebruikt, moeten voor elke tegel afzonderlijke query's per gebruiker worden verzonden naar de onderliggende bron.

Er kan een groot vermenigvuldigingseffect zijn. Een dashboard met 10 tegels, gedeeld met 100 gebruikers, gemaakt op een semantisch model met DirectQuery met beveiliging op rijniveau, resulteert in ten minste 1000 query's die voor elke vernieuwing naar de onderliggende gegevensbron worden verzonden. Overweeg zorgvuldig het gebruik van beveiliging op rijniveau en de configuratie van het vernieuwingsschema.

Time-outs voor query’s

Een time-out van vier minuten is van toepassing op afzonderlijke query's in de Power BI-service. Query's die langer dan vier minuten duren, mislukken. Deze limiet is bedoeld om problemen te voorkomen die worden veroorzaakt door te lange uitvoeringstijden. U moet DirectQuery alleen gebruiken voor bronnen die interactieve queryprestaties kunnen bieden.

Diagnostische gegevens over prestaties

In deze sectie wordt beschreven hoe u prestatieproblemen kunt diagnosticeren of hoe u gedetailleerdere informatie krijgt om uw rapporten te optimaliseren.

Begin met het diagnosticeren van prestatieproblemen in Power BI Desktop, in plaats van in de Power BI-service. Prestatieproblemen zijn vaak gebaseerd op de prestaties van de onderliggende bron. U kunt problemen gemakkelijker identificeren en diagnosticeren in de meer geïsoleerde Power BI Desktop-omgeving.

Deze benadering elimineert in eerste instantie bepaalde onderdelen, zoals de Power BI-gateway. Als de prestatieproblemen niet optreden in Power BI Desktop, kunt u de details van het rapport in de Power BI-service onderzoeken.

De Power BI Desktop Performance Analyzer is een handig hulpmiddel voor het identificeren van problemen. Probeer eventuele problemen te isoleren voor één visual, in plaats van veel visuals op een pagina. Als één visual op een Power BI Desktop-pagina traag is, gebruikt u Performance Analyzer om de query's te analyseren die Door Power BI Desktop naar de onderliggende bron worden verzonden.

U kunt ook traceringen en diagnostische gegevens weergeven die door sommige onderliggende gegevensbronnen worden verzonden. Zelfs als er geen traceringen van de bron zijn, kan het traceringsbestand nuttige details bevatten over hoe een query wordt uitgevoerd en hoe u dit kunt verbeteren. U kunt het volgende proces gebruiken om de query's weer te geven die door Power BI worden verzonden en hun uitvoeringstijden.

SQL Server Profiler gebruiken om query's te bekijken

Standaard registreert Power BI Desktop gebeurtenissen tijdens een bepaalde sessie naar een traceringsbestand met de naam FlightRecorderCurrent.trc. Het traceringsbestand bevindt zich in de power BI Desktop-map voor de huidige gebruiker, in een map met de naam AnalysisServicesWorkspaces.

Voor sommige DirectQuery-bronnen bevat dit traceringsbestand alle query's die naar de onderliggende gegevensbron worden verzonden. De volgende gegevensbronnen verzenden query's naar het logboek:

• SQL Server
• Azure SQL Database
• Azure Synapse Analytics (voorheen Azure SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

U kunt de traceringsbestanden lezen met behulp van de SQL Server Profiler, onderdeel van de gratis download van SQL Server Management Studio.

Het traceringsbestand voor de huidige sessie openen:

1. Selecteer tijdens een Power BI Desktop-sessie bestandsopties>en instellingenopties> en selecteer vervolgens Diagnostische gegevens.

2. Selecteer onder CrashDumpverzameling de map Crashdumps/traceringen openen.

   

   De map Power BI Desktop\Traces wordt geopend.

3. Navigeer naar de bovenliggende map en vervolgens naar de map AnalysisServicesWorkspaces , die één werkruimtemap bevat voor elk geopend exemplaar van Power BI Desktop. Deze mappen hebben een naam met een achtervoegsel voor een geheel getal, zoals AnalysisServicesWorkspace2058279583. De werkruimtemap wordt verwijderd wanneer de bijbehorende Power BI Desktop-sessie wordt beëindigd.

   In de werkruimtemap voor de huidige Power BI-sessie bevat de map \Data het traceringsbestand FlightRecorderCurrent.trc . Noteer de locatie.

4. Open SQL Server Profiler en selecteer File>Open>Trace File.

5. Navigeer naar of voer het pad naar het traceringsbestand voor de huidige Power BI-sessie in en open FlightRecorderCurrent.trc.

SQL Server Profiler geeft alle gebeurtenissen uit de huidige sessie weer. In de volgende schermopname ziet u een groep gebeurtenissen voor een query. Elke querygroep heeft de volgende gebeurtenissen:

• A Query Begin en Query End gebeurtenis, die het begin en einde van een DAX-query vertegenwoordigen die worden gegenereerd door een visual of filter in de Power BI-gebruikersinterface te wijzigen, of gegevens te filteren of transformeren in de Power Query-editor.

• Een of meer paren DirectQuery Begin en DirectQuery End gebeurtenissen, die query's vertegenwoordigen die naar de onderliggende gegevensbron worden verzonden als onderdeel van het evalueren van de DAX-query.

Meerdere DAX-query's kunnen parallel worden uitgevoerd, zodat gebeurtenissen uit verschillende groepen kunnen worden ge interleaved. U kunt de ActivityID waarde gebruiken om te bepalen welke gebeurtenissen deel uitmaken van dezelfde groep.

De volgende kolommen zijn ook van belang:

• TextData: de tekstdetails van de gebeurtenis. Voor Query Begin en Query End gebeurtenissen is de details de DAX-query. Voor DirectQuery Begin en DirectQuery End gebeurtenissen is de details de SQL-query die naar de onderliggende bron wordt verzonden. De TextData voor de geselecteerde gebeurtenis wordt ook weergegeven in het deelvenster onder aan het scherm.
• EndTime: het tijdstip waarop de gebeurtenis is voltooid.
• Duur: De duur, in milliseconden, duurde om de DAX- of SQL-query uit te voeren.
• Fout: Of er een fout is opgetreden, in welk geval de gebeurtenis ook rood wordt weergegeven.

Een trace vastleggen om een mogelijk prestatieprobleem vast te stellen:

1. Open één Power BI Desktop-sessie om verwarring in meerdere werkruimtemappen te voorkomen.

2. Voer de reeks acties uit die van belang zijn in Power BI Desktop. Voeg nog enkele acties toe om ervoor te zorgen dat de interessante gebeurtenissen in het traceringsbestand worden leeggemaakt.

3. Open SQL Server Profiler en bekijk de tracering. Houd er rekening mee dat als u Power BI Desktop sluit, het traceringsbestand wordt verwijderd. Ook worden verdere acties in Power BI Desktop niet onmiddellijk weergegeven. U moet het traceringsbestand sluiten en opnieuw openen om nieuwe gebeurtenissen te kunnen zien.

Houd afzonderlijke sessies redelijk klein, misschien 10 seconden aan acties, niet honderden. Deze methode maakt het gemakkelijker om het traceringsbestand te interpreteren. Er is ook een limiet voor de grootte van het traceringsbestand. Voor lange sessies is de kans groot dat vroege gebeurtenissen worden verwijderd.

Inzicht in de indeling van query's

De algemene indeling van Power BI Desktop-query's maakt gebruik van subselecties voor elke tabel waarnaar ze verwijzen. De Power Query-editor query definieert de subselectiequery's. Stel dat u de volgende TPC-DS-tabellen in SQL Server hebt:

Voer de volgende query uit:

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

Resultaten in de volgende visual in Power BI:

Als u deze visual vernieuwt, wordt de SQL-query in de volgende afbeelding gegenereerd. Er zijn drie subselectiequery's voor Web_Sales, Itemen Date_dim, die elk alle kolommen in de desbetreffende tabel retourneren, ook al verwijst de visual slechts naar vier kolommen.

Power Query-editor definieert de exacte subselectiequery's. Dit gebruik van subselectiequery's is niet getoond om de prestaties voor de DirectQuery-gegevensbronnen te beïnvloeden. Gegevensbronnen zoals SQL Server optimaliseren de verwijzingen naar de andere kolommen.

Power BI gebruikt dit patroon omdat de analist de SQL-query rechtstreeks levert. Power BI gebruikt de query zoals opgegeven, zonder dat u deze opnieuw wilt schrijven.

Gerelateerde inhoud

Zie voor meer informatie over DirectQuery in Power BI:

• DirectQuery gebruiken in Power BI Desktop

In dit artikel worden aspecten van DirectQuery beschreven die gebruikelijk zijn in alle gegevensbronnen. Zie de volgende artikelen voor meer informatie over specifieke bronnen:

• DirectQuery en SAP HANA
• DirectQuery en SAP BW
• DirectQuery gebruiken voor semantische Power BI-modellen en Analysis Services