Waarschijnlijk ben je al een tijdje bezig met het zetten van de eerste stappen in data-land: de eerste dashboards, de eerste modellen, de eerste analyses. Via een Power BI-connector, een handgeschreven script, of een uitgebreide Excel-sheet haal je je data op. Ergens komt er een kink in de kabel: de data past niet meer in Excel, de connector valt steeds uit of je probeert data aan elkaar te knopen. De huidige werkwijze voldoet niet langer. Kortom: tijd voor een datawarehouse.

Maar welke software moet je daarvoor kopen? En is een cloud-native-oplossing het beste of is flexibiliteit belangrijker? Commercieel of toch liever open source? En ook: wat mag het kosten?

Stappenplan

Veruit de belangrijkste overweging is de vraag wat je er mee gaat doen, nu en in de voorzienbare toekomst. Een datawarehouse opzetten en inrichten is geen kleinigheid. En op een later tijdstip veranderen van leverancier is doorgaans een recept voor stevige en langdurende hoofdpijn. Daarom heb ik een stappenplan ontwikkeld. Op deze manier blijft het overzichtelijk.

Stap 1: het soort data bepaalt in grote mate de mogelijkheden

Het overgrote deel van onze klanten beschikt over data die eigenlijk bestaat uit veel grote Excelsheets-achtige data, ofwel tabulaire data. Denk hierbij aan data vanuit een webshop zoals Shopify, een financieel pakket als Exact Online, of sensordata die temperatuur en vochtigheid in een kas meet. De data is tabulair, omdat we rijen hebben (bijvoorbeeld: transacties van de webshop, memoriaalboekingen, of kastemperaturen), waarbij de kolommen aangeven wáár iets gebeurd is, wanneer, en vaak ook door wie. Dit soort data past goed in een Excelsheet mits het niet teveel is.

Herken je je in dit soort data-eisen? Dat is fijn: je hebt vrijwel onbeperkt keuze in welke datawarehouse-software je wilt gaan gebruiken. Dus nadrukkelijk óók relationele databases die je als datawarehouse in kunt zetten. Waarom je hiermee geluk hebt? De kosten zijn heel overzichtelijk en er zijn een paar duidelijke keuzes te maken.

Als je data primair tabulair van aard is, zijn traditionele oplossingen zoals Microsoft SQL Server (prijzig maar veelgebruikt), PostgreSQL (de populairste open source -en dus gratis!- database-software) en Oracle (zeer prijzig maar verbluffend robuust) goede opties. Bottom line: voor organisaties die niet gebonden willen zijn aan commerciële software is PostgreSQL een goede optie, anders kun je voor Microsoft of Oracle gaan.

Extra handig: PostgreSQL ondersteunt, via talloze plugins, vrijwel alle soorten data die je maar kunt bedenken. Bijvoorbeeld tekstzoek-data (Full Text Search) en vectordata (perfect in combinatie met generatieve ai-toepassingen).

Er zijn ook nadelen aan bovenstaande softwarepakketten voor datawarehouses. Zo zijn ze niet specifiek voor zogenaamde *OLAP-*doeleinden gemaakt (OLAP betekent Online Analytics Processing), maar vaak voor OLTP-doeleinden (Online Transaction Processing). Dat betekent dat de hoge data-integriteitsstandaarden de snelheid soms in de weg zitten. Dit merk je in de praktijk pas als je echt heel veel data hebt (honderden miljoen datapunten of meer). En zelfs dan zijn dergelijke systemen goed te optimaliseren.

Heb je te maken met dergelijke enorme hoeveelheden data, dan kun je zogenaamde columnar storage-gebaseerde datawarehouses inzetten. ClickHouse, Synapse Analytics en Redshift zijn voorbeelden hier van. Dit zijn moderne alternatieven, maar vereisen wel iets andere manier van denken dan je gewend bent van klassieke databases. We raden ze dan ook vooral aan voor geavanceerdere doeleinden met specifieke wensen rondom snelheid of hoeveelheid data.

Als je data niet hoofdzakelijk tabulair van aard is, maar bijvoorbeeld bestaat uit afbeeldingen, video’s, documenten en dergelijke, dan zijn andere systemen geschikt. Voor documenten zou je kunnen denken aan Apache Cassandra, of een Data Lakehouse. De flexibiliteit van deze systemen vereist wel een grote mate van precisie, vooral bij het invoeren van data, dus bezint eer ge begint.

Stap 2: waar ga je je datawarehouse voor gebruiken?

Wil je real-time analytics op vele miljoenen observaties die je op allerlei mogelijke manieren samen wilt voegen en uit elkaar wilt trekken? Dan is een relationele database datawarehouse (zoals PostgreSQL of Oracle) niet geschikt. Je komt dan al snel in het domein van column storage-systemen.

…maar wees eerlijk: heb je dit echt nodig? Heb je die hoeveelheden data, en is snelheid zo cruciaal? Als het antwoord ja is, dan zijn column storage-datawarehouses zeker je vriend.

De meeste van onze klanten kunnen prima uit de voeten met relationele databases als datawarehouse. De eerder genoemde data-integriteit en de jarenlange ervaring helpen hierbij. Personeel vinden met ervaring met dergelijke systemen is doorgaans makkelijker dan voor esotherische, nieuwe systemen. Bovendien heb je de -inmiddels decennia lange- basis waarop dergelijke relationele databases gebouwd zijn niet met de meeste systemen. Ga je voor een nieuw ontwikkeld systeem, onderzoek dan goed hoe duurzaam die investering is. Is het open source met een grote community van ontwikkelaars? Of zijn het afgesloten producten van ‘hippe start-ups’?

Stap 3: kosten en flexibiliteit

De kosten voor een datawarehouse zijn soms erg onduidelijk. Zo betaal je bij Google BigQuery (een prachtig columnar-georiënteerd systeem) niet zozeer voor de opslag of de hoeveelheid computerprocessoren, maar vooral hoeveel data er per data-opvraag geanalyseerd wordt. Dat is mooi voor datasets die je weinig gebruikt — maar waarom zou je veel moeite steken in het opslaan van data die je weinig gebruikt? Check de pricing models dus goed, zeker als je in de cloud werkt.

Een andere kostenpost zijn de licentiekosten. Commerciële aanbieders van datawarehouse-software hebben vaak ingewikkelde licentiemodellen waarbij de hoeveelheid geheugen, het soort data, het aantal processoren en dergelijke bepalend zijn voor wat je betaald. Ben je net lekker bezig en wil je meer met je datawarehouse gaan doen, betaal je opeens ook (fors) meer voor je licentiekosten.

Bovenstaande druist erg in tegen de data science-gedachten van ‘onderzoek alles en behoudt het goede’. Het zou analisten vrij moeten zijn zo vaak en zo veel data te analyseren als ze zelf willen, in plaats van afgestraft te worden op gebruik.

Naast kosten is flexibiliteit een belangrijke overweging. Neem nu SQL Server: als je dit pakket afneemt in de cloud, dan zit je al vrij snel automatisch vast aan Azure. Een overstap naar een andere cloudprovider kan wel (of moet soms, in geval van stringentere privacy-wetgeving), maar vereist een veel duurdere licentie.

Ons advies

Wees eerlijk tegenover jezelf en bekijk de hoeveelheid en het soort data dat je wil verwerken kritisch. Trap niet in de val van meteen het nieuwste willen, maar onderzoek of bewezen technieken voldoende zijn voor jouw (voorzienbare) doelen.

…en onderschat de kracht van open source-software niet.