Qlik vs. Power BI: deel 2 – Back-end & datamodellering 

In het eerste deel introduceerden we deze blog en bakenden we het onderwerp voor de rest van de serie af. In deze blog vergelijk ik hoe Qlik en Power BI omgaan met datavoorbereiding en modellering. We beginnen bij de back-end, waar de data wordt voorbereid en in het model wordt geladen.

Zorg voordat we de diepte ingaan dat je helemaal bij bent. Lees hier het eerste deel van deze serie.

Back-end: waar datavoorbereiding begint 

Laten we beginnen bij de back-end, waar data wordt voorbereid en in het model wordt geladen. Dit is de fase waarin de echte vergelijking tussen Qlik en Power BI op het gebied van datavoorbereiding en modellering begint. In Qlik gebeurt dit in de Data Load Editor; in Power BI is dat Power Query. Voor de volledigheid: Qlik biedt ook andere opties voor datavoorbereiding. Sommige zijn meer UI-gestuurd (Data Manager), bieden previews (Script), ondersteunen transformaties via de UI (Table Recipe) of hebben een flow-achtige interface (Data flow). Deze opties maakten geen deel uit van het project waaraan ik werkte en zijn, met uitzondering van Data Manager, nog relatief nieuw. Uiteindelijk blijft de Qlik Data Load Editor wereldwijd de meest gebruikte tool onder Qlik-gebruikers, al sluit ik niet uit dat sommige van deze nieuwe opties in de toekomst een prominentere rol krijgen.  

Microsoft biedt eveneens aanvullende opties voor datavoorbereiding, zoals Apache Spark-notebooks en Dataflow Gen2. Deze vielen echter 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, al kan dat veranderen doordat Microsoft de functionaliteit binnen Fabric verder blijft uitbreiden. 

Power BI – Power Query 

Power Query staat bekend om de gebruiksvriendelijke point-and-click-interface. De meeste transformaties kun je via de gebruikersinterface uitvoeren en als opeenvolgende stappen vastleggen. Voor geavanceerdere logica kun je M-code schrijven, de scripttaal achter Power Query. Het is belangrijk om te weten dat Power BI voor berekeningen in de front-end een andere taal gebruikt: DAX. Als je Power BI volledig wilt beheersen, is het essentieel dat je beide onder de knie hebt. 

Een van de sterke punten van Power Query is de toegankelijkheid. Omdat het ook beschikbaar is in Excel en net als andere Microsoft Office-tools een vertrouwde lintinterface gebruikt, is het laagdrempelig voor gebruikers zonder BI- of SQL-achtergrond. Veelvoorkomende taken, zoals velden hernoemen, datatypen wijzigen en tabellen samenvoegen, voer je met slechts een paar klikken uit.

De meeste beginnende gebruikers werken met Power Query binnen Microsoft Power BI Desktop, maar dezelfde transformatielogica is ook beschikbaar in de Power BI-service. Microsoft voegt namelijk ook de meeste functies voor datamodellering uit de desktopversie toe aan de cloudservice.  

Een handige functie in Power Query is kolomprofilering. Deze toont de verdeling van waarden, het aantal null-waarden en de uniciteit, wat helpt bij controles op datakwaliteit. Een andere opvallende functie is het voorbeeldvenster, waarin je het resultaat van elke transformatiestap ziet. Dit is bijzonder nuttig bij het opsporen van fouten en om je data gaandeweg beter te begrijpen, iets wat ik in Qlik vaak mis. Deze voorbeelden kunnen de ontwikkeling echter ook vertragen, vooral bij grote datasets of tragere verbindingen. Je moet dan na elke stap wachten op het voorbeeld voordat je de volgende transformatiestap kunt uitvoeren.  

Het voorbeeldvenster en de kolomprofilering van Power Query 

Om dit te omzeilen, kun je je onbewerkte data laden in een Power BI Dataflow, een Power Query-omgeving in de Power BI-service. Hiermee kun je ongetransformeerde data naar de cloud uploaden en daarbovenop je model bouwen. Afhankelijk van je datavolume en vereisten kan dit met een Pro-licentie, hoewel voor grotere omgevingen mogelijk Dataflows v2 nodig is. Hiervoor is Fabric-capaciteit vereist.  

Dataflows zijn in feite het Power BI-equivalent dat het dichtst bij de QVD-gebaseerde architectuur van Qlik komt. Hiermee kun je transformatielogica centraal beheren en hergebruiken in meerdere semantische modellen. Governance en beheerbaarheid kunnen echter lastiger zijn, vooral in grotere omgevingen. Een andere aanpak is om de transformatielogica helemaal uit de BI-tool te halen en deze in een apart dataplatform te beheren. Met bijvoorbeeld TimeXtender-consultancy helpen we organisaties een herbruikbare datafundament onder governance te bouwen die zowel Power BI als Qlik kan ondersteunen.

In de omgeving waarin wij werkten, zou de overgang veel minder soepel zijn verlopen zonder het Databricks-platform waarop zowel Qlik als Power BI is aangesloten en waar de meeste transformaties centraal worden uitgevoerd. Zonder Databricks, Microsoft Fabric of een vergelijkbaar dataplatform zou het vrijwel onmogelijk zijn geweest om alle Qlik-scripts naar Power Query te migreren en daarbij herbruikbare transformatielogica te behouden. Als je een bredere overgang plant, behandelt onze Qlik naar Power BI migratiegids de architectonische, organisatorische en praktische aandachtspunten die verder gaan dan alleen het datamodel. In de gids vind je ook onze Migration Readiness Checklist met 85 concrete checkpunten om te beoordelen hoe goed je huidige omgeving op een migratie is voorbereid.

Hoewel dit buiten de scope van deze vergelijking valt, moet ik de voortdurende investeringen van Microsoft in Microsoft Fabric noemen. Dit platform biedt geavanceerdere mogelijkheden voor data-integratie en -opslag. Je kunt bijvoorbeeld Apache Spark-notebooks gebruiken voor complexe transformaties. In grootschalige omgevingen vormen die een robuuster en schaalbaarder alternatief voor Power Query. Het resultaat kun je wegschrijven naar een Fabric SQL-database of Lakehouse. Voor al deze mogelijkheden is echter een licentie voor Microsoft Fabric-capaciteit vereist.

Voor grotere omgevingen wordt dit vaak een architectuurkeuze in plaats van alleen een Power BI-keuze. Bij onze Microsoft Fabric-consultancy richten we ons doorgaans op die bredere dataplatformlaag, waaronder integratie, opslag en herbruikbare transformatielogica.

Een praktijkvoorbeeld van deze aanpak is onze casestudy van Nature’s Pride, waar TimeXtender de centrale datalaag werd toen de organisatie de overstap van Qlik naar Power BI maakte.

Naarmate je Power Query-query’s complexer worden, wordt het lastiger om structuur te behouden. Zonder een gedisciplineerde aanpak kunnen je transformatiestappen al snel een onoverzichtelijk geheel worden.  

Een functie die ik bijzonder waardeer, is het selectief vernieuwen van tabellen. Als je slechts één tabel in je model wijzigt, kun je met Power Query alleen die tabel opnieuw laden. Dat bespaart tijd tijdens de ontwikkeling. Je kunt dit ook vanuit de dataweergave in de front-end starten als je actuele data uit je databron nodig hebt.

Power BI biedt veel flexibiliteit, maar daardoor worden architectuur en conventies ook belangrijker naarmate de omgeving groeit. Bij onze Power BI-consultancy helpen we organisaties vaak om die basis goed neer te zetten voordat de complexiteit toeneemt. 

Qlik Sense – Data Load Editor 

In Qlik vindt datavoorbereiding plaats in de Data Load Editor, waar je Qlik-script schrijft. Anders dan de stapsgewijze aanpak van Power Query 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 die gewend zijn aan Excel of geen technische achtergrond hebben. Wie bekend is met SQL, zal de syntaxis echter deels herkennen. Vergeleken met Power Query is Qlik-script moeilijker te leren, maar eenvoudiger te beheersen. Dat komt vooral doordat dezelfde scripttaal wordt gebruikt in zowel de back-end als de front-end. 

In elke omgeving kan iemand er een rommeltje van maken, maar Qlik maakt het eenvoudiger om je code overzichtelijk en modulair te houden. Met QVD-bestanden kun je je ETL-proces opsplitsen in herbruikbare lagen. Deze aanpak is krachtig voor kleine tot middelgrote organisaties die Qlik gebruiken voor zowel ETL als visualisatie. In veel gevallen maakt dit zelfs een afzonderlijk datawarehouse overbodig.

Qlik biedt datapreviews in de scripteditor, maar daarvoor is een gedeeltelijke load nodig en de previews zijn beperkt tot de bovenste X rijen. Anders dan in Power Query van Microsoft kun je transformaties tijdens het schrijven niet stap voor stap bekijken in de Qlik Data Load Editor. Qlik heeft inmiddels Table Recipe, geïntroduceerd, waarmee je stapsgewijze transformaties met datapreviews kunt uitvoeren. Dit is echter alleen beschikbaar in Qlik Cloud (voorlopig) en is een afzonderlijke functie naast de Data Load Editor.   

Een andere beperking is dat het omslachtig is om slechts één tabel opnieuw te laden. Je kunt hiervoor gedeeltelijke reloads gebruiken, maar dan moet je script toevoegen aan de LOAD-statements van al je tabellen. Als je alleen die ene DimCustomer-tabel opnieuw wilt laden, moet je het script aanpassen. Hoewel een gedeeltelijke reload zeker nuttig kan zijn, heb ik deze in echte productieomgevingen zelden voor dit scenario zien gebruiken, omdat de scriptlogica dan te complex wordt. Als je transformatielogica netjes van je front-end is gescheiden, kun je natuurlijk 1 tabel vanuit de bron vernieuwen. Je moet dan wel altijd het volledige datamodel van de front-end opnieuw laden om de tabel ook daar bij te werken.  

Bij het verkennen van je data heb je vaak een afzonderlijke Qlik-app nodig om bron- of doeltabellen te bekijken. In Qlik Client-Managed betekent dit vaak dat je een externe QVD-viewer gebruikt, of meerdere apps naast elkaar opent om zowel de bron als de resultaten van je transformaties te bekijken.

Qlik is zeer krachtig voor datavoorbereiding en -modellering, maar grotere omgevingen zijn gebaat bij duidelijke scriptingconventies, herbruikbare lagen en een gedisciplineerde architectuur. Binnen ons werk op het gebied van Qlik-consultancy zijn dit veelvoorkomende aandachtspunten wanneer we organisaties helpen hun Qlik-omgevingen schaalbaar en onderhoudbaar te houden.

Verschillen in functionaliteit 

Sommige Qlik-functies bestaan simpelweg niet in Power Query.

Enkele opvallende voorbeelden: 

• AutoNumber() – Genereert automatisch unieke gehele getallen voor tekenreeksen, wat handig is om joins te optimaliseren en het geheugengebruik te verminderen. 

• Where Exists() – Filtert data tijdens het laden op basis van de vraag of een sleutel al in een andere tabel bestaat. 

• ApplyMap() – Een mappingfunctie die vergelijkbaar is met VLOOKUP in Excel en wordt gebruikt om data te verrijken zonder joins uit te voeren. 

In Power BI heb je joins of opzoektabellen nodig om deze werkwijzen na te bootsen, vaak ten koste van de prestaties. Ook heeft het variabelenconcept van Qlik geen echte tegenhanger in Power Query. Power Query ondersteunt wel parameters, maar die kunnen tijdens reloads niet dynamisch worden bijgewerkt. Daardoor zijn loops (zoals for..each) lastig te implementeren. 

Daar staat tegenover dat Power Query ook enkele  ingebouwde functies en mogelijkheden heeft die moeilijker na te bootsen zijn in Qlik: 

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

