Skip to main content

Sélections de la rédaction

Système de fichiers distribués Hadoop

Published Date

Ce billet de blogue présente la nouvelle ère du stockage : le système de fichiers distribués Hadoop (HDFS). Il s’agit de l’une des sources de données externes qu’il est possible d’enregistrer auprès de GeoAnalytics Server d’Esri. Les données spatiales et non spatiales sont stockées dans le HDFS et référencées dans GeoAnalytics Server, ce qui permet aux outils de GeoAnalytics d’obtenir les données dont ils ont besoin. De plus, les résultats des outils de GeoAnalytics sont écrits dans un emplacement du HDFS enregistré.

Le stockage d’ensembles de données dans plusieurs tables liées sur un seul ordinateur est pratiquement de l’histoire ancienne. Tout comme l’utilisation d’Internet pour communiquer avec les personnes et les entreprises, l’emploi de capteurs et d’appareils mobiles est devenu omniprésent dans la société moderne. Ces technologies entraînent la création et la collecte d’un volume important de données non structurées, volume qui a d’ailleurs rapidement dépassé la capacité de stockage des bases de données relationnelles se trouvant dans un même référentiel et sur un seul appareil. C’est pourquoi ce billet de blogue aborde la nouvelle ère de la collecte et du stockage des données massives. Plus précisément, il présente le concept de stockage distribué qui a été développé pour répondre aux nouveaux besoins en matière de stockage et de gestion des données. Nous nous attarderons sur le système de fichiers distribués Hadoop (HDFS) d’Apache.

Auparavant, les responsables des données utilisaient les systèmes de fichiers pour stocker, organiser et trouver des données sur un dispositif de stockage. Parmi les systèmes de fichiers bien connus, on retrouve la table d’allocation des fichiers 32 bits (FAT32) et le nouveau système de fichiers NTFS avec efficacité améliorée de Microsoft. Sous Linux, les équivalents sont le système de fichiers étendus 3 et 4 (Ext3 et Ext4) et XFS, qui a été créé par Silicon Graphics et porté sous Linux en 2001. Ces systèmes de fichiers sont des « systèmes de fichiers locaux », car ils disposent d’une vue locale (centrée sur la machine) des données et de l’espace de stockage qu’ils gèrent. Les systèmes d’exploitation s’appuient sur ces systèmes de fichiers pour stocker et gérer les données locales. Le HDFS est également un système de fichiers, comme ceux mentionnés ci-dessus. Toutefois, contrairement aux systèmes de fichiers locaux, il possède une vue distribuée des données, qui sont réparties dans une grappe de machines. En d’autres mots, le HDFS gère le système de fichiers local propre à chaque machine. Les systèmes de fichiers distribués sont essentiellement une composante des systèmes distribués, qui utilisent des grappes de matériel de base pour stocker et traiter les données. Hadoop est l’un des systèmes distribués les plus populaires qu’il est possible d’intégrer à l’écosystème de logiciels SIG d’Esri. Principal composant de stockage de données d’Hadoop, le HDFS permet aux utilisateurs de stocker des mégadonnées, plus communément appelées des « données massives », sur des centaines de machines (nœuds) au sein d’une grappe.

Comme le mentionnait le précédent billet de blogue Options de stockage des données pour GeoAnalytics Server, ce système est l’une des sources de données externes prises en charge par GeoAnalytics Server d’Esri. Les données spatiales (comme les fichiers SHP) et non spatiales (comme les fichiers texte, CSV ou autres) peuvent être stockées dans le HDFS et référencées dans GeoAnalytics Server afin que tous les outils d’analyse offerts par la plateforme GeoAnalytics disposent des données dont ils ont besoin. De plus, les résultats des outils de GeoAnalytics peuvent être écrits dans un emplacement du HDFS enregistré. L’écriture des résultats générés par les outils de GeoAnalytics dans le HDFS est prise en charge dans ArcGIS Enterprise 10.7 et les versions subséquentes. Les sections suivantes de ce billet de blogue vous expliqueront quand et comment utiliser le HDFS (ou tout autre type de stockage distribué de données).

