Qlik vs. Power BI: Deel 2 – Backend en datamodellering 

In het eerste deel introduceerden we deze blogserie en bepaalden we de grenzen van wat je de komende weken kunt verwachten. In deze blogpost vergelijk ik Qlik en Power BI op het gebied van datavoorbereiding en modellering, te beginnen met de back-end, de omgeving waar data wordt voorbereid en geladen in het model. 

Voordat we erin duiken, zorg dat je bij bent. Lees eerst het eerste deel van deze serie.

Back-end: waar datavoorbereiding begint  

Laten we beginnen met de back-end, de plek waar data wordt voorbereid en geladen in het model. Dit is het stadium waar de echte vergelijking tussen Qlik en Power BI begint op het gebied van datavoorbereiding en modellering. In Qlik is dat de Data Load Editor; in Power BI is dat Power Query. 

Voor de volledigheid: Qlik heeft ook andere mogelijkheden voor datavoorbereiding, waarvan sommige meer op de gebruikersinterface gericht zijn (Data Manager), previews bieden (Script), UI-transformaties (Table Recipe) of een flowachtige interface (Data Flow). Deze opties maakten geen deel uit van het project waar ik aan werkte, en behalve de Data Manager zijn ze nog relatief nieuw. Uiteindelijk blijft de Qlik Data Load Editor het meest gebruikte hulpmiddel onder Qlik-gebruikers wereldwijd, al sluit ik niet uit dat sommige van deze nieuwe functies in de toekomst een grotere rol zullen spelen. 

Ook Microsoft heeft aanvullende mogelijkheden voor datavoorbereiding, zoals Apache Spark-notebooks en Dataflow Gen2, maar deze vielen buiten de scope van dit project en worden beschouwd als onderdeel van Microsoft Fabric, niet van Power BI. Over het algemeen gebruiken Power BI-gebruikers Power Query, hoewel dat in de toekomst kan veranderen door Microsofts voortdurende uitbreidingen binnen Fabric. 

Power BI – Power Query 

Power Query staat bekend om zijn gebruiksvriendelijke point-and-click-interface. De meeste transformaties kunnen via de UI worden uitgevoerd en worden vastgelegd als opeenvolgende stappen. Voor complexere logica kun je schrijven in M-code, de scripttaal achter Power Query. Belangrijk is dat Power BI een andere taal gebruikt (DAX) voor berekeningen aan de voorkant. Als je Power BI echt wilt beheersen, moet je beide leren. 

Een van de sterke punten van Power Query is de toegankelijkheid. Omdat het ook beschikbaar is in Excel en dezelfde lint-interface gebruikt als andere Microsoft Office-tools, is het toegankelijk voor gebruikers zonder BI- of SQL-achtergrond. Veelvoorkomende taken zoals veldnamen wijzigen, datatypes aanpassen en tabellen samenvoegen kunnen met een paar klikken worden uitgevoerd. 

De meeste beginnende gebruikers werken met Power Query binnen Power BI Desktop, maar dezelfde transformatielogica is beschikbaar in de Power BI Service, omdat Microsoft steeds meer van de datamodelleerfuncties van Desktop naar de cloud heeft gebracht. 

Een handige functie in Power Query is column profiling, die de waardeverdeling, null-aantallen en uniciteit toont — nuttig voor datakwaliteitscontroles. Daarnaast is er het preview-venster, dat het resultaat van elke transformatieslag laat zien. Dit is erg handig voor debugging en om je data te begrijpen terwijl je werkt, iets wat ik vaak mis in Qlik. Het nadeel is dat deze previews de ontwikkeling kunnen vertragen, vooral bij grote datasets of trage verbindingen, omdat je na elke stap moet wachten op een preview.   

Het preview pane en column profiling in Power Query.

Om dit te omzeilen kun je je ruwe data laden in een Power BI Dataflow, een Power Query-omgeving in de Power BI Service. Dit stelt je in staat om ongetransformeerde data naar de cloud te uploaden en je model daarbovenop te bouwen. Afhankelijk van je datavolume en vereisten kan dit met een Pro-licentie, al hebben grotere setups Dataflows v2 nodig, waarvoor Fabric-capaciteit vereist is. 

