Warum ein Greenfield-Lakehouse und keine punktuelle Anbindung an vorhandene Tools?

Die Ausgangslage war eine produktive MongoDB als operativer Katalog, ohne eigene Analytics- oder ML-Umgebung. Ein Greenfield-Aufbau war die kürzere Strecke: eine Plattform, ein Governance-Modell, ein Betriebsmodell. Databricks bringt Lakehouse-Architektur, Unity Catalog und Lakeflow Jobs in einer Umgebung zusammen und trägt Ingestion, Transformation und den ML-Pfad auf derselben Grundlage.

Was ist die Medallion-Architektur?

Die Medallion-Architektur gliedert Daten in mehrere Schichten. Im Projekt entspricht das Raw für Rohdaten aus der MongoDB, Curated für bereinigte und harmonisierte Datenstände, Datamart für fachlich modellierte Sichten und Analytics für die konsumfertige, föderierte Tabelle. Dieses Modell sorgt für Nachvollziehbarkeit, Datenqualität und klare Verantwortlichkeiten. Jede Schicht hat einen definierten Zweck, klare Ownership und ein eigenes Qualitätsniveau, was den Betrieb entlang der Pipeline vereinfacht.

Was ist Unity Catalog?

Unity Catalog ist die Governance-Ebene der Databricks-Plattform. Er bündelt Metadaten, Zugriffsrechte, Lineage und Auditing über alle Datenobjekte im Lakehouse. Im Projekt regelt Unity Catalog, wer welche Katalog-Sicht sehen darf, wie Daten zwischen den Layern fließen und welche Objekte im Federated-Export landen. Damit hat das Team eine zentrale Stelle für alle Fragen rund um Datenzugriff und Datenherkunft.

Delta Lake ist das offene Speicherformat unter dem Lakehouse. Es legt über die Dateien im Objektspeicher eine Transaktionsschicht (ACID), erzwingt Schemata und versioniert Änderungen (Time Travel). Im Projekt liegen alle vier Layer als Delta-Tabellen vor: Änderungen sind nachvollziehbar, fehlerhafte Läufe lassen sich zurückrollen, und Lese- wie Schreibzugriffe bleiben auch bei wachsendem Katalog konsistent.

Wie lässt sich MongoDB an ein Databricks-Lakehouse anbinden?

Über den MongoDB-Spark-Connector, der die Collections direkt in Spark liest und in den Raw-Layer schreibt. Im Projekt läuft die Anbindung inkrementell aus einem abgeschotteten, extern gehosteten Netzwerk. Netzwerkzugriffe, Secrets und Authentifizierung sind sauber getrennt, damit neue Katalog-Auszüge ohne vollständigen Reload verarbeitet werden.

Was ist Fuzzy Matching und wozu dient es?

Fuzzy Matching gleicht Datensätze ab, die dasselbe meinen, aber unterschiedlich geschrieben sind, etwa Software-Titel, Versionen und Hersteller-Varianten. Statt exakter Gleichheit bewertet es Ähnlichkeit, üblicherweise über Embeddings und eine Vektor-Datenbank. Im Projekt ist die föderierte Analytics-Tabelle die Datengrundlage für ein solches Modell.

Was ist der Unterschied zwischen Data Warehouse, Data Lake und Lakehouse?

Ein Data Warehouse ist auf strukturierte Analytics optimiert, ein Data Lake auf günstige Speicherung beliebiger Rohdaten. Das Lakehouse verbindet beides: offene Speicherung wie im Lake, dazu Transaktionen, Governance und Performance wie im Warehouse. Im Projekt trägt genau diese Kombination Ingestion, Transformation und den ML-Pfad auf einer Plattform.

Wozu dient der föderierte Export in PostgreSQL?

Der Export stellt die fertige Analytics-Tabelle dort bereit, wo das nachgelagerte Fuzzy-Matching-Modell sie konsumiert. Statt punktueller Ausleitungen läuft der Push automatisiert und reproduzierbar. Secrets, Netzwerkzugriffe und die Verbindung zwischen Databricks und PostgreSQL sind versioniert konfiguriert, sodass keine manuellen Zwischenschritte nötig sind.

