ResourceManager (rm) : traiter les demandes des clients, démarrer / surveiller ApplicationMaster, surveiller NodeManager, l'allocation des ressources et la planification;

NodeManager (nm) : gestion des ressources sur un seul nœud, traitement des commandes depuis ResourceManager et traitement des commandes depuis ApplicationMaster;

ApplicationMaster (am) : segmentation des données, application des ressources pour les applications et affectation aux tâches internes, surveillance des tâches et tolérance aux pannes.

Conteneur : une abstraction de l'environnement de fonctionnement de la tâche, qui encapsule les informations relatives à l'opération de la tâche, telles que le processeur, la mémoire et d'autres ressources multidimensionnelles, ainsi que les variables d'environnement et les commandes de démarrage.

Section 2 Soumission des tâches de fil (mécanisme de travail)

YARN du processus de soumission d'emploi ( pour pouvoir le répéter )

Soumission du devoir

Étape 1: le client appelle la méthode job.waitForCompletion pour soumettre des travaux MapReduce à l'ensemble du cluster.

Étape 2: Le client demande un identifiant de travail auprès de RM.

Étape 3: RM renvoie le chemin de soumission et l'ID de travail de la ressource de travail au client.

Étape 4: Le client soumet le package jar, coupe les informations et les fichiers de configuration au chemin de soumission des ressources spécifié.

Étape 5: Une fois que le client a soumis les ressources, il s'applique au RM pour exécuter MrAppMaster.

Initialisation du travail

Étape 6: Lorsque RM reçoit la demande du client, il ajoute le travail au planificateur de capacité.

Étape 7: Un certain NM libre reçoit le travail.

Étape 8: Le NM crée un conteneur et produit MRAppmaster.

Étape 9: Téléchargez les ressources soumises par le client au local.

Attribution de tâche

Étape 10: MrAppMaster s'applique à RM pour exécuter plusieurs ressources de tâches MapTask.

Étape 11: Le RM affecte la tâche MapTask aux deux autres NodeManagers, et les deux autres NodeManagers reçoivent les tâches et créent des conteneurs respectivement.

Opération de tâche

Étape 12: MR envoie le script de démarrage du programme aux deux
NodeManagers qui ont reçu la tâche. Les deux NodeManagers démarrent MapTask respectivement et MapTask trie les partitions de données.

Étape 13: Une fois que MrAppMaster a attendu que toutes les MapTasks s'exécutent, demandez un conteneur à partir de RM et exécutez ReduceTask.

Étape 14: ReduceTask obtient les données de la partition correspondante de MapTask.

Étape 15: Une fois le programme exécuté, MR demandera à RM de se déconnecter.

Mises à jour de la progression et du statut Les tâches dans YARN renvoient leur progression et leur statut au gestionnaire d'applications, et le client demande des mises à jour de progression au gestionnaire d'applications toutes les secondes (définies par mapreduce.client.progressmonitor.pollinterval) et les affiche à l'utilisateur.

Devoirs terminés

En plus de demander la progression du travail au gestionnaire d'applications, le client appelle waitForCompletion () toutes les 5 secondes pour vérifier si le travail est terminé.

L'intervalle de temps peut être défini par mapreduce.client.completion.pollinterval.

Une fois le travail terminé, le gestionnaire d'applications et le conteneur nettoient l'état du travail. Les informations sur le travail seront stockées par le serveur d'historique des travaux pour une vérification ultérieure par l'utilisateur.

Section 3 Stratégie de planification des fils

Il existe trois principaux types de planificateurs de travaux Hadoop: FIFO , Capacity Scheduler et Fair Scheduler .

Le planificateur de ressources par défaut de Hadoop 2.9.2 est Capacity Scheduler .

Vous pouvez afficher yarn-default.xml

1. FIFO (premier entré, premier planificateur sorti)

2. Planificateur de capacité (planificateur par défaut de Capacity Scheduler)

La stratégie de planification utilisée par Apache Hadoop par défaut. Le planificateur de capacité permet à plusieurs organisations de partager l'ensemble du cluster, et chaque organisation peut obtenir une partie de la puissance de calcul du cluster. En attribuant une file d'attente dédiée à chaque organisation, puis en attribuant une certaine ressource de cluster à chaque file d'attente, l'ensemble du cluster peut fournir des services à plusieurs organisations en configurant plusieurs files d'attente. En outre, la file d'attente peut être divisée verticalement afin que plusieurs membres d'une organisation puissent partager les ressources de la file d'attente. Dans une file d'attente, la planification des ressources est basée sur une stratégie de premier entré, premier sorti (FIFO).

3. Fair Scheduler (Fair Scheduler, le planificateur par défaut utilisé par la version CDH de hadoop)

L'objectif de conception du planificateur équitable est d'allouer des ressources équitables pour toutes les applications (la définition de l'équité peut être définie par des paramètres). Une planification équitable peut également être effectuée entre plusieurs files d'attente.

Par exemple, supposons qu'il y ait deux utilisateurs A et B, et qu'ils aient chacun une file d'attente.
Lorsque A démarre un travail et que B n'a aucune tâche, A obtiendra toutes les ressources du cluster; lorsque B démarre un travail, le travail de A continuera à s'exécuter, mais après un certain temps, les deux tâches obtiendront chacune la moitié des ressources Ressources du cluster. Si B démarre le deuxième travail à ce moment et que d'autres travaux sont toujours en cours d'exécution, il partagera les ressources de la file d'attente B avec le premier travail de B, c'est-à-dire que les deux travaux de B seront utilisés pendant un quart Les ressources de cluster de A, mais Le travail de A est toujours utilisé pour la moitié des ressources du cluster, le résultat est que les ressources sont finalement partagées à parts égales entre les deux utilisateurs

Section 4 Configuration de l'isolation des ressources multi-locataires Yarn

Les ressources du cluster de fils sont définies sur deux files d'attente, A et B. La file d'attente
A est définie pour occuper 70% des ressources et est principalement utilisée pour exécuter des tâches chronométrées régulières, et la
file d'attente B est définie pour occuper 30% des ressources pour exécuter des tâches temporaires.
deux files d'attente peuvent interagir. Partage des ressources, si les ressources de la file d'attente A sont pleines et que les ressources de la file d'attente B sont plus abondantes, la file d'attente A peut utiliser les ressources de la file d'attente B pour maximiser l'utilisation globale des ressources

Choisissez d'utiliser la stratégie de planification Fair Scheduler! !

Placement spécifique

1. yarn-site.xml

<!-- 指定任务调度使⽤fairScheduler的调度⽅式 -->
<property>
     <name>yarn.resourcemanager.scheduler.class</name>
     <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
     <description>In case you do not want to use the default scheduler</description>
</property>

2. Créez le fichier fair-scheduler.xml Créez le fichier
dans le répertoire d'installation Hadoop / etc / hadoop

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<allocations>
      <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
      <queue name="root" >
          <queue name="default">
              <aclAdministerApps>*</aclAdministerApps>
              <aclSubmitApps>*</aclSubmitApps>
              <maxResources>9216 mb,4 vcores</maxResources>
              <maxRunningApps>100</maxRunningApps>
              <minResources>1024 mb,1vcores</minResources>
              <minSharePreemptionTimeout>1000</minSharePreemptionTimeout>
              <schedulingPolicy>fair</schedulingPolicy>
              <weight>7</weight>
          </queue>
          <queue name="queue1">
              <aclAdministerApps>*</aclAdministerApps>
              <aclSubmitApps>*</aclSubmitApps>
              <maxResources>4096 mb,4vcores</maxResources>
              <maxRunningApps>5</maxRunningApps>
              <minResources>1024 mb, 1vcores</minResources>
              <minSharePreemptionTimeout>1000</minSharePreemptionTimeout>
              <schedulingPolicy>fair</schedulingPolicy>
              <weight>3</weight>
          </queue>
      </queue> 
      <queuePlacementPolicy>
         <rule create="false" name="specified"/>
          <rule create="true" name="default"/>
      </queuePlacementPolicy>
</allocations>

Vérification des limites

La deuxième partie de l'analyse du code source principal d'Apache Hadoop HDFS

Section 1 Préparation de la lecture du code source

1. Téléchargez le code source officiel d'Apache Hadoop-2.9.2
2. Importez le code source dans idea

Commencez l'idée et choisissez d'importer dans l'interface d'invite

Attendez la fin du téléchargement et de la résolution des dépendances, l'importation du code source est réussie! !

Section 2 Processus de démarrage de NameNode

Commande pour démarrer le cluster HDFS

start-dfs.sh

Cette commande lancera le NameNode et le DataNode de Hdfs. Le NameNode est démarré principalement via la
classe org.apache.hadoop.hdfs.server.namenode.NameNode.

Nous nous concentrons sur ce que fait le NameNode pendant le processus de démarrage (les détails techniques qui s'écartent de la ligne principale ne seront pas étudiés)

Pour le processus de démarrage de l'analyse, deux parties du code sont principalement concernées:

La principale responsabilité de namenode est la gestion des méta-informations de fichiers et le mappage des blocs de données. En conséquence, le processus de démarrage du namenode doit se concentrer sur le fil de travail communiquant avec le client et le datanode, le mécanisme de gestion des méta-informations de fichier et le mécanisme de gestion des blocs de données. Parmi eux, RpcServer est principalement responsable de la communication avec les clients et les datanodes, et FSDirectory est principalement responsable de la gestion des méta-informations des fichiers.

Section 3 Processus de démarrage de DataNode

La classe principale du datanode est DataNode, recherchez d'abord DataNode.main ()

Section 4 Processus d'écriture des données

Il existe de nombreux threads de travail importants sur datanode. Parmi eux, DataXceiverServer et BPServiceActor sont les plus étroitement liés au processus d'écriture de blocs de données. Le client et le nœud de données effectuent principalement la lecture / écriture du bloc de données via le protocole de transfert de données.

DataTransferProtocol est utilisé pour diffuser la communication entre les clients et les nœuds de données dans tout le pipeline. Parmi eux, DataTransferProtocol - writeBlock () est responsable de l'écriture des blocs de données:

Section 5 Comment NameNode prend en charge l'accès simultané élevé (mécanisme de double tampon)

Quels types de problèmes seront rencontrés lors de l'accès simultané à NameNode:

Après avoir appris le mécanisme de gestion des métadonnées de HDFS, le client demande au NameNode de modifier un élément de métadonnées à chaque fois

(Plutôt que de postuler pour télécharger un fichier, vous devez rédiger un journal des modifications, qui comprend deux étapes:

Écrire sur le disque local - modifie le fichier

Il est transmis au cluster JournalNodes via le réseau (cluster Hadoop HA combiné avec zookeeper pour apprendre).

La difficulté de la haute concurrence réside dans la sécurité multi-thread des données et l'efficacité de chaque opération! !

Pour la sécurité multi-thread:

NameNode a quelques principes lors de l'écriture du journal des modifications:

Lors de l'écriture de données dans edits_log, il est nécessaire de s'assurer que chaque édition a un transactionId (txid pour faire court) qui augmente dans l'ordre global, afin que l'ordre des modifications puisse être identifié.

Si vous voulez vous assurer que le txid de chaque modification est incrémenté, vous devez ajouter un verrou de synchronisation. Autrement dit, lorsque chaque thread modifie les métadonnées, lorsque vous souhaitez écrire une modification, vous devez faire la queue pour acquérir le verrou afin de générer un txid incrémentiel, qui représente le numéro de série des modifications à écrire cette fois.

Le problème qui en résulte:
si chaque fois qu'un bloc de code verrouillé est généré, txid est généré, puis le journal des modifications du fichier disque est écrit, ce type d'opération de verrouillage de synchronisation et d'écriture sur disque prend beaucoup de temps! !

Solution d'optimisation HDFS
La raison principale du problème est que la sérialisation et la mise en file d'attente lors de l'écriture des modifications entraînent une augmentation des opérations d'écriture sur txid + sur le disque prend du temps,

Solution HDFS
1. Sérialisation: utiliser le verrouillage de segment
2. Ecrire sur le disque: utiliser la double mise en mémoire tampon

Dans le mécanisme de verrouillage segmenté, chaque thread acquiert le verrou pour la première fois en séquence, génère un txid séquentiellement croissant, puis écrit les modifications dans la zone de mémoire double tampon 1, puis libère le verrou pour la première fois. Profitant de cet écart, les threads suivants peuvent acquérir à nouveau le verrou pour la première fois, puis écrire immédiatement leurs propres modifications dans la mémoire tampon.

Le programme du mécanisme de double tampon ouvrira deux espaces mémoire identiques, dont l'un est bufCurrent, et les données générées seront directement écrites dans ce bufCurrent, et l'autre s'appelle bufReady, et les données sont écrites dans bufCurrent (jusqu'à un après fixant la norme), les deux mémoires seront échangées. Échangez directement la zone 1 et la zone 2 à double tampon. Il est garanti que toutes les demandes d'écriture de données du client sont reçues de la mémoire de fonctionnement et non sur le disque de manière synchrone.

Analyse du code source à double tampon

Étendre la présentation des nouvelles fonctionnalités de Hadoop 3.x

De nombreuses fonctionnalités ont été améliorées dans Hadoop3.x. Dans Hadoop3.x, jdk1.7 n'est plus autorisé et jdk1.8 ou supérieur est requis. En effet, Hadoop 2.0 a été développé sur la base de JDK 1.7, et JDK 1.7 a été interrompu en avril 2015, ce qui a directement obligé la communauté Hadoop à rééditer une nouvelle version Hadoop basée sur JDK 1.8, qui est exactement Hadoop 3.x. Hadoop 3.x ajustera l'architecture du projet à l'avenir, et mapreduce sera basé sur la mémoire + io + disque pour traiter les données ensemble.

Hadoop 3.x a introduit certaines fonctions et optimisations importantes, notamment le codage effaçable HDFS, la prise en charge de plusieurs Namenode, l'optimisation MR NativeTask, la mémoire basée sur le groupe de contrôle YARN et l'isolation des E / S de disque, le redimensionnement du conteneur YARN, etc.

L'adresse officielle du document Hadoop3.x est la suivante:

http://hadoop.apache.org/docs/r3.0.1/

Améliorations courantes des nouvelles fonctionnalités de Hadoop3.x

Améliorations courantes de Hadoop:

1. Rationalisez le noyau Hadoop, notamment en supprimant les API et implémentations obsolètes, en remplaçant l'implémentation du composant par défaut par l'implémentation la plus efficace (par exemple, en changeant l'implémentation par défaut de FileOutputCommitter en v2, en supprimant hftp et en le remplaçant par webhdfs, et en supprimant le sous Hadoop -implementation Bibliothèque de sérialisation org.apache.hadoop.Records

2. L'isolation Lasspath est utilisée pour éviter les conflits entre différentes versions de packages jar. Par exemple, lorsque Google Guava mélange Hadoop, HBase et Spark, il est facile de provoquer des conflits. (Https://issues.apache.org/jira/browse / HADOOP -11656)

3. Reconstruction du script Shell. Hadoop 3.0 a remanié les scripts de gestion Hadoop, corrigé un grand nombre de bogues, ajouté de nouvelles fonctionnalités et pris en charge les commandes dynamiques. La méthode d'utilisation est cohérente avec la version précédente. (Https://issues.apache.org/jira/browse/HADOOP-9902)

Amélioration HDFS des nouvelles fonctionnalités de Hadoop3.x

Le changement le plus significatif dans Hadoop3.x est HDFS. HDFS est calculé par le dernier bloc noir. Selon le principe du calcul récent, le bloc noir local est ajouté à la mémoire, d'abord calculé, via la zone de calcul de la mémoire partagée IO, et finalement formé rapidement le résultat du calcul.

1. HDFS prend en charge le codage d'effacement des données, ce qui permet à HDFS d'économiser la moitié de l'espace de stockage sans réduire la fiabilité. (Https://issues.apache.org/jira/browse/HDFS-7285)

2. Prise en charge de Multi-NameNode, c'est-à-dire prise en charge du déploiement d'un namenodes actif et de plusieurs namenodes de secours dans un cluster. Remarque: la fonctionnalité multi-ResourceManager a été prise en charge dans hadoop 2.0. (Https://issues.apache.org/jira/browse/HDFS-6440)

L'adresse du document officiel pour ces deux caractéristiques:

http://hadoop.apache.org/docs/r3.0.1/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html

http://hadoop.apache.org/docs/r3.0.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

Amélioration de YARN des nouvelles fonctionnalités de Hadoop3.x

1. Isolation mémoire basée sur Cgroup et isolation IO Disk (https://issues.apache.org/jira/browse/YARN-2619)

2. Utiliser le conservateur pour mettre en œuvre l'élection du chef de la RM (https://issues.apache.org/jira/browse/YARN-4438)

3. containerresizing （https://issues.apache.org/jira/browse/YARN-1197）

4. Timelineserver nouvelle génération （https://issues.apache.org/jira/browse/YARN-2928）

Adresse du document officiel:

http://hadoop.apache.org/docs/r3.0.1/hadoop-yarn/hadoop-yarn-site/TimelineServiceV2 .html

MapReduce amélioration des nouvelles fonctionnalités de Hadoop3.x

1. Optimisation Tasknative. Ajout de l'implémentation du collecteur de sortie de carte C / C ++ (y compris Spill, Sort, IFile, etc.) à MapReduce, et peut basculer vers cette implémentation en ajustant les paramètres de niveau de travail. Pour les applications gourmandes en lecture aléatoire, ses performances peuvent être améliorées d'environ 30%. (Https://issues.apache.org/jira/browse/MAPREDUCE-2841)

2. Les paramètres de la mémoire MapReduce sont automatiquement déduits. Dans Hadoop 2.0, la définition des paramètres de mémoire pour les tâches MapReduce est très lourde, impliquant deux paramètres: mapreduce. {Map, reduction} .memory.mb et mapreduce. {Map, reduction} .java.opts. Une fois que les paramètres sont déraisonnables, cela Si le premier est défini sur 4096 Mo, mais que le second est défini sur "-Xmx2g", les 2g restants ne peuvent pas être utilisés par le tas Java. (Https://issues.apache.org/jira/browse/MAPREDUCE-5785)

Autres nouvelles fonctionnalités de Hadoop 3.x

1. Ajoutez de nouveaux composants hadoop-client-api et hadoop-client-runtime à un seul package jar pour résoudre le problème d'incompatibilité des dépendances (https://issues.apache.org/jira/browse / HADOOP-11804)
2. Prend en charge le système de fichiers distribué Azure de Microsoft et le système de fichiers distribué aliyun d'Arab

3.1.4 Hadoop, Yarn, stratégie de planification des ressources, analyse du code source principal d'Apache Hadoop, aperçu des nouvelles fonctionnalités de Hadoop 3.x

Partie 7 Planification des ressources YARN

Section 1 Architecture du fil