De laatste tijd zie je dat steeds meer bedrijven aan de slag gaan met Power BI. Het is een populair product, men heeft er weleens van gehoord en het is makkelijk zelf, en gratis, te downloaden. De drempel om een dashboard te bouwen is laag en het ziet er al snel erg mooi en interactief uit. Wat is nu nog de meerwaarde van een datawarehouse of een semantische laag als iedereen gewoon zelf met power BI aan de slag kan? 

 

Databron

Als men binnen een organisatie zelf aan de slag gaat met Power BI als self-service tool zien we waak dat Power BI wordt gevoed door excel files. Deze excel files worden vaak uit een bronapplicatie geexporteerd en daarna, voordat ze in Power BI worden geladen, als dan niet bewerkt. Om een rapportage te updaten moeten een aantal handelingen worden verricht en de herkomst van de data van de verschillende dashboards is soms zelfs lastig te achterhalen. Voor je het weet wordt de organisatie gestuurd op dashboard waarvan eigenlijk niemanad ooit goed heeft gecontroleerd of de data echt wel klopt. 

Organisaties die de data al rechtstreeks uit het bronsysteem halen denken deze problemen voor te zijn, maar ook dan kan het erg nuttig zijn om na te denken over de architerctuur. Een model in Power BI is zo gemodelleerd, maar waar leg je dan je definities vast en hoe zorg je dat de tabellen altijd op de goede manier aan elkaar worden gekoppeld?  

Semantische laag

Wat is nu de meerwaarde van een semantische laag tussen de database en de rapportage tool?  

  • Definities kunnen op 1 plek worden vastgelegd
  • Modellering hoeft maar 1 keer te worden gedaan
  • De modellering wordt juist gedaan, waardoor iedereen over de juiste cijfers beschikt
  • Een eindgebruiker hoeft geen verstand van databases te hebben
  • Men kan rapporteren aan de hand van businesstermen

Security

 

Collaboration

Conclusie

Zodra we in gesprek komen met onze klanten over de noodzaak van een column-store database ten behoeve van hun BI behoeften gaat het veelal zo:

 

Met zulke hoeveelheden rijen waarover jullie willen rapporteren, is het raadzaam om een column store database aan te schaffen voor jullie BI omgeving

Wat? Hoezo? We hebben net veel geld uitgegeven aan nieuwe hardware voor onze Oracle omgeving en we hebben op die omgeving nog genoeg ruimte

Laat me raden, jullie ERP omgeving draait daar op?

Jazeker, en we hebben ook nog een hot-standby scenario ingericht

Dat is allemaal prachtig voor jullie operationele behoeften, maar als wij de BI omgeving gaan inrichting op die omgeving gaan we niet de performance halen die jullie verwachten

Die performance is nu meer dan goed, via de webportal worden soms wel 100 orders per minuut ingeschoten, zonder problemen!

Klinkt inderdaad alsof jullie het goed voor mekaar hebben, maar geloof ons nu maar, voor jullie BI gaat het niet werken

Hoe moet ik mijn manager nu overtuigen om budget ter beschikking te stellen voor een nieuwe database terwijl we net afgelopen jaar al geinvesteerd hebben in de database?

Horses for courses

Huh? Leg uit!

 

Ok, dat probeer ik dan maar te doen

Bij het starten van BI trajecten vergeet men  vaak te kijken of hun huidige database wel aansluit bij de eisen van een BI omgeving. Veel bedrijfen beschikken namelijk vaak al over een van de traditionele OLTP database smaken zoals Oracle, DB2, Sybase ASE, Microsoft SQL Server, Informix etc. Het is dan begrijpelijk dat men vergeet om te toetsen of de BI omgeving uit de voeten kan met die bestaande database:

Een database is immers toch maar gewoon een database?

Nee, het tegendeel is waar. Databases zijn er in allerlei smaken.
Het eenvoudigste tweedeling die je kan maken is wel of geen On-line Transaction Processing database (OLTP).

Sterk versimpelt kun je zeggen dat OLTP databases als primair doel hebben het snel en betrouwbaar vastleggen van transacties. Daarom is het zo dat bijna elk bedrijf wel een database in-huis heeft dat goed is voor OLTP, omdat transactionele vastlegging belangrijk is voor elk bedrijf.

OLTP databases kenmerken zich door een rij/record als een geheel op te slaan, dus rij blok na rij blok achter mekaar. Rijen als geheel kunnen hierdoor snel gevonden en bijgewerkt worden. Onderstaande plaatje illustreert het verschil in fysieke opslag methodiek tussen rij en kolom opslag. 

 

row storage column storage comparison

 

De niet-OLTP database smaken zijn er legio, maar in ons geval ligt de focus op databases die data-analyse vergemakkelijken. Dus met het oog op functionaliteit die nodig is voor efficiente BI omgevingen.

Waar moet dan een database voor data analyse aan voldoen?

  • Snel grote hoeveelheden data kunnen laden
  • Snel kunnen aggregeren over veel data om samenvattingen te maken
  • Ad-hoq vragen moeten niet veel langzamer beantwoord worden dan veel voorkomende vragen
  • Data opslag moet niet te kostbaar zijn (compressie is belangrijk)
  • Schaalbaar voor toenemende hoeveelheden data qua query snelheid en data laad tijd

Wat is niet zo belangrijk voor een data analyse database?

  • ACID compliance
  • Veel concurrerende sessies ondersteunen
  • Snel kunnen updaten van een enkel record
  • Fail over (vaak niet bedrijfskritisch)

Geconcludeerd kan worden dat een row-store OLTP database zeer verschilt van een column-store data-anaylyse database, en in een volgende blog zal ik ingaan waarom een column-store database veel beter voldoet aan de eisen die een BI omgeving stelt dan een row-store OLTP database. Dit zal ik illustreren met enkele praktijk voorbeelden. Stay-tuned