O Web Scraping, também chamada de coleta de dados da web ou raspagem da web, é uma forma de mineração que permite a extração de dados de sites da web convertendo-os em informações estruturadas para posterior análise. Em um projeto de Ciências de Dados, a coleta de dados é uma importante etapa, a partir da coleta é que começamos a aplicar o conhecimento específico.
Essa publicação surge como experiência de um projeto que eu desenvolvi para coletar informações de vários sites e a partir das dificuldades, encontrei essas dicas como soluções para melhorar o desempenho de um Web Scraping que por diversos fatores podem tornar o projeto lento e cansativo.
Com o Web Scraping você consegue automatizar tarefas que uma pessoa realiza em sites da web. Por exemplo, todo dia você acessa um site de esporte específico para conferir o placar atual e clica em cada time para conferir as últimas notícias, com o web scraping você automatiza esse processo podendo transformar em um relatório único e muito mais fácil de ler.
Ou seja, tudo que uma pessoa possa fazer em um site da internet pode também ser programado, automatizado e executado repetitivamente.
Nesse projeto de Web Scraping eu utilizei a linguagem de programação C# (C Sharp), .NET Core e o framework Selenium.
Framework Selenium
O Selenium é um framework open-source que fornece em várias linguagens de programação a emulação de um browser para desenvolvimento de robôs que automatizam a coleta de dados da web (web scraping) como se fosse uma pessoa real utilizando.
Meu projeto e experiência adquirida
No projeto desenvolvido eu precisei acessar cerca de 3200 páginas de vários sites de 5 sites, coletando informações de tabelas presentes nas páginas e executando posteriormente a refinação e estruturação.
Acessar 3200 páginas e copiar o conteúdo existente só é possível utilizando programação. Um trabalho custoso para computadores comuns, muitas vezes acessando sites em servidores lentos, com dados que não estavam padronizados, categorias discrepantes, dados preenchidos com erros humanos como valores monetários contendo ou não “R$”, ponto ou espaço para separação de milhar, lançamentos errados, diferentes unidades de medidas para cada registro. Causando ainda mais lentidão no processo.
Apesar de tantas regras para transformar esses conteúdos em dados aproveitáveis, a maior dificuldade do projeto foi o tempo de execução.
Como experiência adquirida surgiram essas dicas para aumentar a velocidade de processamento. Eu dividi o projeto em etapas com funções distintas.
Etapas para melhorar o desempenho de um Web Scraping
Etapa 1: Salvar o HTML original do site
Foi comum nesse projeto eu ter que passar novamente por todas as páginas escaneadas para coletar novas informações não previstas antecipadamente.
Essa é a etapa mais demorada, acessar uma página web com tantas adversidades pode demorar milissegundos e até segundos que multiplicados pelas 3200 páginas previstas tornam um desenvolvimento bastante lento e inviável.
Por exemplo: acessar uma página de um site pode demorar 1,8 segundos (1 hora e meia esperando processar tudo), mas acessando o arquivo salvo em HTML demora 200 milissegundos, ou seja, o mesmo processo demorará somente 10 minutos.
Então para evitar essa demora, nessa camada eu fiz o processo de apenas acessar a página e salvar em arquivos HTML para que toda vez que eu precise acessar a página novamente, eu primeiro verifico se existe o HTML salvo e acesso esse arquivo.
Esses arquivos HTML, também chamados de “cache” e foi utilizado o padrão de nomeação dos arquivos no formato link da página em MD5.html, evitando possíveis duplicidades e caracteres não permitidos.
Apesar dessa etapa ser melhor recomendada para páginas com conteúdo estáticos, também é útil fazer para páginas dinâmicas. Pois é melhor que você programe quando vai acessar o conteúdo do site original e quando vai acessar o conteúdo salvo em HTML. Trazendo mais liberdade e processamentos muito mais rápidos.
Etapa 2: Obter os dados brutos
A obtenção dos dados brutos é acessar novamente as páginas, mas agora utilizando o cache das páginas salvas em HTML (ou seja, um processo que demora cerca de 10 minutos) e obter os dados que realmente necessita.
Os dados são obtidos sem realizar qualquer conversão e verificação, conforme estão nas páginas, foram salvos em uma lista na memória e posteriormente no disco em formato JSON.
No projeto eu precisei acessar as páginas e obter uma tabela existente com 5 colunas. Como já dito, essa tabela contém dados não padronizados e por isso cada coluna foi salva em formato String, sem realizar qualquer conversão ou verificação.
O motivo de se fazer isso é que apesar dessa etapa ser bem mais rápida do que a primeira, demorar 10 minutos continua sendo muito tempo caso precise executar várias vezes. Veja como ficou o arquivo JSON:
[
{
"datalancamento": "01/01/2021",
"empresa": "NOME DA EMPRESA",
"produto": "Produto Teste 001",
"qtde": "1 unidade",
"peso": "1,20kg",
"preco": "1,25"
}
]
Pode-se observar que os campos que os campos que deveriam ser inteiros ou decimais foram salvos como string.
Etapa 3: Refinar os dados brutos
Essa é a etapa que mais foi executada, apesar das etapas 1 e 2 terem sido executadas várias vezes, essa etapa 3 foi executada mais de 100 vezes, pois cada nova regra identificada de refinamento era necessária uma nova execução.
Estimando um tempo de 3 segundos para essa execução, o desenvolvimento ficou muito mais rápido e viável.
Conforme explicado na etapa 2, com o arquivo JSON bruto, essa etapa 3 lê o arquivo JSON, aplica regras de conversão e salva no mesmo arquivo mas em novas colunas contendo o sufixo “_convertido“, veja o exemplo abaixo:
[
{
"datalancamento": "01 jan 2021",
"datalancamento_convertido": "2021-01-01",
"empresa": "NOME DA EMPRESA",
"produto": "Produto Teste 001",
"produto_convertido": "Teste 001",
"qtde":"1 unidade",
"qtde_convertido": 1,
"peso":"1,20kg",
"peso_convertido": 1.2,
"preco":"1,25",
"preco_convertido": 1.25
}
]
Tempo de processamento para cada etapa
| Etapa | Qtde. de vezes executada | Tempo p/ cada execução |
|---|---|---|
| Etapa 1: Salvar o HTML original do site | +- 3 vezes | 1 hora e meia |
| Etapa 2: Obter os dados brutos | +- 10 vezes | 10 minutos |
| Etapa 3: Refinar os dados brutos | > 100 vezes | 3 segundos |
| TOTAL | 1 hora e 43 minutos |
Como podemos visualizar, se não fosse aplicada essas 3 etapas toda execução demoraria 1 hora e 43 minutos para cada alteração ou nova regra aplicada.
Limitei aqui a falar sobre melhorias que possam refletir em um desenvolvimento com maior velocidade e robustez sem os exemplos técnicos em código.