Comprendre le stockage distribué en Big Data : HDFS (Hadoop) et Cassandra

À l’ère du Big Data, les systèmes traditionnels de stockage ne suffisent plus. Les volumes de données explosent (logs, IoT, transactions, réseaux sociaux, imagerie médicale, etc.), et les entreprises doivent stocker, traiter et analyser des pétaoctets de données de manière fiable et scalable. Le stockage distribué est au cœur de cette révolution.

Dans cet article, nous allons :

1. Comprendre le principe du stockage distribué

2. Explorer l’architecture de Hadoop HDFS

3. Explorer l’architecture de Cassandra

4. Comparer leurs forces et limites

   
   

1. Qu’est-ce que le stockage distribué ?

Le stockage distribué consiste à répartir les données sur plusieurs machines (nœuds) au lieu de les centraliser sur un seul serveur.

Objectifs principaux

1. Scalabilité horizontale (ajouter des machines plutôt qu’augmenter la puissance d’une seule)

2. Tolérance aux pannes

3. Haute disponibilité

4. Optimisation des coûts (machines standards au lieu de serveurs très coûteux)

Principe fondamental

Les données sont :

• Découpées en blocs ou partitions

• Répliquées sur plusieurs nœuds

• Localisées via des mécanismes de métadonnées

• Accédées via des protocoles distribués

Deux approches dominantes :

• Approche master-slave (ex : Hadoop HDFS)

• Approche peer-to-peer sans maître unique (ex : Cassandra)

  
  

2. Architecture de Hadoop HDFS

HDFS (Hadoop Distributed File System) est le système de fichiers distribué du framework Hadoop. Il est conçu pour stocker de très grands fichiers (TB, PB) et optimiser le traitement batch via MapReduce.

Architecture HDFS

HDFS repose sur un modèle Master-Slave.

NameNode (Master)

• Gère les métadonnées

• Conserve :

  • Arborescence des fichiers

  • Emplacement des blocs

  • Permissions

• Ne stocke pas les données elles-mêmes

⚠ Point critique : si le NameNode tombe, le cluster est impacté (bien que le HA existe aujourd’hui).

DataNodes (Workers)

• Stockent physiquement les blocs de données

• Envoient des heartbeats au NameNode

• Répliquent les blocs (généralement facteur 3)

Blocs HDFS

• Fichiers découpés en blocs (128MB ou 256MB)

• Chaque bloc est répliqué sur plusieurs machines

• Optimisé pour gros fichiers séquentiels

Fonctionnement simplifié

1. Le client demande au NameNode où écrire/lire

2. Le NameNode renvoie la liste des DataNodes concernés

3. Le client communique directement avec les DataNodes

Points forts de HDFS

✔ 1. Scalabilité massive : Peut gérer des pétaoctets de données.

✔ 2. Tolérance aux pannes : Grâce à la réplication des blocs.

✔ 3. Optimisé pour traitement batch : Idéal pour :

• ETL

• Machine Learning offline

• Analyse historique

✔ 4. Coût réduit : Fonctionne sur matériel commodity.

Points faibles de HDFS

✖ 1. Mauvais pour petites données : Trop de petits fichiers surcharge le NameNode.

✖ 2. Latence élevée : Pas adapté aux applications temps réel.

✖ 3. Write Once Read Many : Pas conçu pour des mises à jour fréquentes.

✖ 4. Dépendance au NameNode : Même avec HA, il reste un point sensible.

3. Architecture de Cassandra

Apache Cassandra est une base NoSQL distribuée conçue pour la haute disponibilité, la scalabilité horizontale et le temps réel.

Contrairement à HDFS, Cassandra n’a pas de master unique.

Architecture Cassandra

Cassandra adopte une architecture peer-to-peer (sans maître).

Tous les nœuds sont équivalents.

Cluster

Un ensemble de nœuds interconnectés.

Anneau (Ring Architecture)

Les données sont distribuées via :

• Partitionnement par hash (consistent hashing)

• Chaque nœud possède une plage de tokens

Cela permet :

• Une répartition équilibrée

• Une montée en charge facile

Réplication

Stratégies configurables :

• SimpleStrategy

• NetworkTopologyStrategy

Facteur de réplication paramétrable (RF = 3 par exemple).

Mécanisme d’écriture (Write Path)

1. Écriture dans le Commit Log

2. Écriture en mémoire (Memtable)

3. Flush vers disque en SSTables

4. Compaction périodique

Optimisé pour les écritures rapides.

Cohérence configurable

Cassandra applique le modèle CAP :

• Haute disponibilité

• Partition tolerance

• Cohérence configurable

Exemple :

• ONE

• QUORUM

• ALL

Points forts de Cassandra

✔ 1. Haute disponibilité native : Pas de point unique de défaillance.

✔ 2. Scalabilité linéaire : Ajouter un nœud augmente proportionnellement la capacité.

✔ 3. Excellentes performances en écriture : Idéal pour :

• Logs

• IoT

• Transactions à fort débit

• Applications temps réel

✔ 4. Tolérance aux partitions réseau : Très résilient dans des environnements distribués géographiquement.

Points faibles de Cassandra

✖ 1. Modélisation complexe : On modélise selon les requêtes, pas selon la logique métier.

✖ 2. Jointures inexistantes : Pas de JOIN comme en SQL classique.

✖ 3. Cohérence éventuelle par défaut : Peut compliquer certaines applications critiques.

✖ 4. Maintenance (compaction, tuning) : Peut devenir complexe à grande échelle.

Quand choisir quoi ?

Choisir HDFS si :

• Vous construisez un Data Lake

• Vous faites du traitement batch massif

• Vous utilisez Spark, Hive, MapReduce

Choisir Cassandra si :

• Vous avez des millions d’écritures par seconde

• Vous développez une application temps réel

• Vous avez besoin de haute disponibilité multi-région

  
  

Le stockage distribué est une brique fondamentale du Big Data.

• HDFS est puissant pour le stockage massif orienté batch.

• Cassandra est robuste pour les applications distribuées temps réel.

Un architecte Big Data ne choisit pas une technologie par mode, mais selon :

• le volume

• la vélocité

• la criticité

• le modèle d’accès aux données