Hola a todos, soy Cai Shunfeng, ingeniero de datos sénior en WhaleOps y miembro del comité de gestión de proyectos de la comunidad Apache DolphinScheduler. Hoy explicaré cómo funciona la tarea Worker de Apache DolphinScheduler. Esta explicación se dividirá en tres secciones: Introducción a Apache DolphinScheduler Descripción general del diseño general de Apache DolphinScheduler Proceso detallado de ejecución de las tareas del Trabajador Introducción del proyecto es un sistema de programación de flujo de trabajo visual, distribuido y de código abierto, fácilmente extensible, adecuado para escenarios de nivel empresarial. Apache DolphinScheduler Proporciona las siguientes funcionalidades clave, ofreciendo una solución de procesamiento de datos de ciclo de vida completo para flujos de trabajo y tareas a través de operaciones visuales. Características principales Fácil de usar Operaciones DAG visuales: los usuarios pueden arrastrar y soltar componentes en la página para organizarlos en un DAG (gráfico acíclico dirigido). Sistema de complementos: incluye complementos de tareas, complementos de fuentes de datos, complementos de alerta, complementos de almacenamiento, complementos de centro de registro y complementos de trabajos cron, etc. Los usuarios pueden ampliar fácilmente los complementos según sea necesario para satisfacer sus requisitos comerciales. Escenarios de uso enriquecido Configuración estática: incluye programación de flujo de trabajo, operaciones en línea y fuera de línea, gestión de versiones y funciones de reposición. Operaciones en tiempo de ejecución: proporciona funcionalidades como pausar, detener, reanudar y sustitución de parámetros. Tipos de dependencia: admite un amplio conjunto de opciones y estrategias de dependencia, adaptándose a más escenarios. Paso de parámetros: admite parámetros de inicio a nivel de flujo de trabajo, parámetros globales, parámetros locales a nivel de tarea y paso de parámetros dinámicos. Alta confiabilidad Diseño descentralizado: todos los servicios no tienen estado y pueden escalarse horizontalmente para aumentar el rendimiento del sistema. Protección contra sobrecarga y tolerancia a fallos de instancia: Protección contra sobrecarga: durante la operación, el maestro y el trabajador monitorean su propio uso de CPU y memoria, así como el volumen de tareas. Si se sobrecargan, pausan el flujo de trabajo o el procesamiento de tareas actuales y lo reanudan después de la recuperación. Tolerancia a fallas de instancia: cuando los nodos maestros o de trabajo fallan, el centro de registro detecta que el nodo de servicio está fuera de línea y realiza tolerancia a fallas para instancias de flujo de trabajo o tareas, lo que garantiza la capacidad de autorrecuperación del sistema tanto como sea posible. Diseño general Arquitectura del proyecto A continuación, presentamos el contexto general del diseño. A continuación, se muestra el diagrama de la arquitectura de diseño que se proporciona en el sitio web oficial. Desde el diagrama de arquitectura, podemos ver que Apache DolphinScheduler se compone de varios componentes principales: Componente API: El servicio API administra principalmente metadatos, interactúa con la UI a través del servicio API o llama a interfaces API para crear tareas de flujo de trabajo y diversos recursos necesarios para el flujo de trabajo. Componente maestro: el maestro es el controlador de las instancias de flujo de trabajo, responsable de consumir comandos, convertirlos en instancias de flujo de trabajo, realizar la división de DAG, enviar tareas en orden y distribuir tareas a los trabajadores. Componente de trabajador: el trabajador es el ejecutor de tareas específicas. Después de recibir tareas, las procesa según diferentes tipos de tareas, interactúa con el maestro e informa el estado de la tarea. Cabe destacar que el servicio de trabajador no interactúa con la base de datos; solo los servicios API, maestro y de alerta interactúan con la base de datos. Servicio de alerta: el servicio de alerta envía alertas a través de diferentes complementos de alerta. Estos servicios se registran en el centro de registro y el maestro y el trabajador informan periódicamente los latidos y el estado actual para garantizar que puedan recibir tareas con normalidad. Proceso de interacción entre patrón y trabajador El proceso de interacción entre el patrón y el trabajador es el siguiente: Envío de tareas: una vez que el maestro completa la división de DAG, envía tareas a la base de datos y selecciona un grupo de trabajadores apropiado para distribuir tareas según diferentes estrategias de distribución. Recepción de la tarea: después de que el trabajador recibe una tarea, decide si la acepta en función de su condición. Se le proporciona retroalimentación sobre si la aceptación es exitosa o no. Ejecución de la tarea: el trabajador procesa la tarea, actualiza el estado a "en ejecución" y envía la información al maestro. El maestro actualiza el estado de la tarea y la información de la hora de inicio en la base de datos. Finalización de la tarea: una vez finalizada la tarea, el trabajador envía una notificación de evento de finalización al maestro, y este devuelve una confirmación ACK. Si no se recibe ninguna confirmación ACK, el trabajador volverá a intentarlo para asegurarse de que no se pierda el evento de la tarea. Recepción de tareas del trabajador Cuando el trabajador recibe una tarea, se realizan las siguientes operaciones: Completa su información de host. Genera la ruta del registro en la máquina del trabajador. Genera un ejecutor de tareas de trabajo, que se envía al grupo de subprocesos para su ejecución. El trabajador verifica si está sobrecargado y, en caso afirmativo, rechaza la tarea. Después de recibir la retroalimentación de falla en la distribución de tareas, el maestro continúa eligiendo otro trabajador para la distribución de tareas según la estrategia de distribución. Proceso de ejecución del trabajador El proceso de ejecución específico de las tareas del trabajador incluye los siguientes pasos: Inicialización de la tarea: inicializa el entorno y las dependencias necesarias para la tarea. Ejecución de la tarea: ejecuta la lógica de la tarea específica. Finalización de la tarea: una vez completada la ejecución de la tarea, informa los resultados de la ejecución de la tarea al nodo maestro. A continuación, detallaremos el proceso específico de ejecución de la tarea. Antes de que comience la ejecución de la tarea, primero se inicializa un contexto. En este punto, se establece la hora de inicio de la tarea. Para garantizar la precisión de la tarea, es necesario sincronizar la hora entre el maestro y el trabajador para evitar desfases de tiempo. Posteriormente, el estado de la tarea se establece en ejecución y se envía al maestro para notificar que la tarea ha comenzado a ejecutarse. Dado que la mayoría de las tareas se ejecutan en el sistema operativo Linux, se requiere procesamiento de archivos e inquilinos: primero, verifica si el inquilino existe. Si no existe, decide si crear automáticamente el inquilino según la configuración. Esto requiere que el usuario de implementación tenga permisos de sudo para cambiar al inquilino especificado durante la ejecución de la tarea. Procesamiento de inquilinos: : en algunos casos, no es necesario cambiar de inquilino, sino simplemente ejecutar la tarea con un usuario específico. El sistema también lo admite. Usuarios específicos Después de procesar el inquilino, el trabajador crea el directorio de ejecución específico. El directorio raíz del directorio de ejecución es configurable y requiere la autorización correspondiente. De manera predeterminada, los permisos del directorio están configurados en 755. Durante la ejecución de la tarea, es posible que se necesiten varios archivos de recursos, como la obtención de archivos de clústeres de AWS S3 o HDFS. El sistema descarga estos archivos en el directorio temporal del trabajador para su uso posterior en tareas. En Apache DolphinScheduler, las variables de parámetros se pueden reemplazar. Las categorías principales incluyen: implica principalmente el reemplazo de parámetros relacionados con la fecha y la hora. Parámetros incorporados: Las variables de parámetros establecidas por el usuario en el flujo de trabajo o la tarea también se reemplazarán en consecuencia. Parámetros definidos por el usuario: Mediante los pasos anteriores, el entorno de ejecución de la tarea y los recursos necesarios están listos, y la tarea puede comenzar oficialmente a ejecutarse. Diferentes tipos de tareas En Apache DolphinScheduler se admiten varios tipos de tareas, cada una aplicable a diferentes escenarios y requisitos. A continuación, presentamos varios tipos de tareas principales y sus componentes específicos. Estos componentes se utilizan comúnmente para ejecutar archivos de script, adecuados para varios lenguajes y protocolos de script: Shell: ejecuta scripts de shell. Python: ejecuta scripts de Python. SQL: ejecuta sentencias SQL. Procedimiento almacenado: ejecuta procedimientos almacenados de la base de datos. HTTP: Realiza solicitudes HTTP. La versión comercial (WhaleScheduler) también admite la ejecución de aplicaciones Java mediante la ejecución de paquetes JAR. Componentes de la tarea lógica Estos componentes se utilizan para implementar el control lógico y la gestión del flujo de trabajo: Interruptor: Tarea de control condicional. Dependiente: Tarea de dependencia. Subproceso: Subtarea. NextLoop (versión comercial): tarea de control de bucle adecuada para escenarios financieros. Componente disparador: supervisa si existen archivos o datos. Componentes de Big Data Estos componentes se utilizan principalmente para el procesamiento y análisis de grandes volúmenes de datos: SeaTunnel: Corresponde a la versión comercial de WhaleTunnel, utilizada para la integración y procesamiento de big data. AWS EMR: integración de Amazon EMR. HiveCli: tarea de línea de comandos de Hive. Chispa: Tarea de chispa. Flink: Tarea de Flink. DataX: Tarea de sincronización de datos. Componentes del contenedor Estos componentes se utilizan para ejecutar tareas en un entorno de contenedor: K8S: Tarea de Kubernetes. Componentes de calidad de datos Se utiliza para garantizar la calidad de los datos: DataQuality: Tarea de verificación de calidad de datos. Componentes interactivos Estos componentes se utilizan para interactuar con entornos de ciencia de datos y aprendizaje automático: Jupyter: tarea de Jupyter Notebook. Zeppelin: Tarea del cuaderno de Zeppelin. Componentes de aprendizaje automático Estos componentes se utilizan para la gestión y ejecución de tareas de aprendizaje automático: Kubeflow: tarea de Kubeflow. MlFlow: tarea MlFlow. Dvc: Tarea de control de versiones de datos. En general, Apache DolphinScheduler admite entre tres y cuatro docenas de componentes que abarcan áreas que van desde la ejecución de scripts y el procesamiento de big data hasta el aprendizaje automático. Para obtener más información, visite el para ver la documentación detallada. sitio web oficial Abstracción del tipo de tarea En Apache DolphinScheduler, los tipos de tareas se abstraen en múltiples modos de procesamiento para adaptarse a diversos entornos de ejecución y necesidades. A continuación presentamos en detalle el proceso de abstracción y ejecución de tipos de tareas. El trabajador es un servicio JVM implementado en un servidor. Para algunos componentes de script (como Shell y Python) y tareas ejecutadas localmente (como Spark Local), iniciarán un proceso independiente para ejecutarse. En este punto, el trabajador interactúa con estas tareas a través del ID de proceso (PID). Diferentes fuentes de datos pueden requerir diferentes adaptaciones. Para las tareas de SQL y procedimientos almacenados, hemos abstraído el manejo de diferentes fuentes de datos, como MySQL, PostgreSQL, AWS Redshift, etc. Esta abstracción permite una adaptación y expansión flexibles de diferentes tipos de bases de datos. se refieren a las tareas que se ejecutan en clústeres remotos, como AWS EMR, clústeres SeaTunnel, clústeres Kubernetes, etc. El Worker no ejecuta estas tareas localmente, sino que las envía a los clústeres remotos y monitorea su estado y mensajes. Este modo es especialmente adecuado para entornos de nube donde se requiere escalabilidad. Las tareas remotas Ejecución de tareas Recopilación de registros Los distintos complementos utilizan distintos modos de procesamiento y, por lo tanto, la recopilación de registros varía en consecuencia: Procesos locales: Se registran registros monitoreando la salida del proceso. Tareas remotas: los registros se recopilan verificando periódicamente el estado de la tarea y la salida del clúster remoto (por ejemplo, AWS EMR) y registrándolos en los registros de tareas locales. Sustitución de variable de parámetro El sistema analiza los registros de tareas para identificar las variables de parámetros que deben reemplazarse dinámicamente. Por ejemplo, la tarea A en el DAG puede generar algunos parámetros de salida que deben pasarse a la tarea B posterior. Durante este proceso, el sistema lee los registros y sustituye las variables de parámetros según sea necesario. Recuperando el ID de la tarea Procesos locales: se recupera el ID del proceso (PID). Tareas remotas: se recupera el ID de la tarea remota (por ejemplo, ID de tarea de AWS EMR). La conservación de estos identificadores de tareas permite realizar más consultas de datos y operaciones de tareas remotas. Por ejemplo, cuando se detiene un flujo de trabajo, se puede llamar a la API de cancelación correspondiente utilizando el identificador de tarea para finalizar la tarea en ejecución. Manejo de tolerancia a fallas Procesos locales: si un nodo de trabajo falla, el proceso local no lo sabrá y será necesario volver a enviar la tarea. Tareas remotas: si la tarea se ejecuta en un clúster remoto (por ejemplo, AWS), se puede verificar el estado de la tarea mediante el ID de la tarea y se puede intentar hacerse cargo de ella. Si la tarea se ejecuta correctamente, no es necesario volver a enviarla, lo que ahorra tiempo. Finalización de la ejecución de la tarea Después de ejecutar una tarea, se requieren varias acciones de finalización: Comprobación de finalización de la tarea: el sistema comprobará si es necesario enviar una alerta. Por ejemplo, en el caso de una tarea SQL, si los resultados de la consulta activan una alerta, el sistema interactuará con el servicio de alertas a través de RPC para enviar el mensaje de alerta. Retroalimentación del evento: el trabajador enviará el evento de finalización de la tarea (evento de finalización) al maestro. El maestro actualiza el estado de la tarea en la base de datos y procede con la transición del estado del DAG. Limpieza de contexto: el Worker eliminará de la memoria el contexto de tarea que se creó al inicio de la tarea. También limpiará las rutas de archivo generadas durante la ejecución de la tarea. Si está en modo de depuración (modo de desarrollo), estos archivos no se limpiarán, lo que permitirá la resolución de problemas de tareas fallidas. Mediante estos pasos se completa todo el proceso de ejecución de una instancia de tarea. Contribución de la comunidad Si está interesado en Apache DolphinScheduler y desea contribuir a la comunidad de código abierto, le invitamos a consultar nuestras pautas de contribución. La comunidad fomenta las contribuciones activas, que incluyen, entre otras: Informar problemas encontrados durante el uso. Envío de documentación y códigos PR. Agregar pruebas unitarias (UT). Agregar comentarios al código. Corregir errores o añadir nuevas funciones. Escribir artículos técnicos o participar en Meetups. Guía para nuevos colaboradores Los nuevos colaboradores pueden buscar problemas etiquetados como en los problemas de GitHub de la comunidad. Estos problemas suelen ser más simples y adecuados para los usuarios que realizan su primera contribución. good first issue En resumen, hemos aprendido sobre el diseño general de Apache DolphinScheduler y el proceso de ejecución detallado de las tareas de Worker. Espero que este contenido te ayude a comprender y utilizar mejor Apache DolphinScheduler. Si tienes alguna pregunta, no dudes en ponerte en contacto conmigo en la sección de comentarios.
