Microsoft Fabric Microsoft Fabric

Bilinguale Referenz für OneLake, Lakehouse, Spark, Data Factory, Warehouse, Data Science, Real-Time Intelligence, Administration, Sicherheit und Kapazitätsplanung in Microsoft Fabric. Bilingual reference for OneLake, lakehouse, Spark, Data Factory, warehouse, data science, Real-Time Intelligence, administration, security, and capacity planning in Microsoft Fabric.

Plattformmodell und zentrale Architekturprinzipien Platform model and core architecture principles

Microsoft Fabric ist eine SaaS-Analytics-Plattform, die Data Engineering, Data Factory, Data Science, Data Warehouse, Real-Time Intelligence, Databases und Power BI über gemeinsame Sicherheits-, Speicher- und Verwaltungsdienste verbindet. Das zentrale Designprinzip ist, dass Daten und Artefakte nicht mehr über viele getrennte PaaS-Dienste orchestriert werden müssen. Microsoft Fabric is a SaaS analytics platform that connects Data Engineering, Data Factory, Data Science, Data Warehouse, Real-Time Intelligence, Databases, and Power BI through shared security, storage, and administration services. The core design principle is that data and artifacts no longer need to be orchestrated across many separate PaaS services.

OneLake fungiert als logische, gemeinsame Datenebene. Darüber arbeiten Spark, SQL, KQL und Power BI auf demselben Datenfundament. Governance mit Purview, Sensitivity Labels, Berechtigungen und Lineage wird ebenfalls zentralisiert, statt je Workload neu aufgebaut zu werden. OneLake acts as the logical shared data layer. Spark, SQL, KQL, and Power BI operate over the same data foundation. Governance with Purview, sensitivity labels, permissions, and lineage is also centralized instead of being rebuilt per workload.

Fabric ist besonders effektiv, wenn Plattformteams standardisierte Workspaces, Domänen, Kapazitätszuordnung und Lebenszyklen definieren. Ohne diese Standards verlagert sich die frühere ETL-/PaaS-Komplexität lediglich in eine unklare SaaS-Betriebsform. Fabric is most effective when platform teams define standardized workspaces, domains, capacity placement, and lifecycle rules. Without these standards, earlier ETL/PaaS complexity merely moves into a less visible SaaS operating model.

• Plane Fabric immer als Tenant-/Capacity-/Workspace-Architektur. Always plan Fabric as a tenant/capacity/workspace architecture.
• Standardisiere Namensmuster, Domänen und Umgebungen vor dem ersten produktiven Workspace. Standardize naming patterns, domains, and environments before the first production workspace.
• Bewerte pro Domäne, ob Lakehouse, Warehouse oder beide gebraucht werden. Evaluate per domain whether you need a lakehouse, a warehouse, or both.
• Definiere zentral, wann Daten gespiegelt, kopiert, geshortcutet oder nur referenziert werden. Define centrally when data is mirrored, copied, shortcuted, or only referenced.

OneLake, Shortcuts, Delta/Parquet und Mirroring OneLake, shortcuts, Delta/Parquet, and mirroring

OneLake ist der mandantenweite, logische Data Lake von Fabric. Alle Workloads schreiben oder lesen daraus, auch wenn die Benutzeroberflächen unterschiedlich aussehen. Das Ziel ist eine gemeinsame Datenebene mit konsistenter Governance, Discovery und Wiederverwendung. OneLake is the tenant-wide logical data lake for Fabric. All workloads read from or write to it, even if the user experiences look different. The goal is a common data layer with consistent governance, discovery, and reuse.

Shortcuts funktionieren wie symbolische Verknüpfungen zu internen oder externen Datenquellen. Dadurch können Teams Daten aus anderen Workspaces, ADLS, S3, GCS, Dataverse oder anderen unterstützten Quellen konsumieren, ohne die Daten physisch zu duplizieren. Shortcuts behave like symbolic links to internal or external data sources. This lets teams consume data from other workspaces, ADLS, S3, GCS, Dataverse, or other supported sources without physically duplicating data.

Wenn ein Shortcut auf eine Delta-Struktur im Tabellenbereich zeigt, können Spark, SQL und Power BI diese Daten wie lokale Tabellen behandeln. Für reine Dateien im Files-Bereich bleibt der Zugriff flexibler, aber ohne automatische Tabellenerkennung. When a shortcut targets a Delta structure in the tables area, Spark, SQL, and Power BI can often treat that data as if it were local. For raw files in the Files area, access remains more flexible but without automatic table discovery.

Mirroring ist Zero-ETL-orientierte Replikation in OneLake für unterstützte operative Systeme. Die gespiegelt angelieferten Daten landen als Delta/Parquet-orientierte Tabellen in OneLake und verkürzen den Weg von Transaktionsdaten zu Analytik erheblich. Mirroring is a zero-ETL-style replication model into OneLake for supported operational systems. The mirrored data lands as Delta/Parquet-oriented tables in OneLake, significantly shortening the path from transaction data to analytics.

• Nutze Shortcuts für Föderation und Mirroring für analytische Nähe und Performance. Use shortcuts for federation and mirroring for analytical proximity and performance.
• Halte den Tabellenbereich sauber strukturiert, damit Delta-Tabellen konsistent erkannt werden. Keep the tables area structured so Delta tables are discovered consistently.
• Dokumentiere Ownership und Herkunft je Shortcut, sonst entstehen unsichtbare Abhängigkeiten. Document ownership and origin for each shortcut or you will create invisible dependencies.
• Mirroring reduziert ETL-Aufwand, ersetzt aber kein Datenmodell und keine Security-Prüfung. Mirroring reduces ETL effort but does not replace data modeling or security review.

from pyspark.sql import functions as F

df = spark.read.format("delta").load("Tables/sales_gold")
(df.groupBy("region")
   .agg(F.sum("amount").alias("revenue"))
   .write.mode("overwrite")
   .format("delta")
   .save("Tables/finance_revenue_by_region"))
        

Wann Shortcut, wann Copy, wann Mirroring? When to use shortcut, copy, or mirroring?

Shortcuts sind ideal, wenn eine vertrauenswürdige Quelle bereits existiert und ohne Duplikation konsumiert werden soll. Mirroring ist geeignet, wenn operative Daten fortlaufend in analytisch verwertbarer Form im eigenen OneLake verfügbar sein müssen. Physisches Kopieren bleibt sinnvoll für Entkopplung, Datenqualitätsstufen oder Langzeitaufbewahrung. Shortcuts are ideal when a trusted source already exists and should be consumed without duplication. Mirroring is appropriate when operational data must continuously land in your own OneLake in analytics-ready form. Physical copying still makes sense for decoupling, data quality stages, or long-term retention.

• Shortcut: schnell, günstig, föderiert, aber quellenabhängig. Shortcut: fast, cost efficient, federated, but dependent on the source.
• Mirroring: sehr bequem für operative Replikation, aber mit Speicherkosten. Mirroring: very convenient for operational replication, but with storage cost.
• Copy/ETL: maximale Kontrolle über Qualität, Schema und Entkopplung. Copy/ETL: maximum control over quality, schema, and decoupling.

Lakehouse und Data Engineering Lakehouse and Data Engineering

Das Lakehouse ist die Brücke zwischen Data Lake und tabellenzentrierter Analytik. Es verbindet Files und Tables in einer Oberfläche, stellt einen SQL Analytics Endpoint bereit und erlaubt Spark-Notebooks für Transformation, Anreicherung und Engineering-Automation. The lakehouse bridges data lake storage and table-centric analytics. It combines files and tables in one experience, provides a SQL analytics endpoint, and enables Spark notebooks for transformation, enrichment, and engineering automation.

Data Engineering in Fabric baut typischerweise auf Delta-Tabellen, Medallion-Layern und Notebook- oder Job-orientierten Verarbeitungspfaden auf. Spark übernimmt Batch-Transformation, Qualitätslogik, SCD-Prozesse und strukturierte Verarbeitung semi-strukturierter Daten. Data Engineering in Fabric typically relies on Delta tables, medallion layers, and notebook or job-based processing paths. Spark handles batch transformations, quality rules, SCD patterns, and structured processing of semi-structured data.

