WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Stratégies d'optimisation de requêtes SQL dans un écosystème Hadoop

( Télécharger le fichier original )
par Sébastien Frackowiak
Université de Technologie de COmpiègne - Master 2 2017
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

3 HADOOP

3.1 Histoire

L'histoire de Hadoop commence avec le projet Nutch, initié par Doug Cutting en 2002. Son but était de proposer un moteur de recherche open-source de type « crawler », c'est-à-dire capable de parcourir et d'indexer automatiquement l'ensemble du web, quand les moteurs de recherche de cette époque pratiquaient un référencement manuel des sites web.

Les quantitéscroissantes voire inattenduesde données à stocker et à traiter devinrent une difficulté, l'infrastructure supportant le projet Nutch ne reposaient en effet que sur quelques machines.

En 2003, Google publia un article de recherche concernant un système de fichiers, le GoogleFS (Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung, 2003). Ilse compose d'un cluster de noeuds, le rendant scalable et distribué :

- la taille du FS n'est pas limitée et peut être étendue par ajout d'un nouveau noeud

- la taille de chacun des fichiers qu'il contient n'est pas limitée non plus etces fichiers sont répartis, par blocs, sur plusieurs noeuds

Le GoogleFS est ainsi parfaitement adapté aux traitements distribués.

En 2004, Google publia un nouvel article de recherche concernant un framework de traitement distribué : le MapReduce (Jeffrey Dean and Sanjay Ghemawat, 2004).

Dès 2004, les travaux de Google permirent au projet Nutchde résoudre ses difficultés de stockage et de traitement en concevant une implémentation open-source de GoogleFS et MapReduce :c'est Hadoop. Ce dernier estainsi composéde son propre composant de stockage (HadoopFS ou HDFS) et de son propre composant de traitement (MapReduce).

D'abord utilisé par Yahoo en 2006, puis passé sous licence Apache en 2009, la première version stable de Hadoop fut proposée en 2011.

3.2 Le composant de stockage (HDFS)

Tout comme le GoogleFS, le HDFS repose sur un cluster scalable et distribué (Tom White, 2015). Il est composé d'un noeud principal exécutant le service « NameNode » (maître) et de plusieurs noeuds exécutant un service « DataNode » (esclave).

Les DataNodes contiennent les fichiers découpés en blocs. Par défaut :

- un bloc a une taille de 128MB (contre 4KB pour un FS « classique »),

- un même bloc sera copié sur 3 DataNodes distincts.

Le NameNodemaintient l'arborescence du système de fichier (répertoires, fichiers et blocs composant chaque fichier) et connaît l'emplacement (unDataNode) de chaque bloc constituant chaque fichier.

Il s'ensuit que toute demande de lecture ou d'écriture d'un fichier passera d'abord par le NameNode, soit pour obtenir la liste des blocs et leurs emplacements, soit pour allouer/désallouer de nouveaux blocs.

Ces caractéristiques impliquent que le HDFS est optimisé pour traiter spécifiquement des fichiers de grande taille, le plus rapidement possible. En effet, si la taille des blocs est aussi élevée, c'est pour être en mesure de lire les fichiers à la vitesse permise par le disque. Si ce dernier à une vitesse de lecture de 100MB/s et un temps d'accès de 10ms, un fichier de 128MB sera lu en 1,29s (1,28s+0,01s) et ne sera pas pénalisé pas le temps d'accès. A contrario, la lecture de 128 fichiers de 1MB nécessitera 2,56s (1,28s+0,01s×128) et la nécessité de solliciter autant de DataNodes (si chaque fichier est réparti sur un DataNode différent).

En outre, le HDFS fonctionne en mode « write-once, read-many-times », c'est-à-dire qu'une fois créé, un fichier ne peut être modifié, sauf pour une opération de concaténation ou de suppression. Cela permet de garantir la cohérence des données lorsqu'elles sont sollicitées simultanément. De plus, la modification d'un fichier de très grande taille serait bloquante et donc incompatible avec l'objectif de traiter des fichiers le plus rapidement possible.

Enfin, le HDFS est tolérant aux pannes du point de vue de ses DataNodes, puisque chaque bloc sera recopié 3 fois. En revanche, le NameNode doit être considéré comme un « single point of failure », dans la mesure où il stocke en mémoire l'arborescence du système de fichier et l'emplacement de chaque bloc. Comme un objet nécessite 150B de mémoire (quelle que soit sa taille), une quantité élevée d'objets peut conduire à l'arrêt du NameNode et donc à la panne du HDFS. A titre indicatif, un milliard de fichiers nécessitent 300GB de mémoire vive : pour chaque fichier, il faut considérer 150B pour le fichier et 150B pour le bloc sur lequel il repose.

Le morcellement de HDFS en blocs de données de grande taille est étudié pour être utilisé par une application distribuée : MapReduce.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il y a des temps ou l'on doit dispenser son mépris qu'avec économie à cause du grand nombre de nécessiteux"   Chateaubriand