JindoFS est un système de fichiers compatible Hadoop (HCFS) bâti sur Object Storage Service d'Alibaba Cloud. Il intègre OSS aux écosystèmes big data open source. Il propose trois modes de stockage : le mode client uniquement (SDK), le mode cache et le mode de stockage par blocs. Chacun est optimisé pour répondre à des exigences spécifiques en matière de performances, de coûts et d'exploitation.
Pour la plupart des charges de travail liées aux lacs de données et à l'entraînement de l'IA, utilisez le mode client uniquement (SDK) ou le mode cache. Privilégiez le mode de stockage par blocs si votre charge de travail exige une sémantique POSIX complète, des opérations de renommage atomiques ou une gestion des métadonnées indépendante d'OSS.
Contexte : différences entre le stockage objet et les systèmes de fichiers
OSS stocke les données sous forme d'objets plutôt que dans un système de fichiers hiérarchique. Cette approche rend le stockage objet hautement évolutif et rentable, mais elle crée des lacunes pour les charges de travail dépendant des sémantiques de fichiers POSIX, telles que le renommage atomique, les recherches rapides ou les opérations d'ajout. JindoFS comble cette lacune en superposant des sémantiques de système de fichiers à OSS. Chacun des trois modes présente un compromis différent entre simplicité, performances et charge opérationnelle.
Mode client uniquement (SDK)
Le mode client uniquement fournit une interface compatible Hadoop pour OSS sans service distribué. Il fonctionne comme OSS FileSystem ou S3A FileSystem au sein de la communauté Hadoop et optimise l'accès aux données OSS par les moteurs de calcul tels qu'Apache Hive et Apache Spark.
Les fichiers restent stockés sous forme d'objets dans OSS. JindoFS ajoute uniquement une connexion côté client, des extensions et un accès optimisé pour l'écosystème Hadoop. Pour configurer ce mode, placez le package JAR du SDK JindoFS dans le répertoire classpath.
Ce mode offre la charge opérationnelle la plus faible et la meilleure évolutivité. Il convient parfaitement à l'analytique par lots et aux charges de travail où la simplicité et la mise à l'échelle élastique priment sur la mise en cache.
Mode cache
Le mode cache étend le mode client uniquement (SDK) grâce à une couche de mise en cache distribuée Jindo. Il prend en charge la mise en cache des métadonnées et des données, tout en maintenant une compatibilité et une synchronisation complètes avec OSS. Les données fréquemment utilisées (environ 20 % du total) sont mises en cache localement en mémoire, sur des SSD ou sur des disques standard, selon la configuration de votre cluster.
Le mode cache prend en charge deux modèles d'accès :
oss://<oss_bucket>/<oss_dir>/— Accédez directement à OSS avec la mise en cache activée en option. L'accès inter-services est pris en charge. Il s'agit de la méthode par défaut.jfs://<your_namespace>/<path_of_file>— Accédez aux données via un namespace JindoFS avec la mise en cache activée. L'accès inter-services n'est pas pris en charge.
Ce mode convient bien à l'analytique de données à grande échelle et à l'accélération de l'entraînement de l'IA, lorsque le débit est crucial et que les modèles d'accès aux données fréquemment utilisées sont prévisibles.
Pour plus d'informations, consultez la documentation relative à JindoFS en mode cache.
Mode de stockage par blocs
Le mode de stockage par blocs stocke les fichiers sous forme de blocs dans OSS plutôt que sous forme d'objets. JindoFS gère les répertoires et les métadonnées des fichiers de manière indépendante via son Namespace Service et son Storage Service, ce qui lui confère un comportement proche d'Apache Hadoop HDFS. Les données sont mises en cache localement ; les données tièdes et fréquemment utilisées représentent ensemble environ 60 % du total des données.
Le mode de stockage par blocs prend en charge des interfaces de stockage de haut niveau, notamment les opérations de renommage atomique, de troncature, d'ajout, de vidage, de synchronisation et de snapshot. Ces interfaces permettent à Apache Flink, Apache HBase, Apache Kafka et Apache Kudu d'écrire directement dans OSS comme ils le feraient dans un système de fichiers natif. La compression transparente est également prise en charge pour les données froides afin de réduire les coûts de stockage.
Format d'accès : jfs://<your_namespace>/<path_of_file> (l'accès inter-services n'est pas pris en charge).
Ce mode convient parfaitement aux charges de travail qui nécessitent une sémantique POSIX complète, des performances élevées pour les requêtes de métadonnées ou une intégration directe avec les moteurs de traitement de flux.
Pour plus d'informations, consultez la documentation relative à JindoFS en mode de stockage par blocs.
Choisir un mode
La différence fondamentale entre les modes réside dans la manière dont les fichiers sont stockés dans OSS et dont les métadonnées sont gérées :
Le mode client uniquement et le mode cache stockent les fichiers sous forme d'objets dans OSS. La gestion des métadonnées simule le comportement de HDFS.
Le mode de stockage par blocs stocke les fichiers sous forme de blocs dans OSS et gère les métadonnées de manière indépendante, ce qui lui confère des sémantiques plus proches de HDFS.
Le tableau suivant compare les trois modes selon plusieurs dimensions clés.
| Dimension | Mode client uniquement (SDK) | Mode cache | Mode de stockage par blocs |
|---|---|---|---|
| Idéal pour | Analytique par lots, stockage de lac de données, charges de travail nécessitant une évolutivité maximale et une exploitation minimale | Analytique à grande échelle, accélération de l'entraînement de l'IA, charges de travail sensibles au débit avec des modèles de données fréquemment utilisées prévisibles | Charges de travail nécessitant une sémantique POSIX complète, traitement de flux (Flink, HBase, Kafka, Kudu) ou gestion des métadonnées indépendante d'OSS |
| Coût de stockage | Données complètes dans OSS. Prend en charge la classe de stockage Archive. | Données complètes dans OSS. Données fréquemment utilisées mises en cache (~20 % du total). Prend en charge la classe de stockage Archive. | Données complètes dans OSS. Données tièdes et fréquemment utilisées mises en cache (~60 % du total). Prend en charge la classe de stockage Archive. Prend en charge la compression transparente. |
| Évolutivité | Élevée | Relativement élevée | Moyenne |
| Débit | Dépend de la bande passante OSS. Idéal pour les lectures séquentielles par lots. | Dépend de la bande passante OSS plus la bande passante du cache de données fréquemment utilisées. Idéal pour l'accès répété aux jeux de données fréquemment utilisés. | Dépend de la bande passante OSS plus la bande passante du cache de données tièdes et fréquemment utilisées. Idéal pour les E/S séquentielles et aléatoires mixtes avec des taux de succès élevés du cache local. |
| Métadonnées | Simule la gestion des métadonnées HDFS ; pas de stockage basé sur les répertoires ni de sémantiques de fichiers ; prend en charge les données à l'échelle de l'exaoctet | Simule la gestion des métadonnées HDFS avec mise en cache des données de fichiers ; prend en charge les données à l'échelle de l'exaoctet | Performances de métadonnées les plus élevées ; proche de la compatibilité HDFS ; prend en charge plus d'un milliard de fichiers |
| Maintenance | Faible | Moyenne — nécessite l'exploitation et la maintenance du système de cache | Relativement élevée — nécessite l'exploitation et la maintenance du Namespace Service et du Storage Service |
| Sécurité | Authentification par paire AccessKey, authentification RAM, journaux d'accès OSS, chiffrement des données OSS | Authentification par paire AccessKey, authentification RAM, journaux d'accès OSS, chiffrement des données OSS | Authentification par paire AccessKey, commandes UNIX ou Apache Ranger pour la gestion des autorisations, AuditLog, chiffrement des données |
| Format d'accès | oss://<oss_bucket>/<oss_dir>/ — accès inter-services pris en charge |
oss://<oss_bucket>/<oss_dir>/ (accès inter-services pris en charge) ou jfs://<your_namespace>/<path_of_file> (accès inter-services non pris en charge) |
jfs://<your_namespace>/<path_of_file> — accès inter-services non pris en charge |
FAQ
Quel mode dois-je utiliser pour un lac de données typique ?
Le mode client uniquement (SDK) ou le mode cache. Les deux sont entièrement compatibles avec les sémantiques de stockage objet d'OSS, prennent en charge la séparation complète entre le calcul et le stockage, et offrent une mise à l'échelle flexible. Le mode cache ajoute une mise en cache locale pour les données fréquemment utilisées, ce qui améliore le débit pour l'analytique intensive en accès et l'entraînement de l'IA.
Pourquoi le mode de stockage par blocs prend-il en charge plus de fichiers que HDFS ?
Le mode de stockage par blocs peut gérer plus d'un milliard de fichiers, contre un maximum d'environ 400 millions pour HDFS. Il ne présente aucune limite de mémoire on-heap (HDFS est contraint par la taille du heap JVM), ce qui signifie que les performances restent plus stables sous forte charge. Le mode de stockage par blocs nécessite également une exploitation et une maintenance légères : les disques endommagés ou les pannes de nœuds n'entraînent pas de perte de données, car toutes les données disposent d'une sauvegarde dans OSS, et les nœuds peuvent être ajoutés ou supprimés librement.
Quels sont les avantages uniques du mode de stockage par blocs ?
Le mode de stockage par blocs gère à la fois les métadonnées de fichiers et les données de fichiers indépendamment d'OSS, ce qui lui permet de prendre en charge des interfaces de stockage de haut niveau que le stockage objet ne peut pas fournir nativement : transactions de renommage atomique, écritures locales haute performance, troncature, ajout, vidage, synchronisation et snapshot. Ces interfaces sont nécessaires pour connecter directement les moteurs big data tels qu'Apache Flink, Apache HBase, Apache Kafka et Apache Kudu à OSS.
Le mode de stockage par blocs présente également un avantage en termes de coûts : la mise en cache de 60 % des données localement (données tièdes et fréquemment utilisées) signifie qu'une grande partie des lectures est servie depuis le cluster local plutôt que depuis OSS, réduisant ainsi les coûts de sortie et améliorant la latence pour les données fréquemment consultées.