O processo de limpeza de dados é um dos pontos mais sensíveis para extrair o máximo potencial da Ciência de Dados. Neste post, apresentamos uma abordagem em quatro etapas para lidar com dados ruins do ponto de vista de arquitetura e processo dos dados.
Hoje vamos falar de um assunto um tão problemático quanto [infelizmente] comum: os dados ruins. Eles são um conjunto impreciso de informações, como valores ausentes ou inadequados, informações erradas, duplicadas, com erros de digitação, variações na forma de notação, entre tantas outras coisas que nos deixam de cabelo em pé.
Utilizar esses dados pode afetar de forma significativa o desempenho de análises e projetos. Inclusive, de acordo com estimativas da IBM, o erro humano e a baixa qualidade de dados custam mais de US$ 3 trilhões por ano. De fato, dados sujos não são pouca coisa.
Para contornar o problema, a limpeza, ou Data Cleaning, é uma etapa vital para garantir a qualidade dos dados. Ela pode não ser a tarefa mais atraente do mundo para um profissional de dados, mas não tem como não passar isso. E às vezes apenas a limpeza não resolve, simplesmente porque alguns dados não podem ser limpos e readequados. Eles podem não apenas ser “sujos”, mas também podem ser “arquitetonicamente” incorretos.
Basicamente, a arquitetura de dados descreve quais sistemas são construídos para conectar dados à estratégia de negócios, definindo desde quando os dados são coletados até como são armazenados, gerenciados, transformados e, por fim, utilizados.
E o fato é que há espaço para erros em qualquer pipeline de dados, que podem se manifestar de várias maneiras, incluindo falhas na engenharia do conjunto de dados e bugs de streaming. Então, dados arquitetonicamente incorretos terão características como linhas ou colunas inteiras de dados ausentes, respostas de escolha forçada incorretas, dados coletados durante prazos errados ou com a amostra errada ou até dados que não se encaixam nos objetivos do projeto.
Não importa quantos “NAs” se capture ou quantos nomes de variáveis se renomeie, isso não vai compensar por dados totalmente ausentes ou inválidos. Mas como saber se os dados estão realmente inutilizáveis ou não? Emily Burns, pesquisadora norte-americana de neuropsicologia, propõe em artigo no Medium um sistema de quatro etapas, com o objetivo de mitigar erros de arquitetura e recuperar dados utilizáveis, garantindo um processo com mais qualidade. O objetivo geral deste sistema é identificar e corrigir erros na origem do pipeline:
Uma dica: antes de mergulhar de cabeça no fluxograma acima, examine seu conjunto de dados bruto. Procure padrões indicativos de dados defeituosos. Existem grandes blocos de dados ausentes misteriosamente? Os valores medidos podem responder às perguntas do seu projeto? Existem erros significativos que seus pacotes de limpeza não podem resolver prontamente? Não colete mais dados, a menos que seja necessário.
Um exemplo simples
Emily dá um exemplo para ajudar a ilustrar o sistema:
Uma startup de saúde mental holística quer fazer uma nova pesquisa em seu aplicativo com o objetivo de aumentar a interação dos usuários e permitir que a equipe de produto tenha insights sobre os clientes com baixo tempo de interação. Então a pesquisa é projetada e disponibilizada para um subgrupo de 50 clientes antes de ser lançada em todo o aplicativo.
Ao olhar os dados da pesquisa, percebe-se que há algo estranho:
Em primeiro lugar, dos quatro comportamentos do cliente monitorados pelo aplicativo, hábitos de meditação (meditação_feature ), hábitos alimentares (diet_feature), hábitos de exercícios (exercício_feature) e hábitos de sono (sleep_feature), todos os valores de meditação estão faltando.
Em segundo lugar, todas as variáveis what_app_type estão preenchidos como “Educacional”, o que, embora possível, é estatisticamente improvável.
Terceiro, cada recurso é rastreado pelo número de vezes que é visitado, não pelo tempo total gasto no recurso. Embora utilizáveis, esses dados não capturam o objetivo do projeto tão bem quanto esperado inicialmente.
Agora, é o momento de percorrer o fluxograma apresentado para lidar com dados inválidos.[
Etapa 1: é possível limpar ou solicitar novos dados?
SIM: Como já sugerido, não solicite novos dados, a menos que seja necessário. Erros de dados são comuns e muitos podem ser corrigidos. Se os erros realmente puderem ser limpos, devem ser feitos antes da análise.
Os erros do conjunto de dados atual são muito significativos para serem simplesmente eliminados. Entre a infinidade de ferramentas exploratórias por aí, podemos executar a função count () do pacote R “plyr” para determinar as distribuições de frequência do conjunto de dados (df).
Como podemos ver acima, a totalidade dos dados de Meditação_Feature está faltando (“NA”) e os dados de what_app_type são homogêneos de forma suspeita. A imputação é uma técnica de limpeza viável em muitas circunstâncias, mas prever colunas inteiras de dados é um método claro para exacerbar as preocupações de validade.
A coluna meditação_feature vazia também sugere que uma falha de streaming de dados pode ser a causa raiz do erro, pois é improvável que todos os dados de um recurso de aplicativo estabelecido estejam ausentes.
A coluna homogênea what_app_type também sugere um erro de arquitetura, pois é improvável que todos os 50 clientes tenham interagido apenas anteriormente com aplicativos “Educacionais”.
NÃO: A simples solicitação de novos dados não corrigirá o erro se a raiz do problema for a própria arquitetura, como é provável. E, como a limpeza também não foi possível devido à extensão dos erros, somos forçados a passar para a Etapa 2.
Etapa 2: há dados válidos suficientes para omitir os erros?
SIM: antes de pular para esta conclusão, convém se certificar de que o tamanho da amostra seja grande o suficiente para executar de forma confiável os modelos posteriores após remover as observações com erros.
Se o conjunto de dados for grande o suficiente para ignorar os erros de arquitetura sem custo estatístico significativo, as análises podem ser executadas assim que o conjunto de dados for reduzido de forma adequada.
NÃO: Neste exemplo, colunas inteiras do conjunto de dados são afetadas. Portanto, não é plausível remover cada observação com erros, pois ficaríamos sem quaisquer dados.
Além disso, a remoção de observações tem um impacto mais forte na precisão em conjuntos de dados pequenos do que em grandes. Como o conjunto de dados é pequeno, não temos dados válidos suficientes para omitir os erros. Iremos para a Etapa 3.
Etapa 3: há proxies disponíveis?
SIM: Proxy é um tipo de dado que pode não estar diretamente relacionado aos objetivos do projeto, mas que podem ser usados como aproximação de variáveis não medidas.
Neste exemplo, a proxy pode vir na forma de dados históricos, ou seja, dados coletados pela inicialização em um ponto de tempo anterior que tem variáveis relacionadas de forma proximal. As proxies históricas também podem vir na forma de conjuntos de dados disponíveis publicamente ou conjuntos de dados voluntariamente compartilhados por outras empresas.
NÃO: para fins de exemplo, vamos supor, em vez disso, que o recurso “meditação” foi lançado recentemente e ainda não há dados de interação de clientes o suficiente para projetar tendências de uso precisas para o projeto atual.
Como não há substitutos para os dados do recurso de meditação, passamos para a Etapa 4.
Etapa 4. Outra coleta de dados pode ser executada?
SIM: parece uma pergunta bastante simples, mas muitas vezes há vários fatores em jogo durante a avaliação da resposta.
Um desses fatores é o custo de repetir a coleta de dados. Quer seja o gasto de tempo, reorganizando itens prioritários da empresa ou o investimento monetário real que será necessário para pagar os participantes, os serviços de tecnologia envolvidos ou os próprios funcionários, a coleta de dados pode ter um custo orçamentário.
Outro fator em jogo é o próprio pipeline de dados. Se os erros forem realmente de natureza arquitetônica, simplesmente executar novamente a coleta vai resultar nas mesmas inconsistências que o levaram a esta etapa em primeiro lugar.
Existe um erro no design do front-end da pesquisa? Existe um serviço de streaming diferente que se integra melhor com a plataforma de aplicativo escolhida? Os dados foram perdidos na fusão de vários conjuntos de dados? Somente depois que perguntas como essas forem respondidas e as falhas devidamente corrigidas, a coleta de dados deve começar novamente.
Uma vez que os erros de arquitetura e a carga de executar medidas de coleta adicionais tenham sido resolvidos e aprovados, é possível continuar com as análises assim que o novo conjunto de dados estiver disponível.
NÃO: Novamente, por causa do exemplo, supomos a startup seja nova, com fundos mínimos e prazos rígidos. Então decide-se que apresentar os dados disponíveis no prazo é mais importante do que ter dados inicialmente perfeitos.
Isso leva à resolução final do fluxograma: modifique o objetivo do seu projeto. Como os dados disponíveis não medem se a interação anterior com o aplicativo influencia positivamente a interação dos clientes com os recursos atuais do aplicativo no nível micro que a equipe esperava originalmente (ou seja, o comportamento é influenciado pelo tipo de aplicativo, avaliação da bateria completa de recursos, e o tempo total gasto em recursos em vez do tempo total visitado), os objetivos do projeto devem ser alterados para destacar as avaliações macro.
Com isso em mente, simulação de um gráfico de barras é feita visualizando essas novas análises:
Não é uma análise tão refinada quanto se esperava, mas as tendências gerais ainda estão presentes. Porém, ao contrário da suposição natural, percebe-se que os clientes com experiência com aplicativos são um pouco menos propensos a abrir um determinado recurso.
A reflexão aqui é que vale à pena ser realista sobre a qualidade dos dados. Não importa a rapidez com que gostaríamos de passar pelas verificações e limpeza de dados, os dados ruins continuarão sendo dados ruins sem o escrutínio adequado.
Embora o exemplo seja simples e sintético, as etapas do fluxograma indicado permanecem as mesmas para projetos e conjuntos de dados mais complexos. Incorporar essa abordagem direta ao pré-processamento de dados do dia-a-dia pode ajudar a transformar o desconforto, perda de tempo e dinheiro de uso de dados ruins em confiança, eficiência financeira e análises de alta qualidade.
Outro ponto importante é que criar e gerenciar dados ruins de maneira proativa, em vez de fingir que eles não existem, significa que é possível não apenas minimizar o impacto negativo no negócio, mas também pode preparar o caminho para importantes melhorias.
A visibilidade adequada do processo de correção de dados ajuda a entender as causas dos dados ruins e ajuda a revelar outros problemas sistêmicos que precisam ser resolvidos. Problemas com os dados podem indicar a necessidade de alterações em outras partes do processo.
