Linhagem no módulo de transformação

Esta página descreve a linhagem observada nos jobs de transformação executados no módulo de transformação.

Identidade da linhagem

No módulo de transformação, a identidade de um dataset segue o padrão do OpenLineage: o par formado por namespace e nome. Isso significa que dois jobs só compartilham o mesmo dataset se estiverem no mesmo namespace e apontarem para o mesmo nome.

Por isso, a documentação e os testes tratam o namespace compartilhado como a configuração correta para ligar produtores e consumidores de um mesmo ativo.

Linhagem entre jobs

A base do módulo de transformação é a ligação entre um job que escreve um dataset e outro job que lê esse mesmo dataset.

Os cenários cobrem dois comportamentos importantes:

• quando writer e reader compartilham o mesmo namespace, a grafo de linhagem fica conectada;
• quando cada job usa um namespace diferente, o dataset passa a ser distinto e o grafo fica isolado.

Isso é o que garante que a plataforma saiba seguir um ativo da origem até o consumo downstream.

Linhagem por coluna

O runner também valida linhagem em nível de coluna para transformações SQL e tabelas derivadas.

Os cenários cobertos mostram:

• CTAS com renomeação de colunas;
• expressões derivadas, como multiplicação de colunas para calcular métricas;
• joins com resolução correta de alias;
• rastreamento das colunas de saída até as colunas de entrada reais.

Na prática, isso permite entender não apenas qual tabela foi gerada, mas também quais campos alimentaram cada campo de saída.

Arquivos, pandas e chamadas externas

A linhagem de transformação também registra o uso de arquivos locais e chamadas HTTP:

• arquivos lidos ou escritos por open() e bibliotecas como Pandas entram como datasets;
• arquivos de configuração e artefatos não-dados podem ser filtrados para não poluir a grafo;
• chamadas GET, HEAD e OPTIONS entram como entradas;
• chamadas de escrita, como POST, entram como saídas.

Esse comportamento é importante para que fluxos híbridos, que combinam arquivo, rede e banco, continuem rastreáveis.

Snowflake e Snowpark

Os cenários de Snowflake validam a construção da faceta de linhagem por coluna a partir de SQL realista, incluindo:

• CTAS;
• resolução de alias em joins;
• normalização de identificadores no dialeto Snowflake.

Já o cenário de Snowpark valida a emissão de dataset e da faceta de schema. O teste de linhagem por coluna ainda está marcado como expectativa futura, o que deixa visível um gap conhecido no instrumentador.

O que a documentação garante hoje

Hoje a documentação deste módulo descreve com clareza que as transformações no módulo de transformação cobrem:

• conexão entre jobs por dataset compartilhado;
• isolamento por namespace quando necessário;
• linhagem de colunas para transformações SQL suportadas;
• rastreamento de arquivo, Pandas e HTTP;
• emissão de schema em Snowpark;
• identificação explícita dos pontos em que a coluna ainda não está totalmente instrumentada.

Próxima página

Volte para a visão geral do módulo de linhagem para navegar entre coleta e transformação.