Aujourd’hui, notre monde est entré dans l’ère des données. Avec le développement rapide des technologies de l’information telles que l’Internet, l’IoT, la 5G, le big data, l’intelligence artificielle, la conduite autonome et le métaverse, la quantité totale de données que les gens génèrent, collectent, stockent, gèrent et analysent augmente rapidement. Les données à grande échelle dans des secteurs sous des formes diverses, des formats complexes, à grande échelle et une génération rapide ont entraîné des changements rapides dans les nouvelles technologies de support informatique de base sous-jacentes. Grâce aux conseils et à la pratique de pionniers de l'industrie et du monde universitaire au cours des 10 dernières années, l'écosystème technologique du calcul parallèle distribué et du stockage de données distribué a continué d'évoluer, de devenir riche et prospère. Parmi eux, la gestion du stockage de données distribué joue un rôle fondamental dans cette pile technologique massive de traitement de données et constitue la pierre angulaire de l’analyse des applications Big Data dans de nombreux secteurs.

Le système de fichiers distribués est un système de gestion de stockage de données distribué grand public qui a été largement utilisé à l'ère du calcul haute performance et du Big Data. Ces dernières années, avec le développement continu de la technologie du cloud computing, l'application du stockage d'objets distribués, du stockage clé-valeur et d'autres technologies est également devenue populaire. Dans ce contexte, de nombreux systèmes de fichiers distribués ont commencé à emprunter la voie technique d'une gestion unifiée et efficace du stockage des données. Parmi eux, un système bien connu et couramment utilisé par les utilisateurs est Alluxio, né dans l'AMPLab de l'Université de Californie à Berkeley. Il peut être considéré comme un système de fichiers virtuels Big Data unifié, différents types de systèmes de stockage distribués (systèmes de fichiers, systèmes de stockage d'objets) peuvent être montés dans le répertoire Alluxio pour fournir des modes d'accès et des interfaces efficaces et unifiés. Les métadonnées constituent le type d’informations clés le plus important et le plus fréquemment consulté sur les données d’un système de stockage. Afin de gérer efficacement les fichiers de données et les objets à grande échelle provenant de différents systèmes de stockage distribués sous-jacents, Alluxio doit fournir un mécanisme de gestion des métadonnées à grande échelle efficace et évolutif.

Cet article prend la version open source d'Alluxio 2.8 comme exemple pour révéler le mécanisme de gestion des métadonnées à grande échelle courant dans les systèmes de fichiers distribués. Pour les utilisateurs d'Alluxio, les utilisateurs interagissent avec l'interface du système de fichiers Alluxio via des métainformations de fichiers, et lisent, écrivent et mettent en cache des données via des métainformations de blocs de données. Les métainformations des fichiers et des blocs de données sont stockées et gérées uniformément par Alluxio Master.

0 1. Types courants de métadonnées de système de fichiers distribués

Parmi les métadonnées gérées par Alluxio Master, les catégories les plus importantes sont les métadonnées de fichiers, les métadonnées de blocs de données, les métadonnées de point de montage et les métadonnées Alluxio Worker.

Métadonnées de fichier (inode)

Chaque fichier ou dossier du système de fichiers Alluxio est représenté par un inode. Cet inode stocke tous les attributs et méta-informations du fichier, y compris les attributs de fichier de base, les informations d'autorisation, les attributs de gestion, les horodatages, les blocs de données contenus et chaque métadonnée d'une donnée. bloquer, etc Le concept d'"inode" vient des systèmes de fichiers de type Unix et est largement utilisé dans les systèmes de fichiers tels que Linux et HDFS. Un inode représente un nœud dans l'arborescence des répertoires du système de fichiers. Étant donné qu'Alluxio gère plusieurs magasins sous-jacents, le nombre potentiel de fichiers dans l'espace de noms Alluxio est en réalité la somme des fichiers de tous les magasins sous-jacents. En tant que service le plus important du cluster Alluxio, le service de métadonnées détermine directement l'échelle, les performances et la stabilité du système. Il convient de mentionner que les inodes du système de fichiers Alluxio n'existent pas nécessairement dans le stockage sous-jacent. Par exemple, si ce chemin est écrit dans Alluxio en utilisant le mode MUST_CACHE, Alluxio ne créera pas ce fichier dans le stockage sous-jacent. De plus, si le stockage sous-jacent est un stockage d'objets, étant donné que le stockage d'objets n'a pas le concept de dossiers, les dossiers d'Alluxio ne correspondront pas aux objets réels du stockage sous-jacent.

