Seis verdades inconvenientes sobre o Apache Airflow (e o que fazer em relação a elas)

As equipes de dados que trabalham com processos de ingestão complexos adoram o Apache Airflow.

Você pode definir seus fluxos de trabalho em Python, o sistema tem ampla extensibilidade e oferece uma variedade saudável de plug-ins. 86% de seus usuários dizem que estão felizes e planejam continuar usando-o em vez de outros mecanismos de fluxo de trabalho. Um número igual diz que recomenda o produto.

Mas, como todo software, e especialmente o tipo de código aberto, o Airflow é atormentado por uma série de lacunas e deficiências que você precisará compensar. Para os desenvolvedores que estão se familiarizando com ele, isso significa que o início é lento e o avanço é difícil. Neste artigo, discutimos esses problemas e algumas soluções possíveis.

O Airflow é um trabalhador incansável com vendas. Ele não faz nada para corrigir o curso se algo der errado com os dados, apenas com o pipeline. Praticamente todos os usuários já passaram por alguma versão do Airflow informando que um trabalho foi concluído e verificando os dados apenas para descobrir que faltava uma coluna e tudo estava errado, ou que nenhum dado realmente passou pelos sistemas.

Isso é especialmente verdadeiro quando a organização de dados amadurece e você passa de 10 gráficos acíclicos de dados (DAGs) para milhares. Nessa situação, você provavelmente está usando esses DAGs para ingestão de dados de fontes de dados externas e APIs, o que torna ainda mais difícil o controle da qualidade de dados no Airflow. Não é possível "limpar" o conjunto de dados de origem nem implementar suas políticas de controle nele.

Embora você possa criar alertas no Slack para verificar manualmente cada execução, incorporar o Airflow como uma parte útil da sua organização de engenharia de dados e atingir seus SLAs, você quer automatizar as verificações de qualidade. E para isso, é necessário ter visibilidade não apenas sobre se um trabalho foi executado, mas se foi executado corretamente. E se não foi executado corretamente, por que e onde o erro se originou. Caso contrário, você estará vivendo o Dia da Marmota.

Esse não é um desafio simples e, se estamos sendo sinceros, é por isso que o IBM Databand foi criado. A maioria das ferramentas de observabilidade de produto, como Datadog e New Relic, não foi criada para analisar pipelines e não consegue isolar onde os problemas se originaram, agrupar ocorrências simultâneas para sugerir uma causa raiz ou indicar possíveis correções

No entanto, a necessidade de observabilidade ainda não é totalmente compreendida, mesmo dentro da comunidade do Airflow. Hoje, apenas 32% dizem que implementaram a medição da qualidade de dados, embora o fato de os redatores da pesquisa estarem perguntando seja uma indicação de melhoria. Eles não fizeram essa pergunta nas pesquisas de 2019 ou 2020.

Como se monitora a qualidade de dados no Airflow? Na verdade, o Airflow leva você a meio do caminho. Como seus mantenedores apontam, "Quando os fluxos de trabalho são definidos como código, eles se tornam mais sustentáveis, versionáveis, testáveis e colaborativos."

O Airflow oferece essa representação formal do código. Você precisa de uma ferramenta de observabilidade criada especificamente para monitorar pipelines de dados. Aquelas criadas para monitorar produtos são uma medida intermediária, mas geralmente fazem parte do processo porque já possuem essas licenças.

Identificamos que existem várias fases pelas quais as organizações de engenharia passam em sua jornada rumo à plena maturidade de observabilidade:

• Pré-consciência: não monitorar a qualidade dos dados (68% da comunidade Airflow).
• Gambiarra estruturada: emprestar ferramentas de observabilidade de produto e fazê-las funcionar, embora não seja o ideal.
• Solução criada para esse fim: adotar ferramentas de observabilidade de pipeline de ponta a ponta, como o Databand, para automatizar alertas, isolar causas raiz e corrigir problemas mais rapidamente. Definir aprendizado de máquina em torno de parâmetros esperados dos dados, receber alertas no Slack indicando dados ausentes ou alterações de esquema no Airflow Scheduler, rastrear a linhagem do problema e fazer back-testing através de dados históricos.

Aprender o Airflow requer um investimento de tempo. Inúmeros artigos e encadeamentos do Stack Overflow documentam as dificuldades de desenvolvedores que ficam presos a questões básicas, como: "Por que o trabalho que agendei não começou?" (Uma resposta comum: o Airflow Scheduler começa a agendar no final do período programado, não no início. Mais sobre isso depois).

Além disso, para se tornar competente com o Airflow, você precisará aprender Celery Executor e RabbitMQ ou Redis, e não há como evitar isso.

Esse atrito é suficiente para que algumas organizações, como a empresa de software CMS Bluecore,decidiram que era mais fácil codificar essencialmente sua própria interface do Airflow. Dessa forma, cada novo desenvolvedor contratado ou designado não precisaria aprender todos os novos operadores e, em vez disso, poderia confiar nos Kubernetes com os quais já estava familiarizado.

