| Data de elaboração | 28/06/2023 |
| Autor | João Thomas de Souza Telles |
| Equipe do estudo | Time Auto |
| Documentação correlata | Artigos sobre Apache Airflow |
¶ Por que precisamos do Airflow?
A SETIC consta com um ambiente de desenvolvimento de ETLs extremamente diverso e instável, tendo em vista alterações e situações passadas. Temos ETLs rodando simultâneamente em SQL, PDI e alguns até mesmo em C#. Essa descentralização de onde e como são realizados os ETLs é um problema crucial no avanço da maturidade do time de Engenharia de Dados, e também gera diversos problemas de monitoramento e sincronização.
Dessa forma foi necessário encontrar alguma ferramenta que possibilitasse a centralização dos nossos ETLs ou ao menos um agendamento sincronizado, de modo a monitorar e visualizar eles com mais efetividade.
A SETIC também apresenta empecilhos com relação a licenciamento, uma vez que é difícil justificar os custos de software encontrados no mercado. Dessa forma optou-se por procurar alternativas open-source, e foi encontrado o Apache Airflow como alternativa primária.
¶ Conhecendo o ecossistema Airflow:
O Apache Airflow é um software de automação e orquestração de fluxos de trabalho, funcionando com a lógica de DAGs (Directed Acyclic Graphs) para visualizar e executar estes trabalhos.
Na SETIC ele era mantido através de conteinerização com Docker, e pode-se encontrar documentações sobre como conteinerizá-lo aqui.
Atualmente ele está em Kubernetes, e em breve iremos atualizar a documentação(data do comentário: 27/10/2023)
¶ Como simplificamos o uso do Airflow:
Tendo em vista o uso persistente da plataforma Airflow no desenvolvimento de ETLs, e a situação da conteinerização da ferramenta, tornou-se crucial uma automação para buscar e atualizar as dags do airflow, seguindo os princípios de CI/CD.
¶ O problema:
O Airflow não provê nem prevê nenhum método pronto de atualização das dags que ele executa. Dessa forma fica a critério do desenvolvedor descobrir ou desenvolver uma solução que automatize esse fluxo.
¶ Soluções possíveis:
1 - Utilizar um bucket para sincronizar os arquivos de maneira instantânea
2 - Utilizar um servidor NFS para o mesmo propósito
3 - Utilizar de um repositório git para manter as DAGs, e então o sincronizar através de uma DAG.
4 - Automatizar o envio de arquivos de maquinas locais dos desenvolvedores para o Airflow, e então do Airflow para as máquinas dos desenvolvedores.
¶ Solução adotada:
Utilizar um bucket ou servidor NFS pareceu uma alternativa interessante de princípio, porém logo se encontrou um problema, que é o mesmo da alternativa 4 das soluções possíveis: como enviar os arquivos de máquinas locais para a máquina do Airflow? Como manter histórico de alterações?
Tendo em vista essas perguntas acima, foi preferido a alternativa de criar um repositório git, contendo todos os arquivos necessários para o funcionamento das DAGs, que dentro dele mesmo teria uma DAG que realiza git pull, assim garantindo a atualização das demais DAGs no Airflow. Esse método também facilita para o desenvolvedor, já que com um simples git commit + git push torna-se possível atualizar as DAGs, e para se manter atualizado basta um git pull/fetch.
Código fonte de como sincronizar as DAGs via Git:
from datetime import datetime
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
with DAG(
'ATUALIZAR_dags',
schedule_interval='*/5 * * * *',
start_date=datetime(2021, 10, 1),
tags=['atualizar_dags'],
catchup=False,
) as dag:
# Se der certo, o git vai buscar auto.
git_pull_airflow = BashOperator(
task_id="git_pull_airflow",
bash_command="""
cd /opt/airflow && git stash && git config --global --add safe.directory /opt/airflow && git pull
""",
)
git_pull_airflow
¶ Como customizamos o Airflow:
O Airflow, por mais completo que seja, não possui alguns dos pacotes necessários para o funcionamento na estrutura SETIC, mais especificamente pacotes de provedores de conexão; O Airflow não vem com provedores para a maioria dos SGBDs que a SETIC utiliza.
Sendo assim optou-se por realizar uma extensão do Dockerfile pronto do Airflow, adicionando os pacotes via pip install, da seguinte maneira:
FROM apache/airflow:2.x.x
USER airflow
RUN pip install apache-airflow-providers-odbc \
&& pip install apache-airflow-providers-microsoft-mssql \
&& pip install apache-airflow-providers-microsoft-azure \
&& pip install pypdf\
&& pip install apache-airflow-providers-mysql \
&& pip install pymysql
Dessa forma, basta utilizar a configuração padrão encontrada aqui alterando o nome da imagem encontrado no docker-compose.yaml para o nome escolhido no comando abaixo:
docker build -t airflow -f Dockerfile . --no-cache
Após essas configurações, também foram alteradas as variávies AIRFLOW__DATABASE__SQL_ALCHEMY_CONN, AIRFLOW__CORE__SQL_ALCHEMY_CONN e AIRFLOW__CELERY__RESULT_BACKEND do .yaml para refletir um ambiente de produção, e não de teste.
¶ O Problema do Airflow:
Por mais que a ferramenta proveja um ambiente visualmente simples e de fácil desenvolvimento inicial, ele acaba por ser desnecessariamente complexo para o desenvolvimento de alguns dos ETLs construídos na SETIC. Primariamente em conta do Python e do framework Pandas, alguns tipos de ETL ou ELT realizados acabam por gerar códigos muito complicados ou de difícil compreensão para os criadores de ETL, que nativamente não são desenvolvedores Python.
Dessa forma foi realizada uma busca por uma ferramenta que fosse capaz de operar juntamente com o Apache Airflow de modo a simplificar o desenvolvimento de ETL da SETIC. Após um período extenso de busca, foi encontrada a plataforma Apache Hop, desenvolvida pelos mesmos criadores do Pentaho Data Integration, e que além de open-source, já possui integração prevista com o Apache Airflow.
Para saber mais sobre como foi integrado o Apache Hop no Apache Airflow da SETIC, consulte esse artigo e esse.