De blogpost van vandaag is gewijd aan Power BI, de robuuste bedrijfsanalysedienst van Microsoft. In het bijzonder beschrijven we de impact die geplande vernieuwingen van gegevens kunnen hebben op de ontwikkeling van rapporten. Laten we beginnen!

macht bi

Bij het initiëren van een Power BI-project - ongeacht de grootte en complexiteit ervan - stellen we altijd dezelfde startvragen. De antwoorden op deze drie belangrijke vragen helpen ons inzicht te krijgen in de projectvereisten. De vragen zijn:

  1. Wat is de gegevensbron (nen)? Dit geeft ons duidelijkheid in termen van online versus on-premises, applicatie (s), database (s), datamodellen, datavolume, etc.
  2. Hoe zien de rapporten eruit? Dit helpt ons de soorten visuals, pagina-indeling, navigatie, datamodellering, berekeningen, RLS, etc. te begrijpen.
  3. Waar zullen gebruikers de rapporten bekijken? We moeten weten of het Power BI-service, Dynamics 365, Portals, 3rd party-applicaties, websites, SharePoint, PowerApps, mobiele apps, enz. Zijn.

Dit deel van de discussie is vanuit het perspectief van de ontwikkelaar, hoewel management en klanten over het algemeen geïnteresseerd zijn in de bedrijfskosten en onderhoudskosten in verband met het uitvoeren van Power BI-rapporten. Op deze manier worden licenties vaak een groot deel van de discussie.

Eindgebruikers zijn altijd enthousiast over de dynamische en interactieve Power BI-visualisaties voor hun activiteiten en zakelijke besluitvorming. Als de prestaties van rapporten echter slecht zijn, wordt de gebruikerservaring snel zuur, wat leidt tot mislukte gebruikersacceptatie.

De sleutels tot het succes van Power BI-projecten zijn fundamenteel:

  • Goedkoop
  • high performance

De uitdaging is om een ​​balans te vinden tussen Low Cost en High Performance. Het vinden van die balans is van cruciaal belang, en toch is er een belangrijk en vaak vergeten probleem dat van tevoren moet worden aangepakt: Gegevensvernieuwing.

Gegevens vernieuwen wordt vaak later in projecten besproken, maar idealiter wordt het al vroeg geconfronteerd, dus alle partijen hebben een goed begrip van het onderwerp. Een snel overzicht:

Power BI heeft twee verschillende gegevensvernieuwingen: Power BI desktop verversen en Power BI Service vernieuwen. Het doel van de vernieuwing is hetzelfde tussen Power BI Desktop en Power BI Service. Er is echter een heel belangrijk element van de vernieuwing dat we moeten begrijpen: "Pbix" beperking van bestandsgrootte. Dit wordt toegepast wanneer we pbix-bestanden publiceren van Power BI Desktop naar Power BI Service en wanneer we een geplande gegevensvernieuwing instellen.

Waarom is het belangrijk? Omdat de beperking van de pbix-bestandsgrootte van invloed kan zijn op het ontwerp van het gegevensmodel, de prestaties en de kosten - tenzij het tijdens de projectontdekkingsfase nauwkeurig wordt besproken en beoordeeld. Het worst-case scenario is dat Power BI-rapporten gereed zijn voor productie, maar deze niet kunnen gebruiken omdat de gegevensvernieuwing niet kon worden voltooid in Power BI-service vanwege beperkingen in de bestandsgrootte.

Aangezien Power BI Desktop geen bestandsbeperking voor pbix heeft, is het eenvoudig en relatief gebruikelijk om aan te nemen dat Power BI Service dat ook niet is. Maar nu weten we het!

Let op: de beperking van de bestandsgrootte waarnaar we verwijzen is geen filet Opslagruimte groottebeperking in Power BI Service Workspaces.

Hier moeten we Power BI-licenties bespreken om de kosten te vinden die verband houden met de beperking van de bestandsgrootte voor het vernieuwen van gegevens. Waarom? Omdat het aantal gebruikers de licentiekosten bepaalt en tegelijkertijd de beperking van de pbix-bestandsgrootte van invloed is op de kosten.

In de ontdekkingsfase zouden we het geschatte aantal gebruikers al moeten kennen. Bovendien moeten we meten eerste pbix bestandsgrootte en schatting incrementele datum volume voor de toekomst bij het selecteren van licenties. De onderstaande tabel geeft een schatting van de kosten per licentietype en per bestandsgrootte-beperking voor pbix voor het vernieuwen van gegevens.

cid:2ea298a6-77c1-48ec-8898-040c44799c3d

Merk op dat de beperking van de pbix-bestandsgrootte is geen toegepast op de grootte van elk pbix-bestand, maar is eerder een som van pbix-bestandsgrootte per licentie. Als we bijvoorbeeld 3 pbix-bestanden voor een project hebben en de som van de 3 pbix-bestanden 600 MB (minder dan 1GB) is, is de Pro-licentie van toepassing.

De bestandsgrootte van pbix is ​​afhankelijk van het gegevensvolume in de gegevensbron, het aantal gegevenssets en visuals in Power BI en meer. Laten we twee voorbeelden bekijken die illustreren hoe licenties kunnen worden gekozen op basis van datavolume en pbix-bestandsgrootte.

1. pbix Bestandsgrootte: 250 MB

  • Gegevensset A: 600,000 rijen met 30 kolommen
  • Gegevensset B: 4.2 miljoen rijen met 3-kolommen
  • Totaal aantal rijen: 4.8 miljoen en 33 kolommen
  • Gegevens vernieuwen in Power BI-service: ~ 30 minuten
  • Gegevensbron: Dynamics 365 Online Web API v9.0
  • Licentie: Pro-licentie (gedeelde capaciteit)

Criteria: Pro-licentie geselecteerd

  • Een klein aantal gebruikers: 50
  • De initiële bestandsgrootte van pbix is ​​kleiner dan of gelijk aan 25% van 1 GB beperking
  • Vernieuw de tijd in Power BI Service: 30 minuten - binnen 1 uur

2. pbix Bestandsgrootte: 1.25 GB

  • Gegevensset A: 13 miljoen rijen met 80-kolommen
  • Gegevensset B: 100 miljoen rijen met 15-kolommen
  • Totaal aantal rijen: 113 miljoen en 95 kolommen
  • Gegevens vernieuwen in Power BI-service: ~ 50 minuten
  • Gegevensbron: SQL Database on-premises met Data Gateway
  • Licentie: Premium (P1-capaciteit)

Criteria: Premium-licentie P1 geselecteerd

  • Aantal gebruikers dat schaalbaar is van 300 - 1,000
  • De initiële bestandsgrootte van pbix is ​​groter dan de beperking van 1 GB
  • Vernieuw de tijd in Power BI Service: ~ 50 minuten en zal naar verwachting meer dan een uur overschrijden vanwege toename van het datavolume

Er is nog een element om te overwegen als het gaat om het vernieuwen van gegevens, zoals beschreven in de bovenstaande lijst: het is een tijdvenster om het vernieuwen te voltooien. Terwijl de gegevens worden vernieuwd in Power BI Service, is een sessie geopend en verloopt de sessie in één uur voor Pro-licentie en in 4-uren voor Premium-licentie. Daarom moeten we rekening houden met de duur van de vernieuwingstijd en met de bestandsbeperking voor pbix. De duur van de vernieuwingstijd is gekoppeld aan de bestandsgrootte van pbix en kan worden verbeterd door gegevensmodellering in Power BI, netwerkomgeving, gegevensbronverbinding, gateway-configuratie, enz.

De vraag die we ons moeten stellen is hoe we dat kunnen verminder de grootte van pbix-bestanden bij het ontwerpen van Power BI-rapporten. We kunnen de gegevensverbinding wijzigen van de importmodus naar de DirectQuery-modus zodat de bestandsgrootte aanzienlijk wordt verkleind. Er zijn echter enkele nadelen. De prestaties worden beïnvloed wanneer het gaat om een ​​grote reeks records, bijvoorbeeld 12 miljoen records in een gegevensset. Een trage prestatie verschijnt duidelijk bij het filteren en markeren van gegevens in kaartvisuals met DirectQuery-modus. De importmodus biedt gebruikers een geweldige filterervaring met 3 - 5 seconden per klik. In ons projectvoorbeeld hebben we 10 - 30 seconden responsen ervaren, afhankelijk van de grafieken met DirectQuery, waardoor het gevoel van dynamische gebruikerservaringen afnam. Er is een optie om aggregatietabellen te maken en de prestaties en bestandsgrootte in evenwicht te houden. In ons voorbeeld werkte het goed; maar toen we drilldown-gegevens nodig hadden, hadden we hetzelfde prestatieprobleem met de DirectQuery-modus. Om de beste prestaties te behouden, is de importmodus een beste optie en hebben we aggregatietabellen / transactietabellen / -weergaven in SQL-database gemaakt en gebruikt als gegevensbronnen. Het verkleinde de bestandsgrootte niet in vergelijking met de DirectQuery-modus, maar behield wel de prestaties en geweldige gebruikerservaringen.

De resterende uitdaging is dat als we de importmodus kiezen voor de beste prestaties, de pbix-bestandsgrootte en de vernieuwingstijd beide toenemen naarmate het gegevensvolume in gegevensbronnen toeneemt. De bestandsgrootte van pbix zou een drempel van de SKU's van de Power BI-licentie bereiken en de lopende kosten in de loop van de tijd verhogen.

De conclusie is dat de bestandsgrootte van pbix ons licentie-opties (kosten) vertelt en de manier bepaalt waarop we gegevensbronnen en gegevensmodellen in Power BI moeten ontwerpen om de bestandsgrootte te minimaliseren en de prestaties van rapporten en gegevens te vernieuwen. De volgende lijst is een snelle verwijzing naar licentie-opties en gegevensverversingsprestaties op basis van pbix-bestandsbeperkingen. Hopelijk wordt deze beperking verbeterd in komende Power BI-releases.

  1. Pbix-bestandsgrootte is kleiner dan 1GB
    • Pro Licentie
    • Ontwerp Power BI-rapporten voor vernieuwing om binnen 1 uur te voltooien
  2. Pbix-bestandsgrootte is groter dan 1GB
    • Premium licentie
    • Ontwerp Power BI-rapporten voor vernieuwing om binnen 4 uur te voltooien

Dat is veel informatie, maar hopelijk hebben we geïllustreerd hoe bestandsgrootte, licenties en verversingstijden allemaal met elkaar samenhangen en moeten worden overwogen bij het plannen van een Power BI-project.

Gelukkig Power BI-ing!

Avatar voor Joe D365

Joe D365

Joe D365 is een Microsoft Dynamics 365 superheld die op pure Dynamics adrenaline draait. Als het gezicht van PowerObjects, is de missie van Joe D365 om innovatieve manieren te onthullen om Dynamics 365 te gebruiken en de toepassing naar meer bedrijven en organisaties over de hele wereld te brengen.