Je vais aller droit au but: vous savez comme je vois le DWH Toolkit de Kimball & Co comme LE bouquin de référence pour le décisionnel, et bien c’est très simple, voilà son équivalent côté Big Data. A mon sens c’est une lecture incontournable, d’autant plus si vous avez déjà écrit ou prononcé les mots « Lambda Architecture ».

Notez que je ne suis pas le seul à en dire du bien, c’est un ouvrage qui a été largement encensé depuis qu’il est sorti, et franchement il le mérite!

Nathan Marz (Twitter, Site) c’est un ancien de Twitter et l’un des créateurs d’Apache Storm, la techno de stream processing la plus utilisée dans la stack Hadoop. Il a fait ses preuves.

Au delà du fond, vraiment passionnant, la forme est également au top. En effet on alterne des chapitres théoriques avec des exemples d’implémentation technique, sur des technologies variées, toujours dans le cadre de la mise en place d’un même système de web analytics. Ça donne un fil rouge au bouquin qui rend sa lecture vraiment digeste.

Morceaux choisis:

• Les techniques fondamentales liées au Big Data: des systèmes (storage & compute) qui ont conscience de leur nature distribuée, des données immutables, le tout pour permettre le scaling horizontal (ajout de machines) le moins douloureux possible

• Pour rendre un système de données résistants aux erreurs humaines : on conserve les données dans un format immutable (on ne peut qu’ajouter, ni supprimer ni mettre à jour) et des algorithmes en re-calcul complet (recomputation, à opposer aux chargements incrémentaux)

• D’où l’architecture lambda : un master dataset immutable avec une ligne de chargement en re-calcul complet (batch + serving layers), mais ce sera lent, donc on y adjoint d’une ligne de chargement rapide (speed layer), à côté, qui gèrera les delta en attendant le prochain batch. Et pour l’utilisateur, une vision unifiée qui brasse des données issues du batch et du streaming.

• Côté Master Dataset, on utilise une techno robuste qui assure le caramel en batch write / batch read : du filesystem, en mode distribué avec HDFS. Là-dessus on emploie une modélisation particulière (fact-based model, une normalisation complète), si possible structurée via un framework de serialization genre Avro, ProtoBuf ou Thrift.

• On prépare des batch views dans le Serving Layer, à coup de Map/Reduce en Java ou Python, à destination d’une base batch write / random read orientée requêtage ad-hoc. Ici on va indexer et dénormaliser, pour le confort des utilisateurs.

• Sur le Speed Layer, le but va être de reproduire la même chaîne de traitement qu’en batch (un des inconvénients de la méthode), mais sur un volume bien moindre de donnée, pour s’approcher du temps réel. On parle Kafka pour gérer la queue multi-utilisateur, Storm pour le stream processing incrémental, et Cassandra pour gérer le random read / random write à exposer aux utilisateurs.

Si vous voulez avoir le pourquoi de tout ça, expliqué de façon propre et illustrée, direction le bouquin, il vaut le coup.

Je recommande plus que vivement 🙂