Dataflows zijn in feite het Power BI-equivalent van Qlik’s QVD-architectuur. Ze maken het mogelijk om transformatielogica te centraliseren en te hergebruiken over meerdere semantische modellen heen. Beheer en governance zijn echter uitdagender, vooral in grotere omgevingen. In het project waar ik aan werkte verliep de overgang soepel dankzij het gebruik van Databricks, dat door zowel Qlik als Power BI wordt gebruikt om transformaties centraal uit te voeren. Zonder Databricks, MS Fabric of een vergelijkbaar platform zou het migreren van alle Qlik-scripts naar Power Query, terwijl de herbruikbaarheid van transformatieresultaten behouden blijft, vrijwel onmogelijk zijn geweest. 

Hoewel buiten de scope van deze vergelijking, wil ik Microsofts voortdurende investeringen in Microsoft Fabric noemen. Dit platform introduceert meer geavanceerde data-integratie- en opslagmogelijkheden, zoals Apache Spark-notebooks voor complexe transformaties en het gebruik van Fabric SQL-databases of Lakehouses. Deze vereisen echter allemaal Fabric-licenties. 

Naarmate je Power Query-complexer wordt, neemt de uitdaging toe om overzicht te houden. Zonder structuur kan je transformatieproces snel een rommeltje worden. 

Een handige functie is selectieve tabelverversing. Als je slechts één tabel aanpast, kun je alleen die tabel opnieuw laden, wat veel tijd bespaart. Dit kan ook vanuit de dataview aan de voorkant worden gestart wanneer je verse data nodig hebt. 

Qlik Sense – Data Load Editor 

In Qlik vindt datavoorbereiding plaats in de Data Load Editor, waar je Qlik-script schrijft. In tegenstelling tot Power Query’s stap-voor-stapbenadering bouwt Qlik-script tabellen kolom voor kolom op, meer zoals traditionele SQL. 

De Qlik Data load editor  

Deze scriptaanpak heeft een steilere leercurve, vooral voor gebruikers zonder technische achtergrond. Maar voor wie bekend is met SQL voelt de syntaxis redelijk vertrouwd aan. In vergelijking met Power Query is Qlik-script moeilijker om te leren, maar makkelijker te beheersen, vooral omdat dezelfde scripttaal zowel in de back-end als de front-end wordt gebruikt. 

Met QVD-bestanden kun je je ETL-proces opdelen in herbruikbare lagen, wat krachtig is voor kleine en middelgrote organisaties die Qlik gebruiken voor zowel ETL als visualisatie. In veel gevallen vervangt dit zelfs de noodzaak van een apart datawarehouse. 

Qlik heeft recent data-previews toegevoegd aan de scripteditor, maar die vereisen een gedeeltelijke load en zijn beperkt tot de bovenste X-rijen. Anders dan bij Power Query kun je in Qlik de transformaties niet stap voor stap bekijken. De nieuwere functie Table Recipe (alleen in Qlik Cloud) biedt dit wél, maar maakt nog geen deel uit van de Data Load Editor. 

Een nadeel is dat het herladen van slechts één tabel omslachtig is. Je kunt partial reloads gebruiken, maar die vereisen extra script in de LOAD-statements van al je tabellen. Als je dus alleen de tabel DimCustomer wilt herladen, zul je scriptwijzigingen moeten aanbrengen. Hoewel partial reloads in sommige situaties nuttig kunnen zijn, zie je ze in de praktijk zelden gebruikt voor dit soort scenario’s, omdat de scriptlogica al snel te complex wordt. Natuurlijk kun je, als je je transformatielogica netjes hebt gescheiden van je front-end, één tabel rechtstreeks vanuit de bron verversen. Maar ook dan moet je altijd het volledige front-end datamodel opnieuw laden om die wijziging daar zichtbaar te maken. 

Daarnaast heb je in Qlik vaak een aparte app nodig om brontabellen of eindresultaat te inspecteren. In Qlik Client-Managed omgevingen betekent dit vaak externe QVD-viewers of meerdere apps open naast elkaar. 

Functionele verschillen  

Enkele Qlik-functies bestaan niet in Power Query 

Hierbij een aantal noemenswaardige voorbeelden: 

