Data-Engineer-Interviewfragen

Was ist der Unterschied zwischen ETL und ELT, und warum hat sich ELT durchgesetzt?

ETL transformiert Daten, bevor sie ins Warehouse geladen werden — das ergab Sinn, als Storage und Compute im Warehouse teuer und unflexibel waren. ELT lädt zuerst die Rohdaten und transformiert sie danach mit der eigenen Engine des Warehouses. Für die Analytics hat sich ELT durchgesetzt, weil Cloud-Warehouses Compute elastisch gemacht und vom Storage entkoppelt haben — Rohdaten aufzuheben erlaubt es, Modelle bei geänderten Anforderungen neu abzuleiten, statt aus Quellsystemen neu einzulesen, auf die man womöglich keinen Zugriff mehr hat.

Was ist ein Star Schema, und wann würdest du keins verwenden?

Ein Star Schema hat eine zentrale Faktentabelle mit Events und numerischen Kennzahlen, umgeben von denormalisierten Dimensionstabellen, die den Kontext beschreiben. Es ist auf analytische Abfragen optimiert: wenige Joins, vorhersagbare Aggregation, einfach für BI-Tools. Du würdest darauf verzichten bei reinem Event-Streaming, bei wirklich explorativer Data Science auf Rohdaten, oder wenn das Warehouse spaltenorientiert genug ist, dass eine breite denormalisierte Tabelle besser performt und weniger Wartungsaufwand kostet.

Erkläre Slowly Changing Dimensions, insbesondere Type 2.

Eine SCD behandelt Attribute, die sich über die Zeit ändern, etwa wenn ein Kunde in eine andere Stadt zieht. Type 1 überschreibt den alten Wert und verliert damit die Historie. Type 2 fügt eine neue Zeile mit Gültigkeitsdaten und einem Current-Flag ein, sodass ein über den Surrogatschlüssel verknüpfter Fact das Attribut so widerspiegelt, wie es zum Zeitpunkt des Events war. Genau das erlaubt es, die Frage „wie waren die Umsätze nach Region im letzten Jahr" korrekt zu beantworten, statt alte Umsätze nachträglich der neuen Region des Kunden zuzuschreiben.

Was sind Window Functions, und wo schlagen sie ein GROUP BY?

Eine Window Function rechnet über eine Menge von Zeilen, die mit der aktuellen Zeile in Beziehung stehen, ohne sie zusammenzufassen, sodass die Detailebene der Zeile neben dem Aggregat erhalten bleibt. Damit sind sie das richtige Werkzeug für laufende Summen, Ranking innerhalb einer Partition, den Vergleich einer Zeile mit dem Gruppendurchschnitt und lag/lead-Vergleiche zwischen aufeinanderfolgenden Events. Ein GROUP BY würde dich zwingen, erst zu aggregieren und dann zurück auf die Detailzeilen zu joinen — mehr Code, mehr Shuffling und leichter fehleranfällig.

Was bedeutet es, dass eine Pipeline idempotent ist, und warum ist das wichtig?

Idempotent bedeutet, dass ein zweiter Lauf desselben Tasks für denselben Zeitraum das gleiche Ergebnis liefert, statt Daten zu duplizieren. Das ist wichtig, weil Retries unvermeidlich sind — ein Task scheitert auf halbem Weg, jemand startet gestern erneut, ein Backfill überschneidet sich mit einem geplanten Lauf. Die üblichen Umsetzungen sind das Löschen und Neuschreiben der Zielpartition oder ein Merge über einen Business Key statt eines blinden Insert. Pipelines, die nur bei exakt einmaligem Lauf funktionieren, brechen beim ersten Retry.

Wie entwirfst du einen Airflow-DAG, der sich sicher backfillen lässt?

Jeder Task sollte über das logische Ausführungsdatum parametrisiert werden statt über „jetzt", damit ein Lauf für ein altes Datum auch die Daten dieses Datums liest und schreibt. Tasks müssen idempotent sein, damit ein erneuter Lauf seine eigene Partition überschreibt. Man setzt sinnvolle Retries mit Backoff und nutzt max_active_runs sowie Pools, damit ein Backfill über zwei Jahre nicht das Warehouse sättigt und Produktionsläufe aushungert. Abhängigkeiten zwischen DAGs drückt man sicherer über Prüfungen der Datenverfügbarkeit aus als über geratene Zeitpläne.

Was ist ein Shuffle in Spark, und warum ist er teuer?

Eine narrow Transformation wie map oder filter arbeitet innerhalb einer Partition und braucht daher keine Datenbewegung. Eine wide Transformation wie groupBy, join oder repartition verlangt, dass Zeilen mit demselben Schlüssel auf demselben Executor landen, was bedeutet, Zwischendaten auf Disk zu schreiben und übers Netzwerk zu bewegen — das ist ein Shuffle. Er dominiert die Laufzeit eines Jobs, weshalb Tuning vor allem bedeutet, Shuffles zu reduzieren: die kleine Seite eines Joins broadcasten, vor dem Join filtern und ein Partitioning wählen, das zum Abfragemuster passt.

Was ist Data Skew, und wie gehst du damit um?

Skew bedeutet, dass ein Schlüssel einen unverhältnismäßig großen Anteil der Zeilen trägt, sodass ein einzelner Task den Großteil der Daten verarbeitet, während der Rest des Clusters untätig ist — der Job sieht eine Stunde lang zu 99 % fertig aus. Man erkennt es im Spark UI an einem Task mit deutlich größerem Input als seine Nachbarn. Abhilfen sind Salting des heißen Schlüssels, um ihn über mehrere Partitionen zu verteilen, das Broadcasten der kleineren Tabelle, um den Shuffle-Join ganz zu vermeiden, sowie die separate Behandlung bekannter heißer Schlüssel getrennt vom Long Tail.

Warum Parquet statt CSV oder JSON, und was bringt Partitionierung?

Parquet ist spaltenorientiert und komprimiert, sodass eine Abfrage, die drei von vierzig Spalten liest, wirklich nur diese drei liest, und es trägt Schema und Spaltenstatistiken mit, die es Engines erlauben, ganze Row Groups zu überspringen. CSV und JSON erzwingen jedes Mal einen vollständigen Scan und ein erneutes Parsen. Partitionierung nach einer Spalte, auf die du filterst, meist das Datum, lässt die Engine ganze Verzeichnisse überspringen — aber zu feine Partitionierung erzeugt Millionen winziger Dateien, und der Metadaten-Overhead kostet dann mehr, als er einspart.

Was bedeutet Exactly-Once-Verarbeitung im Streaming wirklich?

Echte Exactly-Once-Zustellung ist end-to-end nicht erreichbar; was Systeme tatsächlich liefern, ist Effectively-Once-Verarbeitung — Duplikate können ankommen, aber das beobachtbare Ergebnis ist so, als wäre jede Nachricht genau einmal gezählt worden. Erreicht wird das durch idempotente Writes, Deduplizierung über einen Message Key oder transaktionale Sinks, die Offsets und Output atomar committen. Exactly-Once zu behaupten, ohne zu nennen, welcher Mechanismus das sicherstellt, ist ein klassisches Red Flag im Interview.

Wie gehst du mit verspätet eintreffenden Daten um?

Zuerst wird die Semantik festgelegt: Wird der Datensatz dem Zeitpunkt zugeordnet, an dem das Event passiert ist, oder dem, an dem er empfangen wurde? Event Time ist für Analytics meist korrekt, verlangt aber, dass die Pipeline eine bereits veröffentlichte Partition wieder öffnen und neu schreiben kann. Watermarks legen fest, wie lange gewartet wird, bevor ein Fenster als geschlossen gilt, und alles, was später eintrifft, geht in einen Korrekturpfad oder eine eigene Tabelle für verspätete Daten. Der Designfehler ist, verspätete Daten stillschweigend zu verwerfen, weil die Zahlen dann von der Quelle abweichen und niemand weiß, warum.

Wie testest du Datenqualität, und was prüfst du?

Tests laufen als Schritte der Pipeline, die laut scheitern, statt als Dashboards, die niemand liest. Die Standardprüfungen sind Freshness, Zeilenanzahl gegen Erwartung, Eindeutigkeit von Schlüsseln, Not-Null auf Pflichtspalten, referenzielle Integrität zwischen Fact und Dimension sowie zulässige Wertebereiche oder Aufzählungen. Tools wie dbt-Tests oder Great Expectations formalisieren das. Die wichtige Design-Entscheidung ist, welche Fehler nachgelagerte Tasks blockieren und welche nur alarmieren, denn bei jeder Anomalie zu blockieren trainiert die Leute darauf, die Alerts zu ignorieren.