Delen via

Gegevensreductiemethoden voor importmodellen

Dit artikel is bedoeld voor Power BI Desktop-gegevensmodelleerders die semantische Power BI-modellen ontwikkelen en publiceren. In het bijzonder worden verschillende technieken beschreven om de gegevens te verminderen die in importmodellen worden geladen.

Importmodellen worden geladen met gegevens die zijn gecomprimeerd en geoptimaliseerd en vervolgens worden opgeslagen op schijf door de VertiPaq-opslagengine. Wanneer brongegevens in het geheugen worden geladen, is het mogelijk om 10x compressie te bereiken en is het dus redelijk om te verwachten dat 10 GB aan brongegevens kan worden gecomprimeerd tot ongeveer 1 GB in grootte. Verder kan een extra reductie van 20% worden bereikt wanneer deze op schijf wordt bewaard.

Ondanks de efficiëntie die wordt bereikt door de VertiPaq-opslagengine, moet u ernaar streven om de gegevens te minimaliseren die in uw modellen worden geladen. Dat geldt met name voor grote modellen of modellen die u verwacht te groeien in de loop van de tijd. Vier overtuigende redenen zijn onder andere:

  • Grotere modelgrootten worden mogelijk niet ondersteund door uw capaciteit. Gedeelde capaciteit kan modellen van maximaal 1 GB hosten, terwijl Premium-capaciteiten grotere modellen kunnen hosten, afhankelijk van de SKU. Zie Grote semantische modellen in Power BI Premium voor meer informatie.
  • Kleinere modelgrootten verminderen conflicten voor capaciteitsresources, met name geheugen. Veel kleinere modellen binnen een capaciteit kunnen gedurende langere tijd gelijktijdig worden geladen, wat resulteert in lagere verwijderingssnelheden.
  • Kleinere modelgrootten zorgen voor snellere gegevensvernieuwing, wat resulteert in een lagere latentierapportage, een hogere semantische doorvoer voor het vernieuwen van modellen en minder druk op bronsysteem- en capaciteitsresources.
  • Kleinere tabelrijen kunnen leiden tot snellere berekeningsevaluaties, wat resulteert in betere algehele queryprestaties.

Belangrijk

