Big Data

Ha, les termes nébuleux de l’informatique moderne, c’est toujours un plaisir…

Ceci dit, il en est un qu’on est amené à entendre de plus en plus, c’est le Big Data…
Mais qu’est-ce donc que cette diablerie ? S’agit-il encore d’une « arnaque commerciale » comme le « Cloud » ?

On va tenter d’y voir plus clair, d’appréhender les concepts sous-jacents pour, au final comprendre de quoi il retourne.

Ceci n’est pas un article de fond, mais une « simple » présentation.
On verra la mise en pratique plus tard et nous approfondirons alors les concepts au fur à et à mesure.

Bien évidement, s’il y a des choses à rajouter, des points qui ne sont pas clairs, n’hésitez pas à commentez.

I – Présentation

Tout d’abord, il faut savoir que chez nous, francophones, on devrait dire « mégadonnées« . Si, c’est très sérieux (Legifrance).
Ceci dit, on est d’accord, on va continuer avec le terme Big data.

Et donc, derrière ce nom qui peut faire frémir, se cachent en fait deux concepts : stockage et traitement.

Merci au revoir … Ha ? Ça ne vous suffit pas ?

Bon, vous avez raison, car dans Big Data, il y a « Big ». Allez, juste pour donner une idée, un avion, c’est plus de 20To/h. Et c’est juste un exemple…

Vous l’avez compris, le « Big » de Big Data n’est pas là pour faire bien, il est pleinement justifié.
Et il apporte son lot de problématiques car stockage et traitement ne peuvent pas se faire de manière « classique ».

II – Les données

Dans le Big data, les données ont un ensemble de caractéristiques importantes qu’on appelle les 3V : Volume, Vélocité et Variété.

A – Volume

Depuis ces dernières années, on assiste à une explosion de la quantité de données générées.

Entre les géants du Web et leurs millions de transactions diverses, les scientifiques, la recherche médicale, les capteurs divers et variés, les objets connectés, les réseaux sociaux, les applications de nos smartphones, et j’en passe et j’en passe… vous voyez que le champ d’application est presque infini…

Les sources sont de plus en plus nombreuses, de plus en plus bavardes : les solutions « classiques » de cluster de stockage (données, bases relationnelles) sont rapidement hors jeu, les volumes étant tout simplement déments.

Le Big Data utilise du stockage distribué certes, mais prévu dans son architecture pour:

• traiter ces énormes volumes (découpage intelligent des données, répartition, duplication, etc…)
• être facilement scalable (ce qui n’est pas le cas de tous les clusters de données…).

On en parlera plus en détail dans un autre article (lors de la mise en place d’Hadoop…)

B – Vélocité

Là, on parle de la vitesse à laquelle sont générées toutes ces données.

Une expérience au CERN et ce sont des millions d’enregistrements en moins d’une seconde…
La bourse mondiale ? Des milliards d’ordres à la journée.

Il y a non seulement la notion de quantité toujours à prendre en compte, mais également la capacité à ingérer ces flux à la vitesse à laquelle ils arrivent.

Les SGBDRs classiques vont faire la tronche : les données dans ces derniers obéissent très souvent aux propriétés ACID (atomicité, cohérence, isolation et durabilité).
En gros, quand une donnée est ajoutée, il y a très souvent des contraintes dessus (Est-elle complète, cohérente, non dupliquée ? Est-elle lié à d’autre données, si oui, sont-elles présentes, etc..).
Des choses qui ralentissent drastiquement l’insertion de la donnée.

Là encore, l’architecture des solutions Big Data répond à toutes ces problématiques.

C – Variété

Le Big Data, pour résumer, c’est un peu comme feu la Foir’Fouille, on y trouve de tout…

Les données sont extrêmement hétérogènes. Elles peuvent être structurées (tables relationnelles ,…), ou non (textes, images, vidéos, etc…)

Concernant les données non structurées, on connaît déjà les bases NoSQL, les Redis, les ElasticSearch, les bases TSDB, etc… en fonction de ce que l’on veut y stocker.

Mais là encore, ces technologies ne sont pas adaptées pour le « Big » de Big Data.

III – Traitement

Maintenant qu’on a solutionné le stockage de nos données, il faut bien en faire quelque chose (pui on ne stocke pas pour le simple plaisir de stocker non ?)

Traitements, recherches, analyses, détections, peu importe ce qu’on veut faire, le problème est dans la quantité de données qu’il faut traiter.

Et si l’on traite les données moins vite qu’elles n’arrivent, on n’est pas sorti…

Il faut donc trouver comment distribuer le calcul sur un ensemble de nœuds.

A – Diviser pour régner

Ou l’art et la manière de diviser une grosse tâche complexe en plusieurs tâches simples et parallélisables (et qu’on peut donc exécuter de façon simultanée sur un cluster).

S’il est un terme à retenir, c’est « Map an Reduce ».

Map, c’est l’action de découper la tâche initiale en tâches plus simples et de donner à chaque « worker » ce qu’il doit effectuer.

Reduce, c’est l’action d’agréger les résultats de chaque nœuds en un résultat global.

J’ai évidemment beaucoup simplifié mais c’est l’idée générale et nous verrons dans les futurs articles tout ceci bien plus en détail.

 B – Mais..

Les algorithmes de type « Map and Reduce » ne sont adaptés pour tout.

Traitements itératifs ou sur des données difficilement réductibles à une simple paire « clé:valeur« , tout n’est pas facile à passer à la moulinette du paradigme « Map and Reduce ».

Dans l’environnement Hadoop, Spark est connu comme étant la « surcouche » adaptée.
Machine learning (découverte de tendances qu’on aurait pas cherchées,) traitements en temps réel (les données sont en Ram), traitements itératifs (dont le résultat final dépend de résultats intermédiaires), Spark, c’est un peu, si j’ose une comparaison, au C, ce que Map and Reduce est à l’assembleur.

Je ne m’étend pas plus, on en reparlera en temps voulu.

IV – Écosystème logiciel

Je ne vous cache pas que quand on regarde ce qui existe dans le domaine du Big Data, c’est un peu le bazar car il y a énormément d’acteurs dans ce domaine.

Mais un nom revient souvent, car c’est un peu le bateau amiral : Hadoop (fondation Apache)

En fait, il s’agit d’un framework open source composé de plusieurs briques :

• HDFS, le stockage distribué
• Hbase la base NoSQL associée
• Hadoop YARN qui est l’orchestrateur
• Map and Reduce, pour le traitement

Et c’est tout cela que nous verrons dans de futurs articles.

Je ne parle pas des autres logiciels,il me faudrait des heures pour tout lister, mais si vous êtes curieux, n’hésitez pas à creuser.

V – Par la suite

Comme généralement, j’utilise ce que je mets en place, j’ai pour idée, à terme, de récupérer les diverses données de différents Raspberrys (domotique, capteurs, etc…) et de réfléchir à ce que je peux en faire. Le projet est loin d’être abouti, mais au moins, j’ai un objectif.

Ne soyez pas trop impatients, les articles sont encore en brouillon et vous le savez, j’en ai encore beaucoup à terminer…

Bref, restez à l’écoute !

Envie de me soutenir et de me payer un café ? C’est sur la page Don !