Revenue Forecasting auf Databricks: 3.000+ Restaurants stundengenau prognostizieren

Die Plattformentscheidung fiel anhand konkreter Anforderungen: mandantenspezifische Modelle für 3.000+ Restaurants, ein governance-geführter Modell-Lifecycle, eine gemeinsame Feature-Basis für alle Modelle und ein Betriebsmodell, das dauerhaft weiterentwickelt werden kann. Databricks bringt Lakehouse, MLflow, Mosaic AI und Unity Catalog auf einer Plattform zusammen. Damit entfällt der Flickenteppich aus verteilten Einzelansätzen, separatem Registry und improvisiertem Deployment.

Jeder Standort bringt eigenes Umsatzverhalten, eigene Öffnungszeiten, eigene Speisekarten und lokale Nachfrageverläufe mit. Ein global aggregiertes Modell hätte diese Unterschiede geglättet und für den einzelnen Standort ungenaue Prognosen geliefert. Deshalb läuft für jeden der 3.000+ Mandanten ein eigenes Modell. Die Feature-Aufbereitung ist dabei standardisiert, die Prognose bleibt mandantenspezifisch. So skaliert Forecasting über den gesamten Bestand, ohne lokale Muster zu verlieren.

Die Modelle nutzen historische ERP-Daten (Mandanten-Stammdaten, Umsatzhistorie) und POS-Daten (Kassendaten, Absatzmengen, Warenkorbstruktur) aus dem bestehenden Curated- und Core-Layer der Lakehouse-Plattform. Betriebsdaten wie Öffnungszeiten, Sortimente und Kalender fließen als Kontext ein. Externe Signale wie Feiertage und Wetter sind für die nächste Ausbaustufe vorgesehen.

Zum Einsatz kommen gängige Time-Series-Forecasting-Verfahren, von klassischen Zeitreihenmodellen bis zu Gradient-Boosting-Ansätzen wie XGBoost. Bewusst keine Exotik. Welches Verfahren pro Mandant produktiv geht, entscheidet die gemessene Prognosequalität im Trainingslauf, nicht eine Vorfestlegung am Anfang. Training, Bewertung und Versionierung laufen über MLflow und Mosaic AI.

Ein kompletter Forecast-Lauf über alle 3.000+ Standorte läuft in unter fünf Minuten durch. Die Prognosen stehen damit nahezu in Echtzeit bereit, nicht als Batch über Nacht. Die stündliche Auflösung bildet Tagesverläufe wie Mittags- und Abendgeschäft ab, die für Personal- und Einkaufsplanung entscheidend sind. Der Horizont von 14 Tagen ist lang genug für Bestellungen und Schichtplanung und kurz genug, um verlässlich zu bleiben.

Nein. Das Prinzip lohnt sich, sobald mehr als ein Modell produktiv laufen soll oder ein einzelner Ansatz reproduzierbar in den Betrieb kommen muss. Für ein kleines Team ist der Vorteil sogar größer, weil die Plattform die Aufgaben übernimmt, die sonst manuell nebenherlaufen: Registry, Deployment, Monitoring.

MLflow ist eine Open-Source-Plattform für den Modell-Lifecycle: Experiment Tracking, Model Registry und Deployment. Wichtig ist MLflow, weil es aus einem einzelnen Trainingslauf ein versioniertes, nachvollziehbares und produktionstaugliches Modell macht. Ohne diese Struktur bleiben einzelne Ansätze schwer reproduzierbar. Mit ihr wird der Weg vom Training zur Produktion zum Standardpfad.

Mosaic AI ist die KI- und ML-Schicht der Databricks-Plattform. Sie deckt Training, Experiment-Tracking, Model Registry und Serving ab und arbeitet dabei mit MLflow und Unity Catalog zusammen. Im Forecast-Betrieb sorgt das dafür, dass Modelle für alle Mandanten über denselben, governance-geführten Weg trainiert, versioniert und bereitgestellt werden.

Unity Catalog ist das Governance-Rückgrat der Databricks-Plattform. Er regelt Ownership, Zugriffe und Lineage für Daten und Modelle über alle Workspaces und Workloads hinweg. Für einen Multi-Tenant-Betrieb bedeutet das: Wer welche Mandantendaten sieht, welches Modell auf welchen Features basiert und welche Prognose zu welchem Mandanten gehört, ist zentral konfiguriert und auditierbar.

Die Medallion-Architektur gliedert Daten in drei Schichten: Bronze für Rohdaten, Silver für bereinigte und angereicherte Daten und Gold für business-nahe, konsumierbare Datensätze. Dieses Modell sorgt für Nachvollziehbarkeit, Datenqualität und klare Verantwortlichkeiten. Auf dieser Foundation setzen die Feature-Layer für die Prognosemodelle auf.

Für SaaS-Anbieter mit vielen Mandanten, für Filialstrukturen mit standortspezifischer Nachfrage, für Handel und Gastronomie mit hoher Sortimentsvielfalt und generell für alle, die Prognosen im Bestand produktiv ausrollen wollen, statt sie pro Standort neu zu bauen. Die Plattformlogik ist übertragbar, die Modelle sind fachspezifisch.

Ein Feature Store ist eine zentrale Ablage für Features, die von ML-Modellen genutzt werden. Er sorgt dafür, dass dieselbe Feature-Definition für Training und Inferenz benutzt wird, und macht Features zwischen Experimenten wiederverwendbar. Im hier beschriebenen Aufbau übernimmt die Curated- und Core-Layer-Struktur diese Rolle innerhalb des Lakehouse.