Het Associatieve Datamodel van Qlik

Door Patrick van den Bemt, Sr. Support Specialist BI

Er wordt mij vaak gevraagd hoe het kan dat Qlik zo snel de gevraagde informatie laat zien op basis van één klik in het dashboard. Mijn antwoord is dat dit komt door het associatieve datamodel van Qlik. En vervolgens ben ik de rest van de tijd bezig om dat uit te leggen. In dit blog probeer ik duidelijk te maken wat het associatieve datamodel van Qlik inhoudt en wat dat kan betekenen voor de keuzes die je maakt bij het ontwerpen van je datamodel.

Het model is gebaseerd op het uitgangspunt dat elk datapunt in elk veld van een tabel is geassocieerd met elk ander datapunt waar dan ook in het volledige schema. Deze onderlinge afhankelijkheid is de reden waardoor Qlik zo snel alle data kan filteren. Maar hoe wordt deze onderlinge afhankelijkheid bereikt, hoe werkt het en welke technieken worden gebruikt?

Onder de motorkap wordt, met de komst van Qlik Sense en Qlikview 12.x, gebruik gemaakt van de QIX engine. De QIX Engine bestaat uit zes engines die allemaal interactie hebben met het zevende element, de QIX Internal Database. Elke engine heeft zijn eigen rol, maar in het hart staat deze interne database.

In dit blog vertel ik u hier graag wat meer over, zodat u deze kennis kunt gebruiken bij het maken van keuzes voor uw eigen datamodel.

QIX Internal Database

De QIX Internal Database drijft op vier basisprincipes: Data, Symbols, State Vectors en Cache.

Data
De data wordt ingelezen vanuit een “normale” bron tabel via de Script Engine. In Qlik wordt deze opgeslagen als een geïndexeerde binaire code. Hierbij wordt in de data tabel van Qlik geen echte waarden opgeslagen, maar alleen verwijzingen naar de Symbol tabellen waarin de unieke waarden staan. Zo is in onderstaande Qlik data tabel het product “Bike Helmet” uit de bron tabel gereduceerd tot code 000.

Symbols
Voor elke kolom uit de originele tabel is er nu een aparte Symbol tabel met daarin een geïndexeerde binaire code voor elke unieke waarde voor een veld uit de Data tabel. In het geval van de kolom “Product” zijn dat dus vijf unieke waardes, maar voor de kolom “In Stock” zijn er maar twee unieke waardes “Yes” en “No”. Via de binaire code is de waarde daarmee “gekoppeld” aan de Qlik Data tabel. Zo zie je bij de originele regel voor het product “Bike Helmet” dat deze op voorraad was en dus heeft de Data tabel daar de binaire waarde 0 die overeenkomt met de waarde “Yes” in de Symbol tabel voor de kolom “In Stock”.

Samen wordt dit de Compressed Binary Data Storage genoemd. Het gevolg van deze methode is dat de Data tabel extreem compact is. Op basis van deze binaire code worden de tabellen gekoppeld op sleutelvelden en daarmee is elk datapunt in elk veld van een tabel geassocieerd met elk ander datapunt waar dan ook in het volledige schema.

Wat zijn de winstpunten van deze kennis?

Hoe meer unieke waarden hoe langer de binaire code wordt en hoe meer rijen er komen. Probeer het aantal unieke waarden daarom zo klein mogelijk te houden. Bijvoorbeeld door Key velden en ID’s die niet langer gebruikt worden te verwijderen. Maar ook door velden uit de bron die niet gebruikt worden gewoon niet in te laden in je Qlik model.

Daarnaast kun je het aantal unieke rijen verminderen door te kijken wat je echt nodig hebt van een veld. Bijvoorbeeld van een datum/tijd veld kun je beter twee velden maken met datum en een apart veld voor de tijd. Dan heb je voor het tijd veld maar één keer alle waardes die mogelijk zijn op een dag nodig en niet bij elke datum weer opnieuw alle uren/minuten/secondes. Bedenk ook wat je laagste niveau is van je tijd. Kun je toe met alleen uren/minuten dan zijn er 1440 unieke waardes op een dag. Maar als je daar seconde bij doet worden dat er al 86400 en bij milliseconde 86400000. Dus gebruik van een tijd veld met hh:mm:ss:xxxx alleen de hh:mm. Dit scheelt in RAM en CPU gebruik.

