Note : 5 ; Une architecture intéressante rendue difficile d’accès par trop de foisonnement technologique !

Le titre initial de cet ouvrage était « unified log processing ». Et c’est souvent de cela qu’il est question ici. Mais le propos a été quelque peu élargi en cours de route, tout en tournant quand même essentiellement autour des grands bus de messages que sont Kafka et Kinesis. Voyons ce qu’il en est.

Le livre compte près de 300 pages, structurées en 3 parties pour un total de 11 chapitres. La première de ces parties se focalise sur l’aspect Unified Log. C’est la plus conséquente du volume, car elle contribue pour 5 chapitres et noircit près de 115 pages ! Fort classiquement, le premier chapitre introduit quelques grands principes d’architecture de l’event stream, ainsi que des cas d’usage. Tout cela est fort agréablement écrit et très bien illustré. On rentre un peu plus dans le dur au chapitre 2, non pas avec la première partie qui détaille l’event log et la structure d’un évènement (en JSON), mais plutôt par l’illustration de la chose avec Kafka et son installation !

Le 3ème chapitre est assez gourmand. Il nous conduit à écrire notre premier worker Kafka. Cela veut dire aussi mettre en place un environnement de développement avec Vagrant et une architecture comprenant du Zookeeper et tout le toutim. Ce n’est pas très facile à suivre. En fait, on n’a guère le temps de reprendre notre souffle au chapitre 4 qui remet ça, mais avec Kinesis ! Dans son ensemble, le chapitre n’est pas super-agréable à lire : beaucoup de setup AWS (forcément) et de longs listing JSON assez ennuyeux en sont la cause principale. De plus, même si c’est assez logique, le code Kinesis est en Python, ce qui n’est pas ce que je préfère.
Au-delà d’être un chapitre douloureux, le va et vient entre Kafka et Kinesis afin de couvrir beaucoup de terrain est une surcharge technologique qui nuit à l’objectif du livre : nous permettre d’appréhender l’architecture « log unifié ». Cette première partie se conclut sur un chapitre au titre paradoxal : le stateful stream processing. Cela commence de manière fort sympathique avec des concepts tels que les évènements dérivés et le fenêtrage de traitement. C’est plus rugueux en seconde partie de chapitre où les auteurs nous introduisent la suppression de paniers avec Apache Samza, avec le code, l’installation et la configuration qui vont avec…

Lire la suite →

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 →