Metrics layer (metriekenlaag)

Wat is een metrics layer?

Een metrics layer is de plek waar je bedrijfscijfers zoals omzet, actieve klanten of churn een keer vastlegt, in code, zodat elk rapport, elk dashboard, elke notebook en elke AI-assistent daarna hetzelfde getal krijgt. In plaats van de berekening van "omzet" telkens opnieuw in te typen in Power BI, in een Excel en in een los SQL-script, staat ze op een centrale plaats en vraagt elk gereedschap ze daar op.

Je hoort ook de namen semantic layer en metrics store voor hetzelfde idee. De metrics layer zit tussen je data warehouse en de tools die de cijfers tonen. Hij bewaart geen data zelf, hij bewaart de definities en de berekeningen, en zet die om in een query op het warehouse zodra iemand een cijfer opvraagt.

Vergelijk het met een gedeeld receptenboek voor een restaurantketen. De data in je warehouse is de voorraad, het receptenboek legt vast hoe je een gerecht maakt. Zonder dat boek kookt elke keuken zijn eigen versie en smaakt hetzelfde gerecht overal anders.

Welk probleem lost een metrics layer op?

Zonder centrale definitie leeft "omzet" op evenveel plekken als er tools zijn. Iemand berekent ze in Power BI met een DAX-measure, iemand anders in een Excel-formule, een derde in een los SQL-script. De ene trekt de teruggestuurde bestellingen af, de andere niet. Op de directievergadering staan er dan drie omzetcijfers op tafel en gaat het gesprek over wiens cijfer klopt in plaats van over de zaak.

Een metrics layer haalt die definitie weg uit de rapportlaag en zet ze in de modellaag. dbt Labs verwoordt de winst zo: verandert een definitie, dan wordt ze overal vernieuwd waar ze wordt opgeroepen, en krijg je consistentie over al je tools. Een plek aanpassen volstaat, elk rapport volgt. Zo is een metrics layer een route naar een single source of truth voor je cijfers.

Hoe werkt een metrics layer?

Een metrics layer bestaat uit twee bouwstenen bovenop de tabellen in je warehouse.

Metric-definities. Elke metric krijgt een naam en een berekening, meestal in een tekstbestand (vaak YAML) dat mee in versiebeheer zit. "Omzet" wordt bijvoorbeeld de som van de orderbedragen min de terugbetalingen. De definitie staat in code, dus je kan ze reviewen, testen en terugdraaien zoals elke andere code.

Dimensies. Dat zijn de manieren waarop je een metric wil opsplitsen: per maand, per regio, per productlijn, per verkoper. De metrics layer weet welke dimensies bij welke metric horen, zodat "omzet per regio per kwartaal" een geldige vraag is die overal hetzelfde antwoord geeft. Dat sluit rechtstreeks aan bij dimensioneel modelleren: de metric leunt op de feiten- en dimensietabellen van je sterschema.

Een tool vraagt een cijfer op via een API of een SQL-achtige interface. De metrics layer vertaalt die vraag naar de juiste query, stuurt ze naar het warehouse en geeft het resultaat terug. Cube biedt bijvoorbeeld een SQL-interface die Postgres-compatibel is en SQL uitbreidt met een MEASURE-functie, plus een REST- en een GraphQL-API. De dbt Semantic Layer wordt bevraagd via een GraphQL-API, een JDBC-driver en een Python-SDK. Het getal wordt telkens door het warehouse berekend, maar de definitie komt uit een bron.

Voorbeeld: een definitie van "actieve klant"

Stel dat "actieve klant" bij jullie betekent: een klant met minstens een bestelling in de voorbije 90 dagen. Je legt die regel een keer vast in de metrics layer, samen met de dimensies regio en maand.

Daarna gebeurt dit:

• Het sales-dashboard in Power BI toont actieve klanten per regio.

• Een finance-rapport in een spreadsheet trekt hetzelfde cijfer per maand.

• Een analist rekent in een notebook verder op dezelfde metric.

• Een AI-assistent die op de data zit, gebruikt exact dezelfde definitie.

Beslist het team later dat de grens 60 dagen wordt in plaats van 90, dan pas je die ene regel aan. De vier tools tonen meteen het nieuwe cijfer, zonder dat iemand vier keer een formule moet gaan aanpassen.

Metrics layer versus Power BI semantic model

Wie met Power BI werkt, heeft eigenlijk al een semantische laag. Een semantisch model in Power BI bevat je relaties en je measures in DAX, en elk rapport dat erop draait krijgt dezelfde cijfers. In die zin is het semantisch model de metrics layer van de Microsoft-stack.

Het verschil zit in het bereik. Een Power BI-model is gebouwd om Power BI-rapporten en Excel te bedienen, en tools die de onderliggende Analysis Services-taal spreken. Een aparte metrics layer zoals de dbt Semantic Layer, Cube of LookML (de modeltaal van Looker) mikt bewust op tool-neutraliteit: eender welke BI-tool, notebook, spreadsheet of AI-agent die SQL spreekt of de API aanroept, krijgt dezelfde metric. Werk je volledig binnen Microsoft, dan volstaat het semantisch model vaak. Draai je meerdere BI-tools naast elkaar, dan wint een neutrale metrics layer.

Metrics layer en headless BI

Een metrics layer is net wat headless BI mogelijk maakt. "Headless" betekent dat de cijferdefinities losgekoppeld zijn van de tool die ze toont. De visualisatie is inwisselbaar: een dashboard, een spreadsheet, een e-mailrapport of een AI-agent haalt allemaal dezelfde cijfers uit dezelfde bron.

Zo zit je niet vast aan een BI-tool. Wil je van tool wisselen of er een tweede naast zetten, dan blijven je definities staan waar ze staan. De cijfers verhuizen niet mee, want ze woonden nooit in de tool.

Waar moet je op letten bij een metrics layer?

De definities uitvechten blijft mensenwerk. De tool dwingt niet af wat "actieve klant" betekent. Zolang sales en finance daar niet over akkoord zijn, verplaatst een metrics layer de discussie alleen maar naar de code. De afspraak komt eerst.

Het is een extra laag om te onderhouden. Verandert een tabel in je warehouse van naam of structuur, dan moet de metrics layer mee. Zonder eigenaar veroudert de definitielaag en klopt na een jaar de helft niet meer.

Niet elk cijfer hoort erin. Voor een eenmalige analyse is een centrale metric overkill. Hou de metrics layer voor de KPI's waar het vaakst discussie over is en die in meerdere tools terugkomen.