Sur le chemin vers MapReduce

« MapReduce » est apparu comme un nouveau paradigme incontournable, mis en place par Google pour des raisons simple. Comment les requêtes de chacun peuvent parcourir toutes les pages web ( 40 milliards) et donner un résultat efficient en quelques millisecondes, voici le début d’explication qui nous amène à la construction des data center :

Un algorithme calcul sur le CPU, et accède aux données qui sont en mémoire. CPU memory

Car une fois les données du disque chargé en mémoire, le CPU n’as plus besoin d’accéder au disque.

 

On parle d’algorithmes modelé pour les statistique, l’apprentissage et bien d’autres choses.

 

 

Que se passe-t-il quand les volumes de données sont si grands qu’ils ne tiennent pas tous en mémoire ?

Ces algorithme classique vont chercher des datas lors des calculs sur les disques.

CPU MEMORY DISKAlors les données sur les disques, sont traitées par portions sur la mémoire.

On peut alors les traités et envoyer le résultat à nouveau sur le disque.

C’est le processus classique des algorithmes.

 

 

Mais parfois cela n’est pas suffisant.

Pensons à Google, explorant et indexant le WEB, d’accord ?

Google Explore 10 Billion de web pages (nombre réduit pour simplifier, car si vous recherchez, par exemple, la lettre « a » Google trouve 25 Billion de pages), si l’on prend une taille moyenne de web-page à 20 KB.

On obtient un nombre de données de 200 TB.

  • 10 Billion de Web-Pages
  • 20 KB pour poids moyen d’un Web-page.
  • 10 Billion X 20 KB = 200 TB

 

Lorsqu’on à 200TB de données à traité et que l’on prend le modèle classique d’algorithme, cela donne un traitement qui doit forcément passer par les Disques durs avant d’être traité par le CPU.

Maintenant la limitation fondamentale que l’on a ici, c’est la bande passante entre les disques et les CPU, la vitesse d’écriture est de 50MB par seconde pour la plupart des disques SATA.

  • Alors si l’on prend 1 seconde pour lire 50 MB, combien de temps faudrait-il pour lire 200TB ?
  • 10 Billion de Web-Pages
  • 20 KB pour poids moyen d’un Web-page.
  • 10 Billion X 20 KB = 200 TB
  • Lecture de disque bandwidth= 50 MB/sec
  • Temps de Lecture = 4 millions de secondes = 46 jours

La réponse est un peu plus que 46 jours,  pensez-bien qu’il s’agit juste du temps pour lire les données, bref, cela n’est pas envisageable. Alors nous devons trouver une meilleure solution

La solution qu’il faut envisager est de morceler les données, et multiplier les disques et ainsi les lires et traiter les données en parallèle, en multipliant aussi  les CPUs.

Ainsi le temps sera considérablement réduit,  par exemple si on traite les données en morcelant ces dernières sur 1000 disques, on pourrait faire ce traitement en 1 heure :

  • 4 Million de secondes / 1000 = 4000 sec = 1 heure

Le cluster

C’est un temps plus acceptable et c’est l’idée fondamentale du cluster informatique.

Voici l’architecture résultant de cette approche :

Cluster informatique

Nous y voyons des « racks » constitué en nœud Linux ( Linux nodes). Pourquoi linux ?

C’est une approche vraiment intéressante niveau rapport/qualité prix. Et l’on peut ainsi acheter 1000 et encore 1000 racks de ce type a moindre coûts, bref …

Chaque rack à de 16 à 64 de ces linux nodes et ces nodes sont connectés à un switch. Ces switch sont des switch d’1 Gbps, donc on à une bande passante d’1 Gbps entre chaque node. Bien sur 16 à 64 nodes ne sont pas suffisant, donc on multiplie les racks, et tous les switch eux-mêmes sont connecté à un par d’autre switch, appelé « backbone ». Et ces derniers sont plus larges en bandes passantes et peuvent aller entre 2, 10 Gbps, entre 2 racks.

Donc on à multiplier, les disques et CPU,  les nodes et  on multiplier les racks, ainsi pour obtenir enfin un Datacenter.