• AutoNumber() – genereert unieke nummers voor strings, handig bij joins en geheugenoptimalisatie. 

• Where Exists() – filtert data tijdens het laden op basis of een sleutel al bestaat een andere tabel. 

• ApplyMap() – een mappingfunctie vergelijkbaar met Excel’s VLOOKUP, waarmee je data kunt verrijken zonder joins uit te voeren. 

In Power BI moet je joins of lookup-tabellen gebruiken om hetzelfde te bereiken, dit gaat vaak ten koste van prestaties. Het variabele-concept in Qlik kent ook geen echt equivalent in Power Query. Hoewel Power Query parameters ondersteunt, kunnen deze niet dynamisch worden bijgewerkt tijdens reloads, waardoor het lastig is om lussen (zoals for..each) te implementeren. 

Aan de andere kant biedt Power Query enkele ingebouwde functies en mogelijkheden die juist moeilijker na te bootsen zijn in Qlik: 

• HTML parsing: het verwijderen van HTML-tags is eenvoudig met Power Query’s Html.Table()-functie. In Qlik vereist dit een combinatie van SubField() en mappingtabellen, of het gebruik van de nieuwere RegEx-functies die beschikbaar zijn in Qlik Cloud. 

• List transformations: Power Query ondersteunt krachtige list transformations. Zo kun je eenvoudig een cumulatief totaal berekenen met List.Accumulate() of een dynamisch datumbereik maken met List.Generate(). In Qlik zijn deze taken ook mogelijk, maar vereisen ze meer inspanning bijvoorbeeld loops voor datumberekening of gesorteerde scripts voor cumulatieve berekeningen. Gevorderde ontwikkelaars gebruiken ze veel, maar voor beginners is de aanpak van Power BI meestal toegankelijker. 

• Pivot en unpivot: Power Query laat je data herschikken met slechts een paar klikken rechtstreeks in de UI. In de Qlik Data Load Editor moet je hiervoor Crosstable() of Generic Load gebruiken, wat betekent dat je de code zelf moet schrijven. In het verleden had QlikView een ingebouwde wizard voor unpivoting in de scripteditor, maar in Qlik Sense is dit verplaatst naar de Data Manager 

Datamodel: de ruggengraat van je dashboard

Het datamodel is het resultaat van je back-endtransformaties en vormt de basis van je front-endvisualisaties. Hoewel beide tools streven naar krachtige en flexibele modellen, hanteren ze een verschillende aanpak.

Qlik Sense – Associative Model 

Qlik koppelt tabellen automatisch op veldnamen. Wanneer meerdere velden dezelfde naam hebben, ontstaan synthetic keys, die je beter kunt vermijden.  

Alle relaties in Qlik zijn bidirectioneel. Dat betekent dat je niet zomaar twee fact-tabellen kunt filteren op gedeelde sleutels zonder een cirkelverwijzing te veroorzaken iets wat Qlik blokkeert. Om dit op te lossen, moet je vaak je model herstructureren door fact-tabellen samen te voegen of dimensies te dupliceren. In tegenstelling tot Power BI kan Qlik ook many-to-many-relaties creëren zonder dat de ontwikkelaar dit direct merkt. Meestal wil je dit juist voorkomen bij het opbouwen van een datamodel. 

Deze beperking kan soms frustrerend zijn, maar dwingt ontwikkelaars ook om beter na te denken over hun modelontwerp wat uiteindelijk loont. Het helpt om een wirwar van dataverbindingen te voorkomen, al beschermt het je niet volledig als je het model onvoldoende doordacht hebt of te veel bedrijfslogica in één dashboard probeert te stoppen. 

De Associative Engine van Qlik biedt overigens meer dan alleen veldkoppeling maar daarover meer in deel 3 van deze reeks. Voor nu kunnen we concluderen dat het datamodel van Qlik krachtig is, maar discipline vereist in naamgeving en structuur. 

Power BI – Semantisch Model 

Power BI biedt een flexibelere modelleeromgeving. Relaties tussen tabellen kunnen handmatig worden aangemaakt of automatisch worden voorgesteld, en je kunt tabellen koppelen op elk gewenst veld, ongeacht de naam. 

Je kunt daarbij ook het volgende definiëren: 

