Data Quality é a adequação dos dados ao uso pretendido, verificada por regras de completude, validade, consistência, unicidade, atualidade e precisão. Dados disponíveis p
Confira!
Data Quality é a adequação dos dados ao uso pretendido, verificada por regras de completude, validade, consistência, unicidade, atualidade e precisão. Dados disponíveis podem ainda produzir indicadores errados caso ocorram duplicações, lacunas de registros, unidades equivocadas ou cadastros incompatíveis. A qualidade precisa ser gerida como requisito de engenharia, com testes, responsáveis, tratamento de exceções e evidência verificável.
Dimensões, critérios e medição de Data Quality
Completude, validade e consistência
Completude depende de universo esperado: uma loja sem vendas pode estar fechada ou com falha de integração. Validade verifica formatos, faixas e domínios; consistência compara regras entre campos e sistemas. Um dado pode ser válido quanto ao formato e incorreto quanto ao significado. Cada regra deve informar fonte, denominador, janela, tolerância, severidade e consequência para as decisões que utilizam a informação.
A definição do escopo deve considerar risco, governança e limites técnicos. Uma regra insuficientemente especificada pode gerar resultados plausíveis porém contraditórios. As responsabilidades e os parâmetros de aceite precisam ser explícitos para permitir rastreabilidade e revisão independente.
Data Quality como requisito mensurável
A definição de qualidade deve começar pela decisão suportada pelo dado. Para cada Critical Data Element, é necessário descrever fonte, uso, regra, método de medição, consequência de erro e responsável pela resolução. Uma taxa de 99% de registros completos pode ser insuficiente quando o 1% ausente corresponde a ativos críticos, enquanto a ausência de um campo opcional pode não afetar qualquer indicador. Assim, não existe score de qualidade universal que substitua uma análise de impacto. Os thresholds são decisões documentadas, sujeitas à revisão quando processos e riscos mudam.
Critical Data Elements e impacto
A escolha dos Critical Data Elements precisa considerar processos e indicadores que dependem de cada campo. Identificação de equipamento, data de ocorrência, estado de manutenção e unidade de medida podem ser críticos em determinados ambientes, enquanto atributos descritivos opcionais têm outro nível de prioridade. Para cada elemento, especificar fonte, responsável, dimensões de qualidade aplicáveis, frequência de controle e consequência do descumprimento. Uma falha em dado crítico não deve ser escondida pela média de um score global elevado. O programa de qualidade precisa apresentar resultados por regra e por fonte, incluindo tendência e severidade. Critérios de aceitação devem corresponder ao impacto real sobre decisões e obrigações contratuais. A priorização pode ser revista após incidentes e alterações operacionais, mas a mudança de threshold deve manter histórico e justificativa formal.
Profiling e estabelecimento de baseline
Data Profiling examina distribuição, tipos, valores nulos, cardinalidade, faixas, padrões e correlações antes de estabelecer controles. O objetivo não é transformar toda anomalia em erro. Um pico de circulação pode decorrer de evento legítimo; um salto de consumo pode sinalizar operação excepcional ou defeito de instrumentação. O baseline precisa contemplar períodos representativos, sazonalidade e mudanças planejadas. A amostra deve declarar cobertura e limitações. A análise de distribuição ajuda a escolher testes específicos, mas não comprova Accuracy por si só. A validação final depende de regras e fontes de referência.
Data Profiling sem conclusões precipitadas
Análise exploratória de distribuição, cardinalidade, valores ausentes e padrões ajuda a identificar hipóteses de erro. Entretanto, outliers não são automaticamente defeitos. Um pico de ocupação pode decorrer de um evento real; uma mudança abrupta de consumo pode resultar de nova rotina produtiva. Data Profiling deve ser realizado sobre janelas representativas, considerando dias úteis, eventos, sazonalidade e mudanças planejadas. O processo precisa comparar resultados com fontes de referência quando possível. Amostras enviesadas podem criar limites de normalidade inadequados, fazendo a validação rejeitar dados corretos ou aceitar erros persistentes. A documentação deve separar estatística observada, regra de negócio validada e hipótese ainda não confirmada. Controles permanentes surgem dessa análise e precisam ser reavaliados quando o comportamento operacional muda.
Unicidade, Accuracy e Freshness
Unicidade depende de identificação estável de eventos; dois registros semelhantes podem ser ocorrências legítimas. Accuracy demanda comparação com referência ou método verificável, especialmente em Video Analytics e sensores. Freshness diferencia horário da ocorrência, chegada e processamento. A exigência de atualização deve seguir a criticidade do processo e não um padrão genérico de baixa latência.
A escolha de ferramentas deve ocorrer depois da definição das necessidades e das evidências esperadas. O projeto precisa preservar a separação entre a função de cada sistema e a interpretação posterior das informações. Mudanças de interface, critérios e período exigem registro e validação antes da produção.
Interfaces e Data Contracts precisam preservar identidade, tempo e significado dos eventos para evitar a publicação de indicadores inconsistentes.
Integridade, tempo e rastreabilidade
Controles de integridade entre sistemas
A consistência entre sistemas não pode ser verificada apenas comparando o número total de linhas. Diferentes aplicações podem representar o mesmo processo com eventos e horários distintos. Um ERP pode registrar a venda confirmada, enquanto a aplicação de atendimento registra tentativas. A reconciliação deve documentar a unidade de comparação, o período, as exclusões e o tratamento de correções. Chaves de entidade, códigos de produto e identificadores de ativo precisam de mapeamento governado. Divergências devem ser classificadas entre atraso legítimo, incompatibilidade semântica, perda de registro e erro de modelagem.
Integridade referencial e cadastros
Uma transação com chave de unidade inexistente pode ser tecnicamente válida no sistema de origem e inutilizável para uma análise segmentada. A integridade referencial exige catálogo de identidades, vigência de cadastros e tratamento de mudanças. O mesmo equipamento pode receber novo código após substituição, e a mesma chave operacional pode ser reaproveitada em circunstâncias específicas. A solução precisa decidir quando relacionar históricos e quando separar entidades. A deduplicação de cadastros não deve depender apenas de similaridade textual, pois nomes quase iguais podem representar ativos diferentes. Exceções devem ser submetidas a responsáveis de negócio e registradas. A análise deve distinguir registros que aguardam cadastro, chaves realmente inválidas e alterações retroativas. Cada situação tem impacto diferente sobre completude, consistência e indicadores históricos.
Validação temporal de séries
Em séries temporais, o timestamp deve representar corretamente a ocorrência e não apenas a chegada ao destino. Eventos fora de ordem, duplicados e tardios exigem regras explícitas. A frequência de amostragem deve corresponder às necessidades do indicador; lacunas não podem ser preenchidas automaticamente por interpolação sem indicar que o valor foi estimado. Para energia, produção e manutenção, a escolha entre valor instantâneo, acumulado ou médio influencia a agregação. A qualidade temporal deve ser testada nas fronteiras de turno, no fechamento de período e durante interrupções de comunicação.
Data Lineage e observabilidade
Data Lineage identifica de onde o registro veio, quais transformações sofreu e onde foi utilizado. O monitoramento mede erros, atrasos, violações de schema, mudanças inesperadas de distribuição e confiabilidade por fonte. Sem trilha de origem, dois dashboards podem apresentar resultados diferentes e parecer igualmente corretos. As regras precisam acompanhar versões de processo e de modelo semântico.
Exemplos operacionais devem ser tratados como hipóteses de projeto, não como resultado real da empresa. O valor de um método se demonstra por controles verificáveis, reconciliação e capacidade de explicar divergências. A análise de risco deve orientar o nível de documentação e de teste.
Métricas de qualidade e denominadores
Uma taxa de completude exige identificar quantos registros eram esperados e quantos passaram na regra. Se a origem deixou de enviar metade dos eventos, medir apenas o percentual de campos completos entre os registros recebidos pode produzir 100% e ocultar a falha. Por isso, a avaliação deve incluir cobertura, volume esperado e frescor. A taxa de duplicidade depende de uma chave de evento e do intervalo de análise. Para regras de integridade, convém separar falhas de cadastro, falhas de captura e problemas de transformação. A apresentação deve informar período, universo e método para permitir comparação. Um dashboard de Data Quality pode destacar tendências e prioridades, mas a evidência do controle reside nos registros de execução, exceções e reconciliação com as fontes.
Uma avaliação técnica independente permite definir limites de aceitação, investigar exceções e comprovar a adequação dos dados às decisões previstas.
Quality Gates, exceções e governança
Quarantine e governança
Data Owners definem regras de negócio, Data Stewards acompanham exceções, Engenharia de Dados implementa testes e Segurança estabelece restrições. Registros suspeitos podem ir para quarantine com motivo e caminho de correção. Excluir linhas silenciosamente pode melhorar percentuais de qualidade e piorar a fidelidade dos indicadores. Cada incidente deve ter impacto, responsável, prazo e evidência de encerramento.
A definição do escopo deve considerar risco, governança e limites técnicos. Uma regra insuficientemente especificada pode gerar resultados plausíveis porém contraditórios. As responsabilidades e os parâmetros de aceite precisam ser explícitos para permitir rastreabilidade e revisão independente.
Quarantine, correção e replay
Quando um registro falha, existem alternativas: bloquear o lote, isolar apenas a linha, publicar resultado provisório com alerta ou descartar conforme política autorizada. A opção depende da criticidade. A área de quarantine deve registrar valor original, motivo da falha, regra violada, versão de processamento e responsável. Depois da correção, o replay precisa ser idempotente e reconciliar os resultados com o que já foi publicado. A ausência dessa trilha faz o sistema aparentar estabilidade à custa de apagar problemas. Métricas de rejeição devem acompanhar gravidade, causa e tempo de resolução.
Tratamento de exceções sem perda de rastreabilidade
Ao identificar um erro, o sistema pode impedir publicação, isolar registros ou permitir uso condicionado a um alerta. A decisão deve estar vinculada a impacto, segurança e finalidade. A área de quarantine precisa preservar valor original, identificador, fonte, regra violada, lote e responsável. Um registro corrigido deve manter trilha de alteração e poder ser reprocessado sem criar uma nova ocorrência artificial. O processo precisa registrar também recusas justificadas de correção, como dados cuja origem não pode ser reconstruída. Excluir silenciosamente registros problemáticos altera os denominadores e pode falsear a melhora da qualidade. O histórico de exceções é insumo para identificar falhas recorrentes de integração, captura e cadastro, orientando intervenções na origem.
Governança de mudanças em Data Contracts
Uma alteração de API, equipamento ou cadastro pode mudar o significado de um campo sem alterar seu nome. A qualidade exige controle das versões dos Data Contracts e avaliação de impacto sobre indicadores. O processo de mudança deve envolver produtores, consumidores, segurança e responsáveis de negócio. Testes regressivos precisam demonstrar que medidas históricas permanecem comparáveis ou explicitar a ruptura. Quando houver migração de sistema, a reconciliação deve usar amostras e períodos de operação paralela quando viável. A documentação de mudança é parte da evidência de confiabilidade.
Incidentes, ownership e escalonamento
Um processo de Data Quality eficiente distingue quem define a regra de quem corrige a informação. Data Owners aprovam interpretação e finalidade, Data Stewards acompanham qualidade e exceções, Engenharia de Dados mantém mecanismos técnicos e a operação da fonte atua quando o defeito nasce no sistema produtor. Essas responsabilidades podem variar, mas devem ser explicitadas em uma matriz. Os incidentes precisam registrar severidade, impacto no indicador, prazo de resposta, ação corretiva e evidência de encerramento. Reincidência pode indicar defeito estrutural e não apenas necessidade de limpar dados. Também é necessário comunicar consumidores quando uma série histórica foi revisada. A governança deve impedir ajustes não autorizados de thresholds com o propósito de melhorar números aparentes de qualidade.
| Dimensão | Verificação | Evidência |
|---|---|---|
| Completude | Cobertura por fonte e período | Comparação com registros esperados |
| Unicidade | Controle de retransmissões e identidade de eventos | Relatório de duplicações |
| Freshness | Atraso entre ocorrência e publicação | Logs temporais |
| Accuracy | Comparação com amostra de referência | Relatório de validação |
Verificação, testes e aceite
Testes e aceite de indicadores
Testes devem cobrir duplicações, dados ausentes, eventos tardios, alterações de schema e inconsistências entre origens. No cálculo de disponibilidade, alarmes repetidos não equivalem automaticamente a novas falhas, e ordens de serviço abertas não provam indisponibilidade contínua. O aceite precisa permitir reconstruir a conta, explicar diferenças e registrar limites de interpretação. O acompanhamento posterior deve investigar causas e não apenas apresentar percentuais.
A escolha de ferramentas deve ocorrer depois da definição das necessidades e das evidências esperadas. O projeto precisa preservar a separação entre a função de cada sistema e a interpretação posterior das informações. Mudanças de interface, critérios e período exigem registro e validação antes da produção.
Testes de aceitação e operação contínua
O pacote de aceite deve conter catálogo de Critical Data Elements, critérios e resultados de testes, exceções registradas, amostras reconciliadas e evidência de tratamento de falhas. É preciso exercitar duplicação, nulidade, atraso, mudança de schema e retomada após indisponibilidade. A equipe deve mostrar como uma regra violada gera alerta, quem decide o tratamento e como o indicador é corrigido. O acompanhamento em produção deve analisar tendências por origem e causa, evitando aceitar percentuais elevados sem compreender quais registros foram excluídos. A revisão periódica deve atualizar regras conforme finalidade e risco.
A rastreabilidade de falhas e intervenções em ativos depende de processos de manutenção consistentes, registros reconciliados e responsabilidade operacional definida.
Medições, Accuracy e calibração
Accuracy depende da proximidade entre o valor registrado e uma referência adequada. Essa verificação é diferente de validade de formato: um sensor pode transmitir números em faixa plausível e ainda apresentar deslocamento sistemático por problema de calibração. Os procedimentos de qualidade devem considerar método de medição, periodicidade de verificação, unidade e tolerância definida para o uso. Em Video Analytics, uma configuração pode contar movimentos com erro de cobertura ou oclusão; nem sempre existe identificação de pessoas únicas. A avaliação precisa explicitar amostragem de referência, condições observadas, intervalo e limitações. Não é correto transferir uma taxa de Accuracy medida em um cenário para todos os ambientes. Quando o dado compõe indicador contratual, o método e as evidências de aceitação precisam ser acordados previamente.
Qualidade em Video Analytics e dados operacionais
Uma contagem extraída de vídeo depende de posicionamento, cobertura, oclusão, iluminação e configuração do algoritmo. Não se deve confundir estimativa de fluxo com identificação de pessoas únicas. Para Business Intelligence, a série precisa carregar contexto de câmera, área monitorada, período e confiabilidade de captura. Uma queda de contagem pode ser mudança de movimento, obstrução ou indisponibilidade de dispositivo. O controle deve avaliar essas causas antes de interpretar o resultado como mudança de demanda. Critérios de comparação precisam considerar eventos externos e alterações de configuração.
Critérios contratuais e verificação
Na contratação, o escopo deve declarar quais conjuntos de dados serão controlados, quem fornece referências de comparação e quais regras serão aceitas. As condições de teste precisam abranger mudança de schema, registro tardio, duplicação, ausência de fonte, correção retroativa e restabelecimento da integração. Para cada caso, o resultado esperado pode ser rejeição, quarentena, alerta ou publicação condicionada. A documentação de aceite inclui catálogo de regras, evidências executadas, relatórios de exceção, reconciliação e procedimentos de manutenção. O processo deve diferenciar testes da solução de dados dos testes dos dispositivos e sistemas que produzem medições. Uma plataforma analítica não corrige por si só calibração inadequada, câmera mal posicionada ou cadastro mantido incorretamente. O tratamento precisa alcançar a causa.
Um programa de Data Quality deve diferenciar prevenção, detecção e recuperação. A prevenção inclui Data Contracts, regras de entrada e controles de cadastro; a detecção observa indicadores e amostras de exceção; a recuperação corrige registros, reprocessa períodos e comunica efeitos sobre relatórios. Essas atividades exigem responsáveis diferentes e procedimentos conectados. Quando uma regra passa a reprovar mais registros, a causa pode ser degradação da origem ou mudança legítima de processo; ajustar silenciosamente o limite prejudica a confiabilidade da medição. Um diagnóstico deve comparar o comportamento com o baseline, identificar a população afetada e validar hipóteses com quem conhece a operação. Os resultados da auditoria devem manter trilha de decisões, evidências e limitações. O aceite de Data Quality não se resume a escolher ferramentas: precisa provar que exceções relevantes são identificadas, encaminhadas, corrigidas e refletidas com rastreabilidade nos indicadores.
Os dados produzidos por sensores e dispositivos físicos exigem tratamento distinto de registros exclusivamente transacionais. Uma leitura pode permanecer dentro da faixa esperada e ainda estar incorreta devido a calibração, configuração ou defeito de comunicação. O programa de qualidade deve relacionar cada variável à unidade de engenharia, ao equipamento de origem e à condição de medição. Quando o sensor é substituído, a série histórica precisa preservar a informação sobre a troca. A interpretação analítica deve distinguir mudança real de processo de mudança na instrumentação.
Uma governança eficaz precisa evitar que relatórios agregados ocultem falhas concentradas. Uma rede pode apresentar alta completude média enquanto uma unidade crítica deixa de transmitir. Além do percentual geral, os controles devem permitir segmentar a qualidade por fonte, período, unidade, tipo de evento e severidade. A visualização deve mostrar o impacto nos indicadores de negócio, e não apenas uma pontuação abstrata. O tratamento deve priorizar falhas que comprometem decisões relevantes, mesmo quando atingem um volume pequeno de registros.
Regras de consistência precisam reconhecer que sistemas diferentes possuem propósitos próprios. Um alarme operacional, uma ordem de serviço e um evento de indisponibilidade não são necessariamente registros equivalentes. A reconciliação deve comparar entidades, janelas e condições explicitamente definidas. Se um sistema registra a abertura do chamado e outro a restauração efetiva, a diferença temporal pode ser legítima. O problema surge quando a análise trata esses momentos como intercambiáveis. Os controles devem explicar quais divergências são esperadas, quais exigem investigação e como registrar exceções.
Data Quality não deve ser tratada como responsabilidade exclusiva da equipe que desenvolve dashboards. O produtor da informação precisa conhecer as condições de captura e transmissão; o Data Owner deve aprovar regras de significado; a Engenharia de Dados implementa testes; e a operação trata incidentes na origem. Uma falha persistente de cadastro exige melhoria do processo que gera o dado, não limpeza infinita na camada analítica. Os papéis podem ser distribuídos de modo diferente em cada organização, desde que a responsabilidade pelo tratamento e pelo aceite seja inequívoca.
Os indicadores de qualidade precisam ter ciclo de revisão. Ao mudar o sistema produtor, o contrato, a regra de negócio ou a finalidade da análise, alguns controles perdem relevância e outros tornam-se obrigatórios. Qualquer ajuste deve conservar histórico e justificativa para permitir interpretar a evolução das métricas. Durante a operação assistida, a equipe deve selecionar incidentes reais e demonstrar detecção, investigação, correção e reprocessamento. Um processo de qualidade só é verificável quando o resultado da regra se conecta a uma ação e a uma evidência de encerramento.
Exemplo de aceite: ocupação e disponibilidade operacional
Considere um empreendimento que utiliza contagens de circulação extraídas de Video Analytics, registros de disponibilidade de dispositivos e ordens de manutenção para avaliar o desempenho operacional. Antes de calcular qualquer indicador, o Data Owner precisa definir qual população está sendo medida: passagens, ocupação estimada em determinado instante ou visitantes distintos. Esses conceitos não são intercambiáveis. O inventário deve identificar quais câmeras cobrem cada área, quais períodos apresentam oclusão ou indisponibilidade e que mudanças de configuração alteraram o método de contagem. A ausência de eventos pode indicar baixa circulação, falha de comunicação, equipamento desligado ou bloqueio temporário de acesso. A hipótese correta deve ser estabelecida com evidências operacionais, não por preenchimento automático de valores.
A avaliação de completude exige comparar a quantidade de intervalos efetivamente recebidos com os intervalos esperados para os dispositivos elegíveis. O denominador deve descontar apenas as exceções autorizadas e documentadas, sem esconder indisponibilidades. Para Accuracy, uma amostra de referência deve ser construída com metodologia de contagem apropriada, períodos representativos e condições de operação distintas. A análise deve separar precisão da medição, cobertura espacial e consistência temporal; uma câmera pode contar corretamente o que vê e ainda não representar todo o fluxo do empreendimento. A taxa de aprovação de regras precisa ser informada por origem, janela e criticidade, pois um único indicador agregado pode ocultar falhas concentradas em locais importantes.
O aceite deve simular falha de câmera, retransmissão de eventos, mudança de timezone, restauração de comunicação e correção retroativa de um período. Para cada ensaio, registra-se a entrada conhecida, a regra aplicada, o resultado esperado, a evidência observada e o responsável pela decisão. Uma falha crítica deve produzir alerta ou bloqueio de publicação conforme o Data Contract. Quando os dados forem corrigidos, o replay precisa manter idempotência e permitir reconstruir o indicador antes e depois da mudança. Assim, o programa de Data Quality comprova não apenas que consegue detectar anomalias, mas que preserva rastreabilidade e oferece condições técnicas para interpretar os resultados com segurança.
Considerações finais
Data Quality não deve ser reduzida a um percentual global de aprovação. A qualidade é sempre relativa ao uso, às fontes e à decisão suportada. Um conjunto de dados pode estar completo em termos de campos e ainda apresentar baixa cobertura de eventos, valores incorretos ou registros duplicados. Cada controle deve informar universo esperado, janela de avaliação, regra aplicada e impacto sobre o indicador.
A governança precisa assegurar que Data Owners, Data Stewards e responsáveis técnicos possam identificar anomalias, distinguir eventos reais de falhas e decidir o tratamento adequado. Quarantine, correção e replay são mecanismos de preservação da rastreabilidade, não substitutos da correção das causas na origem. Resultados alterados por mudanças de regra devem manter histórico e justificativa.
O aceite técnico exige evidências de testes, amostras reconciliadas, exceções documentadas e resposta a incidentes, incluindo alterações de schema e recuperação após interrupções. Somente assim a organização pode justificar a confiança em seus indicadores, mesmo quando há limitações conhecidas nas medições.
Referências técnicas
[1] GOOGLE CLOUD. Auto data quality overview — Knowledge Catalog. Disponível em: https://docs.cloud.google.com/knowledge-catalog/docs/auto-data-quality-overview. Acesso em: 26 out. 2026.
[2] AMAZON WEB SERVICES. AWS Glue Data Quality — AWS Glue User Guide. Disponível em: https://docs.aws.amazon.com/glue/latest/dg/glue-data-quality.html. Acesso em: 26 out. 2026.
[3] GREAT EXPECTATIONS. Introduction to GX Core. Disponível em: https://docs.greatexpectations.io/docs/core/introduction/. Acesso em: 26 out. 2026.
Perguntas frequentes
É a adequação dos dados ao uso pretendido, verificada por regras mensuráveis, responsáveis e evidências. Disponibilidade técnica e qualidade não são sinônimos: os dados podem chegar corretamente e ainda produzir indicadores errados.
Completude, validade, consistência, unicidade, atualidade e Accuracy são dimensões comuns. A relevância de cada uma depende do indicador, da criticidade do processo e da possibilidade de verificar a origem.
É necessário identificar o universo esperado, incluindo fontes e janelas em que não chegaram registros. Medir apenas campos preenchidos entre as linhas recebidas pode ocultar interrupções integrais de um dispositivo.
Não. Validade verifica conformidade a tipo, faixa ou regra; Accuracy exige comparação adequada com uma referência. Um sensor pode transmitir valores plausíveis e ainda apresentar erro sistemático.
A equipe precisa definir identidade, timestamp e regras de negócio. Duas passagens semelhantes podem ser eventos reais, enquanto uma retransmissão técnica não deve criar nova ocorrência analítica.
É o quanto o dado disponível está atualizado em relação ao uso esperado. O controle deve distinguir tempo do evento, recepção e processamento, com tolerâncias associadas à necessidade operacional.
Relacionar fontes, transformações, versões e consumidores para permitir reconstruir indicadores e investigar divergências. Uma alteração de cálculo precisa deixar evidência de quais resultados e períodos foram afetados.
Quando uma regra definida indicar inconsistência que exige tratamento ou revisão antes do consumo. A decisão de bloquear, isolar ou publicar com ressalva depende do impacto e deve ser documentada.
Data Owners aprovam definições de negócio, Data Stewards acompanham exceções e Engenharia de Dados mantém os controles. A divisão real deve estar documentada, com responsáveis pela fonte e pelo tratamento das causas.
Catálogo de regras, identificação de Critical Data Elements, amostras reconciliadas, registros de rejeição, testes de duplicação, atraso, mudança de schema e recuperação, além de critérios de resolução de incidentes.
