Architecture des web crawlers
(velog.io)-
Jusqu’à présent, la plupart des web crawlers largement présentés sur Internet sont en réalité des « scrapers », et il est difficile de les appeler de véritables crawlers
-
L’auteur présente brièvement des articles qui définissent ce qu’est un web crawler
-
Un crawler est une application qui parcourt le monde d’Internet en BFS et DFS.
-
Les règles des robots sont un sujet extrêmement important, au point de pouvoir déterminer l’image d’une entreprise, mais beaucoup de startups l’ignorent encore.
4 commentaires
L’an dernier déjà, en lisant les articles de cette personne, je me demandais pourquoi elle voyait tout de façon aussi biaisée, mais je ne sais pas si ça s’est au moins un peu arrangé.
En étant réaliste, à moins de faire partie d’un grand groupe qui exploite littéralement un moteur de recherche...
Même si on utilise un crawler, dans le domaine du text mining, si ce n’est pas de l’anglais, le coût de prétraitement est élevé ; avec un crawler de ce genre, il est donc difficile d’extraire des données de qualité. Et dans le domaine du traitement d’image, alors qu’il existe déjà partout des jeux de données de qualité, il n’y a pas vraiment de raison d’exploiter un crawler exprès. Ce n’est pas pour rien qu’avec toute cette belle théorie, ce sont les scrapers qui pullulent. C’est simplement parce que la valeur obtenue au prix d’un effort énorme reste faible.
Le crawler « complet » dont parle cette personne a peut-être une bonne base théorique, mais au final il ne fait guère plus qu’extraire des données avec une probabilité un peu plus élevée ; c’est donc une solution bancale, difficile à utiliser aujourd’hui dans des domaines comme l’IA. Les coûts de maintenance ne sont pas faibles, les données extraites ne sont pas complètes, c’est difficile à gérer, et il y a en plus beaucoup de problèmes juridiques. Plutôt que de prendre tout cela en compte, pour un particulier ou une entreprise, il est plus économique de faire tourner quelques scrapers sur de gros sites. Un seul scraper bien analysé et bien conçu pour un grand site est des centaines, voire des milliers de fois plus économique et plus pratique qu’un système qui va inutilement visiter 100 sites. Exploiter « correctement » un crawler de façon large est déjà difficile même avec des titulaires de master et de doctorat mobilisés dessus. Et si en plus il faut surveiller le crawler et modifier la logique au fil de l’eau, ce serait encore plus terrible. Les logs seraient eux aussi énormes, au point qu’il faudrait probablement les traiter de manière distribuée.
Bien sûr, je suis évidemment d’accord sur le fait que les crawlers sont un socle essentiel et important, mais je me demande vraiment s’il fallait défendre cette thèse toute l’année en passant son temps à établir une hiérarchie avec les scrapers.
Même maintenant, je ne comprends toujours pas pourquoi cette personne ignore Scrapy. Au minimum, que ce soit en options ou en extensions, il y en a bien davantage que pour gocolly.
Bon, chacun verra cela selon son point de vue, mais comme je travaille moi aussi dans une équipe de collecte de big data, je laisse ici mon humble avis.
Je suis d'accord.
Comme l’article semble encore inachevé, il y a plusieurs endroits où l’on a l’impression qu’il manque des éléments qui devraient s’y trouver.
Au milieu, la mention de [Lambda Crawl] dans la planification des revisites renvoie-t-elle à l’article [Effective Page Refresh Policies For Web Crawlers] (2003) ? Quand on cherche avec ce mot-clé, on tombe surtout sur toutes sortes de discussions sur le crawl avec Lambda, le service serverless d’AWS, et compagnie. Pourtant, il me semble que cet article n’apparaît pas dans la bibliographie ci-dessous…
http://ilpubs.stanford.edu:8090/604/1/2003-44.pdf
On le voit apparaître dans cet article, Tractable near-optimal policies for crawling