# 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.

OneLake OneLake
Gemeinsame Datenebene Shared data layer
Spark + SQL Spark + SQL
Eine Plattform, mehrere Engines One platform, multiple engines
RTI RTI
Streams bis Aktionen Streams to actions
F-SKU F-SKU
Kapazität über CUs Capacity by CUs
💡 Fabric ist am stärksten, wenn Daten nicht kopiert, sondern bewusst geteilt werden 💡 Fabric is strongest when data is not copied but deliberately shared

OneLake, Shortcuts, SQL Endpoints, Direct Lake und gemeinsame Governance entfalten ihren Wert, wenn Teams ein gemeinsames Datenbetriebsmodell nutzen statt isolierte Workload-Silos zu bauen. OneLake, shortcuts, SQL endpoints, Direct Lake, and shared governance create the most value when teams use a common data operating model instead of isolated workload silos.

⚠️ Kapazität ist Architektur, nicht nur Einkauf ⚠️ Capacity is architecture, not just procurement

Falsche Workspace-Zuordnung, konkurrierende Spark-Jobs oder unklare Dev/Test/Prod-Trennung führen schnell zu Engpässen. Kapazitätsplanung ist Teil des Plattformdesigns. Wrong workspace placement, competing Spark jobs, or unclear dev/test/prod separation quickly create bottlenecks. Capacity planning is part of platform design.

Plattformmodell Platform model

SaaS-Architektur, gemeinsame Dienste und Rollenbilder. SaaS architecture, shared services, and role models.

OneLake OneLake

Shortcuts, Delta/Parquet und Mirroring. Shortcuts, Delta/Parquet, and mirroring.

Lakehouse & Engineering Lakehouse and Engineering

Spark-Notebooks, Medallion und Engineering-Patterns. Spark notebooks, medallion, and engineering patterns.

Data Factory Data Factory

Pipelines, Dataflows Gen2 und Orchestrierung. Pipelines, Dataflows Gen2, and orchestration.

Warehouse Warehouse

T-SQL, Cross-DB-Queries und Security. T-SQL, cross-database queries, and security.

Data Science Data Science

MLflow, Experimente, Modelle und PREDICT. MLflow, experiments, models, and PREDICT.

Real-Time Intelligence Real-Time Intelligence

Eventhouse, KQL Database und Data Activator. Eventhouse, KQL Database, and Data Activator.

Admin & Security Admin and security

Kapazitäten, Workspaces, Domains, Git, RLS und Labels. Capacities, workspaces, domains, Git, RLS, and labels.

## 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.

Baustein Building block | Rolle Role | Wesentliche Stärke Primary strength | Typische Frage Typical question
--- | --- | --- | ---
OneLake OneLake | Gemeinsamer Speicher und Katalog Shared storage and catalog | Zero-copy Sharing und einheitliche Datenbasis Zero-copy sharing and a unified data base | Liegt das Dataset lokal, gespiegelt oder als Shortcut vor? Is the dataset local, mirrored, or exposed via shortcut?
Lakehouse Lakehouse | Datei- und Tabellenorientierte Analytik File and table oriented analytics | Spark, SQL Endpoint und offene Dateiformate Spark, SQL endpoint, and open file formats | Brauche ich engineering-lastige Transformation oder Warehouse-Modelle? Do I need engineering-heavy transformation or warehouse modeling?
Warehouse Warehouse | T-SQL-zentrierte Modellierung T-SQL-centric modeling | DWH-Patterns, Security und SQL-Zugänglichkeit DWH patterns, security, and SQL accessibility | Wo liegen Kernmodelle und konsumierbare Fakt/Dim-Strukturen? Where do core models and consumable fact/dim structures live?
Real-Time Intelligence Real-Time Intelligence | Streaming, KQL und Reaktion Streaming, KQL, and action | Echtzeitabfragen und ereignisgesteuerte Aktionen Real-time querying and event-driven actions | Wann brauche ich Stream-Verarbeitung statt Batch? When do I need streaming instead of batch?
Power BI Power BI | Semantische Schicht und Visualisierung Semantic layer and visualization | Direct Lake, Berichte und Geschäftslogik Direct Lake, reports, and business logic | Wie konsumiere ich Daten ohne neue Silos aufzubauen? How do I consume data without building new silos?

- 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.

Konzept Concept | Stärke Strength | Typisches Einsatzmuster Typical pattern | Einschränkung Constraint
--- | --- | --- | ---
Shortcut Shortcut | Zero-copy Datenfreigabe Zero-copy data sharing | Verweis auf ADLS, S3, anderen Workspace oder Dataverse Reference ADLS, S3, another workspace, or Dataverse | Read-only Charakter und Quellabhängigkeit beachten Respect its read-only character and source dependency
Delta in Tables Delta in Tables | Gemeinsame Nutzung über mehrere Engines Shared consumption across multiple engines | Lakehouse-Tabellen für Spark, SQL, Power BI Lakehouse tables for Spark, SQL, Power BI | Namens- und Strukturkonventionen sind entscheidend Naming and structure conventions are critical
Parquet im Files-Bereich Parquet in Files area | Flexible Dateiorientierung Flexible file orientation | Rohdaten, Exportdateien, Zwischenstände Raw data, export files, intermediates | Nicht automatisch als relationale Tabelle erkannt Not automatically recognized as a relational table
Mirroring Mirroring | Nahezu Echtzeit-Replikation in OneLake Near real-time replication into OneLake | Azure SQL, Cosmos DB, Snowflake und andere unterstützte Quellen Azure SQL, Cosmos DB, Snowflake, and other supported sources | Speichermehrbedarf und Sync-Lag einplanen Plan for storage overhead and sync lag

- 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.

PySpark

    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.

Layer Layer | Ziel Purpose | Technische Merkmale Technical traits
--- | --- | ---
Bronze Bronze | Rohdaten und Quelltreue Raw data and source fidelity | Append-lastig, minimale Transformation, schema-on-read möglich Append-heavy, minimal transformation, schema-on-read possible
Silver Silver | Bereinigung und Harmonisierung Cleansing and harmonization | Deduplication, Typisierung, Qualitätsregeln, Join-Vorbereitung Deduplication, typing, quality rules, join preparation
Gold Gold | Geschäftsnahe, konsumierbare Modelle Business-ready consumable models | Dim/Fact- oder KPI-orientierte Tabellen mit stabilen Verträgen Dim/fact or KPI-oriented tables with stable contracts

- 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.

PySpark

    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.

Werkzeug Tool | Stärken Strengths | Wann einsetzen When to use
--- | --- | ---
Pipeline Pipeline | Orchestrierung, Trigger, Parameter, Fehlerpfade Orchestration, triggers, parameters, failure paths | End-to-end Prozesssteuerung und Terminierung End-to-end process control and scheduling
Dataflow Gen2 Dataflow Gen2 | Power Query, Low Code, schnelle Aufbereitung Power Query, low code, rapid shaping | Business-nahe Transformation, überschaubare Komplexität Business-oriented transformation with manageable complexity
Notebook / Spark Job Notebook / Spark job | Skalierbare Code-Transformation Scalable code-based transformation | Große Volumina, komplexe Logik, Data Engineering Large volumes, complex logic, data engineering

- 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.

JSON

    {
      "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.

Experience Experience | Stärke Strength | Typischer Konsument Typical consumer | Hinweis Note
--- | --- | --- | ---
Warehouse Warehouse | Kuratiertes relationales Datenmodell Curated relational data model | SQL-Entwickler, BI-Teams, kontrollierte DWH-Prozesse SQL developers, BI teams, controlled DWH processes | Stark für standardisierte konsumierbare Modelle Strong for standardized consumable models
Lakehouse SQL Endpoint Lakehouse SQL endpoint | Lesender SQL-Zugriff auf Delta-Tabellen Read-only SQL access to Delta tables | Analysten, Self-Service, Direktabfragen Analysts, self-service, ad-hoc querying | Nicht als vollständiger Ersatz für Warehouse-Governance gedacht Not a full replacement for warehouse governance
KQL Database / Eventhouse KQL Database / Eventhouse | Zeitreihen und Eventanalyse Time-series and event analytics | Ops, Telemetrie, Streaming-Analytik Ops, telemetry, streaming analytics | Statt relationalem Sternschema eher ereignisorientiert Event-centric rather than relational star schema

- 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.

T-SQL

    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.

Baustein Building block | Funktion Function | Nutzen Benefit
--- | --- | ---
Notebook Notebook | Feature Engineering, Training, Exploration Feature engineering, training, exploration | Schnelles Experimentieren mit Spark oder Python Fast experimentation with Spark or Python
Experiment Experiment | Tracking von Läufen, Parametern und Metriken Tracking of runs, parameters, and metrics | Nachvollziehbare Modellentwicklung Traceable model development
MLflow Registry MLflow registry | Versionierte Modellverwaltung Versioned model management | Kontrollierter Übergang in produktive Nutzung Controlled transition to production use
PREDICT PREDICT | Batch-Scoring per SQL für registrierte Modelle SQL batch scoring for registered models | Wiederverwendung in Warehouse-/Lakehouse-nahen Prozessen Reuse in warehouse and lakehouse-centric flows

- 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.

Python

    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"
        )

T-SQL

    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.

Komponente Component | Rolle Role | Typischer Output Typical output
--- | --- | ---
Eventhouse Eventhouse | Container für Echtzeitdaten und KQL-Artefakte Container for real-time data and KQL artifacts | Streaming- und Historienanalyse Streaming and historical analytics
KQL Database KQL Database | Hochperformanter Speicher und Query-Engine für Events High-performance storage and query engine for events | Zeitreihenabfragen, Aggregationen, Detektion Time-series queries, aggregations, detection
Data Activator Data Activator | No-code/low-code Reaktion auf Ereignisse und Schwellwerte No-code/low-code response to events and thresholds | Alerts, Teams-Messages, Power-Automate-Aktionen Alerts, Teams messages, Power Automate actions

- 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.

KQL

    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.

Modus Mode | Stärke Strength | Wann gut geeignet When it fits
--- | --- | ---
Import Import | Hohe Berichtsgeschwindigkeit und Modellflexibilität High report speed and model flexibility | Wenn Datenfenster begrenzt und Aktualisierung planbar ist When data volume is manageable and refresh can be scheduled
DirectQuery DirectQuery | Aktuelle Daten ohne Import Current data without import | Wenn Quellsystem-Abfragezeit akzeptabel ist When source query latency is acceptable
Direct Lake Direct Lake | Direkter Fabric-naher Konsum mit geringer Datenbewegung Fabric-native direct consumption with minimal movement | Für sauber modellierte Gold-/Warehouse-Daten in Fabric For well-modeled gold or warehouse data in Fabric

- 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.

Admin-Bereich Admin area | Entscheidungen Decisions | Empfohlene Praxis Recommended practice
--- | --- | ---
Kapazität Capacity | F-SKU, Workspace-Zuordnung, Lasttrennung F-SKU, workspace placement, load separation | Produktive und experimentelle Lasten bewusst trennen Deliberately separate production and experimental loads
Workspace Workspace | Domäne, Umgebung, Owner, Release-Prozess Domain, environment, owner, release process | Ein Workspace ist kein Ablageordner, sondern eine Betriebsgrenze A workspace is an operating boundary, not a folder
Domain Domain | Geschäftsbereich und Datenverantwortung Business area and data ownership | Domänen für Governance, Ownership und Discoverability nutzen Use domains for governance, ownership, and discoverability
Git / Deployment Git / deployment | Branching, Review, Promotion Branching, review, promotion | Dev/Test/Prod und Reviews je Workload standardisieren Standardize dev/test/prod and reviews per workload
Sicherheit Security | Rollen, RLS, Labels, Audit Roles, RLS, labels, audit | Least privilege plus nachvollziehbare Freigabewege Least privilege plus traceable approval paths

Sicherheitskontrolle Security control | Beschreibung Description | Typischer Anwendungsfall Typical use case
--- | --- | ---
Workspace-Rollen Workspace roles | Admin, Member, Contributor, Viewer je nach Arbeitsmodus Admin, member, contributor, viewer according to working mode | Trennung von Autoren und Konsumenten Separation of authors and consumers
Item-Berechtigungen Item permissions | Gezielte Freigabe einzelner Artefakte Targeted sharing of individual artifacts | Berichte oder Modelle für begrenzte Zielgruppen Reports or models for limited audiences
RLS / OLS RLS / OLS | Zeilen- oder objektbasierte Zugriffsbeschränkung Row-level or object-level access restriction | Regionale oder vertrauliche Datenselektion Regional or sensitive data selection
Sensitivity Labels Sensitivity labels | Klassifizierung und Richtlinienvererbung Classification and policy inheritance | Schutz von vertraulichen Reports und Datensätzen Protection of sensitive reports and datasets
Auditing / Lineage Auditing / lineage | Nachvollziehbarkeit von Änderungen und Datenwegen Traceability of changes and data paths | Compliance, Root Cause Analysis, Impact Assessment Compliance, root cause analysis, impact assessment

- 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.

SKU SKU | Capacity Units (CU) Capacity Units (CU) | Power BI SKU Power BI SKU | Power BI v-Cores Power BI v-cores
--- | --- | --- | ---
F2 F2 | 2 2 | - - | 0.25 0.25
F4 F4 | 4 4 | - - | 0.5 0.5
F8 F8 | 8 8 | EM/A1 EM/A1 | 1 1
F16 F16 | 16 16 | EM2/A2 EM2/A2 | 2 2
F32 F32 | 32 32 | EM3/A3 EM3/A3 | 4 4
F64 F64 | 64 64 | P1/A4 P1/A4 | 8 8
Trial Trial | 64 64 | - - | 8 8
F128 F128 | 128 128 | P2/A5 P2/A5 | 16 16
F256 F256 | 256 256 | P3/A6 P3/A6 | 32 32
F512 F512 | 512 512 | P4/A7 P4/A7 | 64 64
F1024 F1024 | 1024 1024 | P5/A8 P5/A8 | 128 128
F2048 F2048 | 2048 2048 | - - | 256 256

Preisaspekt Pricing aspect | Worauf achten? What to watch?
--- | ---
Gleichzeitige Lasten Concurrent workloads | Spark-Jobs, Warehouse-Queries, RTI-Abfragen und Berichtsabrufe konkurrieren auf derselben Kapazität. Spark jobs, warehouse queries, RTI queries, and report consumption compete on the same capacity.
Workspace-Zuordnung Workspace placement | Falsche Zuordnung verteilt produktive und experimentelle Lasten unkontrolliert. Wrong placement mixes production and experimental workloads unpredictably.
Lizenzmodell für Konsumenten Consumer license model | Besonders für Power-BI-Inhalte sind F64+ und per-user Lizenzen architekturrelevant. Especially for Power BI content, F64+ and per-user licensing are architecturally relevant.
Skalierung Scaling | Manchmal ist eine zusätzliche Kapazität für Isolation sinnvoller als nur die größere SKU. Sometimes an additional capacity for isolation is better than only a bigger SKU.

- 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.

Anforderung Requirement | Bevorzugter Workload Preferred workload | Warum Why
--- | --- | ---
Rohdatenföderation ohne Kopie Raw data federation without copying | OneLake Shortcut OneLake shortcut | Schneller Zugriff mit minimaler Datenbewegung Fast access with minimal data movement
Große Batch-Transformation Large batch transformation | Lakehouse + Spark Lakehouse plus Spark | Skalierbare Code- und Delta-Verarbeitung Scalable code and Delta processing
Kuratiertes relationales Modell Curated relational model | Warehouse Warehouse | T-SQL, Security und BI-Konsum T-SQL, security, and BI consumption
Echtzeit-Telemetrie und Alerts Real-time telemetry and alerts | Eventhouse + KQL + Data Activator Eventhouse plus KQL plus Data Activator | Streaming-Analytik mit unmittelbarer Reaktion Streaming analytics with immediate reaction
Geschäftsberichte und Self Service Business reports and self-service | Power BI / Direct Lake Power BI / Direct Lake | Semantische Schicht und Fachbereichskonsum Semantic layer and business consumption

- 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.