Quand utiliser le HDFS?

Avec l’utilisation croissante des magasins de données non relationnels et distribués (comme le magasin de données massives spatiotemporelles d’Esri, les bases de données NoSQL, les systèmes de stockage d’objets ou les systèmes de fichiers), il est pertinent de se demander si le modèle de base de données relationnelle est désuet. La réponse simple à cette question est non. Les bases de données relationnelles traitent encore très rapidement les tâches en ligne associées à des transactions, pour lesquelles un niveau élevé de cohérence est crucial. Par exemple, de nombreuses banques continuent d’employer le modèle de base de données relationnelle pour stocker toutes les transactions bancaires en ligne, car leurs activités exigent une cohérence en temps réel. La cohérence pour les données bancaires signifie que tous les utilisateurs du système doivent voir les mêmes données sur demande. Il est inacceptable qu’une version différente d’une donnée d’un même compte s’affiche si on interroge des serveurs différents. Tous les utilisateurs doivent être en mesure de voir la valeur la plus à jour, peu importe le serveur traitant les requêtes de base de données. Une personne au Canada doit voir la même version d’une donnée qu’une personne en Europe, quel que soit le serveur qui exécute la requête.

Par conséquent, la cohérence est une propriété importante d’une base de données relationnelle, une propriété que la plupart des systèmes de stockage de données NoSQL et des autres systèmes de fichiers distribués ne peuvent garantir. Il existe toutefois quelques exceptions à cette faiblesse. Par exemple, MongoDB hérite de la cohérence du modèle de base de données relationnelle. Plutôt que d’offrir une cohérence en temps réel, les systèmes de stockage distribué proposent une cohérence à terme, c’est-à-dire que tous les utilisateurs d’un système verront la valeur la plus à jour après un court délai, soit le temps que la modification de la donnée soit propagée à tous les autres serveurs d’une grappe. Si nous reprenons notre exemple, il se peut que la personne au Canada voie la dernière version d’une donnée plus rapidement que la personne en Europe si leur requête est exécutée par des serveurs différents.

Une autre question revient souvent à propos des magasins de données non relationnels et distribués : pourquoi sont-ils devenus si populaires au cours des dernières années? C’est simple : en raison de leur évolutivité et de leurs performances. Lorsque des données massives doivent être analysées, la priorité passe de la cohérence à la performance (traitement des opérations de lecture et d’écriture) et à l’évolutivité. Le système doit fournir suffisamment de ressources pour mener à bien le stockage et traiter les données avec efficacité. C’est pourquoi les magasins de données non relationnels et distribués sont généralement la meilleure option pour les données massives. On peut d’ailleurs retrouver ces données sous divers formats, des données structurées aux données non structurées, en passant par celles semi-structurées. Par « données non structurées », on entend des informations qui, contrairement aux données structurées, ne cadrent pas avec le format traditionnel ligne-colonne des bases de données relationnelles. Le texte, les images et les vidéos font partie des principaux types de données non structurées. Entre ces deux extrêmes, il existe une troisième catégorie appelée semi-structurée. Comme les données non structurées, les données semi-structurées ne s’intègrent pas bien dans le format tabulaire des bases de données relationnelles, mais il est toujours possible de créer des propriétés sémantiques (telles que des balises ou des clés) qui peuvent être utilisées pour interpréter le contenu des données. Les documents au format XML (langage de balisage extensible) et JSON (notation des objets du langage Java) sont deux exemples de données semi-structurées, pour lesquelles les magasins de données non relationnels sont tout indiqués. MongoDB (qui stocke les données sous forme de documents binaires JSON [BSON]) et Couchbase seraient de bonnes options pour stocker et interroger les documents JSON en raison de leurs fonctionnalités de traitement adaptées à ce type de fichiers.

