S3 : une option de stockage de plus en plus utilisée pour Hadoop

Un support natif de S3 dans Hadoop

Le support de S3 dans Hadoop s’est régulièrement enrichi au cours des dix dernières années. Le premier support natif du protocole de stockage objet dans le framework est apparu en 2008 avec l’inclusion du client natif S3 (ou s3n, pour S3 Native Filesystem). L’intégration de s3n a permis à Hadoop de lire et d’écrire nativement des données dans un magasin S3 existant et donc de manipuler directement des données stockées dans un ou plusieurs « buckets », sans avoir nécessairement à les importer préalablement dans HDFS. Cette première implémentation souffrait toutefois de problèmes de performances et ne supportait pas certaines fonctions essentielles du protocole S3.

En 2014, la version 2.7 d’Hadoop a donc officiellement remplacé le client s3n par un client de nouvelle génération baptisé s3a. Ce nouveau client a apporté de multiples améliorations, dont celle portant sur des mécanismes de gestion des identités et des accès de S3. Il a également singulièrement amélioré les performances (notamment avec des outils comme Hive ou Spark).

L’arrivée de s3a n’a toutefois pas éliminé tous les problèmes que pose l’utilisation du protocole S3 avec Hadoop. En particulier, l’un des problèmes majeurs à traiter est le fait que contrairement à la plupart des stockages objet locaux, le service AWS S3 n’est qu’éventuellement cohérent. On entend par là qu’après une opération d’écriture, de mise à jour ou d’effacement, il est parfois nécessaire qu’un certain délai s’écoule avant que les modifications soient répercutées dans le système. Ainsi, en listant le contenu d’un répertoire, il est possible que S3 retourne un état qui ne soit pas cohérent avec les dernières opérations effectuées. Cela peut s’avérer catastrophique si l’on effectue une requête MapReduce, Hive ou Spark.

S3Guard : un mécanisme pour garantir la cohérence des données avec AWS S3

Les développeurs ont donc travaillé au développement de S3Guard dont l’objectif est de se protéger contre les éventuelles incohérences d’AWS S3 en maintenant un journal des opérations d’écritures effectuées sur le service. Ce journal est conservé sous forme de métadonnées dans une base DynamoDB et permet lors d’une lecture de s’assurer de la cohérence des informations retournées.

Principe de fonctionnement de S3Guard

Les métadonnées stockées dans DynamoDB pouvant être utilisées comme un cache, la mise en œuvre de S3Guard contribue également à accélérer certaines opérations de lecture et à doper les performances des requêtes exécutées directement sur un magasin de stockage S3. Il est à noter qu’à ce jour S3Guard reste une fonction expérimentale du client s3a.