Nutch & Solr : les premiers pas vers la création d’un robot d’exploration Web

(Last Updated On: 14 septembre 2022)

Contrairement à d’autres didacticiels pour des configurations complexes et simples, la configuration de Nutch sur une machine Linux n’est pas simple, même lorsque vous suivez le didacticiel officiel. Faire travailler Solr et Nutch sur ma machine était un cauchemar mais je vais vous simplifier la tâche ici :

Remarque : Java doit être installé sur votre machine, car Nutch et Solr en dépendent.

Tout d’abord, installons Solr

Rendez-vous sur le site Web de Solr et téléchargez la version binaire de Solr :

Au moment de la rédaction de ce tutoriel, Solr est à la version 8.6.0. Cependant, ma version actuelle de Solr est 8.5.2. Ce tutoriel devrait fonctionner pour les deux versions.

Une fois que vous l’avez téléchargé, vous devez l’extraire dans n’importe quel dossier de votre choix. J’aime le faire dans mon dossier personnel.

Donc, vous devriez vous retrouver avec ceci :

/home/nom_d'utilisateur/solr-8.5.2

Pour démarrer Solr, accédez au répertoire de base de Solr et exécutez bin/solr start pour démarrer Solr.

cd ~/solr-8.5.2 
bin/solr start

Lancez votre navigateur pour accéder à l’application Web Solr à l’aide de l’URL : localhost:8983/solr

Ensuite, nous voulons installer Nutch.

La première étape de l’installation de Nutch suit la même approche qu’avec Solr. Rendez-vous chez Apache Nutch et récupérez le package Nutch.

Vous remarquerez qu’apache maintient deux versions de Nutch. La version 1.x et la version 2.x. La version 2.x semble être l’avenir de Nutch et offre une grande flexibilité en ce qui concerne la base de données à utiliser. Cependant, la version 1.x est la plus mature et la plus établie. J’utilise la version 1.x pour certaines de ces raisons. Et au passage, voici un extrait du site officiel :

Il est supposé que vous avez une connaissance pratique de la configuration de Nutch 1.XX, car actuellement la configuration dans 2.X est plus complexe. Il est important d’en tenir compte avant d’aller plus loin.

ALORS, récupérez simplement le package source Nutch v1.17. Extrayez le package dans votre répertoire personnel. Donc tu as :

/home/nom d'utilisateur/apache-nutch-1.17

Puisqu’il s’agit du paquet source, compilons-le :

/home/username/apache-nutch-1.17/ fourmi

Remarque : vous devez avoir installé ant. Si ce n’est pas le cas, exécutez- sudo apt-get install antle pour l’installer.

Le processus de compilation prendra plusieurs minutes car toutes les dépendances doivent être téléchargées et compilées en conséquence.
Lorsque tout est terminé, vous trouverez un runtime/localdossier créé pour vous dans le répertoire Nutch. Ce sera votre nouveau dossier d’accueil Nutch.

Pour la simplicité,

$NUTCH_HOMEfera maintenant référence à apache-nutch-1.17/runtime/local
et $SOLR_HOMEfera référence au dossier Solr que nous avons extrait précédemment.

Pour tester si Nutch a été installé correctement, accédez à $NUTCH_HOMEet exécutezbin/nutch

Vous devriez obtenir une liste des commandes prises en charge par Nutch.

Puisque Solr et Nutch sont installés, il est maintenant temps de les faire travailler ensemble.

Commençons par Solr. Tout d’abord, nous devons créer des ressources qui seront utilisées par notre noyau Solr.

D’accord, qu’est-ce qu’un noyau ? Un noyau Solr est une instance autonome d’un index Lucene. Cela signifie que pour utiliser Solr, vous devrez créer quelque chose appelé un noyau qui s’exécutera afin d’effectuer vos opérations. Ce noyau aura besoin de ses propres ressources comme les configurations, le schéma et le reste. Vous pouvez créer autant de cœurs que possible sur une seule machine. Cela est logique car différentes sources de données peuvent nécessiter des configurations différentes. Comme dans notre cas, Nutch aura une façon de structurer les données, qui pourrait être différente d’une autre source de données. Dans cette optique, des cœurs spécifiques devraient avoir des ressources qui leur sont propres.

Toutes les ressources pour les cœurs Solr doivent être placées dans le $SOLR_HOME/server/solr/configsestsrépertoire.

Nous allons donc créer un dossier dans ce répertoire pour placer nos ressources pour notre nouveau core :

mkdir -p $SOLR_HOME/server/solr/configsets/nutch/

Nous avons donc maintenant un dossier nutch vide en attente de fichiers de configuration. Solr est livré avec des fichiers de configuration par défaut qui fonctionnent pour presque tous les cœurs que vous allez créer. Ces fichiers se trouvent dans  le  $SOLR_HOME/server/solr/configsets/_defaultrépertoire. Nous allons donc copier ces fichiers dans notre nouveau dossier Nutch :

cp -r $SOLR_HOME/server/solr/configsets/_default/* $SOLR_HOME/server/solr/configsets/nutch/

C’est le moment de définir des configurations spécifiques à Nutch.
Tout d’abord, nous devons dire à Solr comment nos données doivent être structurées. Nous définissons également quels types seront nos champs et comment Solr gère nos valeurs de requête. Tout se fera dans un fichier schema.xml . Recherchez ce fichier dans  $NUTCH_HOME/conf ou téléchargez le plus récent ici .

Copiez le fichier schema.xml dans le dossier  $SOLR_HOME/server/solr/configsets/nutch/conf 

Alors Solr sait-il comment gérer nos données Nutch ?

Pas assez. Par défaut, Solr ignorera vos configurations de schéma pour certains schémas gérés s’il est trouvé. Voyez-le comme l’animal de compagnie préféré dont nous devons nous débarrasser pour que notre propre animal de compagnie soit considéré. Alors faisons ça :

rm $SOLR_HOME/server/solr/configsets/nutch/conf/managed-schema

Maintenant que nous l’avons à l’écart, nous pouvons démarrer notre serveur Solr.

Accédez à $SOLR_HOMEet exécutez :

bin/solr start

Si vous l’avez déjà en cours d’exécution, vous devrez l’arrêter et le redémarrer à nouveau. bin/solr stopest-ce que.

Nous avons maintenant des ressources mises en place pour un noyau qui n’existe pas. Résolvons cela en créant notre noyau de noix :

$SOLR_HOME/bin/solr create -c nutch -d $SOLR_HOME/server/solr/configsets/nutch/conf/

La commande ci-dessus crée un noyau appelé écrou et indique à Solr où trouver les configurations pour le noyau écrou.

Vous pouvez vérifier les choses dans votre navigateur avec localhost:8983/solr. Vous verrez votre noyau nouvellement créé dans la section principale.

La question suivante est, est-ce que Nutch connaît Solr ?

Eh bien, cela a été géré pour nous dans le fichier index-writer.xml qui se trouve dans le dossier  $NUTCH_HOME/conf.

Un index-writer est un composant utilisé pour envoyer des données explorées par Nutch à un serveur externe. Il est important de noter que Solr et Nutch fonctionnent indépendamment et que le serveur Solr n’est pas le seul serveur sur lequel vous pouvez envoyer des données Nutch. index-writer.xml gère cela pour nous.

Vous remarquerez qu’il existe d’autres indexeurs en dehors de celui de Solr. Ceux-ci sont en quelque sorte ajoutés par défaut et seront ignorés car nous n’avons pas de tels serveurs en cours d’exécution.

Ouvrez un compte Payoneer et obtenez une carte master-card internationale Valable en Tunisie et dans le monde entier. cliquez ici

Payoneer est le partenaire de choix pour le commerce numérique, partout dans le monde. Des paiements sans frontières à une croissance sans limites.

Alors quelle est la prochaine étape?, Explorez certains sites Web.

Mais avant cela, nous devons donner un nom à notre bot/crawler. Appelons-le Nutch Crawler . Nous pouvons le faire dans le fichier $NUTCH_HOME/conf/nutch-site.xml. Ouvrez ce fichier et ajoutez ces lignes :

<?xml version=”1.0"?> 
<?xml-stylesheet type=”text/xsl” href=”configuration.xsl”?>
<configuration> 
    <property> 
       <name>http.agent.name</name> 
       <value>Nutch Crawler</value> 
    </property>
    <property> 
       <name>http.agent.email</name>                          
       <value>datalake.ng sur gmail d</value>
    </property> 
</configuration>

Avec cela en place, tout site Web que notre bot va explorer saura avec quoi appeler notre bot. Vous devez définir le nom de votre robot, puis un e-mail de contact est une bonne chose à avoir dans le cas où votre robot encombre anormalement les sites Web.

Ensuite, nous devons faire une liste des URL que nous voulons que notre bot explore. Cette liste doit être placée dans $NUTCH_HOME/urls/seed.txtun fichier, avec chaque URL dans sa propre ligne.

Nous allons donc créer le dossier urls dans notre dossier $NUTCH_HOME :

mkdir -p $NUTCH_HOME/urls

Nous allons également créer ce “seed.txt” dans le dossier que nous venons de créer

touchez $NUTCH_HOME/urls/seed.txt

Une fois cela fait, vous pouvez insérer autant d’URL que vous souhaitez explorer dans le fichier. Pour commencer, parcourons le site officiel de Nutch est http://nutch.apache.org. Donc, notre fichier va contenir l’URL.

Un hic cependant, si nous devons explorer cette URL, nous ne nous retrouvons pas uniquement avec le contenu de cette URL. Nous obtenons également des données de tous les liens externes que le robot trouve sur le site Web de Nutch. Par exemple, s’il y a un https://someurl.com écrit sur n’importe quelle page du site officiel de Nutch , nous allons également récupérer le contenu de https://someurl.com. Nous n’explorons donc pas seulement notre liste de départ initiale, mais également leurs liens sortants.

Pour contrôler quels liens sont explorés, vous pouvez le faire dans le fichier $NUTCH_HOME/conf/regex-urlfilter.txt. Dans ce fichier, vous donnez une expression régulière du type d’URL qui doivent être explorée et toutes celles qui doivent être ignorées.
Remplacez donc :

# accepter tout le reste 
+.

avec ça:

+^https?://([a-z0–9-]+\.)*nutch\.apache\.org/

Nous disons ici que toute URL qui ne se termine pas par nutch.apache.orgdoit être totalement ignorée. De cette façon, https://someurl.com ne sera pas diverti même s’il apparaît sur le site Web Nutch.

Avant de continuer à ramper, comprenons comment fonctionne le processus d’exploration de Nutch. De cette façon, vous arrivez à donner un sens à chaque commande que vous tapez.

La première étape consiste à injecter vos URL dans le crawldb . Le crawldb est la base de données qui contient tous les liens connus. C’est le stockage de tous nos liens crawlés ou non.

Vous vous demandez peut-être, ne connaissons-nous pas tous nos liens à l’avance ? Par exemple, ne les avons-nous pas spécifiés dans seed.txt ?
Eh bien, pas tout à fait. La liste des URL dans seed.txt est notre liste initiale, pour commencer. Lorsque nous explorons ces URL seed.txt, si nous rencontrons d’autres liens sortants, nous les ajoutons toujours à notre liste de liens connus [lire cela encore]. Et si ces nouveaux liens ont d’autres liens sortants, nous les ajoutons quand même à notre liste, et le cycle continue. Ainsi, crawldb stocke tous nos liens connus qui s’additionnent à chaque cycle. Crawldb ne contient pas seulement les liens mais aussi les métadonnées de ces liens, comme le statut de récupération de chaque lien.

Avec cela, une liste de récupérationsera une liste (bien sûr) de liens qui doivent être explorés ensuite. Cette liste dépendra du contenu de notre crawldb. Donc, pour obtenir une liste de récupération précise, chaque fois que nous effectuons une tâche de récupération, nous devons mettre à jour le crawldb.

Mais si le crawldb ne contient que des liens et leurs métadonnées, où sont tous les autres contenus comme le HTML et les images stockés ? Nutch les stocke sous forme de segment dans le répertoire des segments en utilisant l’heure actuelle comme nom.

• Ainsi, crawldb contient des liens connus, explorés ou non.
• Un segment contient tout le contenu renvoyé, y compris leurs liens
• Une liste de récupération contient des liens à explorer ensuite.

Voyons maintenant cela en action.
Je suppose que vous êtes dans votre $NUTCH_HOMErépertoire pour exécuter ces commandes.

Exécutez la commande suivante pour injecter l’URL (dans notre cas, HTTP://nutch.apache.org) dans le crawldb :

bin/nutch inject crawl/crawldb urls

Ensuite, nous devons générer une liste de récupération à partir de crawldb et l’enregistrer dans le répertoire crawl/segment :

bin/nutch génère crawl/crawldb crawl/segments

La commande generate utilise l’horodatage actuel comme nom du segment.

Maintenant, si nous voulons interagir avec notre segment, ce que nous ferons, nous devons aller dans le dossier du segment et deviner lequel du dossier d’horodatage est notre segment, puis le copier. Pour nous faciliter la vie, enregistrons le chemin de ce segment actuellement créé dans une variable shell appelée s1 :

s1=`ls -d analyse/segments/2* | queue -1`

La commande répertorie tous les répertoires dans crawl/segments et nous sélectionnons le dernier et l’attribuons à s1car ce sera notre segment actuel.

Vous pouvez imprimer s1pour voir ce qu’il contient :echo $s1

Il est maintenant temps de faire le vrai crawling et cela pourrait prendre un certain temps pour terminer :

bin/nutch chercher $s1

Ensuite, analysez le contenu renvoyé pour en supprimer les éléments inutiles :

analyse bin/nutch $s1

N’oubliez pas que chaque tâche de récupération renvoie un ensemble de nouveaux liens. Nous devons donc mettre à jour notre crawldb avec les nouveaux liens :

bin/nutch mis à jourb crawl/crawldb $s1

À présent, notre crawldb a un nouvel ensemble de liens et a également mis à jour les anciens liens. Il sera sage de recommencer à ramper. Mais cette fois, puisque nous avons un tas de liens à gérer, nous pouvons spécifier le nombre de liens importants que nous voulons explorer, et non tous les liens. D’une manière ou d’une autre, Nutch peut dire quels liens sont les plus importants, car il dispose d’un système de notation pour nos liens.

Ainsi, les commandes suivantes répètent le processus d’exploration :

bin/nutch génère crawl/crawldb crawl/segments -topN 1000 
s2=`ls -d crawl/segments/2* | queue -1` 
echo $s2bin/nutch chercher $s2 
bin/nutch analyse $s2 
bin/nutch mis à jourb crawl/crawldb $s2

Les commandes ci-dessus sont presque les mêmes que notre premier crawl, à l’exception de la -topN 1000partie. Cela garantit que seuls les 1000 meilleurs liens de score sont explorés. La s2variable contient notre nouveau segment.

Un aspect important qui affecte également le nombre de liens que nous explorons est la profondeur de notre travail d’exploration. La profondeur garantit que la tâche d’analyse est effectuée un certain nombre de fois plutôt que l’analyse unique par défaut. Nous -depth 3allons donc nous assurer que nous exécutons le crawl trois fois en une seule course.

Maintenant, notre crawldb a plus de nouveaux liens, n’est-ce pas ? Nous pouvons effectuer une autre tâche d’exploration pour obtenir plus de données :

bin/nutch génère crawl/crawldb crawl/segments -topN 1000 
s3=`ls -d crawl/segments/2* | queue -1` 
echo $s3bin/nutch récupérer $s3 
bin/nutch analyser $s3 
bin/nutch mis à jourb crawl/crawldb $s3

Cette fois-ci avec un nouveau segment dont les informations de répertoire sont stockées dans s3une variable.

Et comme vous pouvez le deviner, cela peut continuer encore et encore, comme une récursivité. Vous décidez quand vous avez suffisamment de données. Si nous voulons continuer, nous allons créer un nouveau segment et enregistrer les informations du répertoire dans, par exemple, s4. Mais nous nous arrêterons ici.

Inverser les liens

Maintenant que nous avons le répertoire crawl/segments rempli avec les données que nous avons explorées précédemment, nous devons inverser les liens dans ces segments. La raison en est que puisque ces segments contiendront autant de liens, nous devrions trouver un moyen de spécifier quels liens sont importants. Ceux-ci devraient être nos liens entrants et non ceux sortants, n’est-ce pas ?

La commande ci-dessous effectue l’inversion et pousse ces liens vers le linkdb. Ainsi, le linkdb contient nos liens inversés :

bin/nutch invertlinks crawl/linkdb -dir crawl/segments

Maintenant tout est dit et fait. La dernière étape consiste à indexer nos données dans le serveur Solr afin d’effectuer nos requêtes complexes :

bin/nutch index crawl/crawldb/ -linkdb crawl/linkdb/ $s3 -filter -normalize

Cela passe le répertoire crawldb, le répertoire linkdb, le répertoire de segment, puis avec une option pour filtrer les liens qui ont été rejetés par les filtres d’URL et également normaliser les URL avant l’indexation. Il existe également une autre option pour supprimer les URL introuvables et les doublons. Pour inclure cette option, la commande ressemblera à ceci :

bin/nutch index crawl/crawldb/ -linkdb crawl/linkdb/ $s3 -filter -normalize -deleteGone

Une fois que nous avons exécuté cette commande, notre serveur Solr en cours d’exécution préparera nos données pour l’interrogation.

Allez maintenant dans votre navigateur et visitez l’URL : localhost:8983/solr pour accéder à l’application Web Solr et sélectionnez le noyau de noix dans le sélecteur de noyau :

• Après avoir sélectionné le noyau de noix , cliquez sur requête.
• Entrez ensuite votre terme de recherche dans le champ q et cliquez sur Exécuter la requête.

Oups !
Vous serez accueilli par une erreur. Le fait est que nous essayons de faire une requête mais Solr ne sait pas d’où chercher. Nous devons spécifier quel champ nous voulons que Solr examine. Cela se fait en définissant le champ `fl`.

Nous pouvons également définir le dfchamp par défaut, donc dans le cas où aucun champ n’est spécifié, nous revenons au champ par défaut.

Mais que se passe-t-il si nous voulons faire une recherche vraiment générale (c’est-à-dire que nous voulons que Solr examine tous les champs). La recherche générale est censée fonctionner hors de la boîte. Cependant, quelque chose empêche ce comportement.

Il existe un fichier solrConfig.xml que nous pouvons utiliser pour définir les valeurs par défaut de nos requêtes, comme le champ par défaut ou le format dans lequel nous voulons notre réponse. Ce fichier contient également ces lignes :

<initParams path="/update/**,/query,/select,/spell"> 
    <lst name="defaults"> 
      <str name="df">_text_</str> 
    </lst> 
  </initParams>

Remplacez _text-par textet cela devrait résoudre le problème de recherche général :

<initParams path="/update/**,/query,/select,/spell"> 
    <lst name="defaults"> 
      <str name="df">texte</str> 
    </lst> 
  </initParams>

---

Merci de votez pour cet article :