O que é data lineage (linhagem de dados)

Data lineage é o registro auditável do caminho percorrido por um dado desde sua origem até o ponto de consumo final. Ele documenta quais transformações foram aplicadas, por quais sistemas o dado passou e quem ou o quê o modificou ao longo do trajeto. É, em essência, uma cadeia de custódia para dados.

A linhagem pode ser capturada em três níveis de granularidade distintos:

• Nível de tabela: registra quais tabelas alimentam quais outras tabelas, útil para mapear dependências gerais entre datasets.
• Nível de coluna: rastreia como campos específicos se propagam e se transformam entre tabelas, essencial para depurar erros em métricas calculadas.
• Nível de linha: identifica a origem de registros individuais, relevante para auditoria de dados pessoais e reconciliação financeira, mas tecnicamente mais custoso.

Quanto mais granular, maior a utilidade para depuração e maior o custo de implementação. Um analista investigando por que uma métrica de receita mudou não precisa apenas saber que a tabela orders alimenta o dashboard; ele precisa saber qual coluna específica foi alterada e qual transformação intermediária foi responsável pela discrepância.

Relação com conceitos próximos

Data lineage é frequentemente confundido com conceitos adjacentes. O data catalog é o inventário: documenta o que existe, onde está e o que significa. O data lineage responde “de onde veio e como chegou aqui”. Os dois se complementam: um catálogo sem linhagem documenta ativos estáticos; a linhagem sem catálogo produz grafos de dependência difíceis de interpretar.

Data observability monitora a saúde dos dados em tempo real, com detecção de anomalias, schema drift e volume inesperado. A linhagem fornece o contexto para entender por que uma anomalia ocorreu: qual fonte upstream mudou e qual pipeline propagou o problema.

Data governance é o conjunto de políticas, processos e responsabilidades sobre os dados. A linhagem é um dos principais instrumentos técnicos que tornam a governança executável, não apenas declarativa.

O termo ganhou visibilidade com a adoção massiva de pipelines ELT e ferramentas como dbt, que expõem transformações como código. Quando as transformações ficam legíveis e versionadas, rastrear sua linhagem se torna viável em escala, e a demanda por ferramentas que automatizem esse rastreamento cresceu proporcionalmente.

Como a linhagem de dados funciona tecnicamente

Captura de metadados: ativa versus passiva

Existem duas abordagens fundamentais para capturar linhagem. Na abordagem ativa, os pipelines são instrumentados para emitir eventos de linhagem explicitamente: cada execução de um job registra quais entradas consumiu e quais saídas produziu. A precisão é alta, mas requer integração intencional com cada ferramenta da stack.

Na abordagem passiva, a linhagem é inferida retroativamente a partir de SQL, logs de query e planos de execução. É menos invasiva, mas tem limitações: transformações dinâmicas geradas programaticamente em Python ou Spark são difíceis de analisar estaticamente. Na prática, soluções maduras combinam as duas abordagens.

Linhagem estática versus dinâmica

A linhagem estática é extraída do código-fonte: SQL de uma view, DAG do dbt, definição de um job. Ela descreve o que deveria acontecer, não necessariamente o que aconteceu. É útil para documentação e análise de impacto de mudanças antes de executar.

A linhagem dinâmica é capturada em tempo de execução, refletindo o que de fato ocorreu: quais partições foram lidas, qual versão do schema estava vigente, quanto tempo levou. É mais precisa para auditoria e resolução de incidentes, mas exige infraestrutura de coleta em tempo real.

O padrão OpenLineage

OpenLineage é uma especificação aberta, mantida pela Linux Foundation, que define um modelo de eventos e metadados para linhagem de dados. Ferramentas como Apache Airflow, dbt, Spark e Flink já possuem integrações nativas ou via plugin. A ideia central é que qualquer ferramenta que emita eventos no formato OpenLineage pode ser consumida por qualquer plataforma de linhagem compatível.

A neutralidade de fornecedor é o principal argumento. Sem um padrão comum, cada ferramenta produz linhagem em formato proprietário, tornando a visão unificada impossível sem ETL adicional. Com OpenLineage, a linhagem de um job Spark rodando no EMR pode ser correlacionada com a de um modelo dbt no Snowflake na mesma interface.

Trade-offs de granularidade em ambientes grandes

Em ambientes com dezenas de milhares de objetos, linhagem em nível de coluna pode gerar grafos com milhões de arestas. O custo de armazenamento e de navegação cresce exponencialmente. Algumas organizações optam por linhagem de coluna apenas em domínios críticos, como dados financeiros e dados de clientes, mantendo linhagem de tabela para o restante. Essa segmentação reduz custos sem eliminar cobertura onde ela mais importa.

Para que serve e quem se beneficia

Data engineers

O caso de uso mais imediato é análise de impacto: antes de renomear ou remover uma coluna em uma tabela fonte, o engenheiro precisa saber quais pipelines, views e dashboards dependem dela. Sem linhagem, isso exige busca manual em repositórios, processo lento e propenso a falhas. Com linhagem de coluna, a resposta vem em segundos.

Na direção inversa, no debugging de incidentes, a linhagem permite percorrer o grafo de dependências de um dashboard com número errado até identificar exatamente qual transformação introduziu o problema.

Data stewards e times de governança

Para quem precisa aplicar políticas de dados, como classificação de sensibilidade, restrições de acesso e conformidade regulatória, a linhagem torna visível onde dados pessoais trafegam e são transformados. Sem ela, auditar o tratamento de um dado específico exige entrevistar engenheiros e revisar código manualmente.

A linhagem também facilita a resposta a solicitações de titulares de dados (exclusão, portabilidade) ao mapear todos os sistemas onde aquele dado pode ter chegado após transformações.

Analistas e cientistas de dados

Antes de usar um dataset em uma análise ou modelo preditivo, é necessário entender quais transformações foram aplicadas: se houve filtragens, imputações, agregações ou joins que possam enviesar os resultados. A linhagem expõe essas transformações de forma navegável, sem exigir que o analista leia código de pipeline.

Times de negócio

Confiança nos dados é um problema cultural, mas tem raiz técnica. Quando um executivo questiona de onde vem um número em um relatório, a resposta “vem do nosso DW” não é suficiente. A linhagem permite demonstrar a cadeia completa, da fonte transacional ao dashboard, aumentando a credibilidade dos dados e reduzindo debates intermináveis sobre versões conflitantes de métricas.

Desafios comuns na implementação

Ambientes heterogêneos

A maioria das organizações opera com múltiplas ferramentas de ingestão, transformação e consumo, frequentemente em nuvens diferentes. Cada ferramenta captura linhagem de forma fragmentada, quando captura. Montar uma visão unificada exige integração entre sistemas que não foram projetados para conversar entre si.

OpenLineage reduz esse problema, mas não o elimina: a cobertura depende de quais ferramentas da stack implementam o padrão. Ferramentas legadas, pipelines em shell script ou ETLs proprietários normalmente ficam fora da visão automatizada.

Pipelines ELT com dbt, Snowflake e AWS Glue

dbt gera linhagem de coluna a partir dos modelos SQL e expõe via sua API de artefatos. Snowflake oferece rastreamento de acesso e query history via suas views de sistema. AWS Glue tem integração com o AWS Glue Data Catalog, mas a cobertura de linhagem é limitada comparada a soluções dedicadas. Conectar essas peças requer um hub de metadados, seja uma plataforma dedicada ou uma solução construída internamente sobre o padrão OpenLineage.

Rastreamento em nível de linha

Linhagem de linha é tecnicamente viável por dois caminhos: metadados embarcados no próprio registro (colunas de auditoria como source_system, source_id, ingested_at) ou tabelas auxiliares que mapeiam chaves de origem para chaves de destino. Ambas as abordagens funcionam, mas escalam mal em datasets de alta cardinalidade e exigem disciplina de engenharia para não serem omitidas em transformações intermediárias.

Custo de manutenção de linhagem manual

Documentar linhagem manualmente em comentários SQL, READMEs ou wikis funciona para equipes pequenas com pipelines estáveis. À medida que o volume de transformações cresce e as equipes rodam em paralelo, a documentação manual fica desatualizada rapidamente. O custo de mantê-la supera os benefícios, e a linhagem registrada deixa de refletir a realidade.

Integração com ferramentas de BI

Ferramentas de BI como Power BI, Tableau e Looker são frequentemente o ponto de consumo final dos dados, mas também um dos maiores pontos cegos em linhagem. Power BI, por exemplo, permite transformações complexas em Power Query e DAX que não são expostas de forma padronizada para sistemas externos. Algumas soluções de linhagem oferecem conectores via APIs das ferramentas de BI, mas a cobertura é parcial e a linhagem dentro das próprias ferramentas raramente é capturada de forma completa.

Data lineage e governança de dados no contexto brasileiro

LGPD e rastreamento de dados pessoais

A Lei Geral de Proteção de Dados exige que as organizações saibam onde dados pessoais estão, como são usados e como foram obtidos. Isso pressupõe, tecnicamente, capacidade de rastrear o fluxo de dados pessoais desde a coleta até o descarte, exatamente o que a linhagem fornece.

Sem linhagem, responder a um relatório de impacto à proteção de dados (RIPD) ou a uma solicitação de exclusão de titular exige um esforço manual que pode levar dias ou semanas. Com linhagem automatizada cobrindo os sistemas relevantes, o mapeamento de fluxos de dados pessoais se torna um relatório, não um projeto.

Cenário brasileiro de adoção

Grandes organizações brasileiras dos setores financeiro, de telecomunicações e varejo têm avançado na adoção de plataformas modernas de dados, o que cria o ambiente técnico propício para linhagem. A lacuna mais comum observada é a fragmentação: as organizações capturam linhagem dentro de ferramentas individuais, mas não possuem visão unificada que atravesse o pipeline completo da fonte ao consumo.

Outra lacuna frequente é a ausência de processos que conectem a linhagem técnica às políticas de governança: os dados existem, mas não alimentam decisões de acesso, classificação ou conformidade de forma sistemática.

Data lineage em arquiteturas de data mesh

Em arquiteturas de data mesh, cada domínio é responsável por seus próprios data products. A linhagem se torna ainda mais crítica nesse modelo: quando um domínio consome dados de outro, é necessário rastrear a cadeia de custódia entre domínios para garantir que políticas de governança sejam respeitadas e que a proveniência dos dados seja auditável.

Plataformas de linhagem que suportam federação de metadados, onde cada domínio mantém sua própria linhagem e uma camada central agrega a visão global, são mais adequadas para data mesh do que soluções centralizadas que exigem acesso direto a todos os sistemas.

Como começar com recursos limitados

Antes de investir em uma plataforma dedicada, é possível obter cobertura significativa com recursos existentes:

• Usar os artefatos de linhagem gerados nativamente pelo dbt (manifest.json, catalog.json) e expô-los via dbt Docs ou integrá-los ao data catalog já em uso.
• Adicionar colunas de auditoria padronizadas (_source_system, _loaded_at, _source_id) em todas as tabelas de staging, uma forma de linhagem de linha de baixo custo.
• Documentar dependências críticas em código via comentários estruturados e tags, aproveitando ferramentas de busca no repositório Git.
• Usar as views de sistema do warehouse (Snowflake, BigQuery, Redshift) para extrair query history e reconstruir linhagem de acesso retroativamente.

Essas práticas não substituem uma plataforma de linhagem, mas estabelecem hábitos e metadados que facilitarão a transição quando a organização estiver pronta.

Como avaliar soluções e próximos passos

Critérios técnicos

O primeiro critério é o suporte nativo ao padrão OpenLineage. Ferramentas que produzem linhagem apenas em formato proprietário criam dependência de fornecedor e dificultam integrações futuras. Verifique se a solução pode tanto consumir eventos OpenLineage de fontes externas quanto emitir metadados nesse formato.

O segundo critério é a granularidade máxima suportada. Confirme se a ferramenta oferece linhagem de coluna, não apenas de tabela, e se isso está disponível para os conectores da sua stack específica, não apenas nos materiais de marketing.

O terceiro critério é a cobertura de integrações nativas. Mapeie sua stack atual (fontes, orquestradores, warehouses, ferramentas de transformação e ferramentas de BI) e verifique o nível de suporte para cada componente: integração nativa, conector via OpenLineage, ou ausência de cobertura.

Critérios operacionais

Avalie o custo de onboarding: quanto tempo leva para ter linhagem funcionando para os primeiros pipelines? Ferramentas que exigem instrumentação manual extensiva têm custo de adoção elevado e tendem a ficar desatualizadas.

Considere o modelo de escalabilidade. Em ambientes com alto volume de jobs e objetos, o desempenho da interface de navegação de linhagem se degrada em algumas soluções. Teste com dados de volume próximo ao real, não com datasets de demonstração.

Construir versus comprar

Construir internamente faz sentido quando a stack é homogênea, bem instrumentada com OpenLineage e a equipe tem capacidade de manter um hub de metadados. Ferramentas open source como Marquez, OpenMetadata e Datahub oferecem uma base funcional sem custo de licença e suportam o padrão OpenLineage nativamente.

Adotar uma solução de mercado é mais adequado quando a stack é heterogênea, a equipe de dados não tem capacidade para manter infraestrutura adicional, ou quando a linhagem precisa estar integrada a um data catalog mais amplo. Apache Atlas é outra opção open source relevante para ambientes com ecossistema Hadoop ou cloud híbrida.

Caminho incremental recomendado

1. Mês 1–2: Ative a linhagem nativa das ferramentas já em uso (dbt, Airflow, warehouse). Centralize os artefatos gerados em um único ponto de consulta, mesmo que seja um repositório Git ou um dashboard simples.
2. Mês 3–4: Identifique os cinco pipelines mais críticos para o negócio e implemente linhagem de coluna nesses fluxos, manualmente se necessário. Use isso para validar o valor da linhagem com stakeholders de negócio e governança.
3. Mês 5–6: Com casos de uso validados, avalie plataformas dedicadas com base nos critérios acima. Priorize cobertura da sua stack atual sobre features avançadas que você não usará imediatamente.
4. Longo prazo: Evolua para linhagem de linha nos domínios que exigem auditoria granular (dados pessoais, financeiros). Integre a linhagem ao processo de revisão de mudanças de schema: nenhuma alteração em coluna fonte deve ser aprovada sem análise de impacto via linhagem.

Linhagem de dados não é um projeto com data de conclusão: é uma capacidade que amadurece junto com a organização de dados. Começar com escopo limitado e expandir incrementalmente é mais sustentável do que tentar cobrir toda a stack de uma vez.