Zum Inhalt

Base Fabric Data Platform

Data-Teams wollen in Microsoft Fabric bauen, ohne die Kontrollen für Netzwerk, Verschlüsselung, Zugriff und Kosten drumherum zu betreiben. Die Base Fabric Data Platform ist eine paketierte Lösung auf der MCP-Plattform, die Microsoft-Fabric-workspaces mit einer festen Baseline liefert: private Konnektivität, Outbound-Schutz, kundenverwaltete Verschlüsselung für den Data Lake, Zugriff über Entra-ID-Gruppen, Verbindungen zu Datenquellen, Kostenkontrolle der capacity und Monitoring. Alles wird als Infrastructure as Code mit Terraform deployt.

Optionales Angebot, Referenzdesign

Die Base Fabric Data Platform ist nicht Teil des Core-MCP-hub-and-spoke. Sie ist eine Lösung, die im Rahmen einer Vereinbarung geliefert wird (Servicetypen). Welche Teile deine Plattform betreibt und mit welchen Einstellungen, hängt von deinem Deployment ab. Die Namen, Defaults und Werte auf diesen Seiten stammen aus dem Code der Lösung und der Service- beschreibung und sind die üblichen Werte. Dein Deployment kann abweichen. Frag dein Plattform-Team.

Für wen die Lösung ist

Du bist Beginne mit
Data Engineer oder Analyst und nutzt die workspaces Servicebeschreibung, Zugriff und Rollen, Konnektivität
Ein Team, das eine Änderung braucht (neuer workspace, neue Verbindung, Lakehouse, capacity-Größe) Anfragen und Änderungen
Ein Team, das seine Datenschichten entwerfen will Datenarchitektur (Referenzmuster)
Das Plattform-Team, das die Lösung deployt und betreibt Architektur, Verantwortlichkeiten, Plattformkonfiguration

Das Plattform-Team ist XMMS im Rahmen eines Managed-Service-Vertrags oder das eigene Team des Kunden, wenn die Plattform im Eigenbetrieb läuft. Siehe Betriebsmodelle. Die Seiten sprechen deshalb vom „Plattform-Team“ und vom „Workload-Team“.

Wie die Lösung zur Plattform passt

Die Lösung wird auf einem spoke der Managed Cloud Platform gebaut (dem spoke canvas, siehe Spoke canvas und Was du bekommst). Sie nutzt, was der spoke schon bietet: das virtuelle Netzwerk mit einem Subnet für private endpoints, den Key Vault, das Storage Account, den Log Analytics workspace, den Service Principal des spokes und das zentrale private DNS. Die Lösung ergänzt die Fabric- Ressourcen und den Kleber drumherum. Sie ersetzt nicht die Plattform-Baseline.

flowchart TB
    subgraph mcp["MCP platform"]
        hub["Hub: firewall, DNS, VPN / ExpressRoute"]
        spoke["Spoke canvas: VNet, Key Vault, storage, Log Analytics"]
    end
    subgraph fdp["Base Fabric Data Platform"]
        shared["Shared tier: Fabric capacities, auto-pause"]
        workload["Workload tier: gateway, workspaces, connections, data lake"]
        extras["Optional: Purview governance, Grafana observability"]
    end
    hub --> spoke
    spoke --> workload
    shared --> workload
    workload --> extras

Was dokumentiert ist

Bereich Was er abdeckt Seite
Umfang Komponenten, Standardänderungen, SLA-Metriken, Recovery Objectives, Incident-Prozess Servicebeschreibung
Anfragen Wie eine Änderung angefragt und geliefert wird, Feldlisten pro Änderung Anfragen und Änderungen
Zugriff Workspace-Rollen, die optionale Admin-Gruppe, Zugriff auf capacity und Grafana Zugriff und Rollen
Konnektivität Verbindungstypen, managed private endpoints, Outbound-Regeln, Git Konnektivität
Monitoring Plattform-Monitoring, Workload-Monitoring, die Grafana-Dashboards und Alerts Monitoring
Kosten Capacity auto-pause und manuelles Fortsetzen, Sizing Kostenoptimierung
Datenschichten Referenz-Medallion-Muster mit dbt Datenarchitektur
Design Subscriptions, Tiers, Netzwerk, Storage, Identität Architektur
Betriebsmodell Wer macht was, RACI Verantwortlichkeiten
Deployment Repository-Aufbau, Tiers, Variablen, Voraussetzungen Plattformkonfiguration
Runbooks Outbound-Schutz, capacity auto-pause, Grafana, Purview Workspace network policy, Capacity auto-pause, Observability, Governance
Entscheidungen RBAC-Modell und die wichtigsten Designentscheidungen Entscheidungen

Hier nicht dokumentiert

  • Vertragsbedingungen: support-Zeiten, Reaktionszeiten, SLA-Ziele und Gebühren. Die Servicebeschreibung lässt SLA-Ziele „zu vereinbaren“ pro Kunde.
  • Die CI/CD-pipeline-Definitionen. Sie sind nicht Teil der Quelle dieser Lösung und liegen im Konfigurations- Repository des Deployments.
  • Fabric selbst. Microsoft Learn dokumentiert workspaces, Lakehouses, Warehouses und pipelines.
  • Betriebsmodelle: Das Plattform-Team ist XMMS (Managed Service) oder das eigene Team des Kunden (Eigenbetrieb)
  • Servicetypen: Core-, direkte und zusätzliche Services, Spoke-Varianten
  • Architekturreferenz: Schichten, Management Groups, Hub und Spokes
  • Nutzer: Was ein Workload-Team von der Plattform bekommt
  • Verantwortlichkeiten: Die generische Aufteilung zwischen Plattform-Team und Workload-Team