PySpark in Fabric: So setzt du Spark-Workflows sauber auf

Definition

PySpark in Fabric ist die Ausführung von PySpark-Code (Apache Spark über Python) in Microsoft Fabric, um Daten verteilt zu verarbeiten, zu transformieren und für Analysen bereitzustellen. Es ist kein Ersatz für Power-Query-Modellierung im Bericht und auch nicht für kleine lokale Skripte gedacht, sondern für wiederholbare Daten-Workflows auf einer Plattform.

Einleitung

Mit PySpark in Fabric baust du aus Rohdaten eine robuste Datengrundlage, die Fachbereiche direkt in Power BI oder Excel nutzen können. Der praktische Mehrwert: weniger manuelle Exporte, weniger „Welche Zahl stimmt?“ und schnellere Iterationen, wenn sich Quellen oder Logik ändern. Entscheidend ist, dass du PySpark nicht als Notebook-Spielwiese behandelst, sondern als Baustein in einer klaren Pipeline.

Wann ist PySpark in Fabric die richtige Wahl?

PySpark lohnt sich, wenn Datenvolumen oder Komplexität so hoch sind, dass ein „Excel + ein bisschen Power Query“ nicht mehr sauber skalieren kann. Typische Signale sind viele Quellsysteme, häufige Aktualisierungen und Regeln, die nachvollziehbar versioniert werden müssen.

• Du willst Bronze-/Silver-/Gold-Daten aufbauen, die mehrere Reports konsistent versorgen.
• Du brauchst Joins, Bereinigungen und Anreicherungen über viele Tabellen und Zeiträume.
• Du willst eine Pipeline, die planbar läuft und nicht an einer Person hängt.

Voraussetzungen und Umgebung-Setup (pragmatischer Start)

Du brauchst einen Fabric-Workspace mit Capacity und ein Lakehouse als Ziel für Daten und Tabellen. Dann startest du am besten nicht „von Notebook aus“, sondern vom Lakehouse aus: Lakehouse anlegen, anschließend ein Notebook erstellen und damit verbinden. So sind Speicherpfade und Tabellenkontext sauber gesetzt.

Minimaler Startablauf:

• Lakehouse erstellen und Ordnerstruktur für Rohdaten (Bronze) festlegen.
• Notebook verbinden, erste Tabelle schreiben (z. B. bereinigte Silver-Tabelle).
• Gold-Ergebnis so ablegen, dass Power BI es stabil konsumieren kann (klare Namen, klare Grain).

Step-by-step: Ein einfacher ETL-Workflow mit PySpark

Ein sinnvoller Einstieg ist ein bewusst kleiner End-to-End-Flow, der in wenigen Stunden einen echten Nutzen liefert. Beispielhaft als Ablauf (ohne Code-Overload):

• Ingest: Rohdaten aus Dateien oder Quellsystem-Exports in Bronze ablegen.
• Transform: Datentypen korrigieren, Dubletten entfernen, Business-Regeln anwenden.
• Publish: Ergebnis als Gold-Tabelle schreiben und für Self-Service freigeben.

Wichtig: „Gold“ heißt nicht nur zentral gespeichert, sondern verständlich und nutzbar. Also: sprechende Spaltennamen, stabile Schlüssel, dokumentierte Definitionen. Dann können auch weniger IT-affine Nutzer darauf aufbauen, ohne jedes Mal Rückfragen zu stellen.

Integration mit Fabric-Komponenten (Lakehouse, OneLake, Warehouse)

Fabric spielt seine Stärke aus, wenn du nicht nur rechnest, sondern Ergebnisse direkt in ein konsistentes Datenprodukt überführst. Das Lakehouse ist dabei der natürliche Ankerpunkt: PySpark verarbeitet Daten und schreibt sie zurück als Tabellen, die andere Fabric-Workloads weiterverwenden.

OneLake ist für Anwender vor allem deshalb wertvoll, weil „die richtige Tabelle“ auffindbar und wiederverwendbar wird. Das reduziert Schattenkopien in Excel oder lokale Zwischenstände, weil die Gold-Daten als gemeinsamer Startpunkt dienen.

Performance-Optimierung: So vermeidest du die typischen Kostenfallen

Performance-Risiken kommen selten von „Spark ist langsam“, sondern von unnötiger Arbeit: zu breite Joins, zu viele Zwischenstände, falsche Datentypen oder unklare Datenaufteilung. Ziel ist, dass Jobs schnell und reproduzierbar laufen, statt Capacity im Hintergrund zu verbrennen.

• Halte Datenmodelle schlank: lieber wenige, stabile Gold-Tabellen als viele halbfertige Artefakte.
• Vermeide unnötige Shuffles: Joins bewusst planen und nur benötigte Spalten verarbeiten.
• Baue Qualitätschecks ein: früh stoppen, wenn Schlüssel fehlen oder Volumen ausreißt.

Troubleshooting & Debugging: Wenn es „einfach nicht läuft“

Die häufigsten Fehler sind banal, kosten aber Zeit: Notebook nicht mit Lakehouse verbunden, falsche Pfade, Berechtigungen oder unerwartete Datentypen. Debugging funktioniert in Fabric am besten, wenn du schrittweise validierst: erst kleine Stichprobe, dann Vollmenge.

Praktische Routine:

• Jeden Transform-Schritt mit Volumen- und Null-Checks absichern.
• Bei Laufzeitproblemen zuerst Datenumfang und Join-Logik prüfen, nicht „mehr Ressourcen“ rufen.
• Fehler reproduzierbar machen: gleiche Eingabedaten, gleicher Notebook-Commit, klarer Run-Status.

Mini-Use-Case: Vom Excel-Monster zur Gold-Tabelle

Ein typisches Szenario: Umsatz-, Kosten- und CRM-Daten liegen in getrennten Extracts und werden monatlich in Excel zusammenkopiert. Mit PySpark in Fabric wird daraus eine Pipeline, die die Daten regelmäßig konsolidiert, Mapping-Regeln zentral hält und eine Gold-Tabelle erzeugt. Ergebnis: Power BI greift auf dieselbe Wahrheit zu, und die Abstimmungsschleifen werden deutlich kürzer.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn aus dem ersten Notebook eine produktive Datenstrecke werden soll und Themen wie Governance, Rechte, Naming, Monitoring und Übergabe sauber sitzen müssen. Auch wenn Performance- oder Cost-Risiken im Raum stehen, ist ein kurzer Architektur- und Pipeline-Check oft günstiger als Wochen „Trial and Error“.

Typische Auslöser:

• Mehrere Quellsysteme und niemand hat Zeit, eine robuste End-to-End-Pipeline aufzubauen.
• Die Fachbereiche brauchen schnell verlässliche Gold-Daten für Reporting und Planung.
• Es gibt Compliance- oder Datenhoheitsanforderungen, die dokumentiert werden müssen.