• Lijsttransformaties: Power Query ondersteunt krachtige bewerkingen op basis van lijsten. Je kunt bijvoorbeeld eenvoudig een voortschrijdend totaal genereren met List.Accumulate(), of een dynamisch datumbereik maken met List.Generate(). In Qlik zijn deze taken mogelijk, maar ze kosten meer moeite. Denk aan loops voor het genereren van datums of sortering en scripting voor cumulatieve berekeningen. Senior developers zullen deze functies vaak gebruiken, maar voor beginners is de aanpak van Power BI toegankelijker.  

• Pivoteren en unpivoteren: Met Power Query kun je data rechtstreeks vanuit de UI met enkele klikken herstructureren. In de Qlik Data Load Editor gebruik je hiervoor Crosstable() of Generic Load, waarbij je in beide gevallen zelf de code moet schrijven. QlikView had vroeger een ingebouwde wizard voor unpivoteren in de scripteditor, maar in Qlik Sense is deze verplaatst naar de Data Manager.

Datamodel: de ruggengraat van je dashboard 

Het datamodel is het resultaat van je back-endtransformaties en vormt de basis voor je front-endvisualisaties. Hoewel beide tools gericht zijn op snelle, flexibele modellen, hanteren ze verschillende benaderingen. 

Qlik Sense – Associatief model 

Qlik koppelt tabellen automatisch op basis van veldnamen. Als het veld CustomerID voorkomt in zowel de tabel Sales als de tabel Customer, koppelt Qlik deze tabellen. Als het veld een andere naam heeft, moet je het in je script hernoemen.  

Qlik maakt ook synthetische sleutels wanneer meerdere velden met dezelfde naam in verschillende tabellen voorkomen. Je kunt deze beter vermijden door de velden te combineren tot één sleutel. 

Alle relaties in Qlik zijn bidirectioneel. Dit betekent dat je twee feitentabellen niet via gedeelde sleutels kunt filteren zonder een circulaire verwijzing te creëren, wat Qlik blokkeert. Om dit op te lossen, moet je het model vaak herstructureren door feitentabellen te combineren of dimensies te dupliceren. Anders dan Power BI kan Qlik ook veel-op-veelrelaties creëren zonder dat de ontwikkelaar dit direct opmerkt. Bij het bouwen van een datamodel wil je dit meestal voorkomen.  

Deze beperking kan frustrerend zijn voor ontwikkelaars, maar dwingt hen ook goed na te denken over het ontwerp van hun model. Daar hebben ze op de lange termijn profijt van. Het helpt je een kluwen van datamodelspaghetti te voorkomen, maar biedt geen garantie als je niet voldoende over het datamodel hebt nagedacht of te veel bedrijfsfuncties in één dashboard probeert onder te brengen.  

Qlik’s Associative Engine biedt meer voordelen dan alleen het koppelen van veldnamen, maar daar komen we in deel 3 van deze serie op terug. Voor datamodellering kunnen we concluderen dat deze krachtig is, maar ook discipline vereist in naamgevingsconventies en structuur. Die discipline is vooral belangrijk in grotere omgevingen, waar een goede architectuur, scriptconventies en herbruikbare datalagen het verschil kunnen maken tussen een schaalbaar Qlik-platform en technische schuld. Dit is een veelvoorkomend aandachtspunt in ons werk op het gebied van Qlik-consultancy.

Power BI – Semantisch model 

Power BI biedt een flexibele modelleeromgeving. Relaties tussen tabellen kun je handmatig aanmaken of automatisch laten voorstellen. Daarbij kun je tabellen via elk gewenst veld koppelen, ongeacht de naam ervan.

Je kunt ook het volgende definiëren: 

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

• Filterrichting (één richting of bidirectioneel) 

Dit doe je doorgaans in het deelvenster voor het datamodel in Power BI Desktop, dus na de transformatiestappen in Power Query.  

Met deze functies kun je modelleringsscenario’s opzetten waarin bijvoorbeeld meerdere feitentabellen door gedeelde dimensies worden gefilterd, zonder lussen te veroorzaken. Hoewel dit zeer krachtig kan zijn, heb ik ook situaties gezien waarin dit leidt tot datamodelspaghetti die bijzonder lastig te ontwarren is. In de meeste gevallen adviseer ik om ook in Power BI een sterschema te bouwen, zodat je datamodel robuust is en het aantal tussenstappen tussen tabellen zo klein mogelijk blijft.  

