Si vous suivez les aventures de Babbar depuis le début, vous savez déjà que Babbar c’est la réunion des équipes d’Exensa et des ix-labs, des personnes qui se connaissent depuis parfois près de 20 ans, mais qui ont choisi de travailler ensemble depuis seulement quelques mois.
Aujourd’hui, nous allons commencer à rentrer dans les détails techniques de ce que nous faisons.
Tout d’abord, il faut savoir qu’une partie de la techno dite « babbar » a d’abord été développée dans Exensa. En effet au sein d’Exensa cela fait déjà plus de deux ans que du travail est fait sur la techno d’analyse qui fait tourner le « similar sites » de Babbar. Pour ceux qui sont venus aux conférences iSwag en 2015 et 2016 (organisées par les ix-labs en marge de la conférence queduweb), vous avez même pu voir des exposés sur les prémisses de tout cela avec les toutes premières briques algorithmiques.
Bref, tout ça pour dire que pour tester la techno, Exensa a commencé à faire du crawl du web avec une techno open source. Le crawl était très efficace, mais très bête. Mais cela restait très impressionnant, et il y a peu, quand nous nous sommes tous ensemble posés pour décider de fournir un service d’information sur le maillage web qui soit un peu plus sérieux que les outils existants, tout cela a été remis sur le tapis.
A partir de ce moment-là nous avons commencé à travailler sur une techno de crawling plus intelligente, et sur l’aspect stockage/indexation du crawl. Nous avons retroussé nos manches pour voir comment on pourrait stocker tout ce qu’on crawlait de manière efficace.
La première piste envisagée était d’utiliser un système de stockage distribué. Nous en avons benchmarké plusieurs, et notre première idée à été d’utiliser Apache Ignite pour prouver la viabilité de notre approche. On ne va pas vous mentir, ça a été un beau fiasco : nous n’avons jamais pu atteindre des performances acceptables, et par ailleurs cette solution rendait très difficile de maîtriser la localité des données pour faire des calculs dessus. Et un outil qui fournit des métriques mais qui ne sait pas les calculer, ce n’est pas très utile…
Nous avons donc rapidement décidé de gérer nous-même le stockage. Après quelques tests et réflexions autour des solution de stockage locales, nous avons choisi RocksDB, qui avait quelques fonctionnalités intéressantes même si tout n’était pas parfait. Nous avons d’ailleurs sérieusement hacké la techno pour arriver à des bonnes performances sur les opérateurs de fusion en java, mais au final nous avons pu voir que c’était le bon choix, les performances et la qualité des résultats étant au rendez-vous.
Ensuite nous nous sommes attaqués au problème de la distribution des messages. Un problème qui s’est révélé finalement beaucoup plus simple à résoudre. Nous avons rapidement compris que nous avions le choix entre deux technos déjà matures : Kafka et Pulsar.
Nous avons choisi Pulsar, qui a l’avantage d’être particulièrement souple, même si la robustesse n’est pas toujours au rendez-vous.
A partir de là, le schéma de fonctionnement de notre solution n’est pas très compliqué :
- le cœur du crawler envoie des requêtes de crawl via Pulsar (ça en fait c’est tout un sujet, car nous avons vraiment peaufiné le fait de crawler en priorité les pages à haute valeur, ce qui sera le sujet d’un autre billet).
- Ces requêtes arrive sur un crawler, qui gère de son côté les files d’attente par site web et par adresse IP (pour ne pas saturer les sites crawlés).
- Quand le crawler récupère une page web (environ 60 à 80 ko en moyenne d’après nos expériences), il va l’analyser syntaxiquement (parsing), nettoyer le HTML et renvoyer le tout, via Pulsar, à une des machines du cluster principal (le cœur du crawler).
- Le cluster principal reçoit donc, pour résumer, la liste des liens contenus dans la page, et le contenu texte brut de la page. A ce moment l’information de la page est déjà condensée (on reparlera de la compression un peu plus loin), mais on est encore autour de 10 à 20 ko par page. Cela paraît peu, mais à ce niveau de volumétrie c’est encore trop.
L’information sémantique est alors extraite via notre méthode de calcul d’embeddings vectoriels. La techno est propriétaire et est extrêmement efficace et optimisée. Elle fait grosso modo la même chose que Doc2Vec et consorts, mais en mieux bien entendu 😉
Au final, on ne garde de la page qu’un vecteur numérique qui synthétise son orientation sémantique.
C’est une fois tous ces premiers traitements réalisés que les choses sérieuses commencent : la partie « réactive » du cluster principal va traiter l’information de la page, d’une part en la stockant, d’autre part en envoyant via Pulsar les liens sortants de la page (et oui, comme on veut au final vous donner les backlinks, il faut bien que chaque page ait reçu les liens qui pointent vers elle). On en profite pour stocker quelques infos supplémentaires, mais en gros, le côté « réactif » a fini son boulot.
A côté de la partie réactive, il y a une partie « tâches de fond », qui va continuellement passer sur l’intégralité des données stockées pour faire 2 choses : calculer les métriques et les rediffuser (car ce sont des métriques de graphes, donc à chaque mise à jour il faut rediffuser), et agréger des informations au niveau de l’url (par exemple le nombre d’IPs référentes uniques), du site et du domaine. C’est aussi à ce moment que Babbar collecte les informations « IP vers site web ».
Voilà, à ce stade vous savez tout du fonctionnement de la partie « compute » de Babbar. Pour découvrir la suite il faut attendre le prochain épisode, dans quelques jours 😉
En attendant, vous pouvez vous inscrire à la liste d’attente de la beta privée via ce lien : https://t.co/h9nLVXk3YV. A très bientôt !