• Cardinaliteit (één-op-één, één-op-veel, veel-op-veel) 

• Filterrichting (éénrichtings- of tweerichtingsfiltering) 
  

Dit doe je meestal in de Data Model-weergave van Power BI Desktop, dus na de Power Query-transformaties. 

 

Dankzij deze mogelijkheden kun je bijvoorbeeld meerdere feiten-tabellen koppelen aan gedeelde dimensies zonder loops te veroorzaken. Dat kan krachtig zijn, maar leidt soms ook tot complexe modellen die moeilijk te ontleden zijn. In de meeste gevallen is het aan te raden om ook in Power BI een stermodel te bouwen, zodat je datamodel robuust blijft en het aantal tussenstappen beperkt blijft. 

De Model view in Power BI Desktop.

In Power BI kun je bovendien rapporten bouwen op basis van een bestaand semantisch model, zodat meerdere front-endrapporten dezelfde back-end kunnen delen. Je kunt zelfs één rapport bouwen op meerdere semantische modellen. 

Een bijzonder handige functie is Power BI’s visuele relatieweergave, waarin je in één oogopslag de cardinaliteit en filterrichting ziet. Je kunt deze expliciet definiëren, en als de data niet aan de verwachte relatie voldoet (bijv. een één-op-veel die een veel-op-veel wordt), geeft Power BI een foutmelding nog vóórdat de eindgebruiker foutieve data te zien krijgt. 

Modelinspectie en datakwaliteit  

Power BI scheidt de Model View van de Table View, waardoor je: 

• volledige tabellen kunt doorbladeren 

• data kunt filteren en sorteren 

• kolommen en metingen kunt inspecteren 

• snelle datakwaliteitscontroles kunt uitvoeren 

Dit maakt het eenvoudig om je model te valideren en problemen op te sporen tijdens de ontwikkeling. 

In Qlik kun je tabellen bekijken in de Data Model Viewer. Die toont alleen de eerste 100 rijen en ondersteunt geen filtering of sortering. 

Wil je iets aanpassen of grondiger inspecteren, dan moet je meestal: 

• Een tijdelijke sheet toevoegen met een tabelobject, 

• Een aparte app gebruiken om bron- of doeltabellen te bekijken, 

• Ff, in Qlik Client-Managed, een externe QVD-viewer gebruiken. 

De Qlik Data Model viewer 

Conclusie: structuur vs. flexibiliteit 

Op het gebied van back-end en datamodellering bieden zowel Qlik Sense als Power BI krachtige mogelijkheden, maar ze pakken problemen aan uit verschillende invalshoeken.   

Beide tools zijn krachtig, maar verschillen sterk in aanpak: 

• Power BI blinkt uit in flexibiliteit, visuele relatiebeheer en foutdetectie. Het is toegankelijk en gebruiksvriendelijk, vooral voor Excel- of niet-technische gebruikers. Diezelfde flexibiliteit kan echter leiden tot rommelige modellen als er geen duidelijke structuur wordt aangehouden.  

• Qlik Sense legt juist meer nadruk op structuur, via naamgevingsconventies en zijn associative model. Hoewel de leercurve steiler is en de datavoorbereidingsomgeving minder visueelis, stimuleert Qlik een schoner, herbruikbaar en schaalbaar ontwerp vooral met het gebruik van QVD’s.  

Volgende: Front-end & gebruikerservaring 

In het volgende deel verplaatsen we ons van de machinekamer naar de showroom: de frontend. We vergelijken hoe beide tools omgaan met: 

• Visualisaties en interactiviteit 

• Expressietalen (DAX vs. Qlik-expressies) 

• Prestaties en responsiviteit 

• Ontwikkelervaring en samenwerking 

• Eindgebruikerservaring en self-service 

Als je ooit hebt willen weten waarom een dashboard in Power BI anders “aanvoelt” dan in Qlik, zelfs met dezelfde data, dan wil je dit niet missen.  

Bekijk de volledige serie: 

• Deel 1: Een praktijkgerichte vergelijking 

• Deel 3: Frontend ontwikkeling en gebruikerservaring 

• Deel 4: Eindgebruikersinteractie en integratie 

Blijf op de hoogte! 

Meer van het Bitmetric team