• Save
Softshake 2013 - Yarn dans la vraie vie, retour d'expérience et bonnes pratiques tirées de sa mise en place pour un datalab
Upcoming SlideShare
Loading in...5
×
 

Softshake 2013 - Yarn dans la vraie vie, retour d'expérience et bonnes pratiques tirées de sa mise en place pour un datalab

on

  • 1,497 views

 

Statistics

Views

Total Views
1,497
Views on SlideShare
775
Embed Views
722

Actions

Likes
2
Downloads
7
Comments
0

15 Embeds 722

http://blog.octo.com 482
http://cloud.feedly.com 171
http://www.newsblur.com 22
http://www-ig-opensocial.googleusercontent.com 9
http://digg.com 8
http://www.feedspot.com 8
http://feed.boiteataquets.org 6
http://feedly.com 6
http://inoreader.com 3
http://bluerat.fr 2
http://reader.aol.com 1
http://127.0.0.1 1
http://marty.alwaysdata.net 1
http://www.lo-ol.fr 1
http://personne.no-ip.org 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Softshake 2013 - Yarn dans la vraie vie, retour d'expérience et bonnes pratiques tirées de sa mise en place pour un datalab Softshake 2013 - Yarn dans la vraie vie, retour d'expérience et bonnes pratiques tirées de sa mise en place pour un datalab Presentation Transcript

  • 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
  • Contexte 2 © OCTO 2013
  • 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 View slide
  • 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 View slide
  • 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
  • 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
  • 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
  • Déroulement du projet 8 © OCTO 2013
  • 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
  • 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
  • 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
  • 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
  • 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
  • Les alimentations de données Constat en fin de mission Ne pas négliger le travail préparatoire ! 14 © OCTO 2013
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Merci ! Des questions ? 33 © OCTO 2013