Como integrar o Apache Airflow com OpenLineage para rastreabilidade total
Quando um dashboard mostra o número errado numa segunda-feira de manhã, a primeira pergunta é sempre a mesma: de onde veio esse dado e o que mexeu nele pelo caminho? Para times que orquestram pipelines com Apache Airflow, a resposta honesta costuma ser uma caça manual por código de DAG, logs de tarefa e conhecimento que só existe na cabeça de alguém. Integrar o Apache Airflow com OpenLineage é a forma prática de trocar essa caça por um mapa, um registro automático e padronizado de cada conjunto de dados que um pipeline lê e escreve.
O Airflow executa trabalho agendado muito bem, mas uma DAG descreve só a ordem das tarefas, não o fluxo de dados entre sistemas. A orquestração de dados diz qual passo roda em seguida, porém revela pouco sobre qual tabela alimentou qual relatório. É justamente esse ponto cego que uma ferramenta de linhagem resolve dentro de um data pipeline moderno.
O OpenLineage é um padrão aberto para coletar metadados de linhagem, mantido pela LF AI & Data Foundation. Em vez de cada ferramenta inventar o próprio rastreamento, ele define um modelo de eventos comum que orquestradores, data warehouses e ferramentas de transformação falam entre si. A partir do Airflow 2.7, esse padrão passou a vir como um provider nativo, segundo a documentação do Apache Airflow, então os pipelines por trás do seu data lineage automatizado emitem linhagem sem um agente separado grudado por fora.
Por que pipelines do Airflow perdem rastreabilidade
Uma DAG é um grafo de tarefas, e isso é ao mesmo tempo sua força e seu limite. O Airflow sabe que extract precisa terminar antes de transform, mas por padrão ele não registra que transform leu de raw.orders e escreveu em analytics.daily_sales. Quando uma coluna muda lá em cima, ninguém enxerga os relatórios lá embaixo que vão quebrar até que eles de fato quebrem.
O problema cresce junto com a stack. Um único pipeline pode puxar do Postgres, gravar arquivos no S3, rodar um job Spark e carregar uma tabela de warehouse que um modelo de BI consome depois. Cada salto vive em um sistema diferente, com seus próprios logs, e reconstruir o caminho completo vira arqueologia. É a mesma lacuna que transforma uma pequena mudança de schema no erro mais comum em projetos de engenharia de dados: trabalho que trava porque ninguém consegue rastrear o impacto com segurança.
Documentação manual não sobrevive ao ritmo de uma plataforma que muda rápido. Páginas de wiki envelhecem no instante em que alguém sobe uma nova pipeline, e o diagrama no drive compartilhado quase nunca bate com a produção. A linhagem automática resolve isso porque o registro é gerado pela própria execução, não por uma pessoa lembrando de atualizar.
O que é OpenLineage e como ele se conecta ao Airflow
O OpenLineage modela três objetos centrais: o job (a unidade de trabalho, como uma tarefa do Airflow), o run (uma execução daquele job) e o dataset (as tabelas ou arquivos consumidos e produzidos). Em torno disso, ele anexa facets, pequenos blocos de metadados estruturados que descrevem schema, linhagem em nível de coluna, qualidade e mais. Como o modelo é aberto, qualquer ferramenta que o fale pode contribuir com o mesmo grafo de linhagem ou consumir dele.
A integração com o Airflow transforma cada execução de tarefa em eventos de linhagem. Quando uma tarefa começa e termina, o provider emite um evento START e um COMPLETE (ou FAIL) descrevendo as entradas e saídas que ela tocou. Para muitos operadores nativos, sobretudo os operadores SQL, o provider faz o parsing da query para extrair automaticamente os datasets de origem e destino, então até a ingestão de dados produz linhagem como subproduto de rodar normalmente.
Esses eventos seguem para um backend por meio de um transporte, em geral HTTP. O Marquez é o backend de metadados de referência, mantido pela mesma fundação, enquanto plataformas de catálogo também ingerem eventos OpenLineage, algo que conversa direto com a catalogação de dados da empresa. O Airflow segue como orquestrador e o repositório de linhagem fica separado, o que mantém as responsabilidades limpas e deixa você trocar o backend conforme a estratégia de frameworks de metadados amadurece.
Como integrar o Apache Airflow com OpenLineage, passo a passo
O provider nativo deixa a configuração curta. No Airflow 2.7 ou superior você instala o provider, informa para onde enviar os eventos, roda suas DAGs como sempre e confere o grafo de linhagem no seu backend. A tabela abaixo quebra o caminho em passos concretos para um time que está subindo isso pela primeira vez, um padrão que combina bem com uma boa qualidade de dados.
| Passo | O que você faz | Por que importa |
|---|---|---|
| 1. Instalar o provider | Adicione apache-airflow-providers-openlineage ao ambiente | Habilita linhagem nativa sem agentes externos |
| 2. Definir o transporte | Aponte AIRFLOW__OPENLINEAGE__TRANSPORT (ou OPENLINEAGE_URL) para o backend | Diz ao Airflow para onde mandar os eventos START/COMPLETE |
| 3. Escolher um backend | Rode o Marquez ou direcione os eventos para um catálogo | Armazena e visualiza o grafo de linhagem |
| 4. Rodar e verificar | Dispare uma DAG e abra a visão de linhagem | Confirma que datasets e conexões aparecem como esperado |
| 5. Ampliar cobertura | Adicione facets ou extractors para operadores sob medida | Captura a linhagem que os parsers padrão não pegam |
A configuração fica na seção [openlineage] do airflow.cfg ou em variáveis de ambiente, conforme a documentação do OpenLineage, o que se encaixa em deploys em contêiner, onde a config é injetada em tempo de execução. Se você já empacota o Airflow com o dbt na camada de transformação, o mesmo padrão leva a linhagem pelos dois, e o grafo não para na fronteira do orquestrador.
Operadores customizados pedem um passo extra pequeno. Quando os parsers nativos não conseguem inferir entradas e saídas, você implementa get_openlineage_facets_on_start e get_openlineage_facets_on_complete no operador para declará-las de forma explícita. Esse é o mecanismo que mantém a cobertura honesta conforme os pipelines crescem, e vale tratá-lo como parte da definição de pronto de qualquer tarefa nova, no mesmo espírito de quem cuida da observabilidade de sistemas de dados.
Transformando eventos de linhagem em rastreabilidade total
A rastreabilidade total é o que você ganha quando esses eventos se acumulam em um grafo. A análise de impacto vira uma consulta em vez de uma reunião: antes de alterar raw.orders, dá para ver toda tabela e dashboard a jusante e avisar os responsáveis primeiro. A análise de causa raiz corre no sentido contrário, de um relatório quebrado de volta até a tarefa e a execução exatas que produziram o dado ruim.
A linhagem também reforça qualidade e auditoria. Quando você anexa facets de qualidade, uma verificação que falhou em um dataset viaja junto com sua linhagem, então você sabe não só que um teste falhou, mas quais ativos a jusante ficaram suspeitos. É por isso que times que juntam linhagem com analytics auditáveis via dbt e DataHub contêm uma carga ruim antes que ela se espalhe, e por isso auditores ganham uma trilha defensável de como um número foi produzido.
Nada disso torna o OpenLineage a resposta para tudo, e a profundidade certa é situacional. Um pipeline pequeno com três tarefas talvez não precise de um backend de metadados completo, enquanto uma plataforma que alimenta tabelas governadas em lakehouse para vários times se beneficia muito. A BIX trabalha com múltiplos orquestradores, catálogos e nuvens, então a orientação é sempre dimensionar o investimento em linhagem à complexidade real da operação, não ao hype em torno de uma ferramenta específica.
Mais do que o provider em si, o que importa é tratar a rastreabilidade como uma propriedade de arquitetura da plataforma, decidida cedo e capturada de forma automática. Ao integrar o Apache Airflow com OpenLineage, você transforma cada execução agendada em fonte de verdade sobre como o dado se move, a base de que toda iniciativa de governança, qualidade e engenharia de dados agêntica mais cedo ou mais tarde depende.
Se a sua empresa está escalando pipelines no Airflow e precisa de uma linhagem que aguente auditoria e mudança, nossos especialistas podem ajudar a desenhar a arquitetura de rastreabilidade que encaixa na sua stack. Fale com a nossa equipe e avance na maturidade dos seus dados. ⬇️
Perguntas frequentes
O que é OpenLineage e como ele funciona com o Apache Airflow? O OpenLineage é um padrão aberto para coletar metadados de linhagem de dados, mantido pela LF AI & Data Foundation. Com o Apache Airflow, um provider nativo emite eventos de linhagem toda vez que uma tarefa roda, descrevendo os datasets que ela lê e escreve. Esses eventos seguem para um backend como Marquez ou um catálogo, que monta o grafo de linhagem de ponta a ponta.
Como integrar o Apache Airflow com OpenLineage?
Instale o pacote apache-airflow-providers-openlineage no Airflow 2.7 ou superior, defina um transporte apontando para o seu backend de linhagem e rode suas DAGs. O provider extrai linhagem automaticamente de muitos operadores, sobretudo os de SQL. Para operadores customizados, você implementa os métodos de facets do OpenLineage para declarar entradas e saídas de forma explícita.
Qual versão do Airflow suporta OpenLineage de forma nativa? O suporte nativo, de primeira mão, chegou no Airflow 2.7 por meio do provider OpenLineage, segundo a documentação do Apache Airflow. Versões anteriores dependiam de um pacote de integração externo. Rodar uma versão atual do Airflow é o caminho mais simples para ter suporte de linhagem mantido, sem agentes extras.
Qual a diferença entre linhagem no Airflow e um catálogo de dados? O Airflow com OpenLineage gera os eventos de linhagem enquanto os pipelines rodam, capturando como os datasets se conectam. Um catálogo de dados armazena, busca e visualiza essa linhagem junto com donos, glossário e sinais de qualidade. Eles funcionam juntos: o Airflow produz o sinal e o catálogo o transforma em governança.
Por que a linhagem de dados é importante para a governança de dados? A linhagem de dados responde de onde o dado vem e para onde vai, que é a base da análise de impacto, do debug de causa raiz e da auditoria. Sem ela, mudanças de schema quebram relatórios em silêncio e a conformidade vira adivinhação. A linhagem automática a partir do Airflow mantém esse mapa preciso porque o próprio pipeline o gera a cada execução.