De manière générale, la gestion des inodes par Alluxio Master peut être abstraitement divisée dans les catégories suivantes :

En utilisant un InodeTree pour stocker toutes les informations sur les inodes et la structure arborescente entre les inodes (la relation parent-enfant entre les dossiers et les fichiers), Alluxio Master maintient la structure arborescente du système de fichiers.
Implémente l'interface pour les opérations du système de fichiers et prend en charge toutes les opérations sur les fichiers. Alluxio Master ouvre une série d'interfaces d'exploitation du système de fichiers et fournit des garanties de sécurité de concurrence et de persistance pour chaque opération. De cette manière, il fournit un système de fichiers distribué aux applications de couche supérieure.
Maintenez un état persistant via le journal du journal pour garantir la persistance et l’atomicité de chaque opération d’inode. Alluxio Master garantit que les informations sur les inodes et chaque opération sont enregistrées dans le journal du journal, garantissant ainsi que les informations et les modifications de l'inode ne seront en aucun cas perdues.
InodeTree d'Alluxio prend en charge l'accès simultané en lecture et en écriture au niveau de l'inode en affinant la granularité du verrouillage de chaque inode. Le contrôle de concurrence est effectué sur chaque inode via des verrous pour garantir la sécurité des threads de l'inode lors de la lecture et de l'écriture simultanées.

Métadonnées du bloc de données

Si l'inode correspond à un fichier, il contient 0 (fichier vide) ou plusieurs blocs de données. Pour un nouveau fichier, la taille de tous les blocs de données est définie par alluxio.user.block.size.bytes.default sauf le dernier bloc de données. Un fichier avec un seul bloc de données est également compté comme dernier bloc de données. La gestion des méta-informations des blocs de données est relativement simple par rapport aux inodes, car il n'y a pas de structure arborescente ni de relation parent-enfant entre les blocs de données.

Alluxio Master enregistre les métainformations des blocs de données et l'emplacement actuel du cache des blocs de données, et fournit des interfaces de lecture et d'écriture externes pour ces informations. Les métadonnées des blocs de données gérées par Alluxio Master peuvent être brièvement considérées comme deux magasins clé-valeur :

（1）<BlockID, BlockMetadata>

（2）<BlockID, Liste<BlockLocation>>

Parmi eux, BlockMetadata enregistre la longueur du bloc de données. BlockLocation enregistre l'adresse du nœud Alluxio Worker où ce bloc de données (cache) existe, ainsi que l'emplacement de stockage spécifique de ce bloc de données sur le nœud Alluxio Worker.

Ces deux informations différentes sont stockées séparément principalement en raison de leurs cycles de vie différents. Les métadonnées de bloc sont immuables. Alluxio ne prend pas en charge les modifications aléatoires ni ne s'ajoute à des blocs de données déjà écrits. Si ce fichier est réécrit, il obtiendra un nouveau FileID (c'est-à-dire InodeID) et un nouveau BlockID, et les anciens blocs de données seront supprimés. Au contraire, la liste BlockLocation continuera à changer. Par exemple, lorsque le bloc de données est chargé dans un nouvel Alluxio Worker ou est expulsé d'un Alluxio Worker, les informations de la liste changeront en conséquence.

Monter la table

