Wie Uber seine ML-Datenlieferkette aufgebaut hat: Lehren aus dem Feature Store Michelangelo

2017 hatten Ubers Machine-Learning-Ambitionen die eigene Dateninfrastruktur überholt. Das Unternehmen betrieb Modelle für Surge PricingSurge PricingAutomatically adjusting prices in real time based on demand, competition or user behaviour to optimise revenue, margin or conversion.Vollständige Definition ansehen →, ETA-Prognosen, Betrugserkennung und Driver Churn, jedes von einem anderen Team gebaut, jedes mit Daten aus sich überschneidenden Quellen, und jedes berechnete seine Features eigenständig. Nach den von Uber Engineering selbst veröffentlichten Berichten wurden schätzungsweise 40 bis 50 Prozent der Feature-Engineering-Arbeit teamübergreifend doppelt gemacht. Gravierender noch: Ein Feature, das beim Training auf eine bestimmte Weise berechnet wurde, wurde zur Inferenzzeit manchmal anders berechnet, was in der Branche Training-Serving-Skew heißt. Modelle, die in der Offline-Evaluierung solide aussahen, lieferten in der Produktion schlechtere Ergebnisse, und die Ursache dieser Lücke zu finden war teuer und langsam.

Die Organisation war außerdem so schnell gewachsen, dass das institutionelle Wissen darüber, welche Features gut funktionieren, verstreut war. Ein Team, das bei Uber Eats an Empfehlungen für Essenslieferungen arbeitete, hatte keine verlässliche Möglichkeit herauszufinden, dass das Fraud-Team bereits starke zeitliche Features zu Nutzer-Session-Mustern entwickelt hatte, die übertragbar gewesen wären. Die Datenlieferkette war in der Praxis eine Sammlung unverbundener lokaler Pipelines und kein gemeinsames Asset.

Was Uber tatsächlich gebaut hat

Die Antwort war Michelangelo, eine Ende-zu-Ende-ML-Plattform, die Uber Engineering 2017 in einem Blogbeitrag öffentlich dokumentierte. Die Feature-Store-Komponente stand im Zentrum. Die zentrale Engineering-Entscheidung war, die Feature-Berechnung vollständig von Modelltraining und Serving zu trennen und Features als vollwertige, versionierte, teilbare Artefakte zu behandeln statt als Code innerhalb einzelner Modell-Pipelines.

Konkret bedeutete das zwei Speicherschichten. Eine Batch-Schicht nutzte Hive und Spark, um Features in großem MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßstab zu berechnen und in einem Cassandra-basierten Offline Store zu persistieren. Eine Online-Schicht lieferte dieselben vorberechneten Features bei niedriger Latenz (für Ubers Anwendungsfall typischerweise unter 10 Millisekunden) über Cassandra-Lookups während der Echtzeit-Inferenz. Dieselbe Feature-Definition steuerte beide Pfade, und genau das beseitigte den Training-Serving-Skew: Es gab eine kanonische Berechnung, ausgeführt zu unterschiedlichen Zeitpunkten und auf unterschiedlichen Datenvolumen, die aber strukturell identische Werte lieferte.

Teams trugen Features zu einem gemeinsamen Katalog bei, mit Dokumentation und Metadaten zur Ownership. Bevor sie etwas Neues bauten, sollten Engineers zuerst in den Katalog schauen. Das klingt einfach, setzte aber sowohl Tooling als auch organisatorische Anreize voraus, damit es funktioniert. Uber führte eine Feature-Discovery-Oberfläche ein, damit die Suche im Katalog schneller war als der Neubau von Null.

Die Plattform übernahm außerdem automatisch Point-in-Time-korrekte Joins. Besonders bei Fraud- und Churn-Modellen führt die Verwendung eines Feature-Werts, der zum Zeitpunkt der Erzeugung des Trainingslabels noch nicht verfügbar war, zu Data Leakage. Der Offline Store von Michelangelo verfolgte Feature-Werte mit Zeitstempeln, und Trainings-Pipelines konnten den Zustand der Features einer Entität zu einem bestimmten historischen Moment abrufen. Diese Fähigkeit ist technisch einfach zu beschreiben und in großem Maßstab wirklich schwer zuverlässig umzusetzen.

Die Ergebnisse, vorsichtig formuliert

Ubers Engineering-Blog (eine Anbieterquelle in dem Sinne, dass es Ubers eigene Darstellung ist, lesenswert mit kritischem Blick, aber ohne erkennbaren Anreiz, operative Details zu erfinden) berichtete, dass Michelangelo 2018 über 100 Teams und tausende Features im Katalog unterstützte. Modell-Deployment-Zyklen, die vorher Wochen gedauert hatten, verkürzten sich deutlich, auch wenn Uber für diese Metrik keine präzise Vorher-Nachher-Zahl veröffentlichte.

Das konkretere Ergebnis war architektonisch: Teams, die vorher zwei bis vier Wochen für den Aufbau einer Feature-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → gebraucht hätten, konnten stattdessen auf bestehenden Katalogeinträgen aufbauen und eine erste Modellversion in Tagen ausliefern. Das Problem der Doppelarbeit verschwand nicht vollständig, aber der Overhead verschob sich von der Berechnung zur Governance, und das ist das bessere Problem.

Der Training-Serving-Skew ging messbar zurück, auch hier ohne veröffentlichte Zahl zu den Degradationsraten von Produktionsmodellen. Öffentlich sagte die Organisation aber, dass das Debugging des Verhaltens von Produktionsmodellen deutlich schneller wurde, weil die Feature-Schicht nicht mehr als Verdächtige in Frage kam: Die Berechnung war deterministisch und prüfbar.

Das Muster erwies sich als einflussreich. LinkedIn, Twitter und später Google (mit Feast, einem Open-Source-Feature-Store, der aus Gojek hervorging und heute ein CNCF-Projekt ist) bauten alle auf ähnlichen Prinzipien auf. Tecton, Hopsworks und Databricks Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → kommerzialisieren jeweils Varianten dieser Architektur, und ihre Marketingmaterialien verweisen häufig auf Ubers Veröffentlichungen als konzeptionellen Ursprung. Das sind Anbieterquellen und entsprechend zu lesen, aber die architektonische Konvergenz über unabhängige Implementierungen hinweg ist selbst ein Hinweis darauf, dass Ubers Ansatz ein echtes strukturelles Problem gelöst hat.

Was übertragbar ist und was nicht

Die zentrale Lehre ist organisatorisch, bevor sie technisch ist. Ubers Feature Store lieferte nur Wert, weil das Unternehmen die Norm durchsetzte, dass Engineers vor dem Bauen in den Katalog schauen. Ohne diese Norm wird ein Feature Store zu einem Archiv, das niemand pflegt. Ein CDO, der dieses Muster umsetzt, muss festlegen, wer Feature-Definitionen ownt, wie der Review-Prozess aussieht, bevor ein Feature in den Katalog kommt, und wie veraltete oder deprecated Features stillgelegt werden. Das Tooling ist sekundär.

Point-in-Time-korrekte Joins zählen am meisten in Bereichen, in denen Labels retrospektiv entstehen: Kreditrisiko, Churn-Prognose, Fraud. Wenn Ihr Hauptanwendungsfall Echtzeit-Empfehlungen mit nahezu unmittelbaren Feedback-Loops ist, ist das weniger wichtig, und die Implementierungskomplexität lohnt sich möglicherweise nicht.

Ubers Situation umfasste außerdem eine große, gut ausgestattete Engineering-Organisation. Ein Team aus 10 Data Scientists braucht kein Cassandra und kein Spark. Mehrere Open-Source-Optionen, darunter Feast und die Hopsworks Community Edition, erlauben kleineren Organisationen, die Prinzipien von Katalog und Lineage mit leichterer Infrastruktur umzusetzen. Das Prinzip skaliert nach unten, die ursprüngliche Implementierung nicht.

Was in Diskussionen über Feature Stores oft untergeht, ist Monitoring. Features driften über die Zeit, weil sich vorgelagerte Datenverteilungen verschieben. Ein Feature Store ohne Monitoring der statistischen Eigenschaften der Features, die in die Produktion gehen, ist eine unvollständige Datenlieferkette. Uber baute Monitoring in Michelangelo ein; viele Organisationen führen einen Feature Store ein und behandeln Monitoring als späteres Problem, was es selten ist.

Der Feature Store ist nicht primär ein Weg, ML schneller zu machen, auch wenn ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → das oft tut. Er ist ein Weg, ML prüfbar, wiederverwendbar und konsistent über die Lücke zwischen Training und Serving hinweg zu machen. Diese Eigenschaften zählen am meisten, wenn Modelle in regulierten Bereichen laufen oder Produktionsfehler teuer sind. Beginnen Sie mit dem Katalog und der Governance-Struktur und lassen Sie die Infrastruktur der tatsächlichen Größe Ihres Anwendungsfalls folgen.