Olá, muito obrigado por assistir aos vídeos do canal e compartilhar a sua dúvida. Vamos ver se consigo ajudar... O execution_timeout é um parâmetro que existe em todas as tasks do Airflow. Este parametro serve para gerar um erro caso a tarefa fique em execução além do tempo configurado. O poke_interval é um parâmetro em que a tarefa irá tentar executar o comando novamente após o tempo em que foi configurado. Por padrão, o Airflow já vem com todas as tarefas configuradas com o execution_timeout com o valor nulo, ou seja, nunca vai dar timeout, mas se você configurar este parâmetro com algum valor, ai sim teremos a validação de sucesso ou erro por timeout. Em breve devo colocar um vídeo explicando e mostrando o uso do execution_timeout. Espero ter ajudado. Forte Abraço.
Ótimo conteúdo! Teria como disponibilizar o restante das pastas como o airflow-2.6.1, config e old para verificar o que você acrescentou? Pois de uma aula para outra eles apareceram e não foram explicados
Olá! muito obrigado por assistir aos vídeos. Fico muito feliz em saber que estou ajudando. não se preocupe com estas pastas que comentou, pois foram teste e outras instalações que fiz. Quando instalado o Airflow são criadas as pastas: - config (o próprio Airflow cria ela com os arquivos de configuração para ele rodar) - dags (diretorio aonde ficam salvas as DAGs) - logs (logs das execuções das DAGs e das Tasks e também de alguns serviços do Airflow) - plugins (diretório "especial" no Airflow para instação de plugins e bibliotecas reutilizaveis, que você mesmo pode criar) Espero ter ajudado. Forte Abraço
Olá André, tudo bem? Conheci seu canal ontem e estou assistindo seus videos sobre o Airflow. Queria ver se você consegue me ajudar com uma coisa. Vejo muitos videos do Airflow sempre mostrando task1 >> task 2. Se eu quiser que ao final da task1 rodem a task2 e a task3 em paralelo, como sinalizar isso? Além disso, existe alguma forma de dizer na dag que se alguma task falhar, o processo não deve ser abortado? Muito obrigado pelos seus videos!
Olá Marcelo! Muito obrigado pelo comentário. Espero que os vídeos estejam ajudando nos seus estudos. Conheço duas formas bem simples de colocar as tarefas para rodar em paralelo. Primeira (colocando as tarefas 2 e 3 em forma de lista): task1 >> [task2, task3] >> task4 Segunda (colocando cada dependência individualmente): task1 >> task2 task1 >> task3 task2 >> task4 task3 >> task4 Particularmente eu prefiro a primeira, mas tudo depende de como está organizando o seu código. Sobre o processo não abortar em caso de falha de alguma task, é possivel fazer uso de um recurso da versão mais nova: airflow.apache.org/docs/apache-airflow/stable/howto/setup-and-teardown.html Outra forma de executar tarefas é fazendo uso de outros operadores que possibilitam uma configuração do tipo "roteador": BaseBranchOperator airflow.apache.org/docs/apache-airflow/stable/_api/airflow/operators/branch/index.html#airflow.operators.branch.BaseBranchOperator ShortCircuitOperator airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html#shortcircuitoperator Mas é preciso entender com detalhes a sua necessidade para ver qual se adapta melhor. Logo devo gravar um vídeo com estas dicas. Espero ter ajudado. Forte Abraço
Ola@@andre_ricardo , muito obrigado pela resposta. Concordo que a primeira opção é mai simples. Porém, se a task4 não depender da task3 (apenas da task2), creio que a segunda solução atenderia, certo?
@@andre_ricardoOlá, André. Neste exemplo que você citou task1 >> [task 2, 3, 4] >> task5 Consigo colocar sensores para passar para a task5 apenas depois que a lista da 2 a 4 finalizar? E outra consigo fazer o controle de todas as dags só utilizando o Python da primeira, inclusive sensor trigger? Para no gráfico ter todo o caminho do processo task1 >> [task 2, 3, 4] >> [sensor 2, 3, 4] >> task5
@@andre_ricardooutra dúvida, tô testando da seguinte maneira: Tenho 3 dags e 3 Python Na dag1 Tem a trigger que chama a dag 2 Sensor da dag 2 e a trigger chamando a dag 3 Ou seja, Python da dag1: Querys_dag1 >> trigger-dag2 >> sensor_dag2 >> trigger-dag3 Python da dag 2 Querys_dag2 >> fim_dag2 Python da dag 3 Querys_dag3 >> fim_dag3 O sensor não identifica o fim da dag2 para passar para a dag3. Muito parecido com seu exemplo antes de você acertar o horário, porém aqui aparentemente não deu certo
Parabéns pela aula Ricardo!!
Obrigado Rodrigo!
Muito obrigado pela aula !
Olá! Eu que agradeço por assistir aos vídeos.
Forte Abraço.
Ótimo conteúdo!
Obrigado 😃
André, se eu coloco o execution_timeout junto com o poke_interval, nunca dará timeout?
Olá, muito obrigado por assistir aos vídeos do canal e compartilhar a sua dúvida. Vamos ver se consigo ajudar...
O execution_timeout é um parâmetro que existe em todas as tasks do Airflow.
Este parametro serve para gerar um erro caso a tarefa fique em execução além do tempo configurado.
O poke_interval é um parâmetro em que a tarefa irá tentar executar o comando novamente após o tempo em que foi configurado.
Por padrão, o Airflow já vem com todas as tarefas configuradas com o execution_timeout com o valor nulo, ou seja, nunca vai dar timeout, mas se você configurar este parâmetro com algum valor, ai sim teremos a validação de sucesso ou erro por timeout.
Em breve devo colocar um vídeo explicando e mostrando o uso do execution_timeout.
Espero ter ajudado.
Forte Abraço.
Ótimo conteúdo! Teria como disponibilizar o restante das pastas
como o airflow-2.6.1, config e old para verificar o que você acrescentou? Pois de uma aula para outra eles apareceram e não foram explicados
Olá! muito obrigado por assistir aos vídeos. Fico muito feliz em saber que estou ajudando.
não se preocupe com estas pastas que comentou, pois foram teste e outras instalações que fiz.
Quando instalado o Airflow são criadas as pastas:
- config (o próprio Airflow cria ela com os arquivos de configuração para ele rodar)
- dags (diretorio aonde ficam salvas as DAGs)
- logs (logs das execuções das DAGs e das Tasks e também de alguns serviços do Airflow)
- plugins (diretório "especial" no Airflow para instação de plugins e bibliotecas reutilizaveis, que você mesmo pode criar)
Espero ter ajudado.
Forte Abraço
Olá André, tudo bem? Conheci seu canal ontem e estou assistindo seus videos sobre o Airflow. Queria ver se você consegue me ajudar com uma coisa. Vejo muitos videos do Airflow sempre mostrando task1 >> task 2. Se eu quiser que ao final da task1 rodem a task2 e a task3 em paralelo, como sinalizar isso? Além disso, existe alguma forma de dizer na dag que se alguma task falhar, o processo não deve ser abortado? Muito obrigado pelos seus videos!
Olá Marcelo! Muito obrigado pelo comentário. Espero que os vídeos estejam ajudando nos seus estudos.
Conheço duas formas bem simples de colocar as tarefas para rodar em paralelo.
Primeira (colocando as tarefas 2 e 3 em forma de lista):
task1 >> [task2, task3] >> task4
Segunda (colocando cada dependência individualmente):
task1 >> task2
task1 >> task3
task2 >> task4
task3 >> task4
Particularmente eu prefiro a primeira, mas tudo depende de como está organizando o seu código.
Sobre o processo não abortar em caso de falha de alguma task, é possivel fazer uso de um recurso da versão mais nova:
airflow.apache.org/docs/apache-airflow/stable/howto/setup-and-teardown.html
Outra forma de executar tarefas é fazendo uso de outros operadores que possibilitam uma configuração do tipo "roteador":
BaseBranchOperator airflow.apache.org/docs/apache-airflow/stable/_api/airflow/operators/branch/index.html#airflow.operators.branch.BaseBranchOperator
ShortCircuitOperator airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html#shortcircuitoperator
Mas é preciso entender com detalhes a sua necessidade para ver qual se adapta melhor.
Logo devo gravar um vídeo com estas dicas.
Espero ter ajudado.
Forte Abraço
Ola@@andre_ricardo , muito obrigado pela resposta. Concordo que a primeira opção é mai simples. Porém, se a task4 não depender da task3 (apenas da task2), creio que a segunda solução atenderia, certo?
@@andre_ricardoOlá, André. Neste exemplo que você citou task1 >> [task 2, 3, 4] >> task5
Consigo colocar sensores para passar para a task5 apenas depois que a lista da 2 a 4 finalizar? E outra consigo fazer o controle de todas as dags só utilizando o Python da primeira, inclusive sensor trigger? Para no gráfico ter todo o caminho do processo
task1 >> [task 2, 3, 4] >> [sensor 2, 3, 4] >> task5
@@andre_ricardooutra dúvida, tô testando da seguinte maneira:
Tenho 3 dags e 3 Python
Na dag1
Tem a trigger que chama a dag 2
Sensor da dag 2 e a trigger chamando a dag 3
Ou seja,
Python da dag1:
Querys_dag1 >> trigger-dag2 >> sensor_dag2 >> trigger-dag3
Python da dag 2
Querys_dag2 >> fim_dag2
Python da dag 3
Querys_dag3 >> fim_dag3
O sensor não identifica o fim da dag2 para passar para a dag3. Muito parecido com seu exemplo antes de você acertar o horário, porém aqui aparentemente não deu certo
@@andre_ricardoa dag 3 que é dependente da dag 2 eu preciso alterar o horário para ficar diferentes e indicar essa diferença dentro do tasksensor?