Les outils en ligne de commande peuvent être 235 fois plus rapides qu’un cluster Hadoop (2014)
(adamdrake.com)- 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/nullprend 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 | uniqpar AWK pour agréger directement les résultats- Temps d’exécution : 65 secondes, avec une utilisation mémoire quasi nulle
grepmonopolise un seul cœur CPU et devient le principal goulet d’étranglement
Parallélisation et optimisation
- xargs est utilisé pour paralléliser
grepfind . -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
grepet 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é
2 commentaires
Autrefois, on parlait de programmation Taco Bell, on dirait que c’est une philosophie similaire.
Commentaires Hacker News
Le plus triste, c’est que cet article date de 2014
Aujourd’hui, il y a encore plus de couches d’abstraction comme Airflow, dbt, Snowflake, qu’on empile même sur des jeux de données qui tiennent entièrement en RAM
Des startups brûlent 5 000 dollars par mois sur des clusters distribués pour traiter moins de 10 Go de logs par jour. Pourquoi ? Parce qu’utiliser la « Modern Data Stack » aide à décrocher une promotion, alors que résoudre le problème avec un script bash est écarté comme « non scalable ». L’efficacité et les incitations sont complètement désalignées
Il y avait même un cas avec 1 Go de JSON ingéré par jour, et quand j’ai expliqué qu’une seule machine suffisait, on m’a répondu : « c’est techniquement correct, mais ce n’est pas la réponse qu’on attend », puis on m’a recalé
Les machines actuelles ont des To de RAM et des centaines de cœurs. Une seule machine est déjà énorme
Quand on embauche des profils DevOps en mettant en avant l’expérience sur des frameworks tape-à-l’œil, ils reproduisent ensuite exactement la même chose dans l’entreprise
Comme personne ne s’y oppose, on finit par complexifier des tâches qu’un simple desktop pourrait gérer
Je cherche du travail depuis plus d’un an avec un CV où il y a très peu de frameworks à la mode, et j’en viens à me sentir idiot
En 2014, 4 Go étaient la norme, mais maintenant les vitesses de streaming depuis SSD ont tellement progressé qu’il vaut parfois mieux lire depuis un SSD local que depuis un cluster
C’est l’auteur !
Je suis heureux de voir que ce vieil article reste utile
Je suis d’accord avec l’idée que la situation a empiré, mais heureusement on voit aussi un mouvement pour sortir du culte des microservices
Courage à tous ceux qui travaillent à améliorer les performances. Il reste de l’espoir
J’ai relu l’article plusieurs fois, et il m’a inspiré pour porter Waters-Series en JavaScript afin d’implémenter du stream pipelining
Aujourd’hui, dans l’industrie, l’idée que Spark ou les outils distribués sont la bonne réponse en data engineering est beaucoup trop ancrée
C’est comparable à l’usage excessif des frameworks SPA dans le développement web
Mon conseil est le suivant :
Ce que les managers veulent entendre, ce n’est pas « tout est infiniment scalable », mais « ça tourne de façon fiable »
La taille des données suit une loi de puissance, donc les ingénieurs qui travaillent sur des pétaoctets sont extrêmement rares
Mais comme il faut afficher ce type d’expérience sur le CV pour augmenter son salaire, on se retrouve avec de l’over-engineering
Quand j’ai demandé pourquoi, la réponse a été : « il faut juste l’utiliser ». C’était probablement pour le CV ou pour des raisons politiques internes
Une remarque historique liée à l’article
Un outil appelé mrjob pouvait aussi tourner en mode local, sans Hadoop
Sur de petits jeux de données, c’était bien plus rapide qu’un cluster. En particulier, ça finissait plus vite que des clusters temporaires comme AWS EMR
Mais l’approche de l’auteur devait être encore plus efficace
MapReduce facilitait le passage à très grande échelle, mais imposait aussi beaucoup de contraintes inefficaces sur de petites données
Au début des années 2010, on traitait des données à l’échelle du pétaoctet avec mrjob, mais aujourd’hui il n’est presque plus utilisé
Quand je travaillais comme data engineer, j’ai réécrit des scripts Bash/Python en C# et poussé le traitement JSON jusqu’à 1 Go/s
De simples optimisations comme le parsing en streaming faisaient déjà une énorme différence
Du coup, je me demande — à partir de quel volume de données est-ce qu’un cluster commence vraiment à avoir du sens ?
Pour moi, si un traitement prend plus d’une journée, ça peut valoir le coup d’envisager du distribué
Quand les données étaient trop grosses, il les échantillonnait pour les analyser dans Excel. Aujourd’hui, avec les LLM, même de petits scripts Python/Bash sont faciles à écrire
On peut lire et écrire directement depuis un object storage comme S3, et aujourd’hui on peut atteindre 100 Go/s
Ça tient sur disque, mais c’est trop gros pour un portable classique
La « taille » des données dépend de ce qu’on veut en faire
Par exemple, pour de simples statistiques sur des données chirurgicales, bash suffit, mais si on veut calculer la corrélation entre l’expérience des médecins et le taux de réussite, la complexité augmente brutalement
Du point de vue d’une entreprise, dire « on utilise Spark » est donc bien plus simple que dire « on construit un moteur adapté à chaque question »
Tous les problèmes évoqués peuvent être résolus sur un seul serveur avec des outils simples
Cet article a déjà été posté plusieurs fois sur HN
La version 2018, la version 2022 et la version 2024 ont toutes été soumises par la même personne
Ça me rappelle le texte de présentation de l’ancien site Shakti
« 1K lignes : Excel / 1M lignes : Pandas / 1B lignes : Shakti / 1T lignes : Only Shakti »
Source
Beaucoup de développeurs ont été formés dans un environnement Windows et ne sont pas à l’aise avec les outils CLI
Pourtant, la CLI offre des fonctions puissantes : boucles implicites, découpage automatique des champs, application parallèle de regex, etc.
Ça permet de créer rapidement des solutions ad hoc, et c’est un excellent point de départ avant de passer à des systèmes plus lourds
Je me demande ce que donnerait un nouveau benchmark en agrandissant encore les données d’échecs
Aujourd’hui, le jeu de données Lichess représente environ 7B parties, 2,34 To compressés (14 To non compressés)
Je me demande si, à cette échelle, Hadoop finirait par gagner
Mais cela implique en contrepartie de gérer un serveur dédié
EMR est un modèle conçu pour du traitement parallèle lorsque l’accès aux données est peu fréquent (1 à 10 fois par jour)