Ein wichtiges Architekturprinzip ist die klare Trennung zwischen kuratierten Gold-Tabellen und experimentellen oder projektspezifischen Layern. Ohne diese Trennung werden SQL-Endpunkte, semantische Modelle und Berichte schnell unübersichtlich. A key architecture principle is the clear separation between curated gold tables and experimental or project-specific layers. Without this separation, SQL endpoints, semantic models, and reports become chaotic very quickly.

• Trenne Entwicklungs-Notebook, produktive Pipeline und veröffentlichte Gold-Tabelle sauber. Separate development notebooks, production pipelines, and published gold tables cleanly.
• Nutze Notebook-Parameter, Umgebungsvariablen und zentrale Konfigurationen für Wiederverwendung. Use notebook parameters, environment variables, and central configuration for reuse.
• Validiere Datenqualität im Silver-Layer statt sie erst im Reporting zu entdecken. Validate data quality in the silver layer rather than discovering it in reporting.
• Erfasse Lineage und Dokumentation pro Gold-Tabelle, nicht nur pro Workspace. Capture lineage and documentation per gold table, not just per workspace.

from delta.tables import DeltaTable
from pyspark.sql import functions as F

bronze = spark.read.format("delta").load("Tables/orders_bronze")
silver = (bronze
    .dropDuplicates(["order_id"])
    .withColumn("order_date", F.to_date("order_timestamp"))
    .filter(F.col("is_deleted") == F.lit(False)))

silver.write.mode("overwrite").format("delta").save("Tables/orders_silver")

DeltaTable.forPath(spark, "Tables/orders_gold") \
    .alias("t") \
    .merge(silver.alias("s"), "t.order_id = s.order_id") \
    .whenMatchedUpdateAll() \
    .whenNotMatchedInsertAll() \
    .execute()
        

Data Factory: Pipelines und Dataflows Gen2 Data Factory: pipelines and Dataflows Gen2

Data Factory in Fabric fokussiert moderne Orchestrierung, Ingestion und Transformation. Pipelines koordinieren Aktivitäten, Abhängigkeiten, Trigger und Parameter. Dataflows Gen2 bringen die Power-Query-orientierte Transformation in die Plattform, insbesondere für Low-Code- oder analytiknahe Datenvorbereitung. Data Factory in Fabric focuses on modern orchestration, ingestion, and transformation. Pipelines coordinate activities, dependencies, triggers, and parameters. Dataflows Gen2 bring Power Query-oriented transformation to the platform, especially for low-code or analytics-adjacent data preparation.

Eine starke Praxis ist die Kombination aus klarer Zuständigkeitsgrenze: Dataflows Gen2 für leichter verständliche Business-Transformationen und Pipelines/Notebooks/Spark für volumenstärkere oder engineering-lastige Prozesse. Dadurch bleiben Änderungen nachvollziehbar und wartbar. A strong practice is to combine them with clear ownership boundaries: Dataflows Gen2 for understandable business transformations and pipelines/notebooks/Spark for higher-volume or engineering-heavy processes. This keeps change flows transparent and maintainable.

Pipelines werden häufig mit Lakehouse-, Warehouse-, Notebook- und Mirroring-Szenarien kombiniert. Die Frage ist weniger, ob Fabric alle Schritte kann, sondern welche Engine für Qualität, Beobachtbarkeit und Teamkompetenz die passende ist. Pipelines are often combined with lakehouse, warehouse, notebook, and mirroring scenarios. The real question is not whether Fabric can do every step, but which engine best matches quality, observability, and team skills.

• Modelliere Wiederanläufe, Dead-Letter-Pfade und Benachrichtigungen explizit. Model retries, dead-letter paths, and notifications explicitly.
• Vermeide monolithische Superpipelines; domänenspezifische Orchestrierung ist meist robuster. Avoid monolithic super-pipelines; domain-specific orchestration is usually more robust.
• Standardisiere Quell-/Zielkonventionen, damit Monitoring und Support skaliert. Standardize source/target conventions so monitoring and support can scale.
• Halte Secrets, Verbindungsinformationen und Environment-Mapping außerhalb des Business-Codes. Keep secrets, connection data, and environment mapping outside business logic.

{
  "name": "pl_ingest_sales",
  "properties": {
    "activities": [
      {
        "name": "RunBronzeNotebook",
        "type": "Notebook",
        "dependsOn": [],
        "policy": {
          "timeout": "02:00:00",
          "retry": 2
        }
      },
      {
        "name": "RefreshWarehouseView",
        "type": "SqlScript",
        "dependsOn": [
          { "activity": "RunBronzeNotebook", "dependencyConditions": ["Succeeded"] }
        ]
      }
    ]
  }
}
        

Data Warehouse, T-SQL und Cross-Database-Abfragen Data Warehouse, T-SQL, and cross-database queries

Das Fabric Warehouse richtet sich an Teams, die relationale Modellierung, SQL-zentrierte Entwicklung und klassische DWH-Muster bevorzugen. Es bietet T-SQL-Zugriff, relationale Sicherheit, Views, Prozedur-orientierte Denkmodelle und eine enge Verzahnung mit Power BI und anderen konsumierenden Tools. The Fabric Warehouse targets teams that prefer relational modeling, SQL-centric development, and classic data warehouse patterns. It provides T-SQL access, relational security, views, procedural thinking patterns, and tight integration with Power BI and other consuming tools.

Cross-Database-Abfragen sind besonders nützlich, wenn gemeinsame Referenzdaten, bereichsübergreifende Fakten oder schrittweise Modernisierung mehrerer Domänen notwendig sind. Sie sollten jedoch bewusst für kuratierte Modelle genutzt werden und nicht als Ausrede für fehlende Domänengrenzen. Cross-database queries are especially useful when shared reference data, cross-domain facts, or gradual modernization across domains are required. They should be used deliberately for curated models, not as an excuse for missing domain boundaries.

Sicherheitsseitig profitiert das Warehouse von rollenbasierter SQL-Sicherheit, Objektberechtigungen, Views, RLS-Mustern und klarer Schichttrennung zwischen Rohdaten, semantischen Schichten und veröffentlichten Berichtsmodellen. From a security perspective, the warehouse benefits from role-based SQL security, object permissions, views, RLS patterns, and clear separation between raw data, semantic layers, and published reporting models.

• Nutze Views und stabile Contract-Tabellen als Konsumgrenze zwischen Domänen. Use views and stable contract tables as the consumption boundary between domains.
• Baue Cross-DB-Abfragen bewusst und dokumentiert, nicht implizit aus Bequemlichkeit. Build cross-database queries deliberately and document them, not just for convenience.
• Segmentiere Berechtigungen auf Schema-, View- und Rollenebene. Segment permissions at schema, view, and role level.
• Trenne semantische Modellierung für Power BI von technischen Hilfstabellen. Separate semantic modeling for Power BI from technical helper tables.

SELECT  o.OrderDate,
        o.OrderAmount,
        c.CustomerName,
        r.RegionName
FROM    SalesWarehouse.dbo.FactOrders AS o
JOIN    MasterDataWarehouse.dbo.DimCustomer AS c
          ON o.CustomerKey = c.CustomerKey
JOIN    ReferenceWarehouse.dbo.DimRegion AS r
          ON o.RegionKey = r.RegionKey
WHERE   o.OrderDate >= DATEADD(day, -30, CAST(GETDATE() AS date));

CREATE ROLE reporting_reader;
GRANT SELECT ON SCHEMA::reporting TO reporting_reader;
        

Data Science, MLflow, Experimente und PREDICT Data Science, MLflow, experiments, and PREDICT

