Datenarchitektur (Referenzmuster)¶

Diese Seite beschreibt eine Referenz-Datenarchitektur, um auf der Base Fabric Data Platform eine Datenplattform im Medallion-Stil aufzubauen. Sie stammt aus den Architekturdiagrammen der Lösung. Die Plattform liefert die workspaces, Lakehouses, Warehouses, Connections und das Netzwerk. Sie liefert oder erzwingt die folgenden Layer, Schemas, pipelines oder dbt-Modelle nicht. Sie sind ein Ausgangspunkt für das Workload-Team.

Referenzdesign, dein Design kann abweichen

Betrachte die Namen (staging, active, landing, bronze, silver, gold) als Konvention, die du übernehmen oder anpassen kannst. Die Plattform verlangt sie nicht.

Layer¶

flowchart LR
    subgraph src["Sources"]
        s1["Files and blob storage"]
        s2["Databases: Oracle, SQL Server, Azure SQL"]
        s3["API, SharePoint, notebooks"]
    end
    subgraph lh["Lakehouse"]
        stg["Files/staging: full history"]
        act["Files/active: latest only"]
    end
    subgraph wh["Warehouse layers (dbt)"]
        land["Landing"]
        br["Bronze"]
        sil["Silver"]
        gold["Gold"]
    end
    s1 -->|"copy files, shortcut"| stg
    stg -->|"select latest"| act
    s2 -->|"copy job, mirroring"| land
    s3 -->|"notebook ingestion"| stg
    act -->|"external tables"| land
    land --> br --> sil --> gold
    gold --> serve["Serve: Power BI, ML, API"]

Layer	Was er enthält	Hinweise
Lakehouse `Files/staging`	Das vollständige historische Archiv dateibasierter Quellen	Pfad `<source>/<table>/<date>/*.parquet`. Dauerhaftes Archiv, kein separater Archivordner. Parquet ist spaltenorientiert, komprimiert und bringt sein Schema mit. Wird für Compliance und Replay genutzt. Ein Integration Storage Account wird täglich (inkrementell) hierher synchronisiert.
Lakehouse `Files/active`	Nur der neueste Datumsordner pro Tabelle	Pfad `<source>/<table>/.parquet`. Aus staging mit select latest* kopiert. Wird täglich ersetzt. Er ist das Ziel der External Tables des Landing-Layers, und Replay bedeutet, ein bestimmtes Datum aus staging zu kopieren.
Landing (Warehouse)	Eine exakte 1:1-Kopie der Quelle, zur Validierung	Dateibasierte Quellen: External Tables über `Files/active`. Gespiegelte Datenbanken: der SQL Analytics Endpoint (Cross-Database-Abfrage). Copy Jobs: native Warehouse-Tabellen `landing.<source>_<table>`. Keine Duplizierung von Daten bei Dateien und gespiegelten Datenbanken. dbt fragt alle auf dieselbe Weise ab. Tests: Schemavalidierung, Zeilenanzahl, Dateneingang.
Bronze	Native Tabellen, die dbt aus allen Quellen baut	Schema `bronze.<source>_<table>`. Eine Tabelle pro Quellsystem (Source Grain). Grundlegende Bereinigung, Typkonvertierung, Deduplizierung. Tests: Eindeutigkeit, not null, gültige Werte.
Silver	Fachliche Entitäten	Schema `silver.<entity>`, zum Beispiel eine Assets-Tabelle oder eine Wartungshistorie. Joins, Lookups, Geschäftsregeln und berechnete Felder, aus allen Quellen integriert. Die Single Source of Truth für Geschäftsdaten, bereit zur Nutzung oder zur Aggregation in gold. Tests: referenzielle Integrität und Geschäftsregeln.
Gold	Aggregierte, konsumfertige Daten	Das Diagramm zeigt einen Gold-Warehouse-Layer, der das Serving speist.

Ingestion-Methoden¶

Methode	Einsatz für	Landet in
Copy files	Dateiquellen: in Lakehouse-Dateien laden, dann in eine Tabelle laden	`Files/staging`, dann `landing`
Notebook ingestion	Quellen, die Code brauchen, etwa APIs	Staging-Dateien oder `bronze.<source>_<table>`
Shortcut	Daten, die schon woanders liegen und nicht kopiert werden sollen	`Files/<shortcut>/`, dann External Tables
Copy job	Relationale Quellen, ganz oder inkrementell kopiert	`landing.<source>_<table>` als native Tabellen
Database mirroring	Datenbanken, die Fabric spiegeln kann (das Diagramm zeigt Azure SQL Database)	Gespiegelte Datenbank, über ihren SQL Endpoint abgefragt, als `<mirrored_db>.<table>`

Das Diagramm nennt Beispielquellen: Oracle, SQL Server (On-Premises), Blob Storage, SharePoint, eine API, Notebooks und Azure Databricks. On-Premises-Quellen und private Azure-Quellen werden über das VNet data gateway oder managed private endpoints erreicht (Konnektivität).

Umgebungen und Promotion¶

Das zweite Diagramm der Lösung zeigt, wie Development, Pre-Production und Production zusammenhängen.

flowchart LR
    dev["Dev workspace (linked to Git, dev branch)"] -->|"pull request and merge"| pre["Pre-prod workspace (preprod branch)"]
    pre -->|"pull request and merge"| prod["Prod workspace (prod branch)"]
    tf["Terraform and CI/CD: platform team"] -.->|"deploys infrastructure"| dev
    tf -.-> pre
    tf -.-> prod

Das Plattform-Team deployt die Infrastruktur (capacities, workspaces, Connections) mit Terraform und CI/CD, zuerst die Kernkomponenten und dann die workspaces und capacities.
Data Engineers entwickeln im Development-workspace, der mit einem Git-Branch verbunden ist. Datenmodelle werden per pull request und Merge in den Pre-Production- und dann in den Production-Branch befördert.
Production-workspaces sind im Basis-Setup nicht direkt mit Git verknüpft. Sie werden von der pipeline aktualisiert.

Plattform-Bausteine, auf die sich das Muster stützt¶

Bedarf	Geliefert von
Workspaces mit OneLake, Lakehouses und Warehouses	Servicebeschreibung
Privater Zugriff auf Quellen	Konnektivität
Git-Versionskontrolle	Konnektivität
Überwachung der pipeline-Gesundheit	Monitoring
Katalog, Klassifizierung und Lineage	Governance

dbt-Jobs, das Integration Storage Account und die Transformationszeitpläne werden nicht von der Plattform deployt. Stimme mit dem Plattform-Team ab, wer sie einrichtet.