Notes De Révision Du Cours Sur L'architecture Des Big Data

1 Introduction

Les exigences des systèmes de big data incluent les exigences en matière de données, les exigences fonctionnelles, les exigences de performance (haute performance, haute disponibilité, haute extensibilité, haute tolérance aux pannes, sécurité, etc.), les exigences des scénarios de calcul.

Objectifs des systèmes distribués/clusters ou du traitement des big data : haute performance, haute disponibilité, tolérance aux pannes, extensibilité, où la haute performance comprend trois indicateurs de mesure : temps de réponse (latence), débit, taux d’utilisation des ressources ; indicateurs de haute disponibilité : MTTF, MTTR, disponibilité=MTTF/(MTTF+MTTR)

Relation entre le big data et le cloud computing :

• Le cloud computing peut fournir des ressources de calcul suffisantes pour le traitement des big data.
• Le big data est une application typique des services de cloud computing.
• Le big data peut ne pas utiliser le cloud computing. Les scénarios typiques de calcul des big data incluent
• Traitement par lots
• Calcul en flux
• Requêtes interactives Les données statiques sont bornées, stockées de manière persistante, de grande capacité, adaptées au traitement par lots.

Les données en flux sont illimitées, produites en continu, nécessitent des fenêtres de données pour un traitement rapide et n’ont pas de fin visible.

2 Aperçu du cloud computing

2.1 Définition du cloud computing

• Le cloud computing est un modèle commercial de calcul. Il distribue les tâches de calcul dans un pool de ressources composé d’un grand nombre d’ordinateurs, permettant aux systèmes d’applications de récupérer la puissance de calcul, l’espace de stockage et les services d’information selon leurs besoins.
• Il fournit des services de calcul bon marché et dynamiquement extensibles à la demande via le réseau, c’est une pensée et un modèle de gestion des ressources universellement applicable.
• Le cloud computing compare les ressources de calcul à des nuages omniprésents, résultant de l’évolution de technologies telles que la virtualisation, le calcul distribué, le calcul utilitaire, l’équilibrage de charge, le calcul parallèle, le stockage en réseau, la sauvegarde à chaud, etc.

2.2 Caractéristiques du cloud computing

1. Virtualisation des ressources et gestion unifiée des pools
2. Échelle massive, haute disponibilité, haute extensibilité
3. Élasticité, services à la demande, auto-service
4. Accès ubiquitaire, facturation précise, coût faible

2.3 Trois modèles de service

1. Infrastructure en tant que service IaaS (Infrastructure as a Service)

Fournit des services de ressources de calcul tels que serveurs, stockage et réseau.

Principales fonctionnalités :

• Les utilisateurs paient IaaS à la demande, sans avoir besoin d’acheter un ensemble complet de matériel.
• L’infrastructure peut être étendue en fonction des besoins de traitement et de stockage.
• Réduit les coûts d’achat et de maintenance du matériel pour les entreprises.
• Les données sont dans le cloud, il n’y a pas de point de défaillance unique.

2. Plateforme en tant que service PaaS (Platform as a Service)

Fournit un environnement logiciel pour le développement, la gestion et la livraison, tel que système d’exploitation, base de données, middleware, plateforme de développement.

Principales fonctionnalités

• Fournit une plateforme et des outils de développement pour permettre aux éditeurs de logiciels de développer, tester, déployer et exécuter rapidement.
• Les éditeurs de logiciels se concentrent sur le développement sans se soucier de l’infrastructure sous-jacente.
• Les fournisseurs de cloud garantissent la sécurité, la fiabilité et la stabilité de la plateforme.

3. Logiciel en tant que service SaaS (Software as a Service)

Fournit des services logiciels dans le cloud via le réseau.

Principales fonctionnalités

• Les utilisateurs paient un abonnement pour le logiciel, accèdent directement aux applications logicielles via Internet, sans avoir besoin de gérer, installer ou mettre à jour le logiciel.
• Les données sont protégées dans le cloud, les pannes d’équipement ne provoquent pas de perte de données.
• Les ressources peuvent être étendues en fonction des besoins de service.

2.4 Quatre formes de service

Cloud public: infrastructure informatique détenue et exploitée par un fournisseur de services cloud tiers, et fournie via Internet.

Avantages : coût faible, pas besoin de maintenance, extensibilité à la demande, haute fiabilité et disponibilité.

Inconvénients : sécurité incontrôlable, ressources non personnalisables.

Cloud privé constitué de ressources de cloud computing dédiées à une entreprise ou organisation.

Avantages : par rapport au cloud public, ressources plus flexibles et sécurité plus élevée.

Inconvénients : coûts élevés de construction et de maintenance.

Cloud communautaire par plusieurs entreprises ou organisations

Cloud hybride, combinant les environnements de cloud public et privé via des connexions sécurisées, permettant le partage de données et d’applications entre différents environnements cloud.

– Haute contrôlabilité, actifs sensibles dans le cloud privé.

– Flexibilité, utilisation du cloud public à la demande.

– Rentabilité, extensibilité du cloud public.

2.5 Architecture du cloud computing

1. Couche de construction SOA

Encapsule les capacités de cloud computing en services Web standards et les intègre dans l’architecture SOA.

2. Couche middleware de gestion

Gestion des ressources de cloud computing et planification des nombreuses tâches d’application pour que les ressources servent efficacement et en toute sécurité les applications.

2.6 Technologies clés du cloud computing

Les technologies clés du cloud computing incluent principalement la virtualisation et la conteneurisation, la technologie de conteneurisation étant préférée ces dernières années par les développeurs car elle utilise le noyau du système d’exploitation partagé pour empaqueter les applications et leurs environnements d’exécution, offrant une virtualisation plus légère, plus rapide et moins coûteuse que la virtualisation.

2.6.1 Technologie de virtualisation

La virtualisation (Virtualization) est la technologie de base pour construire un environnement de cloud computing, abstrait et mappe les ressources informatiques en entités logiques virtuelles, dépassant les limites des ressources physiques pour une gestion unifiée.

◼ Virtualisation des serveurs : virtualise un ordinateur en plusieurs ordinateurs logiques

◼ Virtualisation du stockage : abstraction et gestion unifiée des équipements de stockage sous-jacents, fournissant des services de stockage indépendants

◼ Virtualisation du réseau : virtualise une carte réseau physique en plusieurs cartes réseau virtuelles, isolant différentes applications via des machines virtuelles

◼ Virtualisation des postes de travail : dissocie l’environnement de bureau de l’utilisateur de son équipement terminal, stocke l’environnement de bureau complet de chaque utilisateur chez le fournisseur, l’utilisateur accède à son bureau via le réseau

2.6.1.1 1. Virtualisation des serveurs

Machine virtuelle (Virtual Machine) VM

Virtualise un ordinateur (machine physique, serveur physique) en plusieurs ordinateurs logiques

Chaque machine virtuelle possède son propre “matériel”.

Le “matériel” de la machine virtuelle est simulé à partir du matériel de la machine physique.

Le travail exécuté par la machine virtuelle est en fait effectué par le matériel de la machine physique.

Moniteur de machine virtuelle (Virtual Machine Monitor) VMM

Le VMM est le système d’exploitation ou le logiciel qui permet de virtualiser une machine physique en machine virtuelle. Sa fonction principale est de fournir des ressources matérielles virtuelles aux machines virtuelles, de gérer et d’allouer ces ressources, et de garantir l’isolation entre les machines virtuelles.