Probeer ook de lengte van een waarde zo klein mogelijk te houden in de Symbol tabel. Hoe langer/groter het veld hoe meer RAM er gebruikt wordt. Gebruik bijvoorbeeld de functie Autonumber om de waarde eerst zelf al te indexeren v.b. Autonumber( ProductID & ’|’ & CustomerID & ’|’ & Date ).

State Vectors
Het principe waarmee Qlik de waarden filtert die getoond worden op het scherm heeft te maken met Selection (Geselecteerd of Niet geselecteerd) en State (Mogelijk of Niet mogelijk). Deze zijn onafhankelijk van elkaar waarmee er uiteindelijk vier mogelijke opties (kleuren) zijn: Geselecteerd, Geselecteerd uitgesloten, Mogelijk en Uitgesloten. De kleur (Color) bepaalt uiteindelijk hoe het veld weergegeven wordt in een Qlik document.

In bovenstaande voorbeeld heeft de gebruiker gekozen voor een “List Price” van 20 en 30, maar ook dat het “In Stock” moet zijn. Dus voor de drie kolommen uit de bron tabel is bij “In Stock” de waarde “Yes” groen van kleur. Dat geeft dus aan dat deze waarde geselecteerd is en mogelijk. Voor “List Price” is de waarde 20 groen, dus mogelijk en geselecteerd. De waarde 30 echter is wel geselecteerd, maar niet mogelijk omdat deze in de rij met “In Stock = No” staat (Selected excluded). Deze zal in de resultaten wel direct onder de groene geselecteerde waarde staan, maar in het grijs. Het product “Bike Helmet” is niet geselecteerd maar wel mogelijk en daarom wit van kleur.

Bij elke klik zullen de State en Color voor elke veldwaarde berekend worden, dit gebeurt via de Logical Inference Engine. Deze statussen worden bepaald op basis van de eerder genoemde Symbol tabellen. Zo kun je hieronder zien dat het product “Bike Helmet” wel de status 1 heeft (is mogelijk) in de “Product” symbol tabel, maar dat deze niet geselecteerd is. Terwijl in de “List Price” symbol tabel de waarde 20 en 30 geselecteerd zijn, maar alleen waarde 20 is ook mogelijk en dus status 1 heeft.

Voor de gehele Data tabel heeft alleen de eerste rij State = 1. Bij berekeningen zouden dus ook alleen deze waarden meegenomen worden. De State wordt opgeslagen in de State Vectors.

Deze evaluatie op basis van State en Color propageert zich van tabel naar tabel door het gehele datamodel en zo wordt alleen getoond wat relevant of interessant is. Dit is de kracht van het Qlik associatieve data model!

Cache
Qlik maakt gebruik van de cache om selecties (State Vectors) die eerder al gedaan zijn te onthouden. Daarmee kan dus nog sneller de Logical Interference bepaald worden en kan de berekening direct vanuit de cache teruggegeven worden. Dus meer RAM geheugen op de server zal resulteren in meer cache en dus meer mogelijke selecties die al berekend zijn.

Samenvatting

QIX Internal Database drijft op vier basisprincipes: Data, Symbols, State Vectors en Cache. Begrijpen van de werking van de QIX Internal Database geeft aanknopingspunten waarmee je een betere opzet van je datamodel kunt maken. Beperk bijvoorbeeld het aantal unieke waarden in een tabel en houdt de veldlengte ook zo klein mogelijk. Daarnaast helpt meer RAM op de server de cache functie van de QIX Engine en daarmee wordt de rekentijd verkort.

In een volgend blog zal ik ingaan op de Calculation Engine en de winst die te behalen is wanneer je het mechanisme daarachter begrijpt.

Meer informatie?

Voor vragen en advies over onder andere Qlik kunt u contact opnemen met onze BI Servicedesk via support.bi.nl@axians.com of via telefoonnummer 088 – 597 55 59. We helpen u graag!

Axians kan u via een Health Check snel inzicht bieden in de status van uw Qlik omgeving.

Handige links

Bezoek http://help.qlik.com/en-US/sense/September2017/Content/Home.htm of http://help.qlik.com/en-US/qlikview/12.1/Content/Home.htm voor de help pagina’s van de laatste versies van QlikView en Qlik Sense.

Op de Qlik community https://community.qlik.com/welcome is ook veel informatie te vinden. Deze community helpt elkaar en ook de Qlik medewerkers zelf zijn zeer actief op dit platform. Met een gratis account is het mogelijk om ook vragen te stellen.