L’une des particularités du formalisme DAFF est justement de ne pas dupliquer dans les archives des ressources Web qui n’auraient pas évolué (Section 2.2). Seules les pages ayant subi une transformation sont ainsi re-collectées. Néanmoins, d’un crawl à l’autre, il est pos- sible qu’une partie du contenu de la page soit similaire à la version précédemment capturée et ce malgré les divers changements qu’elle aurait pu subir. On pense notamment aux pages d’accueil des sites d’actualités ou des forums qui présentent des informations publiées sous la forme de listes où chaque nouvel élément est inséré en en-tête. Mécaniquement certains éléments peuvent se retrouver, à plusieurs reprises, enregistrés dans les archives comme le présente la Figure 3.5.
p1
ti(p1)
e1 e2 e3
Figure 3.5: Contenu d’une page (en rouge) collecté plusieurs fois
Cela peut poser de lourds biais d’analyse si l’on cherche par exemple à connaitre la distribution d’un mot-clé extrait des pages archivées. Ce dernier pourra, du fait de la structure même du corpus, être artificielle- ment sur-représenté dans les résultats.
3.3
Construire un moteur d’exploration d’archives Web
Ces différents biais maintenant présentés, nous pouvons nous tourner vers la description de l’architecture de notre moteur d’exploration d’archives Web. Nos corpus étant en DAFF, il n’a pas forcément été possible de réutiliser des éléments open-source issus d’autres moteurs (quasiment tous conçus pour accueillir du WARC). De fait cette section est intéressante pour qui souhaite mettre en place ou comprendre dans le détail la mécanique d’une tel système. Notre architecture suit néanmoins la structure classique d’une chaîne d’extraction, d’analyse et de visualisation de données à grande échelle (Marz et Warren, 2015).
La Figure 3.6 donne à voir une illustration de son fonctionnement. Il s’agira donc ici d’une description plutôt orientée ingénierie dont la majeure partie a fait l’objet d’une publication démonstration7
. 7. Lobbé, Q. (2018), Revealing Historical Events out of Web Archives, TPDL 2018
.DAFF
HDFS
Spark configurations
catégories e-Diasporas index
schéma Solr handler Peastee Node.js utilisateur visualisations
Figure 3.6: Architecture de notre moteur d’exploration d’archives Web
Extraction et enrichissement
Nous suivons ici l’hypothèse selon laquelle notre moteur doit rendre accessible les archives Web d’une seule e-Diaspora à la fois. Nous prendrons comme exemple les archives du corpus marocain.
La première étape consiste à extraire les informations contenues dans les fichiers DAFF. Rappelons que chaque corpus est divisé en deux fichiers DAFF : les données d’une part (data) et les méta-données (metadata) d’autre part. Pour ce faire, nous commençons par adapter une librairie Java (fournie par les équipes de l’INA, dlweb-commons) qui cherche à transférer les archives des fichiers DAFF vers le système de stockage d’Hadoop8
, le Hadoop Distributed File System (HDFS). Le 8. https://hadoop.apache.org/,https: //fr.wikipedia.org/wiki/Hadoop
HDFS est un système de fichiers qui permet de manipuler de larges vo- lumes de données, de manière distribuée (c.-à-d., réparti entre plusieurs machines) et passant relativement bien à l’échelle (pouvant supporter une forte montée en charge). Le format DAFF a ceci de limitant, qu’il reste pensé pour le stockage et non pour la manipulation des données. Filtrer un fichier DAFF par URL ou date de téléchargement n’est, par exemple, pas trivial.
Une fois chargées dans le HDFS, les données et méta-données DAFF sont envoyées dans un système de traitement nommé Spark9
. Spark 9. https://spark.apache.org/
permet de travailler par batchs (c.-à-d., par petits lots de données) dans un environnement distribué : les données et méta-données sont segmen- tées en sous-ensembles plus facilement manipulables, puis répartis sur plusieurs machines où elles subissent toutes les mêmes traitements en parallèle (filtres, jointure, groupement, etc.). Spark est un outil flexible dans lequel nous pouvons définir une suite d’instructions (ou pipeline) ayant pour finalité la fusion des données et méta-données DAFF en une
seule et même source de données d’archives. La Figure 3.7 décrit la ma- nière dont s’enchainent ces diverses transformations. Les méta-données sont traitées en premier et peuvent suivant la configuration du système être filtrées par date de téléchargement ou nom de domaine (par site Web). Puis, en nous rappelant que les méta-données possèdent chacune un pointeur vers le bloc de données DAFF dont elles sont l’extension (champ content en DAFF, Section 2.2), nous remplaçons l’identifiant des méta-données par l’identifiant du bloc de données correspondant. Cette manipulation nous permet ensuite de grouper les méta-données par identifiants communs, c’est-à-dire, toutes les méta-données d’une seule et même chaine de persistance (Section 3.2).
C’est à cette étape que nous identifions notamment les dates de dernière modification. De là, nous opérons une jointure entre les méta- données et données DAFF afin de rassembler enfin les informations issues du crawler et le contenu même des pages archivées. Pour ter- miner, nous préparons ces nouvelles données à être envoyées dans le moteur de recherche, sans oublier de les enrichir avec des informations tirées de l’Atlas e-Diasporas (type de sites, langue, etc.).
méta
filtre par site filtre par date
data id devient méta id groupe par méta id méta-données
données
jointure par id créer document Solr date de dernière modification
méta id = data id
Figure 3.7: Pipeline de transformation des données et méta-données DAFF
Deux configurations différentes ont été testées pour Spark, l’une distri- buée entre plusieurs machines d’un même cluster (c.-à-d., un groupe de machines), l’autre distribuée sur l’ensemble des cœurs d’une seule machine puissante. Si la première configuration s’est révélée la plus rapide (traitement de l’ensemble du corpus marocain en 3 jours), il a fallut néanmoins s’en détourner. En effet, Spark étant particulièrement dur à piloter sur un réseau souvent instable, il était fréquent de voir le traitement des données s’arrêter après avoir perdu connexion avec une ou plusieurs machines. De fait, nous avons préféré nous contenter de la seconde configuration, plus lente (une dizaine de jours) mais garantissant la totalité du traitement10
. 10. Notre système est téléchar-
geable ici-mêmehttps://github. com/lobbeque/archive-miner