Interviewfragen für Data Engineers

Vorgehensweise — Fensterfunktion mit deterministischer Sortierung

Ich nummeriere die Zeilen mit row_number() over (partition by event_id order by updated_at desc, ingestion_at desc, source_sequence desc) und behalte Rang eins. Die Sortierung muss deterministisch sein; nur updated_at reicht bei Gleichständen oft nicht. Vorher kläre ich, ob event_id tatsächlich der fachliche Schlüssel ist und ob spätere Updates ältere Ereignisse ersetzen dürfen. Für inkrementelle Verarbeitung berücksichtige ich verspätete Daten mit einem Lookback-Fenster oder MERGE und schreibe idempotent in das Ziel. Ich prüfe Anzahl der Duplikate, Nullschlüssel und Konflikte, statt sie still zu verwerfen.

Vorgehensweise — Qualifizierende Aktivität → Datum → eindeutige Nutzer → inkrementelle Partition

Zuerst definiere ich, welche Ereignisse Aktivität darstellen und welche Test-, Bot- oder internen Nutzer ausgeschlossen werden. Dann normalisiere ich event_at auf die vereinbarte Zeitzone und den Kalendertag und zähle distinct user_id je Datum. Produktionsreif wird die Transformation durch partitioniertes Schreiben nach event_date, idempotente Wiederholbarkeit, Umgang mit verspäteten Events und Qualitätsprüfungen. Ich vergleiche Roh- und Zielvolumen, überwache ungewöhnliche Sprünge und dokumentiere Definition sowie Datenstand.

Vorgehensweise — Änderung eingrenzen → Ausführungsplan → Datenvolumen → Joins und Filter → Ressourcen

Ich bestimme zuerst, wann die Verschlechterung begann und ob sich Code, Schema, Datenvolumen, Verteilung, Statistiken, Partitionen oder Warehouse-Ressourcen geändert haben. Danach vergleiche ich Ausführungspläne und suche nach vollständigen Scans, ungünstigen Join-Strategien, Spill, Skew und fehlendem Partition Pruning. Ich prüfe Zeilenwachstum, Kardinalität und Join-Granularität; ein neuer One-to-many-Join kann Daten explosionsartig vergrößern. Optimierungen können frühere Filter und Aggregationen, andere Join-Reihenfolge, passende Partitionen oder Clustering, aktualisierte Statistiken und größere Ressourcen umfassen. Jede Änderung messe ich mit Laufzeit, gescannten Bytes, Shuffle und Kosten.

Vorgehensweise — Geschäftsprozesse → Fakten → Dimensionen → Granularität → Kennzahlen

Ich beginne mit Browsing, Warenkorb, Bestellungen, Zahlungen, Versand, Retouren, Erstattungen, Bestand und Attribution. Mögliche Fakten sind fact_orders je Bestellung, fact_order_items je Produktposition, fact_payments, fact_refunds, fact_shipments und tägliche Bestands-Snapshots. Dimensionen umfassen Kunde, Produkt, Datum, Lager, Kanal und Kampagne. Jede Granularität wird ausdrücklich definiert. Umsatz nach Produktkategorie stammt von Positionen, Kundenlebenszyklus eher von Kunden oder Abonnements, Bestand von täglichen Snapshots. Ich berücksichtige historische Attributänderungen, Stornos, Rabatte auf Bestell- oder Positionsebene, Währungen, Steuern, Gastkäufe und verspätete Daten. Validiert wird gegen Finance, Transaktions-, Zahlungs- und Lagersysteme.

Vorgehensweise — Type 1 oder Type 2 nach Bedarf an Historie

Type 1 überschreibt alte Werte und eignet sich, wenn nur der aktuelle Zustand zählt. Type 2 legt für jede Änderung eine neue Dimensionszeile mit Gültigkeitsbeginn, Gültigkeitsende, current_flag und Surrogate Key an. Wechselt ein Kunde von Region West nach Ost, ordnet Type 1 auch historischen Umsatz nachträglich Ost zu. Type 2 erhält die damalige Region und verbindet Fakten mit der zum Ereigniszeitpunkt gültigen Version. Dafür entstehen zusätzliche Komplexität bei Surrogate Keys, Zeitraum-Joins, verspäteten Fakten und aktueller gegenüber historischer Sicht. Die fachliche Anforderung entscheidet, nicht eine pauschale Präferenz.

Vorgehensweise — Governance und Flexibilität gegenüber Abfrageeinfachheit und Leistung

Ein Star Schema trennt Fakten und Dimensionen. Es unterstützt wiederverwendbare Dimensionen, konsistente Kennzahlen, klare Granularität und flexible Analysen mit weniger Duplizierung. Breite Tabellen eignen sich für häufig genutzte Dashboards, konkrete Analysefälle oder ML-Features, wenn einfache und schnelle Abfragen wichtiger sind. Sie können jedoch Daten duplizieren und widersprüchliche Definitionen fördern. Häufig ist eine vertrauenswürdige Grundlage aus kanonischen Fakten und Dimensionen mit kuratierten Marts oder breiten Tabellen für bestimmte Nutzer der beste Kompromiss. Maßgeblich sind Volumen, Konsumenten, BI-Werkzeug, Kosten, Latenz und Änderungsfrequenz.

Vorgehensweise — Extrahieren → roh speichern → transformieren → validieren → veröffentlichen → überwachen

Ich kläre Aktualität, Volumen, zulässige Quelllast, Konsumenten und nachträgliche Korrekturen. Bestellungen werden inkrementell über updated_at oder CDC extrahiert, unverändert in Object Storage oder einer Raw-Tabelle abgelegt, in Staging bereinigt und als fact_orders sowie fact_order_items veröffentlicht. Ein Orchestrator steuert Abhängigkeiten. Wiederholungen müssen per MERGE, Partitionsersatz oder atomarem Austausch deterministisch bleiben. Ein Lookback-Fenster erfasst verspätete Änderungen. Prüfungen umfassen Zeilenzahlen, Nullschlüssel, doppelte IDs, Umsatz, Statusverteilung, Aktualität und Quellenabgleich. Alarme decken Fehler, ungewöhnliche Volumen, Duplikate und Verzögerungen ab; Verantwortung und Downstream-Abhängigkeiten sind dokumentiert.

Vorgehensweise — Gleiche Eingabe und Wiederholung erzeugen dieselbe Ausgabe

Eine idempotente Pipeline kann mit derselben Eingabe mehrfach laufen und erzeugt stets denselben korrekten Zustand ohne Duplikate oder unerwünschte Nebenwirkungen. Das ist für Retries und Backfills entscheidend. Eine nicht idempotente Pipeline hängt bei jedem Lauf die gestrigen Bestellungen erneut an. Eine robuste Variante ersetzt die Zielpartition, führt einen MERGE über Primärschlüssel aus oder schreibt zunächst temporär und tauscht atomar. Dafür braucht sie eindeutige Schlüssel, passende Partitionierung, deterministische Transformationen und kontrollierte Nebenwirkungen.

Vorgehensweise — Erkennen → klassifizieren → schützen → kommunizieren → migrieren

Schemaänderungen werden über Registry, Metadatenprüfungen, Contract Tests oder Ingestion-Validierung erkannt und als neue, entfernte oder umbenannte Spalte, Typ-, Nullability- oder Bedeutungsänderung klassifiziert. Nullable Ergänzungen sind meist kompatibel; Umbenennungen, Entfernen und Typwechsel können Downstream brechen. Semantische Änderungen sind besonders gefährlich, weil das Schema formal gültig bleibt. Rohdaten bleiben erhalten, kritische Quellen haben Verträge und Kompatibilitätsprüfungen. Bei Breaking Changes koordiniere ich Quellverantwortliche, versioniere, passe Transformationen an, fülle bei Bedarf Historie nach und kommuniziere Lineage-basiert die betroffenen Konsumenten.

Vorgehensweise — Entscheidungslatenz gegenüber Komplexität

Streaming ist sinnvoll, wenn geringe Latenz echten Geschäftswert schafft, etwa bei Betrugserkennung, Betriebsalarmen, Personalisierung, Bestandsupdates oder Produktfunktionen mit frischen Ereignissen. Für Tagesberichte, historische Analysen, Finance-Abstimmungen und stundenweise Transformationen ist Batch meist einfacher, günstiger und leichter wiederholbar. Die Entscheidung berücksichtigt Aktualität, Volumen, Reihenfolge, zustandsbehaftete Verarbeitung, Fehlertoleranz, Teamkompetenz, Kosten und Konsumenten. Streaming bringt zusätzliche Arbeit für Duplikate, verspätete Events, Checkpoints, Schemaänderungen und Monitoring. Ich wähle die einfachste Architektur, die die fachliche Anforderung erfüllt.

Vorgehensweise — Events → Stream → Anreicherung → Regeln oder Modell → Aktion → Speicherung → Monitoring

Ich kläre Volumen, Latenzziel, Entscheidungsart, tolerierbare False Positives und ob Transaktionen blockiert oder geprüft werden. Zahlungsereignisse gelangen in Kafka oder Kinesis. Ein Stream Processor validiert das Schema, dedupliziert per event_id, reichert Nutzer-, Geräte-, Händler- und Velocity-Merkmale an und wendet Regeln oder ein Modell an. Hohe Risiken lösen Blockierung, zusätzliche Authentifizierung oder manuelle Prüfung aus. Rohereignisse und Entscheidungen werden dauerhaft für Audit und Training gespeichert. Kritisch sind Reihenfolge, Duplikate, Feature-Aktualität, State-Größe, Backpressure, Dead-Letter Queue, Replay, Latenz und Versionierung. Reason Codes, False-Positive-Monitoring und Rollback schützen Kunden und Betrieb.

Vorgehensweise — Neuverteilen von Daten zwischen Partitionen

Ein Shuffle entsteht, wenn Spark Daten für groupBy, join, distinct, orderBy oder repartition zwischen Partitionen neu verteilt. Das kostet Netzwerktransfer, Serialisierung, Festplatten-I/O und Koordination. Große Zwischenergebnisse oder ein Hot Key können einzelne Tasks stark verlangsamen oder Speicherfehler verursachen. Ich reduziere Shuffles durch frühe Filter, wenige benötigte Spalten, Voraggregation, Broadcast Joins für kleine Tabellen, sinnvolle Partitionierung, Salting bei Skew und das Vermeiden unnötiger distinct- oder orderBy-Operationen. Im Spark UI prüfe ich Stages, Shuffle Read und Write, Spill, Taskdauer und Executor-Speicher.

Vorgehensweise — Stage finden → Daten reduzieren → Skew beheben → Partitionen abstimmen → problematische Operationen entfernen

Mit Spark UI und Logs bestimme ich Stage, Operation, Partition und Executor. Ursachen können Skew, große Joins, collect(), übergroße Partitionen, ineffiziente UDFs oder zu viel Cache sein. Ich filtere und projiziere früh, nutze Partition Pruning, prüfe Broadcast Joins, behandle Hot Keys mit Salting und passe die Partitionszahl an. Große collect()-Aufrufe und Python-UDFs ersetze ich, wenn native Funktionen genügen; Caches setze ich nur bei Wiederverwendung gezielt ein. Ressourcen wie Executor Memory und Overhead können angepasst werden, aber ein besserer Datenzuschnitt und Plan ist nachhaltiger als nur ein größerer Cluster.

Vorgehensweise — Spaltenformat, Schema, Kompression und Predicate Pushdown

Parquet speichert spaltenorientiert, enthält Typen und Schema, komprimiert effizient und ermöglicht Column Pruning sowie Predicate Pushdown. Analysen lesen oft nur wenige Spalten und scannen dadurch weniger Daten. CSV ist portabler Klartext, aber typunsicher, größer, langsamer und anfällig für Trennzeichen- und Escape-Probleme. Für kleine Exporte und Datenaustausch kann CSV passend sein; als primäres Format in Data Lakes oder Warehouses ist Parquet meist günstiger und schneller.

Vorgehensweise — Aktualität → Vollständigkeit → Eindeutigkeit → Gültigkeit → Abstimmung

Ich prüfe Aktualität, Zeilenvolumen, Nullwerte in Primärschlüsseln, doppelte Transaktionen, gültige Status und Währungen, zulässige Beträge und Zeiträume sowie referenzielle Integrität zwischen Bestellungen, Zahlungen, Erstattungen und Kunden. Zusätzlich stimme ich Umsatz mit Zahlungssystem oder Finance ab und überwache Abweichungen gegenüber Vortag und Vorwoche unter Berücksichtigung von Saisonalität. Fachregeln stellen sicher, dass Stornos und Testtransaktionen nicht zählen, Erstattungen Nettoumsatz mindern und Währungsumrechnung korrekt ist. Alarme müssen einem Verantwortlichen zugeordnet, handlungsrelevant und mit betroffener Tabelle, Schweregrad, Downstream-Wirkung und Runbook versehen sein.

Vorgehensweise — Wirkung bewerten → Versionen vergleichen → Lineage prüfen → mindern → Ursache beheben

Zuerst kläre ich Dashboard, Kennzahl, Nutzer, Zeitraum und betroffene Entscheidungen sowie ob die neue Zahl falsch ist oder einen alten Fehler korrigiert. Ich vergleiche alte und neue Ausgabe nach Tabelle, Partition, Zeilen, eindeutigen Werten, Summen und Segmenten und verfolge Änderungen über die Lineage. Code, Schema, Filter, Joins, Deduplizierung und Datumslogik werden geprüft. Ist die Zahl falsch, rolle ich Transformation oder Tabellenversion zurück, deaktiviere die Ansicht oder kennzeichne sie und fülle anschließend korrigierte Daten nach. Stakeholder erhalten Auswirkung, Vertrauensgrad, erwartete Behebung und den Hinweis, ob frühere Entscheidungen überprüft werden müssen.

Vorgehensweise — Instrumentierung → Ingestion → Speicherung → Verarbeitung → Modellierung → Serving → Governance

Ich kläre Volumen, Latenz, Konsumenten, Aufbewahrung, Schemaentwicklung, Datenschutz und Zuverlässigkeit. Clients senden typisierte Events über ein SDK mit event_name, Nutzer- und Sitzungs-ID, Zeitstempel, Eigenschaften, App-Version und Plattform. Ein Collector schreibt in einen dauerhaften Stream und legt Rohereignisse für Replay in Object Storage sowie für Analysen im Warehouse oder Lakehouse ab. Die Verarbeitung validiert Schemata, dedupliziert, filtert Bots und interne Nutzer, bildet Sitzungen und löst Identitäten auf. Daraus entstehen fact_events, fact_sessions, dim_users und fachliche Marts. Verträge, Schema Registry, PII- und Consent-Regeln, Lineage, Verantwortliche, Aktualitäts- und Volumenalarme sichern die Plattform. Serving umfasst BI, Experimente, Reverse ETL und Feature Stores.

Vorgehensweise — Offline-/Online-Konsistenz → Feature-Definitionen → Aktualität → Serving → Monitoring

Ein Feature Store stellt wiederverwendbare, verlässliche Features für Training und Serving bereit. Offline-Features liegen nach Datum und Entität partitioniert im Warehouse oder Lakehouse; Online-Features in einem latenzarmen Key-Value Store. Eine Registry dokumentiert Name, Eigentümer, Entity Key, Transformation, Aktualitäts-SLA, Quellen und Beschreibung. Point-in-time Correctness verhindert, dass Training zukünftige Informationen verwendet. Online- und Offline-Transformationen sollten dieselbe Logik nutzen oder streng gegeneinander getestet werden. Monitoring umfasst Aktualität, Nullquoten, Verteilungsdrift, Serving-Latenz, Training-serving Skew und Modellwirkung; Governance regelt PII, Lineage, Berechtigungen und Ablösung.

Vorgehensweise — Wirkung → Triage → Minderung → Ursache → Prävention

Ich wähle einen Vorfall mit echter Wirkung, etwa fehlende Daten, falsche Kennzahlen, Duplikate, ein defektes Dashboard oder beeinträchtigte Produktfunktionen. Zuerst erkläre ich Betroffene und Bedeutung. Danach beschreibe ich Triage über Logs, Orchestrator, Quellenaktualität, Deployments, Schemata, Zeilenzahlen, Partitionen und Lineage sowie die Minderung durch Retry, Rollback, Patch, Backfill oder Warnung. Die stärkste Antwort endet mit Prävention: Qualitätsprüfungen, Alarme, Verträge, idempotente Writes, Runbooks, Lineage oder sicherere Deployments. Sie zeigt Verantwortung und Kommunikation statt Schuldzuweisung.

Vorgehensweise — Klären → reproduzieren → Lineage verfolgen → lösen → dokumentieren

Ich konkretisiere Kennzahl, Tabelle, Zeitraum, Filter, erwarteten Wert und fachliche Begründung. Danach reproduziere ich die Abfrage und prüfe Granularität, Filter, Joins, Zeitzone, Aktualität, Definition und letzte Änderungen entlang der Lineage. Sind Daten falsch, behebe ich sie und kommuniziere die Wirkung. Ist die Technik korrekt, aber die Definition anders als erwartet, einigen wir uns auf die fachliche Definition und dokumentieren sie. Bei verbleibender Unsicherheit sage ich klar, was bekannt ist, was geprüft wird und wann die Rückmeldung folgt. Schnelle, evidenzbasierte Antworten bauen Vertrauen auf.

Vorgehensweise — Wirkung → Zuverlässigkeit → Dringlichkeit → Abhängigkeiten → Hebelwirkung

Ich priorisiere nach Geschäftswirkung, Zuverlässigkeitsrisiko, Dringlichkeit, Downstream-Abhängigkeiten und Hebelwirkung. Eine defekte Umsatzpipeline oder ein Compliance-Risiko ist wichtiger als ein optionales Modell; eine Plattformverbesserung kann viele Einzelanfragen übertreffen. Ich trenne Vorfälle, strategische Plattformarbeit, Stakeholder-Wünsche, technische Schulden und operativen Aufwand. Ein ausgewogenes Verfahren nutzt Verantwortung, SLAs, Schweregrade, Roadmap und transparente Trade-offs und erklärt, was verschoben wird und welches Risiko daraus entsteht.