Wie ERGO Hestia mit Lakebase und Mosaic AI Model Serving die Time-to-Market verkürzte

Die nächste Generation des Echtzeit-Pricings aufbauen

ERGO Hestia, eine der führenden Versicherungsgesellschaften Polens, betreibt eine groß angelegte Pricing-Plattform, die über 100 Modelle und 1.000 Variablen unterstützt. Als einer der größten polnischen Nutzer von Databricks hat ERGO Hestia erhebliche Kapazitäten für hochmoderne Preiskalkulationen im Millisekundenbereich und branchenführende Ausführungsgeschwindigkeiten aufgebaut.

Da das Team jedoch ständig nach der nächsten großen Innovation in der Versicherungstechnologie strebt, erkannte es eine Möglichkeit zur weiteren Umsatzmaximierung durch die Einführung von Echtzeit-B2C-Funktionen. Obwohl die bestehende Architektur hochfunktional war, brachte der Übergang zu kontinuierlichen Modell-Updates und sofortiger Kundenreaktionsfähigkeit eine neue Herausforderung mit sich: das Innovationstempo bei zunehmender Komplexität hochzuhalten. Das Team hatte die Kunst des wettbewerbsfähigen Pricings gemeistert und war nun bereit, Pionierarbeit für die nächste Generation der Echtzeit-Preiskalkulation zu leisten.

Aufbauend auf einer engen und produktiven Partnerschaft erörterten ERGO Hestia und Databricks gemeinsam, wie die bisherige Architektur für die nächste Generation des Echtzeit-Pricings verbessert werden kann. Diese großartige Zusammenarbeit führte zur Weiterentwicklung der Plattform unter Verwendung von Lakebase, um einen Online Feature Store neben Mosaic AI Model Serving Endpoints bereitzustellen und so alle Daten und die gesamte Logik innerhalb des Databricks-Ökosystems zu halten. Diese Architektur belässt sowohl die Daten als auch das Model Serving innerhalb des Lakehouse, wodurch externe Systeme überflüssig werden und die Bereitstellungszeit von Modellen verkürzt wird. Durch die Vereinheitlichung der Governance über Unity Catalog integriert das Team das Daten- und Modellmanagement, um eine vollständige Rückverfolgbarkeit und langfristige Aufbewahrung historischer Trainingsdaten und Modellversionen zu gewährleisten. Diese Architektur bietet Pricing-Experten einen zuverlässigen Audit-Trail, um sicherzustellen, dass jede Entscheidung vollständig rückverfolgbar und überprüfbar bleibt, während gleichzeitig eine maximale Modellleistung aufrechterhalten wird. Letztendlich versetzt diese Transformation das Team in die Lage, das Innovationstempo zu beschleunigen, schnell auf Marktbedingungen zu reagieren und gleichzeitig seine hochmodernen Pricing-Modelle kontinuierlich weiterzuentwickeln.

Die Herausforderung: Tempo skalieren ohne Reibungsverluste

Die bisherige Architektur folgte einem logischen Muster, bei dem Databricks Pricing-Daten über seine Medallion-Architektur aufnahm und transformierte und die verarbeiteten Datensätze anschließend in eine externe Azure PostgreSQL-Datenbank exportierte. Eine dazwischen geschaltete Adapterschicht übernahm das Caching und stellte die Daten der Pricing-Engine zur Verfügung. Dies funktionierte bei moderatem Durchsatz gut. Doch als das Datenvolumen wuchs und sich die Modelliteration beschleunigte, schränkte das Multi-Hop-Muster – bei dem Daten aus dem Lakehouse über eine externe Datenbank und eine Caching-Schicht zur Anwendung verschoben wurden – die Leistung und Agilität zunehmend ein.

1. Betriebliche Komplexität: Die Wartung einer externen Datenbank und einer benutzerdefinierten Adapterschicht verursachte einen erheblichen betrieblichen Aufwand, da sich der enorme Wartungsaufwand für Extraktionsjobs als größte Herausforderung für solche kritischen Anwendungsfälle herausstellte. Darüber hinaus bedeutete der Umgang mit einer fragmentierten Data Governance über verschiedene Systeme hinweg – einschließlich Databricks für die Datenverarbeitung und PostgreSQL für das Production Serving sowie benutzerdefiniertem Anwendungscode für die Anforderungslogik und -integration –, dass die Verfolgung der Datenherkunft (Lineage) erschwert wurde, was zu Lasten von Compliance und Auditierbarkeit ging.
2. Geschwindigkeit der Modellbereitstellung: Die bisherige Multi-Hop-Architektur erforderte eine sorgfältige Synchronisierung zwischen der Modelllogik und der zugrunde liegenden Serving-Infrastruktur, was eine technische Abhängigkeit von koordinierten Bereitstellungsfenstern schuf. Obwohl das Team bereits über die Pricing-Expertise für schnelle Iterationen verfügte, führte die Komplexität der externen Datenbank und der Adapterschicht dazu, dass Updates oft in Zeiten mit geringer Auslastung geplant wurden, um die Systemstabilität zu gewährleisten. Diese spezialisierte Orchestrierung schränkte die Häufigkeit von Updates während des Arbeitstages ein, um Leistungsrisiken in der externen Adapterschicht zu vermeiden.
3. Engpass bei der Datenaktualität: Große Datenmengen bei der Datenaufnahme führten zu Leistungseinschränkungen, die eine sorgfältige Orchestrierung erforderten, um Beeinträchtigungen während der Betriebszeiten zu vermeiden. Konkret lösten diese Updates in der externen Serving-Schicht oft Latenzspitzen um das 10- bis 20-fache aus, was Datenaktualisierungen praktisch auf zeitgesteuerte Batch-Fenster beschränkte. Um den strategischen Schritt hin zu Echtzeit-B2C-Pricing zu unterstützen, benötigte das Team eine Architektur, die den ganzen Tag über eine kontinuierliche Datenverfügbarkeit ohne diese betrieblichen Kompromisse gewährleisten konnte.

Für ein Unternehmen, das in einer regulierten Branche mehr als 100 Modelle mit über 1.000 Variablen verwaltet, führte diese Fragmentierung sowohl zu betrieblichen Reibungsverlusten als auch zu Governance-Risiken.

Die Lösung: Konsolidierung im Lakehouse

Die Transformation von ERGO Hestia basierte auf drei technischen Kernsäulen, die alle Abläufe im Lakehouse vereinheitlichten.

Lakebase für einheitliches Data Serving. Databricks Lakebase bietet eine relationale Transaktionsschicht direkt auf Delta-Tabellen. Durch die Verwendung von Sync Tables ermöglichte das Team eine kontinuierliche, automatische Synchronisierung zwischen den verarbeiteten Daten und der Serving-Schicht. Dadurch entfielen manuelle Orchestrierungen und externe Extraktionsjobs. Das Ergebnis ist eine Single Source of Truth für Pricing-Daten direkt im Lakehouse.

Model Serving Endpoints für direkten API-Zugriff. Anstatt den Weg über eine zwischengeschaltete Anwendung mit einer separaten Caching-Schicht und einer externen Datenbank zu nehmen, stellen die Model Serving Endpoints die Daten direkt der Pricing-Engine-Anwendung zur Verfügung. Dies macht die Adapterschicht völlig überflüssig und stellt sicher, dass die Anforderungslogik nativ in Databricks verbleibt. Anfragen fließen in Millisekunden von der Pricing-Engine zu den Model Serving Endpoints und zurück. Dies vereinfacht die Architektur, indem die Abfrageausführung und das Data Serving in einer einzigen verwalteten Schicht konsolidiert werden.

