parlons elasticsearch - digital aquitaine ... 2017/10/04 آ  parlons elasticsearch avec groupe...

Download PARLONS Elasticsearch - Digital Aquitaine ... 2017/10/04 آ  PARLONS Elasticsearch avec Groupe CARTأ‰GIE

Post on 24-Jul-2020

0 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • PARLONS Elasticsearch

    avec

    Groupe CARTÉGIE

    18 octobre 2017

    Vincent BOUGON

    Directeur de Projets WEB

    vincent.bougon@cartegie.com

    Stéphane LIÉNÉRÉ

    Directeur Technique et

    Innovation

    stephane.lienere@cartegie.com

    mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com mailto:vincent.bougon@cartegie.com

  • 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

    D o c E

    n tr

    e p ri s e

    {

    « 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

    D o c E

    n tr

    e p ri s e

    {

    « siret »,

    « siren »,

    « raison_sociale »,

    « dept »,

    « libelle_dept »,

    ….

    }

    Entreprise

    D o c C

    o n ta

    c t

    {

    « siret »,

    « nom »,

    « prenom »,

    « fonction »,

    « email »

    ….

    }

    Contacts

    D o c B

    ila n

    {

    « 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

    D o c E

    n tr

    e p ri s e

    {

    « siret »,

    « siren »,

    « raison_sociale »,

    « dept »,

    « libelle_dept »,

    ….

    « bilan » : {

    « date »,

    « bicn »,

    …..

    }

    }

    Entreprise

    Bilan

    D o c C

    o n ta

    c t

    {

    « 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 à jo