Meer dan rapportages KEMBIT

Transcriptie

1 Meer dan rapportages KEMBIT +31 (0) Kantoor Wijnandsrade Opfergeltstraat 2, 6363 BW Wijnandsrade Kantoor Eindhoven High Tech Campus 41, 5656 AE Eindhoven

2 Inhoudsopgave 1 Inleiding Business Case Stap 1: Behoeften in kaart brengen Stap 2: Architectuur Stap 3: Infrastructuur bepalen Stap 4: Datamodel ontwerpen Stap 5: Datamodel vullen Stap 6: Power BI Stap 7: Ga zelf aan de slag!... 12

3 1 Inleiding Business Case Anderhalf jaar geleden is KEMBIT begonnen met het opzetten van een Business Intelligence (BI) team. Het opzetten van een nieuw team en een voor KEMBIT nieuwe propositie bleek een uitdaging. Het team moest zijn eigen werkwijze ontwikkelen en een goede rolverdeling tussen de teamleden vinden. Eén van de uitdagingen is het voor klanten inzichtelijk krijgen wat het BI-team voor hen kan betekenen, waar de kracht van KEMBIT BI ligt. KEMBIT BI is selfservice BI in een IT managed omgeving. Dit is een omschrijving die wellicht niet meteen tot de verbeelding spreekt. Daarom is gekozen een demo te maken, met gegevens waar veel mensen bekend mee zijn of op z n minst affiniteit mee hebben: Formule 1 data. Een klant kan op basis van bekende gegevens eenvoudiger een rapportagebehoefte definiëren. Met behulp van deze behoefte kunnen we het gemak van selfservice BI demonstreren. De Formule 1 rapportages zijn te vinden op de KEMBIT website: Het is belangrijk om te weten dat de grootste uitdaging niet in de rapportages zit. Het dashboard ziet er weliswaar technisch en ingewikkeld uit, maar deze functionaliteit zit allemaal verweven in de tool Power BI. De grootste uitdaging voor de ontwikkelaars in ons BI-team zit hem in het proces ervoor. Hoe krijgen we de data uit de bronnen op zo n manier gepresenteerd, dat klanten zelf rapporten in elkaar kunnen klikken? Dit proces van het vergaren van gegevens heet Business Intelligence. Dit document beschrijft wat aan bod komt bij Business Intelligence en hoe KEMBIT tot het uiteindelijke resultaat van de Formule 1 rapportages is gekomen. Dit gebeurt onder andere door het in kaart brengen van de rapportagebehoefte, de benodigde bronnen erbij te zoeken en deze te transformeren tot een begrijpelijk model ten behoeve van de rapportages. Een activiteit die niet wordt beschreven in dit document, maar wel essentieel is voor het slagen van een project, is datavalidatie. Deze activiteit gebeurt gedurende het gehele project, waarbij KEMBIT samen met de klant beziet of de getoonde data naar verwachting en eventueel conform bestaande rapportages is. De filosofie achter KEMBIT BI is: wij zorgen dat de juiste data, op het juiste moment, bij de juiste personen volledig geautomatiseerd aangeleverd wordt. Wij leveren een aantal rapporten en de inhoudsdeskundigen zorgen daarna voor het verschaffen van de juiste inzichten met deze data, gebruikmakend van selfservice BI tools, zodat operationeel en strategisch de juiste beslissingen genomen kunnen worden.