Warum ein Proof of Concept mit Dev- und Prod-Umgebung statt eines einzelnen Prototyps?

Ein Prototyp beantwortet eine Machbarkeitsfrage und landet danach oft im Regal. Dev und Prod ab Tag 1, provisioniert per Infrastructure as Code, hinterlassen dagegen eine Plattform, die das interne Team nach der Übergabe im Regelbetrieb weiterführt. Im Projekt war genau das die Vorgabe: ein Proof of Concept, der auch nach vier Wochen ohne externe Hand weiterläuft.

Greenfield-Lakehouse in 4 Wochen: Databricks-Fundament für ML und GenAI

Wie ein IT-Asset-Management-Softwareanbieter mit Databricks, Unity Catalog und Vector Search eine produktive Lakehouse-Basis für Analytics, Fuzzy Matching und GenAI-Use-Cases schafft.

Projekt besprechen

Lesedauer5 Min.

VeröffentlichtJuli 2026

B2B-SaaS

Data & AI

Die wichtigsten Ergebnisse

Produktive Plattform in 4 Wochen
Vom Kickoff bis zum durchgängigen Datenpfad von MongoDB bis zum föderierten Export — als PoC geplant, im Regelbetrieb angekommen.
Läuft ohne fremde Hand
Das interne Engineering-Team übernahm die Plattform nach vier Wochen vollständig — Enablement war Teil des Auftrags.
GenAI-ready ab Tag 1
Unity Catalog und Vector Search legen die Basis für Fuzzy Matching und künftige GenAI-Use-Cases.
Dev + Prod von Anfang an
Zwei getrennte Umgebungen statt PoC-Wildwuchs — dokumentiert und wiederholbar statt manueller Einzelschritte.

Zusammenfassung

Der Kunde entwickelt Software für IT Asset Management, Endpoint Management, Cybersecurity und Software Lifecycle Management. Mehr als 200 Mitarbeitende, internationale Präsenz, Hauptsitz in Deutschland. Kern des Angebots ist ein umfangreicher Software-Katalog, der in einer abgesicherten MongoDB in einem privaten, extern gehosteten Netzwerk betrieben wird. Dieser Katalog ist über Jahre gewachsen und ein zentraler Wert im Produktportfolio.

Aus diesem Katalog sollte die Grundlage für ein neues Fuzzy-Matching-Modell entstehen. Der Anspruch war klar: eine saubere, governance-geführte Datenbasis, ein automatisierter Weg von der Quelle bis zur Analytics-Tabelle und ein internes Team, das die Plattform nach der Übergabe eigenständig betreibt. Der zeitliche Rahmen: vier Wochen, klar abgegrenzt als Proof of Concept, aber mit dem Anspruch einer Plattform, die anschließend im Regelbetrieb bleibt.

Übersicht

Kunde: Softwareanbieter für IT-Asset-Management
Branche: B2B-SaaS

Verwendete Technologien & Systeme

Apache Spark

AWS Cloud

Databricks Unity Catalog

SQL Warehouse

Databricks Delta Lake

Mosaic AI

MLflow

Services

Data & AI Strategy Consulting Databricks-Plattform Data Engineering AI und Machine Learning Databricks Training und Enablement

Die Transformation

Vom abgeschotteten Katalog zur ML-tauglichen Plattform.

01Ausgangssituation

Ein wertvoller Katalog ohne analytisches Fundament.

Der Software-Katalog ist der Kern des Produkts: kuratierte Metadaten zu tausenden von Anwendungen, gepflegt über Jahre, betrieben in einer abgesicherten MongoDB in einem privaten, extern gehosteten Netzwerk. Für die operative Anwendung funktionierte das gut. Für Analytics und Machine Learning gab es keinen Weg.

Konkret hieß das: keine strukturierte Ingestion in eine analysefähige Umgebung, keine Trennung zwischen Rohdaten und modellierten Datenprodukten, keine Governance über die Datenpfade. Ausleitungen für Analysen wurden bisher punktuell erstellt, oft skriptbasiert, ohne konsistente Metadaten und ohne Wiederholbarkeit. Das interne Team hatte klare Ideen für ML-Use-Cases rund um Fuzzy Matching, aber weder die Plattform noch die etablierten Muster, um sie umzusetzen.

Der Auftrag an ruhrdot war entsprechend fokussiert: eine Lakehouse-Grundlage aufbauen, den Katalog kontrolliert anbinden und dem eigenen Engineering-Team so viel Handwerk mitgeben, dass die Plattform nach vier Wochen ohne fremde Hand weiterläuft. Der Rahmen war ein einmonatiger Proof of Concept mit klar definiertem Zielbild, keine offene Vorstudie.

Ohne analytisches Fundament bleibt jeder produktive Katalog ein Datensilo, egal wie sauber er gepflegt ist.

02Herausforderung

Ein Proof of Concept, der auch danach trägt.

Ein einmonatiger Proof of Concept, der später im Regal landet, ist einfach zu bauen. Ein Proof of Concept, der eine Dev- und eine Prod-Umgebung hinterlässt, in kundeneigenen AWS-VPCs, mit sauberer Governance und einem Team, das den Betrieb selbst übernimmt, ist eine andere Aufgabe. Dieser Anspruch verändert die Bauentscheidung von der ersten Woche an: keine Wegwerf-Skripte, keine Notebook-Insellösungen, keine improvisierten Zugriffsrechte.

Zusätzlich lag die Quelle in einer abgeschotteten, extern gehosteten Umgebung. Es ging nicht nur darum, MongoDB anzubinden, sondern das Netzwerk-Setup, das Secrets-Handling und den externen Export in Richtung PostgreSQL sauber zu lösen, bevor die erste Zeile ML-Code sinnvoll wird. Solche Grundlagen entscheiden über die Tragfähigkeit einer Plattform mehr als jede Modellwahl.

Und die dritte Dimension: das Ziel-Modell. Die föderierte Analytics-Tabelle ist die Grundlage für ein Fuzzy-Matching-Modell, das im späteren Betrieb Software-Titel, Versionen und Hersteller-Varianten zusammenführt. Die Plattform musste diesen ML-Pfad von Anfang an mitdenken, ohne ihn im Rahmen des Proof of Concept vollständig zu implementieren. Die Herausforderung war also weniger technisch als konzeptionell: ein Fundament bauen, das das Zielbild kennt, ohne es vorwegzunehmen.

Ein Proof of Concept ist erst dann tragfähig, wenn er auch ohne den externen Partner weiterläuft.

03Strategie

Erst das Fundament, dann das Modell.

Vor der ersten Pipeline entstand gemeinsam mit ruhrdot eine schlanke Zielarchitektur: vier Lakehouse-Layer, Unity Catalog für Governance, Lakeflow Jobs für Orchestrierung, getrennte Dev- und Prod-Umgebungen in der kundeneigenen AWS-Infrastruktur und Provisionierung per Infrastructure as Code.

Der Aufbau folgte einer klaren Reihenfolge: zuerst stabile Ingestion und Transformation, danach der föderierte Export, anschließend der ML-Fahrplan. Ein Embedding-Ansatz mit Vektor-Datenbank und Batch-Inferenz wurde vorbereitet und dokumentiert, aber bewusst nicht als vorschneller Prototyp umgesetzt. Der Proof of Concept sollte ein belastbares Fundament schaffen, nicht ein Modell vorwegnehmen.

Parallel lief das Enablement des internen Teams. Data Engineering, ML Engineering und Plattformbetrieb wurden in Workshop-Tracks vermittelt. Aufzeichnungen, Dokumentation und Templates sichern die Übergabe und erleichtern das Onboarding weiterer Teammitglieder.

Leitprinzip: das Team baut mit, nicht daneben.

04Lösung

Vier Layer, zwei Umgebungen, ein sauberer Übergabepunkt.

In vier Wochen entstand ein durchgängiger Datenpfad von MongoDB bis zum föderierten Export. Die MongoDB-Ingestion läuft über den MongoDB-Spark-Connector aus dem extern gehosteten Netzwerk in den Raw-Layer. Curated bereinigt und harmonisiert die Daten, Datamart modelliert sie fachlich, Analytics stellt die finale Tabelle für den nächsten Verarbeitungsschritt bereit. Lakeflow Jobs orchestrieren den Ablauf, Unity Catalog dokumentiert Lineage, Ownership und Zugriffe über alle Layer hinweg.

