Teradata Data Lineage: Linhagem de colunas para migrações e conformidade.

linhagem de dados Teradata é o mapa em nível de coluna de como os dados se movem por um ambiente Teradata: quais colunas de origem alimentam cada tabela, visualização e relatório de destino, e por meio de quais junções, expressões e QUALIFICAR filtros ao longo do caminho. Gudu SQLFlow Constrói esse mapa automaticamente, analisando seu SQL do Teradata com um analisador de dialeto Teradata dedicado, um dos 39 analisadores específicos de dialeto que ele fornece, e o renderiza como um diagrama interativo e explorável com exportação em JSON, CSV e PNG, além de uma API REST.

Por que a linhagem de dados do Teradata precisa de um analisador sintático do Teradata?

O SQL do Teradata não é o mesmo que ANSI SQL com um logotipo diferente. Um ambiente típico, em funcionamento desde a era BTEQ, carrega décadas de construções específicas de dialetos: DEFINIR e MULTISET definições de tabelas, QUALIFICAR Cláusulas que filtram funções de janela, colunas nomeadas com ponto final e scripts escritos muito antes de alguém imaginar que uma máquina precisaria relê-los. Uma gramática ANSI genérica falha exatamente nessas declarações, e cada declaração que uma ferramenta de linhagem não consegue analisar representa uma lacuna no seu grafo de linhagem.

O SQLFlow adota a abordagem oposta. Ele é construído sobre o Analisador SQL geral, um front-end comercial para compilador SQL desenvolvido desde meados dos anos 2000 e validado com aproximadamente 13.600 conjuntos de testes por dialeto. Seu analisador Teradata lida com SQL da era BTEQ. DEFINIR/MULTISET mesas, QUALIFICARe períodos nomeados como sintaxe Teradata de primeira classe, resolvendo então cada referência de coluna por meio de CTEs, subconsultas, visualizações e SELECIONE * expansão antes de extrair as relações de origem para destino em nível de coluna.

Um exemplo prático: rastreando uma deduplicação QUALIFY

O QUALIFICAR NÚMERO_DA_LINHA() A inserção com deduplicação é um dos padrões mais comuns em data warehouses Teradata e uma maneira confiável de burlar ferramentas de linhagem que só utilizam o padrão ANSI:

INSERT INTO dw.customer_dim (customer_id, full_name, risk_rating) SELECT src.customer_id, TRIM(src.first_nm) || ' ' || TRIM(src.last_nm) AS full_name, src.risk_rating FROM staging.customer_feed src QUALIFY ROW_NUMBER() OVER ( PARTITION BY src.customer_id ORDER BY src.load_ts DESC) = 1;

Execute isso no SQLFlow e o diagrama mostrará dois tipos distintos de relacionamento:

• Linhagem direta: dw.customer_dim.full_name é derivado de staging.feed_do_cliente.primeiro_nm e último_nm através APARAR e concatenação; id_do_cliente e classificação_de_risco passar sem alterações.
• Linhagem indireta (de impacto): carregar_ts nunca chega ao destino, mas decide qual linha sobrevive à desduplicação. O SQLFlow registra isso — juntamente com id_do_cliente em seu PARTIÇÃO POR função — como uma dependência indireta, que pode ser ativada ou desativada separadamente no diagrama.

Essa camada indireta importa. Se alguém alterar a granulação de carregar_ts, o processo de desduplicação silenciosamente começa a manter linhas diferentes, e nenhum gráfico de linhagem puramente direta o alertaria sobre isso. A maioria das ferramentas concorrentes não modela a linhagem indireta; o SQLFlow a trata como um tipo de relacionamento distinto.

Caso de uso 1: linhagem regulatória para bancos no Teradata

A Teradata possui uma ampla base instalada no setor bancário, e os bancos são os que têm as maiores obrigações de rastreabilidade. A norma BCBS 239 exige que as instituições demonstrem a precisão e a integridade da agregação de dados de risco; na prática, isso significa mostrar aos auditores exatamente quais campos de origem alimentam cada dado regulatório e por meio de quais transformações. A rastreabilidade em nível de coluna é essa evidência; a rastreabilidade em nível de tabela é uma aproximação que os auditores questionam cada vez mais.