Si vous souhaitez déterminer le bon type de base de données de façon plus intuitive, utilisez les quadrants ci-dessous pour classer vos données en fonction de leur structure et de leur fréquence de modification :

Les données dynamiques sont continuellement modifiées (insertion, mise à jour ou suppression). De leur côté, les données statiques ne sont pas modifiées après avoir été recueillies ou le sont que très rarement. Comme on peut le voir dans le tableau ci-dessus, les bases de données relationnelles sont parfaites pour les données structurées et dynamiques. Si vous devez stocker des données transactionnelles nécessitant des mises à jour en ligne, optez pour une base de données relationnelle, qui vous offrira de bonnes performances. Toutefois, si le volume des données est extrêmement élevé, vous pouvez vous tourner vers certaines bases de données NoSQL (comme MongoDB). Quant aux données structurées et statiques, les magasins ou les entrepôts de données non relationnels sont tout indiqués en raison de leurs performances de requête. Bien qu’un entrepôt de données soit une base de données relationnelle, sa conception est différente, car la base de données est utilisée à des fins d’analyse plutôt que de traitement transactionnel. Par exemple, la dénormalisation et le stockage des données dans un petit nombre de tables sont une pratique courante de l’entreposage des données. En fait, les entrepôts de données doivent également être mis à jour, mais contrairement aux bases de données transactionnelles, les mises à jour n’ont pas besoin d’être appliquées instantanément. Selon le secteur d’activités, l’entrepôt de données pourrait être mis à jour à la fin de chaque semaine ou à la fin de la journée, voire plusieurs fois par jour. Les mises à jour ne seraient cependant pas effectuées en ligne. Les magasins de données non relationnels (comme le HDFS) ou les entrepôts de données distribués (comme Hive) sont d’autres bonnes options pour le stockage de données statiques et structurées : ils traitent les opérations de lecture d’une façon très performante.

En ce qui concerne les données statiques semi-structurées et non structurées, vous pouvez opter pour des magasins de données non relationnels, comme le magasin de données massives spatiotemporelles d’Esri, les systèmes de fichiers (HDFS), les bases de données NoSQL (MongoDB ou HBase) ou les systèmes de stockage d’objets (Amazon S3). De manière générale, les magasins de données distribués offrent les meilleures performances avec des données à écriture unique et à lecture répétée. En fait, une grande partie des données massives sont statiques et sont rarement mises à jour après leur création. Il est plus difficile de stocker des données dynamiques semi-structurées et non structurées. Si les données sont continuellement mises à jour, il est recommandé d’employer des bases de données NoSQL, car elles offrent de meilleures performances.

Pourquoi utiliser le HDFS?

Pour dépasser les limites associées au stockage et au traitement sur une seule machine, il est possible d’augmenter les ressources informatiques de deux manières : la mise à l’échelle verticale (vers le haut) et la mise à l’échelle horizontale (en parallèle). La mise à l’échelle verticale permet d’ajouter des ressources (comme de la mémoire vive et des unités centrales) à la machine existante ou d’en étendre la configuration. Avec la mise à l’échelle horizontale, on augmente en fait la puissance de calcul de l’infrastructure en ajoutant des machines, généralement appelées des « nœuds », au site de serveur. Bien que la mise à l’échelle verticale puisse convenir dans certains cas, la capacité d’une machine demeure tout de même limitée comparativement aux innombrables possibilités qu’offre la mise à l’échelle horizontale. Comme vous vous en doutez, le HDFS est basé sur le concept de mise à l’échelle horizontale, qui présente de nombreux avantages pour le stockage de données :

  • augmentation illimitée de la capacité du système – il est possible d’ajouter des centaines de machines à un système distribué afin d’en accroître la capacité (c’est-à-dire, la puissance de stockage et de calcul);
  • tolérance aux pannes – un système distribué continuera de fonctionner sans interruption si un ou plusieurs composants d’une machine ont une défaillance (par exemple, le disque de stockage);
  • défaillance logicielle – un système distribué peut gérer une défaillance logicielle si une tâche distribuée assignée à un nœud échoue en partie;
  • haute disponibilité – la haute disponibilité est assurée par la capacité de tolérance aux pannes du système. Par « haute disponibilité », on entend que le système n’a presque jamais de défaillance. On mesure la disponibilité d’un système en calculant son temps de fonctionnement, ce qui correspond au pourcentage du temps de fonctionnement total. Le temps de fonctionnement des systèmes distribués bien conçus frôle les 100 %.

Il faut mentionner qu’on a souvent tenté de rendre les bases de données relationnelles évolutives et hautement disponibles. Par exemple, Oracle a proposé l’architecture Maximum Availability Architecture (MAA) pour améliorer ces deux caractéristiques. Elle permet entre autres de mettre à l’échelle horizontalement les bases de données relationnelles d’Oracle sur un ensemble de nœuds. En outre, certaines techniques (comme la fragmentation des données) permettent de diviser physiquement les données et de les répartir dans la grappe. De cette façon, chaque instance de la base de données relationnelle dispose d’un sous-ensemble de données sur son disque local (voir la figure 1).

Figure 1 : fragmentation de tables dans une base de données Oracle (source : Aperçu de la fonction de fragmentation d’Oracle)

Toutefois, le stockage distribué de données normalisées et structurées peut entraîner des problèmes de performances au moment d’interroger les données : dans la plupart des cas, les tables de tous les nœuds doivent être consultées avant de présenter le résultat à l’utilisateur. Et, comme nous l’avons déjà expliqué, les bases de données relationnelles sont la meilleure option pour stocker des données en ligne axées sur les transactions, pour lesquelles la cohérence est cruciale. De plus, selon le théorème CAP (cohérence, disponibilité et tolérance au partitionnement), le stockage distribué de données ne peut assurer simultanément la cohérence et la haute disponibilité (pour plus de renseignements à ce sujet, visitez la page Théorème CAP). Par conséquent, lorsque la cohérence des données doit être parfaite, il est difficile d’avoir également une haute disponibilité. Le HDFS n’est pas soumis à ces limitations, car il est souvent utilisé pour stocker des ensembles de données statiques.

La suite de ce billet de blogue donne un aperçu de l’architecture du HDFS et du fonctionnement des opérations de lecture et d’écriture afin de démontrer comment le cadre Hadoop combine évolutivité, tolérance aux pannes et disponibilité (assurée par la mise à l’échelle horizontale).

Architecture du HDFS

Le HDFS repose sur une architecture maître/esclave, où une machine serveur est la « machine maître » (appelée NameNode) et les autres sont des « machines esclaves » (appelées DataNodes) qui stockent les données (voir la figure 2).

Figure 2 : architecture du HDFS

Dans le HDFS, les opérations sont appliquées aux blocs, c’est-à-dire qu’un fichier est divisé en plusieurs parties (appelés « blocs de données ») au moment où il est stocké dans le système. La taille par défaut d’un bloc de données est de 128 Mo (dans Hadoop 2.x et 3.x), mais il est possible de la modifier, au besoin. Le système stocke ces blocs de données en les répartissant sur une grappe de DataNodes. Pour ce faire, il applique une politique de distribution presque aléatoire, ce qui signifie qu’il place chaque réplica sur une machine esclave sélectionnée au hasard. Toutefois, d’autres facteurs sont pris en considération dans ce processus. Par exemple, pour améliorer la tolérance aux pannes, le HDFS stocke une réplica de chaque bloc de données dans un ensemble de nœuds différent conformément à la fonction d’évaluation des ensembles de nœuds configurée dans une grappe du HDFS (pour en savoir plus sur l’évaluation des ensembles de nœuds dans Hadoop, consultez la documentation sur cette fonction).

