Téléchargé parJoseph Glorieux
Présentation Big Data et REX Hadoop
Le document présente une analyse approfondie de Big Data et Hadoop, abordant leur définition, leur importance actuelle et les meilleures pratiques pour dimensionner et configurer un cluster Hadoop. Des retours d'expérience sont inclus, mettant en avant des cas d'utilisation ainsi que des conseils pour optimiser les performances de traitement de données. En conclusion, il est souligné que l'écosystème Hadoop évolue constamment et nécessite une approche adaptée aux exigences spécifiques des entreprises.
Contenu connexe
Similaire à Présentation Big Data et REX Hadoop
Présentation Big Data et REX Hadoop
- 1. 1 © OCTO 2013©OCTO 2012© OCTO 2013 Big Data : Usages et opportunités Retour d’expérience sur Hadoop
- 2. 2 © OCTO 2013 JosephGlorieux Directeur général OCTO Suisse [email protected] Rémy SAISSY Architecte senior expert Hadoop OCTO [email protected]
- 3. 3 © OCTO 2013 BigData 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 © OCTO 2013©OCTO 2012© OCTO 2013 Big Data : définition
- 5.
- 6. 6 © OCTO 2013 BigData, une écosystème multiple Web Google, Amazon, Facebook, Twitter, … Logiciel IT IBM, Teradata, Vmware, EMC, … Management McKinsey, BC G, Deloitte, …
- 7. 7 © OCTO 2013 Iln’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 © OCTO 2013 Lemarché 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 © OCTO 2013 Définitiontechnologique 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 © OCTO 2013 Notredé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 © OCTO 2013©OCTO 2012© OCTO 2013 Big Data : pourquoi maintenant?
- 12. 12 © OCTO 2013 Uneévolution du « hardware » toujours fantastique…
- 13. 13 © OCTO 2013 Evolutionnon 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 © OCTO 2013 Evolutiondes 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 © OCTO 2013 Théorèmede 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 © OCTO 2013 Panoramade 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 © OCTO 2013©OCTO 2012© OCTO 2013 Big Data : pourquoi faire?
- 18.
- 19. 19 © OCTO 2013 Scoringde 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 © OCTO 2013 Lesopportunité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 © OCTO 2013 Comparatifmachine à « 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 © OCTO 2013 Archivage Déchargementd’entrepôt de données ET(L) Fail-over Big Data comme « cost killer » : use cases
- 23. 23 © OCTO 2013 Analyserdes 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 © OCTO 2013 Ouvrirle 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.
- 26. 26 © OCTO 2013©OCTO 2012© OCTO 2013 Big Data et Hadoop
- 27. 27 © OCTO 2013 Hadoopdans 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 © OCTO 2013 Hadoops’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 © OCTO 2013 Hadoopet les outils de BI et de Data mining
- 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 © OCTO 2013 Répartitiondes données sur plusieurs machines Réplication des données pour assurer le « fail-over » : « rack awareness » Hadoop Distributed File System (HDFS)
- 32. 32 © OCTO 2013 Paralléliseret 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 © OCTO 2013 Hadoopest à 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.
- 35. 35 © OCTO 2013©OCTO 2012© OCTO 2013 10 best practices pour dimensionner et configurer un cluster Hadoop
- 36. 36 © OCTO 2013 Piège1 : 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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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 © OCTO 2013 Lepiè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.
- 48. 48 © OCTO 2013©OCTO 2012© OCTO 2013 Hadoop CDH4 sous YARN dans les télécoms. Retour d'expérience
- 49. 49 © OCTO 2013 Contexte Caractéristiquesdu 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 © 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 © OCTO 2013 1rack, 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 © OCTO 2013 Déroulementdu projet
- 53. 53 © OCTO 2013 Réseaude 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 © OCTO 2013 Relativementfacile 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 © 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 © OCTO 2013 Beaucoupde 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 © OCTO 2013 Passagede 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 © OCTO 2013 Initialementen 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 © OCTO 2013 ClusterYARN 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 © OCTO 2013 Despoints 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.
- 62. 62 © OCTO 2013©OCTO 2012© OCTO 2013 Conclusion
- 63. 63 © OCTO 2013 Usecases 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 © OCTO 2013 Identifiezles 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 © OCTO 2013 OCTOet 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