airflow
Apache Airflow 2.10.3
Apache Airflow (ou simplesmente Airflow) é uma plataforma para criar, agendar e monitorar fluxos de trabalho de forma programática.
Quando os fluxos de trabalho são definidos como código, eles se tornam mais fáceis de manter, versáveis, testáveis e colaborativos.
Use o Airflow para criar fluxos de trabalho como gráficos acíclicos direcionados (DAGs) de tarefas. O agendador do Airflow executa suas tarefas em uma série de trabalhadores enquanto segue as dependências especificadas. Utilitários avançados de linha de comando facilitam a realização de cirurgias complexas em DAGs. A interface de usuário avançada facilita a visualização de pipelines em execução na produção, o monitoramento do progresso e a solução de problemas quando necessário.
Índice
O Airflow funciona melhor com fluxos de trabalho que são em sua maioria estáticos e mudam lentamente. Quando a estrutura do DAG é semelhante de uma execução para outra, isso esclarece a unidade de trabalho e a continuidade. Outros projetos semelhantes incluem Luigi, Oozie e Azkaban.
O Airflow é comumente usado para processar dados, mas acredita que as tarefas deveriam ser idealmente idempotentes (ou seja, os resultados da tarefa serão os mesmos e não criarão dados duplicados em um sistema de destino) e não devem passar grandes quantidades de dados de uma tarefa para outra (embora as tarefas possam passar metadados usando o recurso XCom do Airflow). Para tarefas de alto volume e uso intensivo de dados, uma prática recomendada é delegar a serviços externos especializados nesse tipo de trabalho.
O Airflow não é uma solução de streaming, mas costuma ser usado para processar dados em tempo real, extraindo dados de fluxos em lotes.
Apache Airflow é testado com:
| Versão principal (desenvolvimento) | Versão estável (2.10.3) | |
|---|---|---|
| Pitão | 3,9, 3,10, 3,11, 3,12 | 3,8, 3,9, 3,10, 3,11, 3,12 |
| Plataforma | AMD64/ARM64(*) | AMD64/ARM64(*) |
| Kubernetes | 1,28, 1,29, 1,30, 1,31 | 1,27, 1,28, 1,29, 1,30 |
| PostgreSQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
| MySQL | 8,0, 8,4, Inovação | 8,0, 8,4, Inovação |
| SQLite | 3.15.0+ | 3.15.0+ |
* Experimental
Nota : MariaDB não é testado/recomendado.
Nota : SQLite é usado em testes de Airflow. Não o use na produção. Recomendamos usar a versão estável mais recente do SQLite para desenvolvimento local.
Nota : Atualmente, o Airflow pode ser executado em sistemas operacionais compatíveis com POSIX. Para desenvolvimento, ele é testado regularmente em distribuições Linux bastante modernas e em versões recentes do macOS. No Windows você pode executá-lo via WSL2 (Windows Subsystem for Linux 2) ou via Linux Containers. O trabalho para adicionar suporte ao Windows é rastreado pelo número 10388, mas não é uma prioridade alta. Você só deve usar distros baseadas em Linux como ambiente de execução de "produção", pois este é o único ambiente compatível. A única distribuição usada em nossos testes de CI e na imagem DockerHub gerenciada pela comunidade é Debian Bookworm .
Visite a documentação oficial do site do Airflow (versão estável mais recente) para obter ajuda com a instalação do Airflow, primeiros passos ou um tutorial mais completo.
Nota: Se você estiver procurando documentação para o branch principal (ramo de desenvolvimento mais recente): você pode encontrá-la em s.apache.org/airflow-docs.
Para obter mais informações sobre propostas de melhoria do fluxo de ar (AIPs), visite o Airflow Wiki.
Documentação para projetos dependentes como pacotes de provedores, imagem Docker, Helm Chart, você encontrará no índice de documentação.
Publicamos Apache Airflow como pacote apache-airflow em PyPI. No entanto, instalá-lo às vezes pode ser complicado porque o Airflow é uma biblioteca e um aplicativo. As bibliotecas geralmente mantêm suas dependências abertas e os aplicativos geralmente as fixam, mas não devemos fazer nenhuma das duas coisas simultaneamente. Decidimos manter nossas dependências o mais abertas possível (em pyproject.toml ) para que os usuários possam instalar diferentes versões de bibliotecas, se necessário. Isso significa que pip install apache-airflow não funcionará de vez em quando ou produzirá uma instalação inutilizável do Airflow.
Para ter uma instalação repetível, no entanto, mantemos um conjunto de arquivos de restrição "que funcionam" nas ramificações órfãs constraints-main e constraints-2-0 . Mantemos esses arquivos de restrições "que funcionam" separadamente por versão principal/secundária do Python. Você pode usá-los como arquivos de restrição ao instalar o Airflow do PyPI. Observe que você deve especificar a tag/versão/ramificação correta do Airflow e as versões do Python no URL.
Nota: Atualmente, apenas a instalação
pipé oficialmente suportada.
Embora seja possível instalar o Airflow com ferramentas como Poetry ou pip-tools, eles não compartilham o mesmo fluxo de trabalho do pip - especialmente quando se trata de gerenciamento de restrições versus requisitos. A instalação via Poetry ou pip-tools não é suportada atualmente.
Existem problemas conhecidos com bazel que podem levar a dependências circulares ao usá-lo para instalar o Airflow. Mude para pip se você encontrar esses problemas. A comunidade Bazel trabalha para corrigir o problema this PR <https://github.com/bazelbuild/rules_python/pull/1166> _ então pode ser que versões mais recentes do bazel resolvam isso.
Se desejar instalar o Airflow usando essas ferramentas, você deve usar os arquivos de restrição e convertê-los para o formato e fluxo de trabalho apropriado que sua ferramenta exige.
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "Para obter informações sobre a instalação de pacotes de provedores, verifique provedores.
Apache Airflow é um projeto da Apache Software Foundation (ASF) e nossos lançamentos oficiais de código-fonte:
Seguindo as regras do ASF, os pacotes fonte lançados devem ser suficientes para que um usuário compile e teste a versão, desde que tenha acesso à plataforma e às ferramentas apropriadas.
Existem outras maneiras de instalar e usar o Airflow. Esses são métodos de "conveniência" - não são "lançamentos oficiais" conforme declarado pela ASF Release Policy , mas podem ser usados por usuários que não desejam construir o software por conta própria.
Estas são - na ordem das maneiras mais comuns pelas quais as pessoas instalam o Airflow:
pip padrãodocker , usá-los no Kubernetes, Helm Charts, docker-compose , docker swarm , etc. Você pode ler mais sobre como usar, personalizar e estender as imagens nos documentos mais recentes e aprender detalhes sobre os internos no documento de imagens.Todos esses artefatos não são lançamentos oficiais, mas são preparados usando fontes divulgadas oficialmente. Alguns desses artefatos são de “desenvolvimento” ou de “pré-lançamento” e estão claramente marcados como tal de acordo com a Política da ASF.
DAGs : visão geral de todos os DAGs em seu ambiente.
Grade : representação em grade de um DAG que se estende ao longo do tempo.
Gráfico : Visualização das dependências de um DAG e seu status atual para uma execução específica.
Duração da tarefa : tempo total gasto em diferentes tarefas ao longo do tempo.
Gantt : Duração e sobreposição de um DAG.
Código : maneira rápida de visualizar o código-fonte de um DAG.
A partir do Airflow 2.0.0, oferecemos suporte a uma abordagem SemVer estrita para todos os pacotes lançados.
Existem algumas regras específicas com as quais concordamos que definem detalhes de versionamento dos diferentes pacotes:
google 4.1.0 e amazon 3.0.3 podem ser instalados com Airflow 2.1.2 . Se houver limites de dependências cruzadas entre provedores e pacotes Airflow, eles estarão presentes nos provedores como limitações install_requires . Nosso objetivo é manter a compatibilidade retroativa dos provedores com todas as versões do Airflow 2 lançadas anteriormente, mas às vezes haverá alterações significativas que podem fazer com que alguns ou todos os provedores tenham a versão mínima do Airflow especificada.Ciclo de vida da versão do Apache Airflow:
| Versão | Patch atual/menor | Estado | Primeiro lançamento | Suporte limitado | EOL/Terminado |
|---|---|---|---|---|---|
| 2 | 2.10.3 | Suportado | 17 de dezembro de 2020 | A definir | A definir |
| 1.10 | 1.10.15 | EOL | 27 de agosto de 2018 | 17 de dezembro de 2020 | 17 de junho de 2021 |
| 1,9 | 1.9.0 | EOL | 03 de janeiro de 2018 | 27 de agosto de 2018 | 27 de agosto de 2018 |
| 1,8 | 1.8.2 | EOL | 19 de março de 2017 | 03 de janeiro de 2018 | 03 de janeiro de 2018 |
| 1.7 | 1.7.1.2 | EOL | 28 de março de 2016 | 19 de março de 2017 | 19 de março de 2017 |
Versões com suporte limitado serão suportadas apenas com segurança e correção de bugs críticos. As versões EOL não receberão nenhuma correção nem suporte. Sempre recomendamos que todos os usuários executem a versão secundária mais recente disponível para qualquer versão principal em uso. É altamente recomendável atualizar para a versão principal mais recente do Airflow o mais cedo possível e antes da data de EOL.
A partir do Airflow 2.0, concordamos com certas regras que seguimos para suporte a Python e Kubernetes. Eles são baseados no cronograma de lançamento oficial do Python e do Kubernetes, bem resumido no Guia do desenvolvedor do Python e na política de distorção de versão do Kubernetes.
Eliminamos o suporte para versões Python e Kubernetes quando elas atingem o EOL. Exceto o Kubernetes, uma versão permanece compatível com o Airflow se dois grandes provedores de nuvem ainda fornecerem suporte para ela. Eliminamos o suporte para essas versões EOL principal logo após a data EOL, e ele é efetivamente removido quando lançamos o primeiro novo MINOR (ou MAJOR se não houver uma nova versão MINOR) do Airflow. Por exemplo, para Python 3.9 significa que abandonaremos o suporte principal logo após 27.06.2023, e a primeira versão MAIOR ou MENOR do Airflow lançada depois não o terá.
Damos suporte a uma nova versão do Python/Kubernetes principal depois que eles são lançados oficialmente, assim que os fazemos funcionar em nosso pipeline de CI (o que pode não ser imediato devido às dependências que acompanham principalmente as novas versões do Python), lançamos novas imagens /support no Airflow com base na configuração do CI em funcionamento.
Esta política é de melhor esforço, o que significa que pode haver situações em que poderemos encerrar o suporte mais cedo se as circunstâncias assim o exigirem.
A comunidade Airflow fornece imagens de contêiner convenientemente empacotadas que são publicadas sempre que publicamos uma versão do Apache Airflow. Essas imagens contêm:
A versão da imagem base do sistema operacional é a versão estável do Debian. O Airflow suporta o uso de todas as versões estáveis atualmente ativas - assim que todas as dependências do Airflow suportam a construção e configuramos o pipeline de CI para construir e testar a versão do sistema operacional. Aproximadamente 6 meses antes do fim do suporte regular de uma versão estável anterior do sistema operacional, o Airflow alterna as imagens lançadas para usar a versão mais recente do sistema operacional com suporte.
Por exemplo, a mudança do Debian Bullseye para Debian Bookworm foi implementada antes do lançamento 2.8.0 em outubro de 2023 e Debian Bookworm será a única opção suportada a partir do Airflow 2.10.0.
Os usuários continuarão a poder construir suas imagens usando versões estáveis do Debian até o final do suporte regular e a construção e verificação das imagens acontecerem em nosso CI, mas nenhum teste de unidade foi executado usando esta imagem no branch main .
O Airflow tem muitas dependências - diretas e transitivas, e o Airflow também é ambos - biblioteca e aplicativo, portanto, nossas políticas para dependências devem incluir ambos - estabilidade de instalação do aplicativo, mas também capacidade de instalar versões mais recentes de dependências para os usuários que desenvolvem DAG. Desenvolvemos a abordagem em que constraints são usadas para garantir que o fluxo de ar possa ser instalado de forma repetível, sem limitar nossos usuários a atualizar a maioria das dependências. Como resultado, decidimos não limitar a versão superior das dependências do Airflow por padrão, a menos que tenhamos bons motivos para acreditar que o limite superior é necessário devido à importância da dependência, bem como ao risco que ela envolve para atualizar uma dependência específica. Também limitamos as dependências que sabemos que causam problemas.
O nosso mecanismo de restrição se preocupa em encontrar e atualizar automaticamente todas as dependências não superiores (desde que todos os testes sejam aprovados). Nossas main falhas de compilação indicarão se há versões de dependências que quebram nossos testes - indicando que devemos fazer um Upper-bind deles ou que devemos corrigir nosso código/testes para levar em conta as alterações upstream dessas dependências.
Sempre que aplicamos um limite superior para tal dependência, devemos sempre comentar por que estamos fazendo isso - ou seja, devemos ter uma boa razão para que a dependência seja um limite superior. E devemos mencionar também qual é a condição para remover a vinculação.
Essas dependências são mantidas em pyproject.toml .
Existem poucas dependências que decidimos serem importantes o suficiente para limitá-las por padrão, já que elas são conhecidas por seguirem esquemas de versionamento previsíveis, e sabemos que novas versões delas provavelmente trarão mudanças significativas. Comprometemo-nos a revisar regularmente e tentar atualizar para as versões mais recentes das dependências à medida que são lançadas, mas este é um processo manual.
As dependências importantes são:
SQLAlchemy : limite superior para uma versão MINOR específica (SQLAlchemy é conhecido por remover obsoleções e introduzir alterações significativas, especialmente porque o suporte para diferentes bancos de dados varia e muda em várias velocidades)Alembic : é importante lidar com as nossas migrações de forma previsível e eficiente. É desenvolvido em conjunto com SQLAlchemy. Nossa experiência com Alembic é que ele é muito estável na versão MINORFlask : estamos usando o Flask como a espinha dorsal de nossa UI e API da web. Sabemos que a versão principal do Flask provavelmente introduzirá alterações significativas entre elas, então limitá-lo à versão PRINCIPAL faz sentidowerkzeug : a biblioteca é conhecida por causar problemas em novas versões. Ele está fortemente acoplado às bibliotecas Flask e devemos atualizá-las juntoscelery : O aipo é um componente crucial do Airflow, pois é usado para CeleryExecutor (e similares). O Celery segue o SemVer, então devemos limitá-lo à próxima versão PRINCIPAL. Além disso, quando atualizarmos a versão superior da biblioteca, devemos garantir que a versão mínima do Airflow do Celery Provider esteja atualizada.kubernetes : Kubernetes é um componente crucial do Airflow, pois é usado para o KubernetesExecutor (e similares). A biblioteca Kubernetes Python segue SemVer, portanto, devemos limitá-la para a próxima versão PRINCIPAL. Além disso, quando atualizarmos a versão superior da biblioteca, devemos garantir que a versão mínima do Airflow do provedor Kubernetes esteja atualizada.A parte principal do Airflow é o Airflow Core, mas o poder do Airflow também vem de vários provedores que estendem a funcionalidade principal e são lançados separadamente, mesmo que os mantenhamos (por enquanto) no mesmo monorepo por conveniência. Você pode ler mais sobre os provedores na documentação dos Provedores. Também implementamos um conjunto de políticas para manter e liberar provedores gerenciados pela comunidade, bem como a abordagem para provedores comunitários versus provedores terceirizados no documento de provedores.
Esses extras e dependências providers são mantidos em provider.yaml de cada provedor.
Por padrão, não devemos limitar as dependências superiores dos provedores; no entanto, o mantenedor de cada provedor pode decidir adicionar limites adicionais (e justificá-los com comentários).
Quer ajudar a construir o Apache Airflow? Confira nosso guia para contribuidores para uma visão geral abrangente de como contribuir, incluindo instruções de configuração, padrões de codificação e diretrizes de pull request.
Se você mal pode esperar para contribuir e deseja começar o mais rápido possível, confira o início rápido de contribuição aqui!
As imagens oficiais do Docker (contêiner) para Apache Airflow são descritas em imagens.
+1s dos membros do PMC e do committer são considerados votos vinculativos. Conhecemos cerca de 500 organizações que usam o Apache Airflow (mas provavelmente há muitas mais) em estado selvagem.
Se você usa o Airflow, sinta-se à vontade para fazer um PR para adicionar sua organização à lista.
O Airflow é trabalho da comunidade, mas os principais committers/mantenedores são responsáveis por revisar e mesclar PRs, bem como orientar as conversas sobre novas solicitações de recursos. Se você gostaria de se tornar um mantenedor, revise os requisitos do committer do Apache Airflow.
Freqüentemente, você verá um problema atribuído a um marco específico com a versão do Airflow ou um PR que será mesclado ao branch principal e poderá se perguntar em qual versão o (s) PR (s) mesclado (s) serão lançados ou em qual versão os problemas corrigidos serão dentro. A resposta para isso é como sempre - depende de vários cenários. A resposta é diferente para PRs e problemas.
Para adicionar um pouco de contexto, estamos seguindo o esquema de versionamento do Semver conforme descrito no processo de lançamento do Airflow. Mais detalhes são explicados em detalhes neste README no capítulo Controle de versão semântica, mas resumindo, temos versões MAJOR.MINOR.PATCH do Airflow.
MAJOR é incrementada em caso de alterações significativasMINOR é incrementada quando novos recursos são adicionadosPATCH é incrementada quando há apenas correções de bugs e alterações somente de documentos Geralmente lançamos versões MINOR do Airflow de uma ramificação que leva o nome da versão MINOR. Por exemplo, as versões 2.7.* são lançadas a partir do branch v2-7-stable , 2.8.* são lançadas a partir do branch v2-8-stable , etc.
Na maioria das vezes em nosso ciclo de lançamento, quando o branch para o próximo branch MINOR ainda não foi criado, todos os PRs mesclados com main (a menos que sejam revertidos) encontrarão seu caminho para o próximo lançamento MINOR . Por exemplo, se a última versão for 2.7.3 e a ramificação v2-8-stable ainda não tiver sido criada, a próxima versão MINOR será 2.8.0 e todos os PRs mesclados com main serão lançados em 2.8.0 . No entanto, alguns PRs (correções de bugs e alterações somente de documentos), quando mesclados, podem ser escolhidos a dedo no branch MINOR atual e lançados na próxima versão PATCHLEVEL . Por exemplo, se 2.8.1 já foi lançado e estamos trabalhando em 2.9.0dev , então marcar um PR com o marco 2.8.2 significa que ele será escolhido a dedo para o branch v2-8-test e lançado em 2.8.2rc1 , e eventualmente em 2.8.2 .
Quando nos preparamos para a próxima versão MINOR , cortamos o novo branch v2-*-test e v2-*-stable e preparamos versões alpha e beta para a próxima versão MINOR , os PRs mesclados com main ainda serão lançados na próxima versão MINOR até que a versão rc seja cortada. Isso está acontecendo porque as ramificações v2-*-test e v2-*-stable são rebaseadas em main quando as próximas versões beta e rc são preparadas. Por exemplo, quando cortamos a versão 2.10.0beta1 , qualquer coisa mesclada com main antes do lançamento de 2.10.0rc1 encontrará seu caminho para 2.10.0rc1.
Então, assim que prepararmos o primeiro candidato RC para a versão MINOR, paramos de mover as ramificações v2-*-test e v2-*-stable e os PRs mesclados com main serão lançados na próxima versão MINOR . No entanto, alguns PRs (correções de bugs e alterações somente de documentos), quando mesclados, podem ser escolhidos a dedo no branch MINOR atual e lançados na próxima versão PATCHLEVEL - por exemplo, quando a última versão lançada do branch v2-10-stable é 2.10.0rc1 , alguns dos PRs de main podem ser marcados como marco 2.10.0 pelos committers, o gerente de lançamento tentará selecioná-los no branch de lançamento. Se forem bem-sucedidos, eles serão lançados em 2.10.0rc2 e posteriormente em 2.10.0 . Isto também se aplica às versões subsequentes PATCHLEVEL . Quando, por exemplo, 2.10.1 já foi lançado, marcar um PR com o marco 2.10.2 significará que ele será escolhido a dedo para o branch v2-10-stable e lançado em 2.10.2rc1 e eventualmente em 2.10.2 .
A decisão final sobre a escolha seletiva é feita pelo gerente de lançamento.
Marcar problemas com um marco é um pouco diferente. Os mantenedores normalmente não marcam os problemas com um marco, normalmente eles são marcados apenas em PRs. Se o PR vinculado ao problema (e "corrigir") for mesclado e lançado em uma versão específica seguindo o processo descrito acima, o problema será encerrado automaticamente, nenhum marco será definido para o problema, você precisa verificar o PR que corrigiu o problema para ver em qual versão ele foi lançado.
No entanto, às vezes os mantenedores marcam os problemas com um marco específico, o que significa que o problema é importante para se tornar um candidato para dar uma olhada quando o lançamento estiver sendo preparado. Como este é um projeto de código aberto, onde basicamente todos os contribuidores oferecem seu tempo, não há garantia de que um problema específico será corrigido em uma versão específica. Não queremos suspender o lançamento porque algum problema não foi corrigido, portanto, nesse caso, o gerenciador de lançamento reatribuirá esses problemas não corrigidos para o próximo marco, caso eles não sejam corrigidos a tempo para o lançamento atual. Portanto, o marco para emissão é mais uma intenção que deve ser olhado, do que uma promessa de que será corrigido na versão.
Mais contexto e perguntas frequentes sobre o lançamento em nível de patch podem ser encontrados no documento O que acontece no próximo lançamento na pasta dev do repositório.
Sim! Certifique-se de cumprir as políticas de marca registrada da Apache Foundation e o Brandbook Apache Airflow. Os logotipos mais atualizados são encontrados neste repositório e no site da Apache Software Foundation.
A infraestrutura de CI para Apache Airflow foi patrocinada por:
