Microsoft Fabric Capacity richtig dimensionieren: Kosten vs. Leistung

Microsoft Fabric vereint Data Engineering, Warehousing, Echtzeitanalyse und Power BI auf einem einzigen Kapazitätsmodell. Das ist elegant für die Beschaffung und gnadenlos für die Kostensteuerung: Jeder Workload im Bestand bezieht nun aus einem gemeinsamen Rechenpool, abgerechnet als Fabric F-SKU mit fester Größe. Stimmt die Dimensionierung, zahlen Sie eine vorhersehbare monatliche Gebühr für eine einheitliche Plattform. Stimmt sie nicht, verbrennen Sie entweder Budget für ungenutzte Kapazität oder erleben, wie interaktive Berichte im Montagmorgen-Ansturm gedrosselt werden.

Dieser Beitrag beschreibt das Dimensionierungs-Framework, das wir bei CC Conceptualise nutzen, wenn wir Kunden auf Fabric onboarden — fundiert in der tatsächlichen Mechanik von Capacity Units, Smoothing und Throttling, nicht in Hersteller-Marketing.

TL;DR / Die wichtigsten Erkenntnisse

Eine Fabric Capacity Unit (CU) ist die gemeinsame Recheneinheit; Ihre F-SKU legt fest, wie viele CUs Sie erhalten, und jeder Workload zieht aus demselben Pool.
Fabric rechnet keinen Mehrverbrauch ab — es drosselt. Dimensionierung bedeutet also, anhaltenden Mehrverbrauch zu vermeiden, nicht eine höhere Rechnung.
Dimensionieren Sie auf den geglätteten 24-Stunden-Durchschnitt, nicht auf die Rohspitze, denn Fabric glättet und burstet. So betreiben Sie eine kleinere SKU, als der momentane Bedarf nahelegt.
F64 ist der ökonomische Wendepunkt: Sie schaltet kostenlose Power-BI-Nutzung und Copilot frei, weshalb sich die Pro-CU-Rechnung an dieser Stelle stark verändert.
CU-Optimierung schlägt SKU-Vergrößerung: Der meiste Mehrverbrauch stammt aus wenigen ineffizienten Elementen, die ohne größere Kapazität behoben werden können.

Wie Fabric-Kapazität tatsächlich abrechnet

Bevor Sie irgendetwas dimensionieren, müssen Sie drei Mechaniken verinnerlichen, die Fabric anders verhalten lassen als Pay-per-Query-Plattformen wie BigQuery oder serverless Synapse.

1. Ein Pool, alle Workloads. Eine einzige F-SKU versorgt Spark-Notebooks, Pipelines, Dataflows Gen2, den SQL-Analyse-Endpunkt, Abfragen semantischer Modelle, Eventstream/Eventhouse und Copilot. Es gibt kein Pro-Dienst-Metering. Deshalb kann ein außer Kontrolle geratener Spark-Job das Dashboard einer Führungskraft beeinträchtigen — beide teilen sich CUs.

2. Smoothing. Interaktive Operationen werden über wenige Minuten geglättet; Hintergrundoperationen (geplante Aktualisierungen, Pipeline-Läufe, Spark-Batches) werden über ein rollierendes 24-Stunden-Fenster verteilt. Fabric verzeiht daher spitze Lasten: Ein Job, der kurzzeitig das Vierfache Ihrer Kapazität benötigt, ist unproblematisch, solange seine über 24 Stunden verteilten Kosten in Ihren Pool passen.

3. Throttling statt Mehrverbrauch. Übersteigt der geglättete Verbrauch 100 Prozent der Kapazität, sammelt Fabric "Carryforward"-Schulden an und wendet eskalierende Strafen an:

Aufgelaufener Mehrverbrauch	Effekt	Was Nutzer erleben
Bis ~10 Min. künftige Schuld	Interaktive Verzögerung	Berichte laden langsam (zusätzliche Sekunden)
~10–60 Min. künftige Schuld	Interaktive Ablehnung	Neue Abfragen abgelehnt; Dashboards fehlerhaft
Über ~24 Std. künftige Schuld	Hintergrund-Ablehnung	Geplante Jobs und Aktualisierungen pausieren

Die praktische Konsequenz: Sie können sich aus einem schlechten Tag nicht mit Mehrverbrauch herauskaufen. Entweder Sie haben korrekt dimensioniert, Surge Protection/Autoscale aktiviert — oder Ihre Nutzer spüren es. Das ist die größte mentale Umstellung für Teams, die von verbrauchsabgerechneten Plattformen kommen.

Die Dimensionierungsmethode, die wir nutzen

Fabric zu dimensionieren ist eine empirische Übung, keine Tabellenkalkulation. Die obige Mechanik bedeutet, dass Sie den CU-Bedarf nicht zuverlässig aus Zeilenzahlen oder Nutzeranzahlen ableiten können. Unsere Methode:

Loading diagram...

Den Workload-Mix inventarisieren. Erfassen Sie jedes Artefakt, das auf der Kapazität läuft: Spark-Jobs, Pipelines, semantische Modelle und ihre Aktualisierungspläne, SQL-Endpunkte, Echtzeit-Streams und Berichts-Parallelität. Markieren Sie jedes als interaktiv oder Hintergrund.
Eine Start-SKU konservativ schätzen. Für BI-lastige Bestände mit breiter Betrachter-Population ist F64 meist die Untergrenze wegen ihrer Lizenzökonomie (siehe unten). Für Data-Engineering-Pilotprojekte starten Sie bei F8–F32.
Eine repräsentative Last 2–4 Wochen auf Pay-as-you-go fahren, niemals auf einer Reservierung. Beziehen Sie einen Monatsabschluss oder ein Spitzenereignis ein, falls Ihr Geschäft eines hat.
Die Microsoft Fabric Capacity Metrics App lesen. Sie ist die einzige verlässliche Quelle. Betrachten Sie die Auslastungs-Timepoint-Ansicht, die verbrauchsstärksten Operationen und — entscheidend — etwaige Carryforward-/Throttling-Ereignisse.
Herunterregeln, dann festlegen. Wenn Sie nie an Throttling herankamen und die Auslastung deutlich unter der Kapazität lag, gehen Sie eine Stufe herunter. Erst wenn der Bedarf stabil ist, kaufen Sie eine Reservierung.

Schritt 4 betrachten wir als Kern des Projekts. Bei einem aktuellen Fabric-Onboarding für einen mittelständischen Fertiger zeigte die Metrics App, dass zwei überdimensionierte Dataflow-Gen2-Aktualisierungen den Großteil des Hintergrund-CU-Verbrauchs ausmachten — beide stündlich, obwohl täglich gereicht hätte. Die Korrektur des Zeitplans erlaubte dem Kunden, auf F64 zu bleiben, statt auf F128 zu springen, und sparte rund die Hälfte der jährlichen Plattformkosten. Das ist CU-Optimierung, die SKU-Vergrößerung in der Praxis schlägt. Dieselbe Disziplin trägt unsere umfassendere Cloud-Kostenarbeit.

Die richtige F-SKU wählen

F-SKUs skalieren linear in CUs und Preis — F2, F4, F8, F16, F32, F64, F128, F256 und höher — jede Stufe verdoppelt Kapazität und Kosten. Doch die Kostenkurve ist nicht glatt, denn die Lizenzierung bricht bei F64.

SKU-Band	CUs	Typische Eignung	Power BI / Copilot
F2–F32	2–32	Data-Engineering-Pilots, Dev/Test, Single-Team-Analyse	Power BI Pro Pro-Nutzer-Lizenzen für Betrachter weiterhin nötig; kein Copilot
F64	64	Abteilungs- bis Unternehmens-BI mit breiter Betrachterbasis	Kostenlose Power-BI-Nutzung für Konsumenten; Copilot in Fabric aktiviert
F128–F256+	128–256+	Große Unternehmensbestände, hohe Parallelität, mehrere Geschäftsbereiche	Wie F64, plus Spielraum für Parallelität

Die F64-Klippe dominiert die Entscheidung. Unterhalb von F64 benötigt jeder Power-BI-Berichtsbetrachter eine Pro-Nutzer-Pro-Lizenz. Ab F64 konsumieren Betrachter Berichte kostenlos. Bei einem Bestand mit Hunderten Betrachtern können die Pro-Nutzer-Lizenzkosten die Differenz zwischen etwa F32 und F64 weit übersteigen — wodurch F64 trotz größerer SKU insgesamt günstiger wird. Modellieren Sie stets die Gesamtbetriebskosten, Kapazität plus Lizenzierung, nicht nur den SKU-Listenpreis.

Pay-as-you-go vs. Reservierung

Dimension	Pay-as-you-go	Einjahres-Reservierung
Rabatt	Keiner (Basistarif)	~40 % unter PAYG
Flexibilität	Stündlich pausieren/fortsetzen; frei skalieren	Feste Stufe; nicht pausierbar für Gutschrift
Beste Eignung	Erkundung, spitze/Nicht-Prod, pausierbare Workloads	Stabile, vorhersehbare Produktionsbasis

Das ausgereifte Muster ist eine reservierte Produktionsbasis (Ihre Always-on-Stufe) plus eine separate Pay-as-you-go-Kapazität für Entwicklung, Test und Burst — außerhalb der Geschäftszeiten pausiert. Die Isolierung der Nicht-Produktion schützt zudem die Produktion vor Noisy-Neighbour-Throttling. Dieselbe Commitment-Logik, die wir generell auf Compute anwenden, behandeln wir in unserem Deep Dive zu Reserved Instances vs. Savings Plans vs. Spot.

CU-Optimierung: Weniger ausgeben ohne Vergrößerung

Sobald die SKU grob stimmt, ist die wiederkehrende Disziplin, den Verbrauch effizient zu halten. Nach Wirkung geordnet:

Die Schwergewichte finden. Die Capacity Metrics App reiht Operationen nach CU-Sekunden. Fast immer dominiert eine kleine Zahl von Elementen. Beheben Sie diese, bevor Sie die SKU anfassen.
Hintergrundjobs richtig dimensionieren und planen. Verlagern Sie schwere Spark-Batches und Aktualisierungen in lastarme Fenster, damit Smoothing sie absorbiert. Stellen Sie zu häufige Aktualisierungen auf die Kadenz um, die das Geschäft tatsächlich braucht.
Spark optimieren. Nutzen Sie angemessen dimensionierte Pools, aktivieren Sie die native Ausführungs-Engine und vermeiden Sie Tiny-File- und Skew-Probleme, die den CU-Verbrauch aufblähen. Eine Medallion-Architektur mit gut partitionierten Delta-Tabellen zahlt sich hier aus — siehe unsere Hinweise zu kostenbewussten Schichtungsmustern.
Semantische Modelle bereinigen. Inkrementelle Aktualisierung, Abfragereduktion und das Entfernen ungenutzter Spalten/Measures senken sowohl Aktualisierungs- als auch Abfrage-CU-Verbrauch — der größte interaktive Verbraucher in BI-lastigen Beständen.
Anomalien kontinuierlich überwachen. Eine neue Pipeline oder ein außer Kontrolle geratenes Copilot-Muster kann Ihr Profil über Nacht verändern. Behandeln Sie Kapazität wie jede andere Kostenfläche und richten Sie Kostenanomalie-Erkennung ein, damit eine Regression in Stunden auffällt, nicht erst zum Monatsende.

Ein Hinweis zu KI-Workloads

Copilot und KI-Funktionen in Fabric verbrauchen CUs wie jede andere Operation, und KI-intensive Analysen können Ihr Profil schnell verschieben. Wenn Sie Fabric mit GPU-gestütztem Modelltraining oder Inferenz andernorts in Azure kombinieren, ist die Kostensteuerung verwandt, aber eigenständig — wir behandeln sie in GPU- und KI-Workload-Kostensteuerung auf Azure. Das Fabric-spezifische Risiko ist, dass die Copilot-Nachfrage spitz und nutzergetrieben ist, weshalb Sie Surge Protection aktiviert lassen sollten, statt von einer statischen Spitze auszugehen.

Surge Protection und Autoscale

Zwei Leitplanken verringern die Folgen einer Fehldimensionierung:

Surge Protection erlaubt zu begrenzen, wie viel Hintergrundarbeit laufen darf, wenn die Kapazität bereits ausgelastet ist, und schützt interaktive Nutzer davor, von Batch-Jobs gedrosselt zu werden. Aktivieren Sie sie früh; sie ist die günstigste Versicherung gegen den Montagmorgen-Dashboard-Ausfall.
Autoscale (für Spark) und Fabric-Autoscale-Abrechnung lassen spitzes Compute für bestimmte Szenarien metered über die Basis-SKU hinaus skalieren und tauschen Vorhersehbarkeit gegen Elastizität. Nützlich für wirklich spitze, unvorhersehbare Data-Engineering-Spitzen — aber es führt variable Kosten wieder ein, also steuern Sie es mit Policy-as-Code-Kostenleitplanken.

Häufige Dimensionierungsfehler

Auf die Spitze dimensionieren statt auf den geglätteten Durchschnitt. Sie zahlen zu viel, weil Fabric die Spitze ohnehin absorbiert hätte.
Die F64-Lizenzklippe ignorieren. Eine "günstigere" F32 kann mehr kosten, sobald Pro-Nutzer-Pro-Lizenzen hinzukommen.
Eine Reservierung vor Beobachtung der realen Last abschließen. Sie binden sich an die falsche Stufe.
Dev, Test und Prod auf einer Kapazität mischen. Noisy Neighbours drosseln die Produktion, und Sie können nichts pausieren.
Dimensionierung als einmalige Aufgabe behandeln. Der Verbrauch driftet; ohne kontinuierliche Metrikprüfung entdecken Sie das Problem während eines Ausfalls.

Fazit

