Revue : Big Data par Nathan Marz et James Warren

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.

Couverture : Big Data chez Manning

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.

Schéma de la Lambda Architecture

  • 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 🙂

Dilbert du 2014-05-07

Et d’ailleurs, un des freins à la correction de vieilles anomalies c’est la conduite du changement qui va avec. Comment expliquer à un utilisateur que toutes les décisions qu’il a prise depuis 2 ans reposent sur du vent?

Dilbert du 2014-07-05(dilbert.com)

Traduction approximative:

Boss: Vous êtes sur que les données du rapport sont justes?

Dilbert: Je vous fournis ces données douteuses depuis des années, c’est la première fois que vous vous souciez de leur justesse.

Boss: Pardon?

Dilbert: Je vous dis que les données sont correctes!

Aspirer des données depuis un site web avec Excel, Power Query et Kimono

Mise  à jour 02/05/2014 : cet article existe aussi maintenant en webcast! Merci le GUSS 😉

Vous le savez surement, Power Query est l’add-in Excel publié par Microsoft via son offre Power BI, dédié à l’import de données de sources multiples. On en avait déjà parlé pour importer des fichiers identiques dans un même XLSX, une grosse galère sous Excel nature, une balade avec Power Query.

Logo Power BI

Si nous sommes nombreux à voir en Power Query un outil avec un potentiel exceptionnel, il y a un domaine où il est encore assez faible : l’import de données affichées sur une page web. Enfin ce n’est pas vraiment Power Query qui est faible, c’est plutôt qu’après 2500 lignes de JavaScript, le HTML final des sites est souvent complétement inexploitable…

Logo Kimono Labs

Et un outil fantastique pour contourner le problème c’est kimono. Avec kimono, vous allez générer de manière complétement graphique une API à partir d’un site web, directement depuis de votre navigateur.

On fait juste une pause pour bien laisser ça descendre…

Générer une API, de manière graphique, directement dans le navigateur.

On ne vit pas dans le futur avec ça franchement ? Pour moi c’est le scénario d’usage final. Et pour revenir au sujet du jour, ça les API web, Power Query il maîtrise.

Le mieux pour comprendre tout ça étant certainement de prendre un exemple, on va pratiquer en rapatriant des données depuis MetaCritic, le site web qui agrège les notes données dans la presse (papier ou web) à entre-autres les jeux vidéo.

La source : les meilleurs jeux PC de 2014

Capture d'écran de MetaCritic

On va commencer en essayant de se connecter directement à MetaCritic via Power Query, pour constater l’inutilisabilité de la chose :

1 – Je lance Excel, direction l’onglet Power Query, option importer depuis un site web, puis je renseigne l’adresse du site source :

Power Query - Connexion à un site web

2 – Hum, le navigateur de Power Query ne s’en sort pas tout seul, on va creuser (Edit) :

Power Query - Connexion à un site web

3 – Et boum, bon courage ! Si quelqu’un a trouvé une méthode pour s’y retrouver, je suis preneur, moi j’abandonne là en général

Power Query - Connexion à un site web

Alors à la place on va se connecter à kimono (on s’enregistre, on ajoute le bookmarklet à sa barre de raccourci) et créer l’API de manière graphique, c’est parti!

1 – J’ouvre mon navigateur, je vais sur le site source et j’utilise kimonify (le bookmarklet). La barre d’outils Kimono apparaît en haut de la page, et je commence par importer les noms des jeux juste en cliquant sur eux dans la page de MetaCritic. Le moteur de Kimono reconnait alors l’attribut HTML et identifie les 88 noms suivant, je renomme le champ « Nom du jeu » :

Kimono Labs : Premier paramètre
2 – J’appuie sur + dans la barre Kimono, je sélectionne la première note (92 pour DS2), la deuxième (88 pour Hearthstone), et à nouveau Kimono identifie les 88 valeurs suivantes. Je renomme le champs « Note »:

Kimono Labs : Deuxième paramètre
3 – Je répète la manip pour le Score Utilisateur, cette fois-ci le moteur de Kimono hésite un peu, il me propose plusieurs séries et à force de sélectionner d’autres scores et refuser d’autres attributs (ainsi que le label « User Score »), il m’en trouve bien 85 (en effet 3 jeux n’ont pas ce score, mais ça ne casse pas la reconnaissance):