Fabric Data Science verbindet Notebooks, Spark, Experimente, Modellregistrierung und operativen Konsum. MLflow dient dabei als zentrales Muster für Tracking, Artefaktverwaltung, Modellregistrierung und Wiederverwendung. Fabric Data Science connects notebooks, Spark, experiments, model registration, and operational consumption. MLflow acts as the central pattern for tracking, artifact handling, model registration, and reuse.

Ein professionelles Betriebsmodell trennt explorative Experimente von produktionsreifen Modellen. Experimente dokumentieren Parameter, Läufe und Metriken; registrierte Modelle erzeugen versionierte, nachvollziehbare Schnittstellen für Batch- oder SQL-basiertes Scoring. A professional operating model separates exploratory experiments from production-ready models. Experiments document parameters, runs, and metrics; registered models create versioned, traceable interfaces for batch or SQL-based scoring.

Die PREDICT-Funktion verbindet MLflow-registrierte Modelle mit SQL-basierten Auswertungen. Dadurch können analytische Teams Modelle in relationale oder Lakehouse-nahe Verarbeitungspfade einbinden, ohne jedes Mal einen separaten Python-Serving-Pfad aufzubauen. The PREDICT function connects MLflow-registered models with SQL-based scoring. This allows analytics teams to embed models into relational or lakehouse-adjacent flows without standing up a separate Python serving stack every time.

• Pflege Signaturen und Eingabeschemata für MLflow-Modelle konsequent. Maintain signatures and input schemas for MLflow models consistently.
• Definiere, wer Modelle registrieren, promoten und zurückrollen darf. Define who may register, promote, and roll back models.
• Nutze separate Experimente oder Workspaces für Forschung und Produktion. Use separate experiments or workspaces for research and production.
• Dokumentiere Datenherkunft und Trainingsfenster zusammen mit dem Modell. Document data origin and training window together with the model.

import mlflow
from sklearn.linear_model import LogisticRegression
from sklearn.datasets import load_diabetes
from mlflow.models.signature import infer_signature

data = load_diabetes(as_frame=True)
X = data.data
y = data.target

mlflow.set_experiment("diabetes-demo")
with mlflow.start_run():
    model = LogisticRegression(max_iter=500)
    model.fit(X, y)
    signature = infer_signature(X, y)
    mlflow.sklearn.log_model(
        model,
        artifact_path="diabetes-model",
        signature=signature,
        registered_model_name="diabetes-model"
    )
        

SELECT  customer_id,
        revenue_30d,
        support_tickets,
        PREDICT(MODEL = 'customer-churn-model',
                DATA = (SELECT customer_id, revenue_30d, support_tickets)) AS churn_prediction
FROM    analytics.scoring_input;
        

Real-Time Intelligence: Eventhouse, KQL Database und Data Activator Real-Time Intelligence: Eventhouse, KQL Database, and Data Activator

Real-Time Intelligence bündelt Ingestion, Speicherung, Query und Reaktion für Ereignisströme. Eventhouse ist die zentrale Container-Erfahrung für Echtzeitdaten, während KQL Databases und Tabellen die performante, analysierbare Struktur dahinter bereitstellen. Real-Time Intelligence combines ingestion, storage, querying, and reaction for event streams. Eventhouse is the central container experience for real-time data, while KQL databases and tables provide the high-performance analytical structure underneath.

KQL eignet sich besonders für Telemetrie, Logs, IoT-Events, Clickstreams, Operational Analytics und Ad-hoc-Untersuchungen über Zeitreihen. Data Activator schließt die Lücke zwischen Erkenntnis und Aktion, indem definierte Bedingungen unmittelbar Benachrichtigungen oder Prozesse auslösen. KQL is especially well suited for telemetry, logs, IoT events, clickstreams, operational analytics, and ad-hoc investigations over time-series data. Data Activator closes the gap between insight and action by turning defined conditions into notifications or processes.

