Une introduction à Hadoop

introduction

Apache Hadoop est l’un des outils open source les plus anciens et les plus influents pour le stockage et le traitement de l’énorme quantité de données numériques facilement disponibles qui s’est accumulée avec l’essor du World Wide Web. Il a évolué à partir d'un projet appelé Nutch, qui tentait de trouver un meilleur moyen open source d'explorer le Web. Les créateurs de Nutch ont été fortement influencés par les réflexions de deux journaux clés de Google et les ont initialement intégrés à Nutch. Toutefois, les travaux de stockage et de traitement se sont scindés en deux dans le projet Hadoop, tout en continuant à développer Nutch en tant que projet d'analyse Web.

Dans cet article, nous examinerons brièvement les systèmes de données et certains besoins spécifiques et distinctifs des systèmes Big Data. Nous verrons ensuite comment Hadoop a évolué pour répondre à ces besoins.

Systèmes de données

Les données existent partout: sur des bouts de papier, dans des livres, des photos, des fichiers multimédia, des journaux de serveur et sur des sites Web. Lorsque ces données sont collectées à dessein, elles entrent dans un système de données.

Imaginez un projet d’école où les élèves mesurent chaque jour le niveau d’eau d’une crique toute proche. Ils enregistrent leurs mesures sur le terrain dans un presse-papiers, retournent dans leur classe et saisissent ces données dans un tableur. Quand ils ont collecté une quantité suffisante, ils commencent à l’analyser. Ils peuvent comparer les mêmes mois d’années différentes, du niveau d’eau le plus élevé au plus bas. Ils peuvent créer des graphiques pour rechercher les tendances.

Ce projet d'école illustre un système de données:

  • L'information existe à différents endroits (les cahiers de terrain de différents étudiants)

  • Il est rassemblé dans un système (saisi manuellement dans un tableur)

  • Il est stocké (enregistré sur le disque de l'ordinateur de la classe; les cahiers de terrain peuvent être copiés ou conservés pour vérifier l'intégrité des données).

  • Il est analysé (agrégé, trié ou autrement manipulé)

  • Les données traitées sont affichées (tableaux, graphiques, graphiques)

Ce projet est sur le petit bout du spectre. Un seul ordinateur peut stocker, analyser et afficher les mesures quotidiennes du niveau d'eau d'un ruisseau. À l'autre extrémité du spectre, tout le contenu de toutes les pages Web du monde forme un ensemble de données beaucoup plus vaste. Il s’agit en gros de données volumineuses: tellement d’informations qu’elles ne peuvent pas tenir sur un seul ordinateur.

Les entreprises de moteurs de recherche étaient confrontées à ce problème spécifique en raison de l'explosion du contenu Web au cours de l'ère du commerce électronique. En 2003, Google a publié son article influent,The Google File System, décrivant comment leur logiciel propriétaire gérait le stockage de l'énorme quantité de données traitées pour leur moteur de recherche. Il a été suivi en 2004 desMapReduce: Simplified Data Processing on Large Clusters de Google, qui expliquaient comment ils simplifiaient le traitement de telles quantités de données. Ces deux articles ont fortement influencé l'architecture de Hadoop.

Comment le Big Data est-il différent?

Les documents de Google et la mise en œuvre de ces idées par Hadoop reposaient sur quatre changements majeurs dans la réflexion sur les données nécessaires pour prendre en charge le volume de données:

  1. Les systèmes de Big Data ont dû accepter quedata would be distributed. Le stockage du jeu de données en morceaux sur un groupe de machines était inévitable.

  2. Une fois que les clusters sont devenus la base du stockage, puissoftware had to account for hardware failure, car une défaillance matérielle est inévitable lorsque vous parlez d'exécuter des centaines ou des milliers de machines dans un cluster.

  3. Puisque les machineswill échouent, elles avaient besoin d'une nouvelle façon de communiquer les unes avec les autres. En informatique de données courante, nous sommes habitués à une machine spécifique, généralement identifiée par une adresse IP ou un nom d’hôte qui envoie des données spécifiques à une autre machine spécifique. Ceexplicit communication had to be replaced with implicit communication, où une machine dit à une autre machine qu'elle doit traiter certaines données spécifiques. Sinon, les programmeurs seraient confrontés à un problème de vérification au moins aussi important que le problème de traitement de données lui-même.

  4. Enfin,computing would need to go to the data and process it on the distributed machines plutôt que de déplacer les grandes quantités de données sur le réseau.

Publié en 2007, Hadoop, la version 1.0 du framework de programmation basé sur Java, a été le premier projet open source à intégrer ces changements de mentalité. Sa première itération est composée de deux couches:

  1. HDFS: Le système de fichiers distribués Hadoop, responsable du stockage des données sur plusieurs machines.

  2. MapReduce: Le framework logiciel pour traiter les données en place et en parallèle sur chaque machine, ainsi que pour planifier les tâches, les surveiller et relancer celles qui ont échoué.

HDFS 1.0

Le système de fichiers distribués Hadoop, HDFS, est la couche de stockage distribuée utilisée par Hadoop pour étaler les données et garantir leur stockage correct pour une haute disponibilité.

Comment HDFS 1.0 fonctionne

HDFS utilise la réplication en bloc pour stocker de manière fiable des fichiers très volumineux sur plusieurs machines avec deux logiciels distincts: le serveur NameNode, qui gère l’espace de nom du système de fichiers et l’accès client, et le DataNodes, responsable du traitement des demandes de lecture et d’écriture, ainsi que des blocages. création, suppression et réplication. Une compréhension de base du modèle de réplication peut être utile aux développeurs et aux administrateurs de cluster car, bien que généralement efficace, les déséquilibres dans la distribution des données peuvent avoir un impact sur les performances du cluster et nécessiter un réglage.

HDFS stocke chaque fichier sous la forme d'une séquence de blocs, de taille identique, à l'exception du dernier. Par défaut, les blocs sont répliqués trois fois, mais leur taille et le nombre de réplicas peuvent être configurés fichier par fichier. Les fichiers ne sont écrits qu'une seule fois et ne comportent qu'un seul enregistreur à la fois, ce qui permet un accès à haut débit aux données et simplifie les problèmes de cohérence des données.

NameNode prend toutes les décisions concernant la réplication de bloc en fonction des pulsations et des rapports de bloc qu'il reçoit de chaque DataNode du cluster. La pulsation indique que le DataNode est en bon état et le rapport sur les blocs fournit une liste de tous les blocs du DataNode.

Lorsqu'un nouveau bloc est créé, HDFS place le premier réplica sur le nœud sur lequel le graveur est en cours d'exécution. Une seconde réplique est écrite sur un nœud choisi au hasard dans n'importe quel rackexcept le rack où la première réplique a été écrite. Ensuite, la troisième réplique est placée sur une machine choisie au hasard dans ce deuxième rack. Si plus de trois réplicas par défaut sont spécifiés dans la configuration, les réplicas restants sont placés de manière aléatoire, avec la restriction de ne pas placer plus d'un réplica sur un nœud ni plus de deux réplicas sur le même rack.

Limitations de HDFS 1.0

HDFS 1.0 a établi Hadoop comme le premier leader open source pour le stockage de données volumineuses. Une partie de ce succès résulte de décisions architecturales qui ont éliminé une partie de la complexité du stockage distribué, mais ces choix n’ont pas été sans compromis. Principales limitations de la version 1.0 version incluse:

  • No Control over the Distributions of Blocks
    Le modèle de réplication de bloc de HDFS est l'épine dorsale de sa haute disponibilité. Cela peut s'avérer très efficace et évite aux administrateurs et aux développeurs de se préoccuper du niveau de stockage des blocs. Toutefois, comme il ne tient pas compte de l'utilisation de l'espace ou de la situation en temps réel des nœuds, les administrateurs de cluster peuvent avoir besoin d'un programme d'équilibrage. redistribuer des blocs.

  • The NameNode: A Single Point of Failure
    Limitation plus importante que la distribution des blocs, le NameNode représente un point de défaillance unique. En cas d'échec du processus ou de la machine, l'intégralité du cluster est indisponible jusqu'au redémarrage du serveur NameNode. Même après son redémarrage, il doit recevoir les messages de pulsation de chaque nœud du cluster avant qu'ils ne soient réellement disponibles, ce qui prolonge la panne, notamment en cas de perte importante. grappes.

En dépit de ces limitations, HDFS a été une contribution majeure au travail avec le Big Data.

MapReduce 1.0

La deuxième couche de Hadoop, MapReduce, est chargée du traitement par lots des données stockées sur HDFS. La mise en oeuvre par Hadoop du modèle de programmation MapReduce de Google permet aux développeurs d’utiliser les ressources fournies par HDFS sans avoir besoin d’expérience des systèmes parallèles et distribués.

Comment MapReduce 1.0 fonctionne

