Note de lecture : Storm Applied, par Sean T. Allen, Matthew Jankowski & Peter Pathirana

Note : 6 ; Clair sur la mise en jambe, mais insuffisant sur la gestion en production

J’ai une affection particulière pour Storm, car j’ai activement participé à l’amener dans un projet à une époque où les frameworks Big Data temps réel et plus particulièrement Storm n’étaient pas pris pour acquis. Il aura fallu attendre près de 2 ans de plus pour voir apparaître un ouvrage dédié de bonne facture. Comme nous le verrons, ce dernier ne se limite pas à Storm sensu-stricto.

Le présent ouvrage accuse ses 250 pages totalisant 9 chapitres. Des chapitre relativement longs en moyenne selon mon standard, donc. Le premier d’entre eux ne l’est pas, car il ne pèse que 10 pages. C’est une introduction de haut niveau dont le but est de camper la place de Storm dans le mode du Big Data, et plus précisément dans celui du Big Data temps réel que les auteurs re-segmentent en « stream » et « micro-batching ». En passant, les auteurs positionnent Storm par rapport non seulement à Hadoop, mais à Spark, Samza et Kafka Stream.

Le chapitre 2 est d’avantage dédié architecture et présente les concepts centraux de Storm : Typologie, Tuples, Bolts et Spout. Le tout est abondamment illustré, y compris par des extraits de codes qui ont le bon goût de ne pas être trop longs. L’homme pressé qui n’a pas trop de temps à consacrer pour comprendre Storm y trouvera à se nourrir ! J’avoue que je trouve ce chapitre particulièrement réussi.

Lire la suite

Note de lecture : Making Sense of NoSQL, par Dan McCreary & Ann Kelly

Note 4 ; NoSQL plus ou moins décrypté pour le manager

Voici un ouvrage « à priori » destiné aux managers. En tout cas son objectif est de donner une image du paysage NoSQL sans nécessité de voir une ligne de code. Dans le principe, le livre atteint son objectif : il couvre les différents types de bases NoSQL, avec toutefois un biais marqué vers les bases XML (qui ne sont généralement pas considérées comme des bases NoSQL), ces dernières ayant droit à leur propre chapitre contrairement aux autres ! Mais le texte me laisse quand même un sentiment d’inachevé, il ne permet pas vraiment de comprendre les patterns d’usage des différentes bases par manque de parti pris.

L’ouvrage est assez conséquent pour une introduction. Il compte 275 pages réparties sur 12 chapitres. Ceux-ci sont eux-mêmes regroupés en 4 parties. La première d’entre-elle est une introduction, courte d’un peu plus de 30 pages et de deux chapitres. Le premier répond au « pourquoi » en exposant succinctement quelques cas d’études des grands du Web, c’est hélas très superficiel. Le second s’attaque aux concepts : documents, sharding, théorème de CAP, cache, etc… C’est un peu brouillon et j’aurais préféré y voir une bonne exposition des typologies de bases.

La seconde partie a trait aux patterns de bases de données, à mon avis le sujet central. Nous avons 90 pages réparties sur 3 chapitres. Le chapitre 3 est en théorie consacrée aux patterns architecturaux. Dans la pratique, ses 24 pages couvrent surtout les concepts relationnels et un peu l’OLAP, bref de quoi être bien déçus ! C’est en fait le chapitre 4 qui a la lourde tâche de faire le tour des différents paradigmes de bases NoSQL : clé-valeur, big table et orienté document, sur 33 pages. Nous avons de la chance : ce chapitre est remarquablement bien fait. Vient l’alien au chapitre 5, celui consacré aux bases XML. On sent que le sujet tient au cœur des auteurs car sur ses 27 pages, le sujet est creusé bien plus en profondeur que pour les autres bases. On aborde même la construction d’application avec Exist !

La troisième partie est intitulée « SQL solutions ». Elle est longue de 82 pages et compte 4 chapitres. Le big data est bien sûr un sujet d’importance. On y consacre joyeusement les 27 pages du chapitre 6. Malheureusement, le traitement est d’avantage digne de 01 Informatique que d’un ouvrage sérieux. On y apprend pas grand chose, sauf si vous ignorez que map-reduce est la clé de voute de cette thématique… La recherche est un sujet inattendu mais bienvenu. On reste aussi à haut niveau au long des 17 pages de ce chapitre 7, mais le contenu est un peu plus éclairé que pour le sujet précédent et les auteurs nous y exposent au moins plusieurs typologies de recherche. La haute disponibilité est le sujet des 19 pages du chapitre 8. A mon avis, les auteurs échouent à rendre cela passionnant. Au chapitre 9, on parle d’agilité. Ou plutôt on passe complètement à côté du sujet. De nouveau, les auteurs en profitent pour nous caser un sujet complètement exotique qui leur tient à cœur : un moteur XForm appelé XRX. J’aime bien XForm, même si la norme n’a jamais prise et a aujourd’hui rejoint le cimetière des éléphants, mais que fout ce sujet ici ?

Très classiquement la quatrième partie est dévolue aux « sujets avancés ». Il s’agit de 70 pages sur 3 chapitres. Le chapitre 10 est pour le moins original, car il fait le lien entre programmation fonctionnel et bases NoSQL. Les 22 pages de ce sujet sont plutôt inattendues. Cela concerne surtout les big table, mais c’est plutôt bien construit et sympathique. C’est de sécurité qu’il s’agit au chapitre 11. Nous en prenons pour une vingtaine de pages, mais les auteurs maitrisent vraiment bien leur sujet. C’est un plaisir. On ne peut pas en dire autant du dernier chapitre dédié à la sélection d’une base. Les 20 pages qui y sont consacrées nous proposent un processus bien relou à l’ancienne. C’est idiot et pénible à lire.

Tout n’est pas mauvais dans cet ouvrage, loin s’en faut. Il est hélas souvent un peu trop stratosphérique et bien trop verbeux. Bref, un peu frustrant.

image

Référence complète : Making Sense of NoSQL – Dan McCreary & Ann Kelly – Manning 2013 – ISBN : 978 1 617291 07 4

Making Sense of NoSQL

https://www.goodreads.com/book/add_to_books_widget_frame/1617291072?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Waiting for the Storm…

Le Storm User Group, c’est une initiative de quelques collègues autour du « big data temps réel ». Aujourd’hui, nous parlons de Storm et quelques infrastructures qui peuvent s’y connecter. Demain, il s’agira peut-être de Spark ou d’autres…

Halte là ! Je vais peut-être un peu vite ? Et d’abord, Storm, qu’est-ce que c’est ? Voilà une question à laquelle une partie de cette première rencontre va être consacrée.

Oui, Storm, qu’est-ce que c’est ?

C’est Florian Hussonois qui va répondre à cette question. Nous pourrions résumer la chose en déclarant simplement qu’il s’agit d’un Hadoop « temps réel ». Il s’agit en quelque sorte d’un middleware permettant le traitement d’évènements en mode flux.

Un (petit) peu d’historique

Storm a été développé par Nathan Marz chez BackType en 2011. La société est rachetée ensuite par Twitter qui promeut le projet et le passe en Open-Source. La première release officielle date de 2011. En Septembre 2014, le projet devient officiellement « Apache Top Level Project » alors même qu’il n’a pas encore atteint la release 1.0 !

Ecrit principalement en Clojure et en Java, ce « processeur d’évènements » est conçu pour traiter un flux de très nombreux évènements (des tuples dans la terminologie Storm), à savoir 1 millions de tuples par seconde et par noeud (1 seul coeur processeur), avec tolérance aux fautes, gestion de la scalabilité et garantie de traitement !

image

Les concepts clés

Pour bien comprendre Storm, il faut en saisir les concepts de base.

  • Le Tuple : Nous en avons parlé, il s’agit de l’unité d’information à traiter. C’est l’évènement.
  • Le Stream : c’est une séquence illimitée de tuples.
  • Le Spout : C’est un connecteur producteur de tuples. En pratiques, ce sont des composants source de données. Il en existe de nombreux types (dans le projet officiel et en dehors) pour se connecter à différentes infrastructures.
  • Le Bolt : Il s’agit du composant de traitement élémentaire. Il consomme bien entendu des tupples et peut en produire (mais pas obligatoirement). Il peut aussi se connecter à une base de données, par exemple.
  • La Topologie : il s’agit de la structure de déploiement de votre configuration Storm. Dans la pratique, il s’agit d’un graphe acyclique (DAG).
  • Groupements de streams : Si les bolts peuvent « splitter » des streams (façon CBR) ou les multicaster, ils peuvent aussi les regrouper. Il existe 7 types de regroupements.

Le parallélisme est intrinsèque à Storm. Chaque Bolt peut être instancié plusieurs fois (on les appellent « task »). Chaque tâche est prise en charge par un Executor qui correspond dans la pratique à un thread. Storm prend en charge la répartition des Executors sur des Workers (qui correspondent à une JVM). Chaque Worker devant être géré par un Supervisor. Ce dernier point est important, car les Workers peuvent tomber ! Un petit dessin vaut parfois mieux qu’un long discours…

image

Pour gérer et faire tourner l’ensemble, Storm met à notre disposition 3 briques importantes :

  • Le Supervisor : nous en avons parlé, il gère un Worker, le relançant si nécessaire, et permet de surveiller sa charge.
  • Zookeeper, qui a en charge de gérer une topologie
  • Nimbus, qui gère les masters des topologies. Il doit lui-même tourner sous supervision.

Traiter en toute quiétude

Les graphes de traitement de Storm peuvent devenir des arbres très complexes ! Toutefois Storm s’y entend pour reconnaitre si un Tuple entrant a été traité sur la totalité de son arbre. Tout d’abord chaque Tuple a son id (sur 64 bits). Nathan Marz a développé un algorithme très complexe, basé sur le XOR pour identifier si un arbre a été complètement traité. Bien entendu, chaque Bolt opère son acquittement local, c’est le « Ack ».

image

Florian passe rapidement sur Trident qui permet d’assurer une sémantique « exactement 1 » aux traitements. J’avoue que le sujet est passé trop rapidement pour moi. Peut-être une occasion de creuser le sujet ultérieurement ? Il en va de même pour la fonctionnalité DRPC.

Si vous avez raté le live et que ma prose vous laisse de marbre, voici l’enregistrement de l’intervention de Florian lui-même !

Storm et Redis chez Twitter Foot

Ce retour nous était proposé par Benjamin Houdu. Cette présentation m’intéressait d’autant plus que j’ai participé au début de ce projet. Et je dois dire que ce dont Benjamin nous a gratifié est probablement le meilleur retour d’expérience auquel j’ai pu assister !

Le projet

Comme son nom l’indique, Twitter Foot traite des flux Twitter, suivant des comptes identifiés par l’AFP (7000 comptes sur 5 ligues), pour fabriquer des timelines spécialisées et toute sortes de statistiques, comme des tendances, la détection de viralité ou de popularité.

Techniquement, les particularités de cette mise en oeuvre de Storm repose d’une part sur la connexion Twitter via la streaming API en utilisant le connecteur Hosebird, et d’autre part sur la mise en oeuvre conjointe de Redis, un base NoSQL de type clé-valeur fonctionnant en mémoire. Redis est d’ailleurs très exploité ici, car on en fait un triple usage :

  • Pour bufferiser le flux Twitter et alimenter le stream Storm. Incidemment, cela rend l’architecture plus testable, car les tests peuvent être faits simplement en peuplant Redis, sans connexion à Twitter, avec en prime la maitrise sur les données injectées !
  • Pour sauvegarder les données de référence : aussi bien la topologie que l’on va injecter dans Zookeeper que les comptes sur lesquels on a des abonnements.
  • En frontal, pour exposer les timelines résultantes et les données statistiques !

