DATA SCIENCE: QUALIDADE, LIMPEZA E ARMAZENAMENTO DE DADOS

Recentemente, mostramos como identificar um problema em projetos de ciência de dados (que é drasticamente diferente da coleta tradicional exigida por BI - Business Analytics) e discorremos sobre o processo e as ferramentas relacionadas à coleta de dados brutos. Agora que sabemos como fazer as perguntas certas para enquadrar os problemas da empresa e estamos capacitados a coletar os dados brutos, é hora de iniciar uma atividade crucial: o Processamento de Dados.

Procurando examinar os dados em um alto nível, o Engenheiro de Dados deve diferenciar as etapas de manipulação ou processamento dos dados a fim de propor a arquitetura e os componentes que melhor se ajustem às necessidades de cada etapa.

De quais etapas estamos falando? Para ser sucinto, a resposta é:

• Qualidade e Limpeza de Dados
• Armazenamento de Dados

Os processamentos de dados que iremos focar nesta publicação são preparatórios para as fases seguintes do Processo de Ciência de Dados (veja a primeira publicação da série), denominadas Exploração de Dados e Análise Profunda.

Qualidade e Limpeza de Dados

Os dados possuem um conjunto inteiro de propriedades que os definem: tipo, formato, acesso, disponibilidade, volume, natureza... Todas essas propriedades irão influenciar a definição dos componentes de arquitetura e os processos de coleta e manipulação de dados. 

Começando pelos dados brutos - que queremos manter como estão para salvar uma “imagem digital” dos dados de origem - o Engenheiro de Dados inicia uma análise de alto nível, em geral procurando por erros formais, como tipos de dados incorretos (por ex. a expectativa é descobrir uma data, mas chega a um número ou a códigos e classificações inconsistentes, valores perdidos, etc.) e aplica técnicas para limpar os dados e melhorar a qualidade dos mesmos (por ex. interpolação para estimar valores perdidos).

Aqui é onde a teoria e a prática podem entrar em conflito: existe uma barreira entre as tarefas de um Engenheiro de Dados e um Cientista de Dados? O que quero dizer é que as atividades de limpeza de dados podem ser realizadas a partir de uma perspectiva puramente “formal” (exemplos acima) ou mirando no problema empresarial que queremos resolver. Por  exemplo,  altos e baixos em uma série de dados são geralmente uma boa prática na previsão de processos, mas eu poderia estar diante de um caso empresarial em que altos são eventos importantes que eu quero investigar e não eliminar.

Supondo que estamos trabalhando com ambas as competências na equipe (caso contrário, estaríamos com pessoal inadequado), essa não é uma questão crítica e pode ser solucionada com um trabalho em equipe no padrão tradicional. Nossa sugestão é ter Cientistas para verificar e oferecer suporte nas tarefas de Qualidade dos Dados realizadas por Engenheiros até porque, no final do dia, quatro olhos são mais eficientes que apenas dois.

Em termos de ferramentas e competências, existem muitas plataformas de integração de dados que contêm sólidos critérios de qualidade (Oracle, Informatica, IBM, Talend - apenas para nomear as mais comuns no mercado) que encurtam o tempo necessário para executar tarefas específicas, especialmente aquelas destinadas à padronização (p. ex. nomes, endereços, normatização de números de telefone). Além disso, frequentemente vemos linguagens e estruturas como Python, R e Scala sendo usadas quando os requisitos de limpeza de dados são considerados mais “exóticos” e baseados em condições. Obviamente, as Plataformas em Nuvem oferecem serviços de apoio às atividades de gerenciamento de dados de modo que possa ser implementado qualquer tipo de arquitetura, seja ela local, completamente na nuvem ou híbrida.

Armazenamento de Dados

Outra importante decisão que o Engenheiro de Dados tem que tomar é com relação ao repositório - onde são armazenados os dados extraídos, uma vez que existe uma variada gama de opções: arquivos, bancos de dados relacionais, banco de dados NoSQL (colunas, documentos, gráficos), chave-valor e XML - apenas para mencionar os mais comuns.

Um dilema típico surge quando temos que escolher entre os Bancos de Dados Relacionais e NoSQL.

Os bancos de dados NoSQL (não-relacionais) têm a vantagem de serem mais escaláveis e são projetados para suportar estruturas distribuídas; em geral, são mais velozes, adaptáveis e flexíveis do que os bancos de dados Relacionais. Além disso, sendo estruturados em documentos e armazenando informações em uma hierarquia semelhante a pastas, os bancos de dados Não-relacionais são a melhor opção quando se trata de armazenar dados não estruturados como documentos, imagens, tweets e qualquer tipo de dados difíceis de serem encaixados em uma estrutura de “coluna por linha”.

Por outro lado, os bancos de dados NoSQL não são 100% compatíveis com SQL padrão e, acima de tudo - não podem garantir a integridade absoluta dos dados (que seria o nirvana dos armazéns de dados). Pode-se acrescentar ainda que nos casos em que os requisitos de análise podem ser atendidos por dados estruturados e onde não se espera um crescimento exponencial da empresa, pode-se tranquilamente encontrar suporte em um BD Relacional.

Nem todas as soluções de aprendizado de máquinas precisam de grandes volumes de dados (Uau, eu disse isso) - na verdade, tais soluções dependem da natureza do problema da empresa e, consequentemente, do tipo de dados com que você terá que trabalhar. A boa notícia é que você pode ter uma arquitetura de dados onde os dois tipos de bancos de dados coexistam e fazer uso do melhor suporte para diferentes tipos de carga de trabalho e de armazenamento.

A inovação tecnológica atual nos permite promover o armazenamento distribuído (reproduzido) que consiste basicamente na distribuição de cópias de dados em servidores diferentes, o que permite melhorar a flexibilidade, desempenho e escalabilidade, solucionando problemas em episódios de falhas no sistema. Isso não exige muito conhecimento por parte dos Engenheiros de Dados, pois é algo feito de maneira clara pelo próprio banco de dados, especialmente se estamos usando Serviços em Nuvem, como o Amazon Aurora, Google Spanner ou Microsoft Cosmos DB.

Escolha a arquitetura mais apropriada para a sua solução

Uma vez que possuímos os dados, o Cientista de Dados pode começar o processo de análise para alcançar os objetivos propostos. Para implementar esses processos, podemos usar as mesmas linguagens de programação e estruturas usadas para a busca dos dados ou até mesmo utilizar ferramentas abrangentes, como a Knime, RapidMiner, DataRobot, SAS Visual Data Mining (Mineração Visual de Dados) e Machine Learning (Aprendizado de Máquina), mas vamos nos ater ao nosso propósito original, vamos falar sobre arquitetura de dados e processamento.

A forma como os processos analíticos são organizados e executados introduz conceitos tais como sistemas distribuídos e sistemas paralelos, cuja diferença, em termos gerais, é que um sistema paralelo pode ser definido como aquele que divide o processo em tarefas que são executadas ao mesmo tempo  enquanto o sistema distribuído divide um processo em tarefas que são executadas em locais diferentes utilizando recursos diferentes. É interessante conhecer a forma como os processos são executados para aumentar suas possibilidades com o dimensionamento de recursos.

Os resultados da nossa análise e a execução dos nossos algoritmos podem ser integrados e armazenados novamente no mesmo sistema de onde foram tirados os dados de entrada, armazenados em nosso repositório  (potencialmente um lago de dados - data lake) ou até mesmo em um novo repositório de análise específico que permita um modelo de aproveitamento mais ágil e rápido.

É recomendado que os Engenheiros de Dados criem e mantenham um dicionário de dados, contendo todas as definições de fontes, processos de carregamento, transformações, KPIs... e, em geral, todas as informações coletadas, pois esses registros podem ser muito úteis no momento de elaborar ou fazer uso de tais informações em análises futuras.

Assim sendo, após os Cientistas de Dados identificarem o melhor algoritmo para fazer face às necessidades da empresa e obter resultados de alta qualidade, é hora de indagar sobre visibilidade, acessibilidade e confiabilidade da informação produzida. Como afirmamos acima, algumas vezes o problema é “onde armazenar os dados”, porém, cada vez mais ele tem sido identificado em “como os usuários irão acessar os dados” o que nos coloca diante de cenários variados.

Pode ser que o novo conhecimento inferido pela aplicação de técnicas de Ciência de Dados seja usado para dar suporte ao processo de análise realizado por equipes internas especializadas, mas pode ser também que a informação tenha que ser consumida por aplicativos de terceiros, até mesmo aqueles transacionais (pense em um algoritmo para sugerir qual será a Próxima Melhor Oferta em um processo de vendas). Nesses casos, precisaremos implementar mecanismos e protocolos para acessar a informação com interfaces de comunicação como APIs ou desenvolver mecanismos através do uso de tecnologias (o Apache Beam, para citar uma).

Para finalizar, mesmo em uma etapa do Processo de Ciência de Dados, como o Processamento de Dados, que a primeira vista pode parecer menos complexa do que as outras, a quantidade de interseções técnicas, decisões a serem tomadas, opções a serem selecionadas e a tecnologia envolvida é tão grande que é muito raro encontrar todas as competências necessárias em uma única pessoa, por isso podemos concluir que a Ciência de Dados é definitivamente um esporte de equipe!

Para saber mais sobre esse tópico, não se esqueça de ler nossos artigos anteriores:  

• DATA SCIENCE OU CIÊNCIA DE DADOS: UMA ABORDAGEM PARA A RESOLUÇÃO DE PROBLEMAS E ESTRATÉGIA EMPRESARIAL
• DATA SCIENCE: DEFININDO O STATEMENT DO PROBLEMA
• DATA SCIENCE: COLETA DE DADOS BRUTOS (RAW DATA)

Confira o que está por vir: 

• DATA SCIENCE: EXPLORAÇÃO DE DADOS
• DATA SCIENCE: MACHINE LEARNING EM AÇÃO
• DATA SCIENCE: 5 DIAS PARA UMA NARRATIVA DE DADOS EFICIENTE

Até o próximo artigo!