9.3 Airflow

9.3.1 História

A Airbnb iniciou como startup e tomou proporções globais, o que gerou uma complexidade na orquestração dos fluxos de dados. Em 2014 iniciou a criação do Airflow para facilitar a coordenação, publicado em 2015.

Publicação de 2015 no medium da Airbnb por Maxime Beauchemin

Desde a publicação a ferramenta ganhou força e foi incubada pela Apache Foundation em 2016.

9.3.2 Arquitetura

Os principais componentes do Airflow são:

  • Scheduler: Responsável por agendar a execução das DAGs

  • WebServer: WebUI para manipulação dos metadados e DAGs

  • Workers: Responsável pela execução dos processos

  • Metadata databases: Responsável por armazenar os metadados do Airflow

  • Dag Directory: Contém os arquivos de DAGs

Diagrama de arquitetura do Airflow

Os workflows do Airflow são representados por DAGs.

DAG

9.3.3 Preparando container com Airflow

Para preparar as configurações do Airflow crie uma pasta serving-batch/airflow.

Vamos usar o Airflow standalone para fins didáticos. Para implementações em produção, usar a documentação oficial.

O arquivo de docker-compose.yaml nos ajuda a gerir os containers. Neste exemplo vamos criar um volume para as DAGs e os modelos. Copie o modelo joblib na pasta model do Airflow.

O arquivo de requirements.txt segue as mesmas versões das bibliotecas que usamos no Spark. Repare que também incluímos o plugin do Apache Livy do Spark que será utilizado para integrar o Spark com o Airflow.

Inicialize o Airflow com o docker-compose e verifique a WebUI na url localhost:8080. Com a WebUI é possível acompanhar e operar as execuções das DAGs. Explore a documentação da WebUI para o aprofundamento.

O exemplo a seguir traz a utilização do Bash Operator, operador do Airflow que executa um comando Bash nos Workers do Airflow.

Faça teste com a dependência entre as Tasks e os TaskGroups e veja o resultado na WebUI do Airflow.

O Scheduler do Airflow tem vários recursos de periodicidade e triggers de execução.

Explore a documentação de parametrização das DAGs, altere o pipeline e veja o resultado na WebUI.

Vamos explorar o Python Operator.

Inclua a seguinte função na sua DAG:

O decorator @task indica que esta função é uma task do Airflow.

Inclua ela no fim como tarefa5 e veja o resultado:

Repare que a função é executada e o contexto da DAG é apresentado no log das tasks.

Agora que já sabemos como orquestrar um comando Python em uma DAG, vamos simular a inferência do modelo em uma Task Python.

Inclua essa task no final da sua DAG como Task6 e veja que é possível executar a inferência dentro de uma Tarefa Python no Airflow. Explore o código para ler de arquivos externos, executar a inferência e gravar o resultado em um arquivo de saída.

9.3.4 Data-aware scheduling

É possível controlar dependência entre DAGs via Task Sensor ou desde a versão 2.4, quando o conceito de Dataset foi criado, é possível ter o mesmo resultado com Data-aware scheduling.

Com este novo conceito uma DAG pode depender de um Dataset para ser iniciada e as tasks dentro de uma DAG podem gerar versões de Datasets. Assim é possível ter dependência entre DAGs e uma visão parcial de Data Lineage na interface de Dataset.

Vamos gerar duas novas DAGs de teste para visualizarmos esta dependência:

Last updated