Apache Airflow: maestro de pipelines de tarefas agendadas

Neste artigo, você irá conhecer um pouco sobre o que é e do que se trata a ferramenta que permite automatizar a execução de tarefas agendadas (scheduled tasks) de maneira inteligente e baseada em grafos acíclicos dirigidos (Directed Acyclic Graph, DAG).

Apesar de ser incrivelmente eficaz, o Airflow pode se tornar relativamente confuso para iniciantes (e algumas vezes até mesmo para usuários avançados) devido ao seu grande número de configurações e ampla versatilidade, que, consequentemente, acabam trazendo uma carga de complexidade a mais para o projeto. Por essas razões, este artigo tem como objetivo trazer um pouco de luz às definições iniciais do que a ferramenta é – e o que ela não é –, permitindo ao usuário compreender melhor quando este orquestrador lhe renderá uma bela sinfonia, e quando é melhor deixá-lo de lado.

O que o Airflow é?

O Apache Airflow é uma ferramenta de código aberto, escrita em python e desenvolvida pela Apache Foundation, seu objetivo é orquestrar pipelines de tarefas agendadas por meio de arquivos python com instruções de sequenciamento definidas, chamados DAGs. Pense nele como um versátil maestro, capaz de orquestrar diferentes músicas, de diversos tempos e com diferentes instrumentos de maneira igualmente ótima.

Para seu funcionamento, o Airflow conta com alguns elementos chave que permitem a existência da sinergia necessária entre tarefas, eventos, estados e filas, todos funcionando de maneira sincronizada e de acordo com configurações definidas pelo usuário. A Figura abaixo representa, de maneira relativamente simplificada e em uma mesma máquina (visto que é possível configurar o Airflow de maneira escalonável) a estrutura de uma instância da ferramenta:

Sendo assim, descrevendo de maneira também simplificada a funcionalidade e comportamento de cada elemento apresentado na Figura anterior:

• Airflow.cfg:
  Arquivo de configurações que descreve, principalmente, as conexões utilizadas para comunicação com o banco de dados de metadados da ferramenta, os intervalos de verificação de novos arquivos DAGs, e a frequência de atualização dos estados correntes de cada tarefa.
• Web Server:
  Sub-sistema responsável pela integração e execução de uma interface visual para o usuário. Aqui são apresentados graficamente a maior parte dos elementos que podem ser utilizados pelo usuário, como DAGs, logs, alertas, avisos e todo tipo de monitoramento do sistema.
• Scheduler:
  Este componente pode ser entendido como o “coração” do Airflow. No mundo musical, é possível comparar o Scheduler a um metrônomo, ou ao compasso que dá o tempo à música. Aqui, ele é responsável pela temporização do sistema, resultando na execução programada de DAGs, no agendamento de execução de tarefas individuais das DAGs e também da distribuição destas para diferentes Executors. Resumidamente, garantir o bom funcionamento deste componente faz parte de um grande diferencial para garantir o bom funcionamento do Airflow como ferramenta, já que faz a integração de quase todos os outros componentes/sub-sistemas.
• Metadata:
  Se o Scheduler pode ser considerado o “coração” do Airflow, então o banco de dados de metadados seria o “cérebro”. É neste elemento que são armazenadas todas as variáveis utilizadas por todos os outros componentes da ferramenta, desde usuários até retornos de tarefas. Faz uso de um banco de dados relacional que permite, inclusive, a troca de informação entre tarefas, principal causa de problemas de má utilização do Airflow, que serão discutidos no próximo capítulo.
• Executors:
  Sub-sistema responsável pela execução das tarefas programadas pelo Scheduler, que estão localizadas na fila (queue) deste sub-sistema (na atual representação). O Airflow permite a execução de diferentes tipos de tarefas através de operadores de diferentes naturezas, como o PythonOperator, para execução de scripts Python, o DockerOperator, para trabalho com containers do Docker ou até mesmo o BashOperator, para a execução de comandos bash. Essa versatilidade permite que cada tarefa possa ser executada isoladamente dentro do ambiente específico definido como Worker. Todas essas funções são definidas (para a arquitetura local apresentada) e executadas dentro de um Executor, que ao fim comunica com o banco de metadados para informar o retorno das ações.

Com a integração de todos esses componentes, o usuário é capaz então de escrever e programar a execução de diferentes conjuntos de tarefas acíclicas com uma imensa variedade de possibilidades para a execução de cada tarefa, que vão desde interpretadores Python, containers Docker e até mesmo comandos bash.

O que o Airflow não é

Após as definições dos componentes que integram o Airflow, é possível que o leitor esteja imaginando diferentes tipos de fluxo de trabalho, com inúmeras aplicações e a possibilidade de processar dados quase que de forma irrestrita. Este capítulo se faz ainda mais importante para este caso, visto que uma limitação extremamente importante foi apresentada indiretamente no capítulo anterior mas que pode ter passado despercebida: o Airflow não é um processador de dados e não pode ser utilizado para sequências indefinidamente cíclicas de tarefas. Trazendo ao leitor novamente a analogia musical, seu maestro até pode ser um grande multi-instrumentista, mas acaba sendo impossível orquestrar a música e efetivamente tocar seus instrumentos simultaneamente.

O problema de processamento de dados nesta ferramenta pode ser mais facilmente compreendido através da explicação mais minuciosa do funcionamento da transferência de dados entre tarefas. A transferência de dados entre tarefas é feita através de um componente chamado Xcom, que nada mais é do que a abstração de acesso, leitura e escrita de dados no banco de dados do Airflow. Ou seja, para cada leitura/escrita desse banco de dados, é necessário fazer uma conexão e executar uma nova operação no banco, que, para grandes quantidades de dados, pode acabar resultando em problemas de consulta para outras DAGs ou tarefas que estejam sendo executadas simultaneamente. Por esse motivo, é indicado que o processamento de dados seja feito externamente ao Airflow, utilizando Xcoms apenas para a troca de pequenas informações entre tarefas, como metadados.

Já o problema de execução de tarefas indefinidamente cíclicas se dá pela maneira que os diferentes componentes e sub-sistemas dentro do Airflow se comunicam. É esperado que um bloco de tarefas (DAG) tenha um início bem definido e programado temporalmente, que em seguida irá executar suas tarefas de forma sequencial ou paralela até que chegue a um fim determinado, atualizando assim o estado da execução desse conjunto de tarefas com a condição final do mesmo (sucesso ou falha). Por esse motivo, e para evitar que usuários tentem executar tarefas indefinidamente, o Airflow utiliza e deixa tão claro o conceito de grafos acíclicos dirigidos.

Conclusão

Após essas descrições, espera-se que o leitor tenha conseguido esclarecer um pouco mais os conceitos que constituem essa poderosa ferramenta de automação de tarefas nominada Airflow. Ao mesmo tempo, espera-se também que tenha surgido o interesse em experimentar a utilização desta ferramenta e começar a escrever suas próprias “sinfonias”, ao ponto de que o leitor esteja se perguntando em como fazê-lo. Como demonstrado, o Airflow pode ser relativamente complexo para utilização, e não seria diferente para sua instalação e configuração, portanto, não deixe de conferir os próximos artigos se tiver interesse em se aprofundar no uso deste incrível orquestrador, começando por este: Organizando o palco: instalando e configurando o Apache Airflow localmente.