Datenplattform im Betrieb

Speicherspitze und Laufzeit desselben Laufs vor und nach dem Umbau der Verarbeitung.

Ausgangslage

Die Plattform aus der ersten Fallstudie lebt von Daten, die an jedem Werktag neu kommen. Was nachts nicht durchläuft, fehlt morgens. Die Daten stammen aus vier Quellen: dem ERP-System über eine Programmierschnittstelle, einem Data Warehouse, einer Analyseplattform und der Warenwirtschaft. Zusammen sind es rund 155 Millionen Zeilen und zehn Jahre Historie.

Eine Datenplattform, die das täglich schafft, ist keine Sammlung von Skripten. Sie ist ein Betrieb mit Abhängigkeiten, Laufzeiten, Grenzen und Ausfällen. Ich verantworte diesen Betrieb allein, neben der Anwendung, die davon abhängt. Das setzt den Maßstab: Jeder Handgriff, den ich nachts nicht machen muss, zählt doppelt.

Entscheidung

Erstens: Orchestrierung über Assets statt über Zeitpläne. Jeder Datenbestand ist ein Asset mit bekannten Abhängigkeiten. Fehlt eines, sehe ich sofort, was davon abhängt und was neu gerechnet werden muss. Ein Zeitplan weiß das nicht.

Zweitens: Betriebsreife aus Störfällen, nicht aus Vermutung. Ich habe die Absicherung nicht auf Verdacht gebaut. Nach jedem echten Ausfall habe ich genau die Lücke geschlossen, die er gezeigt hat. Das klingt nach Nachlässigkeit und ist das Gegenteil: Jede Regel in der Plattform hat einen Vorfall als Beleg.

Drittens: Alarme mit dem ganzen Fehler. Eine Meldung „Job fehlgeschlagen” hilft niemandem. Der Alarm trägt den vollständigen Traceback, damit ich beim ersten Blick weiß, wo ich ansetze.

Umsetzung

Die Plattform umfasst 57 Assets in 16 Jobs. An einem Werktag laufen rund 164 orchestrierte Schritte. Sie holen die Rohdaten aus den vier Quellen, prüfen sie, bereiten sie auf und schreiben die Spaltendateien, aus denen die Anwendung liest.

Die Härtung besteht aus vier Bausteinen. Gleichzeitigkeitsgrenzen, damit parallele Abrufe eine Quelle nicht überlasten. Zeitlimits, damit ein hängender Abruf nicht die ganze Nacht blockiert. Wiederholungsregeln, damit ein kurzer Aussetzer kein Eingriff von Hand wird. Und Alarme mit Traceback. Jeder dieser Bausteine ist nach einem echten Störfall entstanden.

Der dritte Standort kam mit 6,85 Millionen Zeilen und 26 Jahren Historie dazu. Bei der Anbindung lag die Speicherspitze zunächst bei 39,3 Gigabyte und die Laufzeit bei 22,3 Sekunden. Ich habe die Verarbeitung umgebaut. Danach: 9,7 Gigabyte und 7,1 Sekunden.

Ergebnis mit Messung

Im Betrieb: 57 Assets, 16 Jobs, rund 164 Schritte je Werktag, rund 155 Millionen Zeilen aus vier Quellsystemen, zehn Jahre Historie. Der dritte Standort bringt 6,85 Millionen Zeilen mit 26 Jahren Historie.

Eine Zahl fehlt hier bewusst: die Quote der Läufe, die ohne Eingriff durchgehen. Ich nenne sie erst, wenn ich sie sauber gemessen habe. Ohne diese Zahl bleibt „gehärtet” eine Behauptung mit Belegen, keine Messung.

Was ich anders machen würde

Grenzen und Zeitlimits von Anfang an als Standard, den man lockert, statt als Nachrüstung nach dem Vorfall. Das widerspricht meiner zweiten Entscheidung nur zum Teil. Die Grundsicherung würde ich vorziehen. Die Feinjustierung würde ich weiter aus echten Vorfällen ableiten, weil nur die zeigen, wo es wirklich klemmt.

Vor dem dritten Standort ein Lasttest mit den echten Mengen. Die Speicherspitze hätte ich vorher gesehen, nicht erst im Lauf.

Eine Konvention für Namen und Schichten der Assets früh festlegen. Bei 57 Assets zahlt sie sich aus. Wer sie später einführt, benennt um, und jede Umbenennung ist ein Risiko im Betrieb.

Die Quote der störungsfreien Läufe von Anfang an mitzählen. Sie ist die eine Zahl, an der sich ein Betrieb messen lässt, und sie fehlt mir heute.

Technik

• Dagster
• Python
• DuckDB
• Parquet
• SAP R/3 (RFC)
• SQL Server
• Databricks
• Warenwirtschaft