7.8 Qualidade e observabilidade de dados

Visão geral e motivação

A qualidade dos dados é a adequação ao uso: o grau em que os dados servem às decisões, aos produtos e aos relatórios que dependem deles. Um conjunto de dados não é bom nem ruim em abstrato. Ele é bom o bastante para uma finalidade, ou não é. Um endereço de cliente que serve para uma contagem de marketing pode ser impróprio para uma notificação legal. Esse enquadramento importa, porque move a conversa de “os nossos dados são perfeitos?” (nunca) para “os nossos dados são adequados ao que estamos prestes a fazer com eles?” (respondível e testável). As dimensões clássicas são exatidão, completude, consistência, atualidade, validade e unicidade, e a maioria dos problemas reais se reduz a uma delas.

Eis a verdade incômoda para grandes equipes: dado ruim é pior que nenhum dado. Quando não há dados, vocês sabem disso e prosseguem com a cautela apropriada. Quando há dados errados que parecem certos, vocês agem sobre eles com falsa confiança. O dado ruim corrompe em silêncio. Ele flui para um painel em que um executivo confia, para um modelo de aprendizado de máquina que treina com ele e codifica seus erros e para decisões que ninguém pensa em questionar porque o número estava ali na tela. O dano é difuso e atrasado, e é exatamente por isso que é caro. Quando alguém nota, o número errado já foi citado numa apresentação ao conselho, numa declaração regulatória ou numa estatística pública.

A observabilidade de dados é a disciplina que pega isso antes dos seus consumidores. É o paralelo direto da observabilidade e da telemetria de software (capítulo 9.2): o mesmo instinto que manda monitorar a latência das requisições e as taxas de erro manda monitorar a atualidade, o volume, o esquema e a distribuição dos dados. Este capítulo se apoia na estratégia e governança de dados (capítulo 7.1) e na engenharia de dados (capítulo 7.2), e alimenta a modelagem de dados e a camada semântica (capítulo 7.7) e a IA responsável e confiável (capítulo 6.5). Para empresas que reconciliam muitos sistemas de origem e para governos que publicam estatísticas oficiais, tratar a confiabilidade dos dados como um problema de engenharia, com donos e níveis de serviço, é a diferença entre confiança e uma correção muito pública.

Princípios fundamentais

A qualidade dos dados é adequação ao uso, não perfeição. Definam-na em relação à finalidade.
Dado ruim é pior que nenhum dado, porque corrompe as decisões em silêncio.
Testem os dados como testam o código: asserções, expectativas e verificações de esquema no pipeline.
Os contratos entre produtores e consumidores tornam as expectativas explícitas e impositíveis.
Observem atualidade, volume, esquema e distribuição do mesmo modo que observam os serviços.
A linhagem transforma “algo está errado” em “eis o que quebrou e o que isso afeta”.
Tratem os incidentes de dados como incidentes de produção, com dono, severidade e níveis de serviço.
Detectem os problemas onde entram, não três camadas adiante, num painel.

Recomendações

Defina a qualidade por dimensão e meça-a

Metas vagas de qualidade produzem resultados vagos. Dividam a qualidade em dimensões mensuráveis e associem verificações concretas a cada uma. A exatidão pergunta se os valores refletem a realidade (esta receita registrada bate com o livro-razão de origem?). A completude pergunta se os registros e campos esperados estão presentes (falta algum dia, há colunas obrigatórias nulas?). A consistência pergunta se o mesmo fato concorda entre os sistemas (a contagem de clientes das finanças coincide com a do warehouse?). A atualidade pergunta se os dados chegam a tempo de serem úteis (os dados de ontem estão prontos antes do relatório da manhã?). A validade pergunta se os valores obedecem a regras e formatos (todos os códigos de moeda são reais, as datas estão no intervalo?). A unicidade pergunta se as entidades aparecem uma só vez (há pedidos duplicados inflando o total?). Escolham as dimensões que importam para cada conjunto de dados, definam limiares e acompanhem-nas ao longo do tempo. A qualidade que vocês não medem é uma qualidade sobre a qual vocês estão chutando.

