Data Lineage, ou linhagem de dados, descreve e documenta de onde um dado veio, por quais processos e regras passou e quais indicadores ou sistemas utilizam seu resultado. Em Business Intelligence
Confira!
Data Lineage, ou linhagem de dados, descreve e documenta de onde um dado veio, por quais processos e regras passou e quais indicadores ou sistemas utilizam seu resultado. Em Business Intelligence, essa rastreabilidade permite investigar divergências, avaliar impactos de alterações e demonstrar a proveniência de números usados na gestão. Não se resume a um mapa de tabelas: precisa representar transformações, versões, dependências e, quando exigido, execuções concretas. A profundidade da captura deve ser proporcional à criticidade de cada informação e às decisões que ela sustenta.
Fundamentos e escopo da rastreabilidade
O que Data Lineage demonstra
Data Lineage é a representação verificável do percurso de uma informação entre sua origem, suas transformações e seus destinos de consumo. Um registro de venda pode surgir no ERP, ser extraído por API, passar por staging, integrar uma Fact Table e alimentar um indicador executivo. Para explicar o resultado, a organização precisa reconhecer não só a sequência de componentes, mas qual versão do dado, da regra e do processamento foi efetivamente usada. Um diagrama estático de arquitetura mostra o caminho previsto; a linhagem operacional permite examinar o que ocorreu em uma execução específica, incluindo falhas e reprocessamentos. O nível de detalhe necessário depende do risco associado ao indicador e da pergunta que se pretende responder.
Não se deve confundir Data Lineage com Data Quality. A qualidade avalia se os dados cumprem critérios de uso, enquanto a linhagem identifica como foram produzidos e onde são consumidos. Um conjunto pode ter linhagem completa e ainda conter medições incorretas; pode também apresentar números plausíveis sem nenhuma capacidade de rastrear a origem. Em uma auditoria de Business Intelligence, ambas as evidências são complementares. A responsabilidade editorial deste artigo é tratar da proveniência, dos vínculos de dependência, da evolução das regras e do impacto de alterações. Métodos para corrigir duplicações e definir thresholds de qualidade pertencem ao tema específico de Data Quality.
Data Lineage, metadata e Data Catalog
Um Data Catalog organiza a descoberta de ativos, descrições, classificação, proprietários e políticas de uso. Data Lineage acrescenta relações dirigidas entre esses ativos e os processos que os transformam. Uma coluna descrita no catálogo não prova, sozinha, que seu valor chegou ao indicador por determinado processamento. Por outro lado, a captura automática de uma dependência técnica pode mostrar apenas que uma tabela foi consultada, sem dizer qual definição de receita ou de disponibilidade foi aplicada. Por isso, os registros de linhagem precisam de contexto semântico fornecido por Data Owners e por quem mantém os modelos analíticos.
Em implementação prática, o catálogo pode apontar para datasets, jobs, runs e atributos, com chaves que os identifiquem de forma estável. Os produtores de eventos de linhagem informam inputs e outputs, enquanto um serviço de metadados conserva as relações para consultas de impacto. Nomes de tabelas não devem ser o único identificador quando existem ambientes de desenvolvimento, homologação e produção. Namespace, ambiente e versão precisam estar claros. Sem isso, relatórios podem mostrar uma conexão entre fontes homônimas de sistemas distintos, atribuindo a um resultado uma origem que nunca participou do cálculo.
Granularidade da linhagem
Data Lineage pode ser registrado no nível de sistema, dataset, tabela, coluna, transformação ou execução. Um mapa de sistemas é útil para governança de alto nível, mas não permite explicar por que um campo em um dashboard mudou após uma alteração em uma expressão SQL. A linhagem de colunas identifica quais atributos alimentam outro atributo; a linhagem de execução associa aquele relacionamento a um job e a um momento. Quanto mais detalhada for a captura, maior pode ser o custo operacional e a necessidade de manutenção. O projeto deve priorizar indicadores críticos e transformações em que a perda de rastreabilidade cria risco concreto.
Nem toda operação pode ser deduzida com segurança apenas pela leitura de SQL ou pelo nome de um job. Procedimentos armazenados, transformações em código, notebooks, APIs externas, ferramentas de BI e etapas manuais podem exigir instrumentação ou declaração controlada. O que não foi observado precisa ser indicado como lacuna, em vez de preenchido por inferência. Uma relação presumida e apresentada como comprovada produz falsa confiança. O aceite deve diferenciar linhagem declarada pela engenharia, linhagem capturada na execução e documentação de negócio aprovada.
A integração de fontes operacionais e corporativas exige que interfaces, identificadores e regras de transformação sejam definidos antes de produzir indicadores compartilhados. A rastreabilidade começa na responsabilidade por essas conexões.
Modelos, eventos e rastreabilidade
Dataset, Job, Run e Facets
Na especificação OpenLineage, a captura de metadados utiliza entidades como Dataset, Job e Run, complementadas por Facets. Um Dataset identifica um conjunto de dados; um Job descreve uma atividade capaz de processá-lo; um Run representa uma execução concreta. Facets registram informações adicionais, incluindo schemas, contexto de execução e atributos de entrada ou saída. A separação é decisiva porque a definição de um processo pode permanecer estável enquanto uma execução falha, utiliza outra versão de código ou recebe um input inesperado. O modelo permite investigar a produção de uma saída sem concluir que toda execução de um Job produziu o mesmo resultado.
Uma implementação deve acordar convenções de namespace, identificação de datasets e associação entre runs. Quando dois Jobs leem os mesmos datasets, isso não significa que produzem os mesmos outputs. A captura de relações precisa preservar as ligações verdadeiras entre inputs e outputs, evitando construir arestas artificiais por associação cartesiana. A própria documentação do OpenLineage distingue facets sobre Jobs, Runs e Datasets e descreve recursos para expressar relações específicas. O objetivo não é preencher um grafo visualmente completo, mas registrar o conjunto mínimo de dependências que possa ser explicado e auditado.
Linhagem estática versus execução observada
Um mapa estático declara que um dashboard depende de uma tabela, que por sua vez depende de uma API. Ele é útil para planejamento, impacto e arquitetura. Entretanto, se a API não retornou registros no último fechamento, o mapa não demonstra a atualização efetiva do indicador. A linhagem operacional adiciona estado, timestamp, identificador de execução e resultado, permitindo distinguir comportamento previsto de dado efetivamente processado. Uma solução madura conserva ambas as perspectivas: a declarada para governança e a observada para suporte e auditoria.
Em rotinas que fazem backfill, essa distinção evita interpretações equivocadas. O processamento executado hoje pode recalcular registros de um mês anterior, utilizando versões diferentes de regra e origem. Sem registrar a janela de dados e a versão do Job, o histórico de atualização do dashboard pode sugerir que o dado foi gerado na data corrente. A especificação deve definir como relacionar execução, partição, versão de transformação e publicação. A evidência de aceite inclui demonstração com carga regular, reprocessamento e alteração controlada de regra.
Data Lineage no nível de coluna
A rastreabilidade de coluna responde perguntas que um grafo de tabelas não consegue resolver: quais campos alimentaram o valor apresentado em uma medida, quais conversões de unidade foram aplicadas e quais atributos podem ser afetados pela remoção de um campo de origem. Imagine a métrica de disponibilidade calculada a partir de horários de falha e restauração. O relacionamento deve descrever quais timestamps participam da medida, como exceções são tratadas e onde fica documentada a regra de negócio. Exibir somente a ligação entre duas tabelas não comprova a semântica desse cálculo.
Há limites técnicos importantes. SQL dinâmico, lógica condicional, código externo e medidas criadas diretamente no Semantic Model podem não ser cobertos por um analisador automático. Um catálogo que extrai apenas SQL precisa declarar sua cobertura e registrar componentes fora do escopo. Em vez de forçar uma única ferramenta a representar tudo, convém combinar metadados capturados, documentação de medidas e contratos de interface. Os testes devem escolher colunas com transformações simples e complexas para confirmar a fidelidade do mapeamento.
Arquitetura de captura e governança
Instrumentação dos fluxos analíticos
A captura de Data Lineage pode ocorrer nos conectores de ingestão, orquestradores, transformações SQL, pipelines de Spark, modelos semânticos e componentes de publicação. Cada ponto observa uma parte do caminho. Para evitar lacunas, a arquitetura identifica sistemas produtores, mecanismos de extração, transformações, armazenamento e consumo, associando os metadados a um mesmo identificador de cadeia. A captura de um evento não pode interromper a operação crítica quando o serviço de metadados estiver indisponível; o projeto precisa decidir como fazer buffering e posterior envio sem criar registros de execução falsos.
A instrumentação deve ter custo conhecido. Coletar detalhes de todas as queries em alta frequência pode gerar volume e sensibilidade superiores ao valor analítico da linhagem. Em algumas operações, basta capturar mudanças de schema e Jobs relevantes; em outras, o requisito de auditoria demanda evidência por execução. Segurança e privacidade participam dessa decisão, porque nomes de campos, consultas e logs podem revelar informações que não deveriam ficar amplamente acessíveis. A plataforma de metadados precisa ter permissões proporcionais ao papel de quem consulta e administra as relações.
Grafo de dependências e análise de impacto
Uma utilidade central é estimar o efeito de uma mudança antes de executá-la. Se o ERP altera o código de uma unidade, o Data Owner deve identificar quais tabelas, medidas e relatórios dependem do campo. A busca de impacto percorre dependências downstream, mas a direção da ligação importa: conhecer quem usa um dado não demonstra que todos os consumidores serão necessariamente afetados pela alteração. Algumas transformações ignoram o campo modificado, enquanto outras fazem conversão ou fallback. A análise deve combinar o grafo técnico com a especificação do contrato semântico.
O mesmo mecanismo apoia investigação upstream. Quando um indicador diverge, a equipe percorre as dependências até localizar fontes e transformações potencialmente responsáveis. O processo precisa separar a localização da origem do diagnóstico da causa. Uma diferença pode decorrer de regra de negócio aprovada, atraso de captura, atualização cadastral ou defeito real. O grafo ajuda a limitar o universo de investigação, mas a conclusão exige logs, amostras e reconciliação. Registros obsoletos devem ser desativados ou versionados para que o mapa não apresente consumidores que já não existem.
Ownership, classificação e retenção
Cada ativo de dados relevante deve possuir responsável técnico e responsável pelo significado. Um Data Engineer pode garantir a execução de um Job, mas a definição de faturamento líquido pertence ao domínio de negócio. A linhagem precisa indicar quem autoriza mudanças em regras e em dados mestres. Classificações de sensibilidade também devem percorrer os pontos de consumo: um atributo sujeito a restrições não perde a necessidade de avaliação apenas porque foi transformado ou agregado. O acesso a metadados é diferente do acesso ao dado, porém também precisa de política de segurança.
A análise independente das dependências e das versões das regras permite avaliar o impacto de mudanças antes que elas afetem relatórios e decisões gerenciais. O aceite precisa ser sustentado por evidências, não por relações presumidas.
Retenção de linhagem deve ser coerente com as janelas de auditoria e de suporte. Manter indefinidamente eventos detalhados de processamento pode ser custoso e desnecessário; conservar só o estado atual pode impedir reconstrução de decisões passadas. Uma política possível separa visão de dependências atual, histórico de versões e evidência de execuções críticas. A escolha depende do uso, das obrigações aplicáveis e dos riscos. Não se deve afirmar que um determinado período é exigência universal sem verificar contrato, legislação e classificação da informação.
A rastreabilidade faz parte da confiabilidade dos resultados, mas não substitui os controles de Data Quality nem os mecanismos de reprocessamento discutidos em Data Pipeline.
Exemplos de aplicação e controles
Rastrear indicadores operacionais de vídeo
Considere uma operação que cruza eventos de vídeo com horários de funcionamento e registros comerciais. Um indicador de circulação resulta de contagens estimadas e regras que selecionam áreas, períodos e equipamentos elegíveis. A linhagem deve permitir responder quais câmeras e quais versões das configurações de contagem forneceram os eventos, qual agrupamento temporal foi utilizado e onde o dado foi enriquecido com a unidade de negócio. Uma queda no gráfico pode refletir mudança do fluxo ou alteração técnica na captura. Sem rastreabilidade, esses cenários podem ser indistinguíveis no resultado final.
O mapa não transforma contagem estimada em identificação individual nem atribui Accuracy à ferramenta. Ele mostra a proveniência das estimativas e as transformações, enquanto o processo de Data Quality verifica cobertura, precisão e completude. Se uma câmera for substituída, a cadeia precisa conservar a identificação do dispositivo anterior e a data de mudança. O teste de aceitação inclui reproduzir uma janela com registros conhecidos, aplicar uma nova regra e demonstrar o impacto nos consumidores. A finalidade é explicar as diferenças sem alegar resultados reais de clientes.
Rastrear indicadores de produção e manutenção
Em ambiente industrial, séries do Data Historian podem alimentar indicadores de disponibilidade e consumo associados a ordens de serviço do ERP ou CMMS. A cadeia analítica contém fontes com granularidades distintas, por isso a linhagem deve conservar as regras de agregação e os filtros aplicados. Um valor diário pode ter origem em milhares de medições; registrar cada amostra individual no grafo pode ser inadequado, mas é necessário demonstrar qual janela, equipamento, unidade e regra de cálculo participaram da medida. A arquitetura deve proteger a separação entre OT e IT.
Uma auditoria pode selecionar um período, reconstruir o conjunto de entradas e confirmar que a medida do Semantic Model corresponde às regras aprovadas. Isso exige guardar identificadores de versão, histórico de alterações e evidência de execução, em vez de confiar exclusivamente no dashboard mais recente. A linhagem também permite avaliar efeitos de uma troca de sensor, atualização de API e alteração de cadastro de ativos. O projeto deve explicitar o ponto em que a observabilidade do dado termina e começa a responsabilidade pela calibração ou manutenção do equipamento.
Linhagem em indicadores financeiros
Indicadores financeiros exigem clareza sobre fatos de origem, documentos contábeis, cancelamentos, impostos, créditos e janelas de fechamento. Uma medida de receita que usa registros de faturamento pode divergir legitimamente da análise baseada em pedidos. A linhagem precisa apontar qual conjunto foi escolhido e qual política de exclusões e apropriação é aplicada. A mesma sigla pode identificar medidas semanticamente diferentes, e um grafo não resolve essa divergência sem catálogo de definições. Para auditoria, é importante registrar a regra efetiva, sua aprovação e suas alterações.
Quando o ERP é atualizado ou uma interface passa de exportação por arquivo para API, a organização deve comparar a proveniência antes e depois da mudança. A reconciliação precisa considerar ajustes retroativos, documentos estornados e eventos que mudaram de status. A trilha de transformação deve identificar se uma diferença surgiu na captura, na regra ou no próprio lançamento de origem. Assim, a análise de impacto se torna instrumento de controle, e não apenas uma visualização de tabelas conectadas.
Implementação, auditoria e critérios de aceite
Plano de implantação em camadas
O levantamento inicial inventaria indicadores críticos, suas fontes, transformações, donos e consumidores. Em seguida, a equipe classifica a cobertura disponível da instrumentação e as lacunas. É preferível começar por um conjunto que atravesse ao menos dois sistemas e uma transformação semântica relevante, pois um piloto restrito a uma única tabela não prova a utilidade do método. A arquitetura precisa separar a captura de eventos, o armazenamento de metadados, a consulta ao grafo e a documentação de regras. A seleção de produto ou ferramenta vem depois dos requisitos de evidência.
Um piloto deve incluir uma alteração planejada de schema e uma execução com falha. O teste compara o mapa declarado com a trilha observada, verifica como os consumidores são identificados e se a versão anterior permanece consultável. Se a captura for parcial, o relatório precisa tornar essa limitação evidente. A homologação não deve aceitar relações inferidas sem lastro, sobretudo quando serão usadas para aprovar mudanças ou explicar indicadores contratuais. O avanço para outros sistemas depende de ownership e procedimentos de atualização dos metadados.
Evidência de auditoria e testes regressivos
Um pacote de evidências pode reunir inventário de datasets e Jobs, identificadores de execução, versões de schema, regras de transformação, mapa upstream/downstream e logs relacionados. O auditor deve conseguir selecionar um KPI e percorrer a cadeia até as fontes relevantes, sem precisar reconstruir mentalmente uma série de scripts. Quando uma regra é modificada, o ensaio regressivo demonstra quais métricas foram alteradas e quais permaneceram equivalentes. Isso exige amostras reconciliadas e critério de aceite anterior à mudança.
É necessário testar também o desaparecimento e a renomeação de objetos. Uma tabela descontinuada não pode permanecer como origem ativa por tempo indefinido; uma coluna renomeada deve preservar correspondência ou indicar ruptura. O teste com falha de processamento deve comprovar que a ausência de metadados de uma execução não produz evidência fictícia. É legítimo registrar informação indisponível. O erro é apresentar uma cadeia incompleta como se provasse integralmente a origem do número.
Métricas de cobertura e decisão de contratação
Indicadores de governança podem medir percentual de KPIs críticos com origem identificada, percentual de Jobs instrumentados, ativos sem owner, exceções de schema sem avaliação de impacto e tempo de investigação de divergências. Cada percentual precisa definir população elegível e não deve ser tratado como garantia de exatidão dos dados. Uma cobertura de linhagem pode ser alta no Data Warehouse e baixa no Semantic Model; por isso os indicadores devem ser separados por etapa. A evolução deve ser avaliada por redução de lacunas e capacidade comprovada de reconstrução.
A confiabilidade da informação exige que a organização estabeleça processos de revisão, tratamento de exceções e atualização dos fluxos documentados. Sem essa governança, a linhagem deixa de refletir a operação efetiva.
Em contratação, o escopo precisa indicar fontes incluídas, tipos de linhagem exigidos, pontos de instrumentação, integrações suportadas, retenção, segurança, documentação e critérios de aceite. Também deve separar o que o fornecedor captura automaticamente do que depende de cadastro manual ou integração futura. A continuidade após a entrega depende de processos para alteração de Jobs, atualização de ownership e revisão de vínculos. Sem essa manutenção, o mapa de dependências rapidamente deixa de representar a operação real.
| Evidência | O que demonstra | Limitação que deve ser declarada |
|---|---|---|
| Relação entre datasets | Dependência declarada ou capturada | Não prova execução bem-sucedida |
| Evento de Run | Processamento concreto, horário e status | Não garante correção semântica |
| Column-level Lineage | Dependência entre campos | Pode omitir lógica dinâmica externa |
| Versão da regra | Cálculo aplicado no período | Exige registro de aprovação |
| Reconciliação do KPI | Coerência entre origem e medida | Depende de referência confiável |
Ensaio de impacto e trilha de decisão
Considere uma alteração planejada de schema no ERP em que o identificador de unidade passa a ter novo formato e a classificação regional é reorganizada. Antes de executar a mudança, a equipe deve consultar a linhagem downstream do campo e verificar quais transformações realmente o usam. Em um fluxo típico, o código alimenta um Data Contract, a etapa de normalização, uma Dimension Table e diversos indicadores por região. O mapa deve mostrar esses vínculos, mas também indicar quais deles foram observados automaticamente e quais foram declarados. A decisão de liberar a mudança exige comprovar a atualização do mapeamento, o tratamento de unidades históricas e os consumidores que permanecem na versão anterior.
O ensaio começa com um conjunto de registros de referência contendo unidades ativas, desativadas, renomeadas e sem correspondência. A equipe registra os identificadores de Job e Run, o dataset de entrada, a versão da transformação e os totais esperados. Em seguida, executa o processamento com o schema alterado, compara o catálogo de dependências e reconcilia indicadores por unidade e período. Se o resultado divergir, não basta editar uma descrição no Data Catalog; deve ser possível apontar a etapa que mudou e reproduzir a diferença. O mesmo teste deve alcançar as medidas construídas na camada de BI, pois uma mudança de relacionamento pode afetar o indicador mesmo quando a tabela curada permanece idêntica.
Para avaliar a resposta a falhas, um Run deve ser interrompido depois de iniciar a leitura, mas antes de concluir a publicação. A consulta de linhagem precisa representar a execução incompleta e não atribuir a ela um dataset validado. Após o replay, a trilha deve permitir distinguir a execução original da recuperação, mantendo as evidências de data, código e resultado. Esse teste revela se a solução de metadados registra somente o grafo de projeto ou consegue apoiar investigação operacional. Quando a captura falha, a lacuna deve ser explicitada; dados de execução ausentes não podem ser reconstruídos artificialmente a partir da última definição conhecida.
A documentação final inclui a matriz de ativos afetados, os responsáveis por cada decisão, a diferença entre relações confirmadas e inferidas e os testes regressivos. Uma aprovação técnica pode ser condicionada à atualização de um relatório ou à correção de mapeamento de identidade; essa condição deve ficar registrada para auditoria. O aceite não precisa exigir o mesmo detalhe para todos os datasets da organização, mas deve garantir cobertura suficiente para os indicadores críticos definidos no escopo. O ganho prático é encurtar investigações e permitir mudanças sem perder a capacidade de explicar decisões anteriores.
Controle de acesso aos metadados e confiabilidade do grafo
Uma plataforma de linhagem pode revelar informações estratégicas mesmo quando não disponibiliza os próprios registros operacionais. Nomes de tabelas e colunas podem indicar dados financeiros, informações pessoais, sistemas críticos e relações entre fornecedores. Por isso, a política de acesso aos metadados deve separar quem pode consultar dependências, alterar definições, aprovar uma regra e administrar a plataforma. Um usuário que precisa investigar uma divergência não precisa necessariamente visualizar detalhes sensíveis de todas as fontes. A estrutura de ownership e classificação pode orientar permissões, enquanto logs de alteração registram quem modificou uma relação declarada. Uma mudança de documentação sem evidência operacional precisa ser tratada como tal.
Além das permissões, importa a confiabilidade do próprio grafo. Uma integração desativada não deve continuar aparecendo como dependência operacional atual, e um processamento que falhou precisa manter status condizente. O plano de manutenção deve estabelecer revisão de metadados após mudança de schema, implantação de nova versão, transferência de ownership e remoção de sistemas. O backlog de inconsistências precisa ter responsáveis e critérios de prioridade. Quando o serviço de captura de metadados está indisponível, a integração de negócio pode continuar operando; nesse caso, a documentação deve apontar exatamente qual período ficou sem observação, em vez de afirmar cobertura integral.
Em uma auditoria interna, a equipe pode escolher aleatoriamente três indicadores de domínios diferentes e solicitar a cadeia upstream, a versão da transformação e os consumidores downstream. A mesma consulta é repetida depois de uma alteração deliberada em um campo usado por apenas um deles. A solução deve indicar o efeito restrito sem criar dependências fictícias. Esse teste avalia utilidade do grafo, não só sua aparência. A correção de uma relação errada deve manter trilha de justificativa e aprovação para que a documentação não possa ser manipulada sem responsabilização.
Considerações finais
Uma organização só consegue explicar seus indicadores quando conhece as fontes, regras, transformações e versões que participaram da sua construção. Data Lineage transforma essa dependência em evidência consultável: permite investigar uma divergência, estimar impacto de mudanças e distinguir resultados previstos de execuções efetivamente observadas. Esse benefício depende tanto da instrumentação quanto da governança de definições de negócio. Um grafo tecnicamente completo, mas sem ownership e contexto semântico, pode ser tão enganoso quanto um relatório sem rastreabilidade.
A implantação deve priorizar fluxos de maior criticidade e registrar lacunas de captura sem inventar relações. Dataset, Job, Run e Facets permitem estruturar a observação, mas são os testes de reconciliação, as versões de transformação e a documentação de aceite que demonstram se a trilha suporta uma decisão. O resultado esperado é reduzir a investigação baseada em suposições e permitir que alterações de sistemas sejam avaliadas antes de comprometer indicadores corporativos.
Em uma decisão de contratação ou de aprovação de mudança, o critério principal não deve ser a quantidade de relações exibidas no grafo, mas a cobertura de indicadores críticos e a capacidade de reproduzir seus resultados. A equipe deve apresentar um mapa upstream/downstream, evidências de Runs quando exigidas, registro das versões de transformação e matriz de impacto sobre consumidores. Relações declaradas manualmente precisam de responsável e ciclo de revisão; relações inferidas não podem ser tratadas como prova de execução. A escolha entre captura automática e documentação assistida depende da arquitetura instalada e do risco de cada processo. A governança deve conservar a história necessária à auditoria, proteger metadados sensíveis e registrar lacunas sem mascará-las. Dessa forma, o Data Lineage pode orientar manutenção, evolução e avaliação de riscos, mantendo seu papel distinto da validação de Data Quality.
Referências técnicas
[1] OPENLINEAGE. OpenLineage Specification: Facets & Extensibility. Disponível em: https://openlineage.io/docs/spec/facets/
[2] OPENLINEAGE. Lineage Job Facet. Disponível em: https://openlineage.io/docs/spec/facets/job-facets/lineage/
[3] OPENLINEAGE. Lineage Dataset Facet. Disponível em: https://openlineage.io/docs/spec/facets/dataset-facets/lineage/
[4] WORLD WIDE WEB CONSORTIUM (W3C). PROV-O: The PROV Ontology. Disponível em: https://www.w3.org/TR/prov-o/
Perguntas frequentes
É a representação da proveniência e das dependências de dados entre fontes, processos, transformações e consumidores. O detalhamento adequado permite explicar como um indicador foi produzido.
Data Lineage identifica origem e percurso; Data Quality avalia adequação dos registros às regras do uso. Uma trilha completa não garante que a medição na origem esteja correta.
Não. O Data Catalog organiza descrição, descoberta e governança de ativos. Data Lineage acrescenta relações de dependência e informações sobre transformações ou execuções.
É a rastreabilidade das dependências no nível de campos, incluindo colunas que alimentam medidas e atributos derivados. Sua cobertura pode ser limitada por transformações externas ou código dinâmico.
Dataset representa um conjunto de dados, Job uma atividade definida e Run uma execução dessa atividade. Facets adicionam metadados sobre estrutura, contexto e resultados.
Percorre-se a cadeia upstream até as fontes e Jobs, conferindo versões, logs, datas, transformações e amostras reconciliadas. O grafo orienta o diagnóstico, mas não substitui provas do erro.
Permite identificar consumidores downstream de campos, tabelas e transformações que podem ser afetados por mudanças. A análise deve confirmar se a dependência relevante utiliza o componente alterado.
Em várias ferramentas, sim, por instrumentação de Jobs, parsing de SQL e coleta de eventos. Cobertura incompleta e lógica externa precisam ser declaradas, sem inferir vínculos inexistentes.
Depende de criticidade e requisitos de auditoria. Para alguns ativos basta linhagem estrutural; para outros é necessário guardar Run, versão, janela e resultado efetivo.
Documenta-se a versão, a regra de correspondência e os consumidores afetados; executam-se testes regressivos e preserva-se a possibilidade de consultar o histórico relevante.
Inventário de fontes, grafo de dependências, versões de transformações, amostras reconciliadas, eventos de execução quando aplicáveis e testes de impacto e mudança de schema.
Sim. Pode rastrear dispositivos, configurações, eventos, janelas, transformações e KPI, sem converter estimativas de vídeo em identificação de pessoas ou prova automática de Accuracy.
Materiais técnicos complementares
Conteúdos principais sobre o tema
- Data Quality: dimensões, controles e critérios de aceite
- Data Pipeline: arquitetura, observabilidade e critérios de aceite
- Data Lake x Data Warehouse
- Modelagem Dimensional
Conteúdos técnicos correlatos
- Dashboards de Business Intelligence
- Business Intelligence Industrial
- Business Intelligence e Dados de Vídeo