Deux modes de fonctionnement du VMM

1. Mode hébergé (Hosted Mode) : le VMM fonctionne sur le système d’exploitation de la machine physique, installation et utilisation faciles, performances relativement faibles.

Dans la virtualisation hébergée, la couche de virtualisation est généralement appelée moniteur de machine virtuelle (VMM). Le VMM obtient des ressources en appelant le système d’exploitation hôte, réalisant la virtualisation du CPU, de la mémoire et des périphériques d’E/S. Les machines virtuelles créées par le VMM participent à la planification en tant que processus du système d’exploitation hôte. En mode hébergé, le VMM peut tirer parti des fonctionnalités du système d’exploitation hôte pour manipuler les périphériques matériels, mais les étapes intermédiaires entraînent une perte de performance significative.

2. Mode hyperviseur (Bare Metal Mode) : le VMM fonctionne directement sur le matériel de la machine physique, offrant des performances proches de celles de la machine physique.

Dans cette architecture, le VMM est un système d’exploitation, généralement appelé hyperviseur. Hyperviseur = OS + virtualisation, il possède les fonctionnalités d’un système d’exploitation traditionnel et des fonctionnalités de virtualisation, y compris le mappage des ressources virtuelles aux ressources physiques et l’isolation des systèmes de machines virtuelles. Il offre des performances proches de celles de la machine physique, mais prend en charge un nombre limité de périphériques d’E/S.

Classification des technologies de virtualisation des serveurs

Selon la méthode de traitement des instructions critiques

Virtualisation complète (Full Virtualization)

Paravirtualisation (Para Virtualization)

Virtualisation assistée par le matériel (Hardware Assisted Virtualization)

Virtualisation complète

1. Le VMM simule un matériel sous-jacent complet pour le système d’exploitation invité, y compris le processeur, la mémoire physique, l’horloge, les périphériques, etc., le système d’exploitation invité ignore complètement qu’il fonctionne dans une machine virtuelle.

2. Le système d’exploitation invité et ses logiciels système peuvent fonctionner dans la machine virtuelle sans aucune modification.

3. Bonne compatibilité, installation et utilisation simples.

4. Performances relativement faibles (car le VMM doit traduire le code binaire et remplacer les instructions sensibles). Paravirtualisation

5. La paravirtualisation nécessite de modifier le noyau du système d’exploitation invité, remplaçant les instructions privilégiées ou sensibles par des appels hyperviseur.

6. Le système d’exploitation invité sait qu’il fonctionne dans un environnement de machine virtuelle et ne peut pas appeler directement les instructions privilégiées et sensibles du noyau, il passe par le noyau de l’hôte pour appeler directement le CPU.

7. Amélioration des performances,

8. Mais mise en œuvre complexe. Virtualisation assistée par le matériel

Les fabricants de CPU modifient le CPU, introduisant de nouvelles instructions et modes de fonctionnement pour aider le VMM à identifier et intercepter efficacement les instructions sensibles, supportant la virtualisation au niveau matériel. En général, les instructions principales du système d’exploitation invité peuvent être exécutées directement par le matériel du système informatique, sans passer par le VMM. Pour les instructions spéciales, le système bascule vers le VMM, permettant au VMM de traiter les instructions spéciales.

2.6.1.2 2. Virtualisation du stockage

Abstraction et gestion unifiée des équipements de stockage sous-jacents, fournissant des services de stockage indépendants. Cela permet :

1. Haute extensibilité, libération des limites de capacité physique.

2. Masquage de la complexité des équipements, gestion et service unifiés.

3. Intégration des ressources spatiales, amélioration de l’utilisation des équipements.

4. Haute fiabilité, haute disponibilité. Types de technologie

5. Virtualisation basée sur l’hôte (supporte les équipements hétérogènes, bon rapport qualité-prix, mais consomme des ressources de l’hôte, affecte les performances, la sécurité et la stabilité de l’hôte, extensibilité limitée)

6. Virtualisation basée sur l’équipement de stockage (les performances de l’hôte ne sont pas affectées, mais ne supporte pas les équipements hétérogènes de fabricants spécifiques)

7. Virtualisation basée sur le réseau

2.6.1.3 3. Virtualisation des postes de travail

Services de bureau à distance RDS

Infrastructure de bureau virtuel VDI

Virtualisation de bureau intelligent IDV

2.6.1.4 4. Virtualisation du réseau

Services principaux d’OpenStack : service de calcul nova, service de stockage swift, service d’image glance

Défauts de la technologie de virtualisation

1. Le système d’exploitation de la machine virtuelle consomme beaucoup de ressources et prend du temps à démarrer
2. Les étapes intermédiaires (hyperviseur) réduisent les performances du système
3. Les utilisateurs se concentrent davantage sur leurs applications déployées, mais doivent gérer et maintenir le système d’exploitation et l’environnement de dépendance associés

2.6.2 Technologie de conteneurisation

La conteneurisation est une technologie de virtualisation légère basée sur le noyau du système d’exploitation. Elle utilise les fonctionnalités du noyau du système d’exploitation partagé pour établir une série d’environnements d’exécution isolés en termes de ressources, ces environnements fermés ressemblant à des conteneurs (containers), dans lesquels les applications sont déployées et exécutées. Ses avantages incluent la légèreté, l’agilité, la facilité d’extension, le support de DevOps, l’amélioration de l’utilisation des ressources, la réduction des coûts, l’accélération de l’itération des produits, le support de l’architecture microservices et l’automatisation des opérations.

1. Les conteneurs partagent le même noyau du système d’exploitation

2. Les conteneurs empaquettent les applications et leurs environnements d’exécution

3. Construction unique, exécution sur toutes les plateformes

4. Conteneurs légers, démarrage rapide, faible coût Principe de mise en œuvre des conteneurs

5. Namespace (espace de noms)

L’espace de noms définit une portée fermée, stipulant que les processus dans le même espace de noms ne peuvent voir que les ressources sous cet espace de noms, telles que le nom d’hôte, le réseau, les processus, les utilisateurs, le système de fichiers, etc. Les processus dans différents espaces de noms sont invisibles et n’affectent pas les uns les autres. Les conteneurs sont des processus avec des espaces de noms distincts, les applications exécutées dans les conteneurs fonctionnent comme si elles étaient dans un système d’exploitation indépendant, les conteneurs n’affectent pas les uns les autres.

Chaque processus possède sept espaces de noms pour isoler différents types de ressources.

2. Cgroups (groupes de contrôle)

Les espaces de noms peuvent isoler les processus dans un environnement spécifique, mais ne peuvent pas limiter les ressources physiques utilisées par les processus. Les cgroups (Control Groups) sont un mécanisme d’isolation des ressources physiques fourni par le noyau Linux, permettant de limiter, isoler et comptabiliser les ressources des processus ou groupes de processus Linux.

Les conteneurs utilisent les cgroups pour isoler, limiter et enregistrer les ressources physiques (CPU, mémoire, E/S, etc.) utilisées par les conteneurs. Les cgroups traitent chaque conteneur comme un processus ordinaire. En définissant des conditions de limitation des ressources pour un groupe de processus ou un processus particulier, on peut isoler les processus des conteneurs des autres processus en termes d’utilisation des ressources.

· A. Les espaces de noms réalisent l’isolation des ressources.

· B. Les cgroups réalisent le contrôle des ressources.

· C. Chaque processus possède 7 espaces de noms pour isoler différents types de ressources.

· D. Les cgroups traitent chaque conteneur comme un processus ordinaire. En définissant des conditions de limitation des ressources pour un groupe de processus ou un processus particulier, on peut isoler les processus des conteneurs des autres processus en termes d’utilisation des ressources.

3 Aperçu du traitement des big data

3.1 Processus de traitement des big data

Le traitement des big data est l’ensemble des tâches de collecte et de prétraitement, de stockage et de gestion, de traitement et d’analyse, de visualisation et de présentation des big data.

3.1.1 Collecte et prétraitement des données

Types de données : structurées, semi-structurées, non structurées

Sources de données : données d’entreprise, données Internet, données de l’Internet des objets

Méthodes de collecte : collecte de journaux, web scraping, API, partage gouvernemental et d’entreprises

Le prétraitement des données comprend :

• Nettoyage des données Suppression des doublons, traitement des valeurs manquantes, renommage des colonnes

• Intégration des données Intégrer logiquement ou physiquement des sources de données distribuées et hétérogènes interconnectées pour fournir un service d’accès transparent aux utilisateurs, les méthodes d’intégration des données incluent :

Intégration de données (ETL + entrepôt de données, unification physique)

Fédération de données (création d’une vue logique unifiée)

Propagation de données (propagation des données entre plusieurs applications)

Méthode hybride

• Transformation des données Convertir les données d’une forme de représentation à une autre :

Lissage, agrégation, généralisation, normalisation, construction d’attributs

• Réduction des données Réduire l’échelle des données tout en garantissant la qualité de l’analyse des données :

Réduction dimensionnelle : transformation par ondelettes, PCA (analyse en composantes principales), sélection de caractéristiques

Réduction quantitative : clustering, échantillonnage, régression logistique

3.1.2 Traitement et analyse des données de big data

• Modèles et cadres de calcul distribué
  • Traitement par lots : Hadoop, Spark
  • Traitement en flux : Storm, Flink
  • Calcul de graphes : Pregel, GraphX
• Analyse des big data
  • Requêtes interactives : Hive, Pig, Spark SQL
  • Fouille de données : Mahout
  • Apprentissage automatique : Mllib

3.1.3 Stockage et gestion des big data

3.1.4 Interprétation et visualisation des big data

3.2 Principe du calcul distribué

Un système distribué est un système de travail collaboratif composé de nœuds informatiques dans un réseau pour accomplir une tâche commune, nécessitant une haute disponibilité, une haute performance, une extensibilité et une tolérance aux pannes ; il comprend le stockage distribué et le calcul distribué. Le partitionnement et la réplication sont des moyens de base.

Comment HDFS stocke-t-il les fichiers

Divise le fichier en unités de taille fixe, stocke les unités de manière dispersée sur différents nœuds, et lors de l’accès, récupère et combine les unités depuis chaque nœud.

Comment HDFS écrit-il des fichiers

Le client demande à Namenode d’écrire un fichier, Namenode se prépare, puis informe le client que c’est prêt. Le client reçoit la confirmation et exécute en boucle les étapes suivantes jusqu’à ce que les données soient écrites : (1) Demande un bloc à Namenode, Namenode sélectionne un DataNode selon les règles et informe le client. (2) Le client envoie les données au DataNode spécifié, le DataNode reçoit les données et les écrit localement.

Comment HDFS lit-il des fichiers

Le client demande à Namenode de lire un fichier, Namenode se prépare et renvoie les métadonnées correspondantes au fichier. Le client reçoit les métadonnées du fichier, puis demande les données de bloc correspondantes aux DataNodes concernés, et enfin les combine pour former le contenu complet du fichier.

Rôle du stockage distribué des données :

Un, redondance des données pour améliorer la disponibilité.

Deux, séparation lecture/écriture pour améliorer les performances.

3.2.1 Partitionnement

Diviser un ensemble de données en sous-ensembles de données indépendants et orthogonaux selon certaines règles, et les distribuer sur différents nœuds. Le partitionnement peut réaliser une haute performance, une extension horizontale, une haute disponibilité.

Exigences du partitionnement : distribution uniforme, équilibrage de charge, migration minimale des données (extension/réduction)

3.2.1.1 Basé sur la plage de données

Les données sont divisées en différentes plages selon la clé, chaque nœud étant responsable d’une ou plusieurs plages.

Supporte les requêtes de plage, l’équilibrage est difficile à garantir.

3.2.1.2 Méthode de hachage

Établit une relation de mappage entre les valeurs de hachage et les nœuds du système, distribuant ainsi les données avec des valeurs de hachage différentes sur différents nœuds.

Peut résoudre le problème de déséquilibre,

Les performances des requêtes de plage sont affectées.

L’extension/réduction nécessite la migration de nombreuses données

3.2.1.3 Hachage cohérent

• Mappe les nœuds (serveurs) sur un anneau de hachage en fonction de leurs caractéristiques.
• Mappe les données sur le même anneau de hachage en fonction de leurs caractéristiques.
• Stocke les données sur le premier nœud dans le sens des aiguilles d’une montre sur l’anneau.
• Et définit des nœuds virtuels pour chaque nœud physique, les données mappées sur les nœuds virtuels sont en réalité stockées sur les nœuds physiques correspondants, les nœuds virtuels étant uniformément dispersés sur l’anneau de hachage pour éviter les déséquilibres de données et les effondrements de nœuds. L’extension/réduction nécessite peu de migration de données,

Peut entraîner un déséquilibre des données

Effondrement de nœud dû au déséquilibre des données

3.2.2 Réplication

La création de répliques redondantes est un moyen de base pour réaliser la tolérance aux pannes et la haute disponibilité.

3.2.2.1 Stratégies de création de répliques

Réplication à maître unique

La réplication à maître unique a un seul et unique maître, les autres étant des esclaves de secours, le nœud qui maintient la réplique maître sert de nœud central, responsable de la mise à jour des données, du contrôle de la concurrence et de la coordination de la cohérence des répliques.

Processus : lorsque la réplique maître tombe en panne, un maître est élu parmi les esclaves, le maître tombé en panne est rétrogradé en esclave après récupération, et synchronise avec le nouveau maître. Si une réplique esclave tombe en panne, elle se synchronise à nouveau avec le maître après récupération.

Problèmes existants :

(1) Problème de disponibilité : les opérations de basculement après la panne du maître, l’élection de l’esclave et le basculement du service vers le nouveau maître prennent du temps, pendant lequel le système est bloqué et ne peut pas fournir de service.

(2) Problème de cohérence des données : lorsque le maître tombe en panne, un esclave devient le nouveau maître par élection, et à ce moment-là, le nouveau maître et l’ancien maître ne sont pas encore synchronisés, ce qui entraîne une incohérence des données lorsque l’ancien maître est restauré en tant que nouvel esclave, ayant plus de données que le nouveau maître.

(3) Problème de coût : les répliques esclaves ne sont utilisées que pour le basculement en cas de panne, ce qui est quelque peu gaspillé.

Réplication à maîtres multiples

Toutes les répliques sont des maîtres, les répliques sont mutuellement maîtres et esclaves. Les opérations d’écriture peuvent être traitées par n’importe quel maître, puis synchronisées avec les autres maîtres.

La réplication à maîtres multiples présente un problème d’incohérence des données lors des opérations concurrentes.

Réplication sans maître

