Por que seus dados precisam de um processo de controle de qualidade

Neste ponto, a maioria dos cientistas é engenheiros de software vê o valor de testar seu software regularmente. Mas você também está testando sua engenharia de dados?

Quando alguém me pergunta o que faço para ganhar dinheiro, digo que sou um cientista de garantia de qualidade de dados (QD). Eles realmente não entendem o que quero dizer. “Bem, eu faço testes de dados”, tento explicar, muitas vezes sem sucesso. Tenho amigos na área de tecnologia e desenvolvimento de software que não entendem muito bem o que é teste de dados, por que é necessário ou onde ele se encaixa no mundo da programação. É compreensível, já que a ciência de dados é um campo totalmente novo, e mesmo aqueles de nós que trabalham com dados diariamente precisam permanecer abertos a tudo e qualquer mudança na forma como lidamos com nosso trabalho. 

 

Para entender como funciona o teste de dados, primeiro temos que entender o que é engenharia de dados. Em seguida, podemos examinar a qualidade dos dados e como medi-la. 

 

Engenharia e análise de dados

 

Para entender onde o teste de dados começa, precisaremos saber como os dados são projetados e o que os torna diferentes de outros tipos de programação, como o desenvolvimento de software. Vamos começar com o que são dados. Dados são algum tipo de informação agregada mantida em uma ferramenta de negócios. Se essa ferramenta é uma planilha ou um banco de dados depende do negócio, mas o lugar original onde os dados são criados é por onde começamos. 

 

Os dados brutos em uma fonte não são muito úteis para ninguém, e é aí que entra a engenharia de dados. Na engenharia de dados, chamamos o processo de obter esses dados e torná-los extraídos, transformados, carregados ou ETL úteis. Uma vez que os dados são extraídos das fontes, eles podem ser transformados de acordo com as necessidades do negócio e carregados em ferramentas de análise de negócios. É aqui que analistas de negócios e analistas financeiros têm a oportunidade de usar os conjuntos de dados para criar relatórios, gráficos e outras métricas solicitadas que informam as decisões de negócios. 

 

T é para transformação

 

A transformação é talvez o ponto mais crítico no processo de engenharia de dados. Vamos usar um negócio de varejo com várias lojas como um exemplo rápido. Digamos que haja várias lojas mais antigas em um sistema de ponto de venda (POS) desatualizado, enquanto as lojas mais novas estão executando um sistema mais moderno. As transações são registradas e armazenadas de forma diferente em cada tipo de sistema POS em bancos de dados diferentes. Se o proprietário da empresa deseja ver um relatório semanal sobre as vendas, isso exigiria uma agregação das transações de ambos os sistemas. 

 

Para conseguir isso, terá que haver um processo de transformação que possa obter informações sobre as transações de cada sistema POS e reuni-los de uma forma que faça sentido. Além disso, perguntas surgirão rapidamente sobre os dados da transação e sua relação com um relatório de vendas. Vou perguntar apenas uma: como as devoluções são contadas em cada sistema em comparação com uma venda real? 

 

Vamos levar este exemplo ainda mais longe. O sistema POS original armazena tudo em um tipo de banco de dados que é incompatível com o banco de dados do sistema POS mais recente, portanto, não há como simplesmente juntar as informações. Agora, o estágio de transformação deve incluir algum tipo de conversão de dados antes que as transações possam ser reunidas. Em última análise, o proprietário da empresa deseja apenas receber as informações de vendas agregadas em um relatório, o que parecia simples no início. 

 

A necessidade dos dados (o relatório de vendas) e o trabalho técnico necessário para transformá-los em algo que faça sentido (reunir sistemas díspares) são os dois elementos críticos que definem o significado do conjunto de dados. No caso do nosso exemplo, procurávamos o significado de “vendas” e precisávamos de um relatório sobre isso. Como você pode imaginar, esse tipo de definição de negócio nebulosa e subjetiva pode tornar os dados de teste muito complicados.

 

 

Agora temos uma ideia de como são os dados e a engenharia de dados. Não podemos definir a qualidade dos dados sem algum tipo de benchmark para medir, e geralmente dentro dos processos de teste esse benchmark é uma variedade de métricas reportáveis. Então, como encontramos algo mensurável para validar um produto no mundo dos dados? 

 

Seis dimensões da qualidade dos dados

 

O padrão atual da indústria em validação de dados é usar alguma forma das seis dimensões da qualidade de dados para testar modelos de dados, pipelines, arquitetura e muito mais. Essas métricas de qualidade de dados foram inicialmente definidas em um documento de qualidade de dados chamado "As Seis Dimensões Primárias para Avaliação da Qualidade de Dados", escrito pelo capítulo do Reino Unido da Data Management Association (DAMA) em 2013. As seis dimensões são uma série amplamente aceita de métricas de validação usadas para examinar a qualidade de qualquer conjunto de dados. Eles ajudam os engenheiros de qualidade de dados e engenheiros de dados a criar métricas de validação mensuráveis ​​que podem ser aprimoradas.

 

 As seis dimensões são: 

 

Consistência: se os dados forem copiados em vários bancos de dados, sistemas, tabelas e relatórios, eles devem permanecer os mesmos, tornando-os consistentes. Por exemplo, o CEP atual de um cliente deve sempre ter os mesmos cinco dígitos (nove se você estiver usando ZIP + 4), não importa onde você o encontre.

 

Precisão: talvez a mais nebulosa das métricas de qualidade de dados, a precisão é quão bem os dados em questão representam a ocorrência ou objeto do mundo real. Digamos que haja uma coluna que representa o valor agregado em dólares de todas as transações de um cliente e uma coluna que representa a soma total das transações em uma tabela. Cada um desses valores deve ser capaz de ser rastreado claramente até as fontes, onde pode ser provado que os totais são precisos para as transações do mundo real que ocorreram. 

 

Validade: em qualquer campo de um conjunto de dados, é provável que haja algum tipo de requisito de tipo de dados. Você nunca esperaria ver números em um campo de estado onde as restrições de campo são representações de duas letras dos estados dos EUA, como NY, CA ou IL. Se houvesse um número inteiro nesse campo, isso quebraria a validade dos dados.

 

Exclusividade: para cada registro exclusivo esperado em um banco de dados, deve haver um campo que identifica exclusivamente cada registro fornecido, por exemplo, um número de conta de cliente para um banco de dados de compras online. A exclusividade desse número de conta pode ser crítica para identificar transações repetidas para uma única conta de cliente.

 

Completude: os dados estão incompletos se houver campos críticos ausentes. Talvez em um registro de transação de negócios deva haver um carimbo de data / hora para cada transação. Se esse registro de data e hora estiver ausente, o conjunto de dados de transações está incompleto.

 

Oportunidade: Quais são as expectativas ao receber novos dados em cada relatório? A atualidade dos dados é definida pelas necessidades do negócio. Por exemplo, se for necessário que um conjunto de dados seja atualizado diariamente, a métrica de teste para pontualidade nesse conjunto de dados também é diária.

 

Para qualquer conjunto de dados, os testes e a validação de dados devem abranger cada uma dessas dimensões. Principalmente os testes de unidade automatizados, mas falaremos disso mais tarde. Se você estiver interessado em um mergulho mais profundo nas seis dimensões da qualidade de dados, leia este excelente artigo em Rumo à ciência de dados.

 

Teste de dados no processo de engenharia

 

Agora que sabemos sobre as seis dimensões da qualidade dos dados, como a engenharia de dados geralmente funciona e a importância crítica das definições de negócios das necessidades de dados, a tarefa passa a ser reunir todas essas coisas para criar um plano de teste. Os engenheiros de qualidade de dados estão no centro do processo de engenharia de dados; eles apóiam o trabalho técnico dos engenheiros para fornecer o conjunto de dados solicitado e trabalham com analistas de negócios para validar esses dados. 

 

Tipos de testes de controle de qualidade de dados

 

No mundo dos testes de software, existem vários tipos comuns de testes de qualidade úteis que identificam bugs, confirmam os componentes de trabalho e investigam o comportamento esperado do software. Esses tipos de teste ainda são extremamente úteis no mundo dos testes de dados, portanto, se você conhece essas categorias de teste, já entende algo sobre o teste de dados. 

 

Estes incluem, mas não estão limitados a:

 

Testes de unidade : testes de tamanho mínimo embutidos no código de modelagem de dados, usados ​​para identificar pequenos pontos de interrupção dentro de blocos de código críticos necessários para a funcionalidade básica. Por exemplo, talvez haja uma coluna em que nenhum valor NULL deva existir nos dados. Um teste de unidade rápido pode verificar se há NULLs em um campo e certificar-se de que não há nenhum.

 

Testes de integração: são testes que procuram as partes da soma de um programa ou pipeline de dados para funcionar, em vez de apenas uma parte dele. Em um exemplo de pipeline de dados, os testes de integração verificariam se todo o processo ETL poderia ser executado com êxito do início ao fim. 

 

Testes de fumaça: testes rápidos usados ​​para verificar com eficiência as partes mais importantes e geralmente comuns do pipeline de dados quanto a falhas. O termo teve origem em testes de hardware de computador, quando o primeiro teste inicial era conectar a máquina e ver se algum dos componentes mecânicos gerava fumaça. Caso contrário, o hardware passou no teste. Porém, se houvesse fumaça ... Como você pode imaginar, eles desligariam a máquina e tentariam novamente.

 

Testes de regressão: uma série de testes usados ​​para verificar as operações principais de um programa, chamados de “regressão” porque o conjunto de testes analisa as partes funcionais padrão do código que nunca devem ser alteradas. Normalmente, um pacote básico usado antes de um lançamento de produção. No caso de dados, a regressão geralmente cobre as transformações de missão crítica.

 

Testes de recursos: testes usados ​​para verificar quaisquer novos componentes (“recursos”) que foram adicionados a um programa além de suas operações atualmente lançadas. Eles são adicionados aos conjuntos de teste de regressão se os novos recursos forem essenciais para os lançamentos de produção e devem permanecer inalterados no futuro.

 

Talvez você esteja familiarizado com alguns deles e outros. Todos esses são tipos de testes comuns e úteis que muitas equipes de desenvolvimento de software usam regularmente. E eles podem e são aplicados ao teste de dados.

 

Testes de unidade como arma secreta da validação de dados

 

Assim como acontece com quase todas as funções de QA, a engenharia de QA de dados deve agregar valor ao trabalho da equipe de engenharia e fornecer feedback de maneira útil. O Data QA quase sempre começa com testes manuais, especialmente em empresas com banco de dados legado e tecnologia de data warehouse. Provavelmente haverá algumas centenas de scripts SQL a mais no laptop do engenheiro de controle de qualidade de dados. Mas esse teste manual ainda precisa verificar com eficiência as seis dimensões da qualidade dos dados, sem se tornar um gargalo para as versões de produção. Com tudo isso dito, a automação do teste de dados é totalmente possível, especialmente quando se trata de testes de unidade e asserções.

 

Na minha experiência, uma das maiores funções de um engenheiro de controle de qualidade de dados é divulgar os testes de unidade integrados ao pipeline de dados. Quando implementados por um engenheiro de dados durante o desenvolvimento da transformação de dados, os testes de unidade podem detectar erros de dados antes mesmo que os engenheiros de controle de qualidade de dados examinem o conjunto de dados. Normalmente os engenheiros de dados não estão acostumados com testes de unidade, pois isso é mais uma prática de desenvolvimento de software, mas não sou o único que acha que a engenharia de dados precisa de mais testes de unidade culturalmente . Estruturas populares de software livre, como a ferramenta de compilação de dados (dbt), têm testes de unidade integrados que podem evitar problemas de integridade, exclusividade e oportunidade. Outras ferramentas de validação de código aberto como Great Expectations camada um conjunto de testes de unidade de asserção de dados no topo do pipeline de dados.

 

Automação

 

A automação é um princípio crítico no mundo da qualidade de dados e na execução das seis dimensões da qualidade de dados. Por exemplo, usando a combinação de teste de unidade e teste para integridade de dados, os engenheiros de qualidade de dados podem escrever um pequeno e rápido teste automatizado que verifica qualquer valor NULL em um campo crítico. Quanto mais testes automatizados você tiver em seu pipeline de dados, verificando as dimensões críticas da qualidade de dados de várias maneiras, menos trabalho os engenheiros de dados terão de fazer. 

 

E se, em vez de gerar uma tabela e olhar para ela todas as vezes usando SQL e uma conexão de banco de dados, um engenheiro de dados tivesse um conjunto de testes de regressão embutido que executasse suas verificações diárias para ela? Esses são os tipos de fundamentos de automação úteis e engenharia de teste que os engenheiros de qualidade de dados fazem. 

 

Embrulhar

 

O teste de dados é um campo único que está crescendo e mudando diariamente. Não há muitos padrões de qualidade de dados amplamente aceitos, e até mesmo aqueles como as seis dimensões da qualidade de dados são debatidos. Mais campos de ciência de dados, como aprendizado de máquina e inteligência artificial (IA), estão crescendo e criando novas maneiras de validar a precisão, consistência, integridade dos dados e muito mais.

 

O que sabemos é que a qualidade dos dados agora depende muito do significado subjetivo do conjunto de dados que está sendo solicitado e das necessidades das pessoas no final do pipeline de dados. Isso torna difícil encontrar os benchmarks certos para testar e melhorar nossa qualidade de dados, mas ainda podemos usar nosso conhecimento de tipos de teste úteis e as dimensões da qualidade de dados para validar os dados que usamos todos os dias. E à medida que nossa compreensão de como usar os dados evolui, o mesmo ocorre com as métricas de qualidade de dados e nossa compreensão dos testes de dados.


Strong

4452 Blog Postagens

Comentários