Zum Inhalt springen
Von Batch-POS zu Near Real Time: Ingestion-Framework auf Databricks

Von Batch-POS zu Near Real Time: Ingestion-Framework auf Databricks

Wie ein SaaS-Anbieter Kassendaten aus 3.000+ Restaurants mit Databricks in Near Real Time verarbeitet und die Grundlage für Analytics, ML und Agentic AI schafft.

Lesedauer5 Min.
VeröffentlichtJuli 2026

Die wichtigsten Ergebnisse

  • Kassendaten in unter 1 Minute

    POS-Events stehen für Reporting und ML bereit, statt über Nacht per Batch einzutreffen.

  • ~60 % geringere Ingestion-Kosten

    Das wiederverwendbare Framework ersetzt Pipeline-Bau pro Mandant durch Konfiguration.

  • Onboarding in Minuten statt Tagen

    Neue Restaurants werden über das bestehende Konfigurationsmuster aufgenommen.

  • 3.000+ Quellen, eine Plattform

    POS-Streaming und ERP-Ingestion laufen in eine zentrale Lakehouse-Architektur auf Databricks.

Zusammenfassung

Der Kunde ist ein deutscher SaaS-Anbieter mit einer branchenspezifischen ERP-Lösung für Restaurants und Food-Retail. Über 3.000 aktive Restaurant-Mandanten arbeiten täglich auf der Plattform, jeder mit einer eigenen MariaDB-Instanz. Dazu kommen Kassendaten aus angebundenen POS-Systemen: Bestellungen, Umsätze, Tischbelegungen, Storno-Vorgänge. Die operative Nutzung liegt beim Restaurantbetrieb, die konsolidierte Sicht beim Anbieter.

Analytics, Forecasting und mandantenübergreifende Auswertungen sind erklärter Bestandteil der Produktstrategie. Ein SaaS-Anbieter, der seinen Kunden mehr als eine ERP-Oberfläche liefern will, braucht eine belastbare Datenbasis über alle Instanzen hinweg. Die Ingestion-Schicht war der Engpass. Und wurde als Erstes gelöst.

Übersicht

Kunde
SaaS-Anbieter für Gastronomie
Anonymisierte Referenz
Branche
B2B-SaaS

Verwendete Technologien & Systeme

Terraform
Terraform
Azure Cloud
Azure Cloud
Databricks Unity Catalog
Databricks Unity Catalog
SQL Warehouse
SQL Warehouse
Databricks Delta Lake
Databricks Delta Lake
Die Transformation

Von Batch-only zu Near-Real-Time-Ingestion.

01Ausgangssituation

Wenn 3.000 Quellen jede für sich arbeiten.

Vor dem Projekt gab es kein gemeinsames Ingestion- und Konsolidierungsmuster. Jeder der über 3.000 Mandanten lief auf einer eigenen MariaDB-Instanz, POS-Daten wurden über Nacht per Batch eingesammelt. Innerhalb der einzelnen Mandanteninstanz funktionierte das. Über das gesamte Netzwerk hinweg entstand jedoch keine gemeinsame Datenbasis.

Damit fehlte eine Single Source of Truth für mandantenübergreifende Auswertungen. Einzelne Restaurants, Ketten und Franchise-Strukturen ließen sich nicht auf einer konsolidierten Ebene analysieren, ohne Sonderlogik oder manuelle Zusammenführung. Aggregierte Sichten über Mandanten hinweg waren im bestehenden Aufbau nicht sauber vorgesehen und governance-seitig schwer abzusichern.

Gleichzeitig blieb die operative Last nah am ERP. Auswertungen, Exporte und Datenaufbereitung liefen auf Systemen, die primär für Transaktionen gebaut waren. Mit jedem neuen Mandanten, jeder zusätzlichen Auswertung und jeder weiteren Integration wuchs der Aufwand im operativen Kernsystem, statt in eine skalierbare Datenplattform ausgelagert zu werden.

Für ML- und AI-Use-Cases fehlte dadurch die Grundlage. Ohne konsolidierte Datenbasis, ohne einheitliches Layer-Modell und ohne saubere Mandantentrennung lassen sich Forecasting, Empfehlungen, dynamische Preise oder Agentic-AI-Funktionen nicht belastbar produktisieren. Die zentrale Frage lautete deshalb: Wie wird aus vielen isolierten Mandantenquellen ein gemeinsames Datenfundament, das operativ entlastet, mandantenübergreifende Auswertungen ermöglicht und neue datengetriebene Funktionen trägt?

Eine Multi-Tenant-SaaS-Plattform braucht nicht 3.000 einzelne Dateninseln, sondern ein gemeinsames Fundament für Konsolidierung, Governance und datengetriebene Produktfunktionen.
SaaS-Anbieter für Gastronomie: Kapitel 01
02Herausforderung

Batch-Warehouse oder streaming-fähiges Lakehouse?

Ein klassisches Data Warehouse mit nächtlichem Batch-Load wäre der vertraute Weg gewesen. Für den angestrebten Plattformausbau hätte dieser Ansatz jedoch nicht gereicht: POS-Daten sollten nicht erst am nächsten Morgen in Auswertungen erscheinen, sondern zeitnah für Steuerung, Analytics und datengetriebene Funktionen nutzbar sein.

Gemeinsam mit ruhrdot bewertete der Kunde die verfügbaren Plattformen anhand konkreter Anforderungen: heterogene Quellen wie MariaDB, POS-Events und spätere API-Daten in einer Umgebung integrieren, kontinuierliche Datenströme verarbeiten, Mandanten von Beginn an sauber trennen und Analytics sowie ML auf demselben Fundament ermöglichen.

Databricks überzeugte, weil Ingestion, Streaming, Lakehouse, Governance und ML in einer Plattform zusammenkommen. Der Ingest der Kassendaten läuft über Zerobus direkt in die Plattform. Lakeflow Declarative Pipelines übernehmen die kontinuierliche Verarbeitung, Auto Loader deckt die skalierbare ERP-Ingestion ab, Unity Catalog sorgt für Governance und Mandantentrennung, Delta Lake bildet das offene Storage-Fundament.

Damit entfiel ein separates Doppelmodell aus Data Warehouse für Reporting und Data Lake für weitere Datenprodukte. Die Plattform folgt stattdessen einem gemeinsamen Betriebsmodell für Ingestion, Analytics, ML und spätere SaaS-Funktionen.

Die Entscheidung fiel nicht nur für eine Technologie, sondern gegen zwei parallele Datenwelten: eine für operative Datenströme und eine zweite für Analytik.
SaaS-Anbieter für Gastronomie: Kapitel 02
03Strategie

Metadaten als Steuerungsprinzip.

Bevor die erste Pipeline entstand, klärte der Kunde mit ruhrdot das Betriebsmodell: Wer trägt Verantwortung für die Ingestion-Schicht, welche Rollen entstehen, wie werden neue Mandanten technisch aufgenommen, wer pflegt die Metadaten. Der Grundsatz war klar: Kein Mandant bekommt eine eigene Pipeline. Alles läuft über ein metadaten-gesteuertes Framework, in dem die Quelle konfiguriert und nicht codiert wird. Damit verlagert sich der Aufwand aus der Entwicklung in die Konfiguration und wird planbar.

Für die POS-Seite war zunächst Azure Event Hubs als Streaming-Backbone vorgesehen. Im Betrieb erwies sich das als zu teuer und zu unflexibel für die anfallenden Mengen und den mandantenweisen Schnitt. Die Entscheidung fiel deshalb auf Zerobus: Die Kassensysteme schreiben ihre Ereignisse direkt in Databricks, ohne den Umweg über einen separaten Message-Broker. Zerobus ist nativ in der Plattform vorhanden, deutlich günstiger und fügt sich ohne zusätzliche Infrastruktur in den Delta-Landing-Pfad ein; Lakeflow Declarative Pipelines verarbeiten die Events von dort weiter. Für die ERP-Seite fiel die Entscheidung auf Auto Loader mit einem Metadaten-Layer, der die 3.000+ MariaDB-Quellen kontinuierlich in die Landing-Schicht überführt. Beide Pfade nutzen dieselbe Delta-Landing als Zielformat, damit die Konsolidierungs- und Business-Layer darauf einheitlich aufsetzen können.

Governance lief von Anfang an mit. Unity Catalog übernahm die Mandantentrennung ab der Landing-Schicht, damit kein Restaurant Daten eines anderen sieht und mandantenübergreifende Views nur dort möglich werden, wo sie autorisiert sind.

Leitprinzip: Die Plattform skaliert über Konfiguration, nicht über Individualarbeit.
SaaS-Anbieter für Gastronomie: Kapitel 03
04Lösung

Streaming plus Metadaten-Ingestion in einem Framework.

In der Umsetzung entstand ein Ingestion-Framework auf Databricks, das beide Welten trägt. Die Kassensysteme schreiben ihre POS-Events über Zerobus direkt in das Data Lakehouse; Lakeflow Declarative Pipelines verarbeiten sie in Near Real Time und stellen sie innerhalb einer Minute für operative und analytische Nutzung bereit. Fehlertoleranz, Checkpointing und Wiederanlauf sind Teil der Streaming-Pipeline, damit Ausfälle in einer Restaurant-Verbindung nicht die Gesamtverarbeitung anhalten.

MariaDB-Quellen laufen über Auto Loader in die Landing-Schicht, gesteuert durch einen Metadaten-Layer, der Quelle, Mandant, Ladefrequenz und Zielort definiert. Änderungen am Schema einer Instanz werden erkannt und in die Landing-Schicht propagiert, ohne dass die Pipeline manuell nachgezogen werden muss.

Neue Mandanten werden über das Metadaten-Framework aufgenommen. Ein Eintrag in der Konfiguration, keine neue Pipeline. Die Landing-Schicht ist Delta-Lake-basiert, damit die weiteren Layer und die Analytics-Workloads direkt darauf aufsetzen können. Der Aufwand pro zusätzlichem Restaurant sinkt auf einen Konfigurationsschritt.

Unity Catalog setzt die Mandantentrennung durch. Zugriffsrechte, Lineage und Audit-Spuren sind fester Bestandteil der Ingestion-Architektur.

3.000 isolierte Batch-Quellen wurden zu einem kontinuierlichen, governance-geführten Datenfluss.
SaaS-Anbieter für Gastronomie: Kapitel 04
3.000+Angebundene Quellsysteme
< 1 MinDaten für Reporting und ML verfügbar
~60 %Geringere Ingestion-Kosten
Minuten statt TageMandanten-Onboarding

Zielarchitektur

Streaming plus Batch-Ingestion in einem Framework.

POS-Ingestion über Zerobus und ERP-Ingestion aus 3.000+ MariaDB-Instanzen laufen in eine zentrale Lakehouse-Architektur auf Databricks. Delta-Lake-Landing, Lakeflow Declarative Pipelines und Auto Loader, governance-geführt über Unity Catalog. Quellsysteme Databricks Data Intelligence Platform (Managed · Azure · Unity Catalog) Workloads Deployment & Betrieb: Pipelines · CI/CD · Enablement Terraform · Lakeflow Jobs · Metadaten-Framework · Runbooks.

Bausteine

  • MariaDB-ERP-Instanzen: 3.000+ Mandanten
  • POS-Streaming-Services: Kassenereignisse aus den Restaurants
  • Metadaten-Layer: Konfiguration je Quelle und Mandant
  • Erweiterungspfad: weitere APIs und Fachsysteme
  • Governance: Unity Catalog · Mandantentrennung · Lineage · Audit
  • Ingestion: Zerobus (POS, Direct-Write in Delta) und Auto Loader (ERP) in die Landing-Schicht
  • Foundation: Delta Lake · Zerobus · Lakeflow Declarative Pipelines · Auto Loader · Azure
  • POS-Streaming: operative Auswertung in Near Real Time
Platform Outcomes

Was sich durch die Ingestion-Plattform verändert hat

POS-Daten ohne nächtliches Batch-Fenster

Kassenereignisse werden über Zerobus direkt in Databricks geschrieben und mit Lakeflow Declarative Pipelines kontinuierlich verarbeitet. Die operative Sicht auf das Restaurantnetzwerk entsteht damit nicht erst am Folgetag, sondern zeitnah auf denselben Datenpfaden, die auch Analytics und ML nutzen.

Wiederverwendbare Ingestion für über 3.000 MariaDB-Quellen

ERP-Daten aus den Mandanteninstanzen laufen über ein metadaten-gesteuertes Ingestion-Muster in die Landing-Schicht. Quelle, Mandant und Zielort werden konfiguriert, statt pro Mandant eine eigene Pipeline zu bauen. Schema-Änderungen werden erkannt und dokumentiert, damit sich die Plattform kontrolliert weiterentwickeln kann.

Schnelleres Onboarding neuer Mandanten

Neue Restaurants werden über das bestehende Konfigurationsmuster aufgenommen. Der Aufbau einer eigenen Pipeline entfällt. Dadurch wird Mandanten-Onboarding reproduzierbarer und weniger abhängig von manueller Integrationsarbeit.

Mandantensichere Konsolidierung über Unity Catalog

Unity Catalog regelt Zugriffe, Ownership und Lineage zentral. Einzelne Mandanten sehen nur ihre eigenen Daten, während autorisierte, aggregierte Sichten über Mandanten hinweg kontrolliert bereitgestellt werden können.

Gemeinsame Basis für Analytics, Forecasting und ML

Streaming- und ERP-Daten landen auf derselben Delta-Lake-Basis und werden in nachgelagerten Layern bereinigt, konsolidiert und für Analytics nutzbar gemacht. Dashboards, Forecasting-Modelle und spätere ML-Use-Cases bauen damit auf einer gemeinsamen Datenbasis auf, statt eigene Datenpfade zu benötigen.

Vorher / Nachher

Was sich konkret verändert hat

Vorher

Nachher

POS-Daten

Kassendaten wurden im Batch verarbeitet und standen erst am Folgetag bereit
POS-Events fließen über Zerobus und Lakeflow Declarative Pipelines in Near Real Time in die Plattform

ERP-Integration

Jede MariaDB-Instanz erforderte eigene Integrationsarbeit
Ein metadaten-gesteuertes Auto Loader Framework übernimmt ERP-Daten aus über 3.000 Quellen

Mandanten-Onboarding

Neue Restaurants bedeuteten manuelle Konfiguration und eigene Pipeline-Arbeit
Neue Mandanten werden über Konfiguration in das bestehende Ingestion-Muster aufgenommen

Mandantentrennung

Daten lagen isoliert je Instanz, ohne kontrollierte mandantenübergreifende Sicht
Unity Catalog ermöglicht mandantensichere Trennung und autorisierte aggregierte Sichten

Analytics-Basis

Daten lagen verteilt in Quellsystemen, ohne gemeinsame Landing-Schicht
Delta-Lake-Landing schafft die Grundlage für Reporting, Forecasting, Analytics und ML

Nächste Schritte

Von der Ingestion-Basis zu Analytics, ML und Agentic AI

Das Ingestion-Framework schafft die Grundlage für die nächsten Ausbaustufen: konsolidierte Business-Layer, produktive ML-Use-Cases und datengetriebene Funktionen für Mandanten und Plattformbetreiber.

1

Konsolidierungs- und Business-Layer ausbauen

Auf der Landing-Schicht entstehen die weiteren Layer für bereinigte, harmonisierte und konsumierbare Datenprodukte. KPI-Definitionen werden gemeinsam mit den Fachbereichen festgelegt, damit Reporting, Forecasting und mandantenübergreifende Auswertungen auf verbindlichen Kennzahlen aufsetzen.

2

ML-Use-Cases auf der Streaming- und ERP-Basis produktisieren

POS-Streaming und ERP-Konsolidierung liefern die Grundlage für Prognosemodelle zu Auslastung, Umsatzentwicklung und Warenbedarf. Sobald Business-Layer und Feature-Aufbereitung stabil sind, können Modelle reproduzierbar über Lakeflow Jobs betrieben und für weitere ML-Use-Cases erweitert werden.

3

Agentic AI und Analytics-Angebote für Mandanten vorbereiten

Auf der konsolidierten Datenbasis entstehen neue Möglichkeiten für eingebettete Analytics- und Agentic-AI-Funktionen: operative Hinweise zur Nachfrage, Vorschläge für Sortimente und Aktionen, Cross-Selling-Potenziale oder dynamische Empfehlungen je Standort, Tageszeit und Mandantengruppe. Unity Catalog sorgt dafür, dass solche Angebote mandantensicher bereitgestellt werden können, ohne die Datenschicht neu aufzubauen.

Steht eure Datenplattform vor einer ähnlichen Ingestion-Frage?

Wenn Daten aus vielen Quellen, Mandanten oder Systemen zusammengeführt werden müssen, reicht ein einzelner Batch-Job oft nicht mehr aus. Häufig fehlt dann ein gemeinsames Fundament für Ingestion, Konsolidierung, Governance und spätere Analytics-, ML- oder AI-Use-Cases. Wir prüfen mit euch, welche Quellen sich zuerst für eine moderne Ingestion-Strecke eignen, wie ein skalierbares Framework für eure Datenlandschaft aussehen kann und welcher erste produktive Meilenstein realistisch erreichbar ist.

Alexander Rabe
Alexander Rabe
Co-Founder · Head of Data & AI

FAQ

Häufig gestellte Fragen