Ne distingue pas les répliques maître et esclave, le client met à jour les données en envoyant des requêtes d’écriture à plusieurs répliques ; le client interroge les données en envoyant des requêtes de lecture à plusieurs répliques.

Le client peut effectuer certaines opérations de compensation des données, mais il existe toujours un problème d’incohérence des données.

3.2.2.2 Stratégies de synchronisation des répliques

Réplication synchrone (synchronous replication)

Assure que les données sont répliquées sur toutes les répliques avant de considérer la réplication comme terminée. Les répliques ont une forte cohérence, mais les performances sont faibles.

Réplication asynchrone (asynchronous replication)

Considère la réplication comme terminée dès que les données sont répliquées sur la réplique maître, les autres répliques traitant de manière asynchrone. Les performances sont élevées, mais il peut y avoir une perte de données ou une lecture sale des données.

Réplication semi-synchrone (semi-synchronous replication)

Considère la réplication comme terminée lorsque les données atteignent un nombre convenu de répliques. Compromis entre performance et cohérence.

3.2.2.3 Modèle de cohérence des répliques

Théorème CAP

Un système distribué ne peut pas satisfaire simultanément la cohérence, la disponibilité et la tolérance aux partitions, il ne peut satisfaire au maximum que deux de ces propriétés.

• Cohérence (Consistency) : toutes les répliques de données ont des données cohérentes.
• Disponibilité (Availability) : toutes les requêtes peuvent obtenir une réponse correcte.
• Tolérance aux partitions (Partition tolerance) : même en cas de partitionnement réseau, le système peut fournir des services satisfaisant la cohérence et la disponibilité.

Le partitionnement réseau est un problème de lien réseau qui isole les nœuds du cluster en plusieurs partitions, les partitions étant inaccessibles entre elles, mais fonctionnant normalement à l’intérieur.

Les systèmes distribués doivent garantir la tolérance aux partitions, sinon ils perdent leur signification en tant que systèmes distribués, il est donc nécessaire de faire des compromis entre cohérence et disponibilité.

ACID

• Atomicité (Atomicity) : toutes les opérations d’une transaction doivent être entièrement terminées ou entièrement annulées, elles ne peuvent pas se terminer à une étape intermédiaire.
• Cohérence (Consistency) : avant et après une transaction, la base de données passe d’un état cohérent à un autre état cohérent, l’intégrité des données n’est pas compromise.
• Isolation (Isolation) : plusieurs transactions concurrentes s’exécutant simultanément ne s’interfèrent pas les unes avec les autres, évitant ainsi l’incohérence des données.
• Durabilité (Durability) : une fois qu’une transaction est terminée, les modifications apportées aux données sont permanentes, même en cas de panne du système. Principe BASE

Le principe BASE affaiblit la cohérence, poursuivant la tolérance aux partitions et la disponibilité, et représente une philosophie de conception différente de celle de l’ACID.

• Disponibilité de base (Basic Availability) Exige que le système puisse fonctionner de manière basique, fournissant toujours des services, et en cas de panne imprévue, permet de perdre une partie de la disponibilité, par exemple en retardant la réponse ou en dégradant le service.

• État flexible (Soft State) Permet aux données du système d’être dans un état intermédiaire, et considère que cet état n’affecte pas la disponibilité globale du système, c’est-à-dire qu’il permet une incohérence temporaire entre les répliques de différents nœuds.

• Cohérence finale (Eventually Consistency) Exige que les données ne restent pas indéfiniment dans un état flexible, elles doivent atteindre un état cohérent après un certain temps, garantissant la cohérence des données entre toutes les répliques.

Modèle de cohérence définit les contraintes de base pour maintenir la cohérence lors de la réplication des données dans un système distribué.

• Cohérence forte À tout moment, tout utilisateur ou nœud peut lire la réplique de données mise à jour lors de la dernière mise à jour réussie. La cohérence la plus élevée, la plus difficile à réaliser en pratique.

• Cohérence monotone À tout moment, tout utilisateur qui a lu une valeur mise à jour lors d’une mise à jour ne lira plus jamais une valeur antérieure à cette mise à jour. Plus faible que la cohérence forte.

• Cohérence de session Tout utilisateur, dans une session donnée, qui a lu une valeur mise à jour lors d’une mise à jour ne lira plus jamais une valeur antérieure à cette mise à jour au cours de cette session. Plus faible que la cohérence monotone, ne garantit la cohérence des modifications de données monotones que pour une seule session utilisateur, et ne garantit pas la cohérence entre différents utilisateurs ou entre différentes sessions d’un même utilisateur.

• Cohérence finale La cohérence finale exige que, une fois la mise à jour réussie, les données atteignent finalement un état complètement cohérent sur toutes les répliques, mais le temps nécessaire pour atteindre cet état ne peut pas être garanti.

• Cohérence faible Une fois qu’une mise à jour est réussie, l’utilisateur ne peut pas lire la valeur de cette mise à jour dans un délai déterminé, et même si une nouvelle valeur est lue sur une réplique, il n’est pas garanti que la nouvelle valeur puisse être lue sur d’autres répliques. Les systèmes de cohérence faible sont généralement difficiles à utiliser en pratique, nécessitant que les applications effectuent davantage de travail pour rendre le système utilisable.

3.2.3 Protocoles de cohérence des systèmes distribués

‘

Parmi eux, Lease, 2PC, PAXOS peuvent réaliser une cohérence complète

3.2.3.1 Mécanisme de Lease

Le nœud central conserve et maintient les métadonnées, exigeant que les métadonnées mises en cache par chaque nœud soient toujours cohérentes avec les métadonnées sur le nœud central.

Scénarios d’utilisation :

(1) Le client lit les métadonnées du nœud cache

Vérifie si les métadonnées sont déjà dans le nœud cache et si le Lease est valide.

Si oui : retourne directement les métadonnées.

Si non : demande au nœud central de lire les données. Le nœud central, après avoir reçu la demande de lecture, retourne les métadonnées avec un Lease correspondant.

Si le nœud cache échoue à recevoir ou dépasse le délai, la lecture échoue, quitte le processus et réessaie.

Si la réception est réussie, enregistre les métadonnées et le Lease retournés par le nœud central, et retourne les métadonnées au client.

(2) Le client modifie les métadonnées

Le client envoie une demande de modification des métadonnées au nœud central.

Le nœud central, après avoir reçu la demande, bloque toutes les nouvelles demandes de lecture de données, c’est-à-dire qu’il accepte uniquement les demandes de lecture, mais ne retourne pas de données.

Le nœud central attend que tous les Leases liés à ces données expirent, modifie les données et retourne une confirmation de succès de modification au client.

3.2.3.2 Quorum

Supposons qu’il y ait N répliques au total, une opération d’écriture doit mettre à jour avec succès au moins W répliques pour être considérée comme réussie, et une opération de lecture doit lire au moins R répliques pour lire les données mises à jour. Exigence :

W + R > N

Peut ajuster W et R en fonction des besoins commerciaux pour équilibrer la fiabilité et les performances

3.2.3.3 Protocole de validation en deux phases (2PC)

Protocole pour maintenir la cohérence des transactions distribuées, appartient aux protocoles de réplication synchrone, c’est-à-dire que toutes les répliques doivent être synchronisées avant de retourner le résultat au client.

2PC divise la réplication des données en deux phases

Phase de vote : le nœud principal envoie les données à toutes les répliques, chaque réplique doit voter pour valider ou annuler, si une réplique vote pour valider, elle place les données dans une zone temporaire, en attente de validation finale.

Phase de validation : le nœud principal reçoit les réponses des autres répliques, si toutes les répliques votent pour valider, il envoie une confirmation de validation à toutes les répliques pour qu’elles valident la mise à jour, les données passant de la zone temporaire à la zone permanente. Si une seule réplique retourne une annulation, tout est annulé.

2PC est un système CA typique, pour garantir la cohérence et la disponibilité, en cas de partitionnement réseau ou de nœud indisponible, il refuse les opérations d’écriture, transformant le système en lecture seule.

En cas de panne de nœud, 2PC bloque le système indéfiniment, il est donc rarement utilisé dans les scénarios de réplication de données, généralement utilisé pour les transactions distribuées.

3.2.3.4 Protocole Paxos

Le scénario d’application est la réplication à maîtres multiples pour garantir la cohérence (réplication de machine d’état + algorithme de consensus).

Trois rôles

• Proposer : proposeur, propose une proposition (propose), il peut y en avoir plusieurs.
• Acceptor : votant, vote pour accepter la proposition.
• Learner : synchroniseur, synchronise la proposition déterminée. Proposition : demande de mise à jour de données, peut être représentée par : [numéro de proposition n, contenu de la proposition value]

Étapes :

• Chaque proposeur Proposer, lors de la proposition, obtient d’abord un numéro de proposition global unique et croissant N, qu’il attribue à la proposition qu’il souhaite proposer.
• Chaque votant Acceptor, après avoir accepté une proposition, enregistre le numéro de proposition N localement, le plus grand numéro de proposition étant noté MaxN. Chaque votant n’acceptera que les propositions dont le numéro est supérieur à son MaxN local.
• Une élection aboutit nécessairement et uniquement à une proposition sélectionnée parmi les nombreuses propositions.
• Une fois qu’une proposition est sélectionnée, les autres nœuds synchronisent activement (learn) cette proposition localement.
• Aucune proposition n’est proposée, aucune proposition n’est sélectionnée. prepare-promise, propose-accept or learn, learn

Le problème du PaxOS de base est qu’il ne peut prendre une décision que pour une seule valeur, la formation de la décision nécessite au moins deux allers-retours réseau, en cas de forte concurrence, il peut nécessiter davantage d’allers-retours réseau, dans des cas extrêmes, il peut même y avoir un blocage actif (livelock, deux nœuds rivalisant malicieusement pour une valeur).

Multi-Paxos améliore le Paxos de base avec deux améliorations :

1. Pour chaque valeur à déterminer, exécute une instance de l’algorithme Paxos (Instance) pour prendre une décision. Chaque instance Paxos utilise un ID d’instance unique.
2. Parmi tous les Proposers, élit un Leader, le Leader soumet uniquement les Propositions aux Acceptors pour vote. Ainsi, il n’y a pas de concurrence entre les Proposers, résolvant le problème de blocage actif. Lorsqu’il n’y a qu’un seul Leader soumettant des valeurs dans le système, la phase de préparation peut être ignorée, transformant les deux phases en une seule phase, améliorant l’efficacité. Ainsi, même en cas de partitionnement réseau avec plusieurs leaders, le multi-paxos se dégrade au maximum en paxos de base

3.2.4 Article de référence

Horloge

Trois types d’événements dans un système distribué, chacun pouvant déclencher une augmentation de l’horloge

1. Événements internes au nœud
2. Événements d’envoi
3. Événements de réception Deux méthodes pour établir une horloge logique dans un système distribué

Lamport ne peut représenter que les relations causales

L’horloge vectorielle (vector clock) peut représenter les relations causales et de concurrence

①Le timestamp de Lamport est une méthode de représentation d’horloge logique, c’est un entier qui augmente de manière monotone. En suivant certaines règles, chaque événement dans un système distribué se voit attribuer un timestamp de Lamport, en comparant les valeurs des timestamps, on peut déterminer l’ordre partiel des événements.

Règles

• Chaque nœud a localement un timestamp, initialisé à 0.
• Si un événement se produit dans le nœud, le timestamp local augmente de 1.
• Si c’est un événement d’envoi, le timestamp local augmente de 1 et est inclus dans le message.
• Si c’est un événement de réception, le timestamp local = Max(timestamp local, timestamp dans le message) + 1. Ordre des événements : d’abord triés par timestamp, s’ils sont identiques, triés par numéro de nœud (attention particulière, le numéro de nœud est donné par le problème !!!!!!!!!!!!!!!!)

②L’horloge vectorielle est une autre méthode d’horloge logique évoluée à partir du timestamp de Lamport, elle utilise une structure vectorielle (Vector) pour enregistrer le timestamp de Lamport local et ceux des autres nœuds, elle peut bien décrire les relations de simultanéité et de causalité des événements. L’algorithme de l’horloge vectorielle utilise cette structure de données pour diffuser les timestamps logiques de tous les processus globaux à chaque processus : chaque processus, lors de l’envoi d’un événement, écrit dans un vecteur les timestamps de tous les processus connus, et l’inclut dans le message.

Ordre des événements : si Tb[Q] > Ta[Q] et Tb[P] < Ta[P], (c’est-à-dire que sur le nœud Q, l’événement b se produit d’abord, et sur le nœud P, a se produit d’abord), alors on considère que a et b se produisent simultanément, noté a <-> b, ce qui est une relation de concurrence que le timestamp de Lamport ne peut pas représenter.

3.3 Structure des systèmes de big data

Décrire brièvement ce qu’est un système de big data, et quels besoins doivent être pris en compte lors de la création d’un système de big data)

Système de big data : un système matériel et logiciel haute performance, extensible, hautement disponible, tolérant aux pannes, sécurisé et facile à utiliser, intégrant les fonctions de collecte et de prétraitement des données, de stockage et de gestion, de traitement et d’analyse, de visualisation et de présentation des big data ; utilisé pour aider les utilisateurs à découvrir des informations et des connaissances potentiellement précieuses dans les big data, à comprendre la réalité des affaires et à prévoir les tendances commerciales.

La structure d’un système de big data dépend des besoins et des décisions macroéconomiques de la construction du système de big data, y compris les objectifs commerciaux, les types et caractéristiques des sources de données, les exigences de performance, le traitement par lots/traitement en flux (cadre de calcul), le choix technologique, etc.

3.3.1 Architecture BI traditionnelle

Sources de données + ETL + entrepôt de données + rapports d’analyse

• Analyse structurée autour de l’entrepôt de données, manque d’analyse non structurée.
• Fonctionnalités complexes et encombrantes de prétraitement des données ETL.
• Caractéristiques ACID, impact sur les performances, incapacité à gérer l’échelle des big data.

3.3.2 Architecture de traitement par lots

Sources de données + ETL +stockage de données + traitement par lots+ rapports d’analyse

• Avantages : simple et facile à utiliser, lors du choix technologique, remplace les composants BI par des composants big data.
• Inconvénients : ① manque de flexibilité de support commercial de l’entrepôt de données, pour de nombreux rapports et scénarios de forage complexes, nécessite une personnalisation manuelle ; ② principalement basé sur le traitement par lots, manque de support en temps réel.
• Scénarios d’application : principalement pour les scénarios BI, adapté à l’analyse hors ligne de grandes quantités de données historiques.

3.3.3 Architecture de traitement en flux

**Sources de données +canal de données en temps réel+ traitement en flux +**notification de message

• Avantages : pas de processus ETL encombrant, haute actualité des données.
• Inconvénients : pas de traitement par lots, incapacité à bien supporter la rediffusion des données et les statistiques historiques. Pour l’analyse hors ligne, ne supporte que l’analyse dans la fenêtre.
• Scénarios d’application : alerte, surveillance, situations nécessitant des données avec une période de validité.

3.3.4 Architecture Lambda

Architecture Lambda : couche de traitement par lots + couche de traitement en flux + couche de service. Les données sont écrites en parallèle dans les systèmes de traitement par lots et de traitement en flux de manière additive via deux chemins. Fournit une logique de calcul de données correspondante pour les deux chemins de traitement par lots et en flux. Enfin, les résultats de calcul sont intégrés via la couche de service pour la sortie de service externe.

• Avantages : analyse en temps réel + hors ligne, couvre tous les scénarios d’analyse de données.
• Inconvénients : nécessite la maintenance de deux systèmes, de traitement par lots et de vitesse : Hadoop & Storm. La même logique de calcul commercial doit être implémentée et maintenue dans les deux couches. La fusion des résultats de requête est complexe & maintenance complexe.
• Scénarios d’application : situations nécessitant à la fois des besoins en temps réel et hors ligne.

3.3.5 Architecture Kappa

Simplifie l’architecture Lambda, supprime le système de traitement par lots, toutes les données passent par le chemin en temps réel, toutes les données sont considérées comme un flux. Traite les données en temps réel et historiques via le système de traitement en flux. Les données sont introduites en tant qu’événements dans un journal distribué unifié tolérant aux pannes. Le flux d’événements est traité en temps réel dans la couche de vitesse pour générer une vue en temps réel. Le flux d’événements est également stocké à long terme. Si nécessaire, le flux d’événements est rediffusé, recalculé via le moteur de calcul en flux pour générer la vue des données historiques.

• Avantages : résout les parties redondantes de l’architecture Lambda, conçu avec la pensée de la rediffusion des données, architecture simple.
• Inconvénients : mise en œuvre difficile, en particulier la partie rediffusion des données.
• Scénarios d’application : situations nécessitant à la fois des besoins en temps réel et hors ligne.

4 Hadoop

Évolution des versions de Hadoop :

2.0 ajoute Yarn

3.0 MapReduce basé sur la mémoire, supporte plusieurs NameNode, simplification du noyau

Trois composants principaux de Hadoop : HDFS, MapReduce, YARN

Fonction : 5731

◼ HDFS est un cadre de stockage distribué, stockant les fichiers de manière distribuée sur plusieurs nœuds informatiques, adapté au stockage de grandes quantités de données.

◼ MapReduce est un cadre de calcul distribué, abstrait le processus de calcul parallèle sur un cluster à grande échelle en deux fonctions : Map, Reduce, utilisant la stratégie “diviser pour régner”, les ensembles de données à grande échelle stockés dans le système de fichiers distribué sont découpés en de nombreux fragments indépendants (split), ces fragments étant traités en parallèle par plusieurs tâches Map.

◼ Yarn est une plateforme de planification des ressources, responsable de l’ajustement des ressources occupées en fonction des besoins de charge des différents cadres de calcul, réalisant le partage des ressources du cluster et l’élasticité des ressources.

4.1 HDFS

4.1.1 Architecture du système HDFS

L’architecture du système HDFS adopte un modèle de structure maître/esclave (Master/Slave), un cluster HDFS comprend généralement :

(1) Un nœud de nom (NameNode), le nœud de nom sert de serveur central, responsable de la gestion de l’espace de noms du système de fichiers et de l’accès des clients aux fichiers.

(2) Plusieurs nœuds de données (DataNode), chaque nœud de données exécute un processus datanode, responsable du traitement des demandes de lecture/écriture des clients, et sous la planification unifiée du nœud de nom, effectue des opérations telles que la création, la suppression et la réplication des blocs de données. Les données des nœuds de données sont en réalité stockées dans le système de fichiers Linux local.

4.1.2 Principe de stockage HDFS

Pour garantir la tolérance aux pannes et la disponibilité du système, HDFS utilise une méthode de stockage redondant avec plusieurs répliques, généralement plusieurs répliques d’un bloc de données sont réparties sur différents nœuds de données. Les clients privilégient l’utilisation des données sur le même rack. Avantages :

(1) Accélération de la vitesse de transmission des données

(2) Facilité de vérification des erreurs de données

(3) Garantie de la fiabilité des données

Stratégie de stockage des répliques :

(1) Première réplique : placée sur le nœud de données de téléchargement du fichier ; si soumise depuis l’extérieur du cluster, un nœud est sélectionné au hasard, avec un disque pas trop plein et un CPU pas trop occupé ;

(2) Deuxième réplique : placée sur un nœud d’un rack différent de la première réplique ;

(3) Troisième réplique : placée sur un autre nœud du même rack que la première réplique ;

(3) Répliques supplémentaires : nœuds aléatoires.

4.1.3 Processus de lecture et d’écriture des données

Écriture de fichier

Le client demande à Namenode d’écrire un fichier, Namenode se prépare, puis informe le client. Le client reçoit la confirmation et exécute en boucle les étapes suivantes jusqu’à ce que les données soient écrites :

1. Demande un bloc à Namenode, Namenode sélectionne un DataNode selon les règles et informe le client.

2. Le client envoie les données au DataNode spécifié, le DataNode reçoit les données et les écrit localement.

Lecture de fichier

Le client demande à NameNode de lire un fichier, Namenode se prépare et retourne les métadonnées correspondantes au fichier. Le client reçoit les métadonnées du fichier, puis demande les données de bloc correspondantes aux DataNodes concernés, et enfin les combine pour former le contenu complet du fichier.

4.1.4 Erreurs et récupération des données

1. Erreur du nœud de nom

Le nœud de nom conserve toutes les métadonnées, en cas d’erreur, l’ensemble du cluster HDFS devient inutilisable. HDFS met en place un mécanisme de point de contrôle, copiant périodiquement ces métadonnées sur le serveur de sauvegarde SecondaryNameNode. En cas d’erreur du nœud de nom, les métadonnées du NameNode peuvent être récupérées à partir du SecondaryNameNode.

2. Erreur du nœud de données

• Chaque nœud de données envoie périodiquement des informations de pulsation au nœud de nom, signalant son état.
• En cas de panne ou de problème réseau du nœud de données, le nœud de nom ne reçoit pas les informations de pulsation du nœud de données, ce dernier est alors marqué comme en panne, et toutes les données sur le nœud sont marquées comme non lisibles, le nœud de nom ne leur envoie plus de requêtes d’E/S.
• Le nœud de nom vérifie périodiquement le nombre de répliques des blocs de données, si inférieur au facteur de redondance, il lance une réplication redondante des données.

3. Erreur de données

Des erreurs de données peuvent survenir en raison de la transmission réseau et des erreurs de disque. Le client vérifie les blocs de données après lecture à l’aide de codes md5 et sha1 pour s’assurer que les données lues sont correctes.

4.2 Architecture du système Map Reduce

4.2.1 Modèle de calcul

• Abstrait le processus de calcul parallèle sur un cluster à grande échelle en deux fonctions : Map, Reduce.
• Programmation facile, pas besoin de maîtriser les détails fastidieux de la programmation parallèle distribuée pour exécuter son programme sur un système distribué, réalisant le calcul de grandes quantités de données.
• Utilise la stratégie “diviser pour régner”, les ensembles de données à grande échelle stockés dans le système de fichiers distribué sont découpés en de nombreux fragments indépendants (split), ces fragments étant traités en parallèle par plusieurs tâches Map.
• La conception est de “rapprocher le calcul des données”, plutôt que de “rapprocher les données du calcul”, car le déplacement des données nécessite beaucoup de coûts de transmission réseau.
• Adopte une architecture de type Master/Slave, comprenant un Master et plusieurs Slaves (ou Workers). Le Master exécute JobTracker, responsable de la planification, du traitement et de la récupération après échec des tâches, le Slave exécute TaskTracker, responsable de recevoir les instructions de tâches envoyées par JobTracker.

4.2.2 Quatre composants

1. Client :

• a L’utilisateur écrit un programme MapReduce et le soumet au JobTracker via le client.
• b L’utilisateur peut consulter l’état d’exécution des tâches via certaines interfaces fournies par le client.

2. Job Tracker :

• a Responsable de la surveillance des ressources et de la planification des tâches,
• b Surveille l’état de santé de tous les Task Tracker et des tâches, et en cas d’échec, transfère les tâches concernées à d’autres nœuds.
• c JobTracker suit la progression de l’exécution des tâches, l’utilisation des ressources, etc., et transmet ces informations au planificateur de tâches (TaskScheduler, détachable, personnalisable), qui choisit les tâches appropriées pour utiliser les ressources disponibles lorsque celles-ci sont libres.

3. Task Tracker :

• a Task Tracker envoie périodiquement les informations d’utilisation des ressources et de progression des tâches de ce nœud à JobTracker via des “pulsations”, et reçoit les commandes envoyées par JobTracker pour exécuter les opérations correspondantes (comme démarrer une nouvelle tâche, tuer une tâche, etc.).
• b Task Tracker utilise des “slots” pour diviser les ressources de ce nœud (CPU, mémoire, etc.) en quantités égales. Une tâche ne peut être exécutée que si elle obtient un slot, et le rôle du planificateur de tâches Hadoop est de distribuer les slots libres sur chaque TaskTracker aux tâches à utiliser. (Les slots sont divisés en deux types : Map slot et Reduce slot, utilisés respectivement par MapTask et Reduce Task.)

4. Task : se divise en deux types, Map Task et Reduce Task, tous deux démarrés par Task Tracker.

Flux de travail

(1) Déploiement du programme ; (2) Attribution des tâches Map et Reduce ; (3) Les nœuds map lisent les données, exécutent les tâches map et écrivent les résultats intermédiaires ; (4) Les nœuds reduce reçoivent les données des résultats intermédiaires et exécutent les tâches reduce ; (5) Écrivent les résultats d’exécution dans HDFS.

4.3 Architecture du système Yarn

4.3.0.1 Resource Manager

Traite les demandes des clients, surveille NodeManager, démarre et surveille Application Master, planifie et alloue les ressources

Gestionnaire de ressources global, responsable de la gestion et de l’allocation des ressources du système. Comprend deux composants : le planificateur (Scheduler) et le gestionnaire d’applications (Applications Manager).

(1) Le planificateur attribue les ressources du cluster sous forme de “conteneurs” aux applications qui en font la demande, le choix des conteneurs prend généralement en compte l’emplacement des données que l’application doit traiter, choisissant de manière proche pour réaliser “rapprocher le calcul des données”. Le planificateur est un composant détachable, YARN fournit non seulement de nombreux planificateurs directement utilisables, mais permet également aux utilisateurs de redéfinir le planificateur selon leurs besoins.

(2) Le gestionnaire d’applications gère toutes les applications du système, y compris la soumission des applications, la négociation des ressources avec le planificateur pour démarrer ApplicationMaster, la surveillance de l’état d’exécution d’ApplicationMaster et son redémarrage en cas d’échec, etc.

4.3.0.2 Application Master

Les principales fonctions sont :

(1) Lorsqu’une tâche utilisateur est soumise, ApplicationMaster négocie avec Resource Manager pour obtenir des ressources, ResourceManager attribue des ressources à Application Master sous forme de conteneurs.

(2) ApplicationMaster attribue les ressources obtenues aux différentes tâches internes (tâches Map ou Reduce), réalisant une “répartition secondaire” des ressources.

(3) Communique en continu avec NodeManager pour démarrer, exécuter, surveiller et arrêter les applications, surveille l’utilisation des ressources obtenues, surveille la progression et l’état de toutes les tâches, et effectue une récupération en cas d’échec (c’est-à-dire redemande des ressources pour redémarrer les tâches).

(4) Envoie périodiquement des “pulsations” à ResourceManager pour signaler l’utilisation des ressources et les informations de progression des applications.

(5) Lorsque la tâche est terminée, ApplicationMaster se désinscrit de ResourceManager et se ferme.

4.3.0.3 Node Manager

NodeManager est un agent résidant sur chaque nœud du cluster YARN, principalement responsable de :

1. Gestion du cycle de vie des conteneurs, surveillance de l’utilisation des ressources (CPU, mémoire, etc.) de chaque conteneur
2. Suivi de l’état de santé des nœuds, communication continue avec ResourceManager via des “pulsations”, rapport de l’utilisation des ressources des tâches et de l’état d’exécution de chaque conteneur,
3. Réception des demandes de démarrage/arrêt de conteneurs de la part d’ApplicationMaster. Remarque : NodeManager est principalement responsable de la gestion des conteneurs abstraits, ne gérant pas l’état de chaque tâche (tâche Map ou Reduce) elle-même. La gestion de l’état des tâches est effectuée par ApplicationMaster, qui communique en continu avec NodeManager pour suivre l’état d’exécution de chaque tâche.

JobHistoryServer : gestion unifiée des tâches historiques YARN.

WebAppProxyServer : proxy de la page Web lors de l’exécution des tâches. Responsable de la supervision de l’ensemble du processus d’exécution des tâches MapReduce spécifiques, collecte les informations d’exécution des tâches des conteneurs et les affiche sur une interface Web.

4.3.0.4 Flux de travail de Yarn

Étape 1 : L’utilisateur écrit une application cliente et la soumet à YARN, incluant le programme ApplicationMaster, la commande de démarrage d’ApplicationMaster, le programme utilisateur, etc.

Étape 2 : ResourceManager de YARN est responsable de recevoir et de traiter les demandes des clients, attribue un conteneur à l’application, dans lequel ApplicationMaster est démarré.

Étape 3 : Une fois ApplicationMaster créé, il s’enregistre d’abord auprès de ResourceManager.

Étape 4 : ApplicationMaster utilise une méthode de sondage pour demander des ressources à ResourceManager.

Étape 5 : ResourceManager attribue des ressources sous forme de “conteneurs” à ApplicationMaster qui en fait la demande.

Étape 6 : Démarre les tâches dans les conteneurs (environnement d’exécution, script).

Étape 7 : Chaque tâche rapporte son état et sa progression à ApplicationMaster.

Étape 8 : Une fois l’application terminée, ApplicationMaster se désinscrit de ResourceManager et se ferme.

4.3.0.5 Rôle du déploiement unifié de YARN

• Déploie un cadre de planification des ressources YARN unifié dans le cluster, déploie divers cadres de calcul au-dessus de YARN.
• YARN fournit des services de planification et de gestion des ressources unifiés pour ces cadres de calcul, et ajuste les ressources occupées en fonction des besoins de charge des différents cadres de calcul, réalisant le partage des ressources du cluster et l’élasticité des ressources.
• Réalise une charge mixte de différentes applications sur un cluster, augmentant efficacement l’utilisation du cluster
• Les différents cadres de calcul peuvent partager le stockage sous-jacent, évitant le déplacement de jeux de données entre clusters

5 ZooKeeper

Les applications distribuées peuvent réaliser les fonctionnalités suivantes via Zookeeper : gestion de la configuration, service de nommage, verrouillage distribué, gestion de cluster

5.1 Architecture du système

Leader

1. Seul planificateur et gestionnaire des requêtes transactionnelles (opérations d’écriture) dans le cluster, garantissant l’ordre des transactions dans le cluster

2. Planificateur des services internes du cluster Follower

3. Traite les requêtes non transactionnelles (opérations de lecture) du cluster

4. Transfère les requêtes transactionnelles au Leader

5. Participe au vote des propositions de requêtes transactionnelles

6. Participe au vote pour l’élection du Leader Observer

7. Traite les requêtes non transactionnelles des clients

8. Transfère les requêtes transactionnelles au Leader

9. Ne fournit que des services de lecture de données, ne participe à aucun vote L’architecture de cluster Leader/Followers confère à Zookeeper des capacités de maître-esclave et maître-secours.

(1) Maître-esclave : le nœud maître attribue les tâches, les nœuds esclaves exécutent les tâches.

(2) Maître-secours : le nœud maître et les nœuds de secours, lorsque le nœud maître échoue, un nouveau nœud maître est rapidement élu parmi les Followers, garantissant que le nœud maître ne tombe pas en panne.

5.2 Trois types de Znode

1. Nœud persistant (PERSISTENT) : le nœud persiste même après la déconnexion du client de Zookeeper. Par défaut, tous les znodes sont persistants.
2. Nœud temporaire (EPHEMERAL) : le nœud est valide tant que le client est actif, et est automatiquement supprimé lorsque le client se déconnecte de Zookeeper. Les nœuds temporaires ne peuvent pas avoir de nœuds enfants, ils jouent un rôle important dans l’élection du leader.
3. Nœud séquentiel (SEQUENTIAL) : nœud avec un numéro de séquence. Les nœuds séquentiels peuvent être persistants ou temporaires, donc les nœuds séquentiels peuvent être des nœuds séquentiels persistants (PERSISTENT_SEQUENTIAL) ou des nœuds séquentiels temporaires (EPHEMERAL_SEQUENTIAL). Opérations primitives sur Znode : 

Créer un nœud (create)

 Supprimer un nœud (delete)

 Mettre à jour un nœud (set)

 Obtenir des informations sur un nœud (get)

 Contrôle des permissions (getAcl/setAcl)

 Écoute d’événements (watch)

5.3 Caractéristiques des opérations sur les nœuds znode

1. Si plusieurs machines créent simultanément un nœud, une seule réussira, cela peut être utilisé comme verrou distribué
2. La durée de vie d’un nœud temporaire est égale à celle de la session, le nœud temporaire est supprimé lorsque la session se termine, souvent utilisé pour le battement de cœur, la surveillance, la charge, etc.
3. Les nœuds séquentiels garantissent l’unicité globale des noms de nœuds, peuvent être utilisés comme identifiant global auto-incrémenté dans un environnement distribué
4. Le client enregistre une écoute sur le répertoire de nœuds concerné, lorsque les données du répertoire de nœuds changent, Zookeeper informe le client

5.4 Services fournis par zookeeper

Gestion de la configuration

Service de nommage unifié

Gestion de cluster

Verrou distribué (verrou partagé, verrou exclusif)

Comment zookeeper réalise-t-il un verrou exclusif :

(1) Représentation du verrou exclusif : via un znode représentant un verrou exclusif, tel que /x_lock/lock.

(2) Acquisition du verrou : tous les clients tentent de créer un nœud enfant temporaire sous /x_lock via l’interface create. Bien sûr, un seul client réussira finalement à créer le nœud, indiquant que ce client a acquis le verrou exclusif. En même temps, les autres clients qui n’ont pas acquis le verrou enregistrent un Watcher pour écouter les changements des nœuds enfants.

(3) Libération du verrou : le client qui a acquis le verrou tombe en panne ou termine normalement sa logique métier, supprimant le nœud enfant temporaire, indiquant la libération du verrou exclusif. Une fois le nœud enfant temporaire supprimé, les autres clients commencent un nouveau cycle d’acquisition du verrou.

6 Kafka

6.1 Deux modèles de file d’attente de messages

Modèle point à point et modèle de publication/abonnement

Le modèle point à point ne peut pas réaliser la diffusion et la multidiffusion des messages

6.2 Cinq scénarios d’application de la file d’attente de messages

Dissociation des applications, communication asynchrone, réduction des pics de trafic, traitement des journaux, communication de messages

6.3 Architecture du système

• Le producteur (Producer) utilise le mode push pour publier des messages sur le broker.
• Le consommateur (Consumer) utilise le mode pull pour s’abonner et consommer des messages du broker.
• Broker (serveur kafka, plusieurs brokers forment un cluster kafka) Comment les messages publiés sur Kafka sont-ils organisés et stockés pour obtenir un équilibrage de charge et un débit élevé ?

1. Les messages publiés sur le cluster Kafka ont une catégorie, appelée Topic.

2. La Partition (partition) est la file d’attente ordonnée où les messages sont réellement stockés, chaque message ayant un identifiant unique et ordonné (appelé offset).

3. Chaque Topic peut être stocké dans une ou plusieurs Partitions. Les messages envoyés au Broker sont stockés dans la Partition choisie selon les règles de partitionnement. Si les règles de partitionnement sont définies de manière appropriée, tous les messages peuvent être répartis uniformément dans différentes Partitions, équilibrant ainsi la charge des requêtes sur les différents nœuds du cluster, augmentant le débit.

4. Tout message publié dans une Partition est ajouté à l’extrémité de la Partition. Cette opération d’écriture séquentielle sur disque est une raison importante pour laquelle Kafka a un débit élevé. Comment le cluster Kafka utilise-t-il les répliques pour obtenir la disponibilité et la tolérance aux pannes ?

5. Dans Kafka, une Partition a plusieurs répliques (Replication) sur différents Brokers du cluster.

6. Dans une Partition avec plusieurs répliques, une seule réplique est le Leader, les autres répliques étant des Followers.

7. Le Leader est responsable de traiter toutes les opérations de lecture et d’écriture de cette partition, les Followers se contentent de copier les données du Leader. En cas de panne du Leader, un Follower est élu Leader via Zookeeper. Comment le cluster Kafka réalise-t-il le modèle point à point et le modèle de publication/abonnement ?

8. Kafka réalise le modèle point à point. Si tous les consommateurs appartiennent au même groupe de consommation, tous les messages seront distribués de manière équilibrée à chaque consommateur, c’est-à-dire que chaque message sera traité par un seul consommateur, équivalent au modèle point à point.

9. Kafka réalise le modèle de publication/abonnement. Si tous les consommateurs appartiennent à des groupes de consommation différents, tous les messages seront diffusés à tous les consommateurs, c’est-à-dire que chaque message sera traité par tous les consommateurs, équivalent au modèle de publication/abonnement.