Les outils en ligne de commande peuvent être 235 fois plus rapides qu’un cluster Hadoop (2014)

• En traitant environ 1,75 Go de données de parties d’échecs avec des outils en ligne de commande plutôt qu’avec Hadoop, le traitement s’est terminé en 12 secondes, soit des performances plus de 235 fois supérieures aux 26 minutes de Hadoop
• En combinant des commandes shell de base comme grep, sort, uniq, awk, xargs, mawk, il est possible de construire un pipeline de traitement en streaming tout en maintenant une utilisation mémoire proche de zéro
• La parallélisation avec xargs et les optimisations avec mawk permettent d’augmenter l’utilisation des cœurs CPU et de minimiser les goulets d’étranglement IO
• Par rapport au traitement du même jeu de données sur un cluster Hadoop (7 instances c1.medium), la charge de coût et de maintenance est nettement plus faible
• Cela montre qu’une analyse de données efficace est possible sur une seule machine et alerte sur l’usage inutile d’outils Big Data

---

Introduction : un traitement en ligne de commande plus rapide que Hadoop

• Après avoir vu un exemple d’analyse d’environ 2 millions de parties d’échecs avec Amazon EMR et mrjob, la même donnée a été reproduite avec un traitement en streaming basé sur la ligne de commande
  • Sur un cluster Hadoop (7 machines c1.medium) : 26 minutes, soit un débit de traitement de 1,14 Mo/s
  • Sur un notebook local : terminé en 12 secondes, soit un débit de traitement de 270 Mo/s
• Cela démontre que pour un simple travail d’agrégation de résultats, un pipeline shell est bien plus efficace que Hadoop
• En combinant des commandes shell, il est possible de reproduire sur une seule machine une architecture de traitement de flux parallèle similaire à Storm

Structure des données et préparation

• Les données sont des enregistrements de parties d’échecs au format PGN (Portable Game Notation), et le résultat de chaque partie est indiqué sur la ligne "Result"
  • "1-0" signifie victoire des blancs, "0-1" victoire des noirs, "1/2-1/2" match nul
• Environ 3,46 Go de données ont été récupérés depuis le dépôt GitHub rozim/ChessData
  • Soit environ deux fois le volume des données de test de Tom Hayden (1,75 Go)

Construction du pipeline de base

• Pour mesurer la limite IO, l’exécution de cat *.pgn > /dev/null prend environ 13 secondes (272 Mo/s)
• Pipeline d’analyse de base :

  cat *.pgn | grep "Result" | sort | uniq -c
  

  • Temps d’exécution d’environ 70 secondes, soit environ 47 fois plus rapide que Hadoop
• En remplaçant sort | uniq par AWK pour agréger directement les résultats
  • Temps d’exécution : 65 secondes, avec une utilisation mémoire quasi nulle
  • grep monopolise un seul cœur CPU et devient le principal goulet d’étranglement

Parallélisation et optimisation

• xargs est utilisé pour paralléliser grep

  find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
  

  • Temps d’exécution : 38 secondes, soit environ 77 fois plus rapide
• En supprimant grep et en passant à un filtrage uniquement avec AWK, le pipeline est simplifié
  • Un double pipeline AWK est construit pour fusionner les résultats de chaque fichier
  • Temps d’exécution : 18 secondes, soit environ 174 fois plus rapide
• Optimisation supplémentaire en remplaçant par mawk

  find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
  

  • Temps d’exécution : 12 secondes, 235 fois plus rapide que Hadoop, avec un débit de 270 Mo/s

Conclusion : l’efficacité de la simplicité

• Sauf lorsqu’un traitement distribué à grande échelle est réellement nécessaire, une combinaison d’outils shell sur une seule machine est plus rapide et plus économique
• Hadoop est souvent utilisé de manière excessive, y compris pour des tâches qui seraient largement couvertes par une base de données relationnelle ou un simple script
• L’analyse en streaming basée sur la ligne de commande constitue une excellente alternative en termes de performances, coût d’implémentation et maintenabilité