En pratique, la topologie est constituée de 3 machines abritant chacun un worker, auxquelles il faut rajouter le serveur frontal abritant le serveur Rest qui expose les services ainsi construits.

image

Et bien sûr, il y a le serveur hébergeant Redis !

Justement Redis, qu’est-ce que c’est ?

Nous l’avons dit, il s’agit d’une base NoSQL de type clé-valeur fonctionnant en mémoire. On devinera que ces choix l’orientent vers la performance, ce qui explique les autres choix techniques : elle est écrite en C et est … monothreadée ! Ce dernier choix peut paraitre curieux, mais de fait, il évite de devoir gérer les problèmes de contention. Il se justifie aussi par les excellentes performances de la base dont les requêtes sont non seulement traitées rapidement, mais aussi peu sensibles à l’augmentation de volume : la plupart des fonctions proposées ont des indices de performance en O (Log (n)) !

Parmi les fonctionnalités intéressantes de cette base, on pourra noter dans le désordre :

  • La présence d’une API de type « publish / subscribe » bien pratique entre autre pour le débug !
  • La présence de connecteurs pour un grand nombre de langages.
  • La mise à disposition de structures intelligentes : sorted sets, Z sets, etc. qui permettent non seulement de retrouver un élément, mais de sélectionner un « range » d’éléments. Une fonctionnalité qui s’avérera particulièrement précieuse dans le cas d’utilisation de Twitter Foot !
  • La présence d’un langage de script basé sur Lua qui permet d’écrire l’équivalent de procédures stockées dont l’atomicité d’opération est garantie par l’architecture monothreadée de la base !
  • L’accès en mode interactif en ligne de commande, via redis-cli pour travailler sur la base en mode non programmatique.

Storm, au coeur de Twitter Foot !

Nous n’allons pas revenir sur le descriptif général de Storm que Florian a fort bien abordé. Benjamin attire toutefois notre attention sur les changements importants survenus entre les versions 0.8.x et 0.9.x, la première dépendait fortement de Zero MQ, ce qui n’est plus le cas des versions ultérieures. Il met aussi l’accent sur l’intérêt de Storm UI d’un point de vue opérationnel, surtout pour savoir quel tâche tourne sur quel worker ! En effet, il faudra abandonner l’idée que l’on traite l’affinité des tâches sur les workers / machines, c’est Storm qui gère cela.

En fait, l’un des enseignements que tire Twitter Foot, c’est que l’administration est un volet du projet aussi important que le développement, et il faut y faire face le plus tôt possible dans le projet ! Autre difficulté, la configuration dont les changements imposent des redémarrages de topologies. C’était une contrainte trop forte pour Twitter Foot, aussi l’équipe a-t-elle traité la configuration comme un Stream traversant les Bolts !

Des fenêtres bien glissantes…

Un concept est rapidement apparu sur Twitter Foot : la nécessité de faire des statistiques sur une durée fixe, mais relative au temps présent. Ce que l’on a appelé des « fenêtres glissantes », c’est à dire entre T0 et T-n minutes (ou heures, ou jours), avec un échantillonnage représentant la résolution de ces statistiques en x minutes ! Vous pouvez aussi dire « sliding windows » pour briller dans les salons, mais ne cherchez pas sur Google, c’est un concept maison !

image

Plusieurs essais d’implémentations en ont été faites. Benjamin nous parle de deux d’entre-elles.

Tout d’abord, on peut s’appuyer sur un concept Storm : les Rolling Buffers. Ils sont plutôt complexes à mettre en oeuvre, mais ils présentent entre autre l’avantage de gérer automatiquement l’éviction des échantillons quittant la fenêtre glissante !

Autre possibilité : s’appuyer sur les ZSets de Redis. Redis permet même d’opérer des aggrégations par x minutes et donc de gérer pratiquement automatiquement l’échantillonnage ! Par contre l’éviction des vieux échantillons doit se faire programmatiquement.

Quelques mots sur la testabilité

J’ai été agréablement surpris de voir Benjamin aborder ce point finalement assez déconnecté des problématiques purement techniques de Storm (bien qu’il y ait bien sûr des corolaires techniques). Le projet a en effet mis en oeuvre tôt dans ses premières phases une approche ATDD impliquant le client et s’appuyant sur le paradigme « Given When Then » outillé avec Cucumber JVM. Cette approche a réellement permit une convergence et appréhension fine des fonctionnements attendus.

D’un point de vue technique, il a été possible de se servir de l’alimentation par Redis pour effectuer ces tests déconnecté de Twitter en injectant dans Redis des Tweets « forgés ». Autre point délicat, la nécessité de ne pas redémarrer la topologie entre chaque tests afin de garder des temps d’exécution raisonnables.

Et le monitoring ?

Nous l’avons dit, avec Storm on fait beaucoup d’administration, ce qui a quelques implications.

D’abord, plus encore qu’ailleurs, les opérations réalisées fréquemment doivent être en « push button ». Jenkins est d’une aide appréciable à ce niveau.

Le Storm Supervisor : il est indispensable, et il en faut un par machine.

L’équipe a aussi utilisé avec bénéfice Monit, un watchdog qui s’est avéré d’une grande utilité. Notre orateur est dithyrambique à ce sujet !

Du côté de Redis, c’est redis-rdb-tools qui s’est avéré indispensable. Le gros avantage est le parse des logs offline, donc sans impacter la machine de production. Dans la pratique, beaucoup d’investigations peuvent être menées à bien en différé.

Si on a réellement besoin de connaitre l’état de santé de l’instance en live, il y a … Redis Live !

Quelques mots sur le débug et les best practices

L’investigation de problèmes sur une architecture Storm peut très facilement se transformer en chemin de croix ! Il faut anticiper cela au niveau de la conception et penser les Bolts avec des responsabilités bien séparées (principe SRP de Bob Martin). En fait, Benjamin nous suggère de séparer les Bolts de contrôle des Bolts d’action !

Même chose sur Redis : bien séparer les actions d’insertion des actions de nettoyage.

Enfin, même les topologies peuvent être décomposées, une leçon qui est arrivée hélas bien tardivement sur Twitter Foot ! De plus petites topologies se testent plus facilement et sont plus robustes. Mais attention, ne pensez pas mutualiser les workers : un worker ne peut appartenir qu’à une topologie.

Autre problème bien connu, celui de l’auditabilité : comment retrouver l’origine du problème ? L’équipe Twitter Foot nous propose la technique du « Carbon dating » : injecter dans les Tuples des informations de trace des Bolts traversés !

Du côté Redis enfin, si l’aspect « sans schéma » est apparemment une liberté bienvenue, on touche vite les limites de ce manque de typage. Ici, c’est l’emploi de json-schema que vient nous recommander l’équipe.

Si vous préféreez la présentation de benjamin in extenso, ne pleurez plus, la voici !

Ce que j’en ai pensé

Je l’ai dit au début : l’orateur nous a gratifié là d’un retour d’expérience d’un niveau de qualité que j’ai rarement (jamais ?) vu !

La mise en oeuvre d’un projet avec Storm est réellement quelque chose de complexe. On perçoit cette impression rapidement, mais les dimensions de cette complexité apparaissent clairement dans cette présentation !

Mais on va plus loin ici : les voies à explorer, les points d’attention dans le projet, les outils indispensables et leur utilité, tout nous est clairement exposé. Un grand bravo !

Neo4J contre SAP Hana

Il y avait un petit moment que l’on n’avait pas eu de meetup Neo4J sur Paris ! C’est donc avec une façon un peu provocante d’aborder un sujet à connotation BI que nous avons été invités !

Nous étions environ 30 à nous rendre ainsi dans le showroom Zenika.

image

Introduction

Cédric Fauvet, toujours égal à lui-même nous fait son habituelle introduction sur les graphes. Presque habituelle, devrais-je dire, car il fait un peu évoluer son propos de meetup en meetup, tout comme son support.

image

Aujourd’hui, le spectre des problèmes couverts par les bases orientées graphes couvre :

  • La collaboration
  • Le SCM
  • L’analyse géo-spatiale
  • L’étude des interactions moléculaires
  • L’analyse d’impact
  • Le MDM
  • La gestion de lignes-produit
  • Et bien entendu la recommandation et les liens sociaux !

En Juin, Neo4J France devrait nous gratifier d’une présentation d’un projet « Dropbox-like » réalisé par des étudiants !

Cédric attire également notre attention sur le talk de Volker Pacher expliquant pourquoi Neo4J augmentait la capacité de delivery de Shutl (acquis depuis par eBay).

Il est l’heure de la pause pizza, nous allons bientôt attaquer la pièce maîtresse de la soirée !

image

Analyse des tickets de caisse avec Neo4J

Nicolas Mervaillies et Charles Besselièvre nous présentent le projet qu’ils ont développé pour « un grand client retail ». Il s’agit d’un petit projet, c’est à dire moins de 100 j/h, qui devait être développé rapidement. Sur les projets analytiques orientés « real time », cette enseigne s’appuie généralement sur SAP Hana. Mais ce projet tactique présente des échéances de temps incompatibles avec ce type de projet, plus adapté à des solutions légères menées en agile.

image

La problématique est essentiellement simple : trouver des corrélations d’achats. Vous savez, celles qui ont permit de déterminer que les couches culottes sont souvent achetées en même temps que le bière le samedi ou qui ont permit à une enseigne d’apprendre via des bons d’achat à une jeune fille qu’elle était enceinte avant qu’elle même ne le sache ! Ici les corrélations doivent être croisées entre magasins et entre régions. Pour chaque magasin, il faut compter une volumétrie de 300 millions de lignes de ticket par an.

Phase 0 : Prototypage

Pour cela on utilise simplement la console Neo4J ! En fait, on ne représente pas chaque ligne d’achat en liaison avec le ticket de caisse : on agrège ces lignes par sous-familles. Bien sûr, les tickets sont associés à une date, un client et un magasin.

Grâce à cela, on voit avec Cypher si l’on parvient à produire les analyses que l’on souhaite.

Phase 1 : Construction initiale

Premier fonctionnement en production : les données de ticket de caisse sont récupérés tous les mois et injectés avec Spring Batch. Le client peut agréger les données en live via des requêtes Cypher : dans le temps, par famille de produits, par magasin.

Les couplages repérés avec de forts pourcentages sont donc mis en exergue dans certains magasins, on compare les éléments différenciants des magasins ayant de moins bons taux de corrélation !

On a toutefois un problème : trop de lenteurs, dû aux fortes volumétries, mais aussi au déploiement de Neo4J sur des serveurs virtualisés. La virtualisation et les bases de données, ce n’est pas le grand amour, même si certains ingénieurs système essaient de se convaincre du contraire !

Phase 2 : Focus sur le « top 15 »

En analysant les données des différents magasins, on perçoit dans le temps des réccurrences d’association, notamment dans le « top 15 ». Nos artistes choisissent donc de précalculer les associations significatives, celles correspondant au « top 50 » de chaque magasin, mais sans Marc Toesca !