Esses obstáculos de aprendizado são um problema recorrente o suficiente para a comunidade que "problemas de integração" justificou sua própria pergunta na pesquisa da comunidade do Airflow de 2021 (imaginada abaixo).

Entre as principais reclamações dos usuários estavam "a falta de melhores práticas no desenvolvimento de DAGs" e "não há uma opção fácil de lançamento". Esta última questão foi parcialmente abordada no Airflow Versão 2.0 (que foi lançada após a pesquisa), mas esta versão é executada em um banco de dados SQLite onde nenhuma paralelização é possível e tudo acontece sequencialmente.
Como aponta o guia de início rápido do Airflow, "isso é muito limitante" e "você deve superar muito rapidamente".

O caso de uso principal do Airflow é agendar lotes periódicos, não execuções frequentes, como até mesmo sua própria documentação atesta: "Espera-se que os fluxos de trabalho sejam em sua maioria estáticos ou de mudança lenta." Isso significa que há poucos recursos para quem precisa coletar amostras ou enviar dados de forma ad hoc e contínua, o que os torna menos ideais para alguns casos de uso de ETL e ciência de dados.

Tem mais. Já mencionamos isso antes, mas o Airflow Scheduler executa os jobs de schedule_interval no final do intervalo inicial do Scheduler, e não no começo. Isso significa que você fará muito mais “contas de bolso” do que gostaria e, ocasionalmente, poderá ser pego de surpresa.

E para executar adequadamente esses trabalhos agendados, você precisará aprender as nuances específicas do Airflow entre operadores e tarefas, como os DAGs funcionam, argumentos padrão, banco de dados de metadados do Airflow, o diretor inicial para implementação de DAGs e assim por diante.

A solução? Você pode considerar se juntar aos 6% de usuários do Airflow que desenvolvem sua própria interface gráfica e renomeiam os operadores em termos que façam mais sentido para eles.

Você vai encontrar muitas práticas tradicionais de desenvolvimento de software e DevOps ausentes do Airflow, e uma grande delas é a capacidade de manter versões dos seus pipelines. Não há uma maneira fácil de documentar tudo o que você criou e, se necessário, reverter para uma versão anterior. Se, por exemplo, você excluir uma tarefa do seu DAG e reimplementá-la, perderá os metadados associados na instância da tarefa.

Isso torna o Airflow um tanto frágil e, a menos que você tenha escrito um script para capturar isso por conta própria, isso torna os problemas de depuração muito mais difíceis. Não é possível realizar o backtest de possíveis correções em relação a dados históricos para validá-las.

Novamente, o Airflow fornece a representação formal do código. Seu desafio é aplicar outras ferramentas de desenvolvimento de software e DevOps para preencher a funcionalidade que falta.

Não há muito mais a dizer aqui. A menos que você use arquivos de Docker compose específicos que não fazem parte do repositório principal, isso não é possível.

O agendador do Airflow não está funcionando? É melhor reabastecer seu café. Você pode ter alguma depuração demorada pela frente.

Isso ocorre porque, em nossa opinião, o Airflow não distingue suficientemente entre operadores que orquestram e operadores que executam. Muitos operadores fazem ambas as coisas. E, embora isso possa ter ajudado na codificação inicial da plataforma, é uma inclusão fatal que dificulta muito a depuração. Se algo der errado, seus desenvolvedores terão que examinar primeiro os parâmetros do DataFlow e, em seguida, o próprio operador, todas as vezes.

Por esse motivo, ferramentas como o Databand podem ser de grande ajuda. O Databand é excelente para ajudar você a entender a integridade da sua infraestrutura em todos os níveis: Airflow global, DAG, tarefa e voltado para o usuário. Em vez de gastar tempo de engenharia de dados aprendendo sobre recursos altamente específicos, o Databand permite que os engenheiros de dados realmente se concentrem na solução de problemas do negócio.

Como qualquer colaborador de código aberto que dedica tempo para propor novas mudanças, esperamos que este artigo seja interpretado como o comentário de amor que é. Nós aqui na Databand somos colaboradores ativos da comunidade do Airflow e estamos ansiosos para vê-lo crescer além de suas limitações existentes e para atender melhor a mais casos de uso de ETL e ciência de dados.

Como dissemos anteriormente, 86% dos usuários planejam mantê-lo em detrimento de outros mecanismos de operação. Outros 86% afirmam que é altamente recomendável. Estamos felizes em dizer que pertencemos aos dois grupos - é uma ótima ferramenta. E para aqueles que estão se familiarizando com o Airflow, saibam que, se já tiverem em mente os problemas mencionados acima, o esforço do Airflow Scheduler pode valer a pena. Veja como o Databand reúne todas as suas atividades de observabilidade do Airflow para simplificar e centralizar sua observabilidade do Apache Airflow. Se você está pronto para fazer uma análise mais detalhada, agende uma demonstração hoje mesmo.