FIL - MapReduce 2

YARN signifie encore un autre négociateur de ressources.

Bref historique:

YARN a été développé par Yahoo en 2010 en remplacement de Map Reduce 1. Il a pu surmonter les inconvénients présents dans Map Reduce 1.

Introduction

Dans Map Reduce 1 Job Tracker a été utilisé à la fois pour la planification des tâches et la surveillance des tâches. Cela a conduit au goulot d’étranglement de l’évolutivité du cluster. YARN sépare ces deux rôles en 2 démons distincts qui sont Resource Manager et Application Master.

Anatomie du fil

Composants

*** Gestionnaire de ressources *** : C’est l’autorité ultime qui alloue les ressources entre toutes les applications du système. Il est également responsable de l’allocation du conteneur dans lequel le maître d’application démarrera et de son initialisation après l’allocation du conteneur pour le maître d’application.

Node Manager : il est responsable de la surveillance des conteneurs et de leur utilisation des ressources sur n’importe quel nœud donné sur lequel il s’exécute.

[![entrez la description de l’image ici][1]][1]

*** Application Master *** : il est responsable de la négociation avec le gestionnaire de ressources pour l’allocation des ressources requises sur le nœud de données pour l’exécution de n’importe quel travail et également de la coordination avec le gestionnaire de nœud pour exécuter le travail et surveiller les conteneurs et leur consommation de ressources.

Container : Il représente les ressources telles que le processeur, la mémoire, le disque, etc. nécessaires au traitement de n’importe quel travail. C’est le résultat d’une allocation de ressources réussie par le gestionnaire de ressources. Le conteneur accorde le droit au maître d’application d’utiliser une quantité spécifique de ressources sur une machine spécifique (nœud) dans un cluster. Il peut y avoir plusieurs conteneurs sur la même machine.

Processus d’exécution du travail [![entrez la description de l’image ici][2]][2]

  1. L’utilisateur/client soumet l’application et les spécifications pour le maître d’application sont générées.

  2. Le gestionnaire de ressources prend la responsabilité d’allouer le conteneur spécifié dans lequel le maître d’application démarrera, puis il lance le maître d’application. Chaque travail obtient son propre maître d’application séparé.

  3. Le maître d’application démarre et s’enregistre auprès du gestionnaire de ressources. Cela aide le client à connaître certains détails requis de l’exécution des travaux directement via Application Master.

  4. Application Master fait ensuite une demande au gestionnaire de ressources pour l’allocation des conteneurs avec les ressources requises afin d’exécuter le travail sur les nœuds. Cette demande de ressources est effectuée via le protocole de demande de ressources (RRP).

  5. Une fois l’allocation de conteneurs réussie, le maître d’application présente les conteneurs au gestionnaire de nœuds. Il fournit également des détails sur l’allocation pour le lancement de conteneurs sur le nœud. Avant de démarrer le conteneur, Node Manager vérifie l’allocation du conteneur avec Resource Manager pour éviter les fausses allocations.

  6. Lorsque le code d’application s’exécute dans le conteneur, le conteneur fournit les informations appropriées à son maître d’application via le protocole ASP (Application Specific Protocol).

  7. Pendant l’exécution, le client se connecte directement au maître d’application pour obtenir l’état, la progression, etc. via le protocole spécifique à l’application.

  8. Une fois le processus de l’application soumise par l’utilisateur terminé, Application Master se désenregistre auprès de Resource Manager et s’arrête, permettant au conteneur qui lui est alloué de se libérer et de se réutiliser. Parallèlement, tous les conteneurs acquis pour le travail sont à nouveau libérés. .

[1] : https://i.stack.imgur.com/N7VCT.png [2] : https://i.stack.imgur.com/lxddU.png