PARLONS Elasticsearch
avec
Groupe CARTÉGIE
18 octobre 2017
Vincent BOUGON
Directeur de Projets WEB
Stéphane LIÉNÉRÉ
Directeur Technique et
Innovation
UNE NOUVELLE VISION DE LA DATA
Les stratégies
d’entreprises se
réorganisent autour de
la DATA
Les stratégies d’entreprises sont de plus en plus « data
driven » car la Data est aujourd’hui devenue moteur
d’innovation et de nouveaux business models.
La fiabilité, l’agilité et la pertinence des données s’affirment
encore plus comme socle fondateur de toute stratégie.
Fonction support
Ressource stratégique
2010
201
7 Un changement de regard de l’entreprise
s’opère, les ETI, et grands groupes
réorganisent l’entreprise et les fonctions clés
autour de la DATA.
DATA
Le capital Data BtoB & BtoC le plus riche du marché
10,5 millions de profils entreprises
45 millions de profils consommateurs
Une fiabilité
reconnue sur le
marché grâce à une expertise en traitement et
enrichissement de la donnée (data
quality / data management)
30 ans d’historique Une base de connaissances et de
contacts sans équivalence
Des partenaires
stratégiques
exclusifs pour de la donnée à haute valeur
ajoutée
Elasticsearch Une nécessité
Constat et Virage technologique
• Collecte de données de navigation et de données non structurées
• Volume exponentiel
• Nécessité de faire cohabiter de l’information structurées et non structurées
• Ouverture des données directement vers nos clients : Mise à disposition d’API et
d’applications SaaS nécessitant des temps de réponses performants
Virage technologique nécessaire
• Le numérique (web, réseaux sociaux, objets connectés, presse économique digitale…)
génère des millions de nouvelles informations qui enrichissent considérablement les
informations historiques
Constat
Besoin d’appréhender les solutions
NoSQL
Choix d’Elasticsearch
• Rapidité d’interrogation des données quel que soit le volume : interrogation
unitaire (Full-text) ou agrégation
• Une solution éprouvée et une communauté importante
• Une scalabilité facilement mise en place, évolutive et aisé à maintenir
• Des interconnexions simples et efficaces pour construire des index provenant
de SGBD SQL
• Un moteur de recherche géographique extrêmement performant
• Un écosystème dense : Kibana / Logstash / Shield (sécurité) / Marvel
(supervision)
Elasticsearch en détail
SGBDR Elasticsearch
Database Index
Table Type
Row Document
Column Field
Elasticsearch : Moteur de recherche et d’agrégations orienté documents
• Un document utilise une structure de format JSON
Série de Clé/Valeur
• Il accepte des types de champs complexes
Objet
Tableau
Geo_point, geo_shape
ipV4
Multi-champs
Parent/child
• Chaque document peut avoir une structure différentes => destructurés
{
"civilité": "Monsieur",
"prenom": "stéphane",
"nom": "Liénéré",
"Fonction": "Directeur
technique"
"location": {
"lon": -0.5825,
"lat": 44.87305
}
}
Elasticsearch
Cluster ES
Nœud => Instance Elasticsearch
Shard => partie d’Index
Architecture distribuée: (cluster, nœud (master), nœud (data), shard primaire, shard
répliqué)
Cluster ES
Nœud ES
Shard
0 (P)
Shard
1 (P)
Shard
1
(R1)
Shard
0
(R1)
Index
Cluster ES
Nœud ES
Shard
0 (P) Shard 1
(P)
Index
Cluster ES
Nœud 1 (master) Nœud 2
Shard
0 (P)
Shard
0 (R)
Shard
1 (P)
Shard
1 (R)
Index
Shard Principal
Shard secondaire
Index ES
Noeud ES
Document
Notre Architecture
• 6 Nœuds Data
• 2 Nœuds Client
• 2 Nœuds Master
• 27 index
• 194 shards
• 242 millions de
documents
• 540 GB de données
Exemple 1: Structure avec un seul document par entreprise
Avantages
• Avec une seule requête, on récupère
l’ensemble des données d’une
entreprise
• Possibilité de faire des requêtes
complexes sur les sous-documents
Inconvénients
• La mise à jour d’un champ nécessite
la ré-indexation de tout le document
• Modèle permettant plutôt de
répondre aux usages orientés
Entreprises
problématique sur des demandes
d’extraction d’un contact
Doc E
ntr
eprise
{
« siret »,
« siren »,
« raison_sociale »,
« dept »,
« libelle_dept »,
….
« contacts » : [
{
« nom »,
« prenom »,
« fonction »,
« email »
},
{ …. }
],
« bilan » : {
« date »,
« bicn »,
…..
}
}
Entreprise
Contacts
Bilan
Exemple 2: Structure avec un document par source
Doit être caller en fonction du besoin
Avantages
• Cycle de vie des différents
documents faciles à gérer
• Adapté aux différents usages de
recherches unitaires, que ce soit
pour les Entreprises, Contacts ou
Bilans
Inconvénients
• Multiplication des requêtes pour avoir
une information complète
• Impact sur les temps de réponse
Doc E
ntr
eprise
{
« siret »,
« siren »,
« raison_sociale »,
« dept »,
« libelle_dept »,
….
}
Entreprise
Doc C
onta
ct
{
« siret »,
« nom »,
« prenom »,
« fonction »,
« email »
….
}
Contacts
Doc B
ilan
{
« siren »,
« date »,
« bicn »,
…..
}
Bilan
Exemple 3: Structure avec document contact séparé
Avantages
• Avec une seule requête, on récupère
l’ensemble des données d’une
entreprise
Requête via lien parent/enfant
• Cycle de vie des différents
documents reste simple
• Modèle permettant de répondre aux
usages orientés Entreprises ou
Contacts
Inconvénients
• Requêtes moins performantes lors de
l’utilisation du lien parent/enfant
• Elasticsearch met en mémoire la
table de liens
Doc E
ntr
eprise
{
« siret »,
« siren »,
« raison_sociale »,
« dept »,
« libelle_dept »,
….
« bilan » : {
« date »,
« bicn »,
…..
}
}
Entreprise
Bilan
Doc C
onta
ct
{
« nom »,
« prenom »,
« fonction »,
« email »
….
}
Contacts
parent=1234
Choix structure document
En fait, le choix de la structure du
document JSON ne doit pas être défini en
fonction de la structure des données,
mais en fonction de l’utilisation métier
attendue
• Suivant le type de recherche
• Suivant le type d’agrégations/statistiques
• Suivant les informations qui devront être
retournées/affichées
• Suivant le cycle de vie des éléments
Ne pas hésiter à dupliquer la donnée
suivant les différents usages métier
Trouver un équilibre entre performance et
contrainte de mise à jour
Do
c E
ntr
ep
rise
{
« siret »,
« siren »,
« raison_sociale »,
« dept »,
« libelle_dept »,
….
« bilan » : {
« date »,
« bicn »,
…..
}
}
Entreprise
Bilan
Do
c C
on
tact
{
« nom »,
« prenom »,
« fonction »,
« email »
….
}
Contacts
parent=1234
Do
c B
ilan
{
« date »,
« bicn »,
…..
}
Bilan
Exemple Requête Full-text
KalibtoB: application permettant de présenter toute l’information
d’une entreprise => utilise l’API de siretage CARTEGIE
POST /notice80-a,notice80-cd/_search
{
"size": 10,
"_source": {
"includes": [ "identreprise","rs","sigle","enseigne","adresse3",adresse4",
"adresse5","adresse6", "l7_etrg","etat","siege" ]
},
"query": {
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"should": [
{
"multi_match": {
"boost": 1.0,
"query": "CARTEGIE",
"fuzziness": 0,
"operator": "and",
"fields":
["rs.raw^100","l1_nomen.raw","sigle.raw","l2_comp.raw","enseigne.raw"
]
}
},
{
"multi_match": {
"boost": 0.5,
"query": "CARTEGIE",
"fuzziness": 1,
"operator": "and",
"fields":
["rs.raw^100","l1_nomen.raw","sigle.raw","l2_comp.raw","enseigne.raw"
]
}
},
{
"multi_match": {
"boost": 0.25,
"query": "CARTEGIE",
"fuzziness": 0,
"operator": "and",
"fields": ["rs^100","l1_nomen","sigle","l2_comp","enseigne"
]
}
}
]
}
}
]
}
}
]
}
}
]
}
},
{
"function_score": {
"functions": [
{
"filter": {
"match": {
"etat": {
"query": "actif"
}
}
},
"weight": 200.0
}
]
}
},
{
"function_score": {
"functions": [
{
"filter": {
"match": {
"siege": {
"query": "true"
}
}
},
"weight": 40.0
}
]
}
},
{
"function_score": {
"functions": [
{
"filter": {
"match": {
"etat": {
"query": "demenage"
}
}
},
"weight": 30.0
}
]
}
}
]
}
}
}
• Recherche toutes les entreprises
contenant le mot « cartegie »
• Utilisation de : la recherche full-text multi champs,
D’une pondération différente
suivant les champs (« raison
sociale » , « enseigne », « sigle »)
d’une option « Fuzziness »
(tolérance d’erreur d’un caractère
dans ce cas)
D’une pondération sur chaque
ligne de résultat en fonction du
critère : « siège / établissement
secondaire »
• Temps de réponse 15 à 20 ms
Volumétrie: 22 M. d’entreprises
En elasticsearch, on considère que
le temps de réponse correcte se
situe aux alentours de 100ms
• En SQL un simple like %XX%
pénalise fortement le temps de
réponse
Exemple Requête Spatiale
POST /datadrive_marche/_search
{
"size": 0,
"min_score": 0.0,
"_source": false,
"query": {
"bool": {
"must": [
{
"geo_polygon": {
"location": {
"points": [
{
"lat": 48.56794,
"lon": 2.48086
},
{
"lat": 48.580443,
"lon": 2.4762246
},
{
"lat": 48.5985879,
"lon": 2.4277362
},
{
"lat": 48.570337317974605,
"lon": 2.3710809439941327
},
{
"lat": 48.5358734,
"lon": 2.3649001
},
{
"lat": 48.53231,
"lon": 2.38857
},
{
"lat": 48.5283185,
"lon": 2.4520608
},
{
"lat": 48.5625876,
"lon": 2.4800435
},
{
"lat": 48.56794,
"lon": 2.48086
}
]
}
}
}
]
}
}
}
DATA DRIVE: application permettant l’acquisition de prospects qualifiés, d’étudier
son marché et de mesurer sa performance commerciale par zone géographique
• Recherche toute les entreprises
situés dans un secteur
géographique défini par un
polygone
• Utilisation d’une recherche
spatiale « geo_polygon »
• Il est aussi possible d’effectuer
une recherche spatiale de type
« geo_distance » en utilisant un
point et un rayon
• Temps de réponse 5ms pour le comptage
300 ms pour l’obtention des
points
• En SQL une requête spatiale
pénalise fortement le temps de
réponse et nécessite une
préparation de la données
Fonctionnement des « Analyzer »
Objectif: permettre d’améliorer la pertinence des résultats d’une recherche full-text
Elasticsearch permet de construire un champ indexé en y appliquant des règles de transformation et de regroupement
des mots
Différents exemples de transformation : Passer les mots en minuscule
Enlever les accents
Supprimer les articles
Regrouper les mots suivant leur racine étymologique ou leur
synonyme
{
"settings": {
"index": {
"analysis": {
"analyzer": {
"custom_analyzer": {
"type": "custom",
"filter": ["lowercase", "asciifolding", …],
"tokenizer": "whitespace"}
}}},
"mappings": {
"my_type": {
"properties": {
"champ1": {
"type": "text",
"analyzer": "custom_analyzer"
},
…
}}
Exemple:
Agrégations • Exemple d’utilisation d’une
agrégation pour calculer la
répartition du nombre
d’entreprises par Département
• Calcul d’agrégations de type
« Term »
• Volume d’information: 10 Millions d’entreprises
• On peut facilement ajouter
d’autres conditions de filtre telles
que: Activité
Effectif établissement
Chiffre d’Affaire
• Temps de réponse 21 ms pour obtenir le résultat
POST /datadrive_marche/_search
{
"size": 0,
"min_score": 0.0,
"sort": [
{
"region2016": {
"order": "asc"
}
},
{
"dept": {
"order": "asc"
}
},
{
"lib_departement": {
"order": "asc"
}
}
],
"_source": {
"includes": [
"region2016",
"dept",
"lib_departement"
]
},
"aggs": {
"scriptedDistrib": {
"terms": {
"script": {
"inline": "doc['region2016'].value + '&#&#&' + doc['dept'].value + '&#&#&' +
doc['lib_departement'].value"
},
"size": 100000000,
"order": [
{
"_term": "asc"
}
],
"missing": "-1"
}
}
},
"query": {
"bool": {
"must": [
{
"term": {
"region2016": {
"value": "75"
}
}
}
]
}
}
}
POST /entreprises-a/_search
{
"size": 0,
"aggs": {
"dept": {
"terms": {
"field": "dept", "order": {
"_term": "asc"
}
},
"aggs": {
"departement": {
"terms": {
"field": "lib_departement" }
}
}
}
},
"query": {
"term":{"region2016":{"value":"75"}}
}
}
Agrégations • Exemple d’utilisation d’une
requête pour afficher de la
données calculées ainsi que des
agrégations et un date
Histogramme
• Tableau de bord des visites du
site web de cartegie sur une
plage de date Calcul de Métriques
« Cardinality »
Calcul d’agrégations « Term »
Calcul d’agrégation « date
Histogramme »
• Volume d’information: Nombre de visites : 110 M.
Nombre de pages vues 230 M.
• En SQL: on devrait réaliser
plusieurs requêtes
Lead the Way: application permettant d’afficher toutes les
entreprises identifiées ayant visité un site web
APRES 3 ANS D’EXPERIENCES ?
• Force
Recherche Full-text ultra rapide
Recherches unitaires, Agrégations et requêtes spatiales sur de gros volumes de données
Répartition de charge, scalabilité et haute disponibilité en standard et gratuit
Nombre de requêtes minimisées
• Faiblesse
Bonne analyse du besoin métier en amont
Apprentissage d’un nouveau langage : « Query DSL »
Non transactionnel
Difficulté de gestion du process de mise à jour des données
• Evolutions
Des questions ?
Merci de votre attention !