Comment stocker ses données dans Hadoop ?

| 8 minutes read

Ce billet a pour objectif de traiter les questions suivantes :

  • Quels sont les différents modes de stockage des données dans Hadoop ?
  • Quels sont les particularités des formats de fichiers « spécifiques » Hadoop ?
  • Quels sont les méthodes de compression disponible ?

A la fin de cet article, vous serez capable de choisir le format de fichier et/ou la méthode de compression à appliquer à vos données, en fonction de vos besoins et de votre environnement.

Le stockage dans Hadoop

Hadoop est un framework open-source permettant de stocker et traiter de grands ensembles de données de façon distribuée et échelonnable (scalable) sur du matériel standard.

HDFS (Hadoop Distributed File System) est le système de fichiers distribué donnant un accès haute performance aux données réparties dans un cluster Hadoop.

Le système est tolérant aux pannes (les données sont répliquées par défaut 3 fois au sein du cluster).

HDFS profite de la scalabilité du cluster. Ce qui signifie que théoriquement, l’espace de stockage peut s’agrandir en fonction des besoins en ajoutant simplement des machines à faible coût, dites de « commodités », dans le cluster.

La donnée est découpée en bloc de 128MB (taille par défaut d’un bloc HDFS) et elle est répartie sur plusieurs nœuds (machines) du cluster. L’un des principes fondamentaux d’Hadoop est de traiter la donnée là où elle est stockée.

Dans Hadoop, on peut stocker des fichiers « standard » comme des fichiers textes, CSV, XML, JSON, … ou des fichiers binaires comme des images.

Plusieurs formats de fichier (containers) ont été spécifiquement créés pour Hadoop et fonctionnent très bien avec MapReduce. Ces formats, que nous détaillerons plus bas dans cet article, peuvent être regroupés en 3 groupes :

  • Les formats de données structurées comme SequenceFile
  • Les formats sérialisés comme Avro
  • Les formats « colonne » comme Parquet

Ces formats ont chacun leur force et leur faiblesse mais ils partagent tous la même caractéristique très importante dans les applications Hadoop, à savoir, la compression par bloc.

Hadoop stocke et traite les données par blocs donc pour profiter pleinement de ses capacités de traitement distribués, le choix d’un format de fichier et/ou de compression « splittable » est souvent indispensable.

  • Si un fichier ne peut être divisé en bloc, l’intégralité du fichier sera passée à une tache MapReduce, aucun traitement distribué n’aura lieu.
  • En revanche, prenons l’exemple d’un fichier CSV. Il peut être divisé en bloc (« splittable ») car on peut commencer à lire un fichier CSV à partir de n’importe quelle ligne du fichier. Dans ce cas, le traitement du fichier pourra être effectué de manière parallèle sur les nœuds du cluster, où sera stockée la donnée.

Les formats « standard » ou spécifiques « Hadoop » peuvent être compressés, ce qui permet de :

  • Diminuer l’espace de stockage des données sur disque
  • Augmenter les performances de lecture et d’écriture sur disque (I/O)
  • Améliorer la vitesse de transfert des fichiers sur le réseau

Cependant, pendant les phases de compression et de décompression, le processeur (CPU) est plus utilisé et le temps des traitements est moins rapide.

Afin de savoir quel container et/ou méthode de compression s’appliquent à vos données, commençons par lister les formats spécifiques « Hadoop » qui supportent tous la compression par bloc dite « splittable ».

Format de données structurées

Le format SequenceFile est l’un des formats les plus utilisés dans Hadoop. Les données sont stockées sous forme de paires “clef-valeur” qu’on appelle “enregistrement”.

Trois modes de compression sont disponibles pour stocker les enregistrements :

  • Décompressé : Les enregistrements sont stockés tel quel sans leur appliquer d’algorithme de compression. Cette méthode est la moins efficace en termes de performance d’entrées/sorties (I/O) et est la plus volumineuse en termes de stockage disque.
  • Enregistrement-compressé (Record-compressed). Chaque enregistrement est compressé dès lors qu’il est ajouté au fichier.
  • Bloc-compressé (Block-compressed). Les enregistrements sont stockés dans des blocs. Dès que la taille du bloc est atteinte, le bloc est compressé. Un ou plusieurs blocs sont compressés dans un même bloc HDFS. Ce mode de compression est le plus utilisé car il possède le meilleur ratio de compression.

Un SequenceFile est composé d’un header (en-tête) contenant les informations des métadonnées basiques du fichier comme le codec de compression utilisé, les class names clef/valeur, les métadonnées de l’utilisateur et un marker « sync » généré aléatoirement. Ce marker est également écrit dans le corps du fichier et permet l’accès aléatoire à des points du fichier et est un élément clef facilitant la splitabilité.

Les SequenceFiles sont très bien supportés par l’écosystème Hadoop, cependant très peu en dehors, et uniquement par Java.

Cas d’utilisation le plus commun : container pour fichier de petite taille (Taille plus petite que la taille d’un bloc HDFS)

  • Stocker des fichiers de petite taille dans Hadoop entraîne une utilisation excessive de la mémoire pour le NameNode car les métadonnées de chaque fichier enregistré dans HDFS sont stockées en mémoire.
  • Le traitement de ces fichiers va générer beaucoup de taches de traitements. Hadoop est conçu pour traiter des gros fichiers donc l’une des solutions possible est de packager tous ces petits fichiers dans un SequenceFile.

Format Sérialisé

La sérialisation est un processus de conversion d’un fichier dans un flux d’octets. Les 3 frameworks ci dessous, décrivent les données dans un schéma permettant une interopérabilité entre les langages.

  • Thrift (développé par Facebook) et Protocol Buffers (développé par Google) ne supportent pas la compression des records et sont non « splittables ». Les formats de stockage Thrift & Protocol Buffers ne sont pas supportés nativement par Map Reduce mais la librairie Elephant Bird adresse certaines de ces faiblesses.
  • Avro est devenu un format d’échange de référence dans l’écosystème Hadoop. Il permet d’adresser les manques de Hadoop Writables, à savoir le manque de portabilité entre les langages. De plus, les fichiers Avro sont « splittables » et compressibles. Avro stocke le schéma (en JSON) dans le header de chaque fichier et il supporte l’évolution du schéma. Entre 2 schémas, on peut ajouter, renommer (avec un alias) ou supprimer un champ.

Format Colonne

Les avantages d’un stockage en colonne sont les suivants :

  • Eviter les I/O et potentiellement la décompression des colonnes ne faisant pas partie de la requête.
  • Bonne performance des requêtes qui n’accèdent qu’à certaines colonnes.
  • Très efficace dans la compression d’une colonne car en général les données se ressemblent.
  • Ajout facile d’une nouvelle colonne, les lignes n’ayant pas besoin d’être redimensionnées.

Les formats “colonne” décrits ci-dessous, sont supportés par Hadoop :

  • RCFile :  Record Columnar File est le premier format « colonne » adopté par Hadoop et utilisé initialement dans Hive. Il a pour objectif un chargement rapide des données, une exécution rapide des requêtes et une utilisation très efficace de l’espace de stockage. Le format RCFile est un format tabulaire constitué de lignes et de colonnes. Les tables sont stockées dans HDFS : des groupes de lignes sont stockés dans des blocs HDFS. RCFile applique une compression par colonne sur ces groupes de lignes donc RCFile hérite de beaucoup d’avantages du stockage « colonne », excepté de l’évolution du modèle de données.
  • ORC (conçu après PARQUET) : Optimized RC Files. ORC a été inventé pour optimiser les performances de Hive et bénéficie des mêmes avantages et limitations de RCFile. La différence se fait sur la qualité de la compression ce qui permet des requêtes plus rapides.
  • Parquet a les mêmes caractéristiques que ORC (stratégie de groupes de lignes avec un stockage et compression par colonne) mais compatible avec toutes les interfaces MapReduce comme Java, Hive, Pig et d’autres moteurs d’exécution comme Impala ou Spark. Parquet supporte des structures de données complexes ainsi que la lecture et l’écriture par les APIs d’Avro et Thrift, sans oublier les évolutions de schéma. 

Format de Compression

Les codecs de compression ont chacun leurs caractéristiques.

Certains privilégient la vitesse de compression/décompression au détriment du ratio de compression (taille du fichier compressé) alors que d’autres privilégient l’inverse.

A cela, se rajoute la capacité du codec à diviser (“split”) les fichiers compressés.

Ci-dessous, vous trouverez un tableau récapitulatif de quelques codecs utilisés dans le monde Hadoop : SnappyLZOGzipbzip2

format_compression

Conclusion

Comme on vient de le voir, chaque format de fichier et de compression répond à des besoins particuliers.

Vos choix seront donc guidés par vos cas d’utilisation et votre environnement :

  • La distribution Hadoop que vous choisirez
  • Les traitements que vous effectuerez
  • Les frameworks que vous utiliserez
  • Les exigences de stockage (taille de stockage, archivage des données, compression, …)
  • L’évolution du modèle de données
  • L’extraction des données d’Hadoop vers un système extérieur
  • ….

Alexia Audevart Author: Alexia Audevart

Data & Enthusiasm @ekito;
Co-Organizer of Toulouse Data Science TDS meet-up;
My hashtags: #BigData #DataScience #Spark #DataVizualisation #MachineLearning

Like it?  Share  it!

Share Button
What do  You  think? Write a comment!

Leave a Reply

Required fields are marked *.


CommentLuv badge

This site uses Akismet to reduce spam. Learn how your comment data is processed.