Supposons que nous avons une collection de texte et que nous voulons savoir combien de fois chaque mot apparaît dans la collection. Le texte étant distribué sur de nombreux serveurs, les tâches de mappage sont exécutées sur tous les nœuds du cluster contenant des blocs de données dans la collection. Chaque mappeur charge les fichiers appropriés, les traite et crée une paire clé-valeur pour chaque occurrence.

Ces cartes ne contiennent que les données du nœud unique. Elles doivent donc être mélangées pour que toutes les valeurs ayant la même clé puissent être envoyées à un réducteur. Lorsque le réducteur est terminé, la sortie est écrite sur le disque du réducteur. Ce modèle de communication implicite évite aux utilisateurs Hadoop de déplacer explicitement les informations d'une machine à une autre.

Nous allons illustrer cela avec quelques phrases:

Elle vend des coquillages sur six rivages.
Elle vend bien des coquillages.

MAPPING         SHUFFLING           REDUCING
{she, 1}        {she, 1, 1}         {she, 2}
{sells, 1}      {sells, 1, 1}       {sells, 2}
{seashells, 1}  {seashells, 1, 1}   {seashells, 2}
{by, 1}         {by, 1}             {by, 1}
{six, 1}        {six, 1}            {six, 1}
{seashores, 1}  {seashores, 1, 1}   {seashores, 2}
{she, 1}        {sure, 1}           {sure, 1}
{sure, 1}       {well, 1}           {well, 1}
{sells}
{seashells, 1}
{well, 1}

Si ce mappage était effectué en séquence sur un jeu de données volumineux, cela prendrait trop de temps, mais effectué en parallèle puis réduit, il deviendrait évolutif pour les jeux de données volumineux.

Les composants de niveau supérieur peuvent se connecter à la couche MapReduce pour fournir des fonctionnalités supplémentaires. Par exemple, Apache Pig fournit aux développeurs un langage pour écrire des programmes d'analyse de données en faisant abstraction des idiomes Java MapReduce à un niveau supérieur, similaire à celui utilisé par SQL pour les bases de données relationnelles. Apache Hive prend en charge l'analyse de données et la création de rapports avec une interface de type SQL avec HDFS. Il résume les requêtes de l'API Java MapReduce pour fournir une fonctionnalité de requête de haut niveau aux développeurs. De nombreux composants supplémentaires sont disponibles pour Hadoop 1.x, mais l’écosystème a été limité par certaines limitations clés de MapReduce.

Limitations de MapReduce 1

  • Tight coupling between MapReduce and HDFS
    Dans l'implémentation 1.x, les responsabilités de la couche MapReduce s'étendent au-delà du traitement des données, pour inclure la gestion des ressources de cluster et sont étroitement couplées à HDFS. Cela signifie que les développeurs de modules complémentaires pour 1.x doivent écrire des programmes MapReduce multi-passes, que cela convienne ou non pour la tâche, car MapReduce est le seul moyen d'accéder au système de fichiers.

  • Static Slots for Data Analysis
    Le mappage et la réduction ont lieu sur les DataNodes, ce qui est essentiel pour travailler avec le Big Data, mais seul un nombre limité et statique d'emplacements à usage unique est disponible sur chaque DataNode. Les emplacements de mappage peuvent uniquement mapper et les emplacements de réduction ne peuvent que réduire. Le nombre est défini dans la configuration sans capacité d’ajustement dynamique. Ils sont donc inactifs et donc perdus chaque fois que la charge de travail du cluster ne correspond pas à la configuration. La rigidité de l'attribution de créneaux empêche également les applications non-MapReduce de planifier correctement.

  • The JobTracker: A Single Point of Failure
    Les applications Hadoop soumettent des tâches MapReduce au JobTracker, qui à son tour distribue ces tâches à des nœuds de cluster spécifiques en localisant un TaskTracker avec des emplacements disponibles ou géographiquement à proximité des données. TaskTracker informe le JobTracker si une tâche échoue. JobTracker peut resoumettre le travail, marquer l'enregistrement à exclure du traitement ultérieur ou éventuellement mettre en liste noire un TaskTracker non fiable, mais en cas d'échec de JobTracker pour une raison quelconque, toutes les tâches MapReduce sont interrompues.

Améliorations dans Hadoop 2.x

La branche 2.x de Hadoop, publiée en décembre 2011, a introduit quatre améliorations majeures et corrigé les principales limitations de la version 1. Hadoop 2.0 a introduit la fédération HDFS, qui a supprimé le NameNode en tant que contrainte de performance et en tant que point de défaillance unique. En outre, il a dissocié MapReduce de HDFS avec l'introduction de YARN (Yet Another Resource Negotiator), ouvrant ainsi l'écosystème de produits complémentaires en permettant aux modèles de traitement non MapReduce d'interagir avec HDFS et de contourner la couche MapReduce.

