Python für Data Engineering – pandas, Jupyter, PySpark und Azure aus einer Hand

Positionierung

Python hat sich in den vergangenen Jahren zur dominanten Sprache im Data Engineering entwickelt. Was einst ein Nischenthema für Datenwissenschaftler war, ist heute die Grundlage für Datenplattformen in Unternehmen aller Grossen. Der Grund liegt auf der Hand: Python verbindet eine lesbare Syntax mit einem Ökosystem, das praktisch jede Anforderung im Datenbereich abdeckt – von der einfachen CSV-Verarbeitung über komplexe Transformationen mit pandas bis zum verteilten Schreiben von Delta-Lake-Tabellen in Databricks. Ich arbeite seit vielen Jahren mit Python im Kontext von Data Engineering, Business Intelligence und Cloud-Plattformen. Die Kombination aus SQL-Server-Erfahrung, Azure-Kenntnissen und Python-Know-how erlaubt es mir, Datenlösungen zu bauen, die laufen, wartbar sind und sich in bestehende Unternehmensarchitekturen einpassen.

Was mich in Python-Projekten von reinen Data-Science-Profilen unterscheidet, ist der Engineering-Fokus. Es geht mir nicht primär um Modellbau oder Machine Learning, sondern darum, Daten zuverlässig von A nach B zu bringen: extrahieren, bereinigen, transformieren, validieren, persistieren. Wer im Data Engineering arbeitet, muss verstehen, wie SQL-Server-Quellsysteme abgefragt werden, wie man performante pandas-Transformationen schreibt, wie man Parquet-Dateien für nachgelagerte BI-Werkzeuge optimiert und wie man Pipelines in Azure Data Factory oder Synapse orchestriert. Dieses vollständige Bild bringe ich mit.

In der Praxis bedeutet das konkret: Ich habe für einen Textil- und Servicedienstleister Extraktionsstrecken aus SQL-Server-Systemen aufgebaut, die Rohdaten als Parquet- und Delta-Dateien in Azure Blob Storage schrieben und von Databricks-Notebooks weiterverarbeitet wurden. Die statistische Auswertung von HR- und Controlling-Daten lief in Jupyter Notebooks, die gleichzeitig als Dokumentation dienten. Die Azure-Synapse-Dataflows und ADF-Pipelines orchestrierten die Ausführungs­reihenfolge. Dieses Zusammenspiel – Python als Verarbeitungs-kern, Azure als Plattform, Databricks als Skalierungsschicht – ist das Muster, das ich in Enterprise-Data-Engineering-Projekten immer wieder realisiere.

Python im Datenumfeld

Die Nachfrage nach Python-Kenntnissen in Data-Engineering-Projekten ist in den letzten Jahren stark gestiegen. Mehrere Entwicklungen treiben diese Nachfrage: Erstens haben Cloud-Plattformen wie Azure Databricks und Azure Synapse Analytics Python als Erstklassige Sprache etabliert – Databricks-Notebooks sind im Wesentlichen Python- und PySpark-Notebooks. Zweitens hat das pandas-Ökosystem eine Reife erreicht, die es für Transformationsaufgaben in der Datenverarbeitungskette genuinne SQL-Alternativen bietet: JOINs, GroupBy-Aggregationen, Pivots und Datenbereinigung sind in pandas mindestens so präzise formulierbar wie in T-SQL, aber flexibler in der Handhabung komplexer Logik. Drittens ermöglicht Jupyter der Kombination von Code, Dokumentation und Visualisierung in einem einzigen Notebook, was die explorative Datenanalyse und die Kommunikation von Ergebnissen grundlegend verändert hat.

Warum Python heute in Enterprise-Projekten unverzichtbar ist

Früher war Python in grossen Unternehmen häufig eine Randerscheinung – ein Skripting-Werkzeug für Ad-hoc-Aufgaben. Das hat sich grundlegend geändert. Azure Databricks wird heute von zahlreichen Grossunternehmen als zentraler Baustein ihrer Datenplattform eingesetzt, und Databricks-Notebooks laufen in Python oder PySpark. Azure Data Factory kann Python-Aktivitäten direkt aufrufen. Azure Synapse Analytics bietet native Spark-Notebooks. Wer in diesen Umgebungen arbeitet, kommt an Python nicht vorbei. Ich bringe die Erfahrung aus realen Enterprise-Projekten mit: Ich weiss, wie man Python-Code schreibt, der nicht nur lokal läuft, sondern auch in Databricks-Clustern skaliert und in Azure-Pipelines eingebettet werden kann.

Das Python-Ökosystem im Data-Engineering-Kontext

Das Python-Daten-Ökosystem ist breit und tief zugleich. Im Kern steht pandas für tabellarische Datenverarbeitung. NumPy liefert die numerische Grundlage. pyodbc und SQLAlchemy ermöglichen den Datenbankzugriff auf SQL Server, Oracle und andere Systeme. pyarrow und fastparquet sind die Brücken zum Parquet-Format. PySpark bringt Spark-Verarbeitung nach Python. Great Expectations und Pandera sind Frameworks für Datenvalidierung. Matplotlib, seaborn und plotly ermöglichen Visualisierungen. openpyxl und xlrd verbinden Python mit Excel-Ausgaben für Fachabteilungen. Dieses Ökosystem ist der Grund, warum Python so mächtig im Datenbereich ist: Für praktisch jede Anforderung gibt es eine ausgereifte Bibliothek.

• pandas: DataFrames, Bereinigung, Joins, GroupBy, Pivot, Reshaping
• NumPy: Numerische Berechnungen, Vektoroperationen, statistische Grundfunktionen
• pyodbc / SQLAlchemy: SQL-Server-Anbindung, Connection Pooling, ORM-Schicht
• pyarrow / fastparquet: Lesen und Schreiben von Parquet-Dateien
• PySpark: Verteilte Verarbeitung in Databricks und Synapse-Spark-Pools
• Great Expectations / Pandera: Datenvalidierung und Schema-Prüfung
• Jupyter / JupyterLab: Interaktive Notebooks für Analyse und Dokumentation
• Azure SDKs (azure-storage-blob, azure-synapse): Cloud-Integration

pandas: DataFrames, Cleaning, Joins, GroupBy

pandas ist das Herzstuck meines Python-Toolkits für Data Engineering. Die Bibliothek bietet eine mächtige Abstraktion über tabellarische Daten: den DataFrame. Ein DataFrame verhält sich ähnlich wie eine SQL-Tabelle, ist aber flexibler: Spalten können dynamisch hinzugefügt, transformiert und entfernt werden; Zeilenoperationen laufen vektorisiert und damit performant; komplexe Logik lässt sich in lesbarer Python-Syntax ausdrücken. In der täglichten Data-Engineering-Praxis setze ich pandas hauptsächlich für drei Aufgaben ein: Datenbeschaffung und -ladung, Bereinigung und Transformation sowie Aggregation und Ausgabe.

DataFrames laden und erkunden

Der einfachste Weg, Daten in einen pandas-DataFrame zu laden, ist read_sql() mit einer SQLAlchemy-Connection – das Ergebnis ist ein sofort nutzbarer DataFrame. Für sehr grosse Tabellen verwende ich chunksize, um den Speicherverbrauch zu kontrollieren. Das initiale Erkunden mit shape, dtypes, describe() und isnull().sum() gibt sofort Auskunft über Datenvolumen, Typen und fehlende Werte – das ist die Grundlage für jede Bereinigungsstrategie.

Datenbereinigung: fehlende Werte, Typen, Duplikate

Echte Quelldaten sind selten sauber. Fehlende Werte, fehlerhafte Typen, Duplikate und inkonsistente Schreibweisen sind der Normalfall. pandas bietet für jeden dieser Fälle die richtigen Methoden: fillna() und dropna() behandeln NaN-Werte; astype() konvertiert Typen; drop_duplicates() entfernt Duplikate; str.strip(), str.upper() und str.replace() normalisieren Zeichenketten. Eine gut strukturierte Bereinigungsfunktion, die diese Schritte systematisch durchführt, ist der erste Baustein jeder robusten Pipeline.

Joins, Merges und GroupBy

pandas merge() implementiert SQL-artige JOINs (INNER, LEFT, RIGHT, OUTER) zwischen DataFrames. Für einfache Index-basierte Joins gibt es join(). GroupBy-Aggregationen mit groupby().agg() entsprechen GROUP BY in SQL, sind aber flexibler: Man kann beliebige Aggregationsfunktionen übergeben, einschliesslich benutzdefinierter Lambda-Funktionen. pivot_table() und crosstab() erzeugen Pivot-Auswertungen. Diese Kombination deckt nahezu alle relationalen Transformationsanforderungen ab.

Typische Extraktions- und Transformationspipeline: SQL Server als Quelle, Python mit pyodbc/SQLAlchemy für die Extraktion, pandas für Bereinigung und Transformation, Parquet/Delta Lake als Ausgabeformat in Azure Blob Storage.

import pandas as pd
import sqlalchemy as sa
import pyarrow as pa
import pyarrow.parquet as pq
from datetime import date

# ── Verbindung zu SQL Server aufbauen (Windows-Authentifizierung) ──────────
engine = sa.create_engine(
    "mssql+pyodbc://servername/datenbankname"
    "?driver=ODBC+Driver+17+for+SQL+Server&trusted_connection=yes"
)

# ── Rohdaten laden: Bestellungen und Artikel ───────────────────────────────
sql_bestellungen = (
    "SELECT b.bestellung_id, b.kunde_id, b.bestelldatum, "
    "b.status, b.betrag_brutto "
    "FROM dbo.bestellungen b "
    "WHERE b.bestelldatum >= '2024-01-01'"
)
sql_artikel = "SELECT artikel_id, bezeichnung, kategorie FROM dbo.artikel"

df_bestellungen = pd.read_sql(sql_bestellungen, engine)
df_artikel      = pd.read_sql(sql_artikel,      engine)

# ── Bereinigung: fehlende Werte, Typen, Duplikate ─────────────────────────
df_bestellungen["betrag_brutto"] = pd.to_numeric(
    df_bestellungen["betrag_brutto"], errors="coerce"
)
df_bestellungen.dropna(subset=["betrag_brutto"], inplace=True)
df_bestellungen.drop_duplicates(subset=["bestellung_id"], inplace=True)
df_bestellungen["status"] = df_bestellungen["status"].str.strip().str.upper()
df_bestellungen["bestelldatum"] = pd.to_datetime(df_bestellungen["bestelldatum"])

# ── LEFT JOIN: Bestellungen mit Artikelstamm zusammenfuehren ──────────────
df_merged = df_bestellungen.merge(
    df_artikel,
    how="left",
    left_on="artikel_id",
    right_on="artikel_id"
)

# ── GroupBy-Aggregation: Umsatz je Kategorie und Monat ─────────────────────
df_merged["monat"] = df_merged["bestelldatum"].dt.to_period("M")
df_agg = (
    df_merged
    .groupby(["kategorie", "monat"])
    .agg(
        anzahl_bestellungen=("bestellung_id", "count"),
        umsatz_gesamt=("betrag_brutto", "sum"),
        umsatz_mittel=("betrag_brutto", "mean"),
    )
    .reset_index()
)

# ── Ergebnis als Parquet-Datei speichern (partitioniert nach Monat) ─────────
tabelle = pa.Table.from_pandas(df_agg)
pq.write_to_dataset(
    tabelle,
    root_path="/mnt/datalake/bestellungen_agg",
    partition_cols=["monat"],
)
print(f"Gespeichert: {len(df_agg)} Zeilen, {df_agg['umsatz_gesamt'].sum():.2f} EUR Gesamtumsatz")

Dieses Beispiel zeigt den vollständigen Weg: SQL-Server-Anbindung über SQLAlchemy, Datenbereinigung, LEFT JOIN zwischen zwei DataFrames, GroupBy-Aggregation und partitioniertes Schreiben als Parquet-Dataset. ASCII-Kommentare im deutschen Stil machen den Code wartbar.

