Apache DolphinScheduler 3.x переворачивает архитектуру с ног на голову. Командам, использующим версию 1.3, придется перестроить конфигурацию кластера и переписать схему базы данных перед обновлением. Старый одноузловой мастер исчезает, уступая место децентрализованной системе на базе плагинов, которая иначе планирует, хранит и логирует задачи.

Почему это обновление важно

Версия 1.3 опиралась на централизованный мастер, который принимал все решения по планированию и предлагал всего двенадцать встроенных типов задач. В версии 3.x на смену ему пришло микроядро, которое загружает типы задач и адаптеры хранения в виде плагинов. Это устраняет единую точку отказа, позволяя мастерам и воркерам взаимодействовать через сервис реестра (registry service). Операторы получают масштабируемость и отказоустойчивость; разработчики могут расширять планировщик, просто добавляя JAR-файл, вместо того чтобы вносить изменения в основной код.

Архитектурная переработка

  • Система плагинов на базе микроядра – Определения задач, обработчики ресурсов и пользовательские проверки состояния теперь находятся в отдельных модулях. Чтобы добавить новый тип задачи, достаточно поместить плагин в classpath и перезапустить соответствующие узлы.
  • Децентрализованная координация – Мастера и воркеры находят друг друга через реестр. В качестве реестра можно использовать ZooKeeper (традиционный вариант по умолчанию), реляционную базу данных на базе JDBC или кластер Etcd. Выбирайте технологию, которая соответствует вашему текущему стеку.
  • Расширенный каталог задач – Количество встроенных задач выросло с 12 до более чем 30, охватывая облачные (cloud-native) рабочие нагрузки и конвейеры машинного обучения.
  • MasterServer против WorkerServer – MasterServer теперь отвечает за разбиение DAG, отправку задач и мониторинг состояния. WorkerServer выступает в роли чистого движка выполнения, который также транслирует логи. Такое разделение разграничивает обязанности и позволяет независимо масштабировать каждый уровень.
  • Отказоустойчивость через Watcher – Watcher следит за реестром на предмет сбоев узлов. Если Master или Worker выходит из строя, реестр инициирует автоматическое переключение (failover).
  • Транспортировка логов через gRPC – Удаленное получение логов перешло с протокола на базе Netty на gRPC, что, согласно источникам, обеспечивает лучшую производительность.

Рефакторинг базы данных, который нельзя игнорировать

Переработка схемы — самое серьезное препятствие для любого обновления:

Таблица 1.3 Таблица 3.x Что изменилось
t_ds_process_definition t_ds_workflow_definition Термин «process» был переименован в «workflow», чтобы соответствовать терминологии UI и API.
t_ds_process_instance t_ds_workflow_instance Аналогичное изменение семантики для записей о выполнении.

Помимо переименования, в версии 3.x метаданные задач, которые раньше хранились внутри JSON-блобов, выносятся в отдельные реляционные таблицы, что делает управление данными более упорядоченным.

Чек-лист миграции

  1. Сделайте резервную копию всего – Экспортируйте полный дамп базы данных 1.3 и скопируйте директорию conf.
  2. Сопоставьте старые таблицы с новыми именами – Запустите скрипт, который переименует t_ds_process_definition в t_ds_workflow_definition и t_ds_process_instance в t_ds_workflow_instance. После этого проверьте ограничения внешних ключей (foreign-key constraints).
  3. Мигрируйте поля задач в формате JSON – Скопируйте данные задач в формате JSON в новые реляционные таблицы. Протестируйте несколько DAG, чтобы убедиться, что планировщик корректно считывает новую структуру.
  4. Выберите реестр – Оставьте ZooKeeper, если вы его уже используете; в противном случае настройте реестр на базе JDBC или кластер Etcd и укажите всем узлам новый адрес.
  5. Разверните плагины – Упакуйте все пользовательские типы задач, которые вы использовали в 1.3, в виде совместимых с 3.x плагинов и разверните их на каждом MasterServer.
  6. Сначала разверните MasterServer – Запустите новый экземпляр MasterServer, указывающий на мигрированную базу данных. Убедитесь, что он отображает существующие рабочие процессы (workflows) и что панель мониторинга состояния не показывает ошибок.
  7. Добавьте WorkerServers – Запускайте WorkerServers по одному. Следите за успешной регистрацией в реестре и убедитесь, что логи передаются через gRPC.
  8. Проведите дымовые тесты – Запустите несколько малорисковых DAG, охватывающих наиболее распространенные типы задач. Проверьте, появляются ли логи в UI и правильно ли обновляется статус задач.
  9. Проверьте механизм переключения при сбое – Симулируйте сбой MasterServer и посмотрите, как Watcher переводит в рабочий режим резервный узел. Убедитесь, что выполняющиеся задачи продолжаются без ручного перезапуска.

Подводные камни

Новая модель плагинов мощная, но она повышает планку требований к кастомной разработке.

Итог: Переход с версии 1.3 на 3.x — это не простое обновление версии; он требует скоординированного переименования базы данных, миграции из JSON в реляционную модель и перепроектирования архитектуры кластера под модель с поддержкой плагинов и управлением через реестр. Следуйте чек-листу шаг за шагом, проводите тестирование на ранних этапах, и вы получите планировщик, который масштабируется горизонтально, автоматически восстанавливается и работает по тем же протоколам, что и современные облачные сервисы.