Wie der Databricks Feature Store Features mit einer Aktualität im Subsekundenbereich bereitstellt

Machine-Learning-Modelle sind nur so gut wie die Signale, die sie empfangen. Ein Anwendungsfall zur Betrugserkennung muss innerhalb von Millisekunden, nachdem ein Benutzer auf „Kaufen“ geklickt hat, entscheiden, ob die Transaktion zugelassen wird. Die richtige Entscheidung hängt davon ab, ob eine verdächtige Transaktion erkannt wird, die erst vor wenigen Sekunden stattgefunden hat. Die Kombination der durchschnittlichen Transaktionen eines Benutzers der letzten 30 Tage mit dem Gesamttransaktionsbetrag der letzten 10 Minuten macht potenziellen Betrug sichtbar. Die langfristigen Aggregationen erstellen ein Basisprofil des Benutzers, um festzulegen, was normal ist, während die neuesten Daten helfen, abnormales Verhalten direkt bei dessen Entstehen aufzudecken. Die Personalisierung steht vor derselben Herausforderung: Nur die aktuellsten Signale erfassen die momentane Absicht des Benutzers und steigern die Interaktion.

Spark-Pipelines sind ein etablierter Weg, um Massendaten im Lakehouse für historische Basis-Features zu verarbeiten. Die regelmäßige Ausführung dieser Batch-Jobs ist bewährt, führt jedoch zu einer Verzögerung von Minuten oder gar Stunden. Für Basis-Signale über Benutzer ist diese Verzögerung ein akzeptabler Preis für eine einfachere Infrastruktur. Wenn Modelle jedoch aktuelle Signale benötigen, stößt diese Infrastruktur an ihre Grenzen. Eine Verzögerung im Sekunden- oder Millisekundenbereich ist mit bestehenden Feature-Store-Plattformen nicht möglich. Um den Nutzen aktueller Features bereitzustellen, sind Data Scientists gezwungen, komplexe, streamingspezifische Logik für diese Aggregationen zu implementieren und eine eigene, gehostete Infrastruktur aufzubauen.

Mit dem Databricks Feature Store können Sie ein Feature einmal erstellen und überall verwenden: Dieselbe Definition steuert sowohl umfangreiche Offline-Batch-Flows als auch hochaktuelle Online-Feature-Pipelines. Das Framework nimmt Ihnen die Infrastrukturlast ab und orchestriert den Spark Real-Time Mode (RTM) für die kontinuierliche Stream-Verarbeitung, Lakebase für streaming-optimierten Online-Speicher und Model Serving für den Abruf in großem Maßstab. Und einmal erstellt, wird dieses Feature in Millisekunden bereitgestellt: Eine End-to-End-p99-Latenz von 200 ms, vom Eintreffen eines Ereignisses in Kafka bis zur Verfügbarkeit im Online-Feature-Store.

Architektur: Von Kafka zum Feature Store in 200 ms

Werfen wir einen Blick unter die Haube, um zu sehen, wie der Databricks Feature Store eine infrastrukturunabhängige Feature-Definition nutzt und eine Pipeline aufbaut, um diese konsistent innerhalb von Millisekunden zu berechnen. Der End-to-End-Pfad für ein Streaming-Feature sieht wie folgt aus:

1. Ereignisse gehen in Kafka ein – Rohdaten wie Kreditkartentransaktionen, Werbeeinblendungen oder Clickstream-Events
2. Eine Spark-RTM-Pipeline auf serverlosen Lakeflow Spark Delta Pipelines verarbeitet Ereignisse kontinuierlich und berechnet fortlaufende Aggregationen in Echtzeit
3. Aktualisierte Aggregate werden über einen neuen Streaming-JDBC-Sink in Lakebase geschrieben und landen im Online-Feature-Store
4. Model Serving-Endpunkte rufen die neuesten Features zum Inferenzzeitpunkt aus Lakebase ab und führen sie dem Modell automatisch zu

Beziehen wir dies auf unser Betrugs-Feature: die Summe des Transaktionsbetrags eines Benutzers in den letzten 10 Minuten. Jedes eingehende Ereignis enthält die Transaktionsdetails – Betrag, Ort, Benutzer-ID, Händlerinformationen – und wird an eine zustandsbehaftete Pipeline weitergeleitet. Die Pipeline fragt eine lokale RocksDB-Instanz ab, die die laufende Transaktionssumme des Benutzers enthält, mit Ablaufzeiten, die das Zeitfenster auf die letzten 10 Minuten beschränken. Die Pipeline liest und erhöht den Wert lokal und schreibt dann den aktualisierten Feature-Wert in Lakebase. Wenn also eine Anfrage an das Modell zur Genehmigung einer neuen Transaktion eingeht, ist eine aktuelle Transaktionssumme mit einer Aktualität im Subsekundenbereich im Feature Store verfügbar. Dieses Summen-Feature wird zusammen mit der historischen Kaufbasis des Benutzers abgerufen, um die Entscheidung über die Genehmigung zu unterstützen. Eine Summe, die deutlich über der historischen Basislinie liegt, ist für das Modell ein starker Indikator für potenziellen Betrug.

Jede Komponente in dieser Pipeline wurde so optimiert, dass eingehende Ereignisse so schnell wie möglich weitergeleitet, Aggregationen berechnet und Features in den Online-Store geschrieben werden.

Rolling Window: Aggregationen in Millisekunden aktualisieren

Bevor wir näher auf die Infrastruktur eingehen, lassen Sie uns über Aggregations-Features sprechen und über den Wechsel von einem Batch-Synchronisations-Paradigma hin zu Echtzeit-Updates.

Aggregations-Features über ein Zeitfenster – zum Beispiel Häufigkeiten, Summen oder Durchschnitte – sind leistungsstarke und flexible Signale für Echtzeit-ML. Ein langfristiges Batch-Feature legt eine historische Basislinie für den Benutzer über einen bestimmten Zeitraum fest, sodass sich das Modell anpassen und das Verhalten jedes Benutzers verstehen kann. Ein kurzes, aktuelles Feature reagiert schnell auf sich ändernde Situationen, um neues Benutzerinteresse oder betrügerische Aktivitäten zu erkennen. Zeitfenster definieren eine Zeitspanne (z. B. 10 Minuten) sowie die Art und Weise, wie sich diese Zeitspannen im Laufe der Zeit entwickeln (z. B. überlappend oder disjunkt).

Der Databricks Feature Store unterstützt 3 verschiedene Zeitfenster:

• Tumbling Windows (feste Zeitfenster) sind an der Echtzeit (Wall-Clock) ausgerichtet und beginnen, sobald das vorherige Intervall endet. Ein 10-minütiges Tumbling Window könnte beispielsweise die Zeiträume 12:00–12:10 und danach 12:10–12:20 abdecken. Ereignisse werden in diesen festen Intervallen zusammengefasst, wobei am Ende eines Intervalls ein Feature-Wert ausgegeben wird. Das bedeutet, dass das Aggregat nur an den Intervallgrenzen aktuell ist
• Sliding Windows (gleitende Zeitfenster) sind ebenfalls an der Echtzeit ausgerichtet, lassen jedoch überlappende Intervalle zu. Ein 10-minütiges Sliding Window mit einem 5-minütigen Gleitintervall könnte beispielsweise die Zeiträume 12:00–12:10, dann 12:05–12:15 und danach 12:10–12:20 abdecken.
• Rolling Windows (fortlaufende Zeitfenster) sind nicht an der Echtzeit ausgerichtet, sondern blicken vom Zeitstempel jedes Ereignisses mit Millisekundengenauigkeit zurück. „Die Summe der Transaktionen in den letzten 10 Minuten bezogen auf die aktuelle Echtzeit“ ist immer auf dem neuesten Stand, da sich das Fenster mit jedem neuen Ereignis verschiebt. Dies macht RollingWindow zur idealen Lösung für die Echtzeit-Bereitstellung, bei der sich das „Jetzt“ ständig ändert.

Tumbling und Sliding Windows sind weiterhin nützlich, wenn sich ein Feature nicht häufig ändert: Sie erzeugen weniger Updates, sind kostengünstiger im Unterhalt und fügen sich problemlos in einfachere, geplante Pipelines ein. Rolling Windows tauschen diese Effizienz gegen maximale Aktualität ein. Dies ist besonders wertvoll für Signale, bei denen jedes neue Ereignis sofort den an das Modell übergebenen Wert beeinflussen soll.

So einfach lässt sich ein Rolling-Window-Feature mit der deklarativen API des Feature Stores definieren:

Spark Real-Time Mode: Die Engine für die Feature-Berechnung

Kommen wir zur zugrunde liegenden Infrastruktur: Die Streaming-Pipeline ist das, was aktuelle Features bei hohem Durchsatz erst möglich macht. Diese Pipeline leitet Daten von Kafka bis hin zum Online-Feature-Store weiter. Die Streaming-Pipeline basiert auf dem Spark Real-Time Mode (RTM), einem grundlegend neuen Ausführungsmodus für Spark Structured Streaming. RTM ist die entscheidende architektonische Innovation, die eine Aktualität im Millisekundenbereich ermöglicht.

Gleichzeitige Stages und zustandsbehaftete Verarbeitung

Im traditionellen Microbatch-Modus (MBM) verarbeitet Spark Streaming-Daten in diskreten Batches. Jeder Batch sammelt Ereignisse über ein konfigurierbares Intervall, verarbeitet sie nacheinander in den einzelnen Stages, setzt Checkpoints und startet dann den nächsten Batch. Dies setzt der Latenz eine Untergrenze: Selbst bei aggressivem Tuning arbeiten MBM-Pipelines für zustandsbehaftete Aggregationen typischerweise im Bereich von Sekunden bis Minuten. RTM hingegen führt Stages gleichzeitig aus. Aggregationsoperatoren verarbeiten Zeilen sofort, sobald sie verfügbar sind, ohne darauf zu warten, dass die vorgelagerte Stage die Verarbeitung aller Zeilen abgeschlossen hat.

Für Rolling-Aggregationen gibt es zwei wichtige Stages. Die erste Stage umfasst Datenverarbeitung, Schema-Validierung, Data Coalescing und Type Casting. Hier wird die Geschäftslogik ausgeführt, die generische Aktionsereignisse in das Format für Ihre Feature-Aggregation konvertiert. Die zweite Stage ist die Aggregation der Daten pro Entität, um die Rolling-Window-Aggregationen zu berechnen. Jede eingehende Zeile aktualisiert sofort das Aggregat in einem lokalen RocksDB-Zustandsspeicher (State Store) und gibt den neuen Wert an die nachfolgenden Stages weiter. Der Ablauf des Zeitfensters erfolgt ebenfalls pro Zeile: Wenn die Fensterdauer für ein bestimmtes Ereignis abläuft, entfernt die Pipeline den Beitrag dieses Ereignisses und gibt das korrigierte Aggregat an Lakebase aus. RocksDB läuft lokal auf jedem Executor, was Zustandsgrößen ermöglicht, die die Speicherkapazität des Clusters überschreiten.

Pipeline-Zustandsverwaltung im serverlosen RTM

Checkpointing ist für die Fehlertoleranz beim zustandsbehafteten Streaming unerlässlich, da es der Pipeline ermöglicht, sich vom Ausfall einzelner Pipeline-Worker zu erholen. Aber Checkpointing hat seinen Preis. Im Microbatch-Modus setzt Spark an jeder Batch-Grenze Checkpoints, und jeder Checkpoint erhöht die Latenz der Pipeline, da er mit Cloud-Objektspeichern interagiert.

RTM verfolgt einen anderen Ansatz: Die Kosten für Planung und Checkpointing werden über längere Intervalle amortisiert. Die Kosten für das Checkpointing werden auf alle in diesem Intervall verarbeiteten Zeilen verteilt, anstatt die Pipeline an jeder Batch-Grenze zu blockieren. Dies geht nicht zu Lasten der Fehlertoleranz. Exactly-Once-Verarbeitungsgarantien bleiben erhalten – bei einem Ausfall spielt die Pipeline maximal 5 Minuten an Daten aus der Kafka-Quelle erneut ab. Der Kompromiss ist ein geringfügiger Anstieg des Replay-Volumens für eine erhebliche Reduzierung der Latenz im stabilen Verarbeitungszustand.

Der Feature Store führt serverlose RTM-Pipelines auf Lakeflow Spark Delta Pipelines (SDP) aus, wodurch Cluster-Verwaltung und Kapazitätsplanung vollständig entfallen. Sie müssen keine Maschinen bereitstellen, keine Executor-Anzahl anpassen und sich nicht um die Cluster-Wartung kümmern. Wenn Infrastruktur-Updates einen Pipeline-Neustart erfordern, koordiniert SDP die Übergabe: Das neue serverlose Cluster wird bereitgestellt und ist vollständig bereit, bevor das alte gestoppt wird. Diese Koordination wird auf die 5-minütigen Checkpointing-Intervalle synchronisiert, was Ausfallzeiten minimiert und Lücken bei der Wiederverarbeitung vermeidet. Dies führt zu einer Unterbrechung der Feature-Aktualität von nahezu Null während der Wartungsfenster.

Lakebase: Minimierung des Overheads für Streaming-Schreibvorgänge

Der Databricks Feature Store nutzt Lakebase zur Speicherung der Online-Feature-Werte für die Inferenz. Die Lakebase-Architektur zur Trennung von Rechenleistung und Speicher ermöglicht Autoscaling, um variable Lasten bei der Modellinferenz zu bewältigen. Der Online Feature Store nutzt diese Fähigkeit, um auf Zehntausende von Lesevorgängen pro Sekunde mit Latenzen im zweistelligen Millisekundenbereich zu skalieren.

Streaming-Schreibvorgänge sind besonders anspruchsvoll, da sie aus einer großen Anzahl kleiner Upserts bestehen, wenn bei jeder empfangenen Kafka-Zeile neue Werte für gleitende Fenster ausgegeben werden. In Standard-Postgres kann dieses Muster ein großes Write-Ahead-Log-Volumen erzeugen, da Postgres Full-Page-Writes verwendet, um eine einfachere Wiederherstellung zu ermöglichen. Nach jedem Checkpoint schreibt die erste Änderung an einer Seite das vollständige 8-KB-Seiten-Image in das Write-Ahead-Log (WAL) und nicht nur die kleine logische Änderung. Bei häufig aktualisierten Entitätszeilen führt dies dazu, dass die WAL-Verstärkung zum Engpass für den Schreibdurchsatz, die Replikation und den Wiederherstellungs-Overhead wird.

Lakebase nutzt nun die Trennung von Rechenleistung und verteiltem Speicher, um die Streaming-Schreibverstärkung im Vergleich zu Standard-Postgres zu minimieren. Die Lakebase-Architektur ermöglicht es Postgres, kleine, kompakte Änderungsdatensätze zu schreiben, anstatt wiederholt vollständige 8-KB-Seitensnapshots in das WAL zu schreiben. Die Dauerhaftigkeit ist weiterhin geschützt, da diese kompakten Datensätze von einem Quorum verteilter Safekeeper-Knoten bestätigt werden. Vollständige Seitensnapshots werden nach einer ausreichenden Anzahl von Änderungsdatensätzen immer noch für die Wiederherstellung benötigt, diese werden jedoch später in der Speicherebene generiert, anstatt den Schreibpfad aufzublähen. Für den Feature Store bedeutet dies, dass RTM kontinuierlich frische Feature-Werte in Lakebase mit weitaus weniger WAL-Verstärkung und minimaler zusätzlicher Latenz veröffentlichen kann.

Model Serving: Feature-Abruf mit geringer Latenz im großen Maßstab

Der letzte Schritt besteht darin, frische Features aus Lakebase abzurufen und sie dem Modell zum Inferenzzeitpunkt bereitzustellen. Dies wird von Databricks Model Serving übernommen, einer vollständig verwalteten Serving-Infrastruktur, die für Workloads mit hohen QPS und geringer Latenz optimiert ist.

Model Serving ist für die Durchsatzanforderungen von Echtzeit-ML ausgelegt:

• Vollständig horizontal skalierbare Architektur: Der Inferenzserver, die Authentifizierungsebene, der Proxy und der Rate Limiter skalieren alle unabhängig voneinander und unterstützen über 100.000 QPS auf CPU-Endpunkten
• Schnelle elastische Skalierung: Das System passt sich an Datenverkehrsspitzen und -abfälle ohne Überbereitstellung an, sodass die Kosten an den tatsächlichen Bedarf angepasst bleiben
• Modelle verwalten und überwachen: Verwalten Sie den Netzwerkzugriff, verwalten Sie Berechtigungen für Modellendpunkte und überwachen Sie die Qualität mithilfe des AI Gateway.

Für den Feature Store ist die Integration nahtlos. Wenn ein Modell mit MLflow protokolliert wird, werden seine Feature-Abhängigkeiten aufgezeichnet. Zum Inferenzzeitpunkt sucht Model Serving automatisch die erforderlichen Features in Lakebase – kein benutzerdefinierter Lookup-Code, keine manuelle Integration erforderlich. Das von RTM berechnete und in Lakebase gespeicherte frische Aggregat wird abgerufen und transparent mit der Inferenzanfrage zusammengeführt.

Feature Store über Streaming hinaus

Leistungsstarke Echtzeitfunktionen sind nur ein Teil dessen, was ein Feature Store lösen kann. Zwei weitere Herausforderungen verdienen eine kurze Betrachtung:

Trainingsdaten für Stream-Features

Die Generierung von Trainingsdaten kann für Streaming-Features schwierig sein, da die kurzen Aufbewahrungsfenster für die Streams die Pflege eines separaten Offline-Stores erfordern. Der Databricks Feature Store löst dies, indem er eine Offline-Kopie der aufgenommenen Kafka-Daten speichert. Für das Modelltraining berechnet der Feature Store dieselben Feature-Werte wie Streaming-Pipelines für historische Werte und führt zeitpunktgenaue Joins durch. Dieselbe Funktion wird verwendet, um Online-Streaming-Features nachträglich zu befüllen (Backfill), um eine schnelle Bereitstellung in der Produktion zu ermöglichen.

Integrationen

Wie oben gezeigt, orchestrieren Feature Stores mehrere komplexe Infrastrukturkomponenten. Diese Fragmentierung kann Governance, Lineage und die Feature-Wiederverwendung erschweren. Sie verlangsamt auch die Entwicklung, da Ingenieure Änderungen über Systemgrenzen hinweg koordinieren müssen.

In Databricks sind Features First-Class-Objekte in Unity Catalog – auffindbar, durch Zugriffskontrollen geregelt und mit vollständiger Lineage nachverfolgt. Feature-Transformationen werden mit dem Modell gepackt, MLflow erfasst, welche Features verwendet wurden, und die Deployment-Lineage verbindet Modelle mit ihren Feature-Abhängigkeiten. Die Plattform ist eine zentrale Anlaufstelle für die Entwicklung, Bereitstellung und Governance Ihres gesamten ML-Stacks.

Der Feature Store von Databricks orchestriert wichtige Bausteine wie Spark RTM, Lakebase und Model Serving, sodass Sie erstklassige Latenzzeiten und Skalierbarkeit erhalten, ohne die Infrastruktur selbst verwalten zu müssen. Jedes dieser Systeme wurde speziell für Streaming-Workloads optimiert, um eine Aktualität von 200 ms für Machine-Learning-Features zur Realität werden zu lassen.

Bitte werfen Sie einen Blick auf die Dokumentation zu Streaming-Pipelines, um zu erfahren, wie Sie Streaming-Features definieren. Experimentieren Sie mit vorhandenen Features, um zu sehen, wie viel stärkere Signale sie mit einer Aktualität im Millisekundenbereich liefern würden.

Wenn Sie die zugrunde liegende Technologie besser verstehen möchten, lesen Sie den Lakebase-Blog über schnellere Schreibvorgänge und die Analyse der RTM-Architektur.

Wenn Sie an solchen Problemen arbeiten möchten, wir stellen ein!

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag