Un chtijug élastique

D’abord, quelques annonces

A 20 € ! Ca va être dur de faire valider la note de frais.

Pour les slides, c’est par là

Elastic, c’est 4 projets open-source :

  • Logstash (malheureusement écrit en JRuby)
  • Beats (alternatives à Logstash en go beaucoup plus simple). il y a FileBeats, NetworkBeats, MetricBeats
  • Elasticsearch (moteur d’indexation et de recherche JSON. Ne loupez pas l’interview de notre speaker chez lescastcodeurs)
  • Kibana (outil de dashboard)

Et un ensemble de solution commerciales appelées génériquement X-Pack

En particulier, graph permet d’éviter le problèmes des supernoeuds dans les graphes (un problème auquel je suis assez sensible, mais je m’éloigne du sujet).
Et prelert va identifier les erreurs « exceptionnelles » grâce à de l’apprentissage.

A quoi sert elasticsearch ?

Ben à faire des recherches floues, où à trier les résultats de recherche selon … un score. Et floue, ça implique de gérer les fautes d’orthographe, les textes approchants, les synonymes, …

Et maintenant, le coeur de la présentation : ingest node

Avec ingest, on peut remplacer l’architecture classique

iyxfbszfiyqhkn3bp4briaqiaupaxelvvas7bogmpowa5ifpxazotebfsoa4r1ixorlc91qnp2o7foom9mtmmmtkjkco3cvfsa5c1vc85kpm5kqwtyzc0g00

par une architecture beaucoup plus simple

iyxfbszfiyqhkn3bp4briaqiaupaxekvvygmbsgc1wsc5ylda5hpag01gjopbpsrk8ihbwkkllvn3y880000

Du coup, le pipeline de transformation Logstash (grok, date, mutate) est remplacé par un équivalent ingest (grok, date, remove). Il y a naturellement tout un tas de plugins (dont la lecture d’attachments avec Tika). Bon, autrement dit, on remplace un ETL par un autre, espérons juste qu’il soit plus performant. Et évidement, on peut créer ses propres plugins.

Il y a quand même un gros intérêt, puisque les pipelines ingest sont utilisables dans la plupart des urls d’appel à Elasticsearch. Et en particulier, dans l’un des trucs les plus balaizes : le reindex. Ce reindex permet la migration facile d’un cluster Elasticsearch d’une vieille version vers une nouvelle. Et ça, ça me paraît vraiment très chouette.

Comme dans n’importe quel ETL, il est possible de définir des failure processors qui vont être utilisés en cas d’échec lors de la série de transformation. On peut les définir par pipeline ou par processeur.

Dans un cluster, (parce que oui, Elasticsearch fonctionne toujours en cluster), il est possible de laisser tous les noeuds faire de l’ingestion, on d’en forcer certains à faire l’ingestion. En prod, d’ailleurs, il vaut mieux séparer les noeuds d’ingestion des noeuds de données.

Et si on regardait un plugin ?

Par exemple, le fameux plugin BANO (déja mentionné chez les castcodeurs). BANO pour base nationale d’adresses, parce que David est fan des adresses postales. Et cette base, ce sont des documents CSV (ou JSON) disponibles chez OpenStreetMap.
Donc David a un plugin qui lui permet de charger dans Elasticsearch la base des adresses, puis d’enrichir les adresses et les localisations GPS en ajoutant la donnée inverse.

Et maintenant, c’est le moment de la démo !

Et franchement, au début, la définition de pipeline d’ingestion est assez facile, et la définition des failure processors est tout aussi facile. J’imagine très bien les interfaces très graphiques faisables là-dessus.
Pour la récupération des données, le fait que ce soit un moteur de recherche fait que des résultats moins pertinents pourront être retournés par les requêtes, mais derrière les résultats les plus pertinents.

Un autre élément intéressant, c’est que la recherche est foutrement rapide : l’ingestion d’une coordonnée GPS avec ajout automatique des adresses (et donc recherche dans l’index des coordonnées) est immédiate (pour autant qu’on puisse le voir). Même si la coordonnée GPS n’est pas exactement la bonne.

Et avec tout ça, et le processor GeoIP, il est par exemple possible d’envoyer un courier à l’adresse donnée lors de la requête HTTP. Ca fout la trouille, hein ?

Au passage, l’un des trucs les plus intéressants selon moi est l’utilisation de JSON pour exprimer les requêtes : le code n’est pas moins clair qu’avec un langage de requête dédié (genre SQL).

Un autre intérêt d’Elasticsearch, c’est qu’il supporte les tâches longues, qu’on peut suivre et gérer (pour par exemple tuer les tâches trop longues).

Non mais, et si on développait vraiment un plugin ?

Eh bien ce serait aussi simple que d’écrire une classe étendant une superclasse abstraite.
Evidement, quand on regarde le code, on voit des choses … curieuses : trouver le point le plus proche en calculant la distance de tous les points, je peux dire que c’est pas le plus efficace (il n’y a pas d’index géographiques ou quadtrees dans Lucene ? Ah si, à priori, avec les bkdtree de Lucene 6).
Dans le même ordre d’idée, déclarer ses plugins en associant une clé à une factory … alors qu’on peut faire du CDI ? C’est pas fameux. mais bon, tout le monde n’est pas censé écrire des plugins.

Conclusion

L’un des plus gros intérêts de cette présentation, c’est de sortir Elasticsearch de son rôle le plus connu de stockage ELK pour bien montrer qu’avant tout, c’est un ETL moderne qu’on sous-utilise volontiers.

Et personnellement, en voyant cette présentation, j’ai eu l’envie un peu folle de resortir mes projets de livestream pour les porter dans une base plus moderne.

Et pour la blague, le premier rang, c’est pratique pour démontrer la présence quand le speaker fait des selfies

Advertisements

2 réflexions sur “Un chtijug élastique

  1. Hello !

    Merci pour l’article. Quelques commentaires :

    Beats (alternatives à Logstash en go beaucoup plus simple). il y a FileBeats, NetworkBeats, MetricBeats

    En fait il s’agit d’agents de collecte de données. Ca complète Logstash ou on peut dire quand ça remplace la partie input de Logstash. Ensuite les noms des beats sont: filebeat, packetbeat, metricbeat

    Et relert va identifier les erreurs « exceptionnelles » grâce à de l’apprentissage.

    C’est Prelert.

    ElasticSearch, Elastic Search

    Globalement on écrit Elasticsearch.

    Et avec tout ça, et le processor GeoIP, il est par exemple possible d’envoyer un courier à l’adresse donnée lors de la requête HTTP. Ca fout la trouille, hein ?

    Juste une remarque, pas la peine de modifier ça, en fait GeoIP donne des coordonnées approximatives. Il y a de fortes chances que ce soit ton voisin qui reçoive le courrier 🙂

    A bientôt !

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s