Apache DolphinScheduler 3.x cambia radicalmente su arquitectura. Los equipos que aún utilizan la versión 1.3 deben reconfigurar el diseño de su clúster y reescribir el esquema de la base de datos antes de poder actualizar. El antiguo master de un solo nodo desaparece, siendo reemplazado por un sistema descentralizado basado en plugins que programa, almacena y registra trabajos de manera diferente.
Por qué este salto es importante
La versión 1.3 se aferraba a un master centralizado que gestionaba cada decisión de programación y ofrecía solo doce tipos de tareas integrados. La versión 3.x lo sustituye por un microkernel que carga los tipos de tareas y los adaptadores de almacenamiento como plugins, y elimina el punto único de fallo permitiendo que los masters y workers se comuniquen a través de un servicio de registro (registry). Los operadores ganan escalabilidad y resiliencia; los desarrolladores pueden extender el scheduler simplemente añadiendo un archivo JAR en lugar de modificar el código central.
La revisión arquitectónica
- Sistema de plugins de microkernel – Las definiciones de tareas, los controladores de recursos y las comprobaciones de salud personalizadas ahora residen en módulos separados. Añada un nuevo tipo de tarea colocando su plugin en el classpath y reiniciando los nodos afectados.
- Coordinación descentralizada – Los masters y workers se descubren entre sí a través de un registro. El registro puede ser ZooKeeper (el valor predeterminado histórico), una base de datos relacional basada en JDBC o un clúster de Etcd. Elija la tecnología que mejor se adapte a su stack existente.
- Catálogo de tareas ampliado – Las tareas integradas han pasado de 12 a más de 30, cubriendo cargas de trabajo nativas de la nube y pipelines de aprendizaje automático (machine learning).
- MasterServer vs WorkerServer – El MasterServer ahora gestiona la partición de DAG, el envío y el monitoreo de salud. El WorkerServer actúa como un motor de ejecución puro que también transmite logs. Esta división clarifica las responsabilidades y permite dimensionar cada capa de forma independiente.
- Tolerancia a fallos mediante Watcher – El Watcher supervisa el registro en busca de fallos en los nodos. Cuando un Master o Worker cae, el registro activa una conmutación por error (failover) automática.
- Transporte de logs mediante gRPC – La recuperación remota de logs pasó de un protocolo basado en Netty a gRPC, lo que, según la fuente, ofrece un mejor rendimiento.
Refactorización de la base de datos que no puede ignorar
La revisión del esquema es el obstáculo más concreto para cualquier actualización:
| Tabla 1.3 | Tabla 3.x | Qué cambió |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
El término “process” se renombró a “workflow” para coincidir con el vocabulario de la UI y la API. |
t_ds_process_instance |
t_ds_workflow_instance |
El mismo cambio semántico para los registros en tiempo de ejecución. |
Más allá del cambio de nombre, la versión 3.x extrae los metadatos de las tareas que antes residían dentro de blobs JSON hacia tablas relacionales dedicadas, lo que hace que la gestión de datos sea más limpia.
Lista de verificación de migración
- Realice una copia de seguridad de todo – Exporte el volcado completo de la base de datos 1.3 y copie el directorio
conf. - Mapee las tablas antiguas a los nuevos nombres – Ejecute un script que renombre
t_ds_process_definitionat_ds_workflow_definitionyt_ds_process_instanceat_ds_workflow_instance. Verifique las restricciones de clave foránea (foreign-key) después. - Migre los campos de tareas JSON – Copie los datos de las tareas codificados en JSON en las nuevas tablas relacionales. Pruebe un puñado de DAGs para confirmar que el scheduler lee el nuevo diseño.
- Elija un registro – Mantenga ZooKeeper si ya lo utiliza; de lo contrario, configure un registro basado en JDBC o un clúster de Etcd y apunte todos los nodos a la nueva dirección.
- Despliegue los plugins – Empaquete cualquier tipo de tarea personalizada que haya utilizado en la 1.3 como plugins compatibles con la 3.x y despliéguelos en cada MasterServer.
- Implemente primero el MasterServer – Inicie una nueva instancia de MasterServer apuntando a la base de datos migrada. Verifique que enumere los workflows existentes y que el panel de salud no muestre errores.
- Añada WorkerServers – Inicie los WorkerServers uno a la vez. Observe el registro para confirmar el registro exitoso y verifique que los logs fluyan a través de gRPC.
- Realice pruebas de humo (smoke tests) – Ejecute algunos DAGs de bajo riesgo que cubran los tipos de tareas más comunes. Compruebe que los logs aparezcan en la UI y que las actualizaciones del estado de las tareas se propaguen correctamente.
- Monitoree la conmutación por error – Simule la caída de un MasterServer y observe cómo el Watcher promueve a uno de reserva (standby). Confirme que las tareas en curso continúen sin necesidad de un reinicio manual.
Lo que podría causarle problemas
El nuevo modelo de plugins es potente, pero eleva el nivel de exigencia para el desarrollo personalizado.
En conclusión: Pasar de la versión 1.3 a la 3.x no es un simple salto de versión; requiere un renombrado coordinado de la base de datos, una migración de JSON a relacional y una rearquitectura de su clúster basada en un modelo de registros y habilitado para complementos. Siga la lista de verificación paso a paso, realice pruebas tempranas y obtendrá un planificador que escala horizontalmente, se recupera automáticamente y utiliza el mismo protocolo que los servicios modernos en la nube.