Fabric-Kapazitätsdimensionierung ist keine Taschenrechner-Übung — sie ist eine empirische, iterative Disziplin, fundiert darin, wie CUs, Smoothing und Throttling tatsächlich funktionieren. Dimensionieren Sie auf den geglätteten Durchschnitt, respektieren Sie die F64-Klippe, optimieren Sie den Verbrauch vor der Vergrößerung und schützen Sie interaktive Nutzer mit Surge Protection. Gut gemacht, erhalten Sie eine einheitliche Analyseplattform zu vorhersehbaren, vertretbaren Kosten.

Wenn Sie einen zweiten Blick auf einen Fabric-Kapazitätsplan, ein Dimensionierungsmodell oder eine CU-Optimierungsprüfung wünschen: Unsere zertifizierten Architekten leisten diese Arbeit regelmäßig. Erfahren Sie mehr über unsere Cloud-Architektur- und Kostenengineering-Leistungen.

FAQ

Was ist eine Fabric Capacity Unit (CU)?

Eine Capacity Unit (CU) ist die abstrakte Recheneinheit von Microsoft Fabric. Jede Operation — Spark-Jobs, Dataflows, Abfragen semantischer Modelle, SQL-Endpunkte, Eventstream-Verarbeitung — verbraucht CU-Sekunden aus einem gemeinsamen Pool, dessen Größe Ihre F-SKU bestimmt. Eine F64 liefert beispielsweise 64 CUs an dauerhafter Kapazität. Die Dimensionierung besteht darin, diesen Pool dem aggregierten Workload-Bedarf über die Zeit anzupassen.

Mit welcher Fabric F-SKU sollte ich starten?

Es gibt keine allgemeingültige Antwort, aber F64 ist der praktische Wendepunkt, da sie die kostenlose Power-BI-Berichtsnutzung für Betrachter sowie Copilot in Fabric freischaltet. Für reine Data-Engineering- oder Pilot-Workloads reichen kleinere SKUs (F2 bis F32) oft aus. Wir empfehlen, eine Stufe unter dem modellierten Spitzenwert zu beginnen, Autoscale oder Surge Protection zu aktivieren und die Capacity Metrics App zwei bis vier Wochen zu beobachten, bevor Sie eine Reservierung abschließen.

Wie wirken sich Smoothing und Bursting auf die Dimensionierung aus?

Fabric glättet interaktiven Verbrauch über ein kurzes Fenster und Hintergrundjobs über 24 Stunden und lässt kurze Jobs über die nominale Kapazität hinaus bursten. Dadurch können Sie eine kleinere SKU betreiben, als Ihr momentaner Spitzenbedarf vermuten lässt, solange der 24-Stunden-Durchschnitt passt. Das Risiko ist anhaltender Mehrverbrauch, der sich zu Carryforward-Schulden aufstaut und Throttling auslöst. Die Dimensionierung muss daher auf den geglätteten Durchschnitt zielen, nicht auf die Rohspitze.

Was passiert bei Überlastung einer Fabric-Kapazität?

Fabric wendet progressives Throttling auf Basis des aufgelaufenen Mehrverbrauchs an: zuerst interaktive Verzögerungen (Sekunden), dann Ablehnung neuer interaktiver Abfragen und schließlich Ablehnung von Hintergrundjobs, wodurch geplante Jobs pausieren. Es stellt keinen Mehrverbrauch wie ein verbrauchsbasierter Dienst in Rechnung, sondern verschlechtert die Leistung. Das macht vorausschauende Dimensionierung und Surge Protection wichtiger als bei Pay-per-Query-Plattformen.

Sollte ich eine Fabric-Reservierung kaufen oder Pay-as-you-go nutzen?

Nutzen Sie Pay-as-you-go, solange Sie Ihr tatsächliches Verbrauchsmuster noch ermitteln, denn Sie können die Kapazität außerhalb der Geschäftszeiten pausieren und zahlen nicht für ungenutzte Rechenleistung. Sobald der Bedarf für die Basisstufe stabil und vorhersehbar ist, senkt eine Einjahresreservierung den Pay-as-you-go-Tarif um rund 40 Prozent. Das gängige Muster ist eine reservierte Basis plus eine Pay-as-you-go-Kapazität für Burst- oder Nicht-Produktions-Workloads.

Wie senke ich die Fabric-Kosten, ohne Leistung zu verlieren?

Optimieren Sie den Verbrauch, bevor Sie an der SKU drehen. Planen Sie schwere Batch-Jobs in lastarme Smoothing-Fenster, dimensionieren Sie Spark-Pools richtig und aktivieren Sie die native Ausführung, bereinigen Sie überdimensionierte Aktualisierungen semantischer Modelle, trennen Sie Dev und Test auf eine pausierbare Kapazität und nutzen Sie die Capacity Metrics App, um die wenigen Operationen mit dominantem CU-Verbrauch zu finden. Der meiste Mehrverbrauch, den wir sehen, stammt aus einer Handvoll ineffizienter Elemente — nicht daraus, dass die SKU wirklich zu klein wäre.