De plus, il est possible de configurer les politiques de stockage des données du HDFS. Vous pourriez notamment demander au HDFS de stocker une réplica sur un disque SSD. Si seulement quelques DataNodes répondent à cette exigence, le HDFS doit s’assurer qu’un bloc de données est répliqué sur une machine esclave avec du stockage SSD (pour en savoir plus à ce sujet, consultez la documentation sur les politiques de stockage du HDFS). Le NameNode ne stocke aucun bloc de données. Il assure plutôt la gestion des blocs de données stockés sur les DataNodes. La mise en correspondance des blocs de données avec leur fichier est stockée dans un fichier de métadonnées (FsImage) qui se trouve sur le NameNode. Lorsqu’un client envoie une demande de lecture de fichier au NameNode, ce dernier consulte le fichier FsImage et indique au client les DataNodes qui comprennent les blocs de données pertinents.

En plus d’assurer la tolérance aux pannes, un tel système de stockage distribué offre une haute disponibilité grâce à la réplication des blocs de données. Par défaut, le facteur de réplication dans une distribution Hadoop est de trois, ce qui signifie que chaque bloc de données est répliqué trois fois parmi tous les DataNodes de la grappe. Par conséquent, si une machine esclave (ou même deux) avait une défaillance, la troisième réplica permettrait tout de même d’accéder au bloc de données. Il est possible de modifier le facteur de réplication par défaut, au besoin. Par exemple, vous pourriez l’augmenter si les données sont très sensibles ou si la disponibilité doit être de 100 %. De plus, la capacité de stockage peut être accrue de façon illimitée en ajoutant des DataNodes.

Comme nous l’avons expliqué précédemment, le HDFS est une plateforme de stockage et de traitement de données statiques parfaite pour les analyses. Il ne convient pas au traitement de données transactionnelles. En effet, ce système applique un modèle WORM (écriture unique, lectures répétées) pour accéder aux fichiers. Les données sont alors écrites une seule fois dans le HDFS et ne sont jamais mises à jour (même s’il est possible de le faire). Puisque le HDFS repose sur le concept de stockage distribué, il peut être très long de mettre à jour un fichier (il faut généralement plus de temps qu’avec une base de données relationnelle). L’objectif principal du HDFS est donc de réaliser très rapidement les opérations de lecture lorsque les utilisateurs souhaitent obtenir des données aux fins d’analyse. Il est toutefois important de comprendre comment sont effectuées les opérations de lecture et d’écriture dans le HDFS pour avoir un meilleur aperçu du flux de travaux. La section suivante vous présente le concept.

Remarque : Certaines couches de stockage (comme Delta Lake et Apache Hudi) permettent aux utilisateurs d’effectuer des opérations volumineuses de lecture ou d’écriture dans le HDFS avec une faible latence.

Opérations de lecture et d’écriture dans le HDFS

Avant d’expliquer le fonctionnement des opérations de lecture et d’écriture dans le HDFS, il faut préciser que le pipeline de lecture et d’écriture d’Hadoop est très complexe. Nous vous présenterons ici une version simplifiée du processus réel.

Imaginons que vous souhaitez stocker un fichier texte de 228 Mo (nommé journal.txt) dans le HDFS, dont le facteur de réplication est réglé à trois. Le fichier est divisé en deux blocs, l’un de 128 Mo et l’autre de 100 Mo. Supposons que ces blocs sont appelés « b1 » et « b2 ». Un client interagit avec le NameNode. Ce dernier lui prépare et lui transmet ensuite les métadonnées pertinentes. Le client utilise ces métadonnées pour transférer les blocs de données aux DataNodes. La réponse du NameNode ressemblerait à ce qui suit :

Journal.txt, b1:DataNode_A, copy_b1:DataNode_C et DataNode_D

Journal.txt, b2:DataNode_B, copy_b2:DataNode_C et DataNode_D

La figure 3 présente un flux de lecture simplifié dans le HDFS.

Figure 3 : pipeline d’écriture dans le HDFS

Voici les étapes d’une opération d’écriture :

  1. Le client interagit avec le NameNode pour créer un fichier. La machine maître vérifie que le fichier n’existe pas déjà et que le client a l’autorisation pour effectuer cette opération d’écriture. Une fois ces vérifications effectuées, le NameNode crée un nouveau fichier vide (sans données).
  2. Le NameNode transmet la liste de toutes les adresses IP des DataNodes sur lesquels le client peut écrire ses blocs de données. Il envoie également un jeton de sécurité au client.
  3. Le client utilise ce jeton de sécurité pour se connecter aux DataNodes sélectionnés.
  4. Le client commence à écrire les blocs de données directement sur les DataNodes choisis.

L’écriture de blocs de données s’effectue en parallèle, mais l’écriture des réplicas d’un bloc de données est réalisée de façon séquentielle. Par exemple, le client écrit en parallèle journal-b1 sur le DataNode_A et journal-b2 sur le DataNode_B. Les DataNode_A et DataNode_B sont sélectionnés en premier, car ils sont respectivement les premiers DataNodes dans la liste pour journal-b1 et journal-b2. Ces DataNodes sont appelés « machines esclaves primaires ».

Une fois que l’écriture des premiers blocs de données (soit journal-b1 et journal-b2) est terminée, DataNode_A doit répliquer le journal-b1 sur DataNode_C, et DataNode_B doit répliquer journal-b2 sur DataNode_C. Ensuite, DataNode_C est chargé de reproduire journal-b1 et journal-b2 sur DataNode_D. Lorsque l’écriture et la réplication de chaque bloc de données sont bien terminées, tous les DataNodes sélectionnés envoient un accusé de réception au client (trois accusés de réception sont envoyés pour chaque bloc de données si le facteur de réplication est de trois). De plus, les DataNodes primaires (DataNode_A et DataNode_B) mettent à jour les renseignements relatifs au bloc sur le NameNode. Ce dernier utilise ensuite ces renseignements (qui sont associés à un fichier) lorsqu’un client veut lire le fichier.

  1. Le client signale au NameNode que l’opération d’écriture est terminée.

Voici les étapes d’une opération de lecture (voir la figure 4) :

  1. Le client interroge le NameNode pour connaître les emplacements des blocs de données associés au fichier demandé.
  2. Le NameNode vérifie d’abord si le client dispose des autorisations requises pour lire le fichier. Si c’est le cas, le NameNode envoie la liste des adresses IP des DataNodes possédant une copie de chaque bloc de données. Dans notre scénario, le NameNode envoie les adresses de trois DataNodes pour chaque bloc de données (puisque le facteur de réplication est de trois).
  3. Pour chacun des blocs de données, le système choisit les DataNodes en fonction de leur proximité géographique par rapport au client. Le client interagit alors avec la machine esclave la plus près pour chaque bloc de données et extrait les données en parallèle. Dans la figure 4, on suppose que le DataNode_A est le nœud le plus proche avec le bloc de données b1 et le DataNode_B est celui le plus près avec le bloc de données b2.
  4. Une fois que la lecture de tous les blocs de données est terminée, le client coupe la connexion aux DataNodes.

Figure 4 : pipeline de lecture dans le HDFS

Voilà, c’était une présentation simplifiée du fonctionnement des opérations de lecture et d’écriture dans le système Hadoop.

Conclusion

Pour conclure, ce billet de blogue vous a présenté le système de fichiers distribués Hadoop (HDFS), l’une des sources de données externes de haute performance qu’il est possible d’enregistrer auprès de GeoAnalytics Server d’Esri afin d’exploiter les données massives dans les outils de traitement de GeoAnalytics. Le prochain billet de blogue traitera plus en détail de l’utilisation d’une approche de stockage dans le nuage. Il s’agit d’une autre méthode largement utilisée pour stocker des données massives dans une architecture de stockage externe à laquelle l’environnement de GeoAnalytics Server peut accéder.

Ce billet a été écrit en anglais par Hossein Hosseini et peut être consulté ici.