Flujo de aire
Airflow es un componente de programación de tareas, basado principalmente en DAG (gráfico acíclico dirigido) para definir todo el flujo de trabajo. Principalmente resuelve la dependencia de tareas, el servicio web, la suspensión de tareas y otras funciones que no pueden completarse mediante la programación de crontab. Y el flujo de aire puede ser compatible con python, spark, hive, k8s, etc.
-
arquitectura de flujo de aire
El flujo de aire contiene los siguientes componentes:
Metadatabase (DAG de almacenamiento)
Actuador trabajador (responsable de la ejecución de la tarea)
Programador planificador (responsable de la activación de tareas)
servidor web (servicio web)
-
principio de programación de tareas de flujo de aire
El principio de la programación multiproceso de flujo de aire es el siguiente:
Primero, airflow creará un grupo de procesos DagFileProcessor para atravesar todos los archivos dag en la carpeta dags. Cada proceso procesa un archivo dag. El resultado es que DAGRUNS (el estado del gráfico) y taskInstance (instancia de tarea) se colocan en la base de datos. Marcado como en cola.
Al mismo tiempo, el objeto de clase shedulerjob verificará periódicamente la base de datos, pondrá la TaskInstance marcada como en cola en la cola Ejecutor y marcará el estado de la tarea en la base de datos como Programada
Cada Ejecutor disponible tomará una TaskInstance de la cola Ejecutor para su ejecución y luego marcará el estado de la tarea en la base de datos como en ejecución
Cuando se ejecuta una taskInstance, el ejecutor marcará el estado de la tarea en la base de datos como (completado, fallido, omitido, etc.), y procesará cada tarea a su vez de acuerdo con la dependencia de la tarea del gráfico
Cuando un proceso termina de procesar un dag, repite el proceso anterior para el siguiente dag.
Cuando se procesen todos los archivos dag, el flujo de aire ingresará al siguiente ciclo. Si el tiempo de procesamiento de un dag es demasiado largo, el grupo de procesos ignorará este dag en el siguiente ciclo para evitar el bloqueo.
-
Mecanismo de apio del flujo de aire:
CeleryExecutor se utiliza principalmente para ampliar la escala de los trabajadores. Para utilizar esta función, debe configurar los accesorios relacionados (RabbitMQ, REDIS, ...) y modificar la configuración relacionada del flujo de aire a CeleryExecutor.
1. El servidor web obtiene registros de ejecución de tareas de los trabajadores
2. El servidor web obtiene la estructura Dag del archivo Dag
3. El servidor web obtiene el estado de la tarea del DB
4. Los trabajadores obtienen la estructura DAG y ejecutan tareas desde archivos DAG
5. Los trabajadores obtienen y almacenan la configuración de conexión, las variables y la información XCOM de DB
6. Los trabajadores guardan el estado de la tarea en apio Resultado Backend
7. Los trabajadores almacenan los comandos ejecutados en Apio Queue Brokers
8. El programador almacena el estado del gráfico y las tareas relacionadas en DB
9. El programador obtiene la estructura DAG y ejecuta tareas desde archivos DAG
10. El programador obtiene información del estado de las tareas completadas del backend de resultados de Celery
11. El programador coloca los comandos que se ejecutarán en el agente de apio.
-
Creación de Dag de flujo de aire
El dag de Airflow se crea a través de un script de python para definir las dependencias entre tareas. Tome el dag creado a continuación como ejemplo
Primero necesita introducir DAG y BashOperator en el paquete de flujo de aire
Luego cree un conjunto de diccionarios de parámetros
args = {
'propietario': 'Airflow',
'start_date': airflow.utils.dates.days_ago (2),
}
'propietario' si no se especifica, el valor predeterminado es 'flujo de aire'
Luego crea un objeto dag
day = DAY (
dag_id = 'example_bash_operator',
default_args = args,
schedule_interval = '0 0 * * *',
dagrun_timeout = hora delta (minutos = 60),
)
dag_id es el único atributo que identifica dag. default_args establece los parámetros predeterminados de dag. 'schedule_interval' indica el intervalo de ejecución del dag. dagrun_timeout indica la configuración de tiempo de espera de dag. Si dag no se completa después de este tiempo, se indicarán las tareas que no se ejecutan en dag. Falló
Crear tarea
run_this_last = DummyOperator (
task_id = 'run_this_last',
dag = dag,
)
Las tareas se dividen en DummyOperator (), PythonOperator (), BashOperator (), etc. de acuerdo con diferentes operaciones, los usuarios también pueden personalizar el operador (). Instanciar por parámetros como task_id y dag Aquí hay algunas tareas definidas una tras otra
# [START howto_operator_bash]
run_this = BashOperator (
task_id = 'run_after_loop',
bash_command = 'echo 1',
dag = dag,
)
# [END howto_operator_bash]
run_this >> run_this_last
para i in range (3):
task = BashOperator (
task_id = 'runme_' + str (i),
bash_command = 'echo "{{task_instance_key_str}}" && sleep 1',
dag = dag,
)
task >> run_this
# [ START howto_operator_bash_template]
also_run_this = BashOperator (
task_id = 'also_run_this',
bash_command = 'echo "run_id = {{run_id}} | dag_run = {{dag_run}}"',
dag = dag,
)
# [END howto_operator_bash_template]
also_run_this >> run_this_last
Las dependencias entre tareas están definidas por <<, >> entre cada tarea, por ejemplo also_run_this >> run_this_last significa que also_run_this ejecutará run_this_last después de que se ejecute, lo que equivale a run_this_last << also_run_this.
Al mismo tiempo, puede establecer dependencias a través de set_upstream y set_downstream, como also_run_this.set_downstream (run_this_last), que también es equivalente a run_this_last.set_upstream (also_run_this).
Coloque el script creado anteriormente en la carpeta de dags predeterminada de airflow, el flujo de aire escaneará el dag y lo ejecutará automáticamente, o puede activar manualmente la ejecución del dag a través de la interfaz de línea de comandos (cli) o webUI.
-
flujo de aire 的 webUI
Airflow tiene una página web poderosa que admite tareas como la visualización de gráficos de dag, visualización de gráficos de árbol, visualización de registros, visualización de código fuente, visualización del estado de ejecución, pausa de tareas y otras operaciones. Los detalles se muestran a continuación:
K8S
K8s es una arquitectura de microservicio para la programación de contenedores, que optimiza la ejecución de tareas mediante la programación de pods. Su arquitectura de distribución es un punto de control de clúster y múltiples nodos de trabajo, que resuelve principalmente el problema de la coincidencia de recursos entre pods y nodos. Entre ellos, el nodo maestro es responsable de la gestión de todo el clúster y proporciona una interfaz de gestión para el clúster.
Y supervise y organice cada nodo de trabajo en el clúster. Cada nodo de trabajo ejecuta el contenedor en forma de pod, y cada nodo necesita un número de configuración para ejecutar todos los servicios y recursos de los que depende el contenedor.
programación de k8s
Principio de afinidad / anti-afinidad
En algunos servicios que requieren interacción frecuente o recursos comunes, algunos pods deben implementarse en el mismo nodo o el mismo dominio, pero otros servicios deben implementarse en diferentes puntos o regiones para la seguridad y la tolerancia a desastres. Las consideraciones comerciales anteriores conducen a las reglas de implementación de afinidad y antiafinidad.
node_affinity, al generar pods, puede indicar que algunos pods deben implementarse en nodos con una determinada etiqueta. Por ejemplo, algunos pods requieren operaciones de E / S rápidas y deben implementarse en el disco duro del ssd. Si la etiqueta del nodo tiene disk_type: ssd, Luego, el pod se puede implementar en el nodo, de lo contrario no se puede implementar con éxito. Más tarde, la versión mejorada introdujo los conceptos de requisitos duros y requisitos blandos. Los requisitos duros son los mismos que los anteriores. Los requisitos blandos indican que si las condiciones son las mejores, se pueden crear con éxito si no se cumplen.
La afinidad de pod / anti_affinity significa verificar si hay un pod con una determinada etiqueta en el nodo o el dominio antes de la implementación. El alcance aquí está determinado por el dominio de topología definido del pod.
Mancha y tolerancia
Algunos nodos tienen manchas definidas, lo que indica que solo se pueden implementar pods con tales etiquetas, de lo contrario no se pueden implementar
El pod puede definir una tolerancia para que coincida con el nodo.
