[Livre] « Storm Real-time Processing Cookbook »

Storm permet de faire du traitement à la volée (stream processing) de façon distribuée et tolérante à la panne. D’une certaine façon, c’est la contrepartie à Hadoop MapReduce qui ne gère que du batch. Ce projet fut rendu open source fin 2011 et un écosystème commence à se former autour de celui-ci. Packt a publié un livre  « Storm Real-time Processing Cookbook » destiné à démocratiser les recettes d’utilisation. Si vous cherchez un cookbook pour intégrer rapidement Storm au sein d’une véritable architecture, c’est un livre à considérer. Le détail de la revue est dans la suite du post. Et les plus rapides d’entre vous pourront potentiellement gagner une copie gratuite.

La plus grande critique que l’on peut faire des "livres de recettes" (cookbook) est que certains ne fournissent que des exemples pour expliquer l’utilisation d’un outil pour lequel la documentation et la communauté sont insuffisantes pour pouvoir démarrer tout seul. Cela pose en conséquence de nombreux problèmes. Comment savoir si les exemples sont toujours valides à cause de l’évolution de l’API non documentée ? Où chercher des informations supplémentaires ? Est-ce qu’il est même utile de s’intéresser à un outil dont le futur reste très incertain ?

Storm n’est pas un projet qui vient juste de sortir, la documentation est suffisante en soi et cette platforme est déjà utilisée par de nombreuses entreprises en production, comme Twitter, Yahoo! ou Groupon. Nathan Marz, à l’origine de Storm, explique même comment l’expérience de la production chez Twitter a conduit à solidifier cette solution (la présentation est disponible grâce sur InfoQ.) Bref, écrire un tel cookbook seulement sur Storm serait bien inutile. Et l’auteur, Quinton Anderson, le reconnait.

Ce cookbook possède une approche différente. La valeur de "Storm Real-time Processing Cookbook" repose sur l’expérience de son auteur. Il explique comment mettre en place Storm concrètement, en tant que brique dans une solution plus générale. Ainsi le livre aborde :

• la qualité des applications en écrivant
  • des tests unitaires, avec des mocks (JMock)
  • des tests d’intégration
• l’utilisation du bon niveau d’abstraction
  • soit l’API de base, disponible depuis le début du projet
  • soit Trident, qui est à Storm, ce qu’est Cascading à Hadoop MapReduce
• la sauvegarde d’information, avant lecture ou après traitement, par
  • Kafka, un système de message (pusblish/subscribe) distribué
  • Redis, une base clef-valeur
  • Cassandra, une base orienté colonne
  • HDFS, le système de fichier d’Hadoop
• le déploiement continue grâce à
  • Vagrant, pour créer des VMs
  • Puppet, pour les configurer 
  • VirtualBox, pour les charger
  • Pallet, pour créer un cluster Storm depuis 0 
  • AWS, pour reserver des machines
• la mise en place d’une architecture à double vitesse décrite par Nathan Marz
  • Storm pour le temps réel
  • Hadoop MapReduce pour les batchs, par le biais de Cascalog
• l’utilisation de machine learning
  • Storm-Pattern, un port de Pattern pour Storm, reposant également sur l’utilisation de PMML
  • Storm-R, pour utiliser R si jamais l’algorithme n’a pas été porté
  • Trident-ML, pour faire de l’apprentissage en ligne

Toutes ces technologies sont utilisées en suivant une approche orientée recette. Tout le code est disponible et le livre ne duplique pas la documentation de tous ces projets. Les liens vers les éléments importants à comprendre sont fournis. Le livre est bien un cookbook. Il ne s’attarde pas à expliquer tous les concepts manipulés mais montre bien comment, par le code, ces différentes technologies peuvent être utilisées ensemble. Ainsi, si vous cherchez un livre expliquant tout pas à pas, ce n’est pas le livre à choisir. Vous serez déçu. Par contre, si vous cherchez à mettre en place rapidement ces technologies, ce livre vous fournit bien les éléments de base. A vous ensuite de creuser les documentations pour approfondir les concepts et valider ou infirmer les approches choisies. Le point fort du livre est justement le nombre de technologies abordées. Le chapitre traitant du machine learning est également intéressant par son utilisation des différentes librairies.

Sur la forme, il y a un point négatif. Le code java est mal formaté. A priori, le formateur s’attend à des fonctions et donc la première ligne est toujours en retrait. Malheureusement, c’est aussi le cas lorsqu’il s’agit d’un extrait de code qui n’est pas une fonction…. Dans une certaine mesure, ce n’est pas grave car le mieux est de suivre le livre en téléchargeant les sources et en les visualisant avec un éditeur équipé de coloration syntaxique. Mais tout de même, pour un cookbook, avoir du code mal formaté est un mauvais signe, même si le contenu est intéressant. Ce point a été pris en compte par Packt et devrait être corrigé bientôt.

Une copie gratuite?

Packt, l’éditeur, s’est proposé d’offrir deux copies électroniques aux deux gagnants d’un petit concours informel. Les réponses à ce post seront considérées comme réponses à ce challenge. L’ordre d’affichage indiquera l’ordre d’arrivée des réponses. Afin que le gagnant puisse recevoir la copie, il nous faudra communiquer à Packt son nom, son prénom et son adresse email. Ainsi pour que votre réponse soit considérée, il faut avoir rempli ces deux champs et écrit clairement que vous nous autorisez à transmettre ces informations à Packt. En effet, les adresses email ne sont jamais transmises à des tiers, ceci est une exception et nécessite votre accord. Bien sûr, votre adresse email n’apparaîtra pas sur le blog.

Question : Quels sont dans l’ordre les deux langages les plus utilisés pour implémenter Storm?

Note : Les statistiques publiques fournies par Github pour ce projet serviront de référence pour la solution.

Note finale

Afin d’être entièrement transparent, je tiens à préciser que pour cette revue de "Storm Real-time Processing Cookbook", une copie électronique me fut offerte par Packt. Il s’agit cependant de la seule relation entre Packt et moi ou Xebia. L’avis exprimé par ce post, comme tous les autres sur ce blog, est strictement personnel.