Kimono Labs : Troisième paramètre
4 – J’ai assez d’info pour le moment, je valide (Done dans la barre Kimono), je donne un nom à mon API, et une période de rafraichissement (temps réel pour la démo, mais on peut alléger la charge sur la source en ne rafraichissant le dataset que périodiquement):

Kimono Labs : Validation de l'API
5 – Et Kimono me renvoie vers le tableau de bord de mon API:

Kimono Labs : Interface de gestion de l'API
6 – Via l’onglet « How To Use » je retrouve les éléments nécessaires pour accéder à l’API, y compris les URL (endpoints) que je vais pouvoir transmettre à Power Query en JSON, CSS ou RSS :

Kimono Labs : Interface d'appel de l'API
7 – On peut d’ailleurs tester le EndPoint CSV (ouais je suis oldschool) tout de suite :

Kimono Labs : test du endpoint CSV
8 – Mais le mieux c’est de l’appeler directement depuis Power Query (From Web toujours) :

Power Query : Appel de l'API Kimono
9 – Et après quelques petites manipulations (on retire la première ligne, on sépare les colonnes par délimiteur, on utiliser la première ligne comme nom de colonne, on nettoie le User Score, on filtre les lignes de déchet), on obtient le bon dataset. Note : si vous optez pour le JSON et que vous galérez, regardez cette vidéo, si ça ne marche pas comme ça, c’est que l’API est mal formée, le mieux est de la casser et recommencer (Kimono est encore en beta hein… Celle-là fonctionne et elle est publique).

Power Query : Résultat de l'import
10 – Pour obtenir les données attendues dans Excel :

Power Query et Kimono : résultat de l'import dans Excel

Personnellement je trouve ça juste énorme ! Et en plus tout est en live, la Query dans Excel et l’API côté Kimono, donc il suffit de rafraîchir pour que les données soient mises à jour depuis la source.

Si on rajoute la gestion des paramètres pour l’année (2014, 2013…) côté Power Query, la gestion de la pagination côté Kimono, on a les briques de base pour extraire toute la donnée dont on peut avoir besoin !

Joli non? Et sinon oui, c’est le bon moment pour prendre des actions dans Kimono Labs 😉

Big Data, Révolution IT ou effet de mode marketing ?

Je reviens sur le sujet Big Data en quelques schémas faits rapidement sur ArgumentPuissant. Ils sont inspirés par Stephen Few, Ralph Kimball, Rob Collie, Jen Stirrup, Romuald Coutaud, et plein d’autres…

Si on part de la pyramide du savoir, que vous connaissez tous (data > information > knowledge > wisdom en VO) :

Data > Information > Connaissance > Sagesse

Et qu’on écoute les services marketing des éditeurs, et les analystes, le Big Data ça donne ça :

Data > BOUM Big Data > Sagesse

Par contre si on écoute son bon sens, et les gens dont je parlais plus haut, ça donne plutôt ça :

Big Data > Data > Information > Connaissance > Sagesse

A vous de choisir la vision de la chose qui vous semble la plus réaliste.

Le Big Data c’est une belle nouvelle technologie, qui en effet va nous permettre de réaliser beaucoup de nouvelles analyses vraiment chouettes. Mais seulement à travers les outils dont on dispose déjà : les bases relationnelles (le SQL), la modélisation dimensionnelle (dimensions et mesures), la visualisation de données, et une méthode scientifique, une approche rationnelle de compréhension du monde qui nous entoure. Ces étapes ne sont pas facultatives, le Big Data n’y change rien.

Si dans votre entreprise vous n’arrivez déjà pas à exploiter pleinement votre plateforme décisionnelle, à passer de l’information à la connaissance, alors ne vous engagez pas dans un projet Big Data. Plus de données, plus d’informations, ne vous aideront certainement pas à y voir plus clair.

Je reviendrai sur cette pyramide du savoir. C’est une représentation que j’aime beaucoup, et qui illustre bien les différentes facettes de notre métier. On en reparle plus tard 😉