Data Platform Next Step 2026 briefing:
Vi var stolte af at være premium sponsor på Data Platform Next Step 2026;
En konference fyldt med inspirerende, lærerige og fremtidsorienterede oplæg.
Her har vi samlet et kort uddrag af tre sessioner, som særligt fangede vores opmærksomhed, og som giver værdifulde indsigter, du ikke vil gå glip af.
1. Stijn Wynants: OneLake Security: A Deep Dive.
Ved denne session blev baggrunden for OneLake Security pakket ud; hvilke elementer er der er i OneLake’n, og hvordan almindelig sikkerhed fungerer på workspace niveau. OneLake Security kan styrer sikkerheden, men rettigheder givet på workspace eller objekt niveau kan gennemhulle et ellers finmasket sikkerheds-setup i Onelake security. Det er tydeligt, at sikkerhed fortsat er kompleks og kræver opmærksomhed og omtanke.
2. Benni De Jagere: Mastering Fabric Capacities: Advanced Strategies for Planning, Monitoring, and Scaling &
Kevin Thomas: Deep insights in your Microsoft Fabric landscape with FUAM
Hvem har overblik over, hvad der sker, og hvorfor svarer rapporterne ikke? Samt hvad kan man gøre ved det?
Med udgangspunkt i Microsofts Fabric Capacity Metrics er det muligt retrospektivt at få indsigt i, hvad der er sket, samt at identificere de specifikke forespørgsler, der forårsager problemer. Capacity Metrics er ikke det mest intuitive værktøj, men det bør alligevel være det første go-to værktøj, når man skal skabe overblik og arbejde med fejlfinding. FUAM er langt mere udbygget og dermed også mere komplekst. Til gengæld kan det give et samlet overblik (selv over store installationer), og samtidig gøre det muligt at dykke ned i de problematiske forespørgsler og dataprocesser.
Et andet spørgsmål er naturligvis, hvad man så gør ved problemerne. Det vigtigste er først at få identificeret de processer, der skaber problemerne, typisk fordi kapaciteten “burster”, efterfølgende throttler og til sidst afviser opgaver som fx visning af rapporter eller opdatering af data. Når problemerne er identificeret, kan de flyttes til en anden kapacitet, så de ikke længere påvirker den kritiske drift. Dette kræver dog, at man på forhånd har tænkt over sin workspace-arkitektur, så det er muligt at adskille forskellige workloads (fx ved at have separate workspaces til udvikling, test, produktion og analyse).
Man kan også sikre, at produktionsmiljøet har sin egen kapacitet for at beskytte mod utilsigtede forespørgsler, der ellers kan dræne ressourcerne. Derudover er det muligt at reservere en del af kapaciteten til ad hoc-forespørgsler ved at begrænse, hvor meget background operations må fylde, ved hjælp af Surge Protection.
Endelig kan man vælge en mere direkte løsning ved at betale sig fra det ved at enable Capacity Overage. Capacity Overage konfigureres pr. kapacitet, mens Surge Protection kan indstilles både pr. kapacitet og på workspace-niveau.
3. Tino Tereshko: Keynote: Fabric Data Warehouse's Ultra-Modern Architecture
De vigtigste take-aways:
· Med en distribueret platform er det dyrt at schufle data mellem noder og
· Cash Cooldown for at udnytte cashede data bedre.
· Udnytte GPU til processering i Fabric Data Warehouse
Keynoten var specifikt rettet mod Warehouse i Fabric, men flere af emnerne er også relevante for Lakehouse. Der var blandt andet et interessant afsnit om, hvordan Query Optimizer fungerer på en distributed compute platform: Ikke overraskende er den store udfordring i virkeligheden at få data distribueret til noderne på en hensigtsmæssig måde, så de eksempelvis kan joines effektivt. Her spiller kendskab til både data og partitionering en afgørende rolle. Det er for eksempel vigtigt at tilstræbe, at partitionerne matcher antallet af compute-noder, og at data i partitionerne er fordelt på en hensigtsmæssig måde. Samtidig arbejder Microsoft på at holde data i nodens compute cache så længe som muligt for at undgå at skulle distribuere det samme data for mange gange.
En anden nyhed fra Microsoft er, at man fremadrettet vil udnytte GPU’er til processering i Data Warehouse. Det er en feature, man skal enable i forbindelse med afvikling af queries, og som medfører lidt ekstra CU. Til gengæld viser test, at data, konservativt sat, kan processeres 20 gange hurtigere på F64.
Er du interesseret i at høre mere om, hvordan vi kan hjælpe, så skriv til os på: info@dataon.dk