Ein häufiger Architekturfehler besteht darin, Real-Time Intelligence als reines Dashboard-Feature zu sehen. Der eigentliche Mehrwert entsteht, wenn Ereignisströme, Regeln und Aktionen in Betriebsprozesse, Teams, Power Automate oder incident-orientierte Workflows integriert werden. A common architecture error is to view Real-Time Intelligence as only a dashboard feature. The real value appears when event streams, rules, and actions are integrated into operations processes, Teams, Power Automate, or incident-oriented workflows.

• Definiere KQL-Tabellen und Aufbewahrung passend zu Betriebs- und Compliance-Zielen. Define KQL tables and retention to match operations and compliance goals.
• Kombiniere Echtzeitregeln mit sauberem Owner- und Eskalationsmodell. Combine real-time rules with a clean ownership and escalation model.
• Unterscheide streng zwischen Diagnose-Dashboards und auslösenden Business-/SOC-Aktionen. Clearly distinguish diagnostic dashboards from trigger-driven business or SOC actions.
• Nutze Eventhouse nicht nur für Visualisierung, sondern als operationales Analyse-Backend. Use Eventhouse not just for visualization, but as an operational analytics backend.

Telemetry
| where Timestamp > ago(30m)
| summarize ErrorCount = countif(Level == "Error"), AvgLatency = avg(DurationMs) by Service, bin(Timestamp, 5m)
| where ErrorCount > 20 or AvgLatency > 1500
| order by Timestamp desc
        

Power BI-Integration und semantische Konsumschicht Power BI integration and semantic consumption layer

Power BI ist in Fabric keine nachgelagerte Zusatzkomponente, sondern die integrierte Konsumschicht für Berichte, semantische Modelle, Direct Lake, Dashboards und Self-Service-Analysen. Besonders stark ist Fabric, wenn Lakehouse, Warehouse und semantisches Modell als gemeinsam geplante Architektur auftreten. In Fabric, Power BI is not an afterthought but the integrated consumption layer for reports, semantic models, Direct Lake, dashboards, and self-service analytics. Fabric is strongest when lakehouse, warehouse, and semantic model are designed as one architecture.

Direct Lake reduziert Importlatenzen und vermeidet viele klassische Datenbewegungen. Gleichzeitig erfordert es saubere Modellierung, klare Gold-Tabellen und disziplinierte Veränderungen, weil semantische Modelle direkter mit dem physischen Datenmodell gekoppelt sind. Direct Lake reduces import latency and avoids many classic data movement patterns. At the same time, it requires clean modeling, clear gold tables, and disciplined change management because semantic models become more directly coupled to the physical data model.

• Behandle das semantische Modell als Produkt mit Vertrag, Dokumentation und Ownership. Treat the semantic model as a product with a contract, documentation, and ownership.
• Nutze Direct Lake bewusst für kuratierte, stabile Schichten. Use Direct Lake deliberately for curated, stable layers.
• Vermeide, dass Berichte direkt auf experimentellen Bronze-/Silver-Tabellen aufsetzen. Avoid building reports directly on experimental bronze or silver tables.

Administration, Kapazitäten, Workspaces, Domains, Git und Sicherheit Administration, capacities, workspaces, domains, Git, and security

Fabric-Administration beginnt mit Kapazitäten und Workspaces. Eine Kapazität ist der dedizierte Ressourcenpool im Tenant, Workspaces sind die organisatorischen Container für Items, und Domains helfen dabei, Artefakte nach Geschäftsbereichen oder Plattformverantwortung zu ordnen. Fabric administration starts with capacities and workspaces. A capacity is the dedicated resource pool in the tenant, workspaces are the organizational containers for items, and domains help organize assets by business area or platform ownership.

Git-Integration und Deployment Pipelines sind zentrale Bausteine für kontrollierte Entwicklung. Workspaces sollten deshalb klar als Dev/Test/Prod oder nach Domänen und Umgebungen modelliert werden. Nicht jedes Item unterstützt denselben DevOps-Reifegrad, daher sind Standards pro Workload hilfreich. Git integration and deployment pipelines are central building blocks for controlled development. Workspaces should therefore be modeled clearly as dev/test/prod or by domain and environment. Not every item supports the same DevOps maturity yet, so workload-specific standards are helpful.

