Le volume est souvent le V le plus cité, d'où le nom de big data. On va voir qu'en réalité c'est un peu plus complexe que de gros volumes.

Alors, plusieurs solutions se présentent face à un problème simple: aucun disque dur ne peut stocker 500 téra-octets de données d'un coup. Fondamentalement, plusieurs disques vont être mis en réseau pour réaliser les lectures / écritures nécessaires. Deux familles de solutions : on utilise une solution de sharding qui partitionne les données, ou bien on répartit sur plusieurs disques, sans partitionnement, formant ainsi ce qu'on appelle un système de fichiers distribués.

Distribuer les fichiers

Evidemment, si vous avez des données réparties, disons pour stocker des fichiers, vous allez avoir plusieurs problématiques nouvelles qui vous seront cachées (ou pas):

  • redonder les données : bien sûr, plus vous mettez de nœuds dans un cluster, plus vous avez de (mal)chance qu'un nœud vous lâche sur une période donnée. Donc, vos données sont dupliquées, et un mécanisme vous permet de pointer sur une donnée valide.
  • garder l'information sur votre file system. Si réaliser un ls (dir pour les windows addicts) est trivial sur un seul disque, le fait de le répartir complique la tâche. Vous aimeriez éviter un parcours complet de tous les noeuds du cluster (et il y a des solutions pour cela).
  • gestion de la concurrence : si vous et une autre personne crééz simultanément un fichier /data/all.txt , vous aimeriez avoir une erreur pour garder un FS cohérent.

Le HDFS a résolu sauvagement cette question en créant un noeud parent (le name node) qui contient  toutes les informations relatives au FS. Il est redondé pour ne pas mettre le DFS à genoux s'il tombe en panne mais l'idée est là. Pourquoi ne pas partir sur un système en pair à pair et des DHT ? Selon les concepteurs de Google File system, le name node existe essentiellement pour la facilité de l'architecture.

Gestion de la cohérence

Le sujet n'est pas de re-dérouler l'article sur le CAP, mais le fond de la question reste le même : qui dit répartition dit problème de cohérence, ou choix entre disponibilité et cohérence. L'avantage d'avoir un nœud unique qui gère les requêtes de lecture et d'écriture est que les requêtes sont passées dans l'ordre, et que la complexité est gérée par ce nœud. Evidemment, ce mécanisme a lieu au sein d'un cluster. Ce n'est pas le choix de toutes les architectures, en particulier si plusieurs nœuds acceptent des requêtes de lecture (ce qui ne pose pas de problème si personne n'écrit au même moment) ou des requêtes d'écriture (ça c'est compliqué). On vous en a déjà parlé, mais Cassandra permet de définir un niveau de cohérence pour les requêtes, afin de trouver un compromis entre temps et cohérence.

Distribuer les traitements

Le tout n'est évidemment pas de mettre en place un système de fichiers distribué si c'est pour avoir une seule machine qui traite des téra octets sur 128 malheureux Go de RAM. Donc, il faut un cluster pour calculer. Et tant qu'à faire, autant que ce cluster soit le même que celui qui héberge la donnée, pour qu'un traitement soit d'un point de vue réseau le plus proche possible de la donnée qu'il manipule. C'est alors qu'apparait SPARK pour l'éco système Hadoop, un outil qui renvoie le map reduce au rayon de la préhistoire. Le but est de "donner l'illusion" que le cluster est une unique gigantesque machine, sans avoir à se demander si la donnée X est sur l'IP Y ou pas. Pas besoin de rapatrier les données à la main, tout est réglé pour vous. Et c'est formidable. Tout ceci est bel et bon, mais il se trouve que quand plusieurs jobs vont tourner sur les machines, ils risquent de ne pas avoir assez de ressources. Il faut donc un "négociateur de ressources", comme YARN : yet another resources negociator. Sur le principe, c'est simple : un noeud prend et centralise l'intégralité des demandes. Il négocie avec les autres noeuds pour avoir la capacité demandée, et sert le programme au fur et à mesure. Spark est évidemment compatible avec YARN...

Conclusion

Dans l'histoire de l'informatique, on se demande pourquoi on a passé autant de temps sur les grands systèmes. Pour une raison simple : le CAP theorem, et le fait que tant qu'on pouvait utiliser un seul système, c'est celui là qu'on prenait... Et...Un jour, chez Google, ça n'a plus suffi. D'où le Google FS, l'ancêtre d'Hadoop.  Les systèmes distribués comme Hadoop ont ce mérite là au moins : permettre de traiter plus. En conséquence, pour qu'une personne lambda chargée de développements n'ait pas toute cette complexité à gérer, sont arrivés YARN, SPARK, HDFS et d'autres. Voilà... C'est simple finalement, non?

 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.