Deutsche Börse разработала инструмент для массовой миграции Zeppelin‑ноутбуков в Databricks

Deutsche Börse создала Databricks‑приложение и генеративную систему «Genie» для автоматической структурной конвертации тысяч Zeppelin‑ноутбуков в формат.ipynb, что ускоряет перенос аналитики в облако и сохраняет критическую логику нетронутой.

Deutsche Börse Group разработала на платформе Databricks специальное приложение, чтобы автоматически конвертировать тысячи Zeppelin‑ноутбуков при переносе аналитики в облако. Это важно для StatistiX — системы, которая предоставляет около 95% данных по Clearing и Trading внутри группы и обслуживает сотни бизнес‑пользователей; переход означает работу с тысячами ноутбуков и более чем 2 000 пользователями, многие ноутбуки встроены в ежедневные операционные процессы. Команда создала Databricks App с названием «Zeppelin to Databricks Notebook Converter», выполняющую детерминированную структурную конвертацию: параграфы Zeppelin превращаются в ячейки Databricks, применяются соответствия интерпретаторов (%python, %sql, %pyspark и др.), метаданные преобразуются в валидный.ipynb JSON, а исходное содержимое сохраняется без переписывания логики. Такой подход отделяет работу по преобразованию структуры файла от восстановления бизнес‑логики.

После автоматической конвертации приложение генерирует контекстно‑осведомлённые подсказки для «Genie» — внутренней генеративной системы, которая помогает восстановить код и рабочие приёмы в стиле Databricks. Подсказка включает информацию о кастомных интерпретаторах, источниках данных и конфигурациях. Обычный рабочий поток выглядит так: экспорт Zeppelin JSON, загрузка в приложение, Convert, скачивание.ipynb, загрузка в Databricks и запуск Genie с подготовленной подсказкой. Авторы подчёркивают принципальное архитектурное решение: отделять структуру от логики. Структурная конверсия детерминирована и поддаётся автоматизации, тогда как реконструкция бизнес‑логики — нет: разнообразие SQL‑запросов, Python‑фрагментов, визуализаций и пользовательских настроек делает правило‑основанные движки непрактичными. LLM‑подход оказался эффективен в подготовке контекста и помощи инженерам при восстановлении и валидации логики.

команда сознательно отказалась от автоматического переписывания критических частей: SQL и Python‑логики, визуализаций, виджетов, ссылок на Oracle и HDFS, логики расписаний и бизнес‑специфичного кода оставлены нетронутыми, чтобы не нарушить работу и не подорвать доверие внутренних команд. Практический эффект — заметное ускорение миграции по сравнению с ручной переработкой, которая заняла бы годы; сохраняется институциональная память в исходных ноутбуках и формируется контролируемый поток для восстановления и валидации логики с помощью Genie. В производственном интерфейсе используется shadcn UI (прототип выполняли на Streamlit), а поставка реализована через Databricks Apps, что позволило быстро развернуть решение без отдельной инфраструктуры.