É por isso que qualquer organização que considere os dados importantes para o funcionamento de seus negócios, sejam consumidores internos ou externos, precisa praticar o gerenciamento de qualidade de dados e implementar uma framework de qualidade de dados. É isso o que parece: desenvolver processos e padrões repetíveis, idealmente automáticos, para garantir que os dados que entram em seu sistema e são entregues fluxo abaixo sejam o que você e seus consumidores esperam.

E, como vocês engenheiros de dados seniores bem sabem, conhecer essas expectativas é metade do caminho. Grande parte da outra metade é gasta na tradução dessas expectativas em rastreamento e alertas que ajudarão você a encontrar e corrigir problemas em processos complicados de ingestão.

Neste guia, compartilhamos estratégias para garantir que o gerenciamento da qualidade dos dados não seja simplesmente adicionado aos seus processos codificados existentes, mas seja incorporado a cada DAG. Para gerenciá-lo bem, você precisa detectar anomalias muito antes que dados de baixa qualidade entrem na sua camada de transformação.

Vamos começar com uma definição. A estrutura de qualidade de dados é uma ferramenta que uma organização pode utilizar para definir atributos de qualidade de dados relevantes e oferecer orientação para um processo de gerenciamento de qualidade de dados para garantir continuamente que a qualidade dos dados atenda às expectativas dos consumidores (SLAs).

Essa frase é enganosamente complexa, então vamos descompactá-la:

1. Você precisa de um processo: a menos que você tenha horas de engenharia ilimitadas, um processo deve incluir testes de unidades repetíveis e, idealmente, automáticos em todos os estágios do seu pipeline de dados (especialmente na ingestão, se você quiser detectar problemas de forma proativa) e um fluxo de trabalho para lidar com problemas de dados.
2. Você deve garantir continuamente: A qualidade dos seus dados decai proporcionalmente à velocidade dos dados, também conhecido como desvio de dados. Dados de alta velocidade do tipo com o qual muitos de nós lidamos agora exigem verificações frequentes.
3. Você deve atender às expectativas dos consumidores, não às suas próprias: A qualidade dos dados é fundamentalmente um processo de negócios. Seus SLAs de dados ou “acordos de serviço” são com os consumidores e nada na parte de engenharia importa se os cientistas de dados não puderem executar seus modelos, se os clientes receberem estimativas de entrega de frete imprecisas, ou se o seu vice-presidente regional tiver que ir para a reunião do conselho sem informações porque o dashboard não carregou.

Há muita coisa para cumprir a promessa acima, e cada um desses elementos está repleto de dependências. Por exemplo, se você estivesse se perguntando como arquitetar um sistema desses, estaria fazendo as seguintes perguntas:

1. Como você entenderá as expectativas dos consumidores em relação à qualidade dos dados?
2. Como você traduzirá essas expectativas em medidas quantificáveis de qualidade de dados?
3. Como você implementará medidas automáticas de qualidade para cada um de seus pipelines?
4. Como você determinará os limites para cada dimensão da qualidade de dados?
5. Como você alertará sua equipe quando os dados violarem esses limites?
6. O que sua equipe fará quando receber um alerta?
7. Como eles avaliarão a validade e a urgência do alerta?
8. Se houver um problema, como eles identificarão a(s) causa(s) próxima(s)?
9. Como eles identificarão a(s) causa(s) raiz(is)?
10. Como eles informarão aos consumidores o que esperar?
11. Como eles lidarão com a causa raiz?
12. Como eles verificarão se abordaram a causa raiz?
13. Como eles documentam o que aconteceu para construir conhecimento?

Parece uma lista longa, potencialmente sem sorte? Não tenha medo. Você delega.

A pergunta 1 é mais adequada para o analista de negócios do seu grupo ou equipe. Cabe a eles conversar com as unidades de negócios para decompor histórias de usuários, preferências declaradas, preferências implícitas, solicitações e análises post-mortem de eventos em uma lista de “demandas” para os dados. Essas são as expectativas qualitativas que os consumidores têm dos dados, e é uma conversa bidirecional, pois eles podem não ter palavras para descrever exatamente o que querem. (A menos que seus consumidores de dados sejam seus cientistas de dados, o que pode realmente acelerar isso.)

A pergunta 2 é para você e seus cientistas de dados responderem juntos (especialmente se eles também forem o consumidor). Dadas as características dos seus dados para cada pipeline, quais atributos você pode realmente medir para decompor ainda mais a lista de expectativas qualitativas em uma lista de medições quantitativas?

Dependendo do modelo de qualidade de dados que você segue, há quatro ou cinco dimensões de qualidade a serem observadas. No IBM® Databand, preferimos um modelo com quatro características:

• Fitness
  • Precisão — os dados refletem a realidade
  • Integridade — qualidade/tempo
• Linhagem
  • Fonte — o provedor está atendendo às suas expectativas?
  • Origem—de onde veio?
• Controle
  • Controles de dados
  • Privacidade de dados
  • Regulamentação
  • Segurança
• Estabilidade
  • Consistência
  • Confiabilidade
  • Pontualidade
  • Viés

Com essas métricas em mãos, os engenheiros de dados podem responder às Perguntas 3-13 e começar a construir uma estratégia de gerenciamento da qualidade de dados. E antes de falarmos sobre como fazer isso, vale a pena se perguntar: por que fazer todo esse esforço?

Alguns anos atrás, uma mudança de configuração inócua no Microsoft Dynamics CRM de um grande varejista significou que o número de estoque exibido em cada item on-line deixou de refletir a realidade. O contador simplesmente parou de atualizar.

As pessoas continuaram comprando, mas o número de volume permaneceu constante. No momento em que a equipe de engenharia de dados foi alertada, as coisas ficaram ruins.

A maioria dos itens estava disponível para compra online, mas também para retirada na loja. Muitas pessoas optaram pela retirada na loja. Os pedidos foram processados e, mesmo assim, itens que não existiam foram vendidos. Assim, os consumidores visitavam lojas onde os associados de varejo se esforçavam para encontrar substitutos ou prometer descontos ou de alguma forma acalmá-los. Linhas formadas. Os visitantes da loja tinham que esperar para comprar e eram desanimados com tantas pessoas atacando seus telefones com raiva. E como levou dias para descobrir o problema e para o pipeline ser corrigido, passou mais alguns dias até que as coisas fossem resolvidas.

Considerando a perda de reputação da marca, o erro custou dezenas de milhões e não precisava ter acontecido.

Ou seja, os problemas de dados são complexos. Eles podem ser difíceis de identificar e resolver, e crescem de forma invisível. É fácil cair na armadilha de achar que tudo está funcionando só porque você ainda está extraindo alguns insights, mesmo enquanto acumula uma quantidade crescente de dívidas de dados subterrâneos.

Além disso, os sinais mais verdadeiros de problemas de qualidade de dados também tendem a ser indicadores atrasados. Por exemplo, os consumidores dizendo a você. Ou, como no exemplo anterior de CRM para varejo, com milhares de gerentes de varejo e vice-presidentes regionais contando tudo. Isso é ruim. Isso significa que os dados estão em seu sistema há algum tempo e levará dias para que uma correção dê resultados. Fale sobre a falta de expectativas dos consumidores.

Esta é a situação em que a startup de transporte marítimo Shipper se encontrou e por que eles investiram tanto para evitar que isso ocorresse. Sua equipe de engenharia de dados apresenta dados o mais próximo possível do tempo real para um aplicativo que ajuda os fornecedores de comércio eletrônico a entregar seu estoque em um porto de embarque. Não são apenas as expectativas dos seus consumidores com que precisam se preocupar, mas os consumidores de seus consumidores. E às vezes, quando o sistema estava desatualizado havia dois dias, ele criava ondas em cascata de expectativas perdidas. Por isso eles investiram pesado em gerenciamento de qualidade de dados e ferramentas que poderiam apresentar alertas antecipados com verificações automáticas.

O gerenciamento da qualidade dos dados é uma forma de tornar as verificações de qualidade dos dados automáticas e abrangentes, de modo que você esteja combatendo as forças da entropia em seus conjuntos de dados e pipelines com uma quantidade igual e oposta de força.

Vamos voltar ao exemplo anterior e à lista de perguntas. Seus analistas conversam com a empresa para coletar requisitos e você recebe uma lista de expectativas quantitativas do consumidor de seus cientistas de dados. Como então você prossegue e constrói o sistema?

Você desenha sua estrutura de qualidade de dados. Sua estrutura deve, antes de tudo, reconhecer que o sistema é um ciclo e que tudo o que você aprende sobre as expectativas dos consumidores, que estão sempre evoluindo, deve influenciar o sistema.

Vamos explorar cada uma dessas etapas:

1. Qualificar: analistas de negócios decompõem as necessidades dos consumidores em uma lista de requisitos
2. Quantificar: Os cientistas de dados decompõem os requisitos em medidas quantificáveis da qualidade dos dados que, a essa altura, ainda são apenas teóricas.
3. Planejar: os engenheiros de dados traduzem medidas quantitativas de qualidade de dados em verificações que podem ser executadas em sua plataforma de observabilidade de pipelines de dados. Essa plataforma é crítica: sistemas de fluxo de trabalho e agendamento de pipelines, como o Airflow e o Spark, podem detectar problemas no próprio pipeline, mas não nos dados, que é onde a maioria dos problemas surge. Seus engenheiros precisarão conhecer o que pode e o que não pode ser rastreado em seu sistema.
4. Implementar: os engenheiros de dados implementam o rastreamento e o testam. Como um exemplo muito simples, se os dados precisarem estar todos presentes e não faltarem campos ou colunas, você poderá definir um alerta sobre os parâmetros de integridade dos dados. Uma plataforma de observabilidade como o Databand torna isso possível e pode possibilitar que você configure a detecção de anomalias para que você não precise definir cada valor manualmente.
5. Gerenciar: os engenheiros de dados testam esses alertas em comparação com dados históricos do pipeline para verificar se eles realmente teriam funcionado conforme o esperado. Se verdadeiro, eles os colocam em produção junto com um plano de gerenciamento de incidentes para quem é responsável quando um alerta é disparado e o que eles farão quando receberem esse alerta.
6. Verificar: Engenheiros e cientistas de dados confirmam que ter a estrutura de gerenciamento de dados melhorou de forma mensurável o desempenho de acordo com as métricas desejadas. Os analistas de negócios confirmam com os consumidores que esse é realmente o caso.

E o que você faz com o seu framework? Você coloca em prática.

Como exploramos em muitos de nossos exemplos, o pior indicador de um problema de qualidade de dados é um indicador de atraso, digamos, de um consumidor dizendo que algo está quebrado. Grande parte do que fazemos em engenharia de dados é construir confiança junto com pipelines.

Ao investir em uma estrutura de gerenciamento de qualidade de dados que ajuda sua equipe a identificar problemas automaticamente, você criará dados confiáveis. E isso torna seu trabalho muito mais fácil.

Explore como o IBM Databand oferece melhor monitoramento de qualidade de dados detectando alterações inesperadas de colunas e registros nulos para ajudar você a cumprir SLAs de dados. Se você está pronto para fazer uma análise mais detalhada, agende uma demonstração hoje mesmo.