Planilhas de linhagem mantidas manualmente falham nesse teste um dia após serem criadas. O SQLFlow, por outro lado, deriva a linhagem do próprio SQL: aponte-o para seu DDL do Teradata, definições de visualização e scripts de carregamento, e ele produzirá a proveniência em nível de coluna para cada saída regulamentada — atualizável a cada alteração por meio de varreduras incrementais, com um repositório de linhagem persistente por trás.

Duas características tornam isso viável dentro do ambiente de controle de um banco. Primeiro, o SQLFlow realiza apenas análise estática do código SQL — ele nunca lê os dados das linhas, portanto, nenhum registro de cliente é alterado. Segundo, o Edição On-Premise Executa em Docker ou Kubernetes inteiramente dentro da sua rede, incluindo ambientes isolados da internet (air-gapped), de forma que nem mesmo o texto SQL sai da sua infraestrutura. Implantações corporativas realizam varreduras em lote de conjuntos de dados com mais de 100 bancos de dados e mais de um milhão de colunas, e adaptadores de exportação para DataHub, Microsoft Purview e OpenMetadata alimentam a linhagem de dados com qualquer catálogo que sua equipe de governança já utilize.

Caso de uso 2: migração do Teradata com o mapa de dependências verdadeiro

A maioria dos projetos de linhagem Teradata hoje em dia começa com uma migração: o ambiente está sendo migrado para Snowflake, BigQuery ou Databricks, e alguém precisa definir as dependências entre os bancos de dados. Achar que as migrações dependem de algo com base em nomes de tabelas e conhecimento tácito é o que costuma atrasar os cronogramas. O mapa de dependências deve ser derivado do SQL:

• Seja honesto quanto ao escopo. A linhagem em nível de coluna mostra quais colunas alimentam relatórios subsequentes e quais são peso morto — lógica que nada consome e que você pode desativar em vez de migrar.
• Ondas de migração sequenciais. O gráfico de linhagem expõe a verdadeira ordem de dependência entre as áreas temáticas, permitindo que você mova os feeds upstream antes dos marts que os consomem.
• Pegue as armadilhas dialetais. Construções como QUALIFICAR, DEFINIR A semântica de desduplicação de tabelas e os períodos nomeados exigem uma tradução cuidadosa. A linhagem informa onde cada construção se encontra no fluxo de dados e o que acontece a jusante caso a tradução esteja incorreta.
• Verificar após a transição. Como o SQLFlow analisa ambos os dialetos, você pode gerar Linhagem de floco de neve A partir do SQL reescrito, compare-o com a versão base do Teradata — mesmos destinos, mesmas colunas de origem, ou você tem um erro de tradução.

O mesmo fluxo de trabalho de antes e depois se aplica a outras desativações de MPP legados — veja o linhagem de dados Netezza página para a variante de desativação e a Linhagem de dados Oracle página se o seu ambiente combinar fontes Teradata com Oracle.

Como o SQLFlow ingere um ambiente Teradata

Você pode alimentar o SQLFlow com SQL do Teradata em qualquer escala em que esteja trabalhando:

• Cole uma consulta No navegador, para obter um rastreamento rápido de uma declaração.
• Carregar arquivos — Exportações DDL, definições de visualização, scripts ETL e de carregamento — para uma análise do tamanho de um projeto.
• Conectar via JDBC Para extrair metadados de esquema e definições de objetos diretamente do Teradata.
• Automatizar Utilize a CLI sem interface gráfica ou a API REST para manter a linhagem atualizada como parte do seu pipeline de implantação e exporte os resultados em JSON ou CSV para qualquer configuração personalizada.

Para obter uma visão completa do que o mecanismo faz em todos os 39 dialetos — linhagem direta versus indireta, inferência de diagrama ER a partir de DDL, suporte a dbt, consulta de linhagem de IA — consulte o Ferramenta de linhagem de dados SQL página pilar.

E quanto às ferramentas de código aberto e de catálogo?

Analisadores de código aberto como linhagem sql e sqlglot são realmente úteis para extrair a linhagem de declarações individuais, principalmente em formato ANSI, e as plataformas com foco em catálogo são boas para organizar metadados e propriedade em toda a organização. A lacuna específica do Teradata reside na profundidade da cobertura de dialetos: scripts da era BTEQ, com décadas de existência, QUALIFICARA lógica de desduplicação complexa e o DDL específico do fornecedor são exatamente onde as gramáticas genéricas param de funcionar. Se você estiver avaliando ferramentas para um ambiente Teradata, o teste é simples: execute seu script de carga de produção mais complexo em cada candidato e conte as instruções que retornam com a linhagem completa em nível de coluna.

Opções de implantação e preços

Edição	Ideal para	Preços
Nuvem SQLFlow	Testando a linhagem Teradata hoje; trabalho de análise individual	Plano gratuito; plano premium $49,99/mês
SQLFlow no local	Bancos e entidades regulamentadas — o SQL nunca sai da sua rede; ambiente isolado (air-gapped) é suportado.	$500/mês ou $4.800 (pagamento único) por tipo de banco de dados, instalável em dois servidores.
API REST / CLI / Biblioteca Java	Incorporar a linhagem em pipelines e plataformas	Consulte a página de preços.

Tipos de banco de dados adicionais no ambiente On-Premise custam +$100/mês ou +$1.000 (pagamento único) cada, o que é importante durante a migração, quando você precisa analisar o Teradata e o Snowflake lado a lado. Mais detalhes em [link para a documentação]. página de preços.

Perguntas frequentes

O SQLFlow entende a sintaxe específica do Teradata, como QUALIFY e tabelas SET/MULTISET?

Sim. O SQLFlow usa um analisador sintático de dialeto Teradata dedicado, não uma gramática ANSI genérica. SQL da era BTEQ. DEFINIR/MULTISET definições de tabelas, QUALIFICAR Cláusulas e períodos nomeados são todos analisáveis como SQL do Teradata, portanto, a extração de linhagem abrange as instruções que um analisador genérico rejeita.

O SQLFlow pode ajudar na migração de Teradata para Snowflake ou BigQuery?

Sim. Analise primeiro o ambiente Teradata para obter o verdadeiro mapa de dependências em nível de coluna: o que migrar, o que desativar e em que ordem. Como o Snowflake e o BigQuery também estão entre os 39 dialetos do SQLFlow, você pode analisar o SQL reescrito após a migração e comparar a linhagem com a linha de base do Teradata para verificar a tradução.

O SQLFlow lê dados de nossas tabelas Teradata?

Não. O SQLFlow realiza análises estáticas do código SQL e, opcionalmente, lê metadados do esquema, como definições de tabelas e colunas. Ele nunca consulta dados de linhas. Na versão On-Premise, até mesmo o texto SQL permanece dentro da sua rede.

O Lineage pode ser executado completamente dentro da nossa rede para fins de conformidade?

Sim. O SQLFlow On-Premise é implementado em Docker ou Kubernetes dentro da sua infraestrutura, incluindo ambientes isolados (air-gapped), por £1.500/mês ou £4.800 (pagamento único) por tipo de banco de dados. Ele é escalável para conjuntos de mais de 100 bancos de dados e mais de um milhão de colunas, com varreduras incrementais e adaptadores de exportação para DataHub, Microsoft Purview e OpenMetadata.

Quais entradas do Teradata o SQLFlow aceita?

SQL colado, arquivos carregados (DDL, views, scripts de carregamento) e metadados de esquema em tempo real obtidos via JDBC. Os resultados estão disponíveis como diagramas interativos, JSON, CSV, PNG ou através da API REST.

A linhagem em nível de coluna é suficiente para o BCBS 239?

A linhagem em nível de coluna é a camada de evidência técnica: ela documenta quais campos de origem alimentam cada indicador de risco e por meio de quais transformações, incluindo dependências indiretas de filtros e condições de junção. Seu programa de conformidade define o escopo completo; o SQLFlow mantém a camada de linhagem precisa e atualizada automaticamente, em vez de exigir manutenção manual.