Optimalisatiehandleiding voor Power BI

Dit artikel bevat richtlijnen waarmee ontwikkelaars en beheerders geoptimaliseerde Power BI-oplossingen kunnen produceren en onderhouden. U kunt uw oplossing optimaliseren op verschillende architectuurlagen. Lagen zijn onder andere:

  • De gegevensbron(en)
  • Het gegevensmodel
  • Visualisaties, waaronder dashboards, Power BI-rapporten en gepagineerde Power BI-rapporten
  • De omgeving, inclusief capaciteiten, gegevensgateways en het netwerk

Het gegevensmodel optimaliseren

Het gegevensmodel ondersteunt de volledige visualisatie-ervaring. Gegevensmodellen worden gehost in het Power BI-ecosysteem of extern (met behulp van DirectQuery of Live Verbinding maken ion) en in Power BI worden ze aangeduid als semantische modellen, voorheen gegevenssets genoemd. Het is belangrijk om inzicht te hebben in uw opties en om het juiste semantische modeltype voor uw oplossing te kiezen. Er zijn drie semantische modelmodi: Importeren, DirectQuery en Samengesteld. Zie Semantische modellen in de Power BI-service en Semantische modelmodi in de Power BI-service voor meer informatie.

Zie voor specifieke richtlijnen voor de semantische modelmodus:

Visualisaties optimaliseren

Power BI-visualisaties kunnen dashboards, Power BI-rapporten of gepagineerde Power BI-rapporten zijn. Elk heeft verschillende architecturen, dus elk heeft zijn eigen richtlijnen.

Dashboards

Het is belangrijk om te begrijpen dat Power BI een cache voor uw dashboardtegels onderhoudt, met uitzondering van liverapporttegels en streamingtegels. Als uw semantische model dynamische beveiliging op rijniveau (RLS) afdwingt, moet u de gevolgen voor de prestaties begrijpen, omdat tegels per gebruiker worden opgeslagen in de cache.

Wanneer u liverapporttegels vastmaakt aan een dashboard, worden deze niet geleverd vanuit de querycache. In plaats daarvan gedragen ze zich als rapporten en maken ze query's naar v-cores.

Zoals de naam al aangeeft, biedt het ophalen van de gegevens uit de cache betere en consistentere prestaties dan het vertrouwen op de gegevensbron. Een manier om te profiteren van deze functionaliteit is door dashboards te gebruiken als de eerste landingspagina voor uw gebruikers. Vaak gebruikte en zeer aangevraagde visuals vastmaken aan de dashboards. Op deze manier worden dashboards een waardevolle 'eerste verdedigingslinie', die consistente prestaties levert met minder belasting van de capaciteit. Gebruikers kunnen nog steeds doorklikken naar een rapport om details te analyseren.

Voor semantische directQuery- en liveverbindingen wordt de cache periodiek bijgewerkt door een query uit te voeren op de gegevensbron. Dit gebeurt standaard elk uur, maar u kunt een andere frequentie configureren in de semantische modelinstellingen. Elke cache-update verzendt query's naar de onderliggende gegevensbron om de cache bij te werken. Het aantal query's dat wordt gegenereerd, is afhankelijk van het aantal visuals dat is vastgemaakt aan dashboards die afhankelijk zijn van de gegevensbron. Als beveiliging op rijniveau is ingeschakeld, worden query's gegenereerd voor elke verschillende beveiligingscontext. Denk bijvoorbeeld aan twee verschillende rollen die uw gebruikers categoriseren en ze hebben twee verschillende weergaven van de gegevens. Tijdens het vernieuwen van de querycache worden in Power BI twee sets query's gegenereerd.

Power BI-rapporten

Er zijn verschillende aanbevelingen voor het optimaliseren van Power BI-rapportontwerpen.

Notitie

Wanneer rapporten zijn gebaseerd op een semantisch DirectQuery-model, raadpleegt u de richtlijnen voor DirectQuery-modellen in Power BI Desktop (rapportontwerpen optimaliseren) voor aanvullende ontwerpoptimalisaties voor rapporten.

De meest beperkende filters toepassen

Hoe meer gegevens een visual moet weergeven, hoe langzamer deze visual moet worden geladen. Hoewel dit principe duidelijk lijkt, is het gemakkelijk om te vergeten. Stel dat u een groot semantisch model hebt. Op basis van dat semantische model maakt u een rapport met een tabel. Eindgebruikers gebruiken slicers op de pagina om de gewenste rijen te bereiken, meestal zijn ze slechts geïnteresseerd in enkele tientallen rijen.

Een veelvoorkomende fout is om de standaardweergave van de tabel ongefilterd te laten, dat wil gezegd, alle 100M+ rijen. De gegevens voor deze rijen worden in het geheugen geladen en worden bij elke vernieuwing niet gecomprimeerd. Deze verwerking zorgt voor enorme vraag naar geheugen. De oplossing: gebruik het filter Top N om het maximum aantal items te verminderen dat in de tabel wordt weergegeven. U kunt het maximum aantal items instellen op groter dan wat gebruikers nodig hebben, bijvoorbeeld 10.000. Het resultaat is dat de eindgebruikerservaring niet verandert, maar het geheugengebruik daalt aanzienlijk. En het belangrijkste is dat de prestaties verbeteren.

Een vergelijkbare ontwerpbenadering als hierboven wordt voorgesteld voor elke visual in uw rapport. Vraag het uzelf af, zijn alle gegevens in deze visual nodig? Zijn er manieren om de hoeveelheid gegevens in de visual te filteren met minimale gevolgen voor de eindgebruikerservaring? Vergeet niet dat tabellen in het bijzonder duur kunnen zijn.

Visuals op rapportpagina's beperken

Het bovenstaande principe is evenzeer van toepassing op het aantal visuals dat is toegevoegd aan een rapportpagina. Het wordt ten zeerste aanbevolen om het aantal visuals op een bepaalde rapportpagina te beperken tot alleen wat nodig is. Drillthrough-pagina's en knopinfo voor rapportpagina's zijn uitstekende manieren om extra details te bieden zonder dat er meer visuals op de pagina worden vastgelopen.

Aangepaste visuele prestaties evalueren

Zorg ervoor dat u elke aangepaste visual in zijn tempo plaatst om hoge prestaties te garanderen. Slecht geoptimaliseerde Power BI-visuals kunnen de prestaties van het hele rapport negatief beïnvloeden.

Gepagineerde Power BI-rapporten

Gepagineerde power BI-rapportontwerpen kunnen worden geoptimaliseerd door het best practice-ontwerp toe te passen op het ophalen van gegevens van het rapport. Zie richtlijnen voor het ophalen van gegevens voor gepagineerde rapporten voor meer informatie.

Zorg er ook voor dat uw capaciteit voldoende geheugen heeft toegewezen aan de workload voor gepagineerde rapporten.

De omgeving optimaliseren

U kunt de Power BI-omgeving optimaliseren door capaciteitsinstellingen te configureren, de grootte van gegevensgateways te wijzigen en de netwerklatentie te verminderen.

Capaciteitsinstellingen

Wanneer u capaciteiten gebruikt( beschikbaar met Power BI Premium (P-SKU's), PPU-licenties (Premium Per User) of Power BI Embedded (A SKU's, A4-A6)), kunt u capaciteitsinstellingen beheren. Raadpleeg Premium-capaciteiten beheren voor meer informatie.

Grootte van gateway

Een gateway is vereist wanneer Power BI toegang moet hebben tot gegevens die niet rechtstreeks via internet toegankelijk zijn. U kunt de on-premises gegevensgateway op een on-premises server of iaaS (Infrastructure-as-a-Service) installeren op een on-premises server.

Zie De grootte van de on-premises gegevensgateway voor meer informatie over gatewayworkloads en aanbevelingen voor de grootte van de grootte.

Netwerklatentie

Netwerklatentie kan van invloed zijn op de rapportprestaties door de tijd te verhogen die nodig is voor aanvragen om de Power BI-service te bereiken en om reacties te leveren. Tenants in Power BI worden toegewezen aan een specifieke regio.

Tip

Als u wilt bepalen waar uw tenant zich bevindt, raadpleegt u Waar bevindt mijn Power BI-tenant zich?

Wanneer gebruikers van een tenant toegang hebben tot de Power BI-service, worden hun aanvragen altijd doorgestuurd naar deze regio. Wanneer aanvragen de Power BI-service bereiken, kan de service vervolgens aanvullende aanvragen verzenden, bijvoorbeeld naar de onderliggende gegevensbron of een gegevensgateway, die ook onderhevig zijn aan netwerklatentie.

Hulpprogramma's zoals Azure Speed Test bieden een indicatie van netwerklatentie tussen de client en de Azure-regio. Om de impact van netwerklatentie te minimaliseren, streeft u ernaar om gegevensbronnen, gateways en uw Power BI-capaciteit zo dicht mogelijk bij elkaar te houden. Bij voorkeur bevinden ze zich binnen dezelfde regio. Als netwerklatentie een probleem is, kunt u gateways en gegevensbronnen dichter bij uw Power BI-capaciteit zoeken door ze in de cloud gehoste virtuele machines te plaatsen.

Prestaties bewaken

U kunt de prestaties bewaken om knelpunten te identificeren. Trage query's (of rapportvisuals) moeten een centraal punt van continue optimalisatie zijn. Bewaking kan worden uitgevoerd tijdens het ontwerpen in Power BI Desktop of op productieworkloads in Power BI Premium-capaciteiten. Zie Rapportprestaties bewaken in Power BI voor meer informatie.

Raadpleeg de volgende bronnen voor meer informatie over dit artikel: