Successfully reported this slideshow.
Your SlideShare is downloading. ×

Présentation Big Data et REX Hadoop

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 65 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Présentation Big Data et REX Hadoop (20)

Advertisement

Recently uploaded (20)

Présentation Big Data et REX Hadoop

  1. 1. 1 © OCTO 2013© OCTO 2012© OCTO 2013 Big Data : Usages et opportunités Retour d’expérience sur Hadoop
  2. 2. 2 © OCTO 2013 Joseph Glorieux Directeur général OCTO Suisse jglorieux@octo.com Rémy SAISSY Architecte senior expert Hadoop OCTO rsaissy@octo.com
  3. 3. 3 © OCTO 2013 Big Data Définition Pourquoi maintenant? Pourquoi faire? Questions/réponses Big Data et Hadoop Questions/réponses Retour d’expérience 10 Best practices pour dimensionner et configurer un cluster Hadoop Hadoop CDH4 sous YARN dans les coms Questions/réponses Conclusion Agenda
  4. 4. 4 © OCTO 2013© OCTO 2012© OCTO 2013 Big Data : définition
  5. 5. 5 © OCTO 2013
  6. 6. 6 © OCTO 2013 Big Data, une écosystème multiple Web Google, Amazon, Facebook, Twitter, … Logiciel IT IBM, Teradata, Vmware, EMC, … Management McKinsey, BC G, Deloitte, …
  7. 7. 7 © OCTO 2013 Il n’existe pas aujourd’hui de définition claire de Big Data Définir Big Data Super datawarehouse? Stockage low cost? NoSQL? Cloud? Internet Intelligence? Analyse en temps réel? Non structuré? Open Data?
  8. 8. 8 © OCTO 2013 Le marché parle des 3V Volume Variété Vélocité BatchJ+1 Seconde Temps réel Mo ToGo PoFichier SGBDRéseaux sociaux API Photo Video Web Non structurées Audio
  9. 9. 9 © OCTO 2013 Définition technologique Application orientée Flux évènementiel Application orientée Transaction Application orientée Stockage Application orientée Calculs Univers « standard » SGBDR, Serveur d’application, ETL, ESB Au-delà de 10 To en ligne, les architectures « classiques » nécessitent des adaptations logiques et matérielles très importantes. Au-delà de 1 000 transactions/seconde, les architectures « classiques » des adaptations logiques et matérielles très importantes Au-delà de 10 threads/Core CPU, la programmation séquentielle classique atteint ses limites (I/O). Au-delà de 1 000 évènements/seconde, les architectures « classiques » nécessitent des adaptations logiques et matérielles très importantes. Stockage distribué Share nothing XTP Programmation parallèle Event Stream Processing
  10. 10. 10 © OCTO 2013 Notre définition Big data est l’ambition de tirer un avantage économique de l’analyse quantitative des données internes et externes de l’entreprise
  11. 11. 11 © OCTO 2013© OCTO 2012© OCTO 2013 Big Data : pourquoi maintenant?
  12. 12. 12 © OCTO 2013 Une évolution du « hardware » toujours fantastique…
  13. 13. 13 © OCTO 2013 Evolution non uniforme de la capacité et du débit des disques 0 10 20 30 40 50 60 70 Débit(MB/s) Gain : x100 64 MB/s 0,7 MB/s Seagate Barracuda 7200.10 Seagate Barracuda ATA IV IBM DTTA 35010 Gain : x100 000 1990 2010 La croissance du débit reste très inférieure de celle de la capacité
  14. 14. 14 © OCTO 2013 Evolution des architectures pour dépasser cette limite structurelle Architecture In Memory • Réduire la latence en utilisant des supports plus rapides (DRAM, SSD) • Bénéficier de l’évolution des capacités des composants • La limite structurelle n’est que déplacée : pour évoluer, l’architecture doit devenir une grille In Memory Architecture en grille • Paralléliser les accès I/O en divisant les volumes (sharding) • Bénéficier du différentiel de coût entre commodity hardware et haut de gamme • Le réseau de la grille devient un composant principal, nécessitant co- localisation des données et des traitements • Permet de scaler à l’infini, c’est le Warehouse scale computing!
  15. 15. 15 © OCTO 2013 Théorème de CAP L’univers des SGBRD La stratégie des sites à gros trafic. Avec cohérence in fine « Consistency » Tous les clients ont la même vue de la donnée « Partition tolerance » Le système continue a fonctionner en cas de « partition » - plusieurs sous-ensembles n’arrivent plus à communiquer « Availability » Les clients peuvent toujours accéder au système (lecture écriture) « Il est impossible pour un système informatique de calcul distribué de garantir en même temps la consistance, la disponibilité et la résistance au morcellement » Eric Brewer C A P
  16. 16. 16 © OCTO 2013 Panorama de solutions Application orientée Flux évènementiel Application orientée Transaction Application orientée Stockage Application orientée Calculs Cassandra, Mong oDB, CouchDB Univers « standard » SGBDR, Serveur d’application, ETL, ESB HDFS SQLFire Teradata Hana Grid Computing Giga Spaces Map Reduce GPU Voldemort Exadata HBase Esper Quartet ActivePivot Sqoop RabbitMQ, Zero MQ Ultra Low latency Hama Igraph MapR EMC Redis ExalyticsIn memory Distribué
  17. 17. 17 © OCTO 2013© OCTO 2012© OCTO 2013 Big Data : pourquoi faire?
  18. 18. 18 © OCTO 2013
  19. 19. 19 © OCTO 2013 Scoring de crédit Supply-chain management Les nouveaux cas d’usages Prévention de l’attrition Lutte contre la fraude Modèle de tarification Segmentation client Calcul du risque Optimisation du réseau
  20. 20. 20 © OCTO 2013 Les opportunités peuvent être perçues sous 2 angles : Big Data comme « Cost killer » Big Data comme « Ouvrir le champs des possibles » Big Data : de nouvelles opportunités?
  21. 21. 21 © OCTO 2013 Comparatif machine à « puissance équivalente (RAM/CPU) » Comparatif stockage Big Data comme « cost killer » Source : http://www.slideshare.net/lucenerevolution/the-search-is-over-integrating-solr-and- hadoop-in-the-same-cluster-to-simplify-big-data-analytics SAN $2 - $10 par GB 0,5 PB 200 000 IOPS 1 GB per second Filers NAS $1 - $5 par GB 1 PB 400 000 IOPS 2 GB per second Local storage $0,05 par GB 20 PB 10 000 000 IOPS 800 GB per second Available storage for 1 million $
  22. 22. 22 © OCTO 2013 Archivage Déchargement d’entrepôt de données ET(L) Fail-over Big Data comme « cost killer » : use cases
  23. 23. 23 © OCTO 2013 Analyser des données de l’entreprise qu’il paraissait illusoire de vouloir analyser du fait du volume ou de la capacité de traitement sous-jacent : Analyse des logs web Profondeur d’analyse étendue : plusieurs années, plusieurs dizaines d’année… Croisement entre SI cloisonné Analyser des données exogènes de l’entreprise et les croiser avec les données existantes Réseaux sociaux Recherches internet Internet des objets Big Data comme « Ouvrir le champs des possibles »
  24. 24. 24 © OCTO 2013 Ouvrir le champs des possibles : grille de lecture Segmentation Comportement Influence Concurrence Usage / Exp Adoption / Reco Mesure Optimisation Collaboration Données d’Identité Données d’Usage Données de Relation Axesd’analyse Sources de données Client Produit Services Processus
  25. 25. 25 © OCTO 2013
  26. 26. 26 © OCTO 2013© OCTO 2012© OCTO 2013 Big Data et Hadoop
  27. 27. 27 © OCTO 2013 Hadoop dans l’univers Big data Application orientée Flux évènementiels Application orientée Transactions Application orientée Stockage Application orientée Calculs Parrallel database NoSQL NewSQL CEP, ESP H a d o o p In Memory
  28. 28. 28 © OCTO 2013 Hadoop s’impose comme une architecture de référence sur le marché • Apache Hadoop Open Source • Cloudera CDH • Hortonworks • MapR COTS • Greenplum (EMC) • IBM InfoSphere BigInsights (CDH) • Oracle Big data appliance (CDH) • Teradata (aster) Editeurs • Amazon EMR (MapR) • VirtualScale (CDH) Cloud
  29. 29. 29 © OCTO 2013 Hadoop et les outils de BI et de Data mining
  30. 30. 30 © OCTO 2013 Hadoop, un écosystème riche et complexe Traitement MapReduce Framework permettant de traiter des données en parallèle Requêtage Pig Langage de flux de données Hive DSL de requêtage « SQL-like » Workflow Oozie / Azkaban Workflow pour jobs Hadoops dépendants Infrastructure Intégration au SI Flume, Chukwa, Scribe… Collection de données fiable et résiliente Sqoop Intégration RDBMS & Hadoop Supervision Platform Management Console Hue Traitement distribué avancé Mahout Machine learning Hama Bulk Synchronous Processing Stockage HDFS Un système de fichiers distribué write-once, read-many Hbase Base de données pour des accès aléatoires read/write Reporting Hue Beeswax Interface web de requêtage Pentaho Reporting IBM BigSheets Outil de requêtage
  31. 31. 31 © OCTO 2013 Répartition des données sur plusieurs machines Réplication des données pour assurer le « fail-over » : « rack awareness » Hadoop Distributed File System (HDFS)
  32. 32. 32 © OCTO 2013 Paralléliser et distribuer les traitements Traiter plus rapidement des volumes de données unitaires plus faibles Co-localiser traitements / données MapReduce, le système de traitement
  33. 33. 33 © OCTO 2013 Hadoop est à la fois : Un système de stockage distribué pour les grands fichiers Un système d’agrégation et de traitement parallèle en mode batch à la demande, reposant sur la grille de stockage Hadoop n’est pas : Un système d’accès à la donnée unitaire (random access) Un système temps réel, mais batch à la demande Hadoop nécessite des composants externes pour compléter le puzzle Des outils de visualisation graphique des données Une librairie de traitements statistiques et text mining finalisée Mahout, Hama fournissent des algorithmes parallèles … Les mythes et réalités sur Hadoop
  34. 34. 34 © OCTO 2013
  35. 35. 35 © OCTO 2013© OCTO 2012© OCTO 2013 10 best practices pour dimensionner et configurer un cluster Hadoop
  36. 36. 36 © OCTO 2013 Piège 1 : la tentation des machines « monstres de guerre » Piège 2 : le réseau, mieux vaut 10Gb/s c’est plus sûr Piège 3 : pour superviser, mes outils actuels suffisent ! Piège 4 : un SCM ? Pas le temps, SSH fera l’affaire ! Piège 5 : les logs c’est important, il faut tous les collecter Piège 6 : conserver les paramètres mémoire par défaut Piège 7 : conserver la configuration par défaut de HDFS Piège 8 : conserver la configuration par défaut de MapReduce Piège 9 : utiliser les formats de fichier par défaut Piège 10 : benchmarker son cluster avec TeraSort Sommaire
  37. 37. 37 © OCTO 2013 Le piège Des ressources inutilisées Un niveau de parallélisme insuffisant Un surcoût aux performances non garanties Best Practice Penser parallélisation Notion de conteneur : 1 CPU physique / xGo de RAM / Disque dur HDFS Dimensionner pour du temps de traitement Piège 1 : la tentation des machines « monstres de guerre »
  38. 38. 38 © OCTO 2013 Le piège Pour garder de bonnes perfs, il faut éviter la sursouscription Switchs de rack plus gros, donc plus cher 10Gb/s = 1Go/s = 40Go/s au niveau du switch Backbone encore plus gros, donc encore plus cher 40Go/s * <nombre de racks> = ? Best Practice Utiliser deux cartes 1Gb/s FD Moins de disque sur chaque serveur Superviser Piège 2 : le réseau, mieux vaut 10Gb/s c’est plus sûr
  39. 39. 39 © OCTO 2013 Le piège Pas de détail sur les métriques internes d’Hadoop Lectures / écritures de HDFS par nœud Consommation mémoire pendant les étapes d’un job Best Practice Pensez aux développeurs ! Utiliser Ganglia pour des métriques fines Piège 3 : pour superviser, mes outils actuels suffisent !
  40. 40. 40 © OCTO 2013 Le piège Un petit cluster Hadoop, c’est 10 machines Configuration et maintenance à la main difficile Perte de temps Best Practice Utiliser un SCM Piège 4 : un SCM ? Pas le temps, SSH fera l’affaire !
  41. 41. 41 © 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 Best Practice Pas de collecte sur les slaves Collecte sur les masters Piège 5 : les logs c’est important, il faut tous les collecter
  42. 42. 42 © OCTO 2013 Le piège Ils ne sont pas optimisés pour votre cluster Sous utilisation des ressources Échecs possibles de certains jobs Best Practice 2Go pour les démons tasktracker et datanode 4Go pour le démon JobTracker 4Go + 1Go par million de bloc pour le namenode Utiliser 4Go voire 8Go par tâche de map et de reduce Superviser Piège 6 : conserver les paramètres mémoire par défaut
  43. 43. 43 © OCTO 2013 Le piège Pas optimisée pour un cluster Les paramètres dépendent de vos données, de votre réseau, … Best Practice Configurer en pensant I/O vs mémoire vs réseau Chaque cas d’utilisation a sa propre configuration optimisée Superviser Piège 7 : conserver la configuration par défaut de HDFS
  44. 44. 44 © OCTO 2013 Le piège Pas optimisée pour un cluster Les paramètres dépendent de votre utilisation Best Practice Utiliser le CapacityScheduler Configurer avec des règles de calcul Auditer l’usage réel pour optimiser les configurations Piège 8 : conserver la configuration par défaut de MapReduce
  45. 45. 45 © OCTO 2013 Le piège Lenteur des jobs dû à un stockage inefficace Plus d’espace utilisé que nécessaire Best Practice Format de stockage : distinguer les usages Base de données Données binaires Compression : quelle fréquence d’accès ? Donnée utilisée Archivage Piège 9 : utiliser les formats de fichier par défaut
  46. 46. 46 © OCTO 2013 Le piège Non représentatif de l’usage réel du cluster Best Practice Utiliser du code de production Piège 10 : benchmarker son cluster avec TeraSort
  47. 47. 47 © OCTO 2013
  48. 48. 48 © OCTO 2013© OCTO 2012© OCTO 2013 Hadoop CDH4 sous YARN dans les télécoms. Retour d'expérience
  49. 49. 49 © OCTO 2013 Contexte Caractéristiques du cluster Déroulement du projet Déploiement de Hadoop Déploiement des outils support Les alimentations de données L’analyse des données La migration du cluster Le benchmark du cluster Cluster en fin de mission Conclusion Sommaire
  50. 50. 50 © OCTO 2013 Durée : 3 mois Equipe opérationnelle : 8 personnes Trois enjeux majeurs : Construire une plateforme Big Data opérationnelle Montée en compétence des équipes Préconisations pour une plateforme industrielle Equipe colocalisée Contexte
  51. 51. 51 © 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
  52. 52. 52 © OCTO 2013 Déroulement du projet
  53. 53. 53 © OCTO 2013 Réseau de production : utiliser un mirroir local Configuration OS : compétences système et réseau requises Utiliser un SCM pour déployer Nécessité d’avoir des profils polyvalents Déploiement de Hadoop A l’attaque !
  54. 54. 54 © OCTO 2013 Relativement facile une fois Hadoop correctement installé Peu d’impact sur le cluster en lui même Ne déployer que le nécessaire Déploiement des outils support
  55. 55. 55 © OCTO 2013 KISS : Keep It Simple Stupid Ne pas négliger le travail en amont de l’analyse ! Les alimentations de données
  56. 56. 56 © 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 L’analyse des données
  57. 57. 57 © OCTO 2013 Passage de CDH 4.0.1 à CDH 4.1.2 Des leçons Du travail en amont Le SCM aurait fait gagner du temps Suivre les préconisations ! La migration du cluster
  58. 58. 58 © OCTO 2013 Initialement en début de projet… Terasort ? Plutôt HiBench Au final, le travail réalisé pendant le projet a été le meilleur benchmark Le benchmark du cluster
  59. 59. 59 © OCTO 2013 Cluster YARN opérationnel Plusieurs outils testés au cours de l’exploration HDFS occupé à 70% : 1 427 251 fichiers, 280To Les jobs ne saturent pas complètement le cluster Cluster en fin de mission
  60. 60. 60 © OCTO 2013 Des points positifs YARN : stable et ouvre à d’autres frameworks que Map Reduce Des outils polyvalents Des points à améliorer Maturité des outils et de leur environnement de travail Complexité de la configuration de Hadoop comme de ses outils Des documentations et des abaques Mettre en place votre cluster ? une équipe pluri disciplinaire de la polyvalence technique Bilan
  61. 61. 61 © OCTO 2013
  62. 62. 62 © OCTO 2013© OCTO 2012© OCTO 2013 Conclusion
  63. 63. 63 © OCTO 2013 Use cases Cost killer Ouvrir le champs des possibles L’écosystème Hadoop est riche et complexe, en mouvement L’usage a une incidence forte sur l’architecture et la configuration Conclusion
  64. 64. 64 © OCTO 2013 Identifiez les use cases métiers applicables dans votre contexte, en benchmarkant les projets lancés dans d’autres secteurs et au-delà Lancez un POC métier d’exploration des données, avec les métiers les plus early adopters Marketing Distribution Trading Risques Valorisez les résultats du POC en termes métiers Définissez une architecture cible de classe industrielle pour généraliser l’approche en réduisant les coûts Comment démarrer cet après midi?
  65. 65. 65 © OCTO 2013 OCTO et le Big Data Une offre cohérente entre technologie et analyse prédictive CONSEIL EN SI BIG DATA  Etude et positionnement des solutions en fonction de votre contexte  Transformation de SI Décisionnel vers le Big Data  Cadrage de projets Big Data ARCHITECTURE DES SYSTÈMES BIG DATA  POC sur Hadoop et NoSQL  Conception et réalisation de systèmes sous Hadoop et NoSQL  Formation Hadoop CONSEIL EN ANALYSE DE DONNÉES AVANCÉES  Benchmarks de projets Big Data par secteur  Formation des équipes de datamining aux techniques Big Data  Accompagnent des projets pilotes métiers COLLECTE DE DONNÉES EXTERNES  Identification de sources de données  Collecte et traitements de données non structurées  Recherche de corrélations économiques DIRECTION SI DIRECTION MÉTIER

×