Skip to content

elmonvn/desafio1

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

desafio1

Desafio 1

Sumário

0. Equipe

1. Introdução

1.1 Apresentação do desafio e objetivos

O web crawling (e também o web scraping) são ferramentas indispensáveis para a aquisição de grandes massas de dados de forma mais automatizada e flexível, sobretudo a partir de plataforma tão heterogênea e mutante quanto a web.

Há que se destacar as diferenças entre web crawling e scraping, determinantes na escolha da metodologia/ferramentas para captura de dados, conforme discutido adiante.

O web crawling resume-se a navegar entre páginas através da busca de links em cada uma analisada e, de certa forma, a indexar o conjunto de páginas por onde navegou. Já o web scraping busca extrair dados das páginas individuais1. Na prática, ambas as ferramentas costumam realizar a função uma da outra, mas pode ser necessário complementá-las.

O objetivo principal deste projeto parte daí: o desafio consiste em, partindo de portais concorrentes de notícias sobre automóveis, adquirir dados e estruturar informações de notícias.

Os objetivos específicos do projeto são:

  • adquirir e estruturar dados de notícias em portais sobre automóveis, utilizando web crawlers e scrapers, além de solução de persistência de dados e de métricas das buscas;
  • documentar o worklog e processo de tomada de decisões sobre o projeto, bem como as informações colhidas e as métricas selecionadas de aquisição/estruturação dos dados;
  • e apresentar alternativas para escalar a solução implementada e para análises que podem ser realizadas sobre dados/métricas.

Este relatório em formato de README.md está disposto em seções que demonstram a maneira (metodologia) como será implementada a solução, qual o formato (arquitetura) decidido para a solução, e de que forma esta poderá ser aperfeiçoada em termos de software e processo.

Doravante, a solução aqui proposta será denominada desafio1.

2. Metodologia

2.1 Dados

Conforme supracitado, as bases selecionadas para o projeto de aquisição/estruturação de dados serão sites de notícias brasileiros sobre automóveis, dentre os 5 mais populares.

Os dados mínimos a serem coletados de cada notícia de cada portal serão: título (string), corpo do texto (string), autor (string), data (timestamp), url (string), e tags (string).

Outros dados, quando disponíveis, serão capturados para composição de métricas de metacaracterísticas (palavras por artigo) e de engajamento (likes ou número de compartilhamentos).

Todos os dados coletados serão dispostos em armazenamento persistente, ou seja, banco de dados para subseqüentes análises dos artigos.

Por fim, deseja-se guardar os metadados das aquisições, para posteriores manutenções da base de dados.

2.2 Ferramentas de software

Para que seja facilitado os posteriores deploy e migração para serviços de nuvem, foi decidido que a solução de web crawling/scraping desafio1 deve ser implementada sobre serviço de contêiner em plataforma Linux. Assim, o pacote Docker será adotada, devido a sua ampla participação e maturidade em ambientes de nuvem e por sua integração a boas práticas de DevOps.

A solução desafio1 será implementada na linguagem de programação Python, versão 3.7.3, complementada com os pacotes Scrapy e phoenixdb, a serem integrados nas images dos conteineres de aplicação.

O framework Scrapy é uma das alternativas mais populares para web crawling/scraping disponíveis para a comunidade Python, mas também razão de muitos projetos transferirem sua tecnologia para essa linguagem, devido a sua facilidade e sua riqueza de funcionalidades.

Já o pacote phoenixdb foi escolhido por ser o driver nativo de acesso, pela linguagem Python, ao Apache Phoenix, apresentado em seqüência.

Pela quantidade massiva de dados que o web crawling/scraping é designado para coletar, deve ser determinada uma solução de persistência de armazenamento de dados que tenha boa escalabilidade, acesso real-time e distribuído, flexibilidade de estrutura tipo NoSQL e maturidade de mercado, bem como boa integrabilidade com os serviços de nuvem mais populares. Assim, elegeu-se o Apache HBase, parte do ecossistema Apache Hadoop, como a ferramenta de banco de dados para este projeto.

Por outro lado, o HBase pode não ter a interface de consulta mais amigável para desenvolvedores habituados ao mundo relacional --- ou mesmo a outras plataformas NoSQL---, sobretudo por prover poucas operações do tipo CRUD e por restringir seu tipo de dados apenas a arrays de bytes. Assim, foi desenvolvida a solução Apache Phoenix, cujo objetivo é servir de query engine relacional (via SQL), ou camada relacional, para as chamadas nativas ao HBase, além de paralelizar o acesso ao banco. Portanto, o Apache Phoenix foi eleito como camada de acesso ao HBase para este projeto.

As versões utilizadas para todo software mencionado aqui serão as mais recentes.

As ferramentas para análise dos dados recolhidos serão definidas a posteriori, recorrendo-se, no momento, a consultas individuais ao banco via Phoenix.

3. Proposta de solução

3.1 Arquitetura

De forma "macro", observa-se que os artigos de portais sobre automóveis não costumam ter alta freqüência de postagem. De fato, pode-se dizer que são lançamento de notícias sazonalmente, com pico nos último trimestre do ano, quando são divulgados novos lançamentos no mercado para o ano seguinte e as avaliações do tipo "melhor do ano". Logo, é seguro recorrer à estratégia do processamento batch da aquisição dos dados desses portais.

Além disso, para melhor integração e modularização da solução desafio1, bem como melhor adequação às boas práticas do Scrapy, estabeleceu-se que cada spider (crawler) para cada portal ficaria em contêiner separado dos outros. Desta forma, serão criado 5 conteineres, 1 para cada portal. Sobre estas 5 imagens, serão instalados os pacotes Scrapy e phoenixdb, e será copiada a estrutura de diretórios /desafio1/src/desafio1crawlers, igual para cada imagem, mas a ser acionada por spiders diferentes cada uma, referente ao portal em questão. A imagem base será adquirida do Docker Hub, mais especificamente a imagem python.

Por fim, será criada uma imagem única para o HBase e o Phoenix, a partir daquela disponível no Docker Hub harisekhon/hbase.

A figura abaixo ilustra, de forma esquemática, a arquitetura:

Arquitetura de desafio1

3.1.1 Estrutura de dados

Metadados

Métricas de engajamento

3.2 Build

Dockerfiles

3.3 Monitoramento

3.4 Desempenho

3.5 Estratégia de deploy

4. Conclusões e melhorias futuras

  • Apache Gora

  • Apache Spark

  • Apache Nutch

  • PySpark (Python)

Referências

1: https://www.skylynapps.com/scrapemate/learn/help/general/difference-between-crawler-and-scraper.php

Apêndice - Worklog

Data de início Atividade Duração
13/11/2019 Análise e entendimento do desafio proposto 1:00
13/11/2019 Criação do repositório desafio1 no GitHub 0:10
17/11/2019 Revisão das melhores ferramentas para web crawling/scraping 4:00
17/11/2019 Atualização sobre funcionalidades do Scrapy 1:00
18/11/2019 Revisão sobre funcionalidades do Apache HBase e Apache Phoenix 2:00
18/11/2019 Documentação do projeto, arquitetura e módulos (início) 2:00
19/11/2019 Criação do projeto no Scrapy denominado desafio1crawlers 0:10
18/11/2019 Revisão sobre arquiteturas possíveis para projeto 4:00
19/11/2019 Documentação do projeto, arquitetura e módulos (continuação) 2:00
20/11/2019 Documentação do projeto, arquitetura e módulos (continuação)

Releases

No releases published

Packages

No packages published

Languages