Jupyter Notebooks: Explorative Analyse und Dokumentation

Jupyter Notebooks haben die Art und Weise, wie Datenanalysen durchgeführt und kommuniziert werden, grundlegend verändert. Ein Notebook verbindet ausführbaren Python-Code mit Markdown-Dokumentation, mathematischen Formeln und Visualisierungen in einem einzigen Dokument. Das Ergebnis ist nicht nur ein Analyseergebnis, sondern gleichzeitig dessen Dokumentation und Reproduktionsanleitung. Für mich sind Jupyter Notebooks das bevorzugte Werkzeug für explorative Datenanalyse, für die Entwicklung und das Testen neuer Transformationslogik und für die Präsentation von Analyseergebnissen gegenüber Fachabteilungen.

Explorative Analyse: Daten verstehen bevor man sie transformiert

Bevor ich eine Datenpipeline aufbaue, erkunde ich die Quelldaten systematisch in einem Jupyter Notebook. Das typische Vorgehen: Daten laden, shape und dtypes prüfen, Verteilungen mit describe() und value_counts() untersuchen, fehlende Werte visualisieren und korrelierte Spalten identifizieren. Diese explorative Phase dauert typischerweise wenige Stunden, spart aber Tage an Debugging später in der Pipeline, weil Probleme im Quellmaterial frühzeitig sichtbar werden.

Notebooks als lebendige Dokumentation

Ein gut strukturiertes Jupyter Notebook ist mehr als ein Skript – es ist ein nachvollziehbares Protokoll der Analyseschritte. Markdown-Zellen erklären, warum eine Bereinigungsentscheidung getroffen wurde; Code-Zellen zeigen, wie sie umgesetzt wurde; Ausgabezellen belegen das Ergebnis. Dieses Prinzip – Code, Entscheidung und Ergebnis in einer einzigen Datei – ist für Auftraggeber und nachfolgende Entwickler gleich wertvoll: Der Analyseprozess ist reproduzierbar, nachvollziehbar und veränderbar. Ich nutze nbconvert, um Notebooks als HTML-Reports zu exportieren, die ohne Python-Kenntnisse gelesen werden können.

Databricks Notebooks und die Übergabe an Pipelines

Databricks-Notebooks sind im Grunde erweiterte Jupyter-Notebooks, die auf einem Spark-Cluster laufen. Was lokal in einem Jupyter-Notebook als pandas-DataFrame entwickelt wurde, lässt sich in Databricks auf einen PySpark-DataFrame migrieren und auf grosse Datenmengen skalieren. Ich entwickle typischerweise Logik in einem lokalen Jupyter-Notebook gegen eine repräsentative Stichprobe der Daten, teste und dokumentiere dort, und portiere dann die finale Logik in ein Databricks-Notebook, das als Teil einer ADF-Pipeline oder eines Databricks-Workflow-Jobs ausgeführt wird.

import pandas as pd
import matplotlib.pyplot as plt
import matplotlib
import warnings

matplotlib.use("Agg")    # kein interaktives Fenster benoetigt
warnings.filterwarnings("ignore")

# ── Beispieldaten laden (hier: CSV-Datei, in Praxis: SQL Server) ──────────
df = pd.read_csv("controlling_export.csv", sep=";", encoding="utf-8-sig",
                 parse_dates=["buchungsdatum"])

# ── Ueberblick: Form, Typen, fehlende Werte ───────────────────────────────
print("Form:   ", df.shape)
print("Typen:
", df.dtypes)
print("NaN-Anteil:
", df.isnull().mean().round(3))

# ── Verteilung der Kostenstellen analysieren ──────────────────────────────
df["kostenstelle"].value_counts().head(10).plot(
    kind="barh", figsize=(9, 5),
    title="Top-10 Kostenstellen nach Buchungsanzahl",
    color="#2563eb"
)
plt.tight_layout()
plt.savefig("top10_kostenstellen.png", dpi=120)
plt.close()

# ── Monatliche Summen je Kostenart ─────────────────────────────────────────
df["monat"] = df["buchungsdatum"].dt.to_period("M")
monatswerte = (
    df.groupby(["monat", "kostenart"])["betrag"]
    .sum()
    .unstack(fill_value=0)
)
print("
Monatliche Kostenarten (Auszug):")
print(monatswerte.tail(6))

# ── Ausreisser: Buchungen ueber dem 99. Perzentil ─────────────────────────
p99 = df["betrag"].quantile(0.99)
ausreisser = df[df["betrag"] > p99][["buchungsdatum", "kostenstelle", "betrag"]]
print(f"
Ausreisser (> P99 = {p99:.2f} EUR): {len(ausreisser)} Buchungen")
print(ausreisser.head())

# ── Ergebnis als CSV fuer Weitergabe sichern ──────────────────────────────
ausreisser.to_csv("ausreisser_report.csv", index=False)
print("Analyse abgeschlossen. Ergebnis gespeichert.")

Dieses Notebook-Snippet zeigt das explorative Analyse-Muster: Daten laden, Grundstatistiken prüfen, visualisieren und Ausreisser identifizieren. In der Praxis läuft dieses Muster direkt in JupyterLab oder als Databricks-Notebook.

Extraktion SQL Server → Parquet / Delta

Die Extraktion von Daten aus SQL-Server-Quellsystemen und deren Ablage als Parquet- oder Delta-Dateien ist ein zentrales Muster in modernen Datenpipelines. Das klassische SSIS-basierte ETL läuft direkt auf dem SQL Server und schreibt in eine andere SQL-Server-Datenbank. Das moderne Muster dagegen extrahiert aus SQL Server via Python und schreibt in ein Cloud-Data-Lake in Azure Blob Storage – als Parquet-Dateien für einfache Lesbarkeit oder als Delta-Tabellen für ACID-Transaktionen und Time-Travel-Funktionalität. Ich habe dieses Muster in realen Projekten implementiert und kenne die Fallstricke: Verbindungsstabilität bei grossen Datenmengen, Zeichensatz-Probleme bei NVARCHAR-Spalten, DateTime-Konvertierungen und die richtige Partitionierungsstrategie für den Ziel-Data-Lake.

pyodbc und SQLAlchemy: Verbindung zu SQL Server

Für den SQL-Server-Zugriff aus Python heraus gibt es zwei gängige Bibliotheken: pyodbc ist ein direkter ODBC-Treiber-Wrapper, der für einfache Abfragen und Bulk-Reads hervorragend geeignet ist. SQLAlchemy bietet darüber hinaus eine ORM-Schicht, Connection Pooling und einen standardisierten Dialekt-Layer, der den Wechsel zwischen Datenbanktypen vereinfacht. Für pandas read_sql() empfehle ich immer SQLAlchemy als Connection-Objekt, weil es am besten mit dem pandas-Internen Batching harmoniert. Bei Azure SQL und Entra-ID-Authentifizierung (ehemals Azure AD) nutze ich den ODBC Driver 18 mit dem Authentication=ActiveDirectoryInteractive-Parameter oder Managed Identity für headless Pipelines.

Chunked Reads für grosse Tabellen

Sehr grosse Tabellen können nicht in einem Zug in den Arbeitsspeicher geladen werden. pandas read_sql() unterstützt den chunksize-Parameter, der die Tabelle in Blöcke von N Zeilen aufteilt und jeweils einen Iterator über DataFrames zurückgibt. Jeder Chunk kann sofort als Parquet-Datei geschrieben werden. Das Ergebnis ist ein partitioniertes Parquet-Dataset, das auch bei Tabellen mit Millionen von Zeilen zuverlässig läuft, ohne den Arbeitsspeicher zu erschöpfen. Für noch größere Volumina setze ich auf PySpark in Databricks, das die Extraktion verteilt ausführen kann.

Dreistufige Medallion-Architektur: Bronze (Rohdaten, direkt aus SQL Server extrahiert), Silber (bereinigt und validiert durch pandas-Transformationen), Gold (aggregiert und BI-bereit, als Delta-Tabelle in Databricks gespeichert).

Parquet als universelles Austauschformat

Parquet ist das bevorzugte Spaltenformat für Data-Lake-Architekturen: Es komprimiert stark (typisch 3–10x gegenüber CSV), unterstützt Predicate Pushdown, um bei Abfragen nur relevante Spalten und Zeilen zu lesen, und ist sprachunabhängig – Python, Spark, SQL Server PolyBase, Azure Synapse und Power BI können alle nativ mit Parquet arbeiten. Für das Schreiben von Parquet nutze ich pyarrow als Backend, das schneller und speichereffizienter ist als fastparquet für die meisten Anwendungsfälle.

PySpark und Databricks

PySpark ist die Python-Schnittstelle zu Apache Spark und die Sprache, in der Databricks-Notebooks hauptsächlich geschrieben werden. Während pandas DataFrame-Operationen auf einem einzelnen Rechner laufen, skaliert PySpark auf Cluster-Größe: Ein Databricks-Cluster kann Hunderte von Kernen und Terabytes Arbeitsspeicher bereitstellen, um auch sehr grosse Datenmengen in vertretbarer Zeit zu verarbeiten. Für Data-Engineering-Aufgaben in Enterprise-Projekten bedeutet das: Wenn die Datenmenge die Kapazität eines einzelnen Rechners übersteigt oder wenn eine sehr kurze Verarbeitungszeit gefordert ist, ist PySpark das richtige Werkzeug.

PySpark vs. pandas: Wann welches Werkzeug?

pandas ist ideal für Datensätze bis zu einigen Gigabytes, die vollständig in den Arbeitsspeicher passen. Es ist einfacher zu schreiben, zu debuggen und zu testen. PySpark wird dann eingesetzt, wenn Daten die Größe eines einzelnen Rechners übersteigen, wenn verteilte Ausführungs­parallelität benötigt wird oder wenn die Infrastruktur sowieso ein Databricks-Cluster ist und die Verarbeitung dort eingebettet laufen soll. In der Praxis setze ich oft beide ein: pandas für die Entwicklung und das Prototyping, PySpark für die skalierte Produktion in Databricks.

Databricks als Ausführungsumgebung

Databricks vereint Spark-Cluster-Management, Notebook-Entwicklung, Workflow-Orchestrierung und Delta-Lake-Unterstützung in einer einzigen Plattform. In einem Projekt für einen Textil- und Servicedienstleister habe ich Databricks-Notebooks erstellt, die Daten aus SQL-Server-Quellen extrahierten, als Delta-Tabellen persistierten und über Azure Synapse Analytics für BI-Berichte zugreifbar machten. Die Databricks-Jobs liefen als Teil einer Azure-Data-Factory-Pipeline und wurden täglich um 3 Uhr morgens ausgeführt.

# Dieses Notebook laeuft auf einem Databricks-Cluster (PySpark-Kontext verfuegbar)
from pyspark.sql import SparkSession
from pyspark.sql import functions as F
from pyspark.sql.types import StructType, StructField, StringType, DoubleType, DateType

# ── Spark-Session (in Databricks implizit verfuegbar als 'spark') ─────────
spark = SparkSession.builder.getOrCreate()

# ── JDBC-Verbindung zu SQL Server (Credentials via Databricks Secrets) ────
jdbc_url = (
    "jdbc:sqlserver://mein-server.database.windows.net:1433;"
    "database=Quelldatenbank;encrypt=true;trustServerCertificate=false;"
    "hostNameInCertificate=*.database.windows.net;loginTimeout=30"
)
jdbc_props = {
    "user":     dbutils.secrets.get("kv-scope", "sql-user"),
    "password": dbutils.secrets.get("kv-scope", "sql-password"),
    "driver":   "com.microsoft.sqlserver.jdbc.SQLServerDriver",
    # Parallelisierung: Spark liest in 8 Partitionen gleichzeitig
    "numPartitions": "8",
    "partitionColumn": "bestellung_id",
    "lowerBound": "1",
    "upperBound": "10000000",
}

# ── Quelltabelle als Spark-DataFrame laden ───────────────────────────────
df_roh = spark.read.jdbc(
    url=jdbc_url,
    table="dbo.bestellungen",
    properties=jdbc_props,
)

# ── Bereinigung und Transformation in PySpark ─────────────────────────────
df_clean = (
    df_roh
    .filter(F.col("status").isin(["ABGESCHLOSSEN", "VERSENDET"]))
    .withColumn("betrag_netto",  F.round(F.col("betrag_brutto") / 1.19, 2))
    .withColumn("jahr_monat",    F.date_format("bestelldatum", "yyyy-MM"))
    .dropDuplicates(["bestellung_id"])
)

# ── Aggregation: Umsatz je Monat und Kategorie ────────────────────────────
df_agg = (
    df_clean
    .groupBy("jahr_monat", "kategorie")
    .agg(
        F.count("bestellung_id").alias("anzahl"),
        F.sum("betrag_netto").alias("umsatz_netto"),
        F.avg("betrag_netto").alias("umsatz_mittel"),
    )
    .orderBy("jahr_monat", "kategorie")
)

# ── Als Delta-Tabelle schreiben (ueberschreiben bei jedem Lauf) ───────────
delta_pfad = "abfss://datalake@mystorageaccount.dfs.core.windows.net/gold/umsatz_agg"
df_agg.write.format("delta").mode("overwrite").save(delta_pfad)

print(f"Delta-Tabelle geschrieben: {df_agg.count()} Zeilen")

Dieses Notebook zeigt die vollständige PySpark-Pipeline in Databricks: JDBC-Extraktion aus SQL Server mit parallelen Partitionen, Bereinigung und Aggregation in PySpark, Schreiben als Delta-Tabelle in Azure Data Lake Storage Gen2. Credentials werden sicher über Databricks Secrets (Azure Key Vault) geladen.

Delta Lake: ACID-Transaktionen und Time Travel

Delta Lake ist ein Open-Source-Storage-Layer, der auf Parquet-Dateien aufbaut und diese um ACID-Transaktionen, Schema-Enforcement, Update/Delete/Merge-Operationen und Time-Travel-Funktionalität erweitert. In Databricks ist Delta Lake der Standard-Speicherformat: Wenn man in Databricks eine Tabelle erstellt, ist sie standardmäßig eine Delta-Tabelle. Ich habe Delta Lake in Produktionsprojekten eingesetzt und kenne den Mehrwert gegenüber reinen Parquet-Dateien: MERGE-Operationen ermöglichen Upsert-Logik (neu einfügen, falls nicht vorhanden; aktualisieren, falls vorhanden), die klassisches Slowly-Changing-Dimension-Handling in reines SQL ähnlicher Lösung umsetzt. Time Travel erlaubt es, eine ältere Version der Tabelle abzufragen – ein enormer Vorteil beim Debugging und bei der Fehlersuche in Pipelines.

MERGE in Delta Lake: Upsert-Logik

Das MERGE-Kommando in Delta Lake entspricht MERGE (UPSERT) in SQL Server und ist eines der mächtigsten Features von Delta. In einer typischen Extraktionsstrecke werden neue Datensätze eingefügt und bestehende aktualisiert, ohne die gesamte Tabelle zu überschreiben. Das reduziert Schreibvolumen erheblich und macht Pipelines idempotent: Ein erneuter Lauf der Pipeline verändert das Ergebnis nicht, wenn sich die Quelldaten nicht verändert haben.

Partitionierung und Z-Ordering

Delta-Tabellen können nach einer oder mehreren Spalten partitioniert werden, was Leseanfragen beschleunigt, die Filter auf diese Spalten setzen. Darüber hinaus unterstützt Delta Lake Z-Ordering, eine Datenorganisierung, die mehrere Spalten gleichzeitig optimiert, indem ähnliche Werte physisch nah beieinander in den Parquet-Dateien abgelegt werden. Für typische BI-Abfragen, die nach Datum und Kategorie filtern, kann Z-Ordering die Abfragezeit um den Faktor 5–10 reduzieren.

• ACID-Transaktionen: Atomare Schreiboperationen, kein partieller Schreibzustand
• Schema-Enforcement: Abweichende Spalten in Eingabedaten werden abgelehnt
• Schema Evolution: Neue Spalten können gezielt hinzugefügt werden
• MERGE/UPSERT: Einfügen und Aktualisieren in einem Schritt, idempotent
• Time Travel: Ältere Versionen der Tabelle abfragen (Tage oder Versionsnummern)
• VACUUM: Alte Dateiversionen bereinigen, Speicher freigeben
• Optimize + Z-Order: Kleine Dateien zusammenfassen, Abfrageperformance verbessern

Datenvalidierung mit Python

Datenqualität ist keine optionale Anforderung, sondern die Grundvoraussetzung für verlassliche BI-Berichte und Analysen. In der Praxis sind Quelldaten häufig fehlerhaft: referenzielle Integrität wird nicht erzwungen, Pflichtfelder sind leer, Beträge liegen ausserhalb plausibler Bereiche, Datumswerte kommen im falschen Format. Wer diese Probleme nicht systematisch abfängt, lässt Fehler unbemerkt in den Data Lake wandern, wo sie später in BI-Berichten auftauchen – zu einem Zeitpunkt, an dem die Ursache schwer zurückzuverfolgen ist. Python bietet mehrere Ansätze zur Datenvalidierung, die ich je nach Projektanforderung einsetze.

Einfache Assertions in pandas

Für schnelle Prüfungen in Extraktions-Notebooks genügen pandas-Assertions: assert df['betrag'].ge(0).all() prüft, ob alle Beträge nicht-negativ sind. assert df['kunde_id'].notna().all() prüft auf vollständige Pflichtfelder. assert df.duplicated('bestellung_id').sum() == 0 prüft auf eindeutige Schlüssel. Diese Assertions werden direkt nach der Datenladung ausgeführt; bei Verletzung wirft Python einen AssertionError, der die Pipeline unterbricht und im Log protokolliert.

Pandera für schema-basierte Validierung

Pandera ist eine Bibliothek, die pandas DataFrames gegen ein deklarativ definiertes Schema validiert. Das Schema spezifiziert erlaute Datentypen, Wertebereiche, Nullable-Eigenschaften und benutzerdefinierte Checks. Wenn der DataFrame das Schema verletzt, liefert Pandera einen detaillierten Fehlerbericht mit Zeilen- und Spaltenangabe. In Produktionspipelines binde ich Pandera-Validierungen zwischen Extraktion und Transformation ein: Die Extraktion liefert Rohdaten; Pandera prüft diese; erst wenn die Prüfung bestanden ist, startet die Transformation. Das reduziert die Anzahl kryptischer Fehlermeldungen später im Prozess erheblich.

import pandas as pd
import pandera as pa
from pandera import Column, DataFrameSchema, Check
import logging

logger = logging.getLogger(__name__)

# ── Pandera-Schema fuer die Bestellungstabelle definieren ─────────────────
bestellungen_schema = DataFrameSchema(
    columns={
        "bestellung_id": Column(int,   nullable=False, unique=True),
        "kunde_id":       Column(int,   nullable=False),
        "bestelldatum":   Column("datetime64[ns]", nullable=False),
        "betrag_brutto":  Column(float, Check.ge(0.0),  nullable=False),
        "status":         Column(str,
                                 Check.isin(["NEU", "VERSENDET", "ABGESCHLOSSEN", "STORNIERT"]),
                                 nullable=False),
    },
    # Keine unbekannten Spalten erlaubt
    strict=False,
)

def validiere_bestellungen(df: pd.DataFrame) -> pd.DataFrame:
    # Validiert einen Bestellungen-DataFrame gegen das definierte Schema.
    # Gibt den validierten DataFrame zurueck oder wirft einen Fehler.
    # Logging-Ausgabe auf INFO-Niveau.
    # Schritt 1: Einfache Assertions (schnell, keine Bibliothek noetig)
    assert df["bestellung_id"].notna().all(),  "FEHLER: Leere Bestellungs-IDs gefunden"
    assert not df.duplicated("bestellung_id").any(), "FEHLER: Doppelte Bestellungs-IDs"
    assert (df["betrag_brutto"] >= 0).all(),   "FEHLER: Negative Betraege in Quelldaten"

    # Schritt 2: Pandera-Schema-Validierung (detaillierte Fehlermeldung)
    try:
        df_valid = bestellungen_schema.validate(df, lazy=True)
        logger.info("Validierung erfolgreich: %d Zeilen geprueft", len(df_valid))
        return df_valid
    except pa.errors.SchemaErrors as e:
        # Fehlende Zeilen und Spalten im Log ausgeben
        logger.error("Schema-Fehler:
%s", e.failure_cases.to_string())
        raise

# ── Verwendung in der Pipeline ────────────────────────────────────────────
if __name__ == "__main__":
    import sqlalchemy as sa
    engine  = sa.create_engine("mssql+pyodbc://srv/db?driver=ODBC+Driver+17+for+SQL+Server&trusted_connection=yes")
    df_roh  = pd.read_sql("SELECT * FROM dbo.bestellungen WHERE bestelldatum >= '2024-01-01'", engine)
    df_ok   = validiere_bestellungen(df_roh)
    print(f"Validierung bestanden: {len(df_ok)} Zeilen bereit fuer Transformation.")

Diese Validierungsfunktion kombiniert einfache pandas-Assertions mit Pandera-Schema-Validierung. Das lazy=True-Flag sorgt dafür, dass alle Fehler gesammelt und auf einmal gemeldet werden – nicht nur der erste Fehler.

Statistische Auswertungen mit Python

In Data-Engineering-Projekten geht es selten nur um das Verschieben von Daten. Häufig kommen statistische Auswertungen hinzu: Verteilungsanalysen, Ausreisser-erkennung, Zeitreihenanalysen, Korrelationsanalysen und Aggregationen, die über einfache Summen und Mittelwerte hinausgehen. Ich habe für einen Textil- und Servicedienstleister statistische Auswertungen für HR- und Controlling-Daten in Jupyter Notebooks implementiert: monatliche Abweichungsanalysen, Perzentil-basierte Ausreissererkennung, Trendanalysen und Vergleiche zwischen Kostenstellen und Perioden. Python ist für solche Aufgaben das ideale Werkzeug: NumPy und scipy bieten die statistischen Methoden; pandas liefert die Datenstruktur; matplotlib und seaborn erstellen aussagekräftige Visualisierungen.

Deskriptive Statistik und Ausreissererkennung

Der erste Schritt jeder statistischen Auswertung ist die deskriptive Statistik: Mittelwert, Median, Standardabweichung, Quartile und Extremwerte. pandas describe() liefert diese Kennzahlen auf Knopfdruck. Für die Ausreissererkennung nutze ich den IQR-basierten Ansatz (Interquartilsabstand): Werte ausserhalb von Q1 - 1.5*IQR bis Q3 + 1.5*IQR werden als Ausreisser markiert. Diese Methode ist robuster als die einfache Z-Score-Methode, weil sie weniger sensitiv gegenüber extremen Einzelwerten ist.

Zeitreihen und Trends

Zeitreihenanalysen sind in Controlling- und HR-Projekten besonders relevant: Wie entwickelt sich der Umsatz über die Zeit? Gibt es saisonale Muster? Wie verhalt sich eine Kennzahl im Vergleich zum Vorjahreszeitraum? pandas bietet mit resample() und rolling() mächtige Werkzeuge für Zeitreihen-aggregationen und gleitende Durchschnitte. Die Visualisierung mit matplotlib oder seaborn macht Trends und Ausreisser sofort sichtbar. Für Fachabteilungen exportiere ich die Ergebnisse als Excel-Dateien mit openpyxl, die direkt in bestehende Reporting-Prozesse integriert werden können.

Korrelationsanalysen und Pivot-Auswertungen

Korrelationsmatrizen mit df.corr() geben schnell Auskunft darüber, welche Variablen miteinander linear zusammenhängen – nützlich, um redundante Spalten in einem Dimensionsmodell zu identifizieren oder um Einflussfaktoren auf eine Zielgröße zu erkunden. Pivot-Auswertungen mit pd.pivot_table() erlauben die Darstellung von Kennzahlen in einer zweidimensionalen Kreuztabelle, wie sie aus Excel bekannt ist. Diese Ausgaben werden häufig direkt als Excel-Reports für Controlling-Abteilungen geliefert.

Azure Integration: Synapse, ADF, Blob Storage

Python-basierte Data-Engineering-Lösungen laufen in Enterprise-Projekten fast immer in einer Azure-Infrastruktur. Die Verbindung zwischen Python-Code und Azure-Diensten ist über die offiziellen Azure SDKs hergestellt, die für jeden Dienst eine Python-Bibliothek bereitstellen: azure-storage-blob für Blob Storage, azure-synapse-spark für Synapse-Spark-Notebooks, azure-keyvault-secrets für sichere Passwort-Verwaltung, azure-identity für Entra-ID-Authentifizierung. Ich habe in Projekten alle diese Dienste kombiniert: Python-Notebooks in Databricks, die Credentials aus Azure Key Vault lesen, Daten in Blob Storage schreiben und durch Azure Data Factory als Pipeline-Aktivitäten ausgeführt werden.

Azure Blob Storage: Lesen und Schreiben

Azure Blob Storage ist der bevorzugte Data-Lake-Speicher für Python-Datenpipelines in Azure. Mit der azure-storage-blob-Bibliothek lassen sich Dateien lesen, schreiben und verwalten. Für Parquet-Dateien kann man entweder direkt über die Blob-Storage-Bibliothek oder über das abfss://-Protokoll (Azure Data Lake Storage Gen2) schreiben, was von pyarrow und PySpark nativ unterstützt wird. In Databricks ist ADLS Gen2 als Mount-Point eingebunden, was den Zugriff auf Dateipfade mit /mnt/...-Notation vereinfacht.

Azure Data Factory: Python als Pipeline-Aktivität

Azure Data Factory kann Python-Skripte und Databricks-Notebooks als Aktivitäten in Pipelines einbetten. Das Muster ist: ADF-Pipeline mit einem Trigger (zeitbasiert oder ereignisbasiert), der eine Databricks-Notebook-Aktivität ausführt. Die Notebook-Aktivität übergibt Parameter (z.B. Verarbeitungsdatum), das Notebook verarbeitet die Daten und schreibt Ergebnisse in den Data Lake. Dieses Muster habe ich in mehreren Projekten realisiert und kenne die Konfigurationsdetails: Linked Services, Databricks-Integration Runtime, Secret-Referenzen für Credentials und die richtige Fehlerbehandlung in der Pipeline.

Azure Synapse Analytics: Spark-Notebooks und Dataflows

Azure Synapse Analytics vereint SQL-Pool, Spark-Pool und Data-Integration-Funktionen in einer Plattform. Synapse-Spark-Notebooks sind im Wesentlichen PySpark-Notebooks, die direkt aus Synapse ausgeführt werden. Synapse Dataflows sind eine visuelle Alternative für einfachere Transformationsaufgaben, die keine Python-Logik benötigen. In Projekten habe ich Synapse Dataflows für standardisierte ELT-Muster eingesetzt und Python-Notebooks für komplexere Transformationslogik, die sich in Dataflows nicht ausdrücken lässt.

Vollständiger Python-Tech-Stack: SQL Server, REST-APIs und Flat Files als Quellen; pyodbc/SQLAlchemy, pandas/NumPy und PySpark/Databricks als Transformationsschicht; Parquet/Delta Lake, Azure Synapse und Jupyter Notebooks als Ausgabe.

Automatisierung mit Python

Python ist neben seiner Rolle als Transformations- und Analysesprache auch ein mächtigees Automatisierungswerkzeug. Im Data-Engineering-Kontext bedeutet das: Extraktionsskripte als geplante Jobs ausführen, Dateisystemoperationen automatisieren, E-Mail-Benachrichtigungen bei Fehlern versenden, Excel-Reports automatisch befuellen und Konfigurationen zentral aus Umgebungsvariablen oder Key Vault laden. Im Vergleich zu PowerShell ist Python besser für datenzentrierte Aufgaben geeignet, während PowerShell bei Windows-Server-Administration und dbatools-Integration stärker ist. In Projekten nutze ich beide je nach Aufgabe.

Geplante Ausführung: cron, Windows Task Scheduler und ADF

Ein Python-Extraktionsskript kann auf drei Arten geplant ausgeführt werden: Als cron-Job auf Linux-Servern (typisch in Azure-VM- oder Container-Umgebungen), als Windows Task Scheduler-Task auf Windows-Servern, oder als Azure Data Factory Pipeline-Aktivität mit einem Trigger. Für Produktionspipelines bevorzuge ich den ADF-Weg, weil er Retry-Logik, Monitoring und Alerting im Azure-Monitor-Framework mitbringt. Für einfache lokale Automatisierungen ist der Task Scheduler ausreichend.

Fehlerbehandlung, Logging und Alerting

In einer Produktionspipeline ist Fehlerbehandlung keine Kürungsaufgabe, sondern Pflicht. Ich verwende das Python-logging-Modul mit einem konfigurierbaren Handler, der Logs sowohl in eine Datei als auch in Azure Application Insights schreibt. Bei kritischen Fehlern wird eine E-Mail über das smtplib-Modul oder einen Azure Logic App-Endpunkt gesendet. Alle unbehandelten Exceptions werden abgefangen, protokolliert und in einer Fehlertabelle in der Datenbank persistiert – für spätere Analyse und Benachrichtigung.

Konfiguration: Umgebungsvariablen und Key Vault

Hardcodierte Credentials im Code sind in Produktionssystemen inakzeptabel. Ich lade Verbindungszeichenketten, Passwörter und Service-Principal-Secrets entweder aus Umgebungsvariablen (os.environ) oder direkt aus Azure Key Vault über die azure-keyvault-secrets-Bibliothek. Bei Databricks-Notebooks nutze ich das eingebaute Secrets-Management (dbutils.secrets.get()), das Secrets aus dem konfigurierten Key-Vault-Scope lädt, ohne dass Credentials im Notebook-Code auftauchen.

• logging-Modul: Strukturierte Log-Ausgabe, konfigurierbares Level und Handler
• try/except/finally: Saubere Fehlerbehandlung in allen Pipeline-Stufen
• os.environ / python-dotenv: Umgebungsvariablen für lokale Entwicklung
• azure-keyvault-secrets: Sichere Credential-Verwaltung in Produktion
• openpyxl: Excel-Reports automatisch befuellen und formatieren
• smtplib / Azure Logic Apps: Alerting bei Pipeline-Fehlern
• argparse: Parameterisierung von Batch-Skripten über Kommandozeile
• schedule / APScheduler: Einfache cron-ähnliche Job-Planung in Python

Vorgehen und Zusammenarbeit

Der Einstieg in ein Python-Data-Engineering-Projekt beginnt immer mit einer Bestandsaufnahme: Welche Quellsysteme sind vorhanden? Welche Datenmengen und -qualitäten können erwartet werden? Welche Azure-Dienste und Berechtigungen stehen zur Verfügung? Welche BI-Werkzeuge und Teams konsumieren die Daten nachgelagert? Diese Fragen bestimmen die Architekturentscheidungen: ob pandas oder PySpark, ob ADF oder Databricks-Workflow, ob Parquet oder Delta, ob Synapse-Dedicated-Pool oder Serverless. Ich treffe diese Entscheidungen gemeinsam mit dem Auftraggeber, erkläre die Implikationen und dokumentiere die Begründung.

In der Entwicklungsphase arbeite ich iterativ: erste Pipeline-Versionen in Jupyter Notebooks, explorative Tests gegen repräsentative Stichproben der Quelldaten, schrittweise Erweiterung um Bereinigungslogik, Validierung und Fehlerbehandlung, dann Portierung in produktionsreife Skripte oder Databricks-Notebooks. Jeder Schritt wird dokumentiert – im Notebook selbst, im Code als Kommentar und in einem separaten Technischen Design-Dokument für den Auftraggeber. Sauberer, kommentierter Python-Code ist für mich keine Kürungsleistung, sondern Bestandteil der Lieferung.

• Analyse: Quellsysteme, Datenmengen, Qualität, Azure-Umgebung
• Architektur: Toolwahl (pandas/PySpark), Format (Parquet/Delta), Orchestrierung (ADF/Databricks)
• Entwicklung: Iterativ, Notebook-first, dann produktionsreife Skripte
• Validierung: Schematests, Assertions, Pandera in jeder Pipeline-Stufe
• Dokumentation: Inline-Kommentare, Notebook-Markdown, Tech-Design-Dok
• Übergabe: Wissenstransfer, Betriebshandbuch, Einarbeitung interner Teams

Ich arbeite remote, hybrid und vor Ort. Für die Entwicklung und Testphase ist Remote in den meisten Fällen ausreichend. Für die initiale Bestandsaufnahme, für architektonische Grundsatzentscheidungen und für die Übergabe an interne Teams ist persönliche Anwesenheit oft wertvoller. Ich richte mich nach dem, was im Projekt sinnvoll ist. Alle drei Projektsprachen – Deutsch, Englisch und Portugiesisch – beherrsche ich fliessend, auch in technischen Diskussionen.

Typische Leistungen

Das Spektrum meiner Python-Leistungen im Data-Engineering-Kontext deckt die gesamte Wertschöpfungskette ab: von der Quellsystem-Anbindung über Transformation und Validierung bis zur Cloud-Ablage und Orchestrierung. Je nach Projektphase und Bedarf übernehme ich einzelne Bereiche oder das vollständige Spektrum.

• Aufbau von Python-ETL-Pipelines: SQL Server → pandas → Parquet/Delta in Azure
• Implementierung von PySpark-Notebooks in Databricks für grosse Datenmengen
• Explorative Datenanalyse und statistische Auswertungen in Jupyter Notebooks
• Datenvalidierung: pandas-Assertions, Pandera-Schemas, Schema-Evolution
• Azure Data Factory: Pipeline-Design, Databricks-Aktivitäten, Trigger, Monitoring
• Azure Synapse Analytics: Spark-Notebooks, Dataflows, Linked Services
• Azure Blob Storage / ADLS Gen2: Parquet-Datasets, Delta-Tabellen, Berechtigungen
• Delta Lake: Upsert/MERGE-Logik, Partitionierung, Z-Ordering, Time Travel
• Fehlerbehandlung, Logging, Alerting: strukturierte Produktions-Pipelines
• Excel-Report-Automatisierung mit openpyxl für Fachabteilungen
• Code-Reviews und Architekturberatung für bestehende Python-Datenpipelines
• Wissenstransfer und Einarbeitung interner Teams in Python und Databricks

Typische Einsatzszenarien: Ein Unternehmen migriert von SSIS nach Databricks und benötigt Unterstützung beim Aufbau der ersten Python-basierten Pipelines. Ein Controlling-Team will statistische Auswertungen aus dem DWH automatisieren und als reproduzierbare Jupyter-Notebooks dokumentieren. Ein IT-Team hat eine Databricks-Infrastruktur aufgebaut, braucht aber Unterstützung beim Schreiben effizienter PySpark-Jobs und bei der Delta-Lake-Partitionierungsstrategie. In all diesen Szenarien bringe ich sowohl den Python- als auch den SQL-Server- und Azure-Kontext mit.

Ein besonderer Mehrwert entsteht, wenn Python-Kenntnisse und SQL-Server-Erfahrung zusammentreffen: Ich kenne die Eigenheiten von SQL-Server-Quelldaten, weiss, welche NVARCHAR-Codierungen Probleme bei pyodbc verursachen, kenne die SQL-Server-spezifischen Datetime-Typen und deren pandas-Äquivalente und verstehe, wie man SQL-Server-Tabellen mit Millionen von Zeilen effizient per JDBC-Partitionierung in Spark lädt. Diese Kombination erspart viele Stunden Debugging.

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zu Python im Data Engineering