Capacity en cost optimization in Fabric

Meet eerst, optimaliseer daarna

Installeer de Capacity Metrics-app voordat je iets anders doet. Zonder inzicht in welke items capaciteit verbruiken, is elke optimalisatie gokken. De verdeling is vrijwel altijd scheef: een handvol workloads verbruikt het leeuwendeel.

Isoleer productie van experimenten

Eén gedeelde capaciteit betekent dat een zwaar notebook-experiment je directierapportage kan vertragen. Minimaal twee capaciteiten (productie en overig) is de goedkoopste verzekering die er bestaat; pauzeer de niet-productiecapaciteit buiten werktijden.

De vier knoppen die er echt toe doen

1. Refresh-frequentie: de meeste datasets verversen vaker dan iemand ernaar kijkt. Halveer frequenties en wacht op klachten, die komen zelden.
2. Spark-jobs: verkeerde clusterinstellingen en niet-gecompacte tabellen maken jobs onnodig zwaar. Starter pools en autoscale zijn een begin, geen eindpunt.
3. Direct Lake in plaats van import: elke import-refresh is dubbel werk (lezen, comprimeren, kopiëren). Direct Lake elimineert dat voor geschikte modellen.
4. Realtime-ambities: het duurste misverstand. Vraag per dashboard welke beslissing er sneller door wordt genomen; meestal is het antwoord "geen".

Ken de kantelpunten in je SKU-keuze

Twee dingen die elke sizing-discussie sturen. Copilot in Fabric werkt vanaf F2 (elke betaalde SKU, niet op trial), maar let op: Copilot-verbruik telt als background job mee op je capaciteit en drukt op een kleine SKU relatief zwaar. Bij intensief Copilot-gebruik is een split-capacity-strategie met een aparte capaciteit voor Copilot het overwegen waard. En vanaf F64 mogen viewers Power BI-content bekijken zonder Pro-licentie; bij veel gebruikers is dat het grote kostenkantelpunt. Verder: kies voor stabiele productie een capacity reservation van een of drie jaar (aanzienlijk goedkoper dan pay-as-you-go; reken het actuele verschil na op de Fabric-pricingpagina) en houd dev en test op PAYG zodat je buiten kantooruren kunt pauzeren.

Smoothing is geen buffer maar uitstel

Fabric verdeelt pieken over de tijd (smoothing en bursting). Dat maakt het platform soepel, maar het maskeert ook oververbruik tot het te laat is. Throttling treedt vervolgens in fasen op: eerst vertraging van interactieve queries, dan afwijzing van interactieve, dan afwijzing van background jobs. Te klein starten en constant throttlen is een klassieke fout, net als structureel overvragen en de rekening als vertraagde throttling terugkrijgen. Behandel langdurige belasting boven de tachtig procent als incident.

Maak kosten een ontwerpcriterium

Bespreek capaciteitsverbruik in design reviews, niet pas bij de factuur. De goedkoopste optimalisatie is de workload die je niet bouwt, en de op één na goedkoopste is dezelfde workload met een eerlijke latency-eis.