MountTable gère les points de montage dans tous les systèmes de fichiers Alluxio et fournit des opérations telles que la création et la modification des points de montage. Dans le même temps, le chemin du fichier Alluxio et le chemin du fichier du stockage sous-jacent sont également résolus et correspondent l'un à l'autre via MountTable.

Métadonnées du travailleur

La gestion par Alluxio Master des métadonnées d'Alluxio Worker comprend le suivi des Alluxio Workers qui travaillent actuellement et la mise à jour constante de la liste de cache sur Alluxio Workers. Les informations enregistrées par Alluxio Master comprennent principalement :

(1) Adresse Alluxio Worker, heure de démarrage et autres informations constantes.

(2) L'utilisation de l'espace d'Alluxio Worker, y compris l'utilisation de chaque couche du cache multicouche, est mise à jour à chaque battement de cœur.

(3) Tous les BlockID mis en cache dans Alluxio Worker et tous les BlockID à supprimer d'Alluxio Worker. Ces informations changent à chaque battement de cœur et opération de blocage (chargement, expulsion, etc.).

0 2. Mode de stockage des métadonnées du système de fichiers distribué

Le stockage des métadonnées dans les systèmes de fichiers distribués comprend généralement le stockage sur tas et le stockage hors tas. Parmi eux, l'accès au stockage sur tas est efficace, mais l'espace est limité, tandis que l'espace de stockage hors tas est volumineux, mais s'il n'est pas conçu correctement, il entraînera des pertes de performances.

2.1 Les métadonnées sont stockées sur le tas (mode HEAP)

En prenant Alluxio comme exemple, en mode HEAP, toutes les métainformations sont stockées dans le tas de la JVM sous forme d'objets Java. Chaque fichier occupe environ 2 à 4 Ko de mémoire sur le tas. Par conséquent, lorsqu'il y a un grand nombre de fichiers dans le système de fichiers Alluxio, les méta-informations sur le tas entraîneront une forte pression mémoire sur la JVM. Il n'est pas difficile de calculer que lorsqu'il y a 100 millions de fichiers dans le système, le simple stockage des métainformations de ces fichiers sur la JVM occupera 200 Go à 400 Go. Couplées à la grande quantité de surcharge de mémoire d'opération RPC que la JVM principale doit supporter, les besoins en mémoire de cette JVM sont difficiles à supporter pour les serveurs ordinaires.

De plus, le GC avec une telle taille de données devient très difficile à gérer pour la plupart des versions de JVM. Ces méta-informations dans la JVM Alluxio Master sont des objets de longue durée, qui auront notamment un grand impact sur l'efficacité du GC de l'ancienne génération. Bien qu'il existe certaines versions commerciales de JVM qui peuvent éviter certains ou la plupart des problèmes de performances et de gestion causés par JVM, pour la plupart des utilisateurs, une utilisation excessive de JVM reste un problème très difficile, en particulier la JVM d'Alluxio Master pourrait changer à l'avenir. Par conséquent, l'expansion de l'activité peut dépasser la limite supérieure de la mémoire physique de la machine.

2.2 Les métadonnées sont stockées en dehors du tas (mode ROCKS)

En réponse au problème de la difficulté à étendre le mode HEAP, Alluxio a optimisé l'orientation de la conception. Alluxio a introduit le mode ROCKS dans la version 2.0, déplaçant le stockage des méta-informations en dehors de la JVM. En mode ROCKS, Alluxio Master intègre un RocksDB, qui déplace les métainformations des fichiers (et des blocs de données) du tas JVM précédent vers RocksDB. Le support de stockage de RocksDB est en fait le disque dur au lieu de la mémoire. Pour utiliser RocksDB pour stocker des métadonnées, il vous suffit de configurer le mode de stockage des métadonnées et de spécifier le chemin d'accès au stockage RocksDB :

alluxio.master.metastore=ROCHES

alluxio.master.metastore.dir=${alluxio.work.dir}/metastore

