Indexation et classification temps réel de petites annonces en ligne

Transcription

1 RAPPORT DE STAGE DE 3 ème ANNÉE Indexation et classification temps réel de petites annonces en ligne Effectué du 18 Avril 2011 au 16 Septembre 2011 Sous la supervision de M. Benjamin Devèze 34 rue de Cléry Paris contact@yakaz.com Olivier FAVRE Option IAD

2 TABLE DES MATIÈRES Table des matières TABLE DES MATIÈRES 1 Présentation de l entreprise Secteur d activité Yakaz.com Cadre Mission réalisée Besoin originel Contraintes à satisfaire Technologies utilisées et préconisées Collaborateurs et contacts Description des technologies impliquées Lucene Présentation Terminologie Requêtage Autre types de champs Mapping et consistance ElasticSearch Présentation Souplesse de configuration Terminologie Aspect distribué Développement Le plus gros du travail Configuration Analyseurs Mapping Développement de modules Expressivité du champ de recherche En route vers une contribution Analyse avancée des champs textuels En route vers une seconde contribution Requête sur une phylogénie Intégration Traitement des workunits d entrée Front Module de présence Validation Comparaison des résultats Déploiement Stage de 3 ème année Olivier FAVRE 2

3 TABLE DES MATIÈRES TABLE DES MATIÈRES 5 Autre sujet traité Classification de requêtes But recherché Données Description Quelques statistiques Approches testées Régression logistique Description de la méthode Prise de décision Pré-traitements Résultats Classifieur bayésien naïf Description de la méthode Prise de décision Pré-traitements Post-traitements Résultats Méthode retenue et déploiement Base de données Extension PHP Gestion des langues Apprentissage incrémental L idée générale Le procédé Optimisations Parallélisation Export Perspectives Moteur de recherche Classification de requêtes Autres tâches futures Détection des topics Jeux mobiles Apports personnels 39 8 Conclusion 40 Stage de 3 ème année Olivier FAVRE 3

4 1 Présentation de l entreprise Présentation de l entreprise 1.1 Secteur d activité Yakaz est une SARL fondée en Septembre 2005 par Frédéric Mahé et Mathurin Ducastelle, au capital de e dans le domaine de la programmation informatique. Le chiffre d affaire 2010 était de e, en augmentation de 88,74 % par rapport à l année précédente. Avec une rentabilité d exploitation de 47,85 %, l entreprise a augmenté son nombre d employés pour dépasser la vingtaine et embauche toujours actuellement. 1.2 Yakaz.com Yakaz est la société éditrice du site web du même nom : Disponible dans 49 langues et 193 pays, il référence les petites annonces localisées et catégorisées. Ainsi vous pourrez chercher un logement, une voiture, une moto ou même un emploi. Quelque soit le domaine recherché, vous pouvez filtrer par type d annonce : vous cherchez à vendre, à louer, vous donnez, proposez vos services, un emploi ou vous avez une bonne critique, un événement à promouvoir, ou vous recherchez une actualité ou peut être avez-vous une question à poser ou vous lancez une discussion. En plus d avoir un moteur de recherche textuel, vous pouvez filtrer les annonces avec des critères avancés, tels que la superficie minimale d un logement, le nombre de pièces, avec photos, commentaires, des enchères, ou bien même un emploi en intérim ou bien une grosse cylindrée rouge avec un faible kilométrage. Toutes ces informations ont été extraites des annonces et sont disponibles à la recherche. Vous pouvez naturellement poster votre annonce sur Yakaz, mais le site est bien plus que cela car il recense toutes les annonces que vous pourrez trouver sur Internet. L entreprise possède des robots d indexation chargés de parcourir la toile à la recherche de nouvelles sources. Ainsi, à quoi bon aller chercher ailleurs alors que vous avez une énorme base d annonces à portée de clic et que vous pouvez poster la votre gratuitement directement sur notre site? Philosophie Pertinence C est le maître mot du site web. Elle est cruciale, car il ne rimerait à rien de proposer un service d annonces localisées qui vous sert des résultats à 1000 km de l endroit recherché. Il y a un travail perpétuel pour améliorer la précision des analyses automatiques par lesquelles chaque annonce passe. Il peut être difficile, par exemple, de bien savoir à quoi correspondent certains chiffres donnés lorsque l annonce est rédigée dans un style très laconique. Innovation Nous désirons offrir des fonctionnalités diverses et nombreuses car nous croyons que cela rendra service au client et par voie de conséquence, l attirera vers le produit. Stage de 3 ème année Olivier FAVRE 4

5 Cadre Présentation de l entreprise Par exemple, nous avons créé un service de chat intégré au site, afin de mieux connecter les annonceurs et les intéressés. Si cela vous rappelle Google, vous n avez pas tort. Par plus d un aspect, le management de l entreprise rappelle celui du géant de l Internet Technologies Afin de pouvoir offrir une qualité de service optimale, nous devons servir chaque page aussi rapidement que possible. En passant moins de temps à traiter chaque demande, nous pouvons ainsi répondre à un nombre toujours grandissant de requêtes. Obtenir de bonnes performances nécessite d utiliser les outils les plus adaptés. Par exemple, nous n utilisons pas le serveur web le plus connu Apache HTTPD pour des raisons de performances, mais un serveur web écrit dans un langage fonctionnel, nommé Yaws, qui permet un traitement simultané des requêtes optimales. Une part importante de l optimisation d un service à l échelle mondiale repose également dans l utilisation de caches de grande capacité et de vitesse de réponse très faible. L architecture matérielle a été conçue de manière tout à fait adaptée aux besoins que chaque composant : mémoire vive importante, ou grosse capacité de calcul, ou encore accès réseau rapide. 1.3 Cadre Localisée dans le 2 ème arrondissement, l endroit est aisément accessible et la vie dans le quartier y est agréable car nous jouissons de la proximité de la rue Montorgueil et du boulevard Poissonière, riches en restauration et en lieux culturels L équipe L équipe technique est composée de 9 personnes à temps plein, 1 ou 2 freelance ponctuellement. Elle est épaulée par un administrateur système et réseau. Nous devons beaucoup également à notre équipe de recherche et développement composée de 2 personnes. Afin de faire vivre le site web, nous comptons sur une chargée de communication et de son assistant, ainsi que 5 animateurs de communautés étrangers, chargés de surveiller le bon fonctionnement et la pertinence du site en rapport avec leur langue maternelle et pays d origine, mais également de trouver de nouvelles sources à répertorier. L entreprise ne saurait être complète sans les 2 patrons et la secrétaire de direction Ambiance Elle y est très décontractée. Le carcan d une rigueur vestimentaire n est imposé à personne, et personne ne se l impose. L entreprise a même offert des tongs Yakaz pour l été! Entre passionnés de technologies, les échanges de connaissance et les débats vont bon train. Enfin je partage des moments entre geeks sans gêner personne. Que ça soit entre geeks ou pas, la bonne humeur est toujours partagée et il est très agréable de travailler dans de telles conditions, surtout sur des sujets passionnants! Stage de 3 ème année Olivier FAVRE 5