Model Serving für eine hochdynamische Integration des Ökosystems. Modelle werden zuerst in MLflow protokolliert, und die besten Versionen werden dann im Unity Catalog registriert, bevor sie über dedizierte Model Serving Endpoints bereitgestellt werden. Diese Architektur erweitert die bestehenden Bereitstellungsfunktionen um eine einzige, kontrollierte Ebene, auf der Pricing-Experten Modelle in Echtzeit mit Live-Daten im Databricks-Ökosystem validieren können. Sie können mehrere Modellversionen gleichzeitig ausführen, um die Leistung durch A/B- und Regressionstests zu vergleichen, während der gesamte Modelllebenszyklus nativ mit den zugrunde liegenden Datenquellen verbunden bleibt. Dieser Ansatz gewährleistet vollständige Transparenz durch integriertes Lineage-Tracking und Governance-Kontrollen, die sich sowohl auf die Daten- als auch auf die Model-Serving-Schichten im Unity Catalog erstrecken.

Die bestehenden ETL-Pipelines in Databricks erforderten keine Änderungen, und die Daten wurden einfach mit Lakebase synchronisiert, anstatt nach PostgreSQL extrahiert zu werden. Das Model Serving konnte bestehende GLM- und ML-Modelle nutzen, die in MLflow registriert, im Unity Catalog veröffentlicht und über Model Serving Endpoints bereitgestellt wurden. Für die Orchestrierung der Bereitstellungen wurde eine CI/CD-Pipeline in Azure DevOps genutzt.

Erfolg durch schrittweise Migration: Risikominimierung bei der Transformation

Anstelle einer koordinierten Gesamtumstellung entschied sich ERGO Hestia für einen stufenweisen Ansatz, bei dem Vertrauen und Geschäftskontinuität im Vordergrund standen. Das Team begann mit den am wenigsten kritischen Endpunkten und validierte Leistung und Stabilität, bevor es auf geschäftskritische Systeme expandierte. Der Pricing-Betrieb lief währenddessen ununterbrochen weiter.

Phase 1: Proof-of-Concept (Wochen 1–3)

Das Team validierte die Architektur mit einem kleinen und klar abgegrenzten Daten-Endpunkt, der ein begrenztes Portfoliosegment bediente. Sie synchronisierten die bestehende Delta-Tabelle mit Lakebase und stellten sie über einen Model Serving-Endpunkt bereit. Ein entscheidender Vorteil von Lakebase ist die einzigartige Trennung von Compute und Storage, wodurch das System mühelos skaliert werden konnte, um Spitzenlasten bei den Anfragen ohne manuelle Anpassungen an der Compute-Infrastruktur zu bewältigen. Databricks bot integrierte Observability für Latenz und CPU-Auslastung sowie für Durchsatz und Speichernutzung. Die Leistungstests zeigten, dass die Architektur die Erwartungen mit einer Latenz von 20 ms und einer CPU-Auslastung von weniger als 5 % selbst bei einer hohen Last von 40 Anfragen pro Sekunde weit übertraf. Dieser frühe Erfolg eliminierte architektonische Risiken, bevor das Projekt auf die Produktion ausgeweitet wurde.

Phase 2: Bereitstellung in der Produktion (Wochen 3–6)

Nach der Validierung des PoC begann das Team mit der Produktionsmigration, beginnend mit weniger kritischen Endpunkten. Mit der Migration der einzelnen Endpunkte wurden durchweg konsistente Ergebnisse erzielt: perfekte Datenkonsistenz zwischen Delta Lake und Lakebase, stabile und vorhersehbare Leistung sowie weniger benutzerdefinierte Komponenten als bei der Altsystem-Architektur. Mit jeder erfolgreichen Migration wuchs das Vertrauen der Stakeholder, sodass das Team die Expansion auf Endpunkte mit höherem Risiko beschleunigen konnte.

Phase 3: Traffic-Splitting und Validierung unter realen Bedingungen.

Anstatt sich auf ein einziges Umstellungsdatum festzulegen, implementierte ERGO Hestia einen Traffic-Split unter Produktionsbedingungen: Die Hälfte des Kundenstamms wurde über Altsysteme geleitet, die andere Hälfte über das neue System. Dieser Ansatz ermöglichte die praxisnahe Beobachtung des tatsächlichen Nutzerverhaltens und der Lastmuster. Die neuen Preisbildungsmodelle lieferten eine konsistente Angebotserstellung und erfüllten alle Latenzerwartungen. Entscheidend war, dass das Team validieren konnte, dass das neue System die Produktionslast genau wie geplant bewältigte.

Warum dieser Ansatz erfolgreich war: Die schrittweise Strategie eliminierte Risiken in jeder Phase. Die Validierung von Systembereichen mit geringer Kritikalität verhinderte katastrophale, systemweite Ausfälle. Erfolgreiche Meilensteine stärkten das Vertrauen im Unternehmen und ermöglichten eine schnellere Expansion. Die praxisnahe Produktionsvalidierung im großen Maßstab bestätigte, dass die Architektur wie geplant funktionierte. Über alle Phasen hinweg lief die Preisgestaltung ohne Unterbrechung und ohne Auswirkungen auf die Kunden weiter.

Geschäftsergebnisse: Innovationsgeschwindigkeit steigern

Schnellere Markteinführung von Modellen: Pricing-Experten stellen Modelle jetzt direkt im Databricks-Ökosystem bereit, wo sie automatisch mit den neuesten Produktionsdaten synchronisiert werden. Durch die Bereitstellung von Modellen über Mosaic AI zusammen mit dem Lakebase Online Feature Store eliminiert das Team die Latenz, die normalerweise bei der Synchronisierung externer Modellausgaben mit Live-Datenströmen auftritt. Diese Integration stellt sicher, dass die bestehende Agilität von ERGO Hestia nun durch eine direkte Hochgeschwindigkeitsverbindung zwischen Echtzeit-Marktdaten und der Pricing-Engine ergänzt wird. Die Möglichkeit, diese synchronisierten Modelle auszuführen, erlaubt eine schnelle Reaktion auf Marktbedingungen und wettbewerbsbedingten Preisdruck, was letztendlich zu höheren Umsätzen für das Unternehmen führt.

Operative Vereinfachung: Die operative Komplexität wurde durch architektonische Einfachheit ersetzt. Durch die Entfernung der externen PostgreSQL-Datenbank und der Adapterschicht hat ERGO Hestia seinen Stack unter einem einzigen Governance-Modell mit Unity Catalog vereinheitlicht. Dieser Schritt eliminierte den manuellen Aufwand für Patching und Kapazitätsplanung und zentralisierte gleichzeitig die Logik für Preisanfragen innerhalb des Databricks-Ökosystems. Da Logik und Daten nun in einer leistungsstarken Umgebung zusammengeführt sind, verlagert sich die Kapazität der Entwickler von der Wartung maßgeschneiderter Middleware hin zur Förderung von Modellinnovationen.

Einheitliche Governance und Compliance: In einer regulierten Branche ist die Fähigkeit, genau nachzuweisen, worauf eine Preisentscheidung basierte, von entscheidender Bedeutung. Durch die Vereinheitlichung aller Preisdaten und -modelle unter Unity Catalog profitiert ERGO Hestia von automatischen Audit-Trails, Versionsverfolgung und Zugriffskontrollen. Die Datenkonsistenz wird nun automatisch über die gesamte Pipeline hinweg überprüft, um sicherzustellen, dass die beim Testen verwendete Logik perfekt mit der Logik in der Produktion übereinstimmt. Dank der integrierten Plattform-Lineage lässt sich sofort und lückenlos nachvollziehen, welches Modell welche Kunden in einem bestimmten Zeitraum bedient hat. Dies macht manuelle Compliance-Arbeit überflüssig. Compliance-Teams können nun genau nachweisen, welche Daten in die jeweilige Preisentscheidung eingeflossen sind, wer Zugriff hatte und wann Änderungen vorgenommen wurden. Alles wird automatisch erfasst, was eine manuelle Rekonstruktion überflüssig macht und eine Vertrauensbasis schafft, mit der das Unternehmen seine Umsatzmaximierungsstrategien absolut sicher skalieren kann.

Der Weg nach vorn: Skalierung von Innovationen im gesamten Unternehmen

Der Erfolg der Pricing-Abteilung dient als Blaupause für die Skalierung über verschiedene Pricing-Bereiche hinweg. ERGO Hestia weitet die Lakebase- und Model Serving-Architektur nun auf die gesamte Pricing-Organisation aus. Jeder Bereich wird seine Entscheidungs-Engines innerhalb der Lakehouse-Plattform konsolidieren und Modelle sowie Daten als First-Class-Services mit einheitlicher Governance bereitstellen.

Die erste Validierung mit einem kleinen Endpunkt mit geringer Kritikalität hat den Ansatz bestätigt. Nun skaliert das Pricing Office nach demselben schrittweisen Playbook auf größere, kritischere Workloads und umfangreichere Datenbanken. Datensätze mit höherer Relevanz und komplexe Modelle erfordern eine strengere Validierung, aber das Muster der schrittweisen Migration bleibt unverändert.

Das Ziel ist klar: Die externe Azure PostgreSQL-Datenbank soll abgeschaltet werden, sobald alle Pricing-Bereiche erfolgreich auf Lakebase migriert wurden. Die Migration jedes einzelnen Bereichs stärkt das Vertrauen für den nächsten und beschleunigt den gesamten Zeitplan hin zu einer einheitlichen, Databricks-nativen Pricing-Infrastruktur.

Über den Pricing-Betrieb hinaus eröffnet die Konsolidierung aller Preisdaten im Lakehouse neue Möglichkeiten. Da die Pricing-Intelligence in Databricks vereinheitlicht ist, können Teams AI/BI Genie nutzen, um Preismuster zu untersuchen, Erkenntnisse zu gewinnen und Ad-hoc-Geschäftsfragen ohne Unterstützung durch die Entwicklung zu beantworten. Dieselben Daten, die die Pricing-Engine speisen, treiben nun auch Business Intelligence und KI-gestützte Analysen an, was den Wert der Lakehouse-Investition vervielfacht.

Dieses bewährte Muster dient nun als Vorlage für andere Geschäftsbereiche, um externe Abhängigkeiten zu beseitigen und ihre eigene Entscheidungsgeschwindigkeit zu erhöhen.

Fazit

Die Transformation von ERGO Hestia veranschaulicht ein branchenübergreifendes Prinzip: Die Konsolidierung auf einer einheitlichen Plattform beschleunigt die Innovationsgeschwindigkeit und vereinfacht gleichzeitig den Betrieb. Durch den Wechsel zu einer Lakehouse-nativen Architektur, bei der Daten und Modelle direkt über Databricks Lakebase und Model Serving bereitgestellt werden, hat sich die Pricing-Abteilung schneller, zuverlässiger und zukunftsfähiger aufgestellt.

In einem Markt, in dem Millisekunden entscheiden, ist das Unterscheidungsmerkmal nicht mehr nur das Modell selbst, sondern die Architektur, die es ihm ermöglicht, in Echtzeit auf die Realität zu reagieren. Natives A/B-Testing, automatisierte Guardrails und kontinuierliche Audit-Trails in Unity Catalog stellen sicher, dass jede Entscheidung nachvollziehbar bleibt und innerhalb festgelegter Risikogrenzen liegt.

Diese Architektur dient als praktische Referenz für die gesamte ERGO-Organisation und jedes Unternehmen, das Pricing-Engines im Millisekundenbereich einführen möchte, um die Marktwirkung und das Umsatzwachstum zu maximieren. Für die Branche stellt sich nicht mehr die Frage nach der technischen Machbarkeit von Echtzeit-Pricing, sondern wie schnell sie die Architektur einführen kann, die dies zur Realität macht.

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