Dit artikel verwijst naar Power BI Premium of de capaciteitsabonnementen (P-SKU's). Momenteel is Microsoft bezig met het consolideren van koopopties en worden de Power BI Premium per-capaciteit SKU's buiten gebruik gesteld. Nieuwe en bestaande klanten moeten overwegen om in plaats daarvan F-SKU's (Fabric-capaciteitsabonnementen) aan te schaffen.

Zie Belangrijke update voor Power BI Premium-licenties en veelgestelde vragen over Power BI Premium voor meer informatie.

Overbodige kolommen verwijderen

Modeltabelkolommen dienen voor twee hoofddoeleinden:

  • Rapportage, om rapportontwerpen te bereiken die modelgegevens op de juiste manier filteren, groeperen en samenvatten.
  • Modelstructuur, door modelrelaties, modelberekeningen, beveiligingsrollen en zelfs gegevenskleuropmaak te ondersteunen.

U kunt waarschijnlijk een kolom verwijderen die geen van deze doeleinden dient. Het verwijderen van een kolom uit een tabel wordt soms ook wel verticaal filteren genoemd.

We raden u aan modellen te ontwerpen met precies het juiste aantal kolommen op basis van uw bekende rapportagevereisten. Uw vereisten kunnen na verloop van tijd veranderen, maar houd er rekening mee dat het gemakkelijker is om later kolommen toe te voegen dan ze later te verwijderen. Als u kolommen verwijdert, kunnen rapporten of de modelstructuur worden verbroken.

Overbodige rijen verwijderen

U moet modeltabellen laden met zo weinig mogelijk rijen. U kunt dit bereiken door gefilterde rijensets in modeltabellen te laden om twee verschillende redenen: filteren op tijd of op entiteit. Het verwijderen van rijen wordt soms ook wel horizontaal filteren genoemd.

  • Filteren op tijd omvat het beperken van de hoeveelheid gegevensgeschiedenis die in feitentabellen is geladen (en het beperken van de datumrijen die in de modeldatumtabellen zijn geladen). U wordt aangeraden niet alle beschikbare geschiedenis standaard te laden, tenzij dit een bekende rapportagevereiste is. U kunt op tijd gebaseerde Power Query-filters implementeren met parameters en ze zelfs instellen voor het gebruik van relatieve tijdsperioden (ten opzichte van de vernieuwingsdatum, bijvoorbeeld de afgelopen vijf jaar). Houd er ook rekening mee dat een terugwerkende wijziging in tijdfilters geen rapporten verbreekt; Dit resulteert alleen in minder (of meer) gegevensgeschiedenis die beschikbaar is in rapporten.
  • Filteren op entiteit omvat het laden van een subset van brongegevens in het model. In plaats van bijvoorbeeld verkoopgegevens voor alle verkoopregio's te laden, laadt u alleen feiten voor één regio. Deze ontwerpbenadering resulteert in veel kleinere modellen en het kan ook voorkomen dat beveiliging op rijniveau (RLS) hoeft te worden gedefinieerd, maar hiervoor moeten specifieke semantische modelmachtigingen worden verleend in de Power BI-service en dubbele rapporten worden gemaakt die verbinding maken met elk semantisch model. U kunt Power Query-parameters en Power BI-sjabloonbestanden gebruiken om het beheer en de publicatie te vereenvoudigen. Zie Rapportsjablonen maken en gebruiken in Power BI Desktop voor meer informatie.

Groeperen op en samenvatten

Misschien is de meest effectieve techniek om een modelgrootte te verminderen het laden van vooraf samengevatte gegevens. U kunt deze techniek gebruiken om de detaillering van feitentabellen te vergroten. Er is echter een duidelijke afweging, wat resulteert in detailverlies.

Bekijk een voorbeeld waarbij in een feitentabel voor de bronverkoop één rij per orderregel wordt opgeslagen. Aanzienlijke gegevensreductie kan worden bereikt door alle metrische verkoopgegevens samen te vatten, te groeperen op datum, klant en product. Een nog significantere gegevensreductie kan worden bereikt door te groeperen op datum op maandniveau. Hoewel het een mogelijke 99% vermindering van de modelgrootte kan bereiken, is rapportage op dagniveau, of op afzonderlijk orderregelniveau, niet meer mogelijk. Besluiten om feitengegevens samen te vatten, hebben altijd betrekking op compromissen. De afweging kan worden verzacht door een modelontwerp met enkele tabellen in de DirectQuery-opslagmodus, die verderop in dit artikel wordt beschreven.

Kolomgegevenstypen optimaliseren

De VertiPaq-opslagengine maakt gebruik van afzonderlijke interne gegevensstructuren voor elke kolom. Deze gegevensstructuren bereiken standaard de hoogste optimalisaties voor numerieke kolomgegevens, die gebruikmaken van waardecodering. Voor tekst en andere niet-numerieke gegevens wordt echter hash-codering gebruikt. Voor hashcodering moet de opslagengine een numerieke id toewijzen aan elke unieke waarde in de kolom. Het is vervolgens de numerieke identificator, die is opgeslagen in de gegevensstructuur, waarvoor een hash-opzoeking vereist is bij opslag en bij het uitvoeren van query's.

In sommige specifieke gevallen kunt u brontekstgegevens converteren naar numerieke waarden. Een verkoopordernummer kan bijvoorbeeld consistent worden voorafgegaan door een tekstwaarde (bijvoorbeeld SO123456). In dit geval kan het voorvoegsel SO worden verwijderd en kan de ordernummerwaarde worden geconverteerd naar een geheel getal. Voor grote tabellen kan deze wijziging leiden tot aanzienlijke gegevensreductie, met name wanneer de kolom unieke of hoge kardinaliteitswaarden bevat.

In dit voorbeeld wordt u aangeraden de standaardsamenvattingseigenschap van de kolom in te stellen op Do Not Summarize. Het helpt ongepaste samenvatting van de ordernummerwaarden te voorkomen.

Voorkeur voor aangepaste kolommen

In de VertiPaq-opslagengine worden modelberekende kolommen (gedefinieerd in DAX) op dezelfde manier opgeslagen als gewone Power Query-bronkolommen. De interne gegevensstructuren worden echter iets anders opgeslagen en bereiken doorgaans minder efficiënte compressie. De gegevensstructuren worden ook gebouwd zodra alle Power Query-tabellen zijn geladen, wat kan leiden tot langere vernieuwingstijden van gegevens. Het is daarom minder efficiënt om tabelkolommen toe te voegen als berekende kolommen dan berekende Power Query-kolommen (gedefinieerd in M).

Geef waar mogelijk de voorkeur aan het maken van aangepaste kolommen in Power Query. Wanneer de bron een database is, kunt u op twee manieren een grotere belastingsefficiëntie bereiken: de berekening kan worden gedefinieerd in de SQL-instructie (met behulp van de systeemeigen querytaal van de provider) of kan worden gerealiseerd als een kolom in de gegevensbron.

In sommige gevallen zijn berekende modelkolommen echter mogelijk de betere keuze. Dat geldt wanneer de formule betrekking heeft op het evalueren van metingen of als er specifieke modelleringsfunctionaliteit is vereist die alleen wordt ondersteund in DAX-functies. Zie Inzicht in functies voor bovenliggende en onderliggende hiërarchieën in DAX voor informatie over een dergelijk voorbeeld.

Power Query-query laden uitschakelen

Power Query-query's die zijn bedoeld ter ondersteuning van gegevensintegratie met andere query's, mogen niet in het model worden geladen. Om te voorkomen dat deze query's in het model worden geladen, moet u ervoor zorgen dat u het laadproces van query's in deze gevallen uitschakelt.

Schermopname van Power Query met de optie Laden inschakelen.

Automatische datum/tijd uitschakelen

Power BI Desktop bevat een optie met de naam Automatische datum/tijd. Wanneer deze optie is ingeschakeld, worden verborgen automatische datum-/tijdtabellen gemaakt voor elke datumkolom in het model. Deze optie ondersteunt rapportauteurs bij het configureren van filters, groepering en inzoomacties voor kalenderperioden. De verborgen tabellen zijn in feite berekende tabellen die de grootte van het model vergroten.

Zie de richtlijnen voor automatische datum/tijd in Power BI Desktop voor meer informatie.

DirectQuery-opslagmodus gebruiken

De DirectQuery-opslagmodus is een alternatief voor de opslagmodus Importeren. DirectQuery-modeltabellen importeren geen gegevens. In plaats daarvan bestaan ze alleen uit metagegevens die de tabelstructuur definiëren. Wanneer de tabel wordt opgevraagd, worden systeemeigen query's gebruikt om gegevens op te halen uit de onderliggende gegevensbron. Wanneer u import- en DirectQuery-opslagmodustabellen in één model combineert, wordt dit een samengesteld model genoemd.

Een effectieve techniek om de modelgrootte te verkleinen, is door de opslagmodus voor grotere feitentabellen in te stellen op DirectQuery. Houd er rekening mee dat deze ontwerpbenadering vaak goed werkt met de Methode Groeperen op en samenvatten die eerder is geïntroduceerd. Samengevatte verkoopgegevens kunnen bijvoorbeeld worden gebruikt om overzichtsrapporten met hoge prestaties te realiseren. Een drillthrough-pagina kan gedetailleerde verkoopgegevens weergeven voor een specifieke en beperkte filtercontext, waarbij alle verkooporders binnen die context worden weergegeven. In dit voorbeeld kan de drillthrough-pagina visuals bevatten gebaseerd op een DirectQuery-modeltabel om de verkoopordergegevens op te halen.

Er zijn echter veel gevolgen voor beveiliging en prestaties met betrekking tot de DirectQuery-opslagmodus en samengestelde modellen. Zie Samengestelde modellen gebruiken in Power BI Desktopvoor meer informatie.

Gerelateerde inhoud

Raadpleeg de volgende artikelen voor meer informatie over dit artikel: