In diesem Video (Unten eingebettet) zeige ich dir, wie du in Microsoft Fabric ein sauberes, sicheres und praxisnahes Logging‑Konzept für Data‑Engineering‑Workloads aufsetzt. Dabei lernst du die komplette Architektur, Best Practices und wiederverwendbare Patterns kennen.
End‑to‑End Architektur
Du erfährst, wie die einzelnen Komponenten technisch zusammenspielen:
- Lakehouse: Ausgangspunkt deiner Rohdaten (z. B. Parquet‑Files)
- Notebook: Transformationen & Logging‑Logik
- Fabric SQL Database: Persistente Ablage der Logeinträge
- Pipeline: Weiterverarbeitung, Workflow‑Steuerung & Automation
Diese Architektur eignet sich ideal für produktionsreife Data‑Engineering‑Prozesse in Microsoft Fabric.
Sicheres Setup mit Azure Key Vault
Wir verwenden Azure Key Vault, um alle benötigten Secrets (z. B. JDBC‑Connection Strings) sicher abzulegen.
➡️ Keine Credentials im Code. Best Practice für jede produktionsnahe Umgebung.
Logging mit Struktur
Du lernst, wie du in Notebooks automatisiert, einheitlich und reproduzierbar loggst:
- Wiederverwendbare Python‑Funktion für strukturierte Logeinträge
- Konsistentes Logging pro Notebook‑Step
- Erfassung von Start/Endzeit, Status, Messages, Error‑Details
So entsteht ein vollständiger, nachvollziehbarer Audit‑Trail deiner Verarbeitung.
Persistenz in einer SQL‑Logtabelle
Alle Logs werden über JDBC in eine dedizierte SQL‑Tabelle geschrieben:
- Saubere Trennung zwischen Datenverarbeitung & Logging
- SQL‑basiert auswertbar (z. B. via T‑SQL, Power BI, Notebooks)
Weiterverarbeitung in Pipelines
Die erzeugten Logs können direkt in Fabric-Pipelines genutzt werden, etwa für:
- Lookup‑Aktivitäten: Status-Abfragen
- If‑Conditions: Automatisierte Fehlerpfade
- Alerts/Benachrichtigungen : Proaktives Monitoring
So baust du robuste, workflowfähige Data‑Engineering‑Prozesse.
Warum das wichtig ist
Ein standardisiertes Logging bildet die Grundlage für professionelle Data Workloads:
- Transparente Runs: Dauer, Status und Fehler jederzeit nachvollziehbar
- SQL‑auswertbar: Keine zusätzlichen Tools oder Services notwendig
- Monitoring & Troubleshooting: Sofortige Identifikation von Problemen
- Automatisierung: Grundlage für Alerts, Retry‑Logik & Governance
- Praxistauglich: Ideal für produktive Fabric‑Projekte
Demo‑Assets im Video
Im Video kommen folgende Beispiel‑Artefakte zum Einsatz:
- Parquet‑Files im Lakehouse (Input‑Daten)
- Staging‑Table für den Datenfluss
- Log‑Tabelle in der Fabric SQL Database (für Auswertung & Monitoring)
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen