O desafio do dia a dia da engenharia de dados

No mundo dos dados, onde todos os holofotes estão voltados para Machine Learning e algoritmos de Inteligência Artificial, toda empresa deseja arduamente dizer que utiliza algum recurso extremamente inovador ou do “estado da arte” do big data. É como uma frase do Dan Ariely sobre Big Data em um tweet lá em meados de 2014 (deixo aqui a semente para que você procure a analogia que ele fez), nem todos sabem exatamente do que se tratam esses métodos de decisão ou de auxílio a decisões.

O que a maioria esquece, é que para qualquer modelo, ou até mesmo para uma simples análise, é preciso ter os dados em “mãos”. Aí é que entra a figura do engenheiro de dados, que é o profissional capaz de extrair, tratar e armazenar dados para que o negócio possa utilizá-lo em suas análises, relatórios e futuros modelos preditivos.

O maior desafio desse profissional é a primeira parte, a de extrair o dado. Logo depois vem a complexidade de tratá-lo, para finalmente armazenar em um banco de dados ou em um data lake (data lake, normalmente, é um grande repositório de arquivos que suporta dados de diversos formatos, inclusive dados de voz, imagens, vídeos, etc).

Hoje em dia, praticamente nenhuma empresa tem todos os seus sistemas desenvolvidos dentro de casa, o que torna o trabalho do engenheiro de dados, digamos, mais interessante.

Áreas de negócio contratam sistemas sem a noção de quais dados podem ser extraídos de lá ou se esse sistema tem suporte a algum método de “extração completa”, “automática” ou “integrada” dos dados.

Para ilustrar melhor, criei um gráfico colocando nos eixos X e Y os componentes citados acima (extração e limpeza)

Para que a leitura não fique tão cansativa, iremos falar apenas sobre os tipos mais comuns de fontes de dados que as empresas precisam para, minimamente, chegar a um modelo de Machine Learning e como a engenharia de dados faz para entregar um bom resultado.

Bancos de dados das aplicações próprias

Hoje em dia, com o auxílio de diversas ferramentas dos provedores de nuvem, não fica tão complexo (com algumas dependências resolvidas, claro) para coletar, mas dependendo de como o sistema se comporta no armazenamento “cru” dos dados, há um certo esforço de limpeza e relação dos dados entre si para que fiquem legíveis ao negócio. Isso, se houver uma documentação razoável sobre como os dados do sistema estão, sua descrição, de onde vem e pra onde vão. O famoso dicionário de dados.

APIs

Muito resumidamente, Application Programming Interface, ou API, trata-se de um conjunto de requisições que permite a comunicação de dados entre aplicações. Porém, como nem tudo são flores, nem toda API entrega todos os dados necessários, a documentação geralmente é incompleta ou desatualizada e os dados vem em formatos que requerem bastante tratamento até que sejam bem consumíveis pelo usuário final.

De qualquer forma, alguns bons sistemas possuem APIs que atendem a demanda de dados, tornando o processo de coleta possível e até mesmo “plugável”, para que os dados sejam obtidos em NRT (Near Real Time), ou seja, quase em tempo real.

Extrações de arquivos

Geralmente, já vem “prontos” em formato de relatório para uso do negócio. Porém, nem sempre são rápidos de serem extraídos em relação à quantidade de dados que trazem, além da necessidade da criação de um processo automatizado de coleta, chamado hoje de RPA (robotic process automation), ou popularmente conhecido como bot, que requer o conhecimento avançado de um engenheiro de dados para que o fluxo funcione bem e o dado chegue prontinho todos os dias para a área de negócio.

Esses dados não tem a menor condição de serem analisados em tempo real, uma vez que todo o processo de obtenção é lento.

Webscrapping (a apelação final)

Quando você não tem os dados para coletar das fontes internas ou nos sistemas contratados, mas conhece uma fonte pública, porém que não tem API nem extração de relatório, o webscrapping se torna essencial para que o dado seja coletado e usado pelo analista de dados. Esse método simula a requisição a uma página da internet e faz uma varredura no código da página em busca de dados.

O processo de criação de um script que faça isso é complexo e nem sempre rápido de ser executado, pois depende de uma série de fatores, como a velocidade da internet local e do servidor do site em que se está obtendo o dado, até mesmo de como o site é organizado. Além do fato de que o site pode mudar sua estrutura a qualquer momento e invalidar totalmente o script criado, ou seja, é um método de coleta bom porque obtém os dados, mas longe de ser o processo ideal de coleta oficial.

Para resumir…

Ficamos então com o seguinte cenário:

Vemos que realmente não há moleza na vida do engenheiro de dados, não é mesmo!?

Entendendo um pouco mais sobre os tipos mais comuns de fontes de dados e como o trabalho do engenheiro de dados é fundamental para o sucesso do negócio, espero que se você, leitor, for responsável por uma área de negócio, envolva a área de engenharia de dados na contratação dos seus sistemas de fornecedores externos e o mesmo envolvimento também deve ocorrer caso haja um sistema sendo desenvolvido internamente, pois somente com os dados, a empresa consegue virar a chave para um modelo orientado à eles.

Aos profissionais da engenharia de dados, meu sincero respeito à resiliência que vocês tem!

Aqui no Edify, nós temos todos esses tipos de desafios (e mais alguns), e não por isso deixamos de entregar o que nossos stakeholders precisam 😉 !