Avez déjà remarqué comment certains spécialistes arrivent à noyer leurs interlocuteurs dans une pléthore de termes techniques ? À croire que ces termes reflètent leur degré de connaissance pour ne dire leur niveau d’intelligence et qu’en dehors de ces mots magiques, ces buzzwords, point de salut. Soit vous les connaissez, soit vous avez tout intérêt à vous taire vous pour ne pas révéler à la face du monde votre ignorance.
Pourtant, quand on creuse un peu, on découvre qu’il s’agit bien souvent de biais de langages qui participent tout autant à une clarification qu’à une confusion générale. Plutôt antithétique, n’est-ce pas ? Dans l’optique de simplifier un discours, on crée des termes génériques, des néologismes, censés faciliter la compréhension, mais ils viennent malheureusement parfois, pour ne guère dire souvent, in fine la complexifier.
Le Big Data fait ainsi partie de ces fourre-tout où l’on mélange technologie, commercial et marketing, juxtaposant souvent les termes ; les frontières n’étant clairement définies entre les définitions. Il faut aussi dire que le terme est ronflant, a le vent en poupe, et fait vendre. À sa décharge, les technologies gravitant dans sa sphère sont véritablement jeunes comparativement à d’autres domaines de l’informatique fortement plus éprouvés. Fusent ainsi régulièrement de nouveaux principes, algorithmes et produits ayant pour effet de perdre encore plus le néophyte voire le professionnel sans cesse obligé de se remettre en cause sur ses acquis.
Pleuvent ainsi les questions, des plus simples aux plus compliquées. Qu’est-ce que le Big Data ? Quand en fait-on réellement du Big Data ? Faire de Big Data est-ce utilisé systématiquement des systèmes ou technologies éponymes, est-ce du NoSQL ou peut-il s’agir de bases de données relationnelles ? Qu’est-ce que les termes d’architecture lambda, stream, batchs, datascience, datalake, analytiques, machine learning ? Quelles frontières, différences avec le datawarehouse/OLAP, ETL quelles différences entre MongoDB, Cassandra, Hadoop, les déclinaisons MapR, Hortonworks, Cloudera. Qu’est-ce que Spark, Storm, ElasticSearch, Flume, Mahout, CouchDB, Big Query, Hive, Pig, etc.
Si ces mots vous semblent abscons, attendez de lire la suite. Chiffre à l’appui, il y a une claire inadéquation entre les besoins exprimés en BigData et la compréhension globale qu’en ont les métiers. Selon un sondage d’Opinion Way relayé par Microsoft, 75% des dirigeants et manager français n’arrivent pas à donner une notion précise du Big Data et pire encore, 86% disent que la notion est floue. Paradoxalement selon une étude de l’IDC de 2015, 82% des décideurs estiment que l’analytique peut fortement améliorer leurs processus métiers et 41% veulent utiliser leurs données non structurées d’ici 2017.
Autrement dit, les sociétés veulent analyser leurs données pour en tirer de la valeur avec quelque chose qu’elles ne comprennent pas forcément bien. Il faut dire qu’analyser ses clients, ses comportements, pouvoir déterminer des tendances, faire monter les paniers d’achats, optimiser les marges, les processus internes, la gestion des risques ; j’en passe et des meilleurs ; est un souhait antédiluvien.
Or le Big Data est présenté, avec souvent le cloud en toile de fond, comme une martingale pour les aider à gagner plus, à marger mieux, à dépenser moins et comme une panacée à tout problème d’analyse, stockage, montée en charge et haute disponibilité. Tout un programme !
Mais si les dirigeants et managers ne connaissent pas clairement les concepts et avantages apportés par le Big Data, considérant la notion floue ; ils en ignorent totalement les écueils et problématiques de mises en œuvre, n’imaginant pas toutes les limites de ces produits qui, s’ils sont superbement bien conçus et architecturés, ne répondent pas systématiquement et parfois aussi que partiellement, à tous les cas d’usage idéalisés et souhaités par le métier. Le Big Data c’est tout, sauf magique.
Pour preuve, selon Opinionway seuls 4% des projets mis en place du Big Data l’on fait de façon efficace. Ce chiffre est très dommageable, car on pourrait argumenter ; pour ne guère dire conclure, que le BigData est un effet de mode qui ne marchera pas et que sa mouvance devrait logiquement à terme s’estomper.
Pourtant c’est tout l’inverse qui se produira. Le Big Data va s’intensifier à outrance, car est structurellement imaginé pour gérer et analyser un volume titanesque de données. Il n’y a pas mieux dans l’état de l’art informatique pour stocker et traiter la quantité de data que nous produisons chaque jour. Les chiffres ne font que croître, et bientôt de façon exponentielle avec les besoins de l’Internet des Objets (IOT) .
Il convient, dans ce flot de technologies, de savoir de quoi on parle et où on s’oriente. Nous vous proposons ainsi dans weekly une visite guidée du Bigdata en prenant en compte les aspects marketing, techniques et commerciaux, en vous expliquant les rouages du Big Data, les les termes, et en nous permettant même une incursion sérieuse dans le technique pour que les choses soient bien claires.
Nous allons toutefois y aller crescendo, en nous basant sur une série d’articles étalée sur plusieurs semaines. Déjà pour ne pas vous épuiser, car il y a beaucoup à dire ; mais aussi pour vous permettre de digérer les différents concepts. À destination du profane comme du professionnel de l’informatique, nous vous invitons à une plongée au cœur dans ce qui structure l’informatique de demain afin de vous en révéler toute la puissance ; tout en mettant en exergue les sérieuses limitations que vous pouvez rencontrer en fonction des technologies et domaines choisis.
Premier article d’une longue série, commençons par la base et explicitons le mot Big data.
Pour faire simple, au mot data qui représente les données au sein d’une entreprise, on juxtapose le mot big pour dire qu’il y en a beaucoup ; vous voilà bien avancé !
Pourtant, c’est bien cela l’origine du BigData. Lorsque vous faites face à un nombre de données trop grand pour le stocker sur un serveur aussi gigantesque soit-il, et qu’il vous en faudrait assurément plus, bien plus qu’une dizaine ou centaine ; ça y est, vous êtes dans le Big Data.
Arrêt sur image.
Cela signifie donc des infrastructures gigantesques que beaucoup de sociétés ne possèdent pas ! Or nombre d’entre elles utilisent des technologies de Big Data sur un nombre restreint de machines, parfois peut-être même une seule, est-ce normal ?
Disons tout de suite que la clé de voûte du Big Data est la capacité à monter en charge en fonction de vos besoins. Vous pouvez commencer petit et ajouter des machines au fur et à mesure de votre évolution. Argumentons ensuite que de nombreux principes et technologies gravitant autour du Big Data peuvent le rendre intéressant sur des petits systèmes, pour des raisons de stockage, de modèle de données non structurées ou de capacités de travail en mémoire (« in-memory ») par exemple, mais nous ne sommes pas encore là ; nous expliquerons ces principes dans un autre article.
Pour le moment, considérez véritablement le Big Data pour ce qu’il était à l’origine, un problème de taille pour les géants de type Facebook, Google, Amazon, LinkedIn, Yahoo et consorts pour stocker leurs données : beaucoup d’utilisateurs, des sommes astronomiques à dépenser en serveurs et une impossibilité d’utiliser les bases de données classiques sauf en tordant fortement le modèle et en les détournant de leurs principes de base (cas de Facebook et MySQL par « exemple).
Dans la littérature Big Data, Google a beaucoup fait avancé la donne, publiant notamment plusieurs papiers, mais sans expliciter le code, sur sa façon de faire. Un système de fichier réparti, GoogleFS, un algorithme de calcul parallèle, le MapReduce et une base de données propriétaire et haute performance, BigTable. L’ensemble explicitant sa façon d’implémenter des mécanismes pour gérer et requêter sur un gros volume de données en prenant en compte toutes les problématiques de montée en charge, haute disponibilité et résistance aux pannes.
Pour le moment retenez bien que le BigData a été créé pour se cas de figure spécifique, permettant d’avoir des systèmes répartis capables de gérer une volumétrie importante tout en ne perdant pas de vue une maîtrise raisonnable des coûts avec ainsi l’objectif de s’installer simplement sur des machines dites "commodity" (grosso modo des serveurs classiques) plutôt que des mastodontes au prix astronomique.
Cette idée de répartition est tout au cœur du Big Data. De nombreuses contraintes y sont liées. À procéder ainsi, puisque lorsque les données sont réparties sur plusieurs machines, la récupération des données est plus compliquée, plus lente (car il y a des communications réseau entre plusieurs machines) et aussi plus hasardeuse (moins de cohérence) que sur une base de données centralisée. Pas de panique, l’ensemble est stable, mais vous n’êtes pas dans le monde du relationnel et de ses principes ACID, mais dans celui du big data et son principe nommé BASE.
ACID, BASE ? Nous vous définirons ces termes dans un autre article, en introduisant également en détail le concept des 3V (qui sont désormais 4 ou 5 en fonction des auteurs).
Retenez simplement pour ce premier article que le Big Data, c’est vraiment à l’origine fait pour le traitement de données massives. Pour arriver à une telle prouesse il a fallu accepter de fonctionner différemment et donc de perdre certaines fonctionnalités proposées de bases sur les systèmes classiques. Les technologies de Big Data peuvent gérer des volumétries ridiculement petites, avec toutefois une nuance de taille : une changement de paradigme (de façon de penser) qui fait passer de l’ACID vers le BASE. A l'inverse, pour votre information, vous pouvez gérer un grand nombre ; certes non titanesque ; de données avec des bases classiques. Il convient donc de déterminer quand la volumétrie devient véritablement "big". C'est à lire dans notre prochain article.
Pour ceux qui sont en manquent de technicité, sachez que plusieurs implémentations Big Data s'appuient sur le langage de programmation Java. Il est certes très efficace, mais pour de l'optimisation d'un moteur de bases de données, c’est généralement le C/C++ qui s'impose, comme pour les jeux et les calculateurs orientés performance. Et ceci pour des raisons de proximité matérielle, d'optimisation de ressources (notamment la RAM), pour la possibilité d'appeler des API systèmes, pour l'option de passer en assembleur si nécessaire, pour éviter les ralentissements liés à l'usage d'une machine virtuelle (JVM), etc.
A méditer. Si certains logiciels Big Data n'hésitent pas à utiliser des langages comme Java c'est bien que leur architecture n'est initialement pas orientée performance locale sur une machine, mais bien sur un concept autre et bien précis ; concept du Big Data que nous analysons au fil de nos articles.