Big Data et Data Explorer

Comme nous avons pu déjà le souligner, ce blog se veut un cadre d’échanges et de partage avec la mise en avant de problématiques données assorties de la proposition de scénarios/solutions type prêts à l’usage. Ainsi, pour rentrer de façon pragmatique dans le monde du #BigData , l’objectif que nous nous sommes fixé consiste notamment à partager des focus particuliers sur la mise en œuvre concrète d’une technologie particulière ou d’un ensemble de technologies dans le contexte des solutions Microsoft pour le Big Data .

A ce propos, J’ai aujourd’hui le plaisir de publier dans ce blog ce billet rédigé par Jean-Pierre Riehl , responsable de Practice Data & Business Intelligence de la société AZEO . Je profite de cette occasion pour remercier très sincèrement Jean-Pierre pour cette contribution.

Jean-Pierre est MVP SQL Server et fait partie du « board » du Groupe des Utilisateurs SQL Server. Très impliqué sur les usages Self-Service du décisionnel, il suit de très près le dernier outil Data Explorer, véritable Self-Service ETL embarqué dans Excel.

Je vous souhaite une bonne lecture de ce billet et n’hésitez pas à consulter sur le blog de Jean-Pierre les autres billets consacrés à Data Explorer.

--Philippe

________________________________________________________________________________________________

L'un des enjeux des Big Data est de pouvoir les utiliser. Pour reprendre un célèbre slogan, “à quoi ça sert d'avoir des data si c'est pour rien faire avec”.

Souvent associé avec le requêtage des Big Data, on a l'image d'un scientifique (Data Scientist) ou d'un geek nourri aux pizzas, les 2 écrivant des requêtes complexes dans un langage dont on reconnait des morceaux mais qu'on ne comprend jamais vraiment bien.

La réalité est bien différente ; non pas qu'il n'y ait pas de scientifiques ou de geeks, mais on trouve une boite à outil très riche pour exploiter nos données Big Data.

C'est d'autant plus vrai dans l'univers Microsoft où l'on dispose des drivers, langages et outils intégrés à un écosystème riche et existant. Grace à Hive, on peut requêter nos données avec un langage SQL depuis Excel, SSIS (SQL Server Integration Services) ou .Net. Grace à PolyBase, on peut mixer nos Big Data avec un Data Warehouse d'entreprise en faisant des jointures entre les deux.

L'objet de cet article est de présenter un petit nouveau dans cette boite à outils : Data Explorer.

Data Explorer, c’est quoi ?

Data Explorer est un add-in à Excel permettant de faire du « shaping » et du « mashup » de données. En français, on pourrait parler de façonnage (je ne parle pas de mise en forme) et de composition (au sens de mélanger). Derrière ces mots barbares, on trouve toutes les opérations qui permettent de prendre des jeux de données quelconques et de le transformer en un Dataset exploitable : exploitable pour du reporting mais également pour de l'analyse de données bien évidemment.

Les développeurs trouveront que cet outil ressemble (fonctionnellement) à un ETL comme SSIS et ils auront totalement raison, tout du moins dans sa partie flux de données. On parle d'ailleurs de Self-Service ETL.

Cet add-in Excel orienté utilisateur est gratuit et complète parfaitement l'offre de Self-Service BI de Microsoft et en particulier PowerPivot et Power View. C'est un point important ! Ce n'est pas un outil de développeur, c'est bien un outil pour l'utilisateur final. Il est d'ailleurs également important de noter qu'il fonctionne sous Excel 2013 - on s'en serait douté -, mais également sous Excel 2010, comme PowerPivot ; ce qui lui donne une cible d'utilisateurs très large.

Mais le lien avec les Big Data ?

C'est simple, parmi la multitude de sources que prend en entrée Data Explorer, il y a des sources HDInsight que ce soit Windows Azure HDInsight ou HDInsight Server.

Si je rapproche cela du fait qu'on est sur un outil pour les utilisateurs métiers - ou finaux, appelez les comme vous voulez -, on voit tout de suite l'intérêt.

Nos Big Data ne sont plus réservées aux seuls développeurs mais sont utilisables par tous et surtout par les consommateurs les plus intéressés.

Regardons un peu plus tout cela dans le détail. Mettons-nous à la place de notre utilisateur métier. Et sa première question sera "mais quelle source dois-je prendre" ?

Pour cela, on va renseigner notre compte Blob Storage et on va pouvoir requêter les Containers qui s'y trouvent.

Ici, j'ai téléchargé un fichier contenant un flux Twitter.

Côté Excel, je m'y connecte via Data Explorer en précisant mon compte ainsi que la clé d'accès (en effet, ces données ne sont pas publiques).

Dans l'interface de Data Explorer, on voit les Containers de mon BlobStorage dans la zone de navigation de la source de données. On notera aussi que dans la barre de formule (Settings –> Show Formula Bar), la source se requête de la façon suivante :

=HDInsight.Contents("BlobStorageName")

Et on en fait quoi ?

Mais replaçons-nous au niveau d'un utilisateur métier. Ce dernier va naviguer pour arriver jusqu'aux données « finales » et ce d'abord au niveau fichier - ici il n'y en a qu'un dans le container.

Puis on va pouvoir descendre dans le contenu en cliquant sur les 2 petites flèches de la colonne Content.

On a maintenant la liste de tous nos Tweets au format JSON, format riche mais compliqué à exploiter. Ça tombe bien car Data Explorer sait l'interpréter :

• On transforme les données sous la forme d’une table pour pouvoir les exploiter
• On supprime la première ligne d'entête
• On transforme la colonne en JSON et on obtient une table contenant le type Record qui représente les objets à manipuler

• On va dé-normaliser chaque Record en récupérer les clés/valeurs. Cela se fait avec l'icône en haut à droite de la colonne. La liste des champs trouvés s'affiche et on peut même rechercher parmi eux via la textbox du haut.

• On récupère la date, le texte et l'utilisateur. Ce dernier est de nouveau de type Record (c'est la force du format JSON) et donc on réitère l'opération pour récupérer son nom
• On termine notre shaping en renommant les colonnes et en mettant les bons types (la date en particulier).

Une fois tout cela effectué nous disposons d'un Dataset prêt à être exploité dans Excel, PowerPivot, Power View ou encore Geoflow. D’ailleurs, Data Explorer permet justement de charger le résultat directement dans le Data Model de PowerPivot.

Evidemment Data Explorer ne nous sert pas qu'à renommer des colonnes ou simplement sélectionner des données. On peut croiser ces données avec d'autres jeux de données (jointure, union, etc.), les transformer, les pivoter, etc. On peut même étendre les fonctions de base en développant des fonctions avancées (ex : géocoding avec Bing Maps, API de qualification du texte, etc.) comme illustré notamment ici.

On récapitule

Data Explorer permet de récupérer et transformer des données Big Data comme n'importe quelle autre source. On se connecte sur nos Blob Azure (ou bien sur notre cluster HDFS) et nous avons accès à toutes les fonctions de manipulation des données de l'outil.

En sortie, on obtient un Dataset "propre", directement utilisable dans Excel, comme n'importe quelle autre table.

On est dans un scénario BI (Business Intelligence) typique : transformer des données brutes en information.

Mais comment positionne-t-on l'usage exactement ?

En effet, l'outil est simple, séduisant mais comment le place-t-on dans notre Système d'Information ?

Je vois 2 usages principaux :

1. Le premier est évidemment la mise à disposition d'un "requêteur" permettant de faire des analyses sur des données en provenance de notre système Big Data.
   C'est trivial mais un nouvel outil pour manipuler du Big Data n'est pas de trop étant donné l'outillage actuel, surtout quand il est aussi simple et vise une large population de l'entreprise.
2. Le second usage identifié est très intéressant ; c'est un usage de prototypage. Avant de mettre en place un projet plus ou moins complexe de Big Data, que ce soit au niveau du stockage des données ou des services de requêtage, il est peut-être pertinent d'en valider l'utilisation "Business".
   Avant de monter sa solution de Big Data, avant s'y déverser des « tombereaux » de données Twitter, Facebook, logs web et consorts, avant de lancer les équipes dans des algorithmes MapR et dans du requêtage Pig, Hive ou autre ; avant d'activer ces moyens, n'est-il pas pertinent de valider que l'aiguille se trouve bien dans la botte de foin ?

Comment Démarrer ?

Convaincu ? L'avantage, c'est que vous pouvez démarrer tout de suite : :)

• Télécharger Data Explorer.
• Tester le Blob Storage d'Azure.
• Tester Windows Azure HDInsight.
• Récupérer des données Twitter.