1 - Fédération HDFS

La fédération HDFS introduit une séparation claire entre espace de noms et stockage, rendant possible la création de plusieurs espaces de noms dans un cluster. Cela apporte quelques améliorations clés:

  • Namespace scalability La possibilité d'ajouter plus de NameNodes à un cluster permet une mise à l'échelle horizontale. Les grands clusters ou les clusters contenant de nombreux petits fichiers peuvent bénéficier de l'ajout de NameNodes.

  • Performance gains Le NameNode unique du débit de lecture / écriture limité du système de fichiers 1.x. Plusieurs NameNodes atténuent cette contrainte sur les opérations du système de fichiers.

  • Isolation between namespaces Dans les environnements multi-locataires avec un seul NameNode, il était possible qu'un seul voisin bruyant affecte tous les autres utilisateurs du système. Avec la fédération, il est devenu possible d'isoler les résidents du système.

Comment fonctionne HDFS Federation

Les NameNodes fédérés gèrent l'espace de noms du système de fichiers. Ils opèrent indépendamment et ne se coordonnent pas. Au lieu de cela, les DataNodes du cluster s'enregistrent avec chaque NameNode, en envoyant des pulsations et des rapports de bloc et en gérant les commandes entrantes à partir du NameNode.

Les blocs sont répartis sur le stockage commun avec la même réplication aléatoire que celle décrite dans Hadoop 1.x. Tous les blocs appartenant à un seul espace de noms sont appelés pool de blocs. Ces pools sont gérés indépendamment, ce qui permet à un espace-noms de générer des ID de bloc pour les nouveaux blocs sans coordination avec d'autres espaces-noms. La combinaison d'un espace de noms et de son pool de blocs s'appelle un volume d'espace de noms, qui forme une unité autonome. Ainsi, lorsque l'un des NameNodes fédérés est supprimé, son pool de blocs est également supprimé.

Outre l'amélioration de l'évolutivité, des performances et de l'isolation fournies par l'introduction de la fédération NameNode, Hadoop 2.0 a également introduit la haute disponibilité pour les NameNodes.

2 - Haute disponibilité de NameNode

Avant Hadoop 2.0, en cas d'échec de NameNode, l'intégralité du cluster était indisponible jusqu'à son redémarrage ou son apparition sur un nouvel ordinateur. Les mises à niveau du logiciel ou du matériel de NameNode ont également créé des fenêtres d'indisponibilité. Pour éviter cela, Hadoop 2.0 a implémenté une configuration active / passive pour permettre un basculement rapide.

Comment NameNode HA fonctionne

Deux machines distinctes sont configurées en tant que NameNodes, l'une active, l'autre en veille. Ils partagent l'accès à un répertoire commun sur un périphérique de stockage partagé et lorsqu'une modification est effectuée par le nœud actif, il enregistre la modification dans le fichier journal stocké dans ce répertoire commun. Le noeud de secours surveille en permanence le répertoire et, lorsque des modifications sont apportées, il les applique à son propre espace de noms. Si le nœud actif échoue, le serveur en attente lit les modifications non appliquées du stockage partagé, puis se présente comme actif.

3 - FILS

Hadoop 2.0 a découplé MapReduce de HDFS. La gestion des charges de travail, la multi-location, les contrôles de sécurité et les fonctionnalités de haute disponibilité ont été intégrées dans YARN (Yet Another Resource Negotiator). YARN est, par nature, un système d’exploitation distribué à grande échelle pour les applications Big Data qui rend Hadoop bien adapté à la fois à MapReduce et à d’autres applications qui ne peuvent attendre le traitement par lots. YARN a éliminé la nécessité de travailler avec le framework MapReduce de latence élevée et souvent exigeant en E / S, permettant ainsi l’utilisation de nouveaux modèles de traitement avec HDFS. Decoupled-MapReduce est resté en tant que cadre orienté utilisateur exclusivement consacré à l'exécution de la tâche à laquelle il était destiné: le traitement par lots.

Vous trouverez ci-dessous certains des modèles de traitement disponibles pour les utilisateurs de Hadoop 2.x:

  • Batch Processing
    Les systèmes de traitement par lots ne sont pas interactifs et ont accès à toutes les données avant le début du traitement. De plus, les questions explorées pendant le traitement doivent être connues avant le début du traitement. Le traitement par lots est généralement une latence élevée, la vitesse des tâches de traitement Big Data étant généralement mesurée en minutes ou plus.

    Where batch processing shines: Indexation des données, exploration du Web et analyse des données

    Some programs that can do this for Hadoop: MapReduce, Tez, Spark, Hive et Flink

  • Interactive Processing
    Des systèmes de traitement interactifs sont nécessaires lorsque vous ne connaissez pas toutes vos questions à l’avance. Au lieu de cela, un utilisateur interprète la réponse à une requête, puis formule une nouvelle question. Pour prendre en charge ce type d'exploration, la réponse doit être renvoyée beaucoup plus rapidement qu'un travail MapReduce typique.

    Where interactive processing shines: Le traitement interactif prend en charge l'exploration des données.

    Some programs that do this for Hadoop: Impala, Drill, HAWQ, Presto, Vortex et Vertica SQL, Tez

  • Stream Processing
    Les systèmes de traitement de flux prennent de grandes quantités de points de données discrets et exécutent une requête continue pour produire des résultats en temps quasi réel lorsque de nouvelles données arrivent dans le système.

    Where stream processing shines: Chaque fois que vous avez déjà des données numériques générées en continu. Les exemples incluent la surveillance de l'opinion publique à l'égard d'un problème, d'un événement ou d'un produit dans les médias sociaux afin de suivre les tendances émergentes ou de surveiller les journaux du serveur.

    Some programs that do this for Hadoop: Spark Stream, tempête

  • Graph Processing
    Les algorithmes de graphes nécessitent généralement une communication entre les sommets ou les sauts afin de déplacer une arête d'un sommet à un autre, ce qui a nécessité beaucoup de surcharge inutile lors du passage à travers le MapReduce 1.x.

    Les graphiquesWhere graphing shines: sont idéaux pour montrer les relations non linéaires entre les choses: les relations d'amis de Facebook, le suiveur de Twitter, les bases de données graphiques distribuées comme au cœur des sites de médias sociaux.

    Some programs that do this for Hadoop: Apache Giraph, GraphX ​​d'Apache Spark, Hama, Titan

Ce ne sont là que quelques exemples de modèles et d’outils de traitement alternatifs. Pour un guide complet de l'écosystème open source Hadoop, y compris des modèles de traitement autres que MapReduce, consultez lesThe Hadoop Ecosystem Table

4 - Haute disponibilité de ResourceManager

À sa sortie, YARN avait son propre goulot d’étranglement: le ResourceManager. Le JobTracker unique dans MapReduce 1.x gérait la gestion des ressources, la planification des travaux et la surveillance des travaux. Les premières versions de YARN ont amélioré cette situation en divisant les responsabilités entre un gestionnaire de ressources global et un ApplicationMaster par application. ResourceManager a suivi les ressources de cluster et les applications de planification, telles que les tâches MapReduce, mais était un point de défaillance unique jusqu'à la version 2.4, qui introduisait une architecture Active / Standby.

Dans Hadoop 2.4, le gestionnaire de ressources unique a été remplacé par un seul ResourceManageractive et un ou plusieurs standbys. En cas de défaillance du gestionnaire ResourceManager actif, les administrateurs peuvent déclencher manuellement la transition du mode veille au mode actif. Ils peuvent également activer le basculement automatique en ajoutant Apache Zookeeper à leur pile. Parmi les autres responsabilités de Zookeeper en matière de coordination des tâches, il peut suivre l’état des nœuds YARN et, en cas de défaillance, déclencher automatiquement la transition en veille.

Hadoop 3.x

Au moment de la rédaction de cet article, Hadoop 3.0.0-alpha1 est disponible pour des tests. La branche 3.x a pour objectif d’apporter des améliorations telles que le codage d’effacement HDFS pour conserver l’espace disque, le service de timeline de YARN pour améliorer son évolutivité, sa fiabilité et sa facilité d’utilisation, la prise en charge de plus de deux NameNodes et l’équilibreur Intra-datanode, etc. Pour en savoir plus, consultez l'aperçu demajor changes.

Conclusion

Dans cet article, nous avons examiné l'évolution de Hadoop pour répondre aux besoins d'ensembles de données de plus en plus volumineux. Si vous souhaitez expérimenter Hadoop, vous pouvez jeter un œil àInstalling Hadoop in Stand-Alone Mode on Ubuntu 16.04. Pour plus d'informations sur les concepts de Big Data en général, consultezAn Introduction to Big Data Concepts and Terminology.