Fluxo de ar
O fluxo de ar é um componente de agendamento de tarefas, baseado principalmente no DAG (gráfico acíclico direcionado) para definir todo o fluxo de trabalho. Ele resolve principalmente a dependência de tarefas, serviço da web, suspensão de tarefas e outras funções que não podem ser concluídas pelo agendamento do crontab. E o fluxo de ar pode também suportar python, spark, hive, k8s etc.
-
arquitetura de fluxo de ar
O fluxo de ar contém os seguintes componentes:
Metadatabase (DAG de armazenamento)
Trabalhador atuador (responsável pela execução da tarefa)
Programador sheduler (responsável pelo acionamento da tarefa)
webServer (serviço da web)
-
princípio do agendamento de tarefas de fluxo de ar
O princípio da programação de multiprocessos de fluxo de ar é o seguinte:
Primeiro, o fluxo de ar criará um pool de processos DagFileProcessor para percorrer todos os arquivos dag na pasta dags. Cada processo processa um arquivo dag.O resultado é que DAGRUNS (o estado do gráfico) e taskInstance (instância de tarefa) são colocados no banco de dados. Marcado como na fila.
Ao mesmo tempo, o objeto da classe shedulerjob verifica periodicamente o banco de dados, coloca a taskInstance marcada como enfileirada na fila do Executor e marca o status da tarefa no banco de dados como Agendado
Cada Executor disponível pegará uma TaskInstance da fila do Executor para execução e marcará o status da tarefa no banco de dados como executando
Quando uma taskInstance é executada, o executor marcará o status da tarefa no banco de dados como (concluído, falhou, ignorado etc.) e processará cada tarefa sucessivamente, de acordo com a dependência da tarefa no gráfico.
Quando um processo termina de processar um dag, ele repete o processo acima para o próximo dag.
Quando todos os arquivos dag forem processados, o fluxo de ar entrará no próximo ciclo. Se o tempo de processamento de um dag for muito longo, o pool de processos ignorará esse dag no próximo ciclo para evitar o bloqueio.
-
Mecanismo de aipo do fluxo de ar:
O AeryExecutor é usado principalmente para expandir a escala de trabalhadores. Para usar esta função, você precisa configurar acessórios relacionados (RabbitMQ, REDIS, ...) e modificar a configuração relacionada do fluxo de ar no CeleryExecutor.
1. O servidor web busca logs de execução de tarefas dos trabalhadores
2. O servidor da Web obtém a estrutura Dag do arquivo Dag
3. O servidor da web obtém o status da tarefa do banco de dados
4. Os trabalhadores obtêm a estrutura do DAG e executam tarefas dos DAGFiles
5. Os funcionários obtêm e armazenam a configuração da conexão, variáveis e informações XCOM do DB
6. Os trabalhadores salvam o status da tarefa no aipo Result Backend
7. Os trabalhadores armazenam os comandos executados nos agentes de fila de aipo
8. O Agendador armazena o estado do gráfico e tarefas relacionadas no DB
9. O Agendador obtém a estrutura do DAG e executa tarefas dos DAGFiles
10. O Agendador obtém informações de status das tarefas concluídas no back-end do Aipo Result
11. O Agendador coloca os comandos a serem executados no Celery broker.
-
Criação de Dag de fluxo de ar
O dag do Airflow é criado através de um script python para definir as dependências entre as tarefas. Veja o exemplo criado abaixo como exemplo
Primeiro, é necessário introduzir o DAG e o BashOperator no pacote de fluxo de ar
Em seguida, crie um conjunto de dicionário de parâmetros
args = {
'proprietário': 'Fluxo de ar',
'data_início': airflow.utils.dates.days_ago (2),
}
'owner' se não especificado for padronizado como 'airflow'
Em seguida, crie um objeto dag
day = DAY (
dag_id = 'example_bash_operator',
default_args = args,
schedule_interval = '0 0 * * *',
dagrun_timeout = hora delta (minutos = 60),
)
dag_id é o único atributo que identifica dag. default_args define os parâmetros padrão de dag. 'schedule_interval' indica o intervalo de execução do dag. dagrun_timeout indica a configuração de tempo limite do dag. Falhou.
Criar tarefa
run_this_last = DummyOperator (
task_id = 'run_this_last',
dag = dag,
)
As tarefas são divididas em DummyOperator (), PythonOperator (), BashOperator (), etc. de acordo com diferentes operações, os usuários também podem personalizar o operador (). Instanciar parâmetros como task_id e dag. Aqui estão algumas tarefas definidas uma após a outra
# [START howto_operator_bash] run_this
= BashOperator (
task_id = 'run_after_loop',
bash_command = 'eco 1',
dag = dag,
)
# [END howto_operator_bash]
run_this >> run_this_last
para i no intervalo (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
As dependências entre tarefas são definidas por <<, >> entre cada tarefa, por exemplo também_run_esta >> run_this_last significa que também_run_esta execução run_this_last após a execução, o que equivale a run_this_last << also_run_this.
Ao mesmo tempo, você pode definir dependências por meio de set_upstream e set_downstream, como também_run_this.set_downstream (run_this_last), que também é equivalente a run_this_last.set_upstream (also_run_this).
Coloque o script criado acima na pasta dags padrão do fluxo de ar, o fluxo de ar examinará o dag e o executará automaticamente, ou você poderá acionar manualmente a execução do dag por meio da interface da linha de comandos (cli) ou webUI.
-
webUI de fluxo de ar
O Airflow possui uma poderosa página da Web que oferece suporte a tarefas como visualização de gráficos dag, visualização de gráficos em árvore, visualização de logs, visualização de código fonte, visualização de status de execução, pausa de tarefas e outras operações. Os detalhes são mostrados abaixo:
K8S
O K8s é uma arquitetura de microsserviço para agendamento de contêineres, que otimiza a execução de tarefas agendando pods. Sua arquitetura de distribuição é um ponto de controle de cluster e vários nós de trabalho, que resolvem principalmente o problema de correspondência de recursos entre pods e nós. Entre eles, o nó Mestre é responsável pelo gerenciamento de todo o cluster e fornece uma interface de gerenciamento para o cluster.
E monitore e organize cada nó de trabalho no cluster. Cada nó do trabalhador executa o contêiner na forma de um pod e cada nó precisa de um número de configuração para executar todos os serviços e recursos dos quais o contêiner depende.
programação do k8s
princípio de afinidade / anti_afinidade
Em alguns serviços que exigem interação frequente ou recursos comuns, alguns pods precisam ser implantados no mesmo nó ou no mesmo domínio, mas outros serviços precisam ser implantados em diferentes pontos ou regiões para garantir a segurança e a tolerância a desastres. As considerações comerciais acima levam às regras de implantação de afinidade e anti-afinidade.
node_affinity, ao gerar pods, você pode indicar que alguns pods precisam ser implantados em nós com um determinado rótulo.Por exemplo, alguns pods requerem operações rápidas de E / S e precisam ser implantados no disco rígido do ssd. Em seguida, o pod pode ser implantado no nó, caso contrário, não pode ser implantado com sucesso. Posteriormente, a versão aprimorada introduziu os conceitos de requisitos rígidos e requisitos flexíveis.Os requisitos rígidos são os mesmos que os anteriores.Requisitos flexíveis indicam que, se as condições forem melhores, elas poderão ser criadas com êxito se não forem atendidas.
Afinidade / anti_afinidade do pod significa verificar se há um pod com um determinado rótulo no nó ou no domínio antes da implantação. O escopo aqui é determinado pelo domínio de topologia definido do pod.
Mancha e tolerância
Alguns nós definiram taints, indicando que apenas pods com essas tags podem ser implantados; caso contrário, eles não podem ser implantados
O pod pode definir uma tolerância para corresponder ao nó.