Phase 3 : Optimisation de production

En dernière phase, il faut finalement réaliser des optimisations purement de production : gestion de l’infrastructure, mise en place de cache, etc…

En conclusion…

L’utilisation de Neo4J est parfaitement adaptée à ce type de projet tactique : on a la rapidité de de mise en place et la vitesse d’exécution de ce projet typique d’un projet agile ! Par rapport à SAP Hana, on gagne réellement en time to market !

L’équipe a aussi développé un front-end pour faciliter l’utilisation du système. Mais à la limite, cela aurait pu être omis !

Concernant l’infra : elle a été gérée complètement en interne pour des raisons de non exposition de données sensibles. Toutefois, on a une machine puissante qui ne sert que quelques heures, une fois par mois ! Ce type de configuration se marrie donc bien avec le Cloud.

Enfin, l’aspect communautaire de Neo4J permettant de trouver de l’aide sur les forum a été un plus important !

Faute de disposer du support de présentation, je vous propose ici l’enregistrement de la même session qui s’est déroulée au meetup Neo4J Lillois !

Ce que j’en ai pensé

C’est probablement le meetup Neo4J le plus interactif et le plus convivial auquel j’ai pu assister. Les interventions fort pertinentes d’un connaisseur SAP Hana ont été un gros plus dans la discussion, surtout quand, comme lui, on connait et sait reconnaitre les qualités de ce système. Il est là, juste derrière moi.

Pour clore ce compte-rendu et donner un avis éclairé sur cette confrontation, je le citerai :

« Remplaçons notre argent par notre intelligence ».

Cela me rappelle un peu un slogan des années 70 où il était question de pétrole…

… Et Neo4J devint CMS !

Lors de ce Meetup Neo4J de Janvier, toujours dans le zLocalHost de Zenika, nous avons pu découvrir Structr, et comment il adresse la problématique du CMS. Ou du moins, nous allons le faire.

Cédric Fauvet au pas de charge !

Cédric commence par sa très classique introduction à Neo4J. Introduction un peu écourtée d’ailleurs : c’était la soirée des problèmes techniques et il a fallu rattraper le temps perdu.

Le temps tout de même de donner quelques nouvelles de la communauté et de l’actualité. On s’attardera quelques instants sur la dernière référence Française : Meetic ! Bien entendu, comme pour Viadeo, le but est la recherche d’adéquation de profiles. Ce n’est d’ailleurs pas une première expérience pour Neo4J qui a équipé d’autres sites de rencontre avant de s’occuper du n°1 européen.

Autre nouvelle intéressante : la mise à disposition de cours en ligne ! J’ai hâte d’aller voir ça…

Structr

Axel Morgner est fondateur de Structr, il est venu spécialement de Frankfort pour évoquer son usage de Neo4J. Après avoir longtemps travaillé dans le domaine du CMS, il a décidé de changer d’horizon, de faire autre chose. Il a découvert Neo4J, et a décidé de construire avec … un CMS !

image

Structr c’est une société mais aussi un logiciel open-source. La motivation ? Construire des sites web dynamiques avec du contenu. La première release de la bête est apparue en 2011.

La première itération : c’est une classique webapp standalone, dont la partie front utilise freemarker.

Les choses changent radicalement en seconde itération ! C’est d’abord un changement de scope : Structr devient un pur back-end, le front-end est abandonné ! Le produit assure un mapping bidirectionnel entre JSON et le graphe. Et le produit intègre une notion de schéma et de contraintes (avec même une gestion des suppressions en cascade), des choses qui vont bien plus loin que les évolutions apportées par Neo4J 2.0 !

L’interface utilisateur revient en 3ème itération, mais elle s’est faite HTML5 ! Elle permet l’édition sur place, la visualisation des liens entre pages, etc…

Démo time !

Axel nous fait bien sûr une petite visite guidée de la bête. On commence fièrement par un import de page que l’outil digère pour le transformer en graphe. On peut utiliser alors l’édition sur place pour importer ou saisir du contenue … ou faire référence à du contenu dans le graphe, via des requêtes Cypher, par exemple !

image

La sécurité n’est pas en reste et elle se configure sur les noeuds. Elle est bien sûr transitive, suivant les liens “contains”. L’IHM est aussi synchronisée entre les clients, permettant l’édition de contenu collaboratif.
Mais tout cela, c’est du statique. Du “boring stuff” comme le dit Axel. Structr gère la dynamicité du contenu, en partie du fait qu’il ne gère pas de cache et se repose sur la performance de neo4J. L’une des clés est la référence qui peut être faite depuis les pages vers du contenu structuré lui-même dans le graphe.

Pour cela il faut créer un projet “data type”. C’est lui qui permet la structuration des données et les contraintes dont nous avons parlé plus haut. On y crée aussi des bindings qui peuvent être référencés par des noms symboliques.

L’une des question que je me posais pendant que la démo se déroulait concernait les contenu volumineux, de type “blob”. On sait que Neo4J n’est pas fait pour cela. Qu’a cela ne tienne, les data types peuvent référencer des fichiers ou même des répertoires ! Au-delà de cela, il y a aussi des concepts de “web components” et de “shared components area”, mais ne m’en demandez pas plus, car j’ai un peu perdu le fil à ce moment là !

Malgré quelques petits accrocs lors de la démo, il faut avouer que cette gestion de contenu est pour le moins étonnante et résolument différente de ce qui se fait !

Teasing

Cédric souhaitait innover en donnant une minute de parole au débotté à des participants du Meetup ayant un projet avec Neo4J.

Un étudiant de Supinfo Lille (désolé, je n’ai pas noté son nom) nous a donc parlé de son projet d’étude : un “Dropbox like” intégrant une dimension sociale de partage. L’utilisation de Neo4J permet ici de représenter les structures de fichiers, répertoires, partages et droits, tandis que les contenus eux-même peuvent être répartis sur différents serveurs de stockages, ces contenus étant simplement référencés dans le graphe.