Die finale Tabelle wird automatisiert in eine externe PostgreSQL-Umgebung exportiert, an die das spätere Fuzzy-Matching-Modell anschließen kann. Secrets, Netzwerkzugriffe und Systemverbindungen sind reproduzierbar konfiguriert. Damit ist das Zusammenspiel zwischen Databricks, MongoDB und PostgreSQL dokumentiert und wiederholbar, statt von manuellen Einzelschritten abhängig zu sein.

Dev- und Prod-Umgebungen wurden von Beginn an getrennt aufgebaut. Neue Katalog-Auszüge durchlaufen zuerst die Entwicklungsumgebung, bevor sie produktiv bereitgestellt werden. Für das interne Team entstand dadurch ein klarer Übergabepunkt: dokumentierte Pipelines, aufgezeichnete Workshops, wiederverwendbare Templates und ein separater ML-Fahrplan für das spätere Fuzzy-Matching-Modell.

Der Proof of Concept endet nicht mit einem isolierten Prototyp, sondern mit einem Plattformmuster, das der Kunde eigenständig weiterführen kann.

4 Wochenvom Kickoff zur produktiven Plattform

100 % Eigenbetriebläuft nach Handover allein weiter

Zielarchitektur

Software-Katalog im Lakehouse.

Der MongoDB-Katalog läuft über automatisierte Pipelines in eine vierschichtige Lakehouse-Architektur auf Databricks. Raw, Curated, Datamart und Analytics, governance-geführt über Unity Catalog, mit automatisiertem Export in eine externe PostgreSQL für die nachgelagerte ML-Anbindung. Quellsysteme Databricks Data Intelligence Platform (Managed · AWS · Unity Catalog) Workloads Deployment & Betrieb: dev + prod Workspaces · Infrastructure as Code · Enablement Kundeneigene AWS-VPCs · Infrastructure-as-Code-Templates · aufgezeichnete Workshops. Wrapped around everything.

Bausteine

MongoDB-Katalog: Software-Metadaten im privaten, extern gehosteten Netzwerk
Externe PostgreSQL: Ziel des föderierten Tabellen-Exports
Versionsverwaltung: Repositories, Infrastructure-as-Code-Templates
Governance: Unity Catalog · RBAC · Lineage · Audit
Data Ingestion: Raw → Curated → Datamart → Analytics
Foundation: Delta Lake · Apache Spark · MongoDB-Spark-Connector · Lakeflow Jobs
MongoDB-Ingestion: Katalog aus dem privaten Netzwerk in den Raw-Layer
ETL-Orchestrierung: Transformation über alle vier Layer

Platform Outcomes

Was sich durch den Proof of Concept verändert hat

Durchgängiger Datenpfad von Quelle bis Zielsystem

MongoDB-Ingestion, Verarbeitung über vier Lakehouse-Layer und der Export in PostgreSQL laufen automatisiert über Lakeflow Jobs. Aus einem manuellen Integrationspfad wird ein wiederholbarer Ablauf mit klarer Verantwortlichkeit und nachvollziehbarer Verarbeitung.

Reproduzierbare Plattform statt Einzelaufbau

Dev- und Prod-Umgebungen wurden von Beginn an getrennt und per Infrastructure as Code aufgebaut. Änderungen können kontrolliert getestet, versioniert und anschließend produktiv übernommen werden. Damit entsteht ein Betriebsmodell, das über den Proof of Concept hinaus tragfähig ist.

Governance und Nachvollziehbarkeit ab dem ersten Layer

Unity Catalog regelt Ownership, Zugriffe und Lineage über alle Layer hinweg. Wer welche Daten sehen darf, woher eine Tabelle stammt und wie sie verarbeitet wurde, ist zentral nachvollziehbar. Das schafft die Grundlage für kontrollierten Betrieb und spätere Audits.

Externe Integration ohne operative Bruchstelle

Der föderierte Export in PostgreSQL, Secrets-Handling und Netzwerkzugriffe sind reproduzierbar konfiguriert. Die Anbindung an das spätere Fuzzy-Matching-Modell erfolgt damit über einen dokumentierten Übergabepunkt, nicht über manuelle Zwischenschritte.

Grundlage für ML- und GenAI-Use-Cases

Der ML-Fahrplan für Fuzzy Matching wurde entlang der bestehenden Pipeline vorbereitet: Embeddings, Vektor-Datenbank und Batch-Inferenz haben einen klaren technischen Startpunkt. Weitere Modelle oder Agenten-Szenarien können später auf derselben Lakehouse- und Governance-Basis aufsetzen.

Vorher / Nachher

Was sich konkret verändert hat

Vorher

Nachher

Datenzugriff

Der Katalog war primär im operativen MongoDB-Betrieb nutzbar

Analytics-fähige Datenbasis über vier Lakehouse-Layer und Unity Catalog

Datenverarbeitung

Es gab keinen durchgängigen Pfad in eine analytische Umgebung

Automatisierte End-to-End-Pipeline von Raw bis Analytics

Governance

Zugriffe, Datenpfade und Verantwortlichkeiten waren nicht zentral dokumentiert

Unity Catalog regelt Ownership, Rechte und Lineage über alle Layer

Betriebsmodell

Analytics-Umgebungen und Deployments waren noch nicht standardisiert

Getrennte Dev- und Prod-Umgebungen in kundeneigener AWS-Infrastruktur, provisioniert per Infrastructure as Code

ML-Bereitschaft

Fuzzy Matching war als fachlicher Bedarf vorhanden, aber ohne belastbares Plattformfundament

Föderierte Analytics-Tabelle und dokumentierter ML-Fahrplan für Embeddings, Vektor-Datenbank und Batch-Inferenz

Nächste Schritte

Vom Lakehouse-Fundament zu ML- und GenAI-Services

Der Proof of Concept schafft die Grundlage für die nächsten Ausbaustufen: Fuzzy Matching, weitere Katalog- und Produktdatenquellen sowie GenAI-gestützte Services auf derselben governance-geführten Plattform.

Fuzzy Matching operationalisieren

Der dokumentierte ML-Fahrplan wird umgesetzt: Embeddings erzeugen, Vektor-Datenbank anbinden und Batch-Inferenz entlang der bestehenden Pipeline aufsetzen. Die Plattform liefert dafür Datenbasis, Governance, Training, Serving und Monitoring. Die Auswahl der Modelle bleibt beim internen Team.

Weitere Katalog- und Produktdaten anbinden

Zusätzliche Katalog-Sichten und angrenzende Quellsysteme werden über das bestehende Raw-, Curated-, Datamart- und Analytics-Muster integriert. Neue Quellen folgen damit einem wiederverwendbaren Onboarding statt individueller Sonderlogik.

GenAI-Services für die Produktlinie vorbereiten

Auf der konsolidierten Datenbasis entstehen weitere ML- und GenAI-Anwendungsfälle: semantische Produktsuche, Dubletten-Erkennung, automatische Kataloganreicherung, Ähnlichkeitsabfragen und Assistenzfunktionen für interne Produktteams. Fuzzy Matching wird damit zum ersten Baustein einer Plattform, auf der weitere intelligente Services entstehen können, ohne Datenpfade oder Governance neu aufzubauen.

Steht eure Datenplattform vor einer ähnlichen Skalierungsfrage?

Wenn neue Analytics-, ML- oder GenAI-Use-Cases entstehen sollen, reicht eine gewachsene Datenquelle oft nicht mehr aus. Entscheidend ist ein gemeinsames Fundament: saubere Ingestion, klare Governance, reproduzierbare Umgebungen und ein Betriebsmodell, das auch nach dem ersten Proof of Concept weiterträgt. Wir prüfen mit euch, ob ein Lakehouse-Ansatz für eure Datenlandschaft sinnvoll ist und welcher erste produktive Schritt realistisch erreichbar ist.

Jetzt unverbindliches Gespräch vereinbaren

Alexander Rabe

Co-Founder · Head of Data & AI

FAQ

Häufig gestellte Fragen

Jetzt offene Fragen klären