4 2 Stap 1: Behoeften in kaart brengen De eerste stap in een Business Intelligence project (en in vele andere IT-projecten) is het in kaart brengen van de informatiebehoeften van de klant. Immers: hoe kun je een model en rapportages ontwikkelen als je niet eens weet wat de klant hierin wil zien? In deze case scheelt het dat KEMBIT haar eigen klant is; er is geen afstemming met een externe partij, we formuleren alle wensen en behoeften zelf. Natuurlijk moeten we hier ook zelf waken voor een juiste, concrete informatiebehoefte om de juiste zaken te kunnen opleveren. Bij het verzamelen en combineren van informatie dient het liefst zo min mogelijk ruimte voor interpretatie gelaten te worden. Daarnaast moet goed gekeken worden of het een realistisch verzoek is en moet de gevraagde informatie wel uit beschikbare data gehaald kunnen worden. Een aantal voorbeelden van concreet uitgeschreven informatiebehoeften zijn: Ik wil per raceseizoen, per coureur voor elke race kunnen zien hoeveel punten hij heeft gehaald Ik wil kunnen zien op welke circuits gemiddeld de meeste ongelukken voorkomen Ik wil voor elke coureur het aantal races, finishes en pole positions kunnen zien Ik wil bij elke race de snelste rondetijd voor iedere coureur kunnen zien Voorbeelden van onvoldoende gedefinieerde informatiebehoeften zijn: Ik wil alle data zien van de coureurs Zeker interessant, maar wat is alle data? Wat is relevant? Wat is beschikbaar? Ik wil graag de races zien in West-Europa Over welke tijdsperiode? Wat wil je van deze races zien? Ik wil de schoenmaat weten van iedere coureur toen ze 12 jaar oud waren Deze data is hoogstwaarschijnlijk niet beschikbaar De ervaring leert ons dat de beste methode om de wensen van de klant in kaart te brengen mockups (schermontwerpen) is. Niet alleen kom je op deze manier achter wat letterlijk het beeld van de klant is bij de rapportages, maar het helpt enorm om tijdens het ontwerpproces meer inzicht en diepgang te krijgen in de benodigde gegevens. Ervaring leert dat door het maken van de schermontwerpen de klant weer tot nieuwe inzichten komt.

5 3 Stap 2: Architectuur Zodra de informatiebehoefte en de benodigde bronnen duidelijk zijn, kan de architectuur bepaald worden. Onderstaande afbeelding toont de globale architectuur van de implementatie van de Formule 1 rapportages: In de afbeelding zijn een drietal soorten bronnen zichtbaar. De onderste bron is een MySQL database, die data bevat van alle Formule 1 races vanaf Verder hebben we twee Excel-lijsten gemaakt om de oorzaken van crashes te categoriseren en om coureurs te koppelen aan hun social media account. De MySQL database en de Excel bestanden worden gebruikt in de zogenaamde full load. Dit is een dataload die we eenmalig per raceseizoen uitvoeren, waarbij het complete datawarehouse wordt leeggegooid en opnieuw gevuld met de brondata (vandaar de naam full load ). Na elke race worden nieuwe resultaten beschikbaar in een web-service. Deze bevat alleen de gegevens van de laatste race. Deze web-service gebruiken we om gedurende het raceseizoen de resultaten aan te vullen. Omdat bij deze dataload het datawarehouse wordt aangevuld (en niet opnieuw gevuld), wordt dit de delta load genoemd. De bronnen worden bij beide typen dataloads eerst ingeladen in een staging omgeving. Deze omgeving is bedoeld om de benodigde brontabellen in één database te hebben staan. Bij de dataload van staging naar datawarehouse vindt pas echt de transformaties plaats. Zodra de gegevens in het datawarehouse zitten, kan het datawarehouse worden ingeladen in Power BI en hier wordt (zover nog niet gebeurd) een begrijpelijk model gevormd. Op basis van dit model worden de rapportages gemaakt.

6 4 Stap 3: Infrastructuur bepalen Nadat we de globale architectuur hebben besproken, komen de locatie en inrichting van de servers aan bod. De volgende vragen zijn hierbij belangrijk: Waar plaatsen we de staging database, het datawarehouse en de ETL (Extraction, Transformation en Load)? Heeft de klant een eigen server beschikbaar? Voldoet deze aan de eisen voor een BI-omgeving? Hoe richten we de OTAP (Ontwikkel-Test-Acceptatie-Productie) omgeving in? Heeft de klant al een Office365-account? Moeten de rapportages binnen de organisatie gedeeld worden? Hoe zorgen we dat de rapporten automatisch verversen? Welke securityeisen zijn er? In deze casus hebben we ervoor gekozen om de staging database, het datawarehouse en de ETL (de eerdergenoemde dataloads) te plaatsen op een bestaande KEMBIT server. Op deze server hebben we twee instances ingericht, een acceptatie en een productie instance. Aan databasekant is hiermee gekozen om productie te scheiden van ontwikkel, test en acceptatie. Een alternatieve keuze is om de omgeving in Azure in te richten. Dit kan door een Azure VM aan te schaffen, waarop alle benodigde functionaliteiten zijn geïnstalleerd, of door losse Azure componenten aan te schaffen, zoals Azure SQL DB en Azure Data Factory (v2). In het laatste geval heb je geen server nodig. Binnen KEMBIT heeft iedere medewerker een Office365 licentie. We willen de rapportages graag delen binnen de organisatie, dus hebben we een werkruimte ingericht waar de benodigde mensen aan toegevoegd zijn. Vanuit Power BI Desktop kun je het rapport naar deze werkgroep publiceren, dan is deze beschikbaar voor iedereen in de werkruimte. Om ervoor te zorgen dat de rapportages automatisch verversen, is het nodig om een gateway te installeren op de gekozen server. In de Power BI werkruimte geef je vervolgens aan dat deze gateway gebruikt dient te worden en kun je de frequentie van de verversing aangeven. In het kader van security zijn er een aantal configuraties beschikbaar. Als Power BI administrator kun je de Power BI security regelen op Office365 tenant niveau. Dit betreft de security van alle werkruimten. De grootste invloed op de security kun je uitoefenen door het goed inrichten van de wekruimten en role-based security. Zo dienen alleen de mensen die toegang tot het rapport mogen hebben toegevoegd te worden aan de werkruimte. Ook kun je binnen een rapport een rol aanmaken, bijvoorbeeld wanneer de wens is dat een groep alleen de data van Max Verstappen mag zien. In het geval van de Formule 1 demo zijn de security-eisen laag, aangezien de rapportage publiekelijk beschikbaar is en iedereen alle data in mag zien.