Quand Sébastien Just est venu nous parler de Seij, j’ai cru que Structr venait de trouver son frère jumeau ! J’ai pu discuter un peu avec Sébastien et suis maintenant convaincu que ce n’est pas le cas. Certes les deux applications partagent nombre de concepts : le CMS basé sur des graphes Neo4J et la possibilité de constituer son contenu en assemblant les éléments issus des noeuds. Mais là où Structr s’appuie sur une structuration et un typage fort, Seij s’enorgueillis de son approche “free form”, un peu comme si l’on avait un Excel pour la gestion de contenu. Des concepts très proches mais un ciblage client très différents en font deux produits qui ne se comparent finalement pas. J’espère que Sébastien aura l’occasion de revenir nous le présenter et nous en parler !

Meetup Neo4J de décembre 2013 : Des recommandations en temps réel avec Recolytic

Ce sont deux sujets qui seront abordés lors de ce meetup. En effet, en introduction à la présentation de Rochdi Chakroun, Cédric Fauvet a évoqué le concours GraphGist, concours où il y a peu à gagner. Mais ce n’est pas l’objectif. Ici, il s’agit plutôt de monter de petits cas d’utilisation originaux. Neo4J souhaite visiblement pouvoir montrer beaucoup de cas d’utilisation créatifs et variés de sa base de données.

Cédric Fauvet débute généralement ces rencontres par une présentation de la société, des cas d’usage de Neo4… Celle-ci ne fit pas exception.

image

Bien sûr il nous présente les mêmes concepts, les même cas d’utilisation ou presque, mais le propos évolue quand même un peu à chaque fois. Et de plus, il y avait aujourd’hui Neo4J 2.0 à évoquer ! Il n’y a rien non plus de rébarbatif dans sa façon de présenter les choses. Après tout, avant d’être responsable de Neo4J France, Cédric était un développeur comme nous !

Mais avant de passer à la suite : Pizza time !

image

Recolytic

Rochdi Chakroun est architecte logiciel chez Vente Privée. Mais ce n’est pas à ce titre qu’il venait aujourd’hui, mais plutôt pour présenter le fruit d’un projet personnel : Recolytic.

image

Le constat de Rochdi est que les systèmes de recommandation sont aujourd’hui obscures : "nous allons faire progresser votre chiffre d’affaire, vous n’avez pas à savoir comment". Une position qu’il juge insupportable au regard de l’aspect stratégique de ce traitement.

Autre aspect que l’orateur a voulu adresser : la recommandation en temps réel. Les moteurs de recommandation s’appuient sur la plupart sur des algorithmes et des traitements de machine learning qui demandent de longs temps de traitement en différé pour fournir de nouveaux modèles mis à jour.

Recolytic se veut performant, facile à intégrer et transparent sur la stratégie. Il s’appuie bien sûr sur Neo4J, ici le modèle c’est le graphe. Et ce graphe est composé de triplets utilisateur – action -ressource. Il est à noter que Rocolytic est complètement agnostique sur la nature des ressources. Des poids peuvent être accorder aux actions ou aux ressources, par exemple pour donner plus d’importance à un achat par rapport à une consultation.

Pour ce qui est des APIs, Rocolytic en propose 3 catégories :

  1. Les API de collecte : pour récupérer les actions des utilisateurs.
  2. Les APi de recommandation. Elles permettent plusieurs stratégies.
  3. Les API de mesure. Afin de mesurer après coup la pertinence de recommandations et ajuster le paramétrage en conséquence.

A l’initialisation de Recolytic, on débute sans informations de l’utilisateur. Il est donc pertinent de commencer avec la stratégie par défaut : les plus populaires.

Il sera ensuite possible de basculer vers une autre stratégie, par exemple la similarité de panier.

Pour démontrer le produit, Rochdi nous propose de nous promener dans un site d’e-commerce de démonstration.
Rochdi ne s’est pas encore fixé d’objectif pour les prochaines étapes : en faire un open-source, ou une startup… Il avoue surtout avoir besoin de récupérer de ses efforts. On le comprend : il a quand même réalisé tout cela en gardant son activité chez Vente Privée !

En Janvier, nous rencontrerons un autre cas d’utilisation avec Structr.

Neo4J et Spring Data, avec Florent Biville

Ce premier Octobre, Zenika accueillait de nouveau le groupe Meetup dédié à Neo4J. L’occasion de faire connaissance avec Spring Data grâce à Florent Biville.

Echauffement

Débuter un Meetup par l’interlude commercial, ce n’est pas nécessairement le meilleurs départ. Mais Cédric Fauvet connait au moins le public auquel il a à faire et il fut lui-même développeur. En fait, il a même évoqué deux ou 3 choses qui ont piqué ma curiosité !

Meetup Neo4J Octobre 2013

La première réelle application de la théorie des graphes semble être celle des 7 ponts de Königsberg. Le seigneur du coin voulait savoir s’il était possible de faire un trajet dans la ville en passant une fois et une seule par chaque pont. Ce n’est pas possible et l’on peut s’en rendre compte de manière empirique, mais c’est Leonhard Euler qui le démontra mathématiquement.

Les 7 ponts de Königsberg

Il n’y avait pas Neo4J à l’époque, mais aujourd’hui on en dispose et on résoud avec d’autres problèmes ayant trait à la théorie des graphes:

  • Bien sûr il y a déjà le cas classique des réseaux sociaux, comme les suggestions de contacts utilisés par Viadeo.
  • Les analyses d’impact sur les réseaux, mis en oeuvre chez SFR.
  • Les calculs de primes de commerciaux, chez Sisco (!) Il ne faut pas moins de 2 clusters pou gérer cela.
  • Le routage des colis chez un grand opérateur en Allemagne.

Aujourd’hui la communauté Française semble se porter plutôt bien, elle compte 362 personnes inscrites sur le Meetup et un nouveau Meetup va démarrer sur Lyon.
Du point de vue de l’actualité, c’est la version 2.0 qui occupe le terrain et doit être le sujet principal de Graph Connect.

Après le pizza-break, place au sujet principale de la soirée.

Spring Data

Nous sommes face à un dilemme aujourd’hui : le monde devient de plus en plus dynamique, ce qui fait la part belle à des bases de données orientées graphe telle que Neo4J. Et pas seulement cette dernière d’ailleurs, mais aussi des solution empruntant le même paradigme:

  • Flock DB, une solution construite par Twitter.
  • Titan, une base de données orientée graphes distribuée.
  • Blueprint, qui est plutôt une abstraction au-dessus des bases de données graphe, mais aussi une stock logicielle offrant des fonctionnalités de plus haut niveau.
  • RDF, l’ancêtre de ces bases de données, qui est une normalisation par le W3C des représentations de données sous forme de triplets.
  • Orient DB qui mixte des fonctionnalités d’une base orientée documents avec une base orientée graphes.
  • InfiniteGraph

Un dilemme disais-je, car si ces solutions adaptées aux problèmes actuels se développent, l’entreprise reste, elle, conservatrice. Elle continue de s’appuyer majoritairement sur les bases de données relationnelles et donc sur les ORM pour assurer la jonction avec le code applicatif.

Meetup Neo4J Octobre 2013

Ces solutions ORM, tel que le standard JPA ne semblent pas poser de problème dans la plupart des cas, pourtant on fait rapidement face à “l’abstraction leak”, à savoir que les paradigmes fondamentaux des SGBDR et des applications sont différents et les ORM tentent de le masquer.

Les bases de données graphe offrent un mapping plus simple et plus naturel. Elles permettent en outre de satisfaire d’autres besoins :

  • L’hétérogénéité des propriétés associées aux noeuds.
  • L’absence de schéma prédéfini. Sur le papier, c’est un problème car il permet une discordance des donnés par rapport à l’intention de structuration. Mais avec Neo4J 2.0 le schéma existe de manière optionnelle.

Il y a-t-il un intérêt à proposer un mapping objet des bases orientées graphe ? Oui, si il offre une réelle simplification et des fonctionnalités intéressantes.

Hibernate OGM, une première approche

Hibernate OGM offre une approche inspirée de l’ORM qui ne convainc pas Florent. D’une part, à l’instant de JPA elle offre le plus petit dénominateur commun des bases orientées graphes, et l’idée de faire entrer toutes les bases de données NoSQL (pas seulement les bases orientées graphes) dans un même moule semble pour le moins un gros challenge…

Tinkerpop Frames

Cette solution se focalise également sur la construction d’une abstraction des bases orientées graphes (et seulement celles-ci). Elle propose son propre langage de requête, Gremlin. Las aujourd’hui le langage de requête de Neo4J, Cypher est l’un des atouts important du produit et de gros efforts sont consentis pour en améliorer les fonctionnalités. On se retrouve donc dans une course à la fonctionnalité… que Gremlin peut difficilement gagner.

Spring Data

Suivant l’idée d’origine de Spring, il s’agit d’une brique très légère. En fait, à l’origine même de ce sous-projet, il y a la rencontre entre Emil Eifrem et Rod Johnson, à savoir respectivement les créateurs de Neo4J et de Spring !

Un atout important de Spring Data est aussi son concept de “multi-store”. Nous avons évoqué la frilosité des entreprises par rapport aux nouveau paradigmes de bases de données. Spring Data adresse cela en permettant des ponts entre différents paradigmes (par exemple relationnel vers graphe) permettant des transitions douces vers ces nouveaux mondes !
D’un point de vue pratique, pour un repository standard, tout ce que l’on a à faire, c’est d’hériter de l’interface GraphRepository<> … et Spring Data s’occupe du reste ! Derrière le rideau, cette interface hérite de quelques autres (je ne vais pas les lister, elles sont sur le slide 31). Derrière le second rideau, au niveau de l’implémentation générée, cela va bien entendu être la “foire aux proxys” ! Bon, comme on dit : on ne peut pas tout avoir !
Spring Data offre d’importantes facilités pour écrire, ou plutôt ne pas écrire, des méthodes de recherches :

  • Des “find”, où la simple convention de hommage va permettre de connaitre les critères de recherche en les mappant sur les paramètres.
  • Des recherches plus complexes s’appuyant sur des clauses Cypher figurant en annotation @Query de la méthode.

En annotant des classes @NodeEntity, on peut spécifier ce qui est persisté et ce qui ne l’est pas, ce qui constitue des arcs, et bien d’autres choses encore !
Les templates Neo4J, à la façon de ce qui existe pour d’autres modules Spring, permettent d’opérer des requêtes de projection en éliminant la plomberie inhérente à l’utilisation brute de la base.

Spring Data offre de nombreuses fonctionnalités supplémentaires, comprenant bien entendu les famaux “cross store storage” que nous avons évoqué au début.

Pour conclure
Une soirée instructive sur les possibilités de Spring Data, bien que j’ai regretté que cela aille un peu vite sur les NodeEntity et que l’on ne s’arrête guère sur les stores multiples, car cela me parait un point clé pour Neo4J en entreprise, bien plus que l’économie de code que permet le framework !
Par ailleurs Florent a initié une série d’articles très bien écrits pour s’initier à Neo4J : le premier de la série est ici.

Purely awesome – Chess Games and Neo4j

nosql:

I wasn’t able to follow the post. I got myself lost into the superb presentation built for it. Chess game replays. Dynamic graphs. Pure awesomeness.

This is by far the most entertaining blog entry presentation I’ve seen since I’ve start reading and writing about NoSQL.

standingovation

Original title and link: Purely awesome – Chess Games and Neo4j (NoSQL database©myNoSQL)

Cedric Fauvet évoquait justement ce cas d’usage de Neo4J lors du meetup de mardi. Voici a chose mise en musique, hélas seuls les vrais amateurs d’échec sauront vraiment apprécier la chose, ce qui n’est pas non plus mon cas. Comme l’auteur du post, je me suis simplement laissé hypnotiser par ce très beau replay…

Purely awesome – Chess Games and Neo4j

Note de lecture : NoSQL Distilled, par Pramod J. Sadalage & Martin Fowler

Note : 4 ; Plus qu’une distillation, une introduction légèrement frustrante.

Dans la même veine que le « UML distilled », Martin Fowler accompagné d’un de ses collègues de Thoughtwork nous produit un ouvrage très court (moins de 160 pages !) destiné à nous faire découvrir et à nous donner les clés du monde NoSQL ou plutôt de cet écosystème. Pour donner un bon rythme au texte, cet opuscule est découpé en 15 chapitres, ce qui fait une moyenne de 10 pages par chapitre.

On commence par un petit historique sur l’avènement du mouvement NoSQL. Pas indispensable, mais sympathique et bien écrit. Les chapitres 2 et 3 abordent la problématique du modèle de données, de l’intérêt de considérer des agrégats de données, mais aussi la souplesse qu’apporte des bases de données sans schéma … avec le corollaire d’avoir une base de données propriétaire de l’application sachant l’interpréter.

Trois chapitres sont consacrés aux principes sous-jacents de ces bases de données. Le chapitre 4 passe rapidement sur le modèle de distribution. Le chapitre 5 passe moins rapidement sur la gestion de la consistance (vous savez, le fameux « eventually consistent »). En fait, il est même passablement ennuyeux. Enfin le chapitre 6 évoque en quelques pages la question de l’estampillage des versions dans un environnement clusterisé actif / actif.

Difficile, impossible même, d’évoquer les bases NoSQL sans parler du « map reduce ». C’est ce que fait le chapitre 7, bien mais pas aussi brillamment que je me serais attendu de la part de Martin Fowler.

Le cœur du livre est sans contestations possible occupé par les quatre chapitres suivants qui forment le début de la troisième partie. Chacun d’entre eux traite d’un type de base NoSQL.

Le chapitre 8 aborde les bases de données clé-valeur, en prenant comme exemple Riak. Les auteurs ont pensé que 6 pages suffisaient pour s’occuper de cela. Moi j’ai trouvé cela franchement léger.

Les bases de données « orienté document » ont à peine droit à un meilleur traitement au chapitre 9. C’est MongoDB qui fort logiquement a été choisi, le sujet étant traité en 9 pages. Malgré tout, cela me laisse un meilleur goût tout en étant un poil superficiel.

10 pages à peine pour évoquer les bases de données orientées colonnes, c’est un peu un challenge car le sujet n’est pas simple, ou plutôt le paradigme est tellement différent de ce que nous connaissons qu’il aurait mérité plus d’attention que ce que lui accorde ce chapitre 10. J’en sors un peu confus et convaincu que j’ai besoin d’un complément d’information sur la question.

Si différentes des autres types, les bases de données orientées graphe telles que Neo4J qui sert ici d’exemple m’apparaissent clairement abordées dans ce chapitre 11, même si c’est seulement sur 10 pages. En fait ce livre m’incite à me pencher plus avant sur cette base de données et ce que je fais en ce moment ! Ne serait-ce que pour cela : merci !

Le chapitre 12 sur la migration de schéma de données est une blague. Il n’était pas franchement utile, loin de là. On reconnaît l’insertion au chausse-pied du sujet favori de Pramod Sadalage. De ce sujet et de quelques autres, je me serais bien passé au profit d’un développement plus conséquent des 4 chapitres les plus importants du livre !

La persistance polyglotte est un sujet déjà abordé en début de livre. Sans être ennuyeux, les 7 pages de ce chapitre 13 semblent passer une seconde couche.

J’aime bien l’idée d’un chapitre « beyond NoSQL » mais les auteurs n’ont pas tant à dire dans ce chapitre 14. Dommage. Finir par un chapitre sur le choix du type de base NoSQL est une bonne idée. Mai ce n’est visiblement pas si facile à faire, car cela sonne un peu creux.

Qui aime bien châtie bien. Et Martin Fowler d’habitude très brillant dans l’exercice ne convainc pas dans celui-ci. Il prends un « 4 » là où j’aurais certainement noté 5 pour quelqu’un d’autre. Le livre reste fidèle à l’idée de brièveté, mais le contenu est fort mal réparti : trop de place est accordée à des sujets peu importants ou qui pourraient être mieux synthétisés, alors que la partie importante de l’ouvrage aurait dû bénéficier d’un meilleur traitement sur deux ou trois fois plus d’espace !

C’est un livre qui pourra être utile au manager, car il traite, ou plutôt balaye le sujet dans un volume qui peut être absorbé en un week-end et permet de savoir de quoi on parle. Pour ma part, je me sens quelque peu frustré, et je pense que je vais me tourner vers le « seven databases in seven weeks » paru chez Pargamatic Bookshelf !

nosql-distilled

Référence complète : NoSQL Distilled, a brief guide to the emerging world of polyglot persistence – Pramod J. Sadalage & Martin Fowler – Addison Wesley 2012 – ISBN : 978 0 321 82662 6

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence

http://www.goodreads.com/book/add_to_books_widget_frame/0321826620?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on