Contrairement à tout sous-système d'E/S, Hadoop est également livré avec un ensemble de primitives. Ces considérations primitives, bien que de nature générique, vont également avec le système Hadoop IO avec une connotation particulière, bien sûr. Hadoop traite plusieurs téraoctets d'ensembles de données ; une considération particulière sur ces primitives donnera une idée de la façon dont Hadoop gère l'entrée et la sortie des données. Cet article survole rapidement ces primitives pour donner une perspective sur le système d'entrée-sortie Hadoop.
Intégrité des données
Intégrité des données signifie que les données doivent rester exactes et cohérentes tout au long de leurs opérations de stockage, de traitement et de récupération. Pour s'assurer qu'aucune donnée n'est perdue ou corrompue pendant la persistance et le traitement, Hadoop maintient des contraintes strictes d'intégrité des données. Chaque opération de lecture/écriture se produit sur les disques, d'autant plus que le réseau est sujet aux erreurs. Et le volume de données que Hadoop gère ne fait qu'aggraver la situation. Le moyen habituel de détecter des données corrompues consiste à utiliser des sommes de contrôle. Une somme de contrôle est calculé lorsque les données entrent pour la première fois dans le système et est envoyé sur le canal pendant le processus de récupération. L'extrémité de récupération calcule à nouveau la somme de contrôle et correspond à celles reçues. Si cela correspond exactement, les données sont considérées comme sans erreur, sinon elles contiennent une erreur. Mais le problème est - que se passe-t-il si la somme de contrôle envoyée elle-même est corrompue ? Ceci est hautement improbable car il s'agit d'une petite donnée, mais pas d'une possibilité indéniable. L'utilisation du bon type de matériel tel que la mémoire ECC peut être utilisée pour atténuer la situation.
Ceci est une simple détection. Par conséquent, pour corriger l'erreur, une autre technique, appelée CRC (Cyclic Redundancy Check), est utilisée.
Hadoop va plus loin et crée une somme de contrôle distincte pour chaque 512 octets (par défaut) de données. Étant donné que CRC-32 ne contient que 4 octets, la surcharge de stockage n'est pas un problème. Toutes les données qui entrent dans le système sont vérifiées par les nœuds de données avant d'être transmises pour stockage ou traitement ultérieur. Les données envoyées au pipeline datanode sont vérifiées par des sommes de contrôle et toute corruption trouvée est immédiatement notifiée au client avec ChecksumException . Le client lu à partir du nœud de données passe également par le même exercice. Les nœuds de données maintiennent un journal de vérification de la somme de contrôle pour garder une trace du bloc vérifié. Le journal est mis à jour par le nœud de données lors de la réception d'un signal de succès de vérification de bloc du client. Ce type de statistiques aide à garder les disques défectueux à distance.
En dehors de cela, une vérification périodique du magasin de blocs est effectuée à l'aide de DataBlockScanner en cours d'exécution avec le thread datanode en arrière-plan. Cela protège les données contre la corruption dans le support de stockage physique.
Hadoop conserve une copie ou des répliques des données. Ceci est spécifiquement utilisé pour récupérer des données suite à une corruption massive. Une fois que le client détecte une erreur lors de la lecture d'un bloc, il signale immédiatement au datanode le bloc défectueux à partir du namenode avant de lancer ChecksumException . Le namenode le marque alors comme un bloc défectueux et planifie toute autre référence au bloc à ses répliques. De cette façon, la réplique est maintenue avec d'autres répliques et le bloc défectueux marqué est supprimé du système.
Pour chaque fichier créé dans Hadoop LocalFileSystem , un fichier caché portant le même nom dans le même répertoire avec l'extension .
Compression
Compte tenu du volume de données traité par Hadoop, la compression n'est pas un luxe mais une exigence. La compression de fichiers utilisée à juste titre par Hadoop présente de nombreux avantages évidents. Il économise les besoins en stockage et est une capacité indispensable pour accélérer la transmission des données sur le réseau et les disques. Il existe de nombreux outils, techniques et algorithmes couramment utilisés par Hadoop. Beaucoup d'entre eux sont très populaires et ont été utilisés dans la compression de fichiers au fil des ans. Par exemple, gzip, bzip2, LZO, zip, etc. sont souvent utilisés.
Sérialisation
Le processus qui transforme les objets structurés en flux d'octets est appelé sérialisation . Ceci est spécifiquement requis pour la transmission de données sur le réseau ou la persistance de données brutes sur des disques. Désérialisation est juste le processus inverse, où un flux d'octets est transformé en un objet structuré. Ceci est particulièrement nécessaire pour l'implémentation d'objet des octets bruts. Il n'est donc pas surprenant que l'informatique distribuée l'utilise dans deux domaines distincts :la communication inter-processus et la persistance des données.
Hadoop utilise RPC (Remote Procedure Call) pour mettre en place une communication inter-processus entre les nœuds. Par conséquent, le protocole RPC utilise le processus de sérialisation et de désérialisation pour rendre un message au flux d'octets et vice versa et l'envoie sur le réseau. Cependant, le processus doit être suffisamment compact pour utiliser au mieux la bande passante du réseau, ainsi que rapide, interopérable et flexible pour s'adapter aux mises à jour du protocole au fil du temps.
Hadoop a son propre format de sérialisation compact et rapide, Writables , que les programmes MapReduce utilisent pour générer des clés et des types de valeur.
Structure de données des fichiers
Il existe quelques conteneurs de haut niveau qui élaborent la structure de données spécialisée dans Hadoop pour contenir des types de données spéciaux. Par exemple, pour maintenir un journal binaire, le SequenceFile Le conteneur fournit la structure de données pour conserver les paires clé-valeur binaires. Nous pouvons ensuite utiliser la clé, comme un horodatage représenté par LongWritable et valeur par Writable , qui fait référence à la quantité enregistrée.
Il existe un autre conteneur, une dérivation triée de SequenceFile , appelé MapFile . Il fournit un index pour des recherches pratiques par clé.
Ces deux conteneurs sont interopérables et peuvent être convertis l'un vers l'autre.
Conclusion
Ceci n'est qu'un aperçu rapide du système d'entrée/sortie de Hadoop. Nous approfondirons de nombreux détails complexes dans les articles suivants. Il n'est pas très difficile de comprendre le système d'entrée/sortie Hadoop si l'on a une compréhension de base des systèmes d'E/S en général. Hadoop a simplement mis un peu plus de jus pour suivre sa nature distribuée qui fonctionne à grande échelle de données. C'est tout.
Référence
Blanc, Tom. Hadoop, Le guide définitif, 2009 . O'Reilly Publications.
