Note : 7 ; Data Streaming Distiled !

Le livre est réellement une bonne surprise. Il attaque la question du streaming par l’architecture. L’auteur a son opinion sur la question et nous propose sa vision de celle-ci dès son chapitre d’introduction. Les composants de cette architecture formeront la trame de la première partie du texte.

Passé le chapitre d’introduction sur l’architecture générale, le second chapitre adresse le volet « ingestion ». La bonne surprise est de voir l’auteur l’aborder sous l’angle des patterns avec leurs avantages te leurs faiblesses plutôt que de plonger dans des considérations techniques. Au-dessus de cela le texte s’arrête également sur la tolérance aux pannes avec d’autres patterns de gestion de logging précieux et clairement expliqués.

C’est au data pipeline, donc au Queuing que s’intéresse le chapitre 3, en commençant par exposer son utilité face aux variation de production et au besoin d’élasticité du scaling. Les 3 sémantiques de gestion de message sont bien adressées. J’ai cependant trouvé que le propos reprenait des éléments vraiment très élémentaires mais ne rentrait pas des problématiques telles que la sécurité (l’auteur nous renvoie vers un ouvrage de référence). Là encore les problématiques de tolérance aux pannes spécifiques à cette couche sont bien détaillées.

Lire la suite →

Note : 4 ; Une lecture ardue sur un sujet non moins difficile.

Le Big Data en temps réel ou au fil de l’eau est la grande tendance depuis 2016. Et si Storm a ouvert le bal, la grande vedette est aujourd’hui Spark. Ce nouveau volume de la série  » in action  » nous propose de faire le tour de Spark et de son écosystème en 14 chapitres totalisant 400 pages !

Spark est un framework Scala. Il fonctionne aussi avec d’autres langages tels quePython, mais avec de nombreuses limitations qui nous conduisent à nous rabattre sur Scala de toute manière ! C’est une petite difficulté, mais elle aurait été moindre si les auteurs n’avaient pas abusé des idiomes tels que le fameux  » _  » ! Autre aspect aussi assez frustrant : les auteurs nous amènent les fonctionnalités via le REPL disponible avec le framework. Mais comment se structure donc un développement avec Spark ? C’est une question à laquelle nous n’avons que peu de réponse ! On apprends juste à se servir des fonctionnalités.

La première partie  » first steps  » couvre une centaine de pages et regroupe 4 chapitres. Le chapitre d’introduction passe assez rapidement sur le map reduce et sur le big data temps réel (comme j’ai déjà quelques idées là-dessus je ne m’en offusque pas), mais fait du très bon travail pour expliquer et illustrer les différents composants de l’écosystème Spark et la manière dont ils s’agencent. Le second chapitre couvre lui deux sujets. Tout d’abord il aborde le setup de Spark ou du moins la distribution proposée par les auteurs sous forme d’un VM Vagrant. Un montage un peu compliqué je dois dire, mais qui doit isoler les problèmes de version de Python par exemple. Il couvre aussi les basiques de la manipulation des RDD. C’est d’ailleurs là que l’on commence à se frotter au REPL Spark…

Lire la suite →

Note : 4 ; Un apprentissage un peu rugueux de la Lambda architecture inventée par l’auteur.

Ce livre était assez attendu, car il faut dire que Nathan Marz est une figure du monde du Big Data, il est l’architecte du framework Storm (entre autre) et l’une des figures de l’architecture de Twitter où il a pu développer le concept de la Lambda Architecture. C’est d’ailleurs ainsi qu’aurait dû s’appeler le livre : Lambda Architecture ! Car il est exclusivement question de cela, le texte était découpé de manière à refléter la progression dans les couches de l’architecture. Les éléments importants de celle-ci ?

• Requête = fonction (toutes les données) ; Ce point de vue, l’auteur ne cesse de le marteler au fil des pages.
• Un système Big Data doit être immutable, c’est le seul moyen de le rendre résistant aux erreurs humaines et aux erreurs de traitement. Un système immutable permet de retraiter les données.
• Le system Big Data est composé d’une « batch layer » qui donne des données juste, mais avec un temps de latence important, et d’une « speed layer » rapide mais donnant potentiellement des informations moins justes.

Lire la suite →