Softshake 2013 - YARN dans la vraie vie

Retour d'expérience et bonnes pratiques tirées de la mise en place de Hadoop YARN pour un datalab.
Présenté à la Softshake 2013.

Transcript

1. 1 © OCTO 2013 © OCTO 2012 © OCTO 2013 YARN dans la vraie vie Retour d’expérience et bonnes pratiques tirées de sa mise en place pour un datalab Rémy SAISSY
2. 2 © OCTO 2013 © OCTO 2013 Contexte
3. 3 © OCTO 2013 Rémy SAISSY, OCTO Technology Responsable de la R&D Hadoop Architecte spécialisé sur les sujets Big Data @RemySaissy Qui suis je ?
4. 4 © OCTO 2013 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 Contexte
5. 5 © OCTO 2013 Coté client 2 managers 2 ingénieurs logiciel 4 analystes Coté OCTO 1 directeur de mission 2 architectes Equipe colocalisée Caractéristiques de l’équipe
6. 6 © OCTO 2013 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 Caractéristiques du cluster Slaves Masters Outils Accès Masters et Outils
7. 7 © OCTO 2013 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
8. 8 © OCTO 2013 © OCTO 2013 Déroulement du projet
9. 9 © OCTO 2013 Un cluster de CentOS disponibles Accès SSH en root Il ne reste plus qu’à installer ! Oui, mais… Mise en place du cluster Déploiement d’Hadoop A l’attaque !
10. 10 © OCTO 2013 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 Mise en place du cluster Déploiement d’Hadoop
11. 11 © OCTO 2013 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 ! Mise en place du cluster Déploiement d’Hadoop
12. 12 © OCTO 2013 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
13. 13 © OCTO 2013 A chaque outil sa configuration Complexité à tout maintenir Configuration parfois complexe Des IHM globalement trop basiques La ligne de commande reste le plus complet Mise en place du cluster Déploiement des outils
14. 14 © OCTO 2013 Constat en fin de mission Ne pas négliger le travail préparatoire ! Les alimentations de données
15. 15 © OCTO 2013 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é L’analyse des données
16. 16 © OCTO 2013 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 L’analyse des données Hive
17. 17 © OCTO 2013 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. L’analyse des données Pig
18. 18 © OCTO 2013 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 ! L’analyse des données Impala
19. 19 © OCTO 2013 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. L’analyse des données Mahout
20. 20 © OCTO 2013 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 ! La migration du cluster
21. 21 © OCTO 2013 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 Le benchmark du cluster
22. 22 © OCTO 2013 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 Cluster en fin de mission
23. 23 © OCTO 2013 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 Les pièges
24. 24 © OCTO 2013 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 La tentation des machines « monstres de guerre »
25. 25 © OCTO 2013 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 Pour superviser, mes outils actuels suffisent !
26. 26 © OCTO 2013 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 Un SCM ? Pas le temps, SSH fera l’affaire !
27. 27 © OCTO 2013 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 Les logs c’est important, il faut tous les collecter
28. 28 © OCTO 2013 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 Conserver les paramètres mémoire par défaut
29. 29 © OCTO 2013 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 Conserver la configuration par défaut de HDFS
30. 30 © OCTO 2013 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 Conserver la configuration par défaut de MapReduce
31. 31 © OCTO 2013 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 Utiliser les formats de fichier par défaut
32. 32 © OCTO 2013 Le piège Non représentatif de l’usage réel du cluster Comment l’éviter ? Utiliser le code de production Benchmarker son cluster avec TeraSort
33. 33 © OCTO 2013 © OCTO 2013 Merci ! Des questions ?