Business Geek

Il y a quelques jours, en plein milieu des ponts du mois de mai, nous avons organisé un Afterwork sur le thème du Big Data.

Nous étions une petite quinzaine à discuter autour du sujet (ou pas, c’est le principe de l’AfterWork ).

Nous avions l’honneur d’accueillir Stéphane Fermigier, spécialiste du Big Data mais connaissant très peu SQL Server. Il a rédigé un excellent livre blanc, très exhaustif sur le sujet.

Vous pouvez trouver ce livre sur son site : http://www.fermigier.com/

Ma vision sur le sujet

J’ai dans les cartons depuis un moment de faire un petit article sur le Big Data afin de livrer mes pensées sur le sujet. L’AfterWork a été un moment pour quelques échanges de points de vue.

Autant vous le dire tout de suite, mon premier sentiment quand j’entends le mot Big Data est “Buzz”. En effet, à voir comment tout le monde ces derniers mois s’est précipité pour ajouter ce mot dans un article, un discours marketing, une nouvelle feature de sa solution. En moins d’un an, tous les éditeurs ont sorti une offre intégrée plus ou moins dans leur solution.

Le phénomène d’explosion des données n’est pas nouveau. Comme le rappelle Sybase, les plus grands spécialistes en parlaient déjà comme une révolution en 56, en 70, 86 ou encore 90 (source : http://www.decideo.fr/Sybase-se-moque-de-la-tendance-big-data_a4755.html).

Qu’on soit bien d’accord, le Big Data est pour moi un concept bien réel et je ne dénigre personne. Je vais m’expliquer.

Avec ce mot quasi marketing de Big Data, on arrive à imager simplement toutes les problématiques actuelles de nos montagnes de données.

Et la problématique ne se limite pas au simple fait que ce soit une montagne. Si je dois vous livrer ma définition, je reprendrai le principe des 3V (dont je ne connais pas l’auteur original désolé).

Pour qu’on soit dans un cas de Big Data, il faut que ces trois caractéristiques soient présentes :

• Volumétrie : c’est le Big de Big Data. On s’en doute bien, on parle de volumétries importantes et je ne parle pas forcément des Péta-octets de Facebook ou de Google. On peut redescendre sur terre et démarrer le compteur en centaines de Go.
• Vélocité : ma définition est souvent de dire qu’on a un flux entrant supérieur à notre capacité de traitement (ou tout du moins suffisamment élevé en comparaison). Par traitement, j’entends intégration ou analyse.
  Il y a d’autres définitions du second V évidemment mais je conserve la mienne.
• Variété : par variété, on entend le fait que nos données sont changeantes. Je prends souvent l’exemple d’une ligne qui contient une fois 3 colonnes et la fois suivante 10.
  On peut imaginer des logs Web d’un site d’e-commerce où on stocke la simple navigation puis au moment de la vente toutes les données relatives à celle-ci.
  Encore une fois, c’est ma version et je ne veux pas prétendre qu’elle soit la meilleure

L’important est d’avoir l’ensemble de ces critères. Individuellement, chacune de ces caractéristiques est gérable par SQL Server (ou d’autres bases de données).
Au niveau de la volumétrie, SQL Server n’a plus à démontrer ses capacités. Le dernier record en date est la gestion d’un DataWarehouse de 600To avec l’appliance PDW (Parallel Data Warehouse).
Au niveau de la vélocité, SQL Server détient avec SSIS le record de vitesse d’intégration de données (ça date un peu d’ailleurs) avec 1To chargé en 30 minutes.
Enfin, au niveau de la variété, je citerai juste des fonctionnalités comme Sparse Column, XML ou SQLCLR.

Donc, il faut les 3V… Sauf que c’est plus compliqué que cela je pense. Big Data est un concept, donc de nombreuses combinaisons sont à considérer.
Big Data est tout simplement le mot utilisé pour parler de données difficilement exploitables avec des moyens ou techniques traditionnelles.

Et cela veut aussi dire qu’on inclut des modes d’exploitation nouveaux (ou mis à l’écart faute de savoir comment bien les appréhender auparavant). Ainsi, on souhaite maintenant trouver dans notre montagne de données des tendances, des relations inattendues, des modèles dans le modèle, etc.

Pour moi, c’est tout cela finalement le Big Data, le concept d’abolir les limites de l’exploitation des données.

Mais alors, rien de concret ?

En fait si ! Derrière le concept, il faut bien trouver des solutions techniques.

Comme je le disais, SQL Server peut gérer du Big Data si l’on se base sur les fondamentaux. Néanmoins, de nouveaux paradigmes ont été créés pour mieux répondre aux enjeux.

Le premier est le stockage qui doit absorber le volume et la vélocité. Le second le requêtage qui doit s’adapter à la variété.

Ainsi on trouve Hadoop qui propose un système de stockage (HDFS) et des systèmes de requêtage (MapReduce, Hive ou PIG).

Microsoft a rejoint Hadoop en signant un partenariat avec HortonWorks et contribue en fournissant de l’outillage (requêtage en Javascript, Driver Hive ODBC, etc.) et en portant Hadoop sur Azure et Windows.
Vous pouvez d’ailleurs jouer avec Hadoop : hadooponazure.com

Ces solutions sont certes jeunes mais de nombreux projets les utilisent massivement.

Pour conclure…

Je le réaffirme, le mot Big Data est un phénomène marketing. Mais il introduit un changement de paradigme réel dans l’approche que l’on a de l’exploitation de nos données.

En tant que professionnel de la Business Intelligence, je comprends parfaitement même si les solutions traditionnelles répondent encore très bien aux besoins. Mais attention car les solutions telles que Hadoop répondent très bien à l’opérationnel (OLTP) et il faut donc les considérer comme des sources de données, comme celles que nous utilisons déjà.

Pour finir, c’est quand le prochain AfterWork ?

Le prochain Afterwork sera très certainement orienté Business Intelligence. J’ai quelques sujets en tête mais n’hésitez à en proposer au GUSS (en passant par moi par exemple).