De modelweergave in Power BI Desktop.  

In Power BI kun je rapporten bouwen op basis van een semantisch model uit een ander rapport. Gebruikers scheiden vaak de front-end van de back-end, zodat meerdere front-endrapporten één semantisch model kunnen delen. Met Power BI kun je zelfs een rapport op meerdere semantische modellen bouwen.

Een functie die ik bijzonder waardeer, is Power BI’s visuele relatieweergave, waarin je de kardinaliteit en filterrichting in één oogopslag ziet. Je kunt deze expliciet definiëren. Als de data niet aan de verwachte relatie voldoet, bijvoorbeeld wanneer een veel-op-éénrelatie verandert in een veel-op-veelrelatie, zal Power BI een foutmelding geven. Zo wordt de ontwikkelaar gewaarschuwd voordat onjuiste data de eindgebruiker bereikt. 

Modelinspectie en datakwaliteit 

Power BI scheidt de modelweergave van de tabelweergave, zodat je: 

• Volledige tabellen kunt bekijken 

• Data kunt filteren en sorteren 

• Kolommen en metingen kunt inspecteren 

• Snel de datakwaliteit kunt controleren 

Hierdoor kun je jouw model eenvoudig valideren en problemen tijdens de ontwikkeling oplossen. 

In Qlik kun je tabellen vooraf bekijken in de Data Model Viewer. Deze weergave toont alleen de eerste 100 rijen en biedt geen ondersteuning voor filteren of sorteren.

Om iets aan te passen, moet je het script wijzigen. Voor een grondigere inspectie moet je vaak: 

• Een tijdelijk werkblad met een tabelobject toevoegen 

• Een aparte app gebruiken om bron- of doeltabellen te onderzoeken 

• Of in Qlik Client-Managed een externe QVD-viewer gebruiken 
  
  

De Qlik Data Model Viewer 

Conclusie: structuur versus flexibiliteit 

Wat de back-end- en datamodelleringslagen betreft, bieden zowel Qlik Sense als Power BI krachtige mogelijkheden, maar ze benaderen het vraagstuk vanuit heel verschillende invalshoeken. 

• Power BI onderscheidt zich door flexibiliteit, visueel relatiebeheer en functies voor foutdetectie. Het is toegankelijk en gemakkelijker te leren voor Excel-gebruikers of niet-technische gebruikers, maar de vergevingsgezinde modelleeromgeving kan ook tot rommelige transformaties leiden als die niet goed worden beheerd.
   

• Qlik Sense dwingt daarentegen structuur af via naamgevingsconventies en het associatieve model. Hoewel het een steilere leercurve heeft en de meestgebruikte omgeving voor datavoorbereiding geen visuele transformatiefuncties biedt, stimuleert het een helder, herbruikbaar en schaalbaar ontwerp, vooral bij het gebruik van QVD’s.  

Deel 3: Front-end & gebruikerservaring 

In deel 3 gaan we van de machinekamer naar de showroom: de front-end. De vergelijking gaat over:

• Visualisaties en interactiviteit 

• Expressietalen (DAX versus Qlik-expressies) 

• Prestaties en responsiviteit 

• Ontwikkelaarservaring en samenwerking 

• Eindgebruikerservaring en selfservicemogelijkheden 

Deel 3 laat zien waarom dezelfde data in Power BI en Qlik heel anders kan aanvoelen zodra je dashboards gaat bouwen en gebruiken.

Bekijk de volledige reeks:

Deel 1: Qlik vs. Power BI: Deel 1 – Een praktische vergelijking

Deel 2: Je bent hier

Deel 3: Qlik vs. Power BI: Deel 3 – Front-endontwikkeling & gebruikerservaring

Deel 4: Qlik vs. Power BI: Deel 4 – Interactie met eindgebruikers & integratie

More from the Bitmetric team