Leistung
Python und SQL
Excel ist großartig, bis es nicht mehr großartig ist. Bei 10 Millionen Zeilen, sieben Quellsystemen oder API-getriebenen Pipelines wird es Zeit, eine Schicht tiefer zu gehen. Ich baue Python-ETL und SQL-Stages, die genau das tun, was sie sollen, mit Logging, Tests, Versionierung, ohne aus einem konkreten Bedarf ein DWH-Projekt zu machen.
Das Problem
Was ich typisch vorfinde: ein Python-Skript, das ein ehemaliger Werkstudent geschrieben hat. 600 Zeilen ohne Tests, ohne Logging, ohne Type Hints. Pandas-Operationen mit copy()-Warnings, kein Error-Handling. Es läuft seit drei Jahren und niemand traut sich anzufassen. Parallel dazu eine SQL-Datei mit 40 Subqueries, die genau einmal funktioniert hat, als die Person sie geschrieben hat.
Ad-hoc-Auswertungen, deren Ergebnis bei Re-Run um 3% abweicht. Niemand weiß, ob das ein Bug ist oder ein legitimer Drift in den Daten. SELECT-Statements ohne Index-Strategie, die auf der produktiven Datenbank Locks erzeugen.
Python und SQL sind nicht das Problem. Python und SQL ohne Engineering sind das Problem.
Die Lösung
Bei Python: getypte Funktionen mit Type Hints, klare Trennung in extract.py / transform.py / load.py, strukturiertes Logging (loguru oder Standard logging), Pytest-Tests für die kritischen Transformationen, Pyproject.toml mit pinned Dependencies, optional Containerisierung. Bei größeren Pipelines Airflow, Dagster oder schlanke Custom-Scheduler je nach Setup.
Bei SQL: Auswertungs-Logik als Views oder Stored Procedures statt als verstreute Ad-hoc-Snippets. Index-Strategie auf Basis von Execution Plans, nicht Bauchgefühl. CTEs für Lesbarkeit, Window-Functions für ranglistige Auswertungen, korrekte Transactional Boundaries. Bei DWH-nahem Bedarf eine schmale Stage zwischen Quellen und Reporting (PostgreSQL oder SQL Server), die als Source-of-Truth dient.
Lieferumfang: Code in Ihrem Git, README, Test-Suite, Beispiel-Daten für lokale Entwicklung, Deployment-Anleitung für Ihre Zielumgebung (cron, Windows Task, Container, Airflow DAG). Niemals 'läuft halt irgendwo'.
Typische Anwendungsfälle
- Python-ETL: 5-20 Quellsysteme (CSV, APIs, Datenbanken) konsolidieren, validieren, in SQL-Stage oder Data-Warehouse laden
- SQL-Stage-Aufbau zwischen Operativ-Systemen und Reporting: PostgreSQL/SQL Server mit Star-Schema, materialisierten Views, Snapshot-Logik
- Migration einer ungewarteten Python-Pipeline auf testbaren, getypten Code mit Logging und CI-Integration
- API-getriebene Daten-Pulls (Salesforce, HubSpot, Microsoft Graph) mit Pagination, Rate-Limit-Handling, Wiederaufnahmefähigkeit bei Abbruch
- Performance-Tuning bestehender SQL-Queries durch Execution-Plan-Analyse, Index-Strategie, Partitionierung
- Kleines Tool für ein internes Team: CLI oder schlankes FastAPI-Backend mit definierten Endpunkten, ohne Frontend-Overhead
- Datenqualitäts-Monitoring: tägliche Plausibilitäts-Checks (Bereiche, Aggregate, Verteilungen) mit Slack- oder E-Mail-Alerts
Konkreter Nutzen
- Testbarkeit: kritische Transformationen sind durch Tests abgesichert, Regressionen werden vor dem Deployment erkannt
- Wartbarkeit: Type Hints, klare Modulgrenzen, Linting. Ein zweiter Entwickler übernimmt in 2-4 Tagen statt 6 Wochen
- Performance: SQL-Queries oft Faktor 10-100 schneller nach Index- und Execution-Plan-Optimierung
- Skalierbarkeit: was als kleiner Cron-Job startet, kann zu Airflow oder einem proper DWH wachsen, ohne Komplettumbau
- Versionierbarkeit: Code im Git, Schema-Migrations als Code (Alembic oder Flyway), Deployments reproduzierbar
- Sicherheit: Credentials in Vault oder Umgebungsvariablen, keine .env-Dateien auf Desktops, keine SQL-Strings mit f-Strings
So läuft die Zusammenarbeit
Datenfluss und Anforderungen klären
Quellen, Ziele, Frequenz, Datenmenge, SLA, Datenschutz-Constraints. Output ist ein Architektur-Skizze mit drei Optionen.
Architektur-Entscheidung
Reicht ein Python-Skript mit Cron, oder braucht es Airflow/Dagster? SQL-Stage oder direkt ins DWH? Self-hosted oder Cloud? Trade-Offs schriftlich.
MVP-Pipeline mit Tests und Logging
Erste lauffähige Version mit den 1-2 wichtigsten Quellen, Tests auf die kritischen Transformationen, Logging-Schema definiert.
Inkrementeller Ausbau
Weitere Quellen, Validierungs-Schicht, Monitoring, Alerts. Jeder Schritt deployt, getestet, dokumentiert.
Übergabe oder Retainer
README, Architektur-Doku, Test-Setup, Deployment-Anleitung. Optional Retainer für Erweiterungen und Wartung.
Häufige Fragen
Ersetzt Python unsere Power-Query-Pipelines?
Nicht zwingend. Power Query ist für die meisten Excel-/Power-BI-zentrischen Pipelines die bessere Wahl, weil es im Stack bleibt und keine Zusatz-Infrastruktur braucht. Python lohnt sich bei großen Datenmengen, API-Komplexität, ML/NLP-Anforderungen, oder wenn die Pipeline außerhalb des Microsoft-Stacks laufen muss. Entscheidung im Discovery-Workshop.
Wo läuft der Code? Cloud, on-prem oder lokal?
Hängt von Ihren Daten ab. Bei sensiblen Daten (Kunden-PII, HR, Steuer): on-prem oder in einer privaten Cloud, niemals Hobby-Serverless. Bei generischen Daten ohne Personenbezug: jede saubere Umgebung passt. Ich richte mich nach Ihrer IT-Policy, nicht nach Hype.
Können Sie auch direkt auf unseren Produktiv-Datenbanken arbeiten?
Lesend ja, mit Read-Replica oder dedicated Reporting-User. Schreibend nur in dafür vorgesehenen Stage-Datenbanken, niemals direkt im operativen Bestand ohne explizites Freigabe-Verfahren. Locks auf produktiven Tabellen sind eine vermeidbare Katastrophe.
Welche Python-Bibliotheken nutzen Sie?
Standardstack: pandas und polars für Datenmanipulation, SQLAlchemy für Datenbank-Abstraktion, httpx oder requests für APIs, pydantic für Schema-Validierung, pytest für Tests, loguru oder Standard-Logging. Bei größeren Pipelines Airflow oder Dagster. Keine Bibliothek wird ohne klaren Grund aufgenommen.
Wir haben eine SQL-Query, die 8 Minuten läuft. Kriegen Sie das schneller?
Fast immer. Typische Verbesserung Faktor 10-100 durch Index-Strategie, Subquery-Refactor, Window-Functions statt Self-Joins. Wenn die Query fundamental schwer ist (große Aggregation über Milliarden Zeilen), schlage ich Materialized View oder Partitionierung vor.
Was kostet ein typisches Python/SQL-Projekt?
MVP-Pipeline (2-3 Quellen, eine SQL-Stage, Logging und Tests): 6-12 Werktage, ca. 8.000-18.000 Euro netto bei Stundensatz 140-180 Euro. Komplexere DWH-nahe Vorhaben entsprechend länger und im Discovery-Workshop kalkulierbar.
Passende weitere Leistungen
Python- oder SQL-Pipeline auditieren lassen?
Nennen Sie Quellen, Datenmengen, Frequenz und kritische Pain Points. Sie bekommen innerhalb von zwei Werktagen eine Einschätzung mit drei Optionen und realistischem Aufwand.