Datenaufbereitung:
Rohdaten in modellierbare Grundlagen verwandeln
Datenaufbereitung ist Phase 3 des Data-Science-Prozesses: Rohdaten werden bereinigt, zu Merkmalen verdichtet und in reproduzierbare Pipelines gegossen. Das Ergebnis ist ein sauberer, reproduzierbarer Datensatz als Basis für die Modellierung.
Die Kunst der Datenaufbereitung
Datenaufbereitung nimmt den größten Teil der Projektarbeit ein. Wir automatisieren mit robusten Prozessen.
Datenaufbereitung ist die Arbeit zwischen dem Rohdatenexport und dem ersten Modell. Sie besteht aus drei Schritten, die auf dieser Seite je einen eigenen Abschnitt bekommen. Die Datenbereinigung regelt den Umgang mit fehlenden Werten, Duplikaten, Ausreißern und uneinheitlichen Formaten. Das Feature Engineering bildet Merkmale, aus denen ein Modell lernen kann. Der Aufbau einer Datenpipeline macht beides wiederholbar. Englisch heißt dieselbe Arbeit Data Preparation oder Data Wrangling. Sie folgt auf die Datenakquise in Phase 2 und liefert den Datensatz für die explorative Datenanalyse in Phase 4.
Wie groß der Anteil an der Projektzeit ausfällt, hängt vom Zustand der Quellen ab. Die in der Branche oft genannten 60 bis 80 Prozent halten wir für plausibel, sobald mehr als eine Quelle beteiligt ist; gemessen über alle unsere Projekte haben wir diesen Anteil nicht. Planbar wird er, wenn vorher bekannt ist, welche Mängel in den Daten stecken.
Die Ausgangslage ist fast nie ein fertiger Datensatz, sondern das, was in Ihrem Haus ohnehin anfällt: ERP-Tabellen, Exporte aus dem Webshop, Maschinenprotokolle, Schichtbücher. Mit diesen Daten arbeiten wir, bevorzugt in Ihrer Infrastruktur; die Daten müssen Ihr Haus nicht verlassen. Und es gibt den Fall, in dem die Aufbereitung ein Projekt stoppt: wenn die Zielgröße, die das Modell vorhersagen soll, in den Daten gar nicht vorkommt, oder wenn sie nur für einen Zeitraum vorliegt, der die Frage nicht abdeckt. Dann sagen wir das nach der Bestandsaufnahme, nicht erst nach Monaten.
Datenbereinigung
Systematischer Umgang mit fehlenden Werten, Duplikaten und Inkonsistenzen.
Feature-Erstellung
Ableitung aussagekräftiger Merkmale auf Basis von Domänenwissen.
Automatisierung
Reproduzierbare Pipelines mit Fehlerbehandlung und Qualitätsprüfungen.
Datenbereinigung: fehlende Werte, Duplikate, Ausreißer
Datenbereinigung (englisch Data Cleaning) ist das Erkennen und Beheben von Mängeln in Rohdaten: fehlende Werte, Duplikate, Ausreißer und uneinheitliche Formate. Sie ist der erste und meist längste Teil der Datenaufbereitung und beantwortet vier Fragen: Was fehlt? Was ist doppelt? Was ist unplausibel? Was ist richtig, aber anders geschrieben als der Rest? Welche Antwort jeweils richtig ist, entscheidet nicht die Statistik allein, sondern der Zweck des späteren Modells. Deshalb steht bei jedem der vier Punkte eine Entscheidungsregel, nicht nur eine Methodenliste.
Fehlende Werte: löschen, imputieren oder als Merkmal kodieren
Ein fehlender Wert ist selten ein Zufall und oft selbst ein Befund: Im Datensatz einer Lieferplattform waren 38,78 Prozent der Bestellungen unbewertet, die wichtigste Aussage über die Datenqualität der Plattform. Bevor Sie also etwas ersetzen, lohnt die Frage, warum der Wert fehlt.
Drei Wege stehen offen. Löschen: Zeilen oder ganze Spalten entfernen, vertretbar bei wenigen betroffenen Zeilen ohne Bezug zur Zielgröße. Imputieren, also ersetzen: durch den Median, den Mittelwert, den letzten bekannten Wert oder ein Hilfsmodell. In einer Kundensegmentierung haben wir fehlende Einkommensangaben per Median ersetzt und einen Extremwert entfernt; von 2.240 Kundendatensätzen blieben 2.232. Als Merkmal kodieren: Das Fehlen selbst wird zur Information, etwa als Spalte „Einkommen unbekannt". Das ist der richtige Weg, wenn das Fehlen systematisch ist, denn dann sagt es dem Modell etwas über den Kunden.
Ein Sonderfall sind Platzhalter wie „?", „-1" oder „9999", die als gültige Werte durchgehen. Im UCI-Adult-Datensatz wirkt die Spalte „Workclass" zu 100 Prozent gefüllt; erst nachdem das Fragezeichen als Fehlwert deklariert ist, zeigen sich 5,6 Prozent Lücken.
Entscheidungsregel (unsere Faustregel, keine Norm): Liegt der Fehlanteil einer Spalte unter etwa fünf Prozent und ist kein Muster erkennbar, wird gelöscht oder einfach imputiert. Darüber, oder sobald das Fehlen mit der Zielgröße zusammenhängt, wird es als Merkmal kodiert und jede Imputation dokumentiert. Bei sehr hohem Fehlanteil trägt die Spalte meist nur noch als Ja-Nein-Merkmal; in den Titanic-Daten fehlt die Kabine bei 77,1 Prozent der Passagiere, das Alter bei 19,9 Prozent.
Duplikate und Schlüssel
Duplikate entstehen selten durch Tippfehler und meist durch Technik: Ein Export lief zweimal, zwei Systeme führen denselben Kunden, ein Join hat Zeilen vervielfacht. Gemessen haben wir im UCI-Adult-Datensatz mit 32.561 Zeilen 24 doppelte Zeilen, also 0,074 Prozent: niedrig, aber nicht null, und ohne Prüfung unsichtbar.
Die Prüfung läuft auf zwei Ebenen: Identische vollständige Zeilen sind technische Duplikate und werden gelöscht. Zeilen, die nur auf den erklärten Schlüsselspalten übereinstimmen, etwa Auftragsnummer plus Datum, sind fachliche Duplikate, und die Frage lautet, welche die richtige ist. Die zweite Ebene setzt voraus, dass der Schlüssel überhaupt bekannt ist. Bei Prozessdaten gehören doppelte Auftragsnummern zu den Mängeln, die darüber entscheiden, ob ein belastbares Modell entsteht oder eine schöne, falsche Auswertung.
Entscheidungsregel: Technische Duplikate werden gelöscht und ihr Anteil protokolliert. Fachliche Duplikate werden nie stillschweigend gelöscht, sondern nach einer mit dem Fachbereich festgelegten Regel aufgelöst: Der jüngste Stand gewinnt, oder der Stand aus dem führenden System. Die Regel wandert als Code in die Pipeline.
Ausreißer: Messfehler oder seltenes Ereignis
Statistisch ist ein Ausreißer ein Wert weit außerhalb der übrigen Verteilung; die klassische Regel nach Tukey zieht die Grenze beim 1,5-Fachen des Interquartilsabstands. In unserem Datenqualitäts-Audit über drei öffentliche Datensätze war die Werte-Plausibilität die am häufigsten rot leuchtende Dimension, weil schwere Ränder in realen Daten die Regel sind. Der nächste Schritt ist trotzdem immer ein menschlicher. Ist der Wert ein Sensorfehler, eine verwechselte Einheit oder ein echtes seltenes Ereignis? Im UCI-Adult-Datensatz zeigt die Spalte fnlwgt einen schweren Rand und ist als Stichprobengewicht fachlich völlig legitim.
Entscheidungsregel: Ein Ausreißer wird nur gelöscht, wenn der Fehler benannt werden kann: Einheit, Sensor oder Tippfehler. Sonst bleibt er im Datensatz, bekommt eine Markierung als eigenes Merkmal, und die Modellierung wählt Verfahren, die gegen Extremwerte weniger empfindlich sind, etwa den Median statt des Mittelwerts oder baumbasierte Modelle statt linearer.
Formate und Einheiten: Datum, Dezimaltrennzeichen, Zeitzonen
Der unspektakulärste Teil der Datenbereinigung verursacht die spätesten Fehler. Ein Datum, das als Text gespeichert ist, fällt zu Beginn kaum auf und wird zum Drama, sobald ein Zeitreihenmodell danach sortiert; in unserem Audit über 25 Jahre Apple-Tageskurse war ein solches Textdatum der erste Befund. Ähnlich still wirken Dezimaltrennzeichen: „1.250" ist je nach Herkunft eintausendzweihundertfünfzig oder eins Komma zwei fünf. Eine Grafik in einem unserer eigenen Artikel zeigte eine Zeit lang englische Dezimalpunkte, während der Text daneben das Komma nutzte.
Einheiten und Zeitzonen gehören in dieselbe Prüfung: wechselnde Einheiten in Maschinendaten, Zeitstempel in Ortszeit neben Zeitstempeln in Weltzeit, Sommerzeitwechsel, die eine Stunde doppelt oder gar nicht erscheinen lassen. Jede dieser Abweichungen ist für sich harmlos; in der Summe ergeben sie ein falsches Modell.
Entscheidungsregel: Jede Spalte bekommt einen deklarierten Typ, eine Einheit und, bei Zeitstempeln, eine Zeitzone, und zwar als Code in der Pipeline, nicht im Kopf des Bearbeiters. Zeitliche Lücken werden gezählt, aber nicht automatisch gefüllt: In den Apple-Kursen fanden sich 168 Lücken, 2,7 Prozent der Intervalle, und alle waren Wochenenden und Börsenfeiertage.
| Problem | Erkennung | Maßnahme | Risiko bei falscher Wahl |
|---|---|---|---|
| Fehlende Werte | Fehlanteil je Spalte; Platzhalter wie „?", -1, 9999 als Fehlwerte deklarieren | Löschen, imputieren oder als Merkmal kodieren, je nach Anteil und Muster | Systematisches Fehlen geht als Information verloren |
| Duplikate | Identische Zeilen; identische Schlüssel (ID plus Datum) | Technische Duplikate löschen, fachliche nach Regel mit dem Fachbereich auflösen | Aggregate sind aufgebläht; der falsche Stand gewinnt |
| Ausreißer | 1,5-facher Interquartilsabstand, 5 Sigma, fachliche Plausibilitätsgrenzen | Nur belegte Messfehler löschen, den Rest markieren, robuste Verfahren wählen | Das seltene Ereignis wird wegbereinigt |
| Formate und Einheiten | Typprüfung je Spalte; Datum als Text, Dezimaltrennzeichen, Zeitzonen | Typ, Einheit und Zeitzone deklarieren; Zeitlücken zählen, nicht füllen | Stille Fehler, die erst im Zeitreihen-Split auffallen |
Wer vor dem Projekt wissen will, wie viel Bereinigung auf ihn zukommt, bekommt mit dem Data Quality Check einen Befund mit Risikoampel. Die Bereinigung selbst ist darin ausdrücklich nicht enthalten; sie ist Gegenstand dieser Phase.
Data Quality Check zum Festpreis: die Bestandsaufnahme vor Phase 3Feature Engineering: aus Domänenwissen werden Merkmale
Ein Feature, auf Deutsch Merkmal, ist eine Spalte, aus der das Modell lernt. Feature Engineering ist die Arbeit, aus Rohspalten Merkmale zu bauen, die eine fachliche Bedeutung tragen. Nach unserer Erfahrung entscheidet diese Arbeit häufiger über die Güte eines Modells als die Wahl des Algorithmus, und sie ist der Teil der Datenaufbereitung, der ohne Ihr Fachwissen nicht funktioniert.
Was ein Feature ist: zwei Beispiele
In unserer Modellrechnung zur vorausschauenden Wartung liefert die Maschinensteuerung alle zehn Minuten Vibration, Temperatur, Stromaufnahme und Fehlercodes. Keiner dieser Rohwerte ist für sich ein gutes Merkmal. Gute Merkmale sind der gleitende 24-Stunden-Mittelwert der Vibration, der Trend der Stromaufnahme und die Zahl der Fehlercodes in den letzten 72 Stunden: Sie fassen zusammen, was ein erfahrener Instandhalter ohnehin im Blick hätte.
Predictive Maintenance: Wartung nach Zustand statt nach KalenderIm Modehandel ist das stärkste Merkmal für die nächste Retoure die bisherige Retourenquote des Kunden, allerdings nur, wenn sie ausschließlich aus Bestellungen mit früherem Datum berechnet wird. Sauber gebaut hob sie in unserer Auswertung von 2,33 Millionen Bestellposten die Vorhersagegüte (ROC-AUC) von 0,696 auf 0,737. Wie aus Freitext-Kommentaren zählbare Retourengründe werden, zeigt der zweite Anwendungsfall.
Retourengründe analysieren: aus Freitext werden UrsachenTypische Transformationen
- Aggregation über Zeitfenster: Summen, Mittelwerte und Trends über 24 Stunden, 7 Tage oder 12 Monate. Entscheidend ist die Fensterkante: Das Fenster endet zum Vorhersagezeitpunkt, nie danach.
- Kategorien kodieren: Text wie „Zahlart" oder „Maschinen-ID" wird zu Zahlen, klassisch als One-Hot-Kodierung mit einer Ja-Nein-Spalte je Kategorie. Zielkodierungen für viele Ausprägungen nur mit Vorsicht, weil sie leicht Information aus der Zielgröße einschleusen.
- Skalierung und Normalisierung: Für Verfahren, die Abstände messen, werden Spalten auf vergleichbare Größenordnungen gebracht; in der erwähnten Kundensegmentierung gingen dem Vergleich von fünf Clusterverfahren eine Standardisierung und eine Hauptkomponentenanalyse voraus. Baumbasierte Verfahren brauchen diesen Schritt nicht.
- Auswahl (Feature Selection): Merkmale, die nichts erklären oder nur andere wiederholen, werden entfernt; das hält das Modell erklärbar und die Pipeline schlank.
Data Leakage: die größte Falle
Data Leakage, auf Deutsch Datenleck, bedeutet: Ein Merkmal enthält Information, die zum Vorhersagezeitpunkt noch gar nicht vorliegen kann. Das Modell wirkt im Test brillant und versagt im Betrieb. Wie groß der Effekt sein kann, zeigt unsere Auswertung von rund 50.000 Sitzungen eines Online-Shops: Mit den Warenkorb-Merkmalen vom Sitzungsende erreichte das Modell eine AUC von 0,961, ohne sie 0,860. Gut zehn AUC-Punkte waren keine Weitsicht, sondern eine Umformulierung des Ergebnisses. Was dieser Befund für die Modellvalidierung bedeutet, erklärt Phase 5. Die Auswertung selbst steht im Research-Artikel.
Drei Regeln folgen daraus. Erstens verläuft der Schnitt zwischen Training und Test entlang der Zeit oder der Einheit (Sitzung, Kunde, Maschine), nie zeilenweise; sonst steht dieselbe Sitzung auf beiden Seiten. Zweitens wird jedes Merkmal daraufhin geprüft, wann es im Betrieb bekannt ist: Die Wartungshistorie bis gestern ist erlaubt, der Reparaturbericht von morgen nicht. Drittens ist eine überraschend hohe Kennzahl ein Verdachtsmoment, kein Erfolg. Liegt eine Demo deutlich über dem, was eine saubere zeitliche Aufteilung hergibt, ist die Differenz mit hoher Wahrscheinlichkeit der Leakage-Aufschlag.
Warum fast perfekte Conversion-Modelle meist den Warenkorb nacherzählenDatenpipelines: reproduzierbar, getestet, versioniert
Eine Datenpipeline ist die Verarbeitungsstrecke, die Rohdaten bei jedem Lauf in derselben Reihenfolge und mit denselben Regeln in Merkmale verwandelt. Der Begriff ETL (Extract, Transform, Load: auslesen, umformen, ablegen) beschreibt dieselbe Strecke aus Sicht der Datenhaltung. Welches Werkzeug sie ausführt, ist zweitrangig; entscheidend sind Reproduzierbarkeit, Tests und Versionierung, die drei Eigenschaften aus dem Motto der Grafik weiter unten.
Warum Notebook-Skripte nicht reichen: Ein Notebook ist das richtige Werkzeug, um eine Bereinigung zu entwickeln, und das falsche, um sie zu betreiben; nach drei Wochen weiß niemand mehr, welcher Export die Grundlage war.
Versioniert wird der Code der Transformationen, dazu ein eingefrorener Datenstand (Snapshot) der Rohdaten, gegen den sich jedes Ergebnis nachrechnen lässt. Hinzu kommt die Transformationslogik als Dokumentation, also welche Regel aus welchem Grund gilt. Die „Dokumentation aller Transformationen" unter den Ergebnissen dieser Phase ist deshalb kein Nachtrag, sondern ein Nebenprodukt der Pipeline.
Tests auf Schema und Wertebereiche: Jeder Lauf prüft vorab, ob die Eingabe noch dem erwarteten Schema entspricht (Spalten, Typen, Einheiten) und ob die Wertebereiche plausibel sind: keine negativen Mengen, keine Zeitstempel aus der Zukunft, Fehlanteile unter der vereinbarten Schwelle. Solche Vertragstests gegen ein bekanntes Schema sind eine andere Schicht als die Diagnose in Phase 2; eine vollständige Testsuite kostet je nach Datenmodell zwischen einer und vier Wochen und fängt dafür jeden künftigen Export ab, der still sein Format ändert. Schlägt ein Test an, bricht der Lauf ab, statt ein leises falsches Ergebnis zu liefern.
Übergang zu Phase 6: Dieselbe Pipeline, die die Trainingsdaten erzeugt hat, erzeugt später im Betrieb die Eingaben für das Modell. Wer in Phase 3 zwei getrennte Wege baut, einen für das Experiment und einen für die Produktion, bekommt in Phase 6 Abweichungen, die niemand erklären kann.
Dieselbe Pipeline im Betrieb: Phase 6Datenaufbereitung im Mittelstand: drei typische Ausgangslagen
Drei Ausgangslagen begegnen uns in mittelständischen Unternehmen immer wieder. Keine davon ist ein Hindernis; jede verlangt einen anderen ersten Schritt.
Excel-Listen in mehreren Abteilungen
Der Vertrieb pflegt Kunden in einer Tabelle, die Buchhaltung in einer zweiten, die Produktion in einer dritten. Dieselbe Firma steht dreimal darin, dreimal anders geschrieben. Die Aufbereitung beginnt hier mit der Schlüsselbildung: Welche Spalte identifiziert einen Kunden eindeutig? Erst danach lohnt sich die Bereinigung, sonst werden drei Wahrheiten sauber, aber nicht eine.
ERP-Export mit Freitextfeldern
Der Export ist sauber strukturiert, aber die entscheidende Information steht im Bemerkungsfeld: der Stornogrund, die Sonderkondition, der Sonderwunsch des Kunden. Freitext wird per Sprachverarbeitung in Kategorien übersetzt, die sich zählen lassen. Die Kategorien legt der Fachbereich fest, nicht das Modell; das Modell sortiert nur ein.
Maschinendaten ohne gemeinsame Zeitachse
Maschinensteuerung, Produktionsleitsystem (MES) und ERP protokollieren denselben Auftrag, aber mit eigenen Uhren und eigenem Takt. Vor jeder Modellierung müssen die Quellen über Zeitstempel, Auftrags- und Maschinen-IDs verknüpft werden. Lücken in Zeitreihen, wechselnde Einheiten und doppelte Auftragsnummern sind dabei die üblichen Befunde.
Schematischer Ablauf mit Beispielwerten: links der Rohdatensatz (38 Prozent leere Felder, 25 Prozent unklare Einträge, 18 Prozent Dubletten, 12 Prozent gemischte Formate), rechts der Merkmalsdatensatz (42 Merkmale, 98 Prozent Qualität, 95 Prozent Abdeckung, 100 Prozent Tests bestanden). Beispielwerte, keine Projektmessung.
Unser Vorgehen
Bereinigung & Harmonisierung
Systematische Adressierung von Datenqualitätsproblemen über verschiedene Quellen.
Feature Engineering
Erstellung von Merkmalen, die das Modelllernen bestmöglich unterstützen.
Pipeline-Aufbau
Automatisierte, versionierte Datenverarbeitungsprozesse.
Qualitätssicherung
Integrierte Prüfmechanismen für dauerhaft gesicherte Datenqualität.
Typische Ergebnisse
Häufige Fragen zur Datenaufbereitung
Was ist der Unterschied zwischen Datenaufbereitung und Datenbereinigung?
Datenbereinigung ist ein Teil der Datenaufbereitung. Sie beseitigt Mängel in den Rohdaten: fehlende Werte, Duplikate, Ausreißer, uneinheitliche Formate. Datenaufbereitung umfasst zusätzlich das Feature Engineering, also das Bilden fachlich sinnvoller Merkmale, und den Aufbau einer Pipeline, die beide Schritte wiederholbar und prüfbar macht.
Wie geht man mit fehlenden Werten um?
Zuerst klären, warum der Wert fehlt. Fehlt er zufällig und selten, wird die Zeile gelöscht oder der Wert durch Median oder letzten bekannten Stand ersetzt. Fehlt er systematisch, wird das Fehlen als eigenes Merkmal kodiert. Platzhalter wie „?" oder 9999 müssen vorher als Fehlwerte deklariert werden, sonst gilt die Spalte fälschlich als vollständig.
Wie viel Zeit nimmt die Datenaufbereitung in einem Data-Science-Projekt ein?
Den größten Teil der Projektarbeit, sobald mehr als eine Quelle beteiligt ist. Die oft genannten 60 bis 80 Prozent decken sich mit unserer Erfahrung; gemessen über alle Projekte haben wir sie nicht. Planbar wird der Anteil, wenn eine Bestandsaufnahme wie der Data Quality Check vorher zeigt, welche Mängel zu erwarten sind.
Was ist Feature Engineering und warum ist es wichtiger als der Algorithmus?
Feature Engineering bildet aus Rohspalten Merkmale mit fachlicher Bedeutung, etwa den gleitenden 24-Stunden-Mittelwert einer Vibration statt des Einzelwerts. Ein Algorithmus findet nur Muster, die in den Merkmalen stecken; ein besseres Merkmal hebt in der Regel jedes Modell, ein besserer Algorithmus nur das eine. Deshalb steckt in dieser Arbeit das Fachwissen Ihres Hauses.
Was ist Data Leakage und wie vermeidet man es?
Data Leakage liegt vor, wenn ein Merkmal Information enthält, die zum Vorhersagezeitpunkt noch nicht vorliegen kann, etwa der Warenkorbstand am Sitzungsende für eine Conversion-Prognose. Vermeiden lässt es sich durch einen zeitlichen Schnitt zwischen Training und Test, die Prüfung jedes Merkmals auf seinen Bekanntheitszeitpunkt und Misstrauen gegenüber Kennzahlen, die zu gut aussehen.
Müssen unsere Daten perfekt sein, bevor ein Modell gebaut werden kann?
Nein. Modelle kommen mit Lücken und Rauschen zurecht, wenn beides bekannt und dokumentiert ist. Drei Dinge müssen stimmen: Die Zielgröße muss in den Daten vorkommen, der Zeitraum muss die Frage abdecken, und ein eindeutiger Schlüssel muss die Quellen verbinden. Fehlt eines davon, stoppt die Aufbereitung das Projekt, besser früh als spät.
Kann Datenaufbereitung automatisiert werden?
Die Ausführung ja, die Entscheidungen nein. Typprüfungen, Duplikatsuche, Fehlwertstatistik und Schema-Tests laufen in der Pipeline bei jedem neuen Datenstand automatisch. Ob ein Ausreißer ein Messfehler oder ein echtes Ereignis ist und welche Regel bei fachlichen Duplikaten gilt, entscheidet ein Mensch mit Fachkenntnis, und zwar nur einmal.
Lassen Sie uns über Ihr Projekt sprechen
Jedes Projekt ist einzigartig. Schildern Sie uns Ihre Herausforderung.
Kostenloses Erstgespräch buchen