: Die Ausgangslage war eine produktive MongoDB als operativer Katalog, ohne eigene Analytics- oder ML-Umgebung. Ein Greenfield-Aufbau war die kürzere Strecke: eine Plattform, ein Governance-Modell, ein Betriebsmodell. Databricks bringt Lakehouse-Architektur, Unity Catalog und Lakeflow Jobs in einer Umgebung zusammen und trägt Ingestion, Transformation und den ML-Pfad auf derselben Grundlage.
: Die Medallion-Architektur gliedert Daten in mehrere Schichten. Im Projekt entspricht das Raw für Rohdaten aus der MongoDB, Curated für bereinigte und harmonisierte Datenstände, Datamart für fachlich modellierte Sichten und Analytics für die konsumfertige, föderierte Tabelle. Dieses Modell sorgt für Nachvollziehbarkeit, Datenqualität und klare Verantwortlichkeiten. Jede Schicht hat einen definierten Zweck, klare Ownership und ein eigenes Qualitätsniveau, was den Betrieb entlang der Pipeline vereinfacht.
: Unity Catalog ist die Governance-Ebene der Databricks-Plattform. Er bündelt Metadaten, Zugriffsrechte, Lineage und Auditing über alle Datenobjekte im Lakehouse. Im Projekt regelt Unity Catalog, wer welche Katalog-Sicht sehen darf, wie Daten zwischen den Layern fließen und welche Objekte im Federated-Export landen. Damit hat das Team eine zentrale Stelle für alle Fragen rund um Datenzugriff und Datenherkunft.
: Delta Lake ist das offene Speicherformat unter dem Lakehouse. Es legt über die Dateien im Objektspeicher eine Transaktionsschicht (ACID), erzwingt Schemata und versioniert Änderungen (Time Travel). Im Projekt liegen alle vier Layer als Delta-Tabellen vor: Änderungen sind nachvollziehbar, fehlerhafte Läufe lassen sich zurückrollen, und Lese- wie Schreibzugriffe bleiben auch bei wachsendem Katalog konsistent.
: Über den MongoDB-Spark-Connector, der die Collections direkt in Spark liest und in den Raw-Layer schreibt. Im Projekt läuft die Anbindung inkrementell aus einem abgeschotteten, extern gehosteten Netzwerk. Netzwerkzugriffe, Secrets und Authentifizierung sind sauber getrennt, damit neue Katalog-Auszüge ohne vollständigen Reload verarbeitet werden.
: Fuzzy Matching gleicht Datensätze ab, die dasselbe meinen, aber unterschiedlich geschrieben sind, etwa Software-Titel, Versionen und Hersteller-Varianten. Statt exakter Gleichheit bewertet es Ähnlichkeit, üblicherweise über Embeddings und eine Vektor-Datenbank. Im Projekt ist die föderierte Analytics-Tabelle die Datengrundlage für ein solches Modell.
: Ein Data Warehouse ist auf strukturierte Analytics optimiert, ein Data Lake auf günstige Speicherung beliebiger Rohdaten. Das Lakehouse verbindet beides: offene Speicherung wie im Lake, dazu Transaktionen, Governance und Performance wie im Warehouse. Im Projekt trägt genau diese Kombination Ingestion, Transformation und den ML-Pfad auf einer Plattform.
: Der Export stellt die fertige Analytics-Tabelle dort bereit, wo das nachgelagerte Fuzzy-Matching-Modell sie konsumiert. Statt punktueller Ausleitungen läuft der Push automatisiert und reproduzierbar. Secrets, Netzwerkzugriffe und die Verbindung zwischen Databricks und PostgreSQL sind versioniert konfiguriert, sodass keine manuellen Zwischenschritte nötig sind.
: Ein Prototyp beantwortet eine Machbarkeitsfrage und landet danach oft im Regal. Dev und Prod ab Tag 1, provisioniert per Infrastructure as Code, hinterlassen dagegen eine Plattform, die das interne Team nach der Übergabe im Regelbetrieb weiterführt. Im Projekt war genau das die Vorgabe: ein Proof of Concept, der auch nach vier Wochen ohne externe Hand weiterläuft.

Success Stories

Weitere Success Stories

Immobiliendienstleister