Semantisk lag i Power BI: 4 lag med samme struktur som en dataplatform

Et semantisk lag i Power BI kan have præcis samme struktur som en dataplatform på Microsoft Fabric. Microsoft beskriver selv medaljonarkitekturen som tre lag: bronze (raw), silver (enriched) og gold (curated). oneBC365’s Power Query-model har Base, Enriched, Curated og Model. Forskellen er, hvor lagene kører, og hvad det koster at drive dem.

Resumé og konklusion

• Base, Enriched og Curated svarer til bronze, silver og gold. Model-laget er serveringslaget. Samme ansvarsfordeling, samme rækkefølge, men bygget i Power Query inde i den semantiske model.
• Kun Model-tabellerne fylder. BC_-, ER_- og CU_-forespørgslerne evalueres under opdateringen og gemmes ikke. Der er ingen lakehouse at betale lagring for og ingen pipelines at overvåge.
• Nye datakilder følger samme mønster. En kilde som Dynamics 365 Sales får sin egen kæde af Base, Enriched og Curated, og de fælles dimensioner samles i Curated-laget.
• Power BI Pro sætter lofterne. 1 GB pr. semantisk model, otte planlagte opdateringer om dagen og to timer pr. opdatering. Realtid og andre forbrugere end Power BI kræver noget andet.
• Migrationsvejen er indbygget. Rammer I lofterne, kan lagene flyttes til Dataflows Gen2 eller en Fabric Lakehouse, mens rapporterne bliver stående.

Hvad et semantisk lag i Power BI består af

Mange tænker på den semantiske model som tabeller, relationer og DAX-mål. Det er den øverste del. Under den ligger Power Query, som henter, renser og samler data, før noget lander i modellen. Tilsammen er det hele vejen fra kildens API til det tal, brugeren eller agenten ser.

I en typisk Power BI-fil er Power Query en lang række forespørgsler uden orden. Det virker, indtil den første fejl skal findes. I en lagdelt model har hver forespørgsel et præfiks, der fortæller, hvilket lag den hører til, og hvert lag har én opgave. Det er samme disciplin som i en dataplatform, bare uden en separat platform.

De fire lag i oneBC365

Base (BC_): hent og intet andet

Der er én forespørgsel pr. API-endpoint. Alle kalder den samme delte hentefunktion med en erklæret kolonneliste, og felter, som API-siden ikke leverer, fyldes med null.

Ingen kolonner omdøbes, og der er ingen forretningslogik. Ændrer Business Central et felt, er det kun dette lag, der skal rettes.

Enriched (ER_): rens og standardisér

API-navne som customerPostingGroup bliver automatisk til Customer Posting Group. Manglende kolonner null-fyldes, før datatyperne sættes, og datonøgler som CalendarDateID tilføjes.

Til sidst får hver tabel en surrogatnøgle og en unknown-member-række med nøglen -1. Så lander en post på en slettet debitor stadig et sted.

Curated (CU_): gør forretningsklar

Her laves joins på surrogatnøgler, og her bygges tabeller, der ikke findes i Business Central. En valutakurstabel er et eksempel: én række pr. selskab, valuta og dag, så en valutakurs aldrig er tom.

Dimensionerne genereres fra én skabelon. Mange CU_-forespørgsler er blot en videreførelse af ER_-laget, og det er i orden.

Model: server til rapporter og agenter

Model-laget er partitionerne i over 100 modeltabeller med forretningsnavne som Customer og G/L Entry. Hver partition læser sin Curated-forespørgsel og sikrer til sidst, at alle forventede kolonner findes. Forretningsområder, kunden ikke bruger, indlæses som tomt skema. De store faktatabeller har incremental refresh med historik i årspartitioner, så kun de seneste måneder genindlæses ved hver opdatering. Det er det lag, Copilot og AI-agenter på tværs af systemer læser.

Semantisk lag i Power BI sammenlignet med bronze, silver og gold

Microsofts vejledning i medaljonarkitektur i Fabric beskriver bronze som data gemt præcis, som de ankommer, silver som rettet, standardiseret og uden dubletter, og gold som organiseret til rapporter. Læg beskrivelserne ved siden af Base, Enriched og Curated, og de er de samme.

Forskellen ligger i, hvor data bor. I en lakehouse gemmes hvert lag som Delta-tabeller i OneLake, og data flyttes mellem lagene af pipelines, notebooks eller materialized lake views. I det semantiske lag er BC_, ER_ og CU_ opskrifter, der køres under opdateringen. Kun resultatet i Model-laget gemmes.

Grafikken herunder stiller de to arkitekturer op lag for lag.

Hvad der spares med et semantisk lag i Power BI

Kapacitet. Lakehouses, warehouses, notebooks og pipelines kan kun oprettes i et workspace med en F-kapacitet, ifølge Microsofts licensoversigt. Det semantiske lag kører i et almindeligt Pro-workspace. Priserne på de to arkitekturer har vi gennemgået i Hvad koster det? Prisdimensioner mellem arkitekturerne.

Pipelines. Der er ingen orkestrering at bygge eller overvåge. Den planlagte opdatering i Power BI kører hele kæden i rækkefølge.

Lagring. Der gemmes ingen kopier af rådata, rensede data og forretningsklare data. Kun modeltabellerne, komprimeret.

Kompetencer. Det kræver M og DAX. Ikke Spark, Python, SQL-warehouse og Delta-tabeller ved siden af. Al M-kode i oneBC365 er kommenteret inline, så en BC-partner med Power BI-erfaring kan læse den. Det betyder noget for en SMV uden it-afdeling.

Nye datakilder i samme struktur

En dataplatform sælges ofte på, at den kan samle mange kilder. Det kan det semantiske lag også, efter samme opskrift, så længe kilderne er til at overskue: typisk Business Central og to-tre systemer mere. Skal I kombinere mere end 5-8 datakilder, bør I overveje en dataplatform, som vi beskriver i Hvornår er Power BI nok?. Skal Dynamics 365 Sales med, får den sin egen Base-forespørgsel pr. Dataverse-tabel, sit eget Enriched-lag med surrogatnøgler og unknown members, og Curated-laget samler kunden fra begge systemer i én dimension.

De fælles dimensioner er typisk kunde, vare, ressource eller medarbejder, dato og sag. Nøglen er den svære del: hvordan ved modellen, at en konto i CRM er en bestemt debitor i Business Central? Det behandler vi i Data fra flere systemer i Power BI: 6 spørgsmål ERP’et ikke kan svare på alene. Standardmodellen leveres med Business Central som kilde. Nye kilder er en udvidelse, som oneBC365 kan levere som en del af services. Den aftales og estimeres pr. kilde, og målet er, at de eksisterende rapporter virker uændret.

Sådan sætter du det op i Power BI

1. Giv hver forespørgsel et præfiks. Et præfiks pr. lag og pr. kilde, og en regel om, at præfikset skal passe til laget.
2. Saml gentagen logik i funktioner. Hentning, surrogatnøgler og null-fyldning skrives én gang som delte funktioner og kaldes fra alle forespørgsler.
3. Slå indlæsning fra på alt under Model-laget. Kun de endelige tabeller skal indlæses i modellen.
4. Tilføj incremental refresh på de store posttabeller. Parametrene RangeStart og RangeEnd skal findes, og datofilteret skal ligge i partitionen.

Hvad et semantisk lag i Power BI ikke løser

Power BI Pro har faste lofter. En semantisk model i et Pro-workspace må højst være 1 GB, jf. Microsoft Learn om store semantiske modeller. På Premium og Fabric kan grænsen hæves med large semantic model storage format.

Der kan planlægges otte opdateringer om dagen, og en opdatering skal være færdig på under to timer (fem timer på Premium), jf. Data refresh in Power BI. Med Premium, PPU eller Fabric-kapacitet er tallet 48 opdateringer om dagen.

Realtid er ikke muligt på Pro. Incremental refresh virker, men den realtidspartition med DirectQuery, der kan lægges oven på, kræver Premium eller PPU. Og data i det semantiske lag kan kun bruges gennem modellen. Skal et machine learning-projekt eller en anden applikation læse de rensede data, er de ikke gemt nogen steder.

Derfor er migrationsvejen vigtig. Fordi lagene har samme opgaver som i en dataplatform, kan de flyttes et ad gangen til Dataflows Gen2 eller en Fabric Lakehouse, mens modeltabellerne og rapporterne bliver stående. Se også tre signaler på, at I rammer grænsen.

Grafikken herunder viser lofterne på Pro, og hvad der flyttes, når et af dem rammes.

Sådan understøtter oneBC365 det

oneBC365 er bygget som et semantisk lag i Power BI med de fire lag beskrevet ovenfor: flere hundrede forespørgsler, delte funktioner og over 100 modeltabeller. Data hentes fra en read-only Business Central-extension via OData v4, og løsningen kører på Power BI Pro uden Fabric-kapacitet. Hele modellen ligger som Power BI-projekt i Git, og kunden ejer koden.

Arkitekturen er valgt, så I ikke skal betale for en dataplatform, før I har brug for den. Den dag volumen, realtid eller andre forbrugere kræver det, kan Power Query-lagene flyttes til Dataflows Gen2 eller en Fabric Lakehouse, mens rapporterne virker uændret. Og fordi modellen har beskrivelser, stjerneskema og entydige navne, er den samme model udgangspunktet for Copilot og andre AI-agenter.

Sådan kommer du i gang

1. Tjek jeres nuværende models størrelse. Se den i workspace-indstillingerne. Ligger den tæt på 1 GB, skal incremental refresh eller kapacitet på dagsordenen.
2. Tæl jeres opdateringer. Hvor mange gange om dagen har forretningen reelt brug for friske tal? Er svaret under otte, er Pro ikke flaskehalsen.
3. Sortér jeres Power Query-forespørgsler i lag. Markér hvilke der henter, hvilke der renser, og hvilke der samler. Det viser hurtigt, hvor logikken er spredt.
4. Skriv jeres næste datakilde ned. Notér hvilke dimensioner den deler med Business Central, og hvilken nøgle der binder dem.

Relaterede artikler

• AI-agenter på tværs af systemer: ét semantisk lag i stedet for en dataplatform
• Data fra flere systemer i Power BI: 6 spørgsmål ERP’et ikke kan svare på alene
• AI-agenter i Power BI-udvikling: sådan bygger vi oneBC365
• Hvad er en data platform? Microsoft Fabric forklaret
• Power BI Servicen: Hvad får man, og hvor går grænsen?

Vil I se, hvordan et semantisk lag i Power BI ser ud på jeres egne Business Central-tal? Book en demo, og se det live på 30 minutter.