Expliquer les nouvelles fonctionnalités du code d'effacement HDFS3.x

Introduction CE

Codage d'effacement abrégé en CE, nom chinois: code d'effacement

EC (Erasure Coding) est une technologie d'encodage. Avant HDFS, cette technologie d'encodage est la plus largement utilisée dans Redundant Array of Inexpensive Disks (RAID) (RAID Introduction: Big Data Preliminary Knowledge-Storage Disks, Redundant Arrays of Disks RAID) Introduction ), RAID implémente EC grâce à la technologie de striping. La technologie de striping est une technologie qui équilibre automatiquement la charge d'E / S sur plusieurs disques physiques. Le principe est de diviser une donnée continue en plusieurs petites parties et de les diviser. Stocké sur différents disques séparément, ce qui permet à plusieurs processus d'accéder à plusieurs parties différentes des données en même temps sans provoquer de conflits de disque (lorsque plusieurs processus accèdent à un disque en même temps, des conflits de disque peuvent se produire), et lorsque vous devez Lorsque ce type de données est accédé séquentiellement, la capacité parallèle d'E / S maximale peut être obtenue, obtenant ainsi de très bonnes performances. Dans HDFS, la division des données continues en plusieurs petites parties est appelée unité de répartition. Pour chaque unité de répartition de l'unité de données d'origine, un certain nombre d'unités de contrôle de parité sont calculées et stockées. Le processus de calcul est appelé codage. Récupérez toutes les erreurs sur l'unité de striping en décodant les calculs basés sur les données restantes et l'unité de parité .

Stratégie de stockage de redondance des données HDFS

La stratégie de stockage de HDFS est un mécanisme de copie. Cette méthode de stockage améliore la sécurité du stockage des données, mais elle entraîne également une surcharge supplémentaire. Le schéma à 3 copies par défaut de HDFS dispose d'un espace de stockage et d'autres ressources (telles que la bande passante du réseau). 200% de surcharge supplémentaire, mais pour les données avec une activité d'E / S relativement faible, les autres copies de bloc sont rarement accessibles pendant les périodes normales, mais elles consomment toujours la même quantité de ressources que la première copie. Par conséquent, une amélioration majeure de la version HDFS 3.x est d'utiliser le code d'effacement (EC) au lieu du mécanisme de copie. La technologie de code d'effacement offre la même tolérance aux pannes que le mécanisme de copie, mais a beaucoup moins d'espace de stockage. Dans un paramètre de code d'effacement (EC) typique, la surcharge de stockage ne dépasse pas 50%.

Principe de mise en œuvre de l'algorithme EC

Il existe de nombreux algorithmes d'implémentation pour EC. L'un des algorithmes les plus courants est Reed-Solomon (RS) . Il a deux paramètres, notés RS (k, m) , où k représente le bloc de données et m représente le bloc de contrôle. Combien Le nombre maximum de blocs (y compris les blocs de données et les blocs de contrôle) qui peuvent être tolérés pour un bloc de contrôle est perdu. Le principe spécifique est expliqué par l'exemple suivant:

Nous utilisons RS (3,2) pour indiquer l'utilisation de 3 blocs de données d'origine et de 2 blocs de contrôle
Exemple: Il existe trois données d'origine de 7, 8 et 9 , et deux données de contrôle 50, 122 sont calculées par multiplication matricielle . À ce stade, les données d'origine plus les données de contrôle, un total de cinq données: 7, 8, 9, 50, 122, vous pouvez en supprimer deux arbitrairement, puis restaurer via l'algorithme

Multiplication matricielle

GT est la matrice du générateur et la matrice du générateur de RS (k, m) est la matrice avec m lignes et k colonnes.
Les données représentent les données d'origine, 7, 8, 9 représentent le bloc de données d'origine,
La parité représente les données de contrôle et 50122 représente le bloc de données de contrôle

Par conséquent, pour 3 blocs de données d'origine, si 2 blocs de parité sont utilisés, le codage EC occupe un total de 5 blocs de données d'espace disque, ce qui équivaut à la tolérance aux pannes de l'espace disque de 6 blocs de données occupés par le mécanisme à 2 copies.