Teste os pipelines com asserções e expectativas

Os dados merecem o mesmo rigor de teste que o código de aplicação. Usem a validação de dados em todos os estágios: testes baseados em asserções que fazem o pipeline falhar quando uma invariante é violada e testes baseados em expectativas que declaram como é o “normal” de uma tabela e sinalizam desvios. Afirmem que as chaves primárias são únicas e não nulas, que as chaves estrangeiras se resolvem, que as colunas categóricas contêm só valores aceitos, que as colunas numéricas caem em faixas plausíveis e que as contagens de linhas ficam numa banda esperada. Acrescentem verificações de esquema que falham alto quando uma coluna é adicionada, removida, renomeada ou muda de tipo a montante. Rodem essas verificações na integração contínua para que uma transformação ruim seja pega antes do merge e rodem-nas de novo em produção contra dados vivos para que uma origem ruim seja pega antes de chegar aos consumidores. O objetivo é falhar cedo e alto, porque um pipeline quebrado é mais seguro que um silenciosamente errado.

Estabeleça contratos de dados entre produtores e consumidores

A maioria dos incidentes de qualidade de dados começa a montante, quando uma equipe produtora muda um esquema, um significado semântico ou uma convenção de valores sem saber quem depende deles. Um contrato de dados resolve isso tornando a interface explícita: o esquema, a semântica de cada campo, os valores permitidos, as garantias de atualidade e o processo para fazer uma mudança. O produtor se compromete com o contrato, o consumidor constrói contra ele e uma mudança incompatível exige versionamento e aviso e não uma surpresa silenciosa na segunda-feira. Imponham os contratos mecanicamente onde puderem, validando os dados de entrada contra o contrato na fronteira e rejeitando ou pondo em quarentena as violações. Os contratos transformam uma dependência implícita e frágil numa dependência explícita e negociada. Também tornam visível a propriedade, que é metade da batalha em escala.

Monitore os quatro sinais da observabilidade de dados

A observabilidade de dados vigia quatro sinais, em paralelo direto com o modo como vocês vigiam um serviço em execução (capítulo 9.2). Atualidade: os dados estão tão recentes quanto deveriam, ou o pipeline travou? Volume: a contagem de linhas está na faixa esperada, ou uma tabela chegou pela metade ou carregada em dobro? Esquema: a estrutura mudou de forma inesperada? Distribuição: os próprios valores derivaram, de modo que uma coluna que tinha 2 por cento de nulos de repente tem 40, ou uma média mudou de um jeito que sinaliza um bug a montante? Instrumentem esses sinais nas suas tabelas importantes, aprendam seus padrões normais e alertem sobre violações. É assim que vocês trocam “um executivo notou que o painel parecia errado” por “a equipe dona foi acionada no ponto da falha”. O pior detector possível de um problema de dados é um humano a jusante que confia no número.

Acrescente detecção de anomalias, mas ajuste-a contra a fadiga de alertas

Os limiares estáticos pegam as falhas óbvias. Para a deriva mais sutil, acrescentem uma detecção de anomalias que aprende o padrão sazonal normal de cada métrica e sinaliza desvios estatisticamente incomuns, para pegar um vazamento lento antes de virar enchente. Sejam disciplinados nisso. Alertas de anomalia ruidosos treinam as pessoas a ignorar alertas, o que é pior que não ter alertas. Comecem pelas tabelas de maior valor, alertem apenas sobre o que um humano deve agir, encaminhem cada alerta a um dono nomeado e ajustem sem piedade. Um alerta em que ninguém age é um bug no monitoramento, não uma funcionalidade.

Acompanhe a linhagem para análise de impacto e causa raiz

