Skalierbare Python-Verarbeitung
Polars, Lazy Operations und Parquet bilden eine speichereffiziente Pipeline für mehr als zehn Millionen Datensätze, ohne unnötige Vollmaterialisierung großer Zwischenergebnisse.
Python · Data Engineering · Polars · Data Quality
Eigenprojekt · abgeschlossenConsumer Finance Complaint Intelligence
Eine reproduzierbare Data-Intelligence-Plattform zur Analyse von 10.269.540 Verbraucherbeschwerden aus der CFPB Consumer Complaint Database. Das Projekt verbindet skalierbare Datenverarbeitung, Data-Quality-Gates, explorative Analyse, Management-Reporting und interaktive Visualisierung.
Der Schwerpunkt liegt nicht nur auf einzelnen Charts oder Kennzahlen, sondern auf einer überprüfbaren Analyse-Pipeline: von Datenherkunft und Qualitätskontrolle über reproduzierbare Transformationen bis zur fachlich vorsichtigen Interpretation der Ergebnisse.
Das Projekt zeigt dabei vor allem Engineering-Kompetenz im Umgang mit großen Datenbeständen: skalierbare Python-Verarbeitung, strukturierte Datenpipelines, automatisierte Qualitätsprüfungen, reproduzierbare Analyseartefakte und technische Absicherung über Tests und CI.
Datensätze
10.269.540
analysierte Verbraucherbeschwerden
Analyse-Speicher
≈ 599 MiB
bei vollständiger reproduzierter Analyse
Tests
35 / 35
automatisierte Tests erfolgreich
Release
v1.0.1
final veröffentlichtes Portfolio-Release
Relevanz für Data- und Python-Projekte
Datenverarbeitung als belastbare Engineering-Pipeline.
Data Quality als Teil der Pipeline
Schema, Datentypen, Vollständigkeit und weitere erwartete Datenzustände werden automatisiert geprüft, bevor fachliche Auswertungen auf den Daten aufbauen.
Reproduzierbare Analyse statt Einmal-Auswertung
Transformationen, Ergebnisartefakte, Tests, Evidence-Checks und Analyse-Commands sind versioniert und so aufgebaut, dass die vollständige Analyse erneut ausgeführt und geprüft werden kann.
Reporting für technische und fachliche Stakeholder
Strukturierte Tabellen, Visualisierungen, Management-Zusammenfassung und Dashboard verbinden technische Datenverarbeitung mit einer verständlichen Kommunikation der Ergebnisse.
Projektziel
Große Datenmengen analysieren, ohne Datenqualität und Kontext aus dem Blick zu verlieren.
Das Projekt verarbeitet insgesamt 10.269.540 Verbraucherbeschwerden und zeigt, wie eine größere reale Datenbasis strukturiert, geprüft und analysiert werden kann, ohne die gesamte Logik in einem einzelnen Notebook zu verstecken.
Im Mittelpunkt stehen reproduzierbare Datenverarbeitung, nachvollziehbare Qualitätsprüfungen und eine klare Trennung zwischen beobachteten Datenmustern und fachlicher Interpretation.
Die vollständige Analyse wurde im Audit erneut ausgeführt. Dabei lag der gemessene Analyse-Speicherbedarf bei ungefähr 599 MiB.
Skalierbare Datenverarbeitung
Mehr als zehn Millionen Zeilen ohne unnötige Datenkopien analysieren.
Polars bildet den Kern der Analyse-Pipeline. Lazy Operations erlauben es, Transformationen zu planen und erst bei Bedarf auszuführen, anstatt jeden Verarbeitungsschritt unmittelbar vollständig im Speicher zu materialisieren.
Parquet wird als effizientes spaltenorientiertes Format für analytische Daten genutzt. Dadurch lassen sich relevante Spalten und Transformationen gezielter verarbeiten.
Skalierbarkeit wird dabei nicht als abstraktes Versprechen behandelt: Die vollständige Analyse wurde gegen den vorhandenen Datensatz reproduziert und die erzeugten Ergebnisartefakte wurden mit dem Repository-Stand verglichen.
Engineering-Ansatz
Vom Quelldatensatz bis zum reproduzierbaren Management-Report.
-
01
Datenquelle und Provenienz
Die Quelldaten werden mit dokumentierter Herkunft, reproduzierbarem Datenpfad und überprüfbaren Metadaten verarbeitet. Der verwendete Quelldatensatz wird über einen dokumentierten Hash nachvollziehbar referenziert.
Implementiert -
02
Skalierbare Datenaufnahme
Mehr als zehn Millionen Datensätze werden über eine speichereffiziente Polars-Pipeline eingelesen. Lazy Operations und Parquet-basierte Verarbeitung vermeiden unnötige Vollmaterialisierung großer Zwischenergebnisse.
Implementiert -
03
Data-Quality-Gates
Schema, Vollständigkeit, Datentypen, Zielwerte und weitere Qualitätskriterien werden automatisiert geprüft. Fehlerhafte oder unerwartete Datenzustände sollen früh sichtbar werden, bevor Analysen darauf aufbauen.
Implementiert -
04
Taxonomie und analytische Aufbereitung
Beschwerdedaten werden strukturiert kategorisiert und für wiederholbare Analysen vorbereitet. Die Transformationen bleiben im Code nachvollziehbar und werden nicht nur in einem Notebook verborgen.
Implementiert -
05
Explorative und fachliche Analyse
Verteilungen, Kategorien, zeitliche Entwicklungen und weitere relevante Muster werden systematisch untersucht. Interpretation und Datenlage werden bewusst getrennt, um überzogene Schlussfolgerungen zu vermeiden.
Implementiert -
06
Management Reporting und Visualisierung
Die Analyse erzeugt strukturierte Tabellen, sechs zentrale Visualisierungen, eine Management-Zusammenfassung und ein interaktives Dashboard für die verständliche Kommunikation der Ergebnisse.
Implementiert -
07
Tests, CI und Reproduzierbarkeit
Automatisierte Tests, Ruff, GitHub Actions, Evidence-Checks, Package-Builds und reproduzierbare Analyse-Commands sichern die technische Qualität. Die öffentliche CI prüft das Projekt unter Python 3.11 und 3.13 sowie die Installation außerhalb des Repository-Kontexts.
Implementiert
Data Quality
Analyse beginnt mit der Frage, ob die Daten überhaupt belastbar genug sind.
Vor analytischen Auswertungen durchläuft der Datensatz definierte Qualitätsprüfungen. Dabei werden erwartete Strukturen und Datenzustände automatisiert überprüft.
Die Pipeline behandelt Datenqualität nicht als einmalige manuelle Sichtprüfung, sondern als wiederholbaren Bestandteil des Analyseprozesses.
Bekannte Einschränkungen und methodische Grenzen werden in der Dokumentation explizit festgehalten, damit analytische Resultate nicht stärker interpretiert werden als die Datengrundlage erlaubt.
Die CFPB-Beschwerdedaten sind administrative Beschwerdedaten und keine repräsentative Stichprobe des gesamten US-Verbraucherfinanzmarkts. Ergebnisse beschreiben daher den analysierten Datenbestand und werden nicht als allgemeine Marktverteilung interpretiert.
Analyse und Reporting
Technische Analyse wird in verständliche Entscheidungsinformationen übersetzt.
Die Pipeline erzeugt strukturierte Tabellen und sechs zentrale Visualisierungen, die wesentliche Muster des Datensatzes nachvollziehbar darstellen.
Zusätzlich werden eine Management-Zusammenfassung, Report-Artefakte und ein interaktives Dashboard erzeugt. Damit adressiert das Projekt sowohl technische Analyse als auch die Kommunikation der Ergebnisse an nichttechnische Stakeholder.
Interpretationen werden bewusst vorsichtig formuliert. Beobachtete Zusammenhänge werden nicht automatisch als kausale Beziehungen dargestellt.
Engineering Quality
Eine Analyse ist erst dann wertvoll, wenn sie reproduzierbar bleibt.
- 35 von 35 automatisierten Tests erfolgreich
- Ruff Check ohne Befunde
- GitHub Actions erfolgreich auf Python 3.11 und 3.13
- Exakte Dependency-Locks für Python 3.11 und 3.13
- Non-editable Installation und Import aus site-packages geprüft
- Evidence-Checks, Notebook-Smoke-Test und Repository-Audit erfolgreich
- Package-Build und isolierter Wheel-Smoke-Test erfolgreich
- Fresh-Clone-Reproduzierbarkeit geprüft
- Datenqualitäts-Gates als Bestandteil der Pipeline
- Öffentlicher Release v1.0.1 vorhanden
- MIT-Lizenz für den eigenen Projektcode
Technischer Stack
Datenanalyse als Softwareprojekt statt als isoliertes Notebook.
- Python
- Polars
- SQL
- Parquet
- Plotly
- Data Quality
- pytest
- Ruff
- GitHub Actions
Engineering-Nachweis
Data Engineering als Grundlage für belastbare AI-Systeme.
Das Projekt zeigt bewusst keinen Machine-Learning- oder LLM-Use-Case, sondern die technische Grundlage, auf der solche Systeme später aufbauen: nachvollziehbare Datenherkunft, skalierbare Verarbeitung, Data Quality und reproduzierbare Pipelines.
Diese Engineering-Prinzipien – Datenherkunft, Qualitätskontrolle, strukturierte Transformationen, Tests, Reproduzierbarkeit und nachvollziehbare Kommunikation – werden in meinen späteren ML-, Deep-Learning- und Agentic-AI-Projekten konsequent weitergeführt.
Projektstatus
Abgeschlossen, versioniert und reproduzierbar veröffentlicht.
Das Projekt ist als Release v1.0.1 abgeschlossen. Repository, Tests, CI, Evidence-Validierung, Dokumentation und die vollständige Analyse wurden im finalen Portfolio-Audit überprüft.
Die finale technische Absicherung umfasst unter anderem exakte Dependency-Locks für Python 3.11 und 3.13, non-editable Installation, Package- und Wheel-Smoke-Tests sowie einen Fresh-Clone-Check. Methodische Grenzen des CFPB-Datensatzes bleiben ausdrücklich dokumentiert.