7 5 Stap 4: Datamodel ontwerpen Op basis van de rapportagebehoeften van de klant kan het datamodel ontworpen worden. Deze stap is in dit document als stap 4 gedefinieerd, maar kan eigenlijk parallel aan stap 3 worden uitgevoerd. We hebben ervoor gekozen om ons datawarehouse als sterschema op te zetten. Dit houdt in dat het datawarehouse bestaat uit feiten en dimensies. We zullen hier niet te veel in detail op ingaan, maar simpel gezegd is een dimensie een invalshoek en is een feit een meetwaarde. Het uiteindelijke datamodel ziet er als volgt uit:

8 Bij het maken van dit model zijn een aantal ontwerpkeuzes gemaakt. Dit wil zeggen dat er ook andere keuzes gemaakt hadden kunnen worden, waardoor het model er anders uit zou zien. Er is niet per definitie één ontwerpkeuze goed of fout. Een aantal ontwerpkeuzes die wij hebben gemaakt: DimSeason is verwerkt in DimRace (aan de hand van de datum) DimCircuit en DimDate hangen aan DimRace De ongelukken zitten verwerkt in de FactRaceResult De totale stand zit verwerkt in FactRaceResult Bij de eerste keuze zou je ook kunnen kiezen om DimSeason als aparte dimensie op te nemen. Bij keuze twee zou ook gekozen kunnen worden om DimCircuit en DimDate direct aan FactResult te hangen en DimRace weg te laten. De gegevens uit keuze 3 en 4 zou je ook in aparte feittabellen op kunnen slaan. Zoals je kunt opmaken uit de alternatieven die we hebben aangeleverd, had hier ook een heel ander model uit kunnen komen. Ontwerpkeuzes hebben grote invloed op het uiteindelijke model; hierbij zijn vele afwegingen te maken.

9 6 Stap 5: Datamodel vullen Nadat het datamodel is ontworpen, dient deze geïmplementeerd en gevuld te worden. Het implementeren gebeurt in SQL Server Management Studio (SSMS) en het vullen van het datamodel gebeurt in SQL Server Integration Services (SSIS). Het aanmaken van het datamodel is gedaan met behulp van SQL-scripts. Hierbij wordt een database aangemaakt, die gelijk is aan het ontworpen datamodel. Dit ziet er in SSMS uit als in nevenstaand voorbeeld. Het vullen van de gecreëerde database is echter een stuk interessanter. De beschikbare data online ziet er uiteraard niet precies zo uit zoals we het in het datamodel willen zien. Hier dienen de nodige transformaties plaats te vinden. Daarnaast is het niet efficiënt om elke keer alle data in te laden; dit kost namelijk een hoop tijd. Daarom hebben we een full- en een delta load gemaakt. Bij de full load wordt gebruik gemaakt van de MySQL source en de Excel files. Hierbij wordt het complete datawarehouse geleegd en opnieuw gevuld. Dit is een tijdrovend proces, waarbij wel alle data (dus elke dimensie, elk feit) volledig wordt gevuld. Bij een full load wordt de data zo efficiënt mogelijk opgeslagen, vergelijkbaar met defragmentatie op je pc. Deze dataload wordt één keer per raceseizoen uitgevoerd. De delta load maakt gebruik van de web-service en haalt de data van de laatste race op als JSON-bestand. Deze load wordt wekelijks uitgevoerd. Hierbij worden alleen de volgende tabellen (aan)gevuld: FactResult: Deze wordt aangevuld met de resultaten van de laatste race FactLaptime: Deze wordt aangevuld met de rondetijden van de laatste race DimDriver: Indien een nieuwe driver heeft meegedaan in de laatste race In de delta load wordt gecontroleerd of de data uit de web-service al in het datawarehouse aanwezig is. Het kan namelijk voorkomen dat er in een week geen race heeft plaatsgevonden. De web-service behoudt dan nog steeds de data van de laatste race van meer dan een week geleden. Met deze controle wordt voorkomen dat data dubbel in het datawarehouse terecht komt. Om ervoor te zorgen dat deze dataload automatisch plaatsvindt, worden de SSIS packages uitgerold naar SSMS. Daar hebben we vervolgens een SQL job aangemaakt om ervoor te zorgen dat elke week de dataload wordt gestart en het datawarehouse daarmee up-to-date blijft.

10 7 Stap 6: Power BI Nu alle benodigde data aanwezig is, zijn we aangekomen bij onze front-end tool: Power BI. Binnen deze tool dienen een aantal sub-stappen te worden genomen: Het rapportagemodel maken (genaamd tabular model ) De rapporten maken De rapportages publiceren en automatisch verversen Zodra je Power BI Desktop opent, heb je de mogelijkheid om data in te laden. Zodra je dit hebt gedaan, zit de data ook daadwerkelijk in het Power BI bestand opgeslagen en kun je ermee aan de slag. In het rapportagemodel dienen een aantal zaken te gebeuren: De naamgevingen omzetten naar gebruiksvriendelijke naamgeving (voor zover dat nog niet het geval is) Kolommen verbergen die niet relevant zijn voor de rapportages (technische ID s e.d.) Relaties leggen tussen de tabellen (in hoeverre Power BI dit niet al voor je doet) Metingen en berekende kolommen toevoegen Na het uitvoeren van bovengenoemde stappen ziet ons model er als volgt uit:

11 Op basis van dit model kunnen de rapportages gemaakt worden. Eén van de krachten van Power BI is dat je in deze tool gebruik kunt maken van DAX-formules, dezelfde formuletaal die in Excel gebruikt wordt. Daarom is de stap van het beheren van je data in Excel naar Power BI miniem. Als je het aantal drivers wilt tellen, kun je dus gewoon een meting aanmaken als: Aantal Drivers = COUNTROWS(Driver) Bij klanten bestaat natuurlijk een informatiebehoefte, anders zouden zij niet bij ons uit zijn gekomen. Daarom is het eigenlijk altijd zo dat KEMBIT de eerste rapportages voor de klant aanmaakt. Het idee is dat de klant hierna voor verdere inzichten zelf aan de slag gaat met Power BI. Onderstaande screenshots tonen één van de rapportages die KEMBIT gemaakt heeft. Voor alle rapportages, kijk op Zodra de rapportages in Power BI Desktop klaar zijn, dienen deze naar de Power BI Cloud gepubliceerd te worden. Hiervoor is een werkruimte specifiek voor de Formule 1 demo aangemaakt. In de Cloud-omgeving kun je vervolgens instellen wanneer de gegevensset moet worden ververst. Hierbij wordt in de Formule 1 casus gebruik gemaakt van de gekoppelde gateway. In de nevenstaande afbeelding wordt getoond hoe dit eruit ziet.

12 8 Stap 7: Ga zelf aan de slag! De laatste stap in het proces is de klant van een Power BI training voorzien, gebruikmakend van de gemaakte rapportages. Na deze training is het idee dat de klant zelf aan de slag gaat met de rapportages. Enthousiast na het lezen van dit whitepaper? Ga dan naar Hier tref je het uiteindelijke resultaat van de rapportages die wij gemaakt hebben en kun je Power BI zelf verkennen door de demo te downloaden. Ook kun je hier direct een vraag of opmerking sturen naar het KEMBIT BI Team. We helpen je graag!

13 Opfergeltstraat BW Wijnandsrade +31 (0) contactus@kembit.nl High Tech Campus AE Eindhoven