Handbuch

Entwerfen Sie die anfängliche Datenerfassungsschicht in einer Medaillon-Architektur, um Rohdaten von Quellen zu erfassen.

→Daten mit minimaler Transformation und einem nachgiebigen Schema in die Bronze-Schicht aufnehmen.

Warum: Bewahrt die ursprüngliche Datenintegrität, einschließlich fehlerhafter Datensätze, für die Neuverarbeitung, Prüfung und Datenherkunft.

Isolierte Umgebungen und einen Promotion-Prozess für Fabric-Artefakte implementieren.

→Verwenden Sie Fabric Deployment Pipelines mit separaten Arbeitsbereichsstufen für Entwicklung, Test und Produktion.

Warum: Bietet einen strukturierten, sicheren Mechanismus, um Änderungen zu testen und Artefakte zu fördern, ohne Produktions-Workloads zu beeinträchtigen.

Quellcodeverwaltung und Genehmigungsworkflows für Änderungen an Fabric-Produktionselementen durchsetzen.

→Integrieren Sie den Fabric-Arbeitsbereich mit Azure DevOps Git. Verwenden Sie Branch-Richtlinien, um Pull-Request-Reviews durchzusetzen.

Warum: Ermöglicht Versionskontrolle, Änderungsverfolgung und obligatorische Peer-Reviews, wodurch Data Engineering an DevOps-Best Practices angepasst wird.

Umgebungsspezifische Verbindungszeichenfolgenänderungen während Pipeline-Bereitstellungen automatisieren.

→Bereitstellungsregeln in der Bereitstellungspipeline konfigurieren, um Datenquellenverbindungen für jede Phase zu parametrisieren.

Warum: Eliminiert manuelle Konfigurationen nach der Bereitstellung, reduziert Fehler und stellt sicher, dass jede Umgebung mit der richtigen Datenquelle verbunden ist.

Arbeitsbereiche für mehrere Geschäftseinheiten organisieren, die sowohl Isolation als auch gemeinsame Governance erfordern.

→Erstellen Sie separate Arbeitsbereiche pro Geschäftseinheit und gruppieren Sie diese unter Fabric Domains.

Warum: Arbeitsbereiche bieten Inhalts- und Sicherheitsisolation, während Domains eine zentralisierte Governance und Entdeckung über verwandte Arbeitsbereiche hinweg ermöglichen.

Verbessern Sie die Datenerkennung und signalisieren Sie Geschäftsanwendern die Qualität von Datensätzen.

→Beschreibungen und Tags auf Lakehouse-Tabellen anwenden und Endorsement-Labels (Promoted, Certified) verwenden.

Warum: Endorsement-Stufen schaffen Vertrauen bei den Benutzern und leiten sie zu hochwertigen, kuratierten Datensätzen für Berichterstattung und Analyse.

Eine konsistente Datenklassifizierung und -schutz über alle Fabric-Elemente hinweg sicherstellen.

→Integration mit Microsoft Purview Information Protection und Aktivierung der nachgelagerten Vererbung für Vertraulichkeitsbezeichnungen.

Warum: Automatisiert die Anwendung von Vertraulichkeitsbezeichnungen von Datenquellen auf nachgelagerte Artefakte wie semantische Modelle und Berichte und setzt so Sicherheitsrichtlinien durch.

Den primären Faktor für die Dimensionierung einer Fabric-Kapazität bestimmen.

→Analysieren Sie die gleichzeitige Abfrageausführung und die Compute-Anforderungen des Workloads.

Warum: Die Fabric-Kapazität wird durch Compute-Operationen (Capacity Units) verbraucht, nicht durch Datenvolumen. Parallelität und Job-Komplexität sind die Haupttreiber.

Sicheren, produktionsreifen Zugriff von einem Fabric-Shortcut auf ein externes ADLS Gen2-Konto bereitstellen.

→Verwenden Sie einen Service Principal mit Azure AD-Authentifizierung und weisen Sie ihm RBAC-Rollen mit den geringsten Rechten für das Speicherkonto zu.

Warum: Service Principal ist die sicherste und prüfbarste Methode, die Risiken gemeinsamer Kontoschlüssel oder SAS-Token vermeidet.

Eine nahezu Echtzeit-, schreibgeschützte Replikation einer Azure SQL Database in Fabric erstellen, ohne die Quelle zu beeinträchtigen.

→Verwenden Sie Fabric Mirroring für Azure SQL Database.

Warum: Mirroring bietet eine latenzarme, kontinuierliche Replikation von Daten in OneLake als Delta-Tabellen, ideal für Echtzeit-Analysen ohne ETL-Entwicklung.

Einen Datensatz mit einem anderen Arbeitsbereich teilen oder auf externe Daten zugreifen, ohne eine Kopie zu erstellen.

→Erstellen Sie einen Shortcut, der auf die Quell-Lakehouse-Tabelle oder den externen Datenspeicherort verweist.

Warum: Shortcuts fungieren als symbolische Links, die eine einheitliche Ansicht der Daten in OneLake bieten und gleichzeitig Datenredundanz, Speicherkosten und Synchronisierungsprobleme vermeiden.

Hochgeschwindigkeits-Streaming-Daten mit historischen Batch-Daten für eine vereinheitlichte Analyse kombinieren.

→Verwenden Sie Eventstream für die Echtzeit-Erfassung und ein Lakehouse mit Delta Lake-Tabellen für die vereinheitlichte Speicherung.

Warum: Eventstream verwaltet den Streaming-Pfad, während die ACID-Eigenschaften von Delta Lake es ermöglichen, sowohl als Ziel für Streaming-Anhängungen als auch für Batch-Updates zu dienen.

Sowohl T-SQL-basierte Analyse als auch Python-basierte Data Science auf denselben Lakehouse-Daten ermöglichen.

→Nutzen Sie den automatisch generierten SQL-Analyse-Endpunkt für das Lakehouse.

Warum: Fabric bietet Dual-Engine-Zugriff auf dieselben Delta-Tabellen: einen SQL-Endpunkt für T-SQL-Abfragen und die Spark-Engine für Notebooks, ohne Datenredundanz.

Daten von einer lokalen Datenquelle (z. B. Oracle, SQL Server) in Fabric aufnehmen.

→Ein lokales Datengateway installieren und konfigurieren.

Warum: Das Gateway fungiert als sichere Brücke, die Daten zwischen dem lokalen Netzwerk und dem Fabric-Cloud-Dienst weiterleitet, ohne die Quelle dem Internet preiszugeben.

Neue Dateien automatisch verarbeiten, sobald sie in Azure Blob Storage eintreffen.

→Verwenden Sie einen Storage Event Trigger für die Datenpipeline, der so konfiguriert ist, dass er bei Blob-Erstellungsereignissen ausgelöst wird.

Warum: Ereignisgesteuerte Trigger bieten eine geringere Latenz und sind effizienter als geplantes Polling, das Daten übersehen oder unnötig ausgeführt werden kann.

Alle Datensätze aus einer REST API extrahieren, die Daten in Seiten zurückgibt.

→Konfigurieren Sie in einer Kopieraktivität die integrierten Paginierungsregeln des REST-Konnektors. Alternativ verwenden Sie eine Until- oder ForEach-Schleife mit Variablen zur Verwaltung von Seiten-Tokens.

Warum: Automatisiert den Prozess des Iterierens durch alle API-Seiten, bis alle Daten abgerufen wurden, und handhabt dynamische Links zur nächsten Seite oder Offsets.

Logik für Slowly Changing Dimension Type 2 implementieren oder Change Data Capture (CDC)-Streams verarbeiten.

→Verwenden Sie die Delta Lake MERGE-Operation mit `WHEN MATCHED` und `WHEN NOT MATCHED` Klauseln.

Warum: MERGE bietet atomare Upsert-Funktionen (Update/Insert/Delete), die die grundlegende Operation zur Pflege historischer Datensätze in SCD2-Mustern darstellen.

Eine DataFrame-Spalte, die verschachtelte Arrays von Objekten enthält, in separate Zeilen umwandeln.

→Wenden Sie die Funktion `explode()` auf die Array-Spalte in einem PySpark-Notebook an.

Warum: `explode()` ist die Standard-Spark-Funktion zum Entschachteln von Arrays, die für jedes Element im Array eine neue Zeile erstellt.

Spät eintreffende Daten in einer zustandsbehafteten Streaming-Aggregation (z. B. fensterbasierte Zählungen) verarbeiten.

→Konfigurieren Sie ein Watermark auf der Ereigniszeitspalte in der Spark Structured Streaming-Abfrage.

Warum: Watermarking definiert einen Zeitschwellenwert, wie lange die Engine auf verspätete Daten wartet, verhindert ein unbegrenztes Wachstum des Zustands und gewährleistet gleichzeitig die Korrektheit.

Einen inkrementellen Datenimport von einem Quellsystem durchführen, das eine Zeitstempelspalte, aber keine CDC besitzt.

→Ein High-Watermark-Muster implementieren. Speichern Sie den maximalen Zeitstempel des letzten Laufs und verwenden Sie diesen, um die Quelle im nächsten Lauf zu filtern.

Warum: Dies ist ein effizientes und gängiges Muster, um nur neue oder aktualisierte Datensätze zu extrahieren, ohne den Overhead vollständiger Tabellenscans oder die Notwendigkeit formaler CDC.

Eine Pipeline-Aktivität schlägt aufgrund vorübergehender Netzwerkprobleme oder Quellsystemlast intermittierend fehl.

→Konfigurieren Sie die Wiederholungsrichtlinie der Aktivität mit einer bestimmten Anzahl und einem exponentiellen Backoff-Intervall.

Warum: Baut Resilienz in die Pipeline ein, indem fehlgeschlagene Operationen automatisch wiederholt werden, was oft vorübergehende Probleme ohne manuelles Eingreifen löst.

Große Mengen an Telemetrie- oder Protokolldaten mit geringer Latenz für Echtzeit-Explorationsanalysen aufnehmen und abfragen.

→Daten in ein Eventhouse aufnehmen und diese mit Kusto Query Language (KQL) abfragen.

Warum: Eventhouse (aufbauend auf Azure Data Explorer) und KQL sind speziell für Hochleistungs-Zeitreihen- und Log-Analysen konzipiert.

Eine einzige, wiederverwendbare Pipeline erstellen, um Dutzende von Tabellen mit derselben Transformationslogik zu laden.

→Verwenden Sie einen metadatenbasierten Ansatz. Speichern Sie Quell-/Zielinformationen in einer Steuertabelle und verwenden Sie eine ForEach-Aktivität, um zu iterieren und Parameter an eine generische untergeordnete Pipeline zu übergeben.

Warum: Dieses Muster ist hochgradig skalierbar und wartbar, wodurch die Duplizierung und der Verwaltungsaufwand beim Erstellen separater Pipelines für jede Tabelle vermieden werden.

Die Leistung eines Dataflow Gen2 optimieren, der Daten aus einer relationalen Datenbank wie SQL Server bezieht.

→Transformationen entwerfen, die gefaltet werden können. Überprüfen Sie den Query Folding-Status im Power Query-Editor.

Warum: Query Folding verschiebt die Transformationslogik auf die Quelldatenbank-Engine, was deutlich performanter ist, als alle Daten zur Transformation in die Spark-Engine zu ziehen.

Eine Tabelle abfragen, wie sie zu einem bestimmten Zeitpunkt in der Vergangenheit existierte, für eine Prüfung oder zur Wiederherstellung nach einer versehentlichen Aktualisierung.

→Verwenden Sie Delta Lake's Zeitreisefunktion mit `VERSION AS OF` oder `TIMESTAMP AS OF` in der Abfrage.

Warum: Delta Lake versioniert nativ jede Transaktion und ermöglicht so Point-in-Time-Abfragen ohne manuelle Snapshots oder Backups.

Row-Level Security (RLS) durchsetzen, wobei Benutzer nur Daten sehen sollen, die ihrer Region oder Abteilung entsprechen.

→RLS-Regeln mithilfe von DAX-Ausdrücken innerhalb des semantischen Modells implementieren.

Warum: Das semantische Modell ist die zentrale und empfohlene Schicht zur Durchsetzung von Geschäftsregeln wie RLS. Die Logik wird dynamisch basierend auf der Identität des Benutzers angewendet.

Eine Gruppe von Benutzern daran hindern, sensible Spalten (z. B. Gehalt, PII) in einer Tabelle zu sehen.

→Column-Level Security (CLS) im semantischen Modell oder Warehouse implementieren.

Warum: CLS bietet eine granulare Kontrolle, um den Zugriff auf bestimmte Spalten für festgelegte Benutzerrollen zu beschränken und sensible Daten innerhalb einer freigegebenen Tabelle zu schützen.

Einen Power BI-Bericht auf einem sehr großen Lakehouse-Datensatz mit hohen Leistungsanforderungen erstellen.

→Ein semantisches Modell im DirectLake-Modus erstellen.

Warum: DirectLake bietet die Leistung des Import-Modus, indem es Daten in den Speicher lädt, aber ohne Daten zu duplizieren, indem es direkt aus den Delta-Dateien in OneLake liest.

Die Abfrageleistung verbessern und den Kapazitätsverbrauch für Berichte mit hochrangigen Zusammenfassungen reduzieren.

→Aggregationstabellen innerhalb des semantischen Modells erstellen und konfigurieren.

Warum: Abfragen, die auf voraggregierte Daten zugreifen, sind deutlich schneller und verbrauchen weniger Ressourcen als solche, die die vollständige Detailtabelle scannen, was die Benutzererfahrung und Kosten optimiert.

Die Aktualisierungszeit und den Ressourcenverbrauch für ein großes semantisches Modell reduzieren, bei dem sich nur aktuelle Daten ändern.

→Eine inkrementelle Aktualisierungsrichtlinie für die großen Faktentabellen im semantischen Modell konfigurieren.

Warum: Dies partitioniert die Daten und aktualisiert nur die neuesten Partitionen, wodurch kostspielige vollständige Neuladungen historischer Daten, die sich nicht ändern, vermieden werden.

Die Abfrageleistung einer Delta-Tabelle hat sich aufgrund einer großen Anzahl kleiner Dateien aus der Streaming-Aufnahme verschlechtert.

→Führen Sie den `OPTIMIZE`-Befehl auf der Delta-Tabelle aus.

Warum: `OPTIMIZE` verdichtet kleine Dateien zu weniger, größeren Dateien. Dies verbessert die Leseleistung erheblich, da die Abfrage-Engine weniger Dateien öffnen muss.

Die Abfrageleistung auf einer großen Delta-Tabelle verbessern, die häufig nach einer nicht-partitionierten Spalte mit hoher Kardinalität gefiltert wird.

→Führen Sie `OPTIMIZE` mit einer `ZORDER BY`-Klausel auf den häufig gefilterten Spalten aus.

Warum: Z-Ordering platziert verwandte Daten innerhalb von Dateien zusammen, wodurch die Abfrage-Engine Datenskip verwenden kann, um weniger Daten zu lesen, was gefilterte Abfragen drastisch beschleunigt.

Die Leseleistung für Power BI-Berichte optimieren, die Delta-Tabellen in einem Fabric-Lakehouse abfragen.

→Stellen Sie sicher, dass die V-Order-Optimierung für die Delta-Tabellen aktiviert ist.

Warum: V-Order ist eine Fabric-spezifische Schreibzeitoptimierung, die die Leseleistung für die Power BI-Engine durch Verbesserung der Komprimierung und Datenreihenfolge steigert.

Speicherplatz von einer Delta-Tabelle zurückgewinnen, die aufgrund von Aktualisierungen und Löschungen eine erhebliche Historie angesammelt hat.

→Führen Sie den `VACUUM`-Befehl auf der Tabelle aus.

Warum: `VACUUM` entfernt physisch Daten­dateien, die nicht mehr von der Tabelle referenziert werden und älter als die Aufbewahrungsfrist sind, wodurch die Speicherkosten reduziert werden.

Einen Spark-Join zwischen einer sehr großen Faktentabelle und einer kleinen Dimensionstabelle optimieren.

→Verwenden Sie einen Broadcast Join, indem Sie einen Hinweis (`broadcast()`) geben, um die kleine Tabelle an alle Executoren zu senden.

Warum: Broadcasting vermeidet eine kostspielige und netzwerkintensive Shuffle-Operation der großen Tabelle, die ein großer Leistungsengpass bei großen Joins ist.

Eine Spark-Join-Operation ist langsam oder schlägt fehl, weil ein Schlüsselwert eine unverhältnismäßig große Datenmenge aufweist (Data Skew).

→Implementieren Sie eine "Salting"-Technik: Fügen Sie einen zufälligen Schlüssel zu den schiefen Werten hinzu, um sie auf mehr Partitionen zu verteilen, dann joinen und aggregieren Sie.

Warum: Salting zerlegt manuell die schiefe Partition, wodurch die Workload über alle Executoren ausgeglichen und OOM-Fehler oder langlaufende Aufgaben verhindert werden.

Ein Spark-Notebook-Job läuft langsamer als erwartet und die Ursache ist unklar.

→Verwenden Sie die Spark UI, zugänglich über das Monitoring Hub, um den Directed Acyclic Graph (DAG), die Stagedauern und Task-Details zu analysieren.

Warum: Die Spark UI bietet eine detaillierte, physische Ansicht der Abfrageausführung, die es Ihnen ermöglicht, Engpässe wie Data Skew, Spills auf Festplatte oder ineffiziente Shuffles genau zu bestimmen.

Ein Spark-Job schlägt mit einem OutOfMemoryError auf dem Treiberknoten fehl, selbst bei großem Executor-Speicher.

→Überprüfen Sie den Code auf Aktionen wie `.collect()` oder `.toPandas()`, die große Mengen verteilter Daten in den Speicher des Treiberknotens ziehen.

Warum: Der Treiber hat ein eigenes Speicherlimit. Das Sammeln eines großen DataFrames auf dem Treiber ist ein häufiges Anti-Muster, das OOM-Fehler verursacht; verwenden Sie stattdessen verteilte Operationen.

Identifizieren Sie, welche Arbeitsbereiche, Berichte oder Pipelines die meisten Compute-Ressourcen in einer Fabric-Kapazität verbrauchen.

→Installieren und analysieren Sie die Fabric Capacity Metrics App.

Warum: Diese App bietet eine detaillierte Aufschlüsselung des Verbrauchs von Capacity Units (CU) im Zeitverlauf nach Arbeitsbereich, Elementtyp und spezifischer Operation, was gezielte Optimierungen und Kostenanalysen ermöglicht.

Zentralisierte, langfristige Überwachung und Auditierung aller Aktivitäten innerhalb eines Fabric-Arbeitsbereichs implementieren.

→Konfigurieren Sie in den Fabric-Admin-Einstellungen Diagnoseeinstellungen für den Arbeitsbereich, um Protokolle an einen Azure Log Analytics-Arbeitsbereich zu streamen.

Warum: Bietet einen robusten, abfragbaren und langfristigen Speicher für alle Audit- und Betriebs-Logs, der erweiterte Überwachung, Alarmierung und Compliance-Berichterstattung ermöglicht.

Die Betriebskosten einer Fabric-Kapazität reduzieren, die vorhersehbare Inaktivitätsperioden aufweist (z. B. Nächte, Wochenenden).

→Automatisierung implementieren (z. B. über APIs und Azure Automation), um die Kapazität außerhalb der Geschäftszeiten anzuhalten und vor den Geschäftszeiten wieder aufzunehmen.

Warum: Kapazitäts-Compute ist ein primärer Kostentreiber. Das Anhalten der Kapazität stoppt die CU-Abrechnung und bietet erhebliche Kosteneinsparungen während Leerlaufzeiten.

Eine kritische Datenpipeline muss überwacht werden, und das Betriebsteam muss bei einem Fehler sofort benachrichtigt werden.

→Benachrichtigungen im Fabric Monitoring Hub konfigurieren oder Data Activator verwenden, um den Pipeline-Status zu überwachen und Benachrichtigungen auszulösen.

Warum: Proaktive Alarmierung stellt sicher, dass Fehler schnell erkannt und behoben werden, wodurch Daten-Ausfallzeiten und Auswirkungen auf Geschäftsanwender minimiert werden.