Note de lecture : The Data Loom, par Stephen Few

Note : 6 ; Aller au fond du « data sense making ».

Stephen Few n’aime pas le terme « Data Scientist ». Il lui préfère le terme « Data sensemaker ». Et pour donner du sens aux données, il faut certes un socle de connaissances, mais aussi et surtout une culture, une démarche et des « soft skills » qui s’avèrent indispensables. C’est de cela qu’il est question dans cet ouvrage, qui est en quelque sorte le « pragmatic programmer » du Data Sensemaker.

L’ouvrage est court : il ne compte que 120 pages découpés en 7 chapitres. Le premier compte une dizaine de pages et sert d’introduction pour aboutir à la notion de sensemaker. Elle n’est pas franchement passionnante, cette introduction. Heureusement, le reste du texte est mieux !

Les deux fondamentaux que nous assène l’auteur sont la pensée critique et la démarche scientifique, sur lesquels le reste du livre est construit. Le second chapitre est dédié à la pensée critique. C’est un chapitre qui fait force référence à Kahneman, mais surtout aux biais cognitifs et autres erreurs et illusions. Chacune d’entre elle est expliquée et souvent illustrée dans le cadre du sensemaking. Un chapitre très solide. Bien sûr, c’est à la démarche scientifique qu’est consacré le chapitre 3. C’est une démarche empirique, basée sur l’infirmation d’hypothèses, la transparence et la relecture de pairs. Une approche qui se décline très bien sur le travail sur la donnée comme le démontre l’auteur.

Lire la suite

Note de lecture : ODMG-93, le standard des bases de données objet, par Rick G. G. Cattell

Note : 6 ; Bourré d’informations, mais dense et difficile d’accès.

Un livre court et dense, qui traite exclusivement des aspects du standard ODMG. Autant dire que le propos apparaîtra des plus secs : détails sur la syntaxe et la sémantique, support des langages, etc…

Court, nous l’avons dit : l’ouvrage ne compte que 170 pages structurées en 6 chapitres et 2 annexes. Le premier d’entre-eux « Aperçu » donne une image beaucoup trop haut niveau du standard pour pouvoir se donner une idée de l’architecture. D’ailleurs le chapitre parle pour moitié du comité de normalisation, de son historique et de son processus. Nous restons sur notre faim. Le second chapitre est nettement plus conséquent, avec ses 35 pages. C’est l’ensemble de la représentation objet (sous forme idl) qui est abordée ici. La part belle est faite aux différentes collections (il y en a beaucoup), ainsi qu’aux opérations de base que l’on peut effectuer dessus. Les transactions sont abordées de manière un peu sommaire. Il est vrai qu’elles ne diffèrent guère de ce que l’on connait.

Le chapitre 3 fait un zoom sur l’IDL d’ODMG qui se nomme OLD (Object Definition Language, bien sûr). Par zoom, j’entends qu’une grande partie des 14 pages de ce chapitre sont consacrées à la BNF de ce langage et ce n’est pas particulièrement fun. A contrario, les 16 pages décrivant le langage de requête, l’OQL paraissent un peu courtes pour le sujet. Dommage en effet, car le chapitre est intéressant, avec de courts exemples à chaque fois.

Lire la suite

Note de lecture : Event Streams in Action, par Alexander Dean & Valentin Crettaz

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 de lecture : Streaming Data, par Andrew G. Psaltis

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 de lecture : Spark in Action, par Petar Zecevic & Marco Bonaci

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 de lecture : Big Data, par Nathan Marz avec James Warren

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

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

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

Lire la suite