Auf der Sicherheitsseite kombiniert Fabric Workspace-Rollen, Item-Berechtigungen, RLS/OLS-Muster, Sensitivity Labels, Purview-Governance und Aktivitätsprotokolle. Gute Governance trennt Autorenrechte, Bereitstellungsrechte und reine Konsumentenrechte konsequent. On the security side, Fabric combines workspace roles, item permissions, RLS/OLS patterns, sensitivity labels, Purview governance, and activity logs. Good governance separates author rights, deployment rights, and pure consumer rights consistently.

• Ordne Workspaces nicht allein organisatorisch, sondern nach Betriebs- und Releasegrenzen. Arrange workspaces by operating and release boundaries, not only by org chart.
• Führe für Dev/Test/Prod getrennte Workspaces, Reviewer und Promotionspfade. Use separate workspaces, reviewers, and promotion paths for dev/test/prod.
• Prüfe pro Workload, welche Artefakte Git-fähig sind und welche ergänzende Export-/Dokumentationspfade brauchen. Check per workload which artifacts are Git-enabled and which need supplementary export or documentation paths.
• RLS und Sensitivity Labels gehören früh ins Datenprodukt und nicht erst in den letzten Bericht. RLS and sensitivity labels belong early in the data product, not only in the final report.
• Überwache Kapazitätsauslastung und langlaufende Jobs fortlaufend. Continuously monitor capacity utilization and long-running jobs.

Pricing, Capacity Units und F-SKUs Pricing, capacity units, and F SKUs

Fabric-Kapazitäten werden in Capacity Units (CUs) modelliert. Die Auswahl der passenden F-SKU bestimmt, wie viel Rechenleistung für Spark, Warehouse, Real-Time Intelligence und Power-BI-nahe Workloads gleichzeitig verfügbar ist. Fabric capacities are modeled in capacity units (CUs). Choosing the right F SKU determines how much compute is available concurrently for Spark, Warehouse, Real-Time Intelligence, and Power BI-adjacent workloads.

Die folgende Übersicht entspricht dem typischen Microsoft-Fabric-SKU-Modell. Für Architekturplanung ist weniger die reine Zahl wichtig als die Frage, welche Lasten gleichzeitig auf einer Kapazität laufen und ob Produktiv-, Entwicklungs- und Self-Service-Workloads getrennt werden müssen. The following overview reflects the common Microsoft Fabric SKU model. For architecture planning, the raw number matters less than which workloads run at the same time and whether production, development, and self-service workloads must be separated.

• Plane Capacity Units gegen Spitzenlast, nicht gegen Durchschnittsverbrauch. Plan capacity units against peak load, not average consumption.
• Trenne kritische produktive Bereiche von explorativen Notebooks oder Massentests. Separate critical production areas from exploratory notebooks or bulk tests.
• Nutze Kapazitätsmetriken und Governance-Reviews als festen Betriebsprozess. Use capacity metrics and governance reviews as a standing operational process.

Vergleichsmatrix und Entscheidungsleitfaden Comparison matrix and decision guide

Fabric bietet mehrere Wege zum selben Ziel: Daten ingestieren, modellieren, auswerten und bereitstellen. Entscheidend ist daher nicht die Tool-Vielfalt, sondern die bewusste Auswahl des richtigen Workloads pro Aufgabe. Fabric offers multiple ways to reach similar goals: ingest, model, analyze, and publish data. What matters is not the tool variety itself but choosing the right workload for each job.

• Wähle möglichst wenig Workloads pro Datenprodukt, aber so viele wie nötig. Choose as few workloads per data product as possible, but as many as necessary.
• Dokumentiere je Domäne, welche Schicht Gold/Vertrag/Consumption darstellt. Document per domain which layer represents gold, contract, and consumption.
• Ein gemeinsamer Plattform-Backlog für OneLake, Security, Git und Capacity zahlt sich langfristig aus. A shared platform backlog for OneLake, security, Git, and capacity pays off in the long run.