Sistemas Gerenciadores de Workflow
Problemas com Airflow, alternativas e direções
Trabalhei 2 anos criando e mantendo uma infra com Airflow, Flower e Celery na Globo.com. Lá nós precisávamos de 39 instâncias de Celery para executar 100 jobs do Airflow e mesmo assim eles sempre atrasavam para começar a rodar. Isso e outros problemas já me fizeram perceber que tinha algo errado com ele. Seguem alguns:
- Agendador travava e tivemos que fazer um projeto ressuscitador de Airflow para que agendador voltasse a funcionar
- Terrível gerenciamento de log já travou o Airflow inteiro algumas vezes quando o banco de dados ia ficando grande. Ele guardava cada histórico de DAG executada lá. Tivemos que criar rotina de expurgo de histórico
- O processo de aceitar um Pull Request e lançar uma versão era tão lento que tivemos que criar um fork interno com releases internos. Agora parece que estão mais organizados com isso
- Fizemos tantos Operators, Sensors e bibliotecas facilitadoras que tinha mais código pra manter o workflow funcionando do que em muitos dos jobs que ele submetia
Atualmente tenho trabalhado bastante no doutorado no BioBD com Sistemas Gerenciadores de Workflow (SGWf) e fico incomodado com o Airflow se chamando de SGWf. Concordo que ele possa ser usado para várias coisas, mas ele vai contra vários padrões de SGWf e trata muitas coisas na gambiarra:
- Não tem versionamento de Fluxos (DAGs)
- Ele é todo baseado em agendamento e tem tudo baseado em datas. O agendador é obrigatório ou preciso tacar um None lá
- Agendador faz TUDO e vira e mexe algum job atrasa porque não escala
- Dependência externa ou aprovação manual? Nem pensar, vai ficar fazendo polling pra ver se o arquivo ou recurso existe com Sensor até dar timeout. Detalhe que essa gambiarra tem que ficar dentro do workflow
- Cache de tarefas demoradas com mesmo input? Dá pra fazer umas gambiarras brabas com Sensor, mas podia ser simples. Você escolhe fazer cache e pronto! Mesma entrada e mesma saída como no paradigma funcional
- Falando em funcional, o mais lógico de modelar um fluxo de dados seria de forma funcional, mas lá é tudo objeto.
Enfim, aparentemente no Airflow 2.0 vários problemas devem ser resolvidos, mas ainda não temos data para isso. O que parece é que ele está cada vez mais parecido com o Prefect, então por que não começar mais certo?
Um dos maiores problemas dessa área de Workflows é que a cada 5 minutos cada um lança um novo SGWf nem sempre pensando em padrões já estipulados como Common Workflow Language (CWL) ou Workflow Description Language (WDL). Isso acontece em várias áreas que SGWf atuam, seguem alguns exemplos gratuitos para cada área que já usei:
- para Business Process Management (BPM) tem o Bonita BPM
- sistemas de ETL (Extract, Load and Transform) existem o Pentaho Kettle, NiFi
- workflows científicos são o Cromwell, Galaxy, Pegasus, Nextflow, Toil
Para Data Flows vou dar uma detalhada melhor porque é o que muita gente tem feito com o Airflow:
- Luigi e Dagster têm ótimos conceitos, mas o agendador tem problemas bem similares ao Airflow com questão de escalabilidade. Mesmo assim, já permitem mais flexibilidade de execução de Flows
- Azkaban foi uma grata surpresa desenvolvida pelo Linkedin… As 39 instâncias de Celery que eu gerenciava viraram 3 do Azkaban. Ele tem suporte a trigger de fluxos através de tópicos no Kafka (muito funcional)… A criação de DAGs não era muito legal, mas aí fizemos o Auror pra isso
- Argo é utilizado no Kubeflow. Bem simplista, mas cumpre bem toda parte de escala e se comportou sempre de forma bem estável, só que precisa de uma infra de Kubernetes
- Prefect ganhou minha confiança quando finalmente achei alguém com a mesma opinião que eu no artigo Why Not Airflow. Tenho gostado bastante de usar ele e supre todas as reclamações supracitadas além da flexibilidade de uso.
Cada projeto normalmente foca em um problema de forma bem específica e tudo bem, mas no estado atual do Airflow não vejo o problema que ele resolve bem dado que existem outros sistemas mais bem resolvidos para cada tarefa que ele tenta resolver. A questão é que estão tentando abraçar tudo e dar uma solução que resolve muita coisa que um SGWf realmente não precisaria resolver deixando várias coisas básicas capengas.
Atualmente ele é um padrão de mercado com suporte da AWS e Google Cloud com versões gerenciadas e tenho uma teoria quanto a ele ter sido escolhido como padrão. Acho que a simplicidade de instalação inicial acaba iludindo novos adeptos que depois de um tempo percebem a quantidade de trabalho e gambiarras que precisam fazer para escalar a solução para problemas maiores. Quem nunca fez um Operator cheio de lógica pra suprir um monte de limitação do Airflow? Ou encheu a DAG de Sensor pra controlar fluxo?
Com a quantidade imensa de contribuidores tenho certeza que tem tudo para ficar direito, mas precisam de muito foco e atenção com as coisas mais prioritárias para realmente ser um bom SGWf.
