IFCO senkt Laufzeit eines zentralen dbt-Jobs auf Databricks um mehr als 60 Prozent

Milliarden Tracking-Ereignisse, verspätete Daten und rückwirkende Korrekturen

IFCO betreibt wiederverwendbare Kunststoffbehälter (Reusable Plastic Containers, RPCs), die frisches Obst und Gemüse von Erzeugern und Packbetrieben zu Distributionszentren und Händlern transportieren. Anschließend kehren die Kisten in Servicezentren zurück, wo sie gewaschen, sortiert und erneut ausgeliefert werden, und das in mehr als 50 Ländern. Jede Kiste und jede Palette wird verfolgt. Diese Daten fließen in Kennzahlen wie Umlaufzeit, Verlust, Bruch, Waschkosten und Poolgröße ein.

Das Unternehmen hat dafür einen Semantic Layer aufgebaut, eine Sammlung governter dbt-Modelle, die rohe Tracking-Ereignisse in Geschäftskennzahlen überführen. Er vereint Barcode-Scans an Waschstraßen, RFID-Lesungen an Verladetoren und batteriebetriebene Tracker, die GPS-Position, nahe Bluetooth-Beacons und Temperatur melden.

Databricks nennt drei Schwierigkeiten. Pro Tag treffen Milliarden Tracking-Ereignisse ein. Manche Datenfeeds hinken um Wochen, einige sogar um Monate hinterher, und zwar ohne festen Rhythmus. Und weil die Aktivität eines Assets eine Abfolge bildet, verändert ein verspäteter Scan, was die Pipeline bereits über alles danach geschlossen hat. Die Pipeline muss deshalb Zustände neu berechnen, die sie schon veröffentlicht hat. Das erklärte Ziel: schnell eine gute Schätzung liefern und sich der Wahrheit annähern, sobald verspätete Daten eintreffen, ohne jede Nacht alles neu zu verarbeiten.

So wenige Zeilen wie möglich anfassen

Der gemeinsam mit Databricks Forward Deployed Engineering verfasste Beitrag führt den größten Teil des Gewinns auf ein Prinzip zurück: Jeder Lauf soll so wenige Zeilen wie möglich berühren, und zwar so früh wie möglich. Die Transformationslogik bleibt in dbt, und jede Incremental-Einstellung entspricht einem konkreten Schreibverhalten von Delta Lake. Beschrieben werden folgende Techniken:

• Liquid Clustering auf den Spalten, nach denen gefiltert und gejoint wird, etwa Asset und Ereignisdatum, damit die Engine Dateien überspringen kann, statt sie zu scannen.
• Eine bewusst gewählte Incremental-Strategie. Für schlüsselbasierte, dedup-lastige Upserts ist Merge der Standard. Mit asset_id und event_date_time als Schlüssel ermöglicht sein Equi-Join-Prädikat Dynamic File Pruning, sodass ein Schreibvorgang nur den Ausschnitt berührt, den er verändert. Ein Row-Hash-Guard verhindert, dass unveränderte Zeilen neu geschrieben werden. Die Alternative delete+insert ist einfacher, wenn ein Lauf eine Gruppe als Einheit neu ableitet, schreibt die Gruppe aber auch dort neu, wo sich nichts geändert hat.
• Ein begrenztes Schreibfenster. Bei Upstream-Modellen mit höherem Volumen beschränkt eine Zeitgrenze den MERGE auf einen jüngeren Ausschnitt der Zieltabelle. Da sie sich am Ingestion-Zeitpunkt statt am Ereigniszeitpunkt orientiert, wird auch ein Ereignis erfasst, das Monate zurückliegt, sofern es erst kürzlich eingetroffen ist.
• Nur neu berechnen, was sich geändert hat. Die Modelle beschränken die Arbeit auf Assets, die von neuen oder verspäteten Daten betroffen sind. Diese werden anhand eines Ingestion-Watermarks erkannt. Gelesen wird dabei ein größeres Fenster, als geschrieben wird.
• Aufgeräumte Delta-Tabellen. Stark genutzte Incremental-Tabellen verwenden Optimized Writes und Auto-Compaction oder Predictive Optimization, um Leseeinbußen durch viele kleine Dateien zu vermeiden.

Der Beitrag warnt: Ist das Fenster zu eng gewählt, werden verspätete Daten stillschweigend übersprungen. Es gibt keinen Fehler, die Daten werden schlicht nie verarbeitet.

Den ausgeführten Plan lesen, nicht das kompilierte SQL

Das am stärksten ausgelastete Modell führt Beobachtungen aller Tracking-Technologien zu einem ortsbezogenen Datenstrom pro Asset zusammen. Es nutzt Fensterfunktionen, partitioniert nach Asset und sortiert nach Ereigniszeit, und greift auf die integrierten H3-Funktionen von Databricks SQL zurück, wenn eine Beobachtung keinen expliziten Standort hat. H3 ordnet jeden Breiten- und Längengrad einer hexagonalen Gitterzelle zu, sodass "gleicher Ort" zu einem günstigen Vergleich von Zell-IDs und Gitterabstand wird. Laut Beitrag war es mit großem Abstand der größte Einzelverbraucher an Laufzeit.

Der erste Schritt des Teams bestand darin, sich anzusehen, was tatsächlich lief. Bei einem Incremental-Modell ist das kompilierte SELECT nicht die Anweisung, die Databricks ausführt, denn dbt erzeugt darum herum temporäre Views, Scans der Zieltabelle und einen abschließenden Schreibvorgang. Der Beitrag argumentiert, nur das stufenweise Lesen des ausgeführten Abfrageplans aus der Query History zeige, wo Zeit und Arbeitsspeicher verbraucht werden.

So betrachtet scannte das Modell Milliarden Zeilen, lagerte Hunderte Gigabyte auf die Festplatte aus und verbrachte rund 85 Prozent seiner Zeit in einer einzigen Fenster-Sortierung samt Shuffle pro Asset. Faktisch baute es bei jedem Lauf die gesamte Tabelle neu auf.

Was das für dbt-Teams auf Databricks bedeutet

In der Zusammenfassung des Beitrags heißt es außerdem, IFCO habe diese planbasierte Diagnose zu einem wiederholbaren Skill gebündelt, der für jedes Modell läuft. Empfohlen wird, das dbt-Projekt mit dem Open-Source-Tool databricks-dbt-factory als einen Task pro Modell in Databricks Jobs auszuführen, statt als einen undurchsichtigen Gesamtjob. Laut Databricks sorgt das für Transparenz pro Modell, gezielte Wiederholungsläufe und erzwungene Tests.

Für Teams mit großen inkrementellen dbt-Projekten lautet die Lehre aus der Quelle: Diese Einstellungen auf der passenden Datengranularität anwenden und anschließend am tatsächlichen Abfrageplan überprüfen, ob die Engine wirklich Daten überspringt, statt stillschweigend zu scannen.