NatanOCR – Apenas meu blog rápido para postar minhas pesquisas de TCC

Apenas meu blog rápido para postar minhas pesquisas de TCC

Borboletas Negras x Unicórnios Alados — July 1, 2016
Conceito de API — June 27, 2016
Desenvolvendo um Crawler — March 29, 2016

Desenvolvendo um Crawler

Desenvolver um crawler que seja focado não é uma tarefa assim tão difícil, talvez a parte que seja mais difícil seja iniciar o projeto quando se ainda está cru e não se tem entendimento sobre o assunto, no fim das contas um Crawler se trata de um robô que cai de cabeça  numa piscina de url’s que pode  varias de dezenas a milhares ou até mesmo milhões de urls.

A estrutura funcional não é tao complexa – julgando que no meu protótipo não estou implementando a indexação, ranqueamento ou Graph como o Google, mas sim coletando metadados e informações para posteriormente serem utilizados dentro da api.

Um cenário de aplicação para este protótipo sera mencionado abaixo:

Um programador sem experiencia com recuperação de informações online se depara com o seguinte projeto em mãos: ele tem que construir um projeto que capture informações online e armazene-as para serem posteriormente utilizadas pelo sistema. Quais dificuldades ele encontraria pelo caminho.

  1. acessar as informações online.
  2. coletar  as informações desestruturadas.
  3. estruturar essas informações.
  4. salvar essas informações de modo prático e rápido.
  5. criar um mecanismo para recuperar essas informações de modo prático e rápido disponibilizar as informações.

1 – Acessar as informações é relativamente fácil desde que a linguagem utilizada pelo desenvolvedor tenha suporte para requisições online e claro consiga interpretar e gerenciar os códigos http, que obviamente são muitos, pelo fato desse ser um protocolo bastante extenso que mantem a web funcional como temos hoje, seja ele o http1 ou http2 (ainda em processo de implantação). (um pouco da historia do http e para que ele serve) Alguns dos principais e mais conhecidos códigos http são 404 para erro de nada encontrado, 403 para erro depara erro de acesso proibido 200 para ok sucesso, 500 erro interno de servidor, 503 erro de serviço indisponível, 504 tempo esgotado. Além de se realizar um bom gerenciamento de erros para que o serviço de crawler não venha a parar prematuramente é necessário que se leve em conta as boas praticas ou mais conhecidos como a educação do crawler, um dos principais pontos a serem focados nesse processo é não  extrapolar os limites de acesso do site principalmente não realizar, evitar ou tomar bastante cuidado com os horários de picos de acesso, isso pode vir a provocar um gargalo nos acessos e posteriormente derrubar a aplicação do ar, assim como dependendo das configurações do Sysadmin o ip do crawler pode ser bloqueado por algumas horas, 24 hrs ou 48 hrs horas ou até mesmo ser adicionado a uma black list de ips e perder por completo ao acesso a aplicação. (organizar melhor essa parte a seguir) —  Quando não se leva em conta a educação nas requisições pode-se facilmente quebrar as barreiras de um processo de raspagem e virar um ataque DDOs, onde seriam feitas tantas requisições que a aplicação alvo não daria mais conta de atender e seria levada  abaixo, isso poe vir a causa grandes prejuízo alem e claro de ações judiciais caso seja identificada a origem de todo esse trafego, nesse caso um ponto importe a ser atenção é se o software trabalha em, assíncrono ou com treds, nesse situação e de suma importância que se tenha um controle rígido do numero de processos simultâneos. Outro ponto importante é analisar o arquivo robots.txt (explicar historia e funcionalidade) esse arquivo contem metadados muito importantes que devem ser levados em conta, tais como urls ou diretórios que são ou não liberados para acesso por parte dos crawlers, a análise desse arquivo também esta envolvida no tocante a educação  do crawler já que muitos sistemas contem partes que seus administradores não pretendem que sejam acessadas pelo publico, ou que realmente devem ser acessadas, este se trato do arquivo de comunicação que liga o sysadmin ao crawler.  (mostrar exemplo de arquivo robots.txt).

2 – Quando se faz coleta de informações em websites significa que se esta coletando dados não estruturados ou seja que na melhor das hipóteses apenas não estão devidamente organizada, consequente o desenvolvedor terá que encontrar uma maneira de processar as paginas requisitadas no passo anterior. Tratar paginas html para coletar metadados pode vir a se tornar algo bastante trabalhoso e falho principalmente pelo fato de que os desenvolvedores de web interfaces por diversas vezes não tem pleno domínio de conhecimentos de Webdesign, consequentemente teremos Layouts quebrados, o que pode vir a prejudicar a coleta de metadados, obviamente que podem haver problemas maiores como o fato de o sistema ter sido desenvolvido em tecnologia java, e neste cenário o desenvolvedor optou por utilizar uma bela Framework java, não sendo via de regra mas geralmente Framework java acabam por gerar mais lixo que interface propriamente dita, assim atolando o projeto com tags e metadados desnecessários que podem vir a interferir durante a coleta, obviamente que também podemos contar com o fato de as tags html terem sido mal escritas e não foram devidamente encerradas com o seu conteúdo.

Existem diversas técnicas para tratamento de metadados html,  durante o processo de parseamento dessas paginas poderíamos utilizar por exemplo lxml, xpath ou cssselectors, html5lib. Estas são bibliotecas especializadas no processo de parseamento de xml e html. Cada uma tem suas especificidades mas todas conseguem facilmente extrair as informações das paginas. O lxml por exemplo é uma biblioteca de parseamento escrita em c bastante robusta, dependendo do projeto pode até mesmo ser inviavel utiliza-la pois poderia até mesmo vir a prejudicar em performace, porem por conta de sua arobustes pode vir a ser compatível comum a gama  maior de projetos. Bibliotecas como o xpath e cssselectors são muito mais leves e memores que o lxml porem podem dependendo de sua utilização podem vir a dar mais problemas caso não se tenha bastante atenção as tags seletoras, isso pelo fato de que ambas iram trabalhar em cima da estrutura de arvore do arquivo indo da base ou de um selector em especifico até o selector que se deseja focar para extrair a informação, por isso é tao comum se deparar com erros de profundida onde se acaba por coleta a informação errada ou ate mesmo nem realizar a coleta.

Nessa faze é essencial que já se tenha em mente quais informações  tem de ser extraídas dos metadados para assim  evitar perca ou ruido dos dados.

3 – Estruturar essa gama de informações pode ser complicado por isso uma estrategia  tem de ser escolhida, e claro que as informações necessárias tem de ser previamente escolhidas para que tudo se encaixe no contexto e possa fazer o minimo de sentido viável para o projeto quando tudo estiver pronto.

4 – salvar as informações de modo adequado pode é sem duvida umas das principais partes desse projeto, pois de acordo co o método e tecnologias utilizadas pode-se definir muitas coisas do projeto tais como desde o método de distribuição as informações até mesmo o desempenho da aplicação como um todo já que levando em conta que todos os processos anteriores e posteriores ficaram ultra dependentes do método de armazenagem, nesse ponto deve-se pensar largamente na expansão do projeto, performance do banco e até mesmo verificar se o mesmo poeria aguentar o nivel de carga que estás preste a ser despejado sobre o mesmo.

5 – Após todos os procedimentos anteriores e necessaroia que se desenvolva uma metodo qu pessiblilite a recuperacao dos dados coletados de uma maneira que possam seer reutilizados devidadmente de acordo com o projeto.

 

 

nagem,

(ainda em desenvolvimento)

 

#estimativaswwwsize — March 23, 2016
#introduction —

#introduction

A internet contém um volume muito alto de informações em constante crescimento e modificação, com diferentes tópicos e organizada de forma descentralizada por milhares de servidores espalhados pelo mundo. Segundo informações de março de 2016 do  site word wide web size  o numero de paginas indexadas na internet é de 4.79 bilhões de paginas publicas indexadas. Em meados dos anos 90 a informação contida na internet era organizada manualmente em diretórios online como o Yahoo, até então o que se tinha era humanos como responsáveis por organizar e catalogar uma longa listas de websites, no fim dessa mesma década essa ideia foi melhorada e evoluída pelo Google utilizando o conceito de webcrawlers para automatizar todo o processo de indexação e  expansão da listas de websites, a partir desse ponto começa  a ser construída a internet que conhecemos hoje onde temos como foco os motores de busca.

Crawlers, também conhecidos como Spiders, Bots, Rapadores e outras tantas denominações, capturar e baixar de modo automatizado um grande numero de paginas, tomemos por exemplo fora da curva o Google que em 2016 tem uma estimativa de de paginas indexadas que  beira os 50 bilhões de paginas.

O funcionamento basico de um crawler consite em dar inicio ao rastreamento a partiir de uma url semente ou conjunto de sementes. O Crawler faz a requisição para cadas semente e captura o conteudo da pagina requisitada. Então dar-se inicio ao parseamento do html para a extraão do texto, links(endereços que apontam para outros documentos dentro do grafico) e demais informações contidos no arquivo para alimentare o indexador, os links sao adcionados a fronteira de urls (lista de endereçõesa serem visitados). O valor inicial da fronteira de urls corresponde ao as urls semnetes e com o decorrer do processo de raspagem esta lista sera incrementada e decrementada de acordo com o avanço do crawler, obviamente as novas urls iam incrementar a lista enquanto os endereções visitados iram drecrementa-la ou de acordo com a plitica de rechecagem seram enviadas para o fim da fila, ou terão uma baixa de prioridade dentroo da lista.

Como é o tamanho da World Wide Web (Internet) estimou? —

Como é o tamanho da World Wide Web (Internet) estimou?

O tamanho mínimo estimado da indexado World Wide Web é baseado nas estimativas do número de páginas indexadas pelo Google, Bing, Yahoo Search. A partir da soma destas estimativas, uma sobreposição estimada entre estes motores de busca é subtraído. A sobreposição é uma superestimação; portanto, o tamanho total estimado do indexada World Wide Web é uma subestimação.
Uma vez que a sobreposição é subtraído em sequência, a partir de um dos quatro motores de busca, vários ordenamentos (e estimativa do total) são possíveis. Nós apresentamos duas estimativas totais, uma partida com o Bing (BG) e um começando com Google (GB). A figura relatado no topo da página refere-se a estimativa GB. O tamanho do índice de um motor de busca é estimado na base de um método que combina a frequência de palavras obtidos em uma grande colecção de texto off-line (corpus), e as contagens de pesquisa devolvidos pelos motores. Cada dia 50 palavras são enviados para todos os quatro motores de busca. O número de páginas da web encontrados para estas palavras são gravadas; com as suas frequências relativas no corpus fundo, várias estimativas extrapoladas são feitos do tamanho do índice do motor, os quais são subsequentemente média. As 50 palavras foram selecionados uniformemente em toda a intervalos de frequência logarítmicas (ver Lei de Zipf ). O corpus fundo contém mais de 1 milhão de páginas de DMOZ , e pode ser considerado uma amostra representativa da World Wide Web. Quando você sabe, por exemplo, que a palavra “o” está presente em 67,61% de todos os documentos dentro do corpus, você pode extrapolar o tamanho total do índice do mecanismo pelo número do documento que relata para ‘o’. Se o Google diz que encontrou ‘a’ em 14.100.000.000 páginas, um tamanho estimado do índice total do Google seria 23.633.010.000. A sobreposição entre os índices de dois motores de busca é estimado pela contagem de sobreposição diárias de URLs retornado no topo -10 pelos motores que foram devolvidos em um número suficientemente grande de consultas de palavras aleatórias. As palavras foram tiradas aleatoriamente do fundo corpus DMOZ. Você pode baixar o meu papel aqui que contém informações detalhadas sobre o método (escrito em holandês). Este trabalho foi realizado como um projeto de tese de mestrado na Faculdade de Letras da Universidade de Tilburg ), no âmbito do Grupo de Pesquisa ILK . Update – 09 de fevereiro de 2016 – Springer Publicação tamanho estimativa do índice motor de busca variabilidade: um estudo longitudinal de 9 anos Para mais lendo por favor consulte este documento ., publicado em Scientometrics em 2016, descrevendo o nosso método em mais detalhe Notas Não há contagens foram realizadas para as seguintes datas: 07 de julho até o 07 de agosto de 2006. 03 de outubro até 16 de Outubro de 2007 ( Apenas para o índice de web). 19 de janeiro até o dia 30 de janeiro de 2008 (apenas para o holandês web). 20 de março até o 01 de abril de 2008. 05 de maio até 14 de Maio de 2010. 03 de abril até o dia 13 de abril de 2012. 11 de julho até o dia 29 de julho de 2012. 08 de outubro até 12 de outubro de 2012. 10 de maio até o dia 30 de maio de 2013. 22 de janeiro até o 27 de janeiro de 2014. 10 de julho até o dia 17 de setembro de 2014. 14 de novembro de 2015 até o dia 11 de januari de 2016

 

fonte: http://www.worldwidewebsize.com/

#wwwsize —
#artigoscrawlers —
apache nutch — March 22, 2016

apache nutch

Crawler open source onde se passa algumas sementes de sites que devem ser crawlwados.

Trabalhar com o nutch pode ser um problema pelo fato de ele exigir um pouco de robustez em sua configuração, testes e limpeza dos daods,por exemplo a necessidade de rodar em cluster.

Alem de nao ter uma saida clara o suficiente ja que toda a inf0ormação coletada será liberada forma de html estatico para o administrador do sistema.

O fato de ser escrito em java pode ser u belo empecilho no tocante do consumo exagerado de memoria em maquinas modestas, obviamente este é a necessidade do mesmo ser execultado em um cluster.

Vantagens :

  • opensource
  • estabilidade pois e mantido pelo apache

Desvantagens:

  • tanto testes quanto uso proficional pode sair caro pela necessidade de rodar em cluster, o mais recomendado e utilizar varias estancias ec2 amazon aws para dar suporte ao mesmo.
  • liberacao dos metadados em html
  • o programador terá que analisar o html posteriormente para retirar informações que juguem importantes.

fontes e links interessantes:

https://clgiles.ist.psu.edu/IST441/materials/crawling/nutch-crawling-and-searching.pdf

 

Commom Crawl —

Commom Crawl

O que é commom crawl?

Se trata de um software escrito em java mantido por uma organização que leva o mesmo nome, estes julgam que todos tem o direito a informação. Esse software constantimente faz  web raspagens  e salva seu resultado  e uma arquivo enorme onde o para ter acesos o desenvolvedor necessita fazer o download do mesmo e manuseá-lo manualmente, o arquivo mais atual data de setembro de 2015 e tem TB de dados e passa de  bilhões de urls. Os arquivos são atualizados de tempos em tempos e disponibilizados por meio da Amazon AWS.

Vantagens:

  • Se trata de um software livre
  • voce pode ter acesos ao fonte
  • e gratuito
  • é mantido por uma comunidade

Desvantagens:

  • não tem foco
  • se trata de uma aruivo muito grande para ser manuseado, caso seja uma qeuipe peguena de desenvolvedores ou que nao tenham equipamentos suficientes se torna inviavel trabalhar com os dados
  • em agosto de
  •  apos uma limpeza dos metadados para realizar estudos soobre os tamanhos padroes de fotos, certos dados foram retirados da imagem do commomcrawl, até entao a imagem tinha mais de 265tb de dados e apos a limpeza foi reduzido para mais 900gb o que ainda e muita informação levando em conta a realidade da região.

fonte:

commoncra.org/

Common Crawl’s Move to Nutch

Web image size prediction for efficient focused image crawling

http://www.theverge.com/2013/3/1/4043374/common-crawl-going-after-google-on-a-non-profit-budget