1. YARN dans la vraie vie
Retour d’expérience et bonnes pratiques tirées de sa mise en
place pour un datalab
1
Rémy SAISSY
© OCTO 2013
2012

2. Contexte
2
© OCTO 2013

3. Qui suis je ?
Rémy SAISSY, OCTO Technology
Responsable de la R&D Hadoop
Architecte spécialisé sur les sujets Big Data
@RemySaissy
3
© OCTO 2013

4. Contexte
Fin 2012
Durée : 3 mois
Equipe : 10 personnes
Trois enjeux majeurs :
Construire une plateforme Hadoop opérationnelle
Montée en compétence de l’équipe
Préconisations pour une plateforme industrielle
4
© OCTO 2013

5. Caractéristiques de l’équipe
Coté client
2 managers
2 ingénieurs logiciel
4 analystes
Coté OCTO
1 directeur de mission
2 architectes
Equipe colocalisée
5
© OCTO 2013

6. Caractéristiques du cluster
1 rack, 12 serveurs
1 nœud pour les outils, 1 autre pour l’anonymisation
2 nœuds master
namenode / resourcemanager
secondary namenode
8 nœuds slave : datanode et nodemanager
Masters
Slaves
Accès Masters et
Outils
Outils
6
© OCTO 2013

7. Méthodologie de travail
Une méthodologie itérative
Pourquoi ?
Temps limité
Projet dense
Infra : Mise en place et configuration du cluster
Exploration des possibilités des outils d’Hadoop
Transfert de compétences
Comment ?
Co-localisation de l’équipe opérationnelle
Mise au point et priorisation d’un backlog
Réunion d’avancement hebdomadaire
On y aborde les réussites et les points bloquants
On y valide le travail réalisé
On y ajuste le backlog pour la semaine suivante
Objectifs
Favoriser un bon suivi de l’avancement
Favoriser les échanges en direct
Eviter les blocages, les non dits
7
© OCTO 2013

8. Déroulement du projet
8
© OCTO 2013

9. Mise en place du cluster
Déploiement d’Hadoop
Un cluster de CentOS disponibles
Accès SSH en root
Il ne reste plus qu’à installer !
Oui, mais…
A l’attaque !
9
© OCTO 2013

10. Mise en place du cluster
Déploiement d’Hadoop
Serveurs fournis par la DSI
Configuration matérielle « imposée »
Taille de certaines partitions inadaptées
Pas d’accès internet
Firewalls
Résultat
Partitions :
des adaptations « crades » à base de liens symboliques
Repartitionnement en GPT des disques de stockage
Accès internet : création d’un mirroir local
Firewalls : demandes d’ouvertures de ports
Coût : Un peu plus d’une semaine
10
© OCTO 2013

11. Mise en place du cluster
Déploiement d’Hadoop
Beaucoup de petits détails qui comptent
Kernel : swapiness, overcommit, hugepages, …
Ext4 : pas de blocs réservés, noatime, nodiratime, …
Hadoop : taille des blocs HDFS, réplication, mémoire par
composant ?
Résultat
Pour le transfert de compétences : très positif
Pour le projet : démarrage très lent. Impact négatif
Un SCM au démarrage peut faire gagner beaucoup de
temps !
11
© OCTO 2013

12. Mise en place du cluster
Déploiement des outils
Relativement facile une fois Hadoop correctement installé
Peu d’impact sur le cluster en lui même
Ne déployer que le nécessaire
12
© OCTO 2013

13. Mise en place du cluster
Déploiement des outils
A chaque outil sa configuration
Complexité à tout maintenir
Configuration parfois complexe
Des IHM globalement trop basiques
La ligne de commande reste le plus complet
13
© OCTO 2013

14. Les alimentations de données
Constat en fin de mission
Ne pas négliger le travail préparatoire !
14
© OCTO 2013

15. L’analyse des données
Beaucoup de travail en amont
Un cluster s’optimise au contact de la réalité
Limites des outils
Ajustement de l’ordonnanceur
Configuration mémoire
Configuration d’HDFS
Python est ici un bon allié
15
© OCTO 2013

16. L’analyse des données
Hive
Points positifs
Globalement compatible avec les requêtes SQL utilisées
Points négatifs
Bug surprenant sur les dates
Trop lent
Après 1 mois de CREATE TABLE, beaucoup de blocs sous remplis
16
© OCTO 2013

17. L’analyse des données
Pig
Points positifs
Les analystes y voyait un « SAS like »
Points négatifs
Trop lent
Pas d’intégration Hcatalog dans la CDH à l’époque
Son utilisation a tourné court rapidement.
17
© OCTO 2013

18. L’analyse des données
Impala
Tests rapides effectués sur la version bêta
Au moment de la sortie d’Impala
Points négatifs
Lent
Plantages du shell Impala
Certaines requêtes retournaient des résultats invalides
Problèmes corrigés depuis mais une leçon de cela :
Qu’un éditeur communique sur un produit ne signifie pas
que ce produit est utilisable !
18
© OCTO 2013

19. L’analyse des données
Mahout
Version utilisée : 0.6
Quelques algorithmes utilisés
Naive bayes, random forest, regression logistique, k-means, arbres de décision
Des points positifs
Ligne de commande, facile à utiliser
Déjà installé dans la CDH
Des douleurs
Documentation inadaptée
Besoin du code source pour comprendre comment ça marche
Sorties textuelles
grep sur la sortie standard
Manque d’homogénéité
Formats d’entrée, docs
Le passage de 0.6 à 0.7 (migration de mineure CDH) a cassé nos jobs
Format d’entrée textuel supprimé au profit du vectoriel
Produit nettement moins mature que scikit ou R mais en amélioration.
19
© OCTO 2013

20. La migration du cluster
Passage de CDH 4.0.1 à CDH 4.1.2
Des leçons
Du travail en amont
Un SCM aurait fait gagner du temps
Suivre les préconisations !
20
© OCTO 2013

21. Le benchmark du cluster
Initialement en début de projet…
Terasort ? Plutôt HiBench
Au final, les jobs exécutés pendant le projet ont été
les meilleurs benchmarks
21
© OCTO 2013

22. Cluster en fin de mission
Cluster YARN opérationnel
Plusieurs outils testés au cours de l’exploration
HDFS occupé à 70%
Les jobs ne saturent pas complètement le cluster
22
© OCTO 2013

23. Les pièges
La tentation des machines « monstres de guerre »
Pour superviser, mes outils actuels suffisent !
Un SCM ? Pas le temps, SSH fera l’affaire !
Les logs c’est important, il faut tous les collecter
Conserver les paramètres mémoire par défaut
Conserver la configuration par défaut de HDFS
Conserver la configuration par défaut de MapReduce
Utiliser les formats de fichier par défaut
Benchmarker son cluster avec TeraSort
23
© OCTO 2013

24. La tentation des machines « monstres de guerre »
Le piège
Des ressources inutilisées
Un niveau de parallélisme insuffisant
Un surcoût aux performances non garanties
Comment l’éviter ?
Penser parallélisme
Notion de conteneur : 1 coeur / xGo de RAM / 1 Disque dur HDFS
Dimensionner pour du temps de traitement
24
© OCTO 2013

25. Pour superviser, mes outils actuels suffisent !
Le piège
L’utilisation d’outils type nagios seuls ne donne pas de détails sur
les métriques internes d’Hadoop
Lectures / écritures de HDFS par nœud
I/O et mémoire pendant l’exécution d’un job
Stop-the-world GC
Comment l’éviter ?
Hadoop embarque un connecteur Ganglia
Ambari permet d’avoir un vue cohérente de toutes ces métriques
Pensez aux développeurs !
Ils sont les mieux placé pour optimiser leurs jobs
25
© OCTO 2013

26. Un SCM ? Pas le temps, SSH fera l’affaire !
Le piège
Un petit cluster Hadoop, c’est 10 machines
Configuration et maintenance à la main difficile
Perte de temps
Comment l’éviter ?
Utiliser un SCM, Cloudera Manager ou Ambari
26
© OCTO 2013

27. Les logs c’est important, il faut tous les collecter
Le piège
500 mappers et 20 reducers
> 520 fichiers de logs à collecter sur tout le cluster
Peu d’informations utiles à long terme
Comment l’éviter ?
Sur les slaves : collecte uniquement des logs des Applications
Master
Collecte sur les masters
27
© OCTO 2013

28. Conserver les paramètres mémoire par défaut
Le piège
Ils ne sont pas optimisés pour votre cluster
Sous utilisation des ressources
Échecs possibles de certains jobs
Comment l’éviter ?
2Go pour les démons nodemanager et datanode
4Go pour le démon resourcemanager
4Go + 1Go par million de bloc HDFS pour le namenode
Secondary namenode configuré comme le namenode
Utiliser 4Go voire 8Go par container
Superviser
28
© OCTO 2013

29. Conserver la configuration par défaut de HDFS
Le piège
Pas optimisée pour un cluster
Les paramètres dépendent de vos données, de votre réseau, …
Comment l’éviter ?
Blocs d’au moins 128Mo
Utiliser la compression BLOCK par défaut
RECORD est pertinent pour pour des vidéos par exemple
Utiliser Gzip pour de la donnée archivée, Snappy pour des
données de travail
Ajuster les buffers d’I/O, le nombre de threads serveur, la bande
passante dédiée à la réplication des blocs, …
Superviser
29
© OCTO 2013

30. Conserver la configuration par défaut de MapReduce
Le piège
Pas optimisée pour un cluster
Les paramètres dépendent de votre utilisation
Comment l’éviter ?
Compresser les résultats intermédiaires avec Snappy
Utiliser le CapacityScheduler ou le FairScheduler
Indiquer à YARN des valeurs mémoire minimales et maximales
larges
Configurer avec des règles de calcul
Container / serveur : nb cores * 1,5 – 1
Mémoire : 8Go / core
Auditer l’usage réel pour optimiser les configurations
30
© OCTO 2013

31. Utiliser les formats de fichier par défaut
Le piège
Lenteur des jobs dû à un stockage inefficace
Plus d’espace utilisé que nécessaire
Comment l’éviter ?
Format de stockage : distinguer les usages
Base de données : Parquet / ORC
Données binaires : SeqFile
Compression : quelle fréquence d’accès ?
Donnée utilisée : Snappy
Archivage : GZip
31
© OCTO 2013

32. Benchmarker son cluster avec TeraSort
Le piège
Non représentatif de l’usage réel du cluster
Comment l’éviter ?
Utiliser le code de production
32
© OCTO 2013

33. Merci !
Des questions ?
33
© OCTO 2013