Quando algo quebra, duas perguntas importam de imediato: o que causou e o que isso afeta. A linhagem de dados responde a ambas mapeando como os dados fluem da origem, por todas as transformações, até cada tabela, painel e modelo a jusante. Para a causa raiz, vocês rastreiam um número ruim a montante até a transformação ou a origem que o introduziu. Para a análise de impacto, rastreiam para a frente e veem todos os consumidores tocados por uma carga ruim, para notificá-los e pôr o dano em quarentena antes que se espalhe. Capturem a linhagem automaticamente das suas ferramentas de transformação e de orquestração em vez de manter um diagrama à mão, porque um diagrama feito à mão está errado no dia seguinte ao desenho. Em empresas com muitas origens, publiquem a linhagem num catálogo de dados para que qualquer consumidor veja de onde veio um campo e confie nele de acordo.

Trate os incidentes de dados como incidentes de produção

As práticas que mantêm os serviços confiáveis se aplicam diretamente aos dados. Deem a cada conjunto de dados importante um dono. Definam níveis de severidade para o “tempo de inatividade dos dados”, os períodos em que os dados estão ausentes, errados ou atrasados. Estabeleçam níveis de serviço: metas de atualidade, um orçamento de erros aceitável e um tempo-alvo de detecção e de resolução. Ponham rodízios de sobreaviso de dados atrás dos pipelines mais críticos, escrevam runbooks e façam revisões pós-incidente sem atribuição de culpa para que a mesma falha não se repita. Quando uma tabela de pagamentos está atrasada ou uma métrica pública está errada, isso é um incidente e merece a mesma seriedade de uma interrupção. Essa é a mudança cultural que faz todas as ferramentas compensarem.

Faça perfilamento e reconciliação continuamente

O perfilamento (profiling) significa examinar rotineiramente a forma dos seus dados: distribuições de valores, taxas de nulos, cardinalidade, mínimo e máximo e padrões de formato. Ele revela problemas em que vocês não pensaram para afirmar e diz como é o “normal”, para definir boas expectativas. A reconciliação significa conferir que fontes independentes concordam: o total do warehouse coincide com o sistema de registro de origem, a soma das partes é igual ao todo? Automatizem a reconciliação entre sistemas críticos e alertem sobre divergências, porque uma quebra de reconciliação costuma ser o sinal mais precoce e mais claro de que algo deu errado a montante.

Compromissos: prós e contras

Abordagem	Prós	Contras	Melhor ajuste
Testes de asserção (falha dura)	Para o dado ruim de vez, invariantes claras	Pode bloquear pipelines por problemas menores	Chaves críticas, integridade referencial
Testes de expectativa (sinalização suave)	Pega deriva, menos frágil	Precisa de ajuste, pode ser ignorado	Distribuições, bandas de volume
Contratos de dados	Previne surpresas a montante, propriedade clara	Sobrecarga de coordenação e governança	Fronteiras de produtor ou consumidor entre equipes
Detecção de anomalias	Pega deriva sutil e imprevista	Fadiga de alertas, falsos positivos	Tabelas de alto valor, métricas sazonais
Verificações manuais por amostragem	Baratas para começar, sem ferramentas	Não escalam, perdem erros silenciosos	Apenas estágio muito inicial
Plataforma completa de observabilidade	Ampla cobertura, linhagem, alertas	Custo, configuração, mais um sistema a operar	Muitas origens, relatórios regulados

A tensão central é cobertura versus ruído. Se não instrumentam nada, os problemas chegam primeiro aos consumidores, o que destrói a confiança. Se instrumentam tudo com alertas de gatilho sensível, afogam a equipe em falsos positivos até ela silenciar o canal, o que também deixa os problemas chegarem aos consumidores. Resolvam isso classificando os dados pelo raio de impacto. As tabelas que alimentam métricas do conselho, produtos voltados ao cliente, relatórios regulatórios e modelos de aprendizado de máquina recebem o tratamento completo: contratos, asserções duras, observabilidade e propriedade com sobreaviso. A longa cauda de tabelas exploratórias recebe um perfilamento leve. Gastem o seu orçamento de confiabilidade onde o dado errado mais doeria e sejam deliberadamente parcimoniosos no resto.

Perguntas para discutir com sua equipe

Quando um dado ruim chega à produção, quem descobre primeiro, e como? Esta é a pergunta mais reveladora sobre a confiabilidade dos seus dados, porque a resposta honesta costuma ser “um consumidor, por acidente”. Se um analista, um executivo ou um cliente é o seu sistema de detecção, o seu tempo médio de detecção se mede em dias e a sua credibilidade leva o golpe a cada vez. A alternativa é uma instrumentação que aciona a equipe dona no ponto da falha, antes de o número ruim se propagar. Levem números reais: quantos dos seus últimos dez incidentes de dados foram pegos por monitoramento versus relatados por um humano a jusante, e quanto tempo cada um ficou sem ser detectado. A resposta diz se vocês têm observabilidade ou apenas esperança, e deve conduzir diretamente onde vocês investem primeiro em verificações de atualidade, volume, esquema e distribuição.
Quais conjuntos de dados têm um dono, um contrato e um nível de serviço, e quais são órfãos? Em escala, a maioria das falhas de qualidade de dados remonta a uma interface sem dono: uma equipe produtora mudou algo sem ideia de quem dependia, porque nenhum contrato dizia isso. A propriedade é a fundação que torna possíveis os contratos, as rotas de alerta e a resposta a incidentes, e os conjuntos órfãos são onde mora a corrupção silenciosa. Percorram as suas tabelas mais importantes e perguntem, para cada uma, quem responde, a que o produtor se comprometeu e que atualidade e exatidão são prometidas aos consumidores. Levem a sua linhagem: as tabelas com maior raio de impacto a jusante são as que mais precisam disso e muitas vezes as que não têm. A lacuna entre “importante” e “com dono” é a sua lista de prioridades para o próximo trimestre.
Qual é o custo real de um incidente de qualidade de dados para nós, e nós o tratamos de acordo? As equipes investem pouco em qualidade de dados porque o custo do dado ruim é difuso e atrasado, então nunca aparece como linha de despesa, enquanto o custo de construir ferramentas de qualidade é concreto e imediato. Reenquadrem precificando um incidente real de ponta a ponta: a decisão errada, o retrabalho, as horas de engenharia gastas rastreando a causa raiz sem linhagem, a confiança corroída que leva as pessoas a reconstruir em silêncio os próprios conjuntos paralelos e, em contextos regulados ou voltados ao público, o aviso de correção e seu dano à reputação. Levem um exemplo específico do último ano e somem com honestidade. Se uma única falha silenciosa num pipeline de pagamentos ou de estatísticas públicas pode custar mais que um ano de ferramentas de observabilidade, o argumento de negócio se faz sozinho, e a conversa passa de se investir para onde.
Nós classificamos os nossos conjuntos de dados pelo raio de impacto, e o nosso investimento em monitoramento de fato segue essa classificação? O modo de falha central em escala é gastar o esforço de confiabilidade de modo uniforme, de maneira que a tabela exploratória em que ninguém confia recebe a mesma atenção que a que alimenta métricas do conselho, enquanto um alerta de gatilho sensível numa tabela de baixo valor treina as pessoas a silenciar o canal que também carrega o acionamento crítico. Vocês não conseguem instrumentar tudo sem se afogar em ruído e não conseguem instrumentar nada sem deixar os problemas chegarem primeiro aos consumidores, então a decisão real é onde vai o tratamento completo (contratos, asserções duras, observabilidade e propriedade com sobreaviso) e onde basta um perfilamento leve. Levem um inventário das suas tabelas marcadas pelo que depende delas: métricas do conselho, produtos voltados ao cliente, relatórios regulatórios e modelos de aprendizado de máquina, e depois comparem essa classificação com onde as suas verificações e alertas de fato estão hoje. Para uma empresa que reconcilia muitas origens ou um governo que publica números oficiais, as tabelas com exposição legal ou pública pertencem ao topo da lista, e qualquer lacuna entre “doeria mais se estivesse errada” e “é a mais monitorada” é um erro de priorização a corrigir agora.
Quais modelos de aprendizado de máquina e análises estão decidindo com dados que nunca validamos, e que erros podem estar codificando em silêncio? Um painel mostra um número errado a um humano que talvez o questione, mas um modelo treina com atributos errados e codifica esses erros em cada previsão que faz, numa escala e opacidade que tornam o dano muito mais difícil de ver ou desfazer. A pressão concorrente é a velocidade: as equipes de ciência de dados querem andar depressa com novos atributos, e acrescentar validação, contratos e garantias de atualidade a cada fonte parece atrito até um modelo se degradar em silêncio porque uma coluna a montante derivou. Levem um inventário dos seus modelos e análises em produção, dos conjuntos de dados que cada um consome e uma marca honesta de quais dessas fontes têm testes, contratos e observabilidade versus quais estão sem proteção. Num contexto corporativo ou governamental em que um modelo influencia decisões de crédito, benefícios ou fiscalização, os dados de treinamento não validados viram um passivo de auditoria e de equidade além de um risco de qualidade, então a pergunta de quais fontes condicionam o lançamento de um modelo deve ter um dono e uma resposta documentada (capítulo 6.5).
Quando um bug de qualidade aparece semanas depois, nós de fato conseguimos reprocessar e reconciliar, ou já descartamos o que precisaríamos? Muitas falhas de qualidade são invisíveis na hora da carga e só ficam claras depois, quando uma quebra de reconciliação ou uma tendência suspeita leva alguém a olhar, e a essa altura a capacidade de consertar limpamente depende de escolhas feitas muito antes: se vocês guardaram registros brutos imutáveis, se fontes independentes podem ser reconciliadas e se a linhagem permite rastrear o número ruim até a origem. A tensão é custo e simplicidade contra reprodutibilidade, porque reter dados brutos e rodar reconciliação contínua entre sistemas não é de graça, e é tentador apagar as entradas brutas assim que as tabelas transformadas parecem certas. Levem a sua política de retenção e de imutabilidade para os dados brutos, a lista dos pares críticos de sistemas que vocês reconciliam automaticamente e um exemplo real de um bug do qual vocês puderam, ou não puderam, sair reprocessando. Para uma agência governamental sob obrigação legal de rastrear qualquer número publicado até os registros de origem, ou uma empresa diante de uma retificação regulatória, os dados brutos imutáveis e a reconciliação automatizada não são higiene opcional, e sim o mecanismo que torna uma correção defensável.

Perspectiva por setor

Startup. Velocidade e confiança importam mais que cobertura. Ponham um punhado de testes leves na sua ferramenta de transformação (unicidade e não nulidade nas chaves, valores aceitos nas colunas que carregam significado, uma banda de contagem de linhas por origem) e acrescentem monitoramento de atualidade e de volume apenas nas poucas tabelas que alimentam as métricas da empresa. Encaminhem todo alerta a um canal que um engenheiro possui e resistam a comprar uma plataforma de observabilidade antes de terem as tabelas ou a equipe que a justifiquem. O objetivo é notar um campo mal rotulado antes de ele inflar um número que os fundadores citam, não instrumentar tudo.

Pequena empresa. Sem engenheiro de dados e com orçamento apertado, apoiem-se nos recursos de qualidade já embutidos no warehouse, na ferramenta de BI ou nas plataformas SaaS que vocês pagam em vez de montar uma pilha separada. Concentrem o esforço no punhado de números que de fato conduzem decisões (receita, pipeline, estoque), conferiram-nos por amostragem contra uma fonte independente numa cadência regular e tratem os alertas de atualidade e de esquema de um fornecedor como bons o bastante quando existirem. Comprar qualidade embutida em ferramentas que vocês já operam vence construir um pipeline que não há ninguém para manter.

Grande empresa. O problema é a confiabilidade entre muitas equipes e milhares de tabelas, então padronizem a interface: contratos de dados em todas as fronteiras de produtor, uma plataforma de observabilidade vigiando atualidade, volume, esquema e distribuição e linhagem publicada num catálogo para análise de impacto. Classifiquem os conjuntos pelo raio de impacto, ponham detecção de anomalias e propriedade com sobreaviso nos de alto valor e passem os incidentes de dados pelo mesmo processo de severidade e de revisão pós-incidente das interrupções de serviço. Níveis de serviço nos pipelines que alimentam relatórios regulatórios e painéis executivos transformam a confiabilidade dos dados de uma aspiração num compromisso medido e governado.

Governo. A exatidão legal e a prestação de contas públicas definem o patamar: depositem registros brutos imutáveis de pesquisas e administrativos, transformem-nos em estágios testados e em camadas e reconciliem contra os totais de origem a cada passo. Mantenham a linhagem completa para que qualquer número publicado possa ser rastreado até os registros de origem para auditoria e condicionem cada lançamento a uma validação de validade, completude e consistência contra os períodos anteriores. A contratação de ferramentas deve exigir transparência e portabilidade de dados, e uma estatística pública errada deve ser tratada como um incidente grave, com a seriedade que a confiança pública nos números oficiais exige.

Exemplos

Startup. Uma empresa de vinte pessoas conduz sua entrada no mercado sobre um warehouse alimentado por eventos de produto e por um provedor de pagamentos. No início, um campo de moeda mal rotulado inflou em silêncio a receita reportada por duas semanas antes de alguém notar, o que abalou a confiança da equipe em todos os painéis. Eles responderam com um conjunto leve de testes na ferramenta de transformação: unicidade e não nulidade nas chaves, verificações de valores aceitos nas colunas de moeda e de status e uma banda de contagem de linhas por origem. Acrescentaram monitoramento básico de atualidade e de volume nas poucas tabelas que alimentam as métricas da empresa, encaminhado a um único canal do Slack que um engenheiro possui. É modesto, mas pega as falhas que importam, e os fundadores voltaram a confiar nos números.

Grande empresa. Um banco multinacional reconcilia dados de clientes e de transações de dezenas de sistemas de origem num warehouse governado que alimenta relatórios regulatórios, modelos de risco e painéis executivos. Roda contratos de dados em toda fronteira de produtor, de modo que uma mudança de esquema a montante é versionada e negociada e não imposta aos consumidores. Uma plataforma de observabilidade monitora atualidade, volume, esquema e distribuição em milhares de tabelas, com detecção de anomalias nas de alto valor e linhagem publicada num catálogo de dados para análise de impacto. Os incidentes de dados seguem o mesmo processo de severidade e de sobreaviso das interrupções de serviço, com níveis de serviço nos pipelines que alimentam as submissões regulatórias. Quando um sistema de origem deriva, a equipe dona é acionada e os relatórios a jusante afetados são conhecidos em minutos, não descobertos por um regulador.

Governo. Um instituto nacional de estatística publica indicadores econômicos que os mercados, os formuladores de política e o público tratam como autoritativos, então a exatidão é uma obrigação legal e cada número publicado precisa ser auditável. Seus pipelines depositam registros brutos imutáveis de pesquisas e administrativos e depois os transformam em estágios testados e em camadas, com reconciliação contra os totais de origem a cada passo. A linhagem completa permite aos analistas rastrear qualquer número publicado até os registros de origem, o que é ao mesmo tempo uma ferramenta de qualidade e uma exigência legal. Antes do lançamento, os números passam por portões de validação de validade, completude e consistência contra os períodos anteriores, e qualquer anomalia é investigada e documentada em vez de publicada. Uma estatística pública errada é um incidente grave, então o instituto trata o tempo de inatividade dos dados com a seriedade que a confiança pública exige.

Justificativa de negócio: motivações, ROI e TCO

O retorno da qualidade e da observabilidade dos dados vem de confiança preservada, incidentes encurtados e más decisões evitadas. Dados confiáveis são a fundação que faz todo investimento a jusante em análises, inteligência de negócio e IA de fato compensar, porque um modelo ou painel é tão bom quanto os dados por baixo dele. Quando as verificações de qualidade pegam uma carga ruim na fronteira, vocês evitam o custo muito maior de um número errado chegar a uma decisão, a um cliente ou a uma declaração. A linhagem colapsa a investigação de causa raiz de dias de rastreamento manual para minutos, o que é tempo de engenharia puro recuperado. A observabilidade encolhe o tempo médio de detecção de “quando um consumidor reclama” para “quando o pipeline falha”, que é onde se evita a maior parte do dano à confiança.

O custo total de propriedade inclui ferramentas de teste, de observabilidade e de catalogação, mais o tempo de engenharia para instrumentar os pipelines e o trabalho organizacional de atribuir donos e escrever contratos. Isso é real, mas pesem-no contra o custo de não fazê-lo: corrupção silenciosa descoberta por executivos, modelos de aprendizado de máquina treinados com atributos ruins que codificam erros em escala, analistas reconstruindo em silêncio conjuntos paralelos porque não confiam mais nos oficiais e, em contextos regulados ou públicos, avisos de correção que danificam a credibilidade por anos. À liderança, enquadrem a qualidade dos dados como um seguro sobre toda decisão guiada por dados que a organização toma. O prêmio é modesto e previsível. A perda não segurada, um único número errado de grande visibilidade, não é nenhum dos dois.

Antipadrões e armadilhas

Tratar a qualidade dos dados como um projeto de limpeza pontual em vez de uma prática contínua de engenharia.
Descobrir as falhas pelos consumidores a jusante em vez de pelo monitoramento no ponto da falha.
Nenhuma propriedade dos conjuntos de dados, de modo que ninguém responde quando algo quebra e ninguém é acionado.
Produtores mudando esquemas ou semântica sem contrato, quebrando em silêncio todos os consumidores.
Alertas de anomalia tão ruidosos que a equipe silencia o canal e perde o incidente real.
Alimentar modelos de aprendizado de máquina com dados não validados, codificando erros em escala (capítulo 6.5).
Manter a linhagem como um diagrama desenhado à mão que está errado no dia seguinte ao desenho.
Perseguir dados perfeitos em toda parte em vez de qualidade adequada ao uso nas tabelas que importam.
Apagar os dados brutos, de modo que não se consegue reprocessar nem reconciliar quando um bug de qualidade aparece depois.

Modelo de maturidade

Nível 1, Iniciar: A qualidade não é trabalho de ninguém. Os problemas são achados pelos consumidores, geralmente depois de um número errado chegar a um relatório. Sem testes, sem monitoramento, sem propriedade. Os consertos são combate manual a incêndios, e as mesmas falhas se repetem.
Nível 2, Desenvolver: Algumas equipes acrescentam testes básicos em suas tabelas críticas (chaves, nulos, valores aceitos) e um pouco de monitoramento de atualidade e de volume nos conjuntos que mais importam para elas. As práticas funcionam onde existem, mas a cobertura e o rigor variam de equipe para equipe, nada é padronizado e os incidentes ainda são tratados de modo reativo.
Nível 3, Padronizar: As dimensões de qualidade são definidas com limiares, e as mesmas expectativas valem entre as equipes em vez de depender de quem construiu um pipeline. Os contratos de dados governam as fronteiras-chave de produtor, a observabilidade cobre atualidade, volume, esquema e distribuição nas tabelas importantes e a linhagem apoia a análise de impacto. Todo conjunto de dados importante tem um dono nomeado, e os incidentes de dados seguem um processo documentado de severidade e resposta em toda a organização.
Nível 4, Gerenciar: A qualidade e a confiabilidade são medidas e controladas em relação a linhas de base. O tempo de inatividade dos dados é acompanhado com métricas reais: tempo médio de detecção, tempo médio de resolução, atualidade e exatidão em relação aos níveis de serviço combinados e orçamentos de erro que um conjunto de dados pode gastar antes de disparar ação. As taxas de quebra de reconciliação, de aprovação de testes e de falsos positivos de anomalias são acompanhadas ao longo do tempo, os alertas são ajustados contra esses números e não por palpite, e as decisões de ir ou não ir num lançamento de dados são tomadas pela qualidade medida em relação à linha de base e não por esperança.
Nível 5, Orquestrar: A qualidade e a observabilidade são pervasivas, automatizadas e adaptativas. A detecção de anomalias pega a deriva sutil, os contratos são impostos mecanicamente e a linhagem é capturada automaticamente e publicada num catálogo. Os dados têm níveis de serviço e propriedade com sobreaviso como os serviços de produção, a reconciliação roda continuamente e as revisões pós-incidente sem atribuição de culpa alimentam uma redução constante do tempo de inatividade dos dados. A qualidade é integrada à governança de dados, ao aprendizado de máquina e ao planejamento de negócio, e a organização continuamente redefine limiares, cobertura e propriedade conforme o panorama dos dados muda.

Ideias para discussão

Quais das suas tabelas causariam mais dano se estivessem silenciosamente erradas por uma semana, e são essas as que vocês mais monitoram?
Onde um contrato de dados teria prevenido o seu último incidente causado a montante, e por que não havia um?
Quanto tempo de engenharia uma investigação típica de causa raiz leva hoje, e quanto a linhagem automatizada economizaria?
Algum dos seus modelos de aprendizado de máquina está treinando com dados que vocês não validam, e que erros ele pode estar codificando?
O seu alerta está ajustado o bastante para que as pessoas ajam em todo alerta, ou alguém já silenciou o canal?
Que níveis de serviço de atualidade e de exatidão os seus consumidores mais importantes de fato assinariam, e vocês conseguiriam cumpri-los hoje?

Principais conclusões

A qualidade dos dados é adequação ao uso em exatidão, completude, consistência, atualidade, validade e unicidade.
Dado ruim é pior que nenhum dado, porque corrompe em silêncio as decisões e os modelos.
Testem os dados como código: testes de asserção e de expectativa mais verificações de esquema, na CI e em produção.
Usem contratos de dados para tornar explícitas e impositíveis as expectativas de produtores e consumidores.
Observem atualidade, volume, esquema e distribuição, em paralelo com a observabilidade de software (capítulo 9.2).
Capturem a linhagem para causa raiz e análise de impacto rápidas e publiquem-na para os consumidores.
Tratem os incidentes de dados como incidentes de produção, com dono, severidade e níveis de serviço.
Instrumentem onde o dado errado mais dói. Mirem a qualidade adequada ao uso, não a perfeição em toda parte.

Referências e leitura complementar

Barr Moses, Lior Gavish, and Molly Vorwerck, “Data Quality Fundamentals.”
Jacek Majchrzak, Sven Balnojan, and Marian Siwiak, “Data Contracts.”
Danette McGilvray, “Executing Data Quality Projects.”
Thomas C. Redman, “Data Driven: Profiting from Your Most Important Business Asset.”
Laura Sebastian-Coleman, “Measuring Data Quality for Ongoing Improvement.”
Joe Reis and Matt Housley, “Fundamentals of Data Engineering.”
DAMA International, “DAMA-DMBOK: Data Management Body of Knowledge.”
ISO/IEC 25012, “Data quality model.”