Hadoop performances
YOUR HUMBLE PRESENTER
Sofian DJAMAA
• Ex-consultant OCTO
#expert-performance
#expert-NoSQL
#expert-babyfoot
• Co-fondateur...
QU’EST-CE QU’HADOOP?
• Stockage: HDFS
– Haute disponibilité
– Large volumétrie
• Traitement: MapReduce
– Divide & conquer
...
ADAPTER LA CONFIGURATION DU CLUSTER
Le plus simple est dans un premier temps de configurer correctement son cluster Hadoop...
MAP REDUCE
5
MAP REDUCE
6
MAP REDUCE
7
PHASE MAP
• Les fichiers d’entrée sont contenus dans des « input
splits »
• Chaque fichier est assigné à un mapper
• Le ma...
PHASE MAP: OPTIMISER LA LECTURE DES FICHIERS
TAILLE DES BLOCKS
• Les fichiers d’entrée sont stockés sur HDFS dans des bloc...
PHASE MAP: OPTIMISER LA LECTURE DES FICHIERS
COMPRESSION
Rappel:
• taille de l’input d’un mapper = taille du fichier / fac...
PHASE MAP: OPTIMISER LA LECTURE DES FICHIERS
FORMATS DE FICHIER
• Les fichiers d’entrée sont stockés selon un format :
– T...
PHASE MAP: OPTIMISER LA COLLECTE DES
DONNÉES TRAITÉES
• Lorsque les données ont été traitées par la fonction map,
elles so...
SPILLING EN DÉTAIL
• En réalité le Spilling est un
Partition/Sort/Merge sur disque 
13
PHASE MAP: OPTIMISER L’ENVOI DES
DONNÉES AUX REDUCERS
• Compression
– mapred.compress.map.output : spécifier si les fichie...
PHASE REDUCE
• Les fichiers d’entrées sont partitionnés pour les reducers
– Une clef est assignée à chaque reducer (pour t...
PHASE REDUCE : OPTIMISER LA LECTURE DES
FICHIERS D’ENTRÉE
• Les fichiers d’entrée sont récupérés depuis les emplacements
l...
PHASE REDUCE : OPTIMISER LE MERGE DES
FICHIERS D’ENTRÉE
• Les fichiers d’entrée sont récupérés et lus par le reducer
• Cha...
PHASE REDUCE : OPTIMISER L’ECRITURE DES
FICHIERS FINAUX
• Partition key (distribute by xxx in Hive)
– pour les reducers
• ...
TUNING JVM
• Réutiliser la JVM
– Temps d’initialisation de la JVM à prendre en compte
• Heap
• JIT
• …
• Heap management
–...
OPTIMISATIONS HIVE/CASCADING
• Mapjoins/Hashjoins :
– S’assurer que l’ensemble utilisé pour la jointure tient effectivemen...
RAPPEL
21
mapred.min.split.size
mapred.max.split.size
dfs.block.size (cluster wide)
hive.merge.mapredfiles
hive.merge.smal...
CLUSTER MANAGEMENT
MRV1
• Utiliser des pools de jobs
22
CLUSTER MANAGEMENT
YARN
• La partie stockage ne bouge pas mais le
JobTracker disparaît au profit d’une nouvelle
architectu...
CLUSTER MANAGEMENT
APACHE MESOS
• « Resource offer » : CPU, RAM…
• Le master Mesos propose une quantité de
ressources à un...
LE PLUS IMPORTANT : LE
MONITORING/PROFILING
• JobTracker
– Possibilité de définir ses propres compteurs pour
debug
• Gangl...
PETITS CONSEILS
• Si vos data tiennent en RAM… EVITEZ HADOOP !!!!
• Si vos data peuvent tenir en RAM sur peu de machines… ...
QUESTIONS ?
We can talk about…
#hadoop
27
#scalding
#scala#sharks
#summingbird
#performance
#mechanical-sympathy
#hive #ca...
Prochain SlideShare
Chargement dans…5
×

PerfUG - Hadoop Performances

1 017 vues

Publié le

Presentation given on Performance User Group Paris: Hadoop performances tips & tricks

Publié dans : Logiciels
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 017
Sur SlideShare
0
Issues des intégrations
0
Intégrations
120
Actions
Partages
0
Téléchargements
34
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

PerfUG - Hadoop Performances

  1. 1. Hadoop performances
  2. 2. YOUR HUMBLE PRESENTER Sofian DJAMAA • Ex-consultant OCTO #expert-performance #expert-NoSQL #expert-babyfoot • Co-fondateur du PerfUG #performance #presentations #usi #devoxxfr • Développeur Hadoop @ Criteo • Amateur de films de requins #avalanche-shark #sharknado #mega-shark-vs-giant-octopus #sharktopus 2
  3. 3. QU’EST-CE QU’HADOOP? • Stockage: HDFS – Haute disponibilité – Large volumétrie • Traitement: MapReduce – Divide & conquer – Parallélisation sur des grosses volumétries (>> PB) • Stockage + Traitement = « Big Data » 3Copyright © 2013 Criteo.
  4. 4. ADAPTER LA CONFIGURATION DU CLUSTER Le plus simple est dans un premier temps de configurer correctement son cluster Hadoop ! • Eviter les accès disques lents sur les datanodes et les tasktrackers • RAID • NAS • LVM • Un VLAN dédié au cluster pour éviter les problèmes de réseau • Un ensemble de machines locales dédiées à Hadoop est l’idéal • Les machines servant au MR doivent être homogènes au niveau hardware (pour une meilleure parallélisation) Monitorer l’usage CPU, RAM et les I/O (disques et réseau) via des outils de monitoring Beaucoup de littérature disponible sur les tailles de machines Terasort to tune the cluster :) 4
  5. 5. MAP REDUCE 5
  6. 6. MAP REDUCE 6
  7. 7. MAP REDUCE 7
  8. 8. PHASE MAP • Les fichiers d’entrée sont contenus dans des « input splits » • Chaque fichier est assigné à un mapper • Le mapper effectue la tâche assignée (job) • Les résultats sont stockés dans un buffer mémoire temporaire • Les résultats sont ensuite partitionnés, triés et écrits sur disque • Les fichiers sont ensuite envoyés aux reducers 8
  9. 9. PHASE MAP: OPTIMISER LA LECTURE DES FICHIERS TAILLE DES BLOCKS • Les fichiers d’entrée sont stockés sur HDFS dans des blocks – Chaque fichier est séparé en input split – Chaque input split est stocké dans 1 ou plusieurs blocks • En général, un input split est assigné à un mapper taille de l’input d’un mapper = taille du fichier / facteur de compression Considérations de performance : • Si les input splits sont plus grands que les blocks HDFS : I/O réseau pour récupérer d’autres blocs sur d’autres DataNodes • Si les input splits sont plus petits que les blocks HDFS : fragmentation • Si les input splits sont trop petits : trop de mappers alloués pour des petites tâches (overhead de création des mappers) • dfs.block.size est un paramètre global au cluster ! 9
  10. 10. PHASE MAP: OPTIMISER LA LECTURE DES FICHIERS COMPRESSION Rappel: • taille de l’input d’un mapper = taille du fichier / facteur de compression • Il existe plusieurs formats de compression utilisables dans Hadoop: – GZIP : utilise le moins de mémoire mais le plus de CPU et n’est pas splittable – LZO : propose la taille de compression la plus optimale mais gourmand en CPU et mémoire – Snappy : est le plus rapide mais moins efficient que LZO sur la taille de compression • Principes généraux des algorithmes de compression – Algorithmes sans perte • Utilisation de la redondance : deflate (remplacement de symboles, utilisation de pointeurs), compression par dictionnaire (stockage d’occurrences à remplacer par un indice)… – Algorithmes avec perte : JPEG • Le curseur est à placer entre les ressources du cluster (CPU, I/Os, RAM…) et la taille des input splits : monitoring ! • Il est possible de combiner la compression à la sérialisation des données : Avro, ProtoBuf, Thrift 10
  11. 11. PHASE MAP: OPTIMISER LA LECTURE DES FICHIERS FORMATS DE FICHIER • Les fichiers d’entrée sont stockés selon un format : – Texte (plain, CSV, TSV, JSON…) – Binaire KV (SequenceFile) – Binaire Columnar (RCFile, Parquet, ORC) • taille input record en mémoire = taille de l’input record stocké sur HDFS/ “largeur” du tuple d’entrée • Pour optimiser la mémoire et le CPU il est possible de ne récupérer qu’un sous- ensemble des records stockés sur les DataNode : format columnar • Il existe plusieurs formats columnar : – RCFile – Parquet – ORCFile • Plus d’informations sur ma présentation au dernier meetup ParisDataGeek  11
  12. 12. PHASE MAP: OPTIMISER LA COLLECTE DES DONNÉES TRAITÉES • Lorsque les données ont été traitées par la fonction map, elles sont stockées dans un buffer temporaire avant d’être écrites sur disque – Les données sur disque doivent être préparées pour les reducers : partitionnées, triées et potentiellement compressées. – Pour éviter des I/O inutiles, ces traitements se font en mémoire • Si le buffer est trop petit pour recevoir l’ensemble du dataset, les données sont flushées partiellement sur le disque – Selon un ratio : io.sort.factor=10 – Selon la taille du buffer : io.sort.mb=256 • Solutions – Augmenter la taille du buffer – Réduire le ratio des meta-data – Augmenter le nombre de mappers • Ces paramètres sont à modifier suite à l’exécution de vos jobs 12
  13. 13. SPILLING EN DÉTAIL • En réalité le Spilling est un Partition/Sort/Merge sur disque  13
  14. 14. PHASE MAP: OPTIMISER L’ENVOI DES DONNÉES AUX REDUCERS • Compression – mapred.compress.map.output : spécifier si les fichiers intermédiaires, résultats de map, doivent être compressés. • Combiners – Lorsque les mappers ont traité les différents tuples, les résultats sont stockés en mémoire avant d’être écrits sur disque – En prenant pour exemple « WordCount », les mappers ne génèrent qu’une série de tuples du type (« clef » -> 1), (« clef » -> 1), (« clef » -> 1)… – Si la clef en question est présente de nombreuses fois, le tuple est dupliqué et la taille (et le nombre) des fichiers augmentent  impact sur les I/O réseau – Solution : utiliser un combiner • Peut être la fonction reduce (dans le cas de WordCount) • Ou un autre aggrégat • Partitionnement – Pour que les reducers puissent traiter des données de manière performante (algorithmes linéaires), les données sont triées et partitionnées par clef aux reducers – Il est donc important de choisir sa clef de partitionnement afin d’avoir une distribution uniforme des données aux reducers • Des reducers ou mappers en wait = des ressources bloquées sur le cluster = des jobs en retard !!!!! • REDUIRE LES I/O 14
  15. 15. PHASE REDUCE • Les fichiers d’entrées sont partitionnés pour les reducers – Une clef est assignée à chaque reducer (pour travailler avec des fichiers provenant de différents mappers) – C’est pour cela que les combiners et la compression de fichiers sont importants : ils permettent de réduire le trafic réseau Etapes : • Shuffle : récupérer les fichiers produits par les mappers (en réalité c’est ce sens là) • Merge : fusionner les fichiers d’entrée déjà triés afin de produire l’ensemble de données d’entrée • Reduce : appliquer la fonction de réduction (ex : group by, somme, moyenne…) • Write : écrire les résultats finaux sur disque 15
  16. 16. PHASE REDUCE : OPTIMISER LA LECTURE DES FICHIERS D’ENTRÉE • Les fichiers d’entrée sont récupérés depuis les emplacements locaux aux mappers  charge réseau à prévoir – Combiners – Compression – Partitionnement • Pour accélérer la récupération des fichiers pouvant être sur plusieurs mappers (donc machines) différents : multithreading 16
  17. 17. PHASE REDUCE : OPTIMISER LE MERGE DES FICHIERS D’ENTRÉE • Les fichiers d’entrée sont récupérés et lus par le reducer • Chaque input est traitée – Soit en mémoire si le dataset tient – Soit sur disque si le dataset est supérieur • Les fichiers sont lus de telle manière à garder l’ordre afin d’appliquer la fonction de reduce de manière linéaire (Big-O(n)) • De la même manière que lors de l’étape de map, le reducer peut faire du spilling – Lorsque la mémoire est trop chargée, les données sont flushées sur disque et mergées entre elles • Pour éviter le spilling : io.sort.factor 17
  18. 18. PHASE REDUCE : OPTIMISER L’ECRITURE DES FICHIERS FINAUX • Partition key (distribute by xxx in Hive) – pour les reducers • Car les data sont distribuées par clefs dans les reducers – si un reducer travaille sur plusieurs partitions • plusieurs RecordWriters  problème de performance • L’idée est donc de dédier les reducer à l’écriture sur une seule partition 18
  19. 19. TUNING JVM • Réutiliser la JVM – Temps d’initialisation de la JVM à prendre en compte • Heap • JIT • … • Heap management – Dimensionner correctement la heap • Attention au GC 19
  20. 20. OPTIMISATIONS HIVE/CASCADING • Mapjoins/Hashjoins : – S’assurer que l’ensemble utilisé pour la jointure tient effectivement en mémoire • UNION ALL/GROUP BY plutôt que d’utiliser des LEFT JOIN : moins de jobs générés – Hive peut lancer plusieurs jobs pour une requête • Sacrifier le temps d’exécution d’un job pour améliorer le temps de requêtage dans Hive 20
  21. 21. RAPPEL 21 mapred.min.split.size mapred.max.split.size dfs.block.size (cluster wide) hive.merge.mapredfiles hive.merge.smallfiles.avgsize + compression + input format mapred.compress.map.output io.sort.mb io.sort.splill.percent io.sort.factor mapred.combiner.class mapred.reduce.parallel.copies mapred.reduce.child.java.optsmapred.map.child.java.opts
  22. 22. CLUSTER MANAGEMENT MRV1 • Utiliser des pools de jobs 22
  23. 23. CLUSTER MANAGEMENT YARN • La partie stockage ne bouge pas mais le JobTracker disparaît au profit d’une nouvelle architecture Composants : • Resource Manager • Application Manager • Scheduler • Embarqué dans Hadoop 2 – Possibilité de l’utiliser hors d’Hadoop mais quelques fonctions sont manquantes (ex : API de communication avec les executors) 23
  24. 24. CLUSTER MANAGEMENT APACHE MESOS • « Resource offer » : CPU, RAM… • Le master Mesos propose une quantité de ressources à un framework à exécuter en fonction de : – Politiques d’organisation – Fair scheduling – Priorité • Il est aussi possible d’étendre via plugins (à développer) le système de mise à disponibilité de ressources • Côté développeur : définir les tasks et leurs ressources nécessaire pour le framework scheduler – API : JAVA/Scala, Python, C++… • Utilisable avec Hadoop mais aussi avec n’importe quel type de frameworks (ex : Spark) 24
  25. 25. LE PLUS IMPORTANT : LE MONITORING/PROFILING • JobTracker – Possibilité de définir ses propres compteurs pour debug • Ganglia • Nagios/Centreon : monitoring bas niveau (CPU, RAM, I/O disque, I/O réseau…) • Starfish : optimisation de la configuration Hadoop (ex : mapred-site.xml) après analyse des logs de jobs 25
  26. 26. PETITS CONSEILS • Si vos data tiennent en RAM… EVITEZ HADOOP !!!! • Si vos data peuvent tenir en RAM sur peu de machines… EVITEZ HADOOP – Spark – Gigaspaces (lol… go Spark) • En gros… tant que vous pouvez, évitez Hadoop  • Pour des requêtes qui ne prennent que peu de temps, évitez de lancer des jobs MR ou Hive ou autre… – Le temps d’initialisation des mappers et reducers est très long… • Et surtout : ME-SU-REZ !!!! – Il est très difficile d’anticiper les paramètres de configuration du cluster – Chaque job est différent si le dataset d’entrée n’est pas le même (ou si le job créé des data supplémentaires, cf. EXPLODE) 26
  27. 27. QUESTIONS ? We can talk about… #hadoop 27 #scalding #scala#sharks #summingbird #performance #mechanical-sympathy #hive #cascading #JVM

×