6 Mission réalisée 2 Mission réalisée 2.1 Besoin originel Yakaz utilise actuellement les technologies Exalead pour plusieurs étapes de la chaîne de traitement : Le crawling, ou le parcours d Internet. Cette étape permet de détecter et de lister les pages à traiter, aussi bien à l intérieur d un site web qu en tentant de trouver de nouvelles sources. L analyse des pages crawlées afin d en extraire automatiquement le contenu utile, ainsi que d en effectuer l extraction fine à l intérieur de chaque annonce, pour déterminer par exemple le kilométrage ou la couleur d une voiture. L indexation et la recherche pour finalement pouvoir servir les résultats sur le site web. Les annonces ne sont pas les seuls éléments concernés, les mots clés ainsi que les lieux sont également indexés. Nous voulons nous séparer du joug d une solution propriétaire pour investir dans une solution OpenSource, que nous pourrons faire évoluer plus facilement dans le sens que nous souhaitons. De plus le support d une communauté riche de centaines d enthousiastes assure également que nous ne serons pas laissés pour compte en cas de problème. Investir est doublement le mot exact, car déployer une solution alternative, quelle qu elle soit, prendra du temps, mais aussi parce que certains des développements supplémentaires que ce changement technique impliquera pourront sans difficulté faire l objet d une contribution à la communauté faisant vivre ces solutions. Les développements réalisés dans les parties crawling et analyse ayant été réalisées sur la base du code source propriétaire qu Exalead a accepté de nous ouvrir, pour des raisons historiques ne seront pas trop difficiles à porter, bien qu ils aient été réalisés en ExaScript, langage propriétaire d Exalead, offrant une surcouche au langage Java et se basant sur les mêmes APIs de base. Le chantier commence donc par la partie indexation, et j ai été recruté pour m en occuper à temps plein, épaulé par quelques autres collaborateurs. 2.2 Contraintes à satisfaire Bien entendu, nous ne devons pas perdre en fonctionnalité par rapport à l offre actuelle. Mais d autres contraintes additionnelles entrent en compte : Être plus évolutif que la solution actuelle. Conserver une taille d index dans le même ordre de grandeur que celui d Exalead. Les machines sur lesquelles font tourner le moteur de recherche auront énormément de mémoire vive, mais une quantité limitée de mémoire persistante. Respecter des timings assez agressifs sur les temps de recherche. Cette contrainte est également fortement liée à la suivante. Être intégrable au système de cache très efficace déjà en place. C est un des éléments principaux qui permet de passer à l échelle mondiale en conservant une grande disponibilité de service. Stage de 3 ème année Olivier FAVRE 6

7 Technologies utilisées et préconisées Mission réalisée 2.3 Technologies utilisées et préconisées À mon arrivée, la question de la technologie de substitution à utiliser avait déjà été abordée. Parmi les moteurs de recherche libre, Lucene semblait l un des mieux placés. Mais surtout, il dispose d une surcouche relativement récente qui démultiplie ses possibilités : ElasticSearch. Si le choix n est pas verrouillé, il semble à priori l un des meilleurs possibles. En effet, il existe d autre moteurs de recherche ainsi que d autres surcouches à Lucene, mais celle ci à l air de correspondre à nos attentes. 2.4 Collaborateurs et contacts Comme je le disais, si je suis la seule personne à travailler à temps plein sur ce chantier, je ne suis pas sans soutien. Benjamin Devèze, le plus ancien employé de Yakaz de l équipe technique, possède une excellente connaissance de toute notre infrastructure, car il a pu suivre, s il n a pas lui-même réalisé la construction de tout l existant. Toujours très disponible, il m a aidé à découvrir les particularités de notre chaîne de traitement. Grâce à ses remarques toujours très pertinentes, nous avons souvent pu avancer dans la bonne direction sans tâtonner et éviter un grand nombre de problèmes. Deux freelances Stéphane Jais et Adbelmajid Boubrik m ont également épaulé durant les trois premiers mois. Ils sont des anciens d Exalead et ont notamment travaillé sur le cœur du moteur de recherche. Ils ont développé un adaptateur permettant de faire le pont entre les formats d entrée d Exalead et d ElasticSearch. Puis l un a porté les changements dans le site web pour le nouveau moteur, tandis que l autre réfléchissait plus aux problèmes d architecture et de portage des fonctionnalités spécifiques dont nous avions besoin. Les communautés construites autour des solutions OpenSource sont également une source de richesse de contenu, pour Lucene, et réactive via leur salon de discussion sur IRC, pour ElasticSearch. J ai d ailleurs eu le privilège de pouvoir rencontrer Shay Banon, auteur d ElasticSearch, car Yakaz nous a proposé, à Benjamin et moi, de suivre la conférence What s Next sur les nouvelles technologies construites autour de Java, qui se tenait à 5 minutes de nos locaux au Grand Rex. En plus de répondre à certaines de nos interrogations sur la réalisation de certaines fonctionnalités, afin d apprécier leur performances potentielles, nous avons pu nouer un meilleur contact qui sera toujours apprécié pour la suite de notre collaboration, en tant qu utilisateur de son logiciel. Stage de 3 ème année Olivier FAVRE 7

8 Description des technologies impliquées 3 Description des technologies impliquées 3.1 Lucene Présentation Lucene est un moteur de recherche textuel OpenSource, écrit en Java. Très connu, il est utilisé dans un bon nombre de projets. Étant une bibliothèque fournissant des fonctionnalités de base, ce moteur est facilement intégrable dans une application, elle ne nécessite pas de serveur ni obligatoirement de fichiers sur le disque Terminologie Les objets que l on index s appellent des documents. Ils sont constitués d un ou plusieurs champs, totalement arbitraires, éventuellement multi-valués. L index de Lucene répertorie les documents qui possèdent un terme donné, et ce pour chaque terme utilisé. Un terme est rattaché à un champ, ainsi il n y a pas de faux positifs en provenance d un autre champ. Un même terme possède des meta-données pour chaque apparition : position du mot, position exacte en caractères, type (mot, chiffre, idéogramme, etc.), ainsi que des données arbitraires nommées payload. Ces meta-données sont facultatives et les stocker font naturellement grossir la taille de l index. Cependant, noter la position du mot permet de favoriser les documents qui possèdent des termes dans le même ordre ou presque que ceux figurant dans la recherche. Noter la position en caractère permet aussi de pouvoir réaliser une mise en valeur des termes ayant matché avec la requête, comme les extraits avec des passages en gras dans les résultats de Google Requêtage Les requêtes Lucene s expriment avec des objets Java. Elles peuvent s imbriquer et devenir assez complexes, mais cela fait également leur puissance. Par exemple vous pouvez rechercher une combinaison précise de plusieurs termes en combinant des requêtes booléennes de la forme (must, should, must not), ce qui correspond généralement aux préfixes +, (vide) et - des moteurs de recherche. Il existe également des requêtes avec des jokers (wildcards) comme? remplaçant un caractère unique et * en remplaçant zéro, un ou plusieurs ; des requêtes approximatives autorisant les termes matchés à différer plus ou moins des termes recherchés ; des requêtes de proximité, comme décrit précédemment ; des requêtes d intervalle de texte, de date comme de nombres ; et toutes les sous-requêtes peuvent être boostée en multipliant leur sous-score par une constante. Naturellement, Lucene possède un type de requête particulier qui permet d analyser un texte écrit dans un champ de recherche, comme sur Google, et d en générer l imbrication de requêtes Lucene correspondant Autre types de champs Lucene étant un moteur de recherche textuel uniquement, les dates et les champs numériques sont convertis en texte correspondant, en faisant en sorte que le tri alphabétique corresponde au tri numérique. Afin d accélérer l exécution d une requête Stage de 3 ème année Olivier FAVRE 8

9 Lucene Description des technologies impliquées numérique sur un intervalle d entiers de 120 à 1024, plutôt que d énumérer les 905 termes pouvant exister dans l index, on utilise des termes particuliers rajoutés pour exprimer moins de précision (en enlevant 4 bits par défaut). Quand un intervalle contient tous les termes de plus grande précision contenus dans un autre terme plus large, ce dernier est utilisé. Par exemple de 16 à 31, le second groupe de 4 bits (bits de poids 4 à 7) vaut toujours 0001b, un groupement est donc réalisable. Précision Précision Précision Précision Nombre TABLE 1 Représentation binaire des nombres requêtés. Les éléments en italique sont les termes requêtés. En gris foncé figurent les éléments ignorés car un terme de plus faible précision a été utilisé à la place. En gris clair, les termes dont la précision ne nous intéresse pas La requête générée est décrite par l arbre ci-dessous : à à à FIGURE 1 Arbre correspondant aux simplifications effectuées. Les termes requêtés sont en italique. La requête devient donc : 15 termes { }} { termes { }} { termes { }} { Les indices dénotent le niveau de précision du terme. Cette requête n utilise plus que 27 termes. On comprend ainsi, par cet exemple de requête en apparence simple, l importance de bien saisir le mode de fonctionnement du moteur Lucene afin d appréhender les points pouvant être susceptibles de devenir des goulots d étranglement. Stage de 3 ème année Olivier FAVRE 9

10 ElasticSearch Description des technologies impliquées Mapping et consistance De plus, l exemple précédent introduit une autre notion que vous n avez peut-être pas remarqué : si Lucene est un moteur de recherche textuel nous pouvons néanmoins utiliser des caractères arbitraires, c est à dire des données binaires. Il ne faudra cependant pas qu il puisse régner de confusion entre des termes textuels et des termes binaires, ni même sur la transformation appliquée aux données initiales pour obtenir un terme. Nous voyons une contrainte qui émerge ici d elle même : l importance de maîtriser le contenu des champs, c est à dire de se fixer un mapping entre chaque champ et un type de données. Ainsi il convient de ne finalement pas mélanger des valeurs textuelles, temporelles et numériques sous un même nom de champ. 3.2 ElasticSearch Présentation ElasticSearch est une surcouche pour Lucene, qui lui permet un passage à l échelle dynamique et sans accrocs. Sans configuration nécessaire, simple à déployer, il permet de construire une fonctionnalité de recherche basique mais néanmoins puissante en peu de temps. Également écrit en Java, son code est clair et très modulaire. Beaucoup de fonctionnalités supplémentaires sont intégrables sous forme de modules Souplesse de configuration La configuration permet de créer plusieurs index et d en détailler le mapping de ses champs, bien qu il soit également possible de lui lancer des documents qu il indexera à la volée en détectant le type probable des différents champs. En se plongeant dans la configuration du mapping, on peut indiquer si un champ doit être analysé ou avant d être indexé, s il doit être indexé tel quel, ou s il ne doit pas l être du tout. Un champ peut également être stocké ou non. Ces deux choix permettent de diminuer la taille de l index en tirant profit d une connaissance au préalable de l utilisation de chaque champ. Il est également possible de configurer la chaîne d analyse très souple que Lucene propose, à partir de la configuration. On référence ensuite un analyseur ainsi construit dans le mapping des champs. Les meta-données des termes tirés de l analyse peuvent ou non être stockées. C est encore un levier supplémentaire sur le compromis entre la taille de l index et la qualité des réponses et du surlignage des mots ayant matché les termes recherchés. En effet, sans information sur la position des mots on ne peut favoriser les termes dans un ordre proche de celui de la requête originelle, si savoir à quelles positions insérer les balises de surlignement Terminologie Un cluster peut contenir plusieurs index ; un index est également un index Lucene ; un index peut contenir plusieurs types ayant des mappings de champs différents ; Stage de 3 ème année Olivier FAVRE 10

11 ElasticSearch Description des technologies impliquées chaque document est associé à un index et un type, et possède un identifiant unique, éventuellement généré automatiquement ; chaque document est également versionné. L identifiant est un champ Lucene comme un autre, mais il possède un sens particulier dans ElasticSearch. Il est préfixé par le type du document. Ceci permet de pouvoir adapter le traitement des différents champs comme le mapping de chaque type l exige. La version de chaque document sert exclusivement à la résolution des conflits de mise à jour, pouvant survenir étant donné la nature distribuée de la plate-forme. Elle ne permet en aucun cas de récupérer une ancienne version dudit document Aspect distribué Chaque index ElasticSearch étant distribué, il correspond en réalité à plusieurs index Lucene : un par shard. Le nombre de shard d un index est fixé à sa création et ne peut être changé par la suite sans procéder à une réindexation complète manuelle. L identifiant de chaque document est hashé en un entier qui, modulo le nombre de shard, donne le numéro du shard auquel il appartient. C est une technique très fréquente dans le partitionnement des bases de données distribuées suivant le principe shared nothing. Elle possède l inconvénient de changer la quasi-totalité des affectations clé-shard à chaque changement du nombre de shard. Un technique n ayant pas cet inconvénient s appelle Distributed Hash Table, à base de consistent hashing. Un shard est soit maître soit un replica (une copie). Le nombre de replica par shard maître lui, est changeable dynamiquement. L indexation a lieu dans les shards maîtres, la recherche peut avoir lieu indifféremment dans le shard maître ou dans un replica. Régulièrement, les changements apportés au shard maître sont répercutés dans les replicas, soit en y rejouant les requêtes, l analyse des documents est donc réalisée plusieurs fois, soit en transférant les segments de l index Lucene qui ont été impactés. Un replica permet plusieurs choses : augmenter la disponibilité et donc la performance de la recherche, car on peut contacter n importe lequel des replicas pour répartir la charge d une requête ; avoir une tolérance aux pannes, car un replica étant une copie du shard maître, n importe lequel peut être élu shard maître à son tour, si l ancien a été victime d un crash. Il est possible de rajouter aisément de nouvelles machines à un cluster ElasticSearch existant. Il suffit simplement que la nouvelle instance possède le même nom de cluster. Une découverte automatique sera alors réalisée, et le nouveau nœud ElasticSearch sera alors intégré aux autres. La charge de l index ElasticSearch sera répartie de nouveau en déplaçant certain replicas ou même certains shards maîtres vers le nouveau nœud ElasticSearch, en maximisant la répartition et en minimisant la présence des shards maîtres sur une même machine. Un cluster ElasticSearch possède également un nœud maître. Il est chargé d orchestrer la vie et la répartition des shards dans le cluster. Si le nœud maître devient indisponible, les nœuds esclaves en élisent un nouveau parmi eux. Pour résumer, un cluster ElasticSearch est composé de plusieurs machines pouvant faire tourner plusieurs instances d ElasticSearch appelées des nœuds, qui possèdent le même identifiant de cluster. Dans un cluster existe un seul nœud maître. Un index ElasticSearch est découpé en plusieurs shards maîtres. Pour chaque shard maître il existe Stage de 3 ème année Olivier FAVRE 11

12 ElasticSearch Description des technologies impliquées un certain nombre de shard replica. Chaque nœud possède plusieurs shards (maître ou replica). Chaque shard est un index Lucene, correspondant donc à une partie d un index ElasticSearch. Tout ceci est quelque peu complexe, mais dans les faits, cela fonctionne de manière entièrement transparente. On peut s adresser à n importe quel nœud ElasticSearch pour effectuer une indexation, une requête, ou une demande d état du cluster, les redirections nécessaires se font automatiquement Développement Le développement d ElasticSearch a été quasi-intégralement réalisé par l israélien Shay Banon, dixit kimchy. Ce logiciel est plus ou moins indépendant de celui de Lucene, cependant il suit de très près ses changements de version. Certaines fonctionnalités ont été intégralement créées dans ElasticSearch, et ne sont pas disponibles dans Lucene directement. Par exemple, les facettes qui permettent de collecter des informations et autre statistiques sur les valeurs des champs des documents matchés par la requête, existent dans Solr une autre surcouche, officielle, mais pas dans Lucene même. D autre fonctionnalités, comme un log transactionnel, permettant de survivre à un crash sans perdre aucune des opérations en cours, on été intégrées à Lucene après avoir existé presque depuis les débuts d ElasticSearch. Stage de 3 ème année Olivier FAVRE 12

13 4 Le plus gros du travail Le plus gros du travail 4.1 Configuration La configuration n est pas l étape qui prend le plus de temps, surtout en environnement de test. Dans un environnement de cluster, il faut faire attention à bien configurer les capacités d auto-détection des nœuds afin d éviter que plusieurs instances rejoignent le même cluster, mais surtout s assurer que tous les nœuds futurs pourront s y joindre. Il faut veiller à configurer convenablement les nombre de nœuds attendus, le nombre de nœuds minimum ainsi que le temps minimum à attendre pour commencer une récupération du cluster. Il est également possible de configurer la persistance de l index afin d utiliser soit des index en mémoire seulement, soit une persistance en fichiers locaux, ou sur un système de gestion de fichier partagés. 4.2 Analyseurs Les différents analyseurs personnalisés utilisables dans les mappings doivent être définis dans la configuration. Ceci est une étape plutôt longue et délicate. Nous avons une centaine de langue à gérer, pour chacune d entre elles, nous devons utiliser les outils les plus appropriés disponibles dans Lucene. L analyseur par défaut permet de découper les mots de manière convenable pour la plupart des langages européens en ignorant la ponctuation et séparant les mots composés avec des tirets. Il permet de conserver les noms de produits en un seul morceaux, ainsi que les adresses s et les noms d hôtes internet. Après le découpage des mots, les mots sont normalisés en supprimant les «s» finaux et les points des acronymes, et sont également mis en minuscule et certains mots clés sont supprimés. Il existe des analyseurs plus spécifiques pour une trentaine de langages. Certains analyseurs sont également disponibles sur Internet et nécessitent d écrire un plugin pour les adapter à ElasticSearch. Plus de détails sont disponibles dans la section Mapping Nos documents possèdent plus de 200 champs. Certains sont propres à Exalead, d autres ont une structure ou ont été adaptés spécialement pour bien fonctionner avec Exalead, la plupart sont plutôt classiques. Un travail long et fastidieux ainsi que difficile à rendre compte dans un rapport a été nécessaire afin de créer le mapping adapté pour ElasticSearch. Avec Benjamin, nous nous y sommes repris à plusieurs fois. Certains champs textuels devaient rester des mot-clés et ne pas être analysés mais devaient être indexés, d autre en revanche devaient être analysés. Parmi ces deux catégories de champs, certains devaient être disponibles dans une recherche sans avoir à en préciser le champ (dans ElasticSearch, ces champs ont la propriété include_in_all, et leur valeur sont recopiées dans un champ particulier nommé _all). Certains champs n ont pas vocation a être indexés car ils ne seront utiles qu une fois le document récupéré. Stage de 3 ème année Olivier FAVRE 13

14 Développement de modules Le plus gros du travail Certains champs comportent des données numériques, d amplitude variable et donc pouvant bénéficier d optimisations diverses sur le nombre de termes de plus faible précision à indexer. Le défaut d un pas de 4 bits de précision, décrit dans les requêtes numériques Lucene, est effectivement configurable, et la taille de l index ainsi que la rapidité de requêtage en sont affectés. Enfin, certains champs sont hiérarchiques et chaque niveau, avec ses ancêtres, doivent être indexés séparément pour permettre un requêtage séparé et un calcul de statistique différencié. Ceci est géré de base par Exalead, mais le découpage nécessite un analyseur particulier pour Lucene. 4.3 Développement de modules Exalead et ElasticSearch n ayant pas les mêmes particularités, des développements ont naturellement été nécessaires. Certains ont été fait en amont, avant la construction du document JSON, car temporaires, d autre en revanche ont été réalisés sous forme de plugins ElasticSearch, car les adaptations ne devraient pas altérer la forme du document, mais plutôt les traitements qui sont effectués dessus par ElasticSearch. Je décris ici quelques uns de ces développements, d autres, plus spécifiques aux types de données manipulées en interne ne sont pas explicités Expressivité du champ de recherche La chaîne de recherche ne s écrit pas de la même façon dans Lucene que dans Exalead pour effectuer une recherche numérique sur un intervalle. Exalead utilise une syntaxe très naturelle «champ>=valeur» alors que Lucene utilise plutôt «champ:[valeur TO *]». On retrouve l utilisation de la première forme en dehors des classes propres à Exalead dans le code source, il me fallait trouver un moyen pour la faire comprendre à ElasticSearch En route vers une contribution En recherchant sur Internet, je n ai trouvé aucune solution. Plutôt que de me pencher sur un pré-traitement de la chaîne de recherche transformant la première syntaxe en la seconde, j ai préféré regarder du côté du travail de la communauté Lucene. J ai trouvé le ticket LUCENE-1823 dans leur site de gestion des développements, qui avait été créé il y a 2 ans, à l activité très disparate. Mais ce ticket est encore ouvert et fait en fait référence à plusieurs autres patchs. Parmi la wishlist figure «3. Improved RangeQuery syntax : Use more intuitive <=, =, >= instead of [] and {}.», mais aucun patch n avait été proposé. Je me suis donc chargé de cette tâche et ait créé deux patchs pour le ticket LUCENE-3343 que j ai alors ouvert : un pour la version prochaine 3.4 de Lucene, un pour la version future 4.0. Cependant, je ne voulais pas modifier la version de Lucene qu ElasticSearch utilise. J ai préféré opter pour la création d un plugin à part entière. J ai ainsi créé un projet copiant Lucene, en le débarrassant de tout élément superflu non modifié, j ai changé le nom du package et de certaines classes pour éviter les conflits, et j ai recompilé le tout pour me fournir un nouveau module Jar pour Lucene. Il m a suffit de copier l adaptation déjà réalisée dans ElasticSearch pour l adapter afin qu il utilise mon nouveau module Lucene à la place du module dans le cœur de la bibliothèque. Stage de 3 ème année Olivier FAVRE 14

15 Développement de modules Le plus gros du travail Analyse avancée des champs textuels Exalead permet d indexer une forme exacte, une forme normalisée ainsi qu une forme lemmatisée de chaque mot. Chacune de ses forme ayant moins de poids que la précédente. Ceci permet de favoriser une correspondance plus exacte sur l orthographe d un mot par rapport à une correspondance par un détour plus important. C est une méthode très intéressante qui n existe malheureusement pas dans Lucene. S il est effectivement possible et géré de sortir plusieurs termes à la même position pour un même mot en entrée, le filtre de synonymes est le seul élément d analyse existant qui permette de le faire, et ça n est clairement pas l outil le plus adapté. Il n est pas possible avec Lucene de combiner le résultat de plusieurs analyseurs. Il est en revanche possible de dédoubler un champ afin qu il subisse plusieurs analyses différentes sous ElasticSearch. Cependant avec cette méthode, il est impossible d effectuer une recherche de conjonction (et logique) de plusieurs termes l utilisation d une disjonction (ou logique) n étant pas intéressant car elle à pour effet de faire remonter de plus en plus de résultats au fur et à mesure que l utilisateur précise sa recherche en rajoutant des mots. C est un défaut que je devais régler pour assurer le bon fonctionnement de notre recherche En route vers une seconde contribution Ayant déjà expérimenté la création d analyseurs dans mon dernier stage, j avais déjà une idée précise de ce qu il fallait que je fasse. Dans Lucene, un Analyzer est un objet qui renvoie un flux de termes à partir d un nom de champ et d une source de texte. Un flux de terme est créé par un Tokenizer qui découpe une source de texte en flux d attributs décrivant les termes successifs. Une seconde manière d obtenir un flux de terme, est d appliquer un filtre via un TokenFilter, afin d en modifier les attributs, mais également de pouvoir créer ou supprimer certains termes. J ai besoin de créer un Analyzer qui puisse créer à son tour plusieurs flux de termes à partir de sous-analyzers, et qui les regroupe au final en un seul flux, si possible ordonné d une façon naturelle position du mot croissante puis position en caractères croissante puis conservation éventuelle du sous-analyseur source pour conserver une séquence de termes à une même position afin d éviter des bugs potentiels sur d autres composants de la chaîne d analyse parmi laquelle notre analyseur figure éventuellement. Plusieurs obstacles se sont dressés. Le premier est qu une source ne peut être dupliquée à moins de la lire entièrement et de la stocker pour créer ultérieurement plusieurs sources, une par sous-analyseur. J ai développé une optimisation à ce cas le plus défavorable : pour un StringReader (et pour quelques autre classes), de loin la plus utilisée dans Lucene en interne, il est possible d accéder au champ interne déclaré par le JRE de Sun en mettant à profit l API de reflexivité de Java, évitant ainsi une duplication fastidieuse et coûteuse. Une autre optimisation est de déballer (unwrap) un Reader caché à l intérieur d un BufferedReader afin de pouvoir trouver une éventuelle optimisation adaptée au Reader interne. Stage de 3 ème année Olivier FAVRE 15

16 Développement de modules Le plus gros du travail Le système d optimisation doit pouvoir s appliquer seul, de manière dynamique en fonction des types rencontrés. Ainsi, à base de tables d association entre un type et un cloneur ou un déballeur, en utilisant le type parent quand le sous-type n est pas reconnu, j ai construit une factory de cloneur de Reader, à grand coup de généricité et de binding. Le second obstacle était plus du domaine de la formalité en comparaison. Beaucoup de choses dans Lucene sont faites pour être réutilisable afin d éviter d allouer trop d objets inutilement. Les analyseurs en faisant partie, j ai également tenté de détecter lorsque c était le cas, afin de ne pas ruiner ces optimisations et de réutiliser les objets que j ai moi-même créé. À la clé, plusieurs problèmes de thread safety doivent être gérés. Les attributs de termes sont également de cette catégorie. Ainsi le consommateur d un flux de termes récupère une unique instance de chaque type d attribut, et en lit la valeur, mise à jour après chaque obtention d un nouveau terme. Il m est alors impossible de renvoyer les attributs provenant de mon sous-analyseur actuel. Une détection de présence et une recopie manuelle se sont avérées nécessaires, fort heureusement, la chose a plus ou moins été prévue dans Lucene. À l heure où j écris ces lignes, je n ai malheureusement aucune nouvelle de l ajout de fonctionnalité proposé à la communauté : LUCENE Je suis conscient que ce patch, avec son module d optimisation, ne sera pas accepté de façon immédiate. Mais je suis persuadé d avoir implémenté la solution la moins pire, une autre ayant nécessité un refactoring massif de code et provoqué un changement d API majeur ayant des répercussions pour tout utilisateur de l indexation de Lucene. Ici encore, j ai implémenté ceci sous la forme d un plugin ElasticSearch. J ai d ailleurs commencé par expérimenter cette fonctionnalité comme cela. Voici le ticket que j ai ouvert pour ElasticSearch : issues/ Requête sur une phylogénie D une manière similaire à l optimisation réalisée dans Lucene sur le requêtage des nombres, nous avons une structure de donnée particulière décrivant un arbre de chaînes de caractères, que nous pouvons requêter avec un formalisme particulier : abcd abefg abefhi abj 1:a 2:b 3:c 4:d 1:a 2:b 3:e 4:f 5:g 1:a 2:b 3:e 4:f 5:h 6:i 1:a 2:b 3:j abcd abefg abefhi abj ab {cd ef {g hi} j} (2) ab {cd ef {g hi} j} 1:a 2:b 3:c 4:d 3:e 4:f { 5:g 5:h 6:i 3:j (3) Stage de 3 ème année Olivier FAVRE 16 (1)

17 Intégration Le plus gros du travail La relation 1 montre une façon naïve de requêter 4 mots donc chaque lettre devient un terme constitué de sa position et de la lettre. Il y a 18 termes, dont beaucoup sont regardés plusieurs fois. La relation 2 est une réécriture que nous utilisons en interne. La plupart du temps, les phylogénies sont bien plus complexes, dans cet exemple la différence apportée par l optimisation suivante n est encore que faible. Fort de cette réécriture, la relation 3 montre la construction d une requête booléenne optimisée, ne requêtant que 10 termes, sans doublons. c d g a b e f h i j FIGURE 2 La phylogénie correspondant à la requête optimisée. Le parcours en profondeur s effectue avec des et logiques tandis que le parcours en largeur s effectue avec des ou logiques. Cette optimisation est effectivement intéressante sur des phylogénies conséquentes car aucune optimisation n est réalisée par ElasticSearch ou par Lucene sur une requête booléenne du genre a a ou a a. 4.4 Intégration Traitement des workunits d entrée L indexation d Exalead fonctionne en surveillant un dossier où sont déposées des archives compressées contenant chaque document décrits en XML. Ils appellent workunit ces archives et corporate document ces éléments à indexer. Or ElasticSearch dispose seulement d une interface HTTP via laquelle il faut envoyer des documents JSON. Un développement a donc été nécessaire afin de permettre l indexation des annonces. Stéphane et Majid ont pris en main son développement dès le premier jour de leur mission, alors que je me formais sur ElasticSearch. L outil développé est un démon Java surveillant un répertoire, extrayant chaque corporate document de la workunit avant de les parser et de construire l objet JSON correspondant. Certains champs nécessitent un pré-traitement, comme l extraction de coordonnées GPS à partir d un champ ayant été encodé d une manière à satisfaire les contraintes d Exalead, ElasticSearch pouvant effectuer plusieurs traitement intéressants avec ce genre de données. Ayant acquis une bonne connaissance du moteur d indexation, j ai pu guider le développement en partie ainsi que corriger des bugs trouvés en testant l indexation. J ai surtout amélioré l aspect parallélisation en modifiant le code, ainsi que le transfert FTP pour utiliser un répertoire temporaire suivi d un déplacement atomique, pour se soustraire à un appel coûteux à la commande lsof qui vérifie si un fichier est actuellement utilisé par un autre processus. Ceci afin d augmenter les performances en indexation et saturer ElasticSearch pour le pousser dans ses derniers retranchements. Stage de 3 ème année Olivier FAVRE 17

18 Intégration Le plus gros du travail Cet outil est normalement temporaire. En effet, les machines réalisant l analyse des annonces peuvent dorénavant directement envoyer le document construit à l indexeur, pour peu qu il soit en JSON. Dans les faits, une grande partie de la chaîne de crawling et d analyse est effectuée grâce aux technologies d Exalead, et a été modifiée en grande partie par nos soins. Ainsi, les corporate documents sont créés en amont de la chaîne de traitement et enrichis au fur et à mesure. Il sera donc plus difficile de s en séparer Front Le site web PHP est assez modulable, il a donc été facile de basculer vers l utilisation d autres classes pour changer le moteur de recherches à utiliser. En revanche, l intégration de ce dernier est plus longue. Il faut mapper chaque fonctionnalité pour réaliser l équivalent avec ElasticSearch. Ce dernier possède un langage d expression des requêtes très modulable et très fournis, axé sur une imbrication hiérarchique de plusieurs éléments de requête exprimés également en JSON. Ces requêtes sont plutôt verbeuses et la quasi totalité de la configuration s effectue en leur sein. Exalead au contraire utilise des requêtes totalement plates et dont une bonne partie de la configuration s effectue au préalable dans une page d administration. La construction des requêtes a donc nécessité beaucoup d efforts, et je m y suis repris à plusieurs fois car il n est pas aisé d obtenir des résultats aussi bons que ceux qu Exalead parvient à fournir, après plusieurs années d utilisation et d ajustements réalisés en interne. Cela fait plus de cinq ans que cette technologie a été utilisée exclusivement. Comme nous avons pu le constater, une partie de la logique qui y était propre a fini par glisser dans d autres classes du code du site web, rendant l intégration encore un peu plus difficile Module de présence En profitant d une refonte de l architecture logicielle, on m a demandé d évaluer la faisabilité d une nouvelle fonctionnalité. Nous voulons pouvoir mettre plus en avant les annonces postées par les personnes actuellement en ligne sur notre système de chat sur le site, ainsi que les annonces postées par les contacts du client effectuant une recherche. La seconde partie est facile à implémenter en rajoutant une condition facultative aux requêtes, ayant pour effet de booster le score des annonces ayant pour auteur une personne figurant parmi une liste définie. La première partie en revanche s annonce plus complexe, car il n est pas réaliste d attacher l immense liste des personnes connectées à chaque requête. Tout d abord, il me faut vous décrire la façon dont nous pouvons être notifiés de la présence ou de l absence d un utilisateur. Notre système de chat utilise le protocole XMPP servi par un serveur ejabberd dans lequel nous avons déjà implémenté un module de listage et de notification des personnes connectées par opposition à la liste des personnes figurant dans une chatroom, car il est inutile est surtout coûteux en terme d échanges réseau d inscrire systématiquement chaque utilisateur dans un tel salon de discussion factice. Ainsi il suffit de créer un client particulier qui se connecte au serveur Stage de 3 ème année Olivier FAVRE 18

19 Validation Le plus gros du travail de chat et qui s inscrit à ces notifications, pour pouvoir reconstruire une liste tenue à jour des utilisateurs connectés. La première approche que j ai testé consiste à créer un composant à ElasticSearch qui se connecterait au serveur et maintiendrait une telle liste, ainsi qu un nouveau type de requête qui pour chaque document retourné par la requête principale, récupère les auteurs et teste leur existence dans ladite liste, avant d augmenter ou non leur score. Cette approche s est avérée désastreuse en terme de temps de traitement : il fallait une quarantaine de minutes pour l examen de près de 9 millions de résultats retournés par la requête principale. Le goulot d étranglement réside entièrement dans la récupération de la valeur du champ auteur pour un nombre très important de documents. Une seconde approche, proposée par Majid, consiste à tirer parti d une requête particulière d ElasticSearch : on effectue une recherche sur des documents fils, elle nous retourne les documents pères correspondants. De cette manière, nous sommes obligés de tester la présence d un document fils pour chaque annonce, et de booster le score des annonces correspondantes. Nous avons donc la tâche de créer un service externe car les annonces sont réparties entre les différents nœuds du cluster qui maintient la liste des personnes connectées, et qui, pour chaque changement de statut, liste les identifiants des annonces de ladite personne, et commande soit la création d autant de document fils, soit la destruction des documents fils rattachés. En utilisant cette solution, on est capable de continuer à servir les recherches, tout en pouvant gérer plus de 60 changements d états par seconde, pour une moyenne de 10 annonces par personne. Ces performances lors de la recherche sont également dues à l utilisation de l index. 4.5 Validation Cette étape ultime n a pas encore été réalisé, faute de temps. Cette section se limitera simplement à une description de ce qu il est envisagé de faire Comparaison des résultats Afin de s assurer que notre travail est fructueux, il convient d en tester les résultats. En programmation les tests unitaires sont fait pour cela. Ici cependant nous sommes en quelque sorte un peu un niveau au dessus, mais la philosophie des tests reste la même : on fournit une entrée, des traitements à effectuer, cela donne un résultat, et nous en analysons la conformité avec un résultat pré-établit. L entrée consiste en un ensemble de documents à indexer, avec un mapping associé éventuel, la plupart du temps le mapping longuement travaillé que nous utilisons sur nos annonces. À cette entrée doit correspondre une instance d ElasticSearch, la plus fraîche possible. Nous allons donc déployer, exécuter et détruire une instance pour chaque test. La facilité de déploiement d ElasticSearch est grandement appréciée ici. À la fin de l indexation, il ne faut pas oublier un appel de l opération refresh, afin que les documents indexés soient immédiatement accessibles à la recherche. Les traitements sont une série de requêtes JSON a jouer auprès de l instance d ElasticSearch de test. Ces requêtes peuvent aussi bien être de la recherche que des ordres de suppression ou autre. Stage de 3 ème année Olivier FAVRE 19

20 Déploiement Le plus gros du travail Chaque traitement renvoie une réponse JSON. Une analyse poussée à lieu ici. Nous allons vérifier le nombre de résultats trouvés, ainsi que l ordre d apparition de chaque document, voire son score, bien que ce dernier n ait au final aucune importance pour l utilisateur. En fonction de la divergence des résultats avec ceux attendus, nous donnerons une statistique de qualité. Nous ne sommes effectivement pas dans une optique manichéenne qui voudrait qu une seule réponse ne soit bonne. Parmi les test de conformité seront relevée la présence de tous les champs nécessaires, et des champs supplémentaires. L absence d expiration de délai à la recherche sera également important lorsque l on voudra s assurer que le moteur est capable de répondre dans des temps minimes. Un autre critère sera relevés pour un suivit. Il s agit du temps de réponse à l indexation et à la recherche. Tout ceci pourra être réalisé dans l environnement de test de Jenkins, que nous utilisons déjà en interne. 4.6 Déploiement Naturellement, cette étape n a pas encore été réalisée non plus. Cette section présente le fruit d une réflexion avec Abdelmajid Boubrik, Stéphane Jais, Benjamin Devèze, Frédéric Mahé et moi même. Avant d envisager un déploiement, il faut d abord dimensionner l architecture nécessaire. Nous avons jusqu ici tenté de conserver une taille d index raisonnable pour pouvoir tourner sur un cluster de 8 machines possédant chacune une grappe de disques SSD d un total de 640 Go et 96 Go de mémoire vive. Chaque machine coûte environ e. Il n est cependant pas exclu de passer à un nombre beaucoup plus important de machine de moyenne gamme. Si ElasticSearch fonctionne toujours mieux avec une grande quantité de mémoire vive, il n a cependant pas besoin de tourner sur un serveur haut de gamme. Tout cela reste quand même à valider, peut être en créant un cluster sur nos machines de travail afin d avoir une meilleure idée des ressources nécessaires. Le début de la migration peut s effectuer de deux manières : dérouter une partie du trafic vers le nouveau cluster, ou migrer tout un pays à la fois. La première méthode présente l avantage de minimiser l impact d un problème éventuel, et de pouvoir effectuer une transition progressive en augmentant petit à petit la quantité de trafic à dérouter. Cependant il faut définir les critères de façon à ce que l expérience d une client ne soit pas perturbée. De même, il est coûteux d indexer une grande quantité de document, nous devons donc nous assurer qu elle serve, ou en indexer moins. Il est délicat de savoir, a priori, quels documents sont susceptibles d intéresser quels utilisateurs sans faire d erreurs. La solution commence à devenir un peu complexe pour valoir le coup en tant que traitement provisoire. La seconde méthode permet une distinction claire sur les requêtes à intercepter : celles qui ne sont effectuées que dans un seul pays, si ce pays figure parmi une liste fixée. L expérience utilisateur peut éventuellement varier si il recherche successivement dans un pays géré par Exalead et dans un pays géré par ElasticSearch, mais cela devrait rester minime et peu dérangeant. Si un problème survient, en revanche, il faudra être très réactif pour repasser le trafic sur Exalead. Nous pouvons cependant commencer par migrer les pays pour lesquels nous avons le moins d annonce et de trafic, avant Stage de 3 ème année Olivier FAVRE 20