RocksDB intégré dans Alluxio utilisera le chemin configuré par alluxio.master.metastore.dir comme son propre stockage de métadonnées. Dans l'exemple suivant, nous visualisons le stockage RocksDB d'un cluster Alluxio en cours d'exécution. Nous pouvons voir qu'Alluxio dispose d'un répertoire de stockage pour les métadonnées Inode et Block enregistrées dans RocksDB et gère les fichiers de données gérés par RocksDB. La structure des répertoires de stockage de RocksDB ne sera pas décrite en détail dans ce livre. Les lecteurs peuvent consulter la documentation officielle de RocksDB.

$ ls -al -R metastore/

metastore/:

total 8

drwxrwxr-x. 2 alluxio-user alluxio-group 4096 May 21 03:20 blocks

drwxrwxr-x. 2 alluxio-user alluxio-group 4096 May 21 03:33 inodes

 

metastore/blocks:

total 4264

-rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 000005.log

-rw-r--r--. 1 alluxio-user alluxio-group    16 May 21 03:20 CURRENT

-rw-r--r--. 1 alluxio-user alluxio-group    36 May 21 03:20 IDENTITY

-rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 LOCK

-rw-r--r--. 1 alluxio-user alluxio-group 52837 May 21 03:30 LOG

-rw-r--r--. 1 alluxio-user alluxio-group   176 May 21 03:20 MANIFEST-000004

-rw-r--r--. 1 alluxio-user alluxio-group 13467 May 21 03:20 OPTIONS-000009

-rw-r--r--. 1 alluxio-user alluxio-group 13467 May 21 03:20 OPTIONS-000011

 

metastore/inodes:

total 4268

-rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 000005.log

-rw-r--r--. 1 alluxio-user alluxio-group  1211 May 21 03:33 000012.sst

-rw-r--r--. 1 alluxio-user alluxio-group    16 May 21 03:20 CURRENT

-rw-r--r--. 1 alluxio-user alluxio-group    36 May 21 03:20 IDENTITY

-rw-r--r--. 1 alluxio-user alluxio-group     0 May 21 03:20 LOCK

-rw-r--r--. 1 alluxio-user alluxio-group 58083 May 21 03:33 LOG

-rw-r--r--. 1 alluxio-user alluxio-group   247 May 21 03:33 MANIFEST-000004

-rw-r--r--. 1 alluxio-user alluxio-group 13679 May 21 03:20 OPTIONS-000009

-rw-r--r--. 1 alluxio-user alluxio-group 13679 May 21 03:20 OPTIONS-000011

2.3 Utilisation de la mémoire et du disque du stockage hors tas

En mode ROCKS, les méta-informations sont stockées dans RocksDB hors tas, ce qui réduira considérablement la pression mémoire du stockage des méta-informations sur le processus Alluxio Master. Par rapport au mode HEAP, toutes les lectures et écritures de méta-informations sont réduites de la vitesse de la mémoire à la vitesse du disque dur, ce qui affectera grandement les performances et le débit d'Alluxio Master. Par conséquent, Alluxio Master ajoute un cache en mémoire pour accélérer l'accès à RocksDB. En d’autres termes, en mode ROCKS, l’utilisation de la mémoire pour le stockage des méta-informations devient l’utilisation de la mémoire pour cette partie du cache. Semblable à l'estimation de l'utilisation de la mémoire en mode HEAP, le stockage des méta-informations de chaque fichier dans le cache occupe les mêmes 2 Ko à 4 Ko.

La taille du cache est contrôlée par alluxio.master.metastore.inode.cache.max.size. La valeur de cet élément de configuration peut varier en fonction de la version d'Alluxio. Alluxio Master écrira d'abord dans le cache, puis commencera à écrire sur RocksDB (disque) lorsque le cache atteint un certain niveau d'utilisation. L'utilisation du disque de RocksDB est la suivante : les méta-informations d'environ 1 million de fichiers occupent environ 4 Go d'espace disque. Il convient de noter que lorsque le nombre de fichiers dans l'espace de noms Alluxio ne déclenche pas l'expulsion basée sur alluxio.master.metastore.inode.cache.max.size, toutes les métainformations des fichiers se trouvent dans le cache en mémoire et ne sont pas écrites dans RocksDB. À l'heure actuelle, l'utilisation du disque de métadonnées de ces fichiers est proche de 0.

2.4 Accélération du cache et réglage du stockage hors tas

Lorsqu'il y a suffisamment d'espace mémoire, augmenter de manière appropriée alluxio.master.metastore.inode.cache.max.size peut mettre en cache davantage de métainformations de fichier en mémoire pour améliorer les performances. Dans le même temps, il convient de noter que les opérations RPC sur Alluxio Master consommeront également de la mémoire. Même si aucune opération RPC n'est en cours, il y aura toujours une logique de gestion interne telle que l'analyse régulière des fichiers sur l'Alluxio Master qui consomme de la mémoire. Lors de l'estimation de la mémoire dans le processus Alluxio Master, vous devez réserver suffisamment de mémoire pour ces opérations et ne pas laisser le stockage des méta-informations occuper toute la mémoire. C'est la même raison pour laquelle 100 % de la mémoire du serveur ne peut pas être allouée à l'application sans réserver de l'espace mémoire pour le système d'exploitation. La gestion du cache de métainformations est basée sur le mécanisme de niveau d'eau. L'utilisateur configure un paramètre de niveau d'eau haut et un paramètre de niveau d'eau bas. Par exemple, voici la configuration par défaut :

alluxio.master.metastore.inode.cache.high.water.mark.ratio=0.85

alluxio.master.metastore.inode.cache.low.water.mark.ratio=0.8

Lorsque l'utilisation du cache atteint 0,85 * alluxio.master.metastore.inode.cache.max.size, les données mises en cache commenceront à être expulsées et le contenu des données dans le cache sera écrit dans le stockage RocksDB. Arrêtez l'expulsion lorsque l'occupation du cache tombe à 0,8.

2.5 Basculer entre les modes HEAP et ROCKS

Le format du journal est différent lors de l'utilisation du mode HEAP et du mode ROCKS, donc le passage d'un mode à l'autre ne peut pas se faire en modifiant simplement la configuration et en redémarrant le processus Alluxio Master. Le changement de mode de stockage des métadonnées peut être effectué en démarrant le cluster à partir de la sauvegarde, voir Chapitre 4.5.

Cet article prend Alluxio comme exemple pour présenter brièvement les types de base de métadonnées des systèmes de fichiers distribués et leurs méthodes de gestion et d'optimisation. Pour plus de détails sur l'optimisation de l'accès aux données, vous pouvez vous référer davantage au code de la communauté open source Alluxio. Vous êtes également les bienvenus pour lire les récentes publications de Machinery Industry Press Le livre technique "Distributed Unified Big Data Virtual File System - Alluxio Principes, Technology and Practice" :

Ce livre est écrit sur la base de la version open source Alluxio 2.8.0, largement utilisée. Il fournit une introduction approfondie aux principes techniques et aux cas pratiques des systèmes de fichiers Big Data unifiés distribués liés à Alluxio. Le contenu principal comprend l'entrée et l'utilisation du système. , les principes de conception et de mise en œuvre des composants du noyau, et détaillés. Il présente des cas et des pratiques d'application d'entreprise à grande échelle et est accompagné du guide du développeur de la communauté open source d'Alluxio. Ce livre fournit un guide technique relativement complet et des tutoriels pratiques pour les utilisateurs de la communauté open source Alluxio, les enseignants et les étudiants des cours sur les systèmes Big Data dans les universités et les utilisateurs potentiels en entreprise. Il peut être utilisé comme manuel professionnel dans le domaine du Big Data, comme ainsi que pour les praticiens et les chercheurs du Big Data.Informations professionnelles importantes de l'auteur.

Révéler le mécanisme de gestion des métadonnées à grande échelle des systèmes de fichiers distribués - en prenant le système de fichiers Alluxio comme exemple