Scénarios d'application d'EC

L'intégration de la technologie EC dans HDFS peut améliorer l'efficacité du stockage tout en offrant une persistance des données similaire aux déploiements HDFS traditionnels basés sur la copie. Par exemple, un fichier de 3 copies avec 6 blocs consommera 6 * 3 = 18 espace disque. Cependant, lors d'un déploiement avec EC (6 données, 3 parités), il ne consommera que 9 blocs d'espace disque.

Cependant, EC utilisera beaucoup de ressources CPU pendant le processus de codage et la reconstruction des données, et la plupart des données sont lues à distance, donc il y aura beaucoup de surcharge du réseau.

Par conséquent, lorsque les ressources CPU sont restreintes et que le coût de stockage est faible, le mécanisme de copie peut être utilisé pour stocker des données, et lorsque les ressources CPU sont excédentaires et que le coût de stockage est élevé, le mécanisme EC peut être utilisé pour stocker des données .

EC dans l'architecture HDFS

HDFS utilise directement Online EC (écriture des données au format EC), évitant la phase de conversion et économisant de l'espace de stockage. Online EC améliore également les performances d'E / S séquentielles en utilisant plusieurs broches de disque en parallèle. Ceci est particulièrement idéal dans les clusters avec des réseaux haut de gamme. Deuxièmement, il distribue naturellement un petit fichier à plusieurs DataNodes sans avoir à regrouper plusieurs fichiers dans un groupe de codage. Cela simplifie considérablement les opérations sur les fichiers telles que la suppression, les quotas de disque et la migration entre les espaces de noms.

Dans un cluster HDFS général, les petits fichiers peuvent représenter plus des 3/4 de la consommation totale de stockage. Afin de mieux prendre en charge les petits fichiers, HDFS prend en charge le schéma EC de disposition par bandes dans la première étape. Actuellement, disposition continue HDFS (mise en page contiguë) Layout) est également en cours

Disposition des barres:
disposition des barres

avantage:

Le client met moins de données en cache

Fonctionne quelle que soit la taille du fichier

Désavantages:

Cela affectera les performances de certaines tâches sensibles à l'emplacement, car le bloc d'origine sur un nœud est dispersé sur plusieurs nœuds différents

Il est plus difficile de passer à une stratégie de stockage multi-copies

Disposition
continue : disposition continue

avantage:

facile à réaliser

Stratégie de stockage pratique et multi-copies pour la conversion

Désavantages:

Le client doit mettre en cache suffisamment de blocs de données

Ne convient pas pour stocker de petits fichiers

En mode traditionnel, l'unité de base des fichiers en HDFS est le bloc, tandis qu'en mode EC, l'unité de base des fichiers est le groupe de blocs . En prenant RS (3,2) comme exemple, chaque groupe de blocs contient 3 blocs de données et 2 blocs de contrôle.

Les principales extensions apportées par HDFS pour l'introduction du mode EC sont les suivantes :

NameNode : les fichiers HDFS sont logiquement composés de groupes de blocs. Chaque groupe de blocs contient un certain nombre de blocs internes. Afin de réduire la consommation de mémoire du NameNode par ces blocs internes, HDFS introduit un nouveau protocole de dénomination de bloc hiérarchique. L'ID du groupe de blocs peut être déduit de l'ID de l'un de ses blocs internes. Cela permet une gestion au niveau des groupes de blocs au lieu des blocs
Client : les chemins de lecture et d'écriture du client ont été améliorés et plusieurs blocs internes du groupe de blocs peuvent être traités en parallèle
DataNode : DataNode exécute des tâches ErasureCodingWorker (ECWorker) supplémentaires pour la récupération en arrière-plan des blocs de codage d'effacement ayant échoué. Le NameNode détecte le bloc EC ayant échoué et sélectionne un DataNode pour la récupération. Ce processus est similaire à la restauration des blocs de la copie en cas d'échec. Reconstruisez et exécutez trois nœuds de tâches clés:

Lire des données à partir du nœud source: utilisez un pool de threads dédié pour lire les données d'entrée à partir du nœud source en parallèle. Sur la base de la stratégie EC, les demandes de lecture sont lancées pour toutes les cibles sources, et seul le nombre minimum de blocs d'entrée est lu pour la reconstruction.
Décodez les données et générez des données de sortie: décodez les nouveaux blocs de données et de parité à partir des données d'entrée. Toutes les données perdues sont décodées avec le bloc de parité.
Transmettez le bloc de données généré au nœud cible: une fois le décodage terminé, le bloc récupéré sera transmis aux DataNodes cibles.

Stratégie de codage d'effacement : afin de s'adapter à des charges de travail hétérogènes, les fichiers et répertoires d'un cluster HDFS peuvent avoir différentes stratégies de codage de réplication et d'effacement. La stratégie de codage d'effacement résume comment encoder / décoder des fichiers. Chaque stratégie est définie par les informations suivantes:

Mode EC: Cela inclut le nombre de blocs de données et de parité dans le groupe EC (par exemple 6 + 3), et l'algorithme de codec (par exemple Reed-Solomon, XOR).
La taille de l'unité de traçage. Cela détermine la granularité de la lecture et de l'écriture par bandes, y compris la taille de la mémoire tampon et le travail d'encodage.

Nous pouvons définir notre propre politique CE via un fichier XML, qui doit contenir les trois parties suivantes:

layoutversion: Ceci représente la version du format de fichier XML de la politique EC.

schémas: cela inclut tous les schémas EC définis par l'utilisateur.

Stratégies: cela inclut toutes les stratégies EC définies par l'utilisateur. Chaque stratégie se compose d'un identifiant de schéma et de la taille de l'unité d'entrelacement (taille des cellules).

Il existe un fichier d'exemple XML pour la configuration des politiques EC dans le répertoire Hadoop conf. Vous pouvez vous référer à ce fichier pendant la configuration. Le nom de fichier est user_ec_policies.xml.template.

Configuration matérielle du cluster

Les codes d'effacement imposent d'autres exigences au cluster en termes de CPU et de réseau:

L'encodage et le décodage consommeront du processeur supplémentaire sur le client HDFS et DataNode.
Les fichiers de code d'effacement sont également distribués dans tout le rack pour atteindre la tolérance aux pannes du rack. Cela signifie que lors de la lecture et de l'écriture de fichiers entrelacés, la plupart des opérations sont effectuées sur le rack. Par conséquent, le réseau divisant par deux la bande passante est très important.
Pour la tolérance aux pannes de rack, il est également important d'avoir au moins autant de racks que la largeur de la bande EC configurée. Pour la stratégie EC RS (6, 3), cela signifie un minimum de 9 racks, et idéalement 10 ou 11 racks, pour gérer les pannes planifiées et non planifiées. Pour les clusters dont les racks sont inférieurs à la largeur de bande, HDFS ne peut pas maintenir la tolérance aux pannes de rack, mais essaiera toujours de distribuer les fichiers entrelacés entre plusieurs nœuds pour préserver la tolérance aux pannes au niveau des nœuds.

Enfin

Par défaut dans HDFS, toutes les stratégies EC sont interdites. Nous pouvons activer les stratégies EC via la commande hdfs ec [-enablePolicy -policy] en fonction de la taille du cluster et des propriétés de tolérance aux pannes requises. Par exemple, pour un cluster avec 9 racks, une stratégie telle que RS-10-4-1024k ne préserve pas la tolérance aux pannes au niveau du rack, tandis que RS-6-3-1024k ou RS-3-2-1024k peut plus approprié.

Dans le cadre du mécanisme de réplique, nous pouvons définir le facteur de réplique et spécifier le nombre de répliques, mais dans le cadre de la politique EC, la spécification du facteur de réplique n'a pas de sens, car il est toujours 1 et ne peut pas être modifié via des commandes associées.