Wie die Deutsche Börse ein generatives KI-Tool entwickelte, um die groß angelegte Migration von Zeppelin-Notebooks zu Databricks zu bewältigen

Bei der Deutsche Börse Group stellt unsere StatistiX-Plattform etwa 95 % aller Clearing- und Handelsdaten des Konzerns bereit und ermöglicht Self-Service-Analysen für Hunderte von Business-Anwendern. Diese Daten zugänglich und nutzbar zu halten, ist zentral für alles, was wir tun.

Jahrelang bedeutete das Zeppelin-Notebooks, die auf Cloudera liefen und Zugriff auf Oracle-Datensysteme und HDFS hatten. Die Plattform hat uns gute Dienste geleistet, aber die Landschaft hat sich verändert. Cloudera stellt Zeppelin 2027 vollständig ein, unsere Analyse-Workloads verlagern sich in die Cloud und Databricks wurde als unsere neue einheitliche Analyseplattform ausgewählt. Diese Kombination schuf eine Migrationsherausforderung, die die meisten Organisationen unterschätzen: über 2.000 Benutzer und eine große Anzahl von Notebooks, von denen viele tief in die täglichen Geschäftsabläufe eingebettet sind und alle migriert werden müssen.

Alles manuell neu zu schreiben, würde Jahre dauern. Also beschlossen wir, einen besseren Weg auf Databricks zu bauen.

Das Problem der Notebook-Migration

Infrastrukturmigrationen erhalten viel Aufmerksamkeit. Notebook-Migrationen eher nicht, was ein Hauptgrund dafür ist, dass sie Teams verlangsamen.

Unsere Zeppelin-Notebooks waren keine einfachen Skripte. Sie enthielten komplexe SQL- und Python-Logik, benutzerdefinierte Interpreter, Oracle- und HDFS-Referenzen, Visualisierungen, Widgets und Planungslogik, die über Jahre hinweg aufgebaut wurden. Jedes spiegelte das institutionelle Wissen der Geschäftsteams wider, die sich darauf verließen. Die Vielfalt in der gesamten Notebook-Landschaft machte eine regelbasierte Rewriting-Engine unpraktisch, da die Logik einfach zu heterogen und zu geschäftsspezifisch war, als dass automatisierte Regeln sie zuverlässig handhaben könnten.

Diese Einschränkung führte uns zu einer klareren Design-Erkenntnis: Trenne Struktur von Logik und wende das richtige Werkzeug auf jedes an. Die strukturelle Konvertierung (Zuordnung des Zeppelin-Paragraph-Formats zu Databricks-Zellen, Übersetzung der Interpreter-Syntax, Formatierung von Metadaten) ist deterministisch und automatisierbar, während die Logik-Rekonstruktion es nicht ist. Glücklicherweise sind LLMs großartig bei diesem Teil der strukturellen Konvertierung.

Der Konverter auf Databricks Apps aufbauen

Mit diesem Designprinzip im Hinterkopf bauten wir den Zeppelin zu Databricks Notebook Converter, eine Databricks App, die speziell für unseren Migrations-Workflow entwickelt wurde.

Die App kümmert sich um die strukturelle Seite der Konvertierung: Zeppelin-Paragraphen werden zu Databricks-Zellen, Interpreter-Zuordnungen werden angewendet (%python, %sql, %pyspark und andere werden in ihre Databricks-Äquivalente übersetzt) und Notebook-Metadaten werden in gültiges .ipynb JSON umformatiert. Der ursprüngliche Inhalt bleibt exakt erhalten. Wir schreiben die Logik in dieser Phase nicht neu, sondern bereiten sie nur für den nächsten Schritt vor.

Dieser nächste Schritt ist Genie. Für jedes hochgeladene Notebook generiert die App automatisch einen kontextbezogenen Prompt, der spezifische Details zu unserer Zeppelin-Umgebung enthält. Denken Sie an unsere benutzerdefinierten Interpreter, Datenquellen und Konfigurationsmuster. Der Prompt gibt Genie den Kontext, den es benötigt, um die Logik auf eine Databricks-native Weise genau zu rekonstruieren.

Der Workflow für einen Business-Anwender ist unkompliziert:

1. Exportieren Sie ein Zeppelin-Notebook als JSON
2. Laden Sie es in die Databricks App hoch
3. Klicken Sie auf Konvertieren
4. Laden Sie die konvertierte .ipynb herunter
5. Öffnen Sie Databricks, laden Sie das Notebook hoch, starten Sie Genie und fügen Sie den generierten Prompt ein
6. Genie stellt klärende Fragen und baut das Notebook neu auf

Die App selbst wurde mit einem shadcn UI-Frontend erstellt. Ursprünglich haben wir einen Streamlit-Prototyp entwickelt, aber wir fanden, dass shadcn uns eine professionellere und skalierbarere Schnittstelle bot. Die Entwicklungserfahrung mit Databricks Apps machte es einfach, schnell zu liefern, ohne separate Infrastruktur aufzubauen.

Was wir nicht automatisiert haben

Eine der wichtigsten Designentscheidungen war, was das Tool absichtlich unberührt lassen sollte.

Der Konverter schreibt keine SQL-Logik, Python-Logik, Visualisierungen, Widgets, Oracle- und HDFS-Referenzen, Planungslogik oder geschäftsspezifischen benutzerdefinierten Code neu. All diese Inhalte bleiben im konvertierten Notebook unverändert erhalten, da eine automatische Neufassung Fehler einführen und das Vertrauen in die Ausgabe untergraben würde. Dies sind genau die Elemente, die zwischen den Notebooks am stärksten variieren und die die geschäftskritischste Logik enthalten. Sie gehören zu Genie, das den Kontext interpretieren, klärende Fragen stellen und Urteile fällen kann, die Regeln nicht treffen können.

Dieser hybride Ansatz, den deterministischen Teil zu automatisieren und den variablen Teil zu delegieren, ermöglicht es uns, die Brüchigkeit regelbasierter Systeme zu vermeiden und KI dort einzusetzen, wo sie tatsächlich gut funktioniert.

Das Ergebnis: Stunden zu Minuten

Durch die Kombination von struktureller Konvertierung mit KI-gestützter Logik-Rekonstruktion haben wir die Wiederentwicklung von Notebooks von stundenlangem manuellem Aufwand auf 15–20 Minuten pro Notebook reduziert, abhängig von der Komplexität. Für eine groß angelegte Migration dieser Art, die mehrere Geschäftsbereiche umfasst, verwandelt dieser Ansatz ein ressourcenintensives, zeitaufwändiges Unterfangen in einen skalierbaren, wiederholbaren Workflow, der viel weniger Zeit in Anspruch nehmen wird.

Die Geschwindigkeitssteigerung verändert auch die Art der Arbeit. Business-Anwender benötigen keine tiefgreifenden Databricks-Kenntnisse, um ihre eigenen Notebooks zu migrieren. Sie folgen einer kurzen Schrittfolge, erhalten einen Prompt und lassen Genie die Rekonstruktion durchführen. Das Tool ist zugänglich genug, dass die Migration kein dediziertes Ingenieurteam erfordert.

Was wir gelernt haben

Einige Prinzipien ergaben sich aus diesem Projekt, die wir in ähnliche Bemühungen mitnehmen würden.

• Vermeiden Sie Overengineering. Unser erster Versuch nutzte eine komplexere agentische Architektur, die zusätzlichen Aufwand verursachte, ohne das Kernproblem zu lösen. Eine einfache Benutzeroberfläche und ein sauberes Backend erwiesen sich als genau ausreichend.
• Regelbasierte Neufassung skaliert nicht für heterogene Inhalte. Die Vielfalt der Logik in unseren Notebooks machte Regeln unpraktisch. LLMs sind unerlässlich, um diese Variabilität zu bewältigen, und der Schlüssel liegt darin, die Übergabe zwischen Automatisierung und KI durchdacht zu gestalten.
• Kontext ist der Unterschied zwischen einem guten und einem großartigen Prompt. Generische Genie-Prompts liefern generische Ergebnisse. Die Investition in einen Prompt, der Wissen über unsere spezifische Umgebung – Interpreter, Datenquellen, Konfigurationsmuster – kodiert, hat die Ausgabe tatsächlich nutzbar gemacht.
• Beziehen Sie Ihr Plattformteam frühzeitig ein. Unsere Zusammenarbeit mit dem Databricks-Team während des gesamten Aufbaus half uns, auf Kurs zu bleiben und Nacharbeiten zu vermeiden.

Was kommt als Nächstes

Obwohl die anfängliche Entwicklung unseres Konverter-Tools abgeschlossen ist, führen wir nun groß angelegte, reale Tests durch. Unsere unmittelbaren Prioritäten umfassen die Finalisierung der Prompt-Definitionen zur Verbesserung der Genauigkeit, die Validierung des Tools mit Notebooks aus verschiedenen Geschäftsbereichen und der IT sowie die Vorbereitung der Benutzer-Onboarding.

Die breitere Implikation ist das, was uns am meisten begeistert. Dieses Projekt hat gezeigt, dass KI-gestützte Migration keine zukünftige Fähigkeit ist, sondern jetzt verfügbar ist! Durch die Kombination von Databricks Apps mit generativer KI haben wir einen wiederholbaren Workflow entwickelt, der eines der schwierigsten Probleme der Cloud-Transformation in einen schnellen, skalierbaren Prozess verwandelt.

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