Thema: data-engineering
-
Pipelines, die beim Einlesen unerwartete Schemaänderungen der Quelle ablehnen, erkennen vorgelagerte Änderungen früher, scheitern aber häufiger als Pipelines, die sie anpassen
Hypothese: Eine Pipeline, die einen Einlesevorgang scheitern lässt, sobald das Quellschema vom deklarierten abweicht (so wie Avros Schema-Resolution einen Fehler meldet, wenn ein Leserfeld keinen Default hat und der Schreiber es nicht liefert), erkennt vorgelagerte Änderungen innerhalb eines Laufs, scheitert aber auch bei harmlosen Änderungen. Eine anpassende Pipeline läuft dagegen weiter und lässt manche Änderungen unbemerkt bis zu den Konsumenten durch; vorgeschlagen wird ein Vergleich an denselben Quellen, ohne Ergebnis zu behaupten.
-
Langsam veränderliche Dimensionen: überschreiben, eine Zeile hinzufügen oder eine Spalte hinzufügen
Ändert sich ein Dimensionsattribut (eine Kundin zieht um, ein Produkt wird neu klassifiziert), überschreibt Typ 1 den Wert und verliert die Historie, Typ 2 fügt unter einem neuen Surrogatschlüssel eine neue Zeile mit Gültig-ab- und Gültig-bis-Datum sowie einem Aktuell-Flag hinzu, und Typ 3 behält den vorherigen Wert in einer zusätzlichen Spalte. Snapshot-Werkzeuge setzen Typ 2 um, indem sie bei jedem Lauf einen Aktualisierungszeitstempel oder eine Menge von Spalten vergleichen.
-
Differential Privacy in einem Absatz, und wo sie nicht passt
Differential Privacy begrenzt, wie stark der Datensatz einer einzelnen Person die Ausgabeverteilung eines Abfragemechanismus verändern kann, indem kalibriertes Rauschen hinzugefügt und jede Antwort einem Budget belastet wird; sie passt zu wiederholten aggregierten Veröffentlichungen über grosse Populationen und passt nicht zu Datensätzen auf Einzelfallebene, kleinen Gruppen, exakten Operationen oder einmaligen internen Analysen.
-
Wie weit zurück sollte eine geplante Pipeline für verspätet eintreffende Ereignisse erneut verarbeiten, und wie haben Teams das Fenster gewählt?
Offene Frage: Stream-Engines räumen ein, dass manche Ereignisse beliebig verspätet eintreffen können, und Batch-Scheduler führen jedes Intervall einmal nach dessen Abschluss aus; ein verbreiteter Kompromiss verarbeitet bei jedem Lauf die letzten N Intervalle erneut, aber N ist meist geraten. Welche Evidenz wurde zur Bemessung von N genutzt, und was geschah mit noch später eingetroffenen Ereignissen?
-
ETL versus ELT: Wo die Transformation läuft und was das ändert
ETL transformiert Daten in einer separaten Engine, bevor sie ins Ziel geladen werden; ELT lädt zuerst die Rohdaten und transformiert sie mit der eigenen Verarbeitung des Zielspeichers. Die Wahl entscheidet, wo Rechenleistung bezahlt wird, welche Rohdaten im Warehouse landen und wie leicht sich eine Transformation erneut ausführen lässt.
-
Aktualitäts- und Zeilenzahl-Prüfungen an rohen Quelltabellen erkennen die meisten Pipeline-Vorfälle früher als nachgelagerte spaltenbezogene Tests
Hypothese: In einem Warehouse mit geschichteten Modellen zeigt sich die Mehrheit der Vorfälle, die letztlich für Berichtskonsumenten sichtbar werden, zuerst als veralteter oder zu kleiner Rohquellen-Ladevorgang, sodass Aktualitäts- und Volumenprüfungen auf der Quellschicht sie früher erkennen als Not-Null-, Eindeutigkeits- und Wertebereichstests auf nachgelagerten Modellen; ein vorgeschlagener Vergleich anhand aufgezeichneter Vorfälle.
-
Idempotente Datenpipelines: Partitions-Überschreiben, sichere Neuläufe und Backfills ohne Doppelzählung
Eine Pipeline-Aufgabe sollte bei jedem erneuten Lauf für dasselbe Datenintervall dieselbe Ausgabe erzeugen: eine feste Partition der Eingabe lesen, die entsprechende Partition der Ausgabe ersetzen statt anhängen, und dort, wo Ersetzen nicht möglich ist, nach Schlüssel upserten. Backfills werden dadurch zu gewöhnlichen Neuläufen über eine Reihe von Intervallen, statt zu einer Quelle doppelter Zeilen.
-
Grundlagen spaltenorientierter Speicherung: wie eine Parquet-Datei aufgebaut ist und warum analytische Lesezugriffe weniger Daten berühren
Eine Parquet-Datei ist eine Folge von Row Groups, von denen jede pro Spalte einen Column Chunk enthält; jeder Chunk ist in Pages unterteilt, die die Einheit für Kodierung und Kompression bilden. Die Metadaten stehen am Ende, sodass eine lesende Stelle zunächst den Footer öffnet, nur die benötigten Spalten auswählt und Row Groups sowie Pages anhand ihrer Min/Max-Statistiken überspringt. Die spaltenweise Anordnung ist es, die Dictionary- und Lauflängenkodierungen wirksam macht.
-
Datenqualitätsprüfungen: Aktualität, Volumen, Nullwerte und Eindeutigkeit als minimales Testset
Vier günstige Prüfungen decken die meisten defekten Ladevorgänge auf: Die Quelle wurde aktuell genug aktualisiert (Aktualität), das Intervall lieferte eine plausible Zeilenzahl (Volumen), Schlüssel und Pflichtmasse sind nicht null, und die deklarierte Granularität ist eindeutig. Jede Prüfung als Abfrage formulieren, die fehlschlagende Zeilen zurückgibt, nach dem Laden und vor der Veröffentlichung ausführen, und Warnungen von blockierenden Fehlern trennen.
-
Welcher Anteil der Tabellen eines Warehouses wird nach dem Schreiben nie wieder gelesen, und wie haben Teams das herausgefunden?
Offene Frage: Pipelines schreiben weiterhin Tabellen, die einmal von einem Dashboard oder Modell benötigt wurden; PostgreSQLs kumulative Statistiken legen Scan-Zahlen und Zeitpunkte des letzten Scans je Tabelle offen, und andere Engines führen Abfrageverläufe, aber welcher Anteil der Tabellen erwies sich als ungelesen, als ein Team nachsah, wie wurden pipeline-interne Lesezugriffe ausgeschlossen, und was wurde mit der Antwort gemacht?
-
Schema-Evolution mit Avro und Parquet: Reader- und Writer-Schemas, zusammengeführte Dateien und Kompatibilitätsmodi
Avro gleicht das Schema eines Writers Feld für Feld mit dem Schema eines Readers ab, füllt fehlende Felder aus den Standardwerten des Readers und ignoriert unbekannte Felder; Parquet-Dateien mit unterschiedlichen, aber kompatiblen Schemas kann die lesende Engine mit einem gewissen Aufwand zusammenführen; eine Schema-Registry erzwingt Rückwärts-, Vorwärts- oder vollständige Kompatibilität. Optionale Felder mit Standardwerten hinzuzufügen ist der sichere Weg, Umbenennungen und Typänderungen sind es nicht.
-
Datenqualitätsprüfungen: Aktualität, Menge, Nullwerte und Eindeutigkeit als Mindestsatz
Vier billige Prüfungen fangen die meisten kaputten Ladeläufe: Ist die Quelle frisch genug, kam eine plausible Zeilenzahl, sind Schlüssel und Kennzahlen gefüllt, ist die erklärte Körnung eindeutig? Jede Prüfung als Abfrage formulieren, die fehlerhafte Zeilen liefert, nach dem Laden und vor dem Veröffentlichen ausführen, Warnung und Blockade trennen.
-
Star schema basics: facts, dimensions and declaring the grain
A star schema stores measurements in fact tables and descriptive context in dimension tables linked by keys; the design starts by declaring the grain, what one fact row represents, because every measure and dimension must be consistent with it. Fully additive measures sum across any dimension, semi-additive ones not across time, and ratios must be stored as their components.
-
Deduplication strategies for records: exact rows, keep-latest by key and bounded windows
Decide first what counts as a duplicate: identical rows, several versions of one key, or messages redelivered within a window. Exact duplicates fall to DISTINCT; versions need a keep-latest rule with an explicit ordering; redelivery is deduplicated on an idempotency key within a bounded time or state window, as message queues and stream engines do.
-
Downsampling and retention tiers for time-series data
Keep raw samples for a short window, roll them up into fixed bins with count, sum, min and max for a longer one, and delete by partition when a tier expires; choose aggregates that can be re-aggregated, align bins to a fixed origin, and run the rollup only after late data for the bin has arrived.
-
Choosing between batch and streaming: required latency, event time and late data
Batch processes a bounded input after its interval closes and is reproducible by construction; streaming processes an unbounded input as it arrives and must reason about event time, watermarks and late data to give stable answers. Pick streaming only when a consumer acts within seconds of an event; otherwise the batch path is simpler, and it is needed for reprocessing anyway.
Maschinenlesbar: JSON