Présentation Big Data et REX Hadoop

3 464 vues

Publié le

présentation sur biga data : définition, la génèse, pourquoi maintenant et pourquoi faire
suivi de REX sur la mise en oeuvre de Hadoop

Publié dans : Technologie
2 commentaires
14 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
3 464
Sur SlideShare
0
Issues des intégrations
0
Intégrations
41
Actions
Partages
0
Téléchargements
0
Commentaires
2
J’aime
14
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Présentation Big Data et REX Hadoop

  1. 1. 1© OCTO 2013© OCTO 2012© OCTO 2013Big Data : Usages et opportunitésRetour d’expérience sur Hadoop
  2. 2. 2© OCTO 2013Joseph GlorieuxDirecteur généralOCTO Suissejglorieux@octo.comRémy SAISSYArchitecte seniorexpert HadoopOCTOrsaissy@octo.com
  3. 3. 3© OCTO 2013Big DataDéfinitionPourquoi maintenant?Pourquoi faire?Questions/réponsesBig Data et HadoopQuestions/réponsesRetour d’expérience10 Best practices pour dimensionner et configurer un clusterHadoopHadoop CDH4 sous YARN dans les comsQuestions/réponsesConclusionAgenda
  4. 4. 4© OCTO 2013© OCTO 2012© OCTO 2013Big Data : définition
  5. 5. 5© OCTO 2013
  6. 6. 6© OCTO 2013Big Data, une écosystème multipleWebGoogle, Amazon,Facebook, Twitter,…Logiciel ITIBM, Teradata,Vmware, EMC,…ManagementMcKinsey, BCG, Deloitte, …
  7. 7. 7© OCTO 2013Il n’existe pas aujourd’hui de définition claire de Big DataDéfinir Big DataSuper datawarehouse?Stockage low cost?NoSQL?Cloud?InternetIntelligence?Analyse en tempsréel?Non structuré? Open Data?
  8. 8. 8© OCTO 2013Le marché parle des 3VVolumeVariétéVélocitéBatchJ+1SecondeTemps réelMo ToGo PoFichierSGBDRéseauxsociauxAPIPhotoVideoWebNon structuréesAudio
  9. 9. 9© OCTO 2013Définition technologiqueApplicationorientée FluxévènementielApplication orientéeTransactionApplication orientéeStockageApplication orientéeCalculsUnivers« standard »SGBDR,Serveur d’application,ETL, ESBAu-delà de 10 To en ligne, lesarchitectures « classiques »nécessitent des adaptationslogiques et matérielles trèsimportantes.Au-delà de 1 000transactions/seconde, lesarchitectures « classiques » desadaptations logiques etmatérielles très importantesAu-delà de 10 threads/CoreCPU, la programmationséquentielle classique atteintses limites (I/O).Au-delà de 1 000évènements/seconde, lesarchitectures « classiques »nécessitent des adaptationslogiques et matérielles trèsimportantes.StockagedistribuéSharenothingXTPProgrammationparallèleEvent StreamProcessing
  10. 10. 10© OCTO 2013Notre définitionBig data est l’ambition de tirer unavantage économiquedel’analyse quantitative desdonnéesinternes et externes de l’entreprise
  11. 11. 11© OCTO 2013© OCTO 2012© OCTO 2013Big Data : pourquoi maintenant?
  12. 12. 12© OCTO 2013Une évolution du « hardware » toujours fantastique…
  13. 13. 13© OCTO 2013Evolution non uniforme de la capacité et du débitdes disques010203040506070Débit(MB/s)Gain : x10064 MB/s0,7 MB/sSeagateBarracuda7200.10SeagateBarracudaATA IVIBM DTTA35010Gain : x100 0001990 2010La croissance du débit reste très inférieure de celle de la capacité
  14. 14. 14© OCTO 2013Evolution des architectures pour dépassercette limite structurelleArchitecture In Memory• Réduire la latence en utilisantdes supports plus rapides(DRAM, SSD)• Bénéficier de l’évolution descapacités des composants• La limite structurelle n’est quedéplacée : pourévoluer, l’architecture doitdevenir une grille In MemoryArchitecture en grille• Paralléliser les accès I/O endivisant les volumes (sharding)• Bénéficier du différentiel decoût entre commodityhardware et haut de gamme• Le réseau de la grille devientun composantprincipal, nécessitant co-localisation des données etdes traitements• Permet de scaler à l’infini, c’estle Warehouse scalecomputing!
  15. 15. 15© OCTO 2013Théorème de CAPL’univers desSGBRDLa stratégie des sitesà gros trafic.Avec cohérence in fine« Consistency »Tous les clients ontla même vue de ladonnée« Partition tolerance »Le système continue afonctionner en cas de« partition » - plusieurssous-ensembles n’arriventplus à communiquer« Availability »Les clients peuventtoujours accéder ausystème (lecture écriture)« Il est impossible pour un système informatique de calcul distribué de garantir enmême temps la consistance, la disponibilité et la résistance au morcellement »Eric BrewerCAP
  16. 16. 16© OCTO 2013Panorama de solutionsApplicationorientée FluxévènementielApplication orientéeTransactionApplication orientéeStockageApplication orientéeCalculsCassandra, MongoDB, CouchDBUnivers« standard »SGBDR,Serveurd’application,ETL, ESBHDFSSQLFireTeradataHanaGrid ComputingGiga SpacesMap ReduceGPUVoldemortExadataHBaseEsperQuartetActivePivotSqoopRabbitMQ,Zero MQUltra LowlatencyHamaIgraphMapREMCRedisExalyticsIn memoryDistribué
  17. 17. 17© OCTO 2013© OCTO 2012© OCTO 2013Big Data : pourquoi faire?
  18. 18. 18© OCTO 2013
  19. 19. 19© OCTO 2013Scoring de créditSupply-chainmanagementLes nouveaux cas d’usagesPrévention del’attritionLutte contre lafraudeModèle detarificationSegmentation clientCalcul du risqueOptimisation du réseau
  20. 20. 20© OCTO 2013Les opportunités peuvent être perçues sous 2angles :Big Data comme « Cost killer »Big Data comme « Ouvrir le champs des possibles »Big Data : de nouvelles opportunités?
  21. 21. 21© OCTO 2013Comparatif machine à « puissance équivalente (RAM/CPU) »Comparatif stockageBig 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-analyticsSAN$2 - $10 par GB0,5 PB200 000 IOPS1 GB per secondFilers NAS$1 - $5 par GB1 PB400 000 IOPS2 GB per secondLocal storage$0,05 par GB20 PB10 000 000 IOPS800 GB per secondAvailable storagefor 1 million $
  22. 22. 22© OCTO 2013ArchivageDéchargement d’entrepôt de donnéesET(L)Fail-overBig Data comme « cost killer » : use cases
  23. 23. 23© OCTO 2013Analyser des données de l’entreprise qu’il paraissaitillusoire de vouloir analyser du fait du volume ou de lacapacité de traitement sous-jacent :Analyse des logs webProfondeur d’analyse étendue : plusieurs années, plusieursdizaines d’année…Croisement entre SI cloisonnéAnalyser des données exogènes de l’entreprise et lescroiser avec les données existantesRéseaux sociauxRecherches internetInternet des objetsBig Data comme « Ouvrir le champs des possibles »
  24. 24. 24© OCTO 2013Ouvrir le champs des possibles : grille de lectureSegmentation Comportement InfluenceConcurrence Usage / Exp Adoption / RecoMesure Optimisation CollaborationDonnéesd’IdentitéDonnéesd’UsageDonnées deRelationAxesd’analyseSources de donnéesClientProduitServicesProcessus
  25. 25. 25© OCTO 2013
  26. 26. 26© OCTO 2013© OCTO 2012© OCTO 2013Big Data et Hadoop
  27. 27. 27© OCTO 2013Hadoop dans l’univers Big dataApplicationorientée FluxévènementielsApplication orientéeTransactionsApplication orientéeStockageApplication orientéeCalculsParrallel databaseNoSQLNewSQLCEP, ESPHadoopIn Memory
  28. 28. 28© OCTO 2013Hadoop s’impose comme une architecturede référence sur le marché• Apache HadoopOpen Source• Cloudera CDH• Hortonworks• MapRCOTS• Greenplum (EMC)• IBM InfoSphere BigInsights (CDH)• Oracle Big data appliance (CDH)• Teradata (aster)Editeurs• Amazon EMR (MapR)• VirtualScale (CDH)Cloud
  29. 29. 29© OCTO 2013Hadoop et les outils de BI et de Data mining
  30. 30. 30© OCTO 2013Hadoop, un écosystème riche et complexeTraitementMapReduceFramework permettant de traiter des données en parallèleRequêtagePigLangage de flux de donnéesHiveDSL de requêtage « SQL-like »WorkflowOozie / AzkabanWorkflow pour jobs Hadoops dépendantsInfrastructureIntégration au SIFlume, Chukwa, Scribe…Collection de données fiable et résilienteSqoopIntégration RDBMS & HadoopSupervisionPlatform ManagementConsoleHueTraitement distribué avancéMahoutMachine learningHamaBulk Synchronous ProcessingStockageHDFSUn système de fichiers distribué write-once, read-manyHbaseBase de données pour des accès aléatoires read/writeReportingHue BeeswaxInterface web de requêtagePentahoReportingIBM BigSheetsOutil de requêtage
  31. 31. 31© OCTO 2013Répartition des données sur plusieurs machinesRéplication des données pour assurer le « fail-over » : « rackawareness »Hadoop Distributed File System (HDFS)
  32. 32. 32© OCTO 2013Paralléliser et distribuer les traitementsTraiter plus rapidement des volumes de données unitaires plus faiblesCo-localiser traitements / donnéesMapReduce, le système de traitement
  33. 33. 33© OCTO 2013Hadoop est à la fois :Un système de stockage distribué pour les grands fichiersUn système d’agrégation et de traitement parallèle en mode batchà la demande, reposant sur la grille de stockageHadoop n’est pas :Un système d’accès à la donnée unitaire (random access)Un système temps réel, mais batch à la demandeHadoop nécessite des composants externes pour compléter lepuzzleDes outils de visualisation graphique des donnéesUne librairie de traitements statistiques et text mining finaliséeMahout, 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 201310 best practices pourdimensionner et configurer uncluster Hadoop
  36. 36. 36© OCTO 2013Piège 1 : la tentation des machines « monstres de guerre »Piège 2 : le réseau, mieux vaut 10Gb/s c’est plus sûrPiè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 collecterPiège 6 : conserver les paramètres mémoire par défautPiège 7 : conserver la configuration par défaut de HDFSPiège 8 : conserver la configuration par défaut de MapReducePiège 9 : utiliser les formats de fichier par défautPiège 10 : benchmarker son cluster avec TeraSortSommaire
  37. 37. 37© OCTO 2013Le piègeDes ressources inutiliséesUn niveau de parallélisme insuffisantUn surcoût aux performances non garantiesBest PracticePenser parallélisationNotion de conteneur : 1 CPU physique / xGo de RAM / Disque durHDFSDimensionner pour du temps de traitementPiège 1 : la tentation des machines « monstres de guerre »
  38. 38. 38© OCTO 2013Le piègePour garder de bonnes perfs, il faut éviter la sursouscriptionSwitchs de rack plus gros, donc plus cher10Gb/s = 1Go/s = 40Go/s au niveau du switchBackbone encore plus gros, donc encore plus cher40Go/s * <nombre de racks> = ?Best PracticeUtiliser deux cartes 1Gb/s FDMoins de disque sur chaque serveurSuperviserPiège 2 : le réseau, mieux vaut 10Gb/s c’est plus sûr
  39. 39. 39© OCTO 2013Le piègePas de détail sur les métriques internes d’HadoopLectures / écritures de HDFS par nœudConsommation mémoire pendant les étapes d’un jobBest PracticePensez aux développeurs !Utiliser Ganglia pour des métriques finesPiège 3 : pour superviser, mes outils actuels suffisent !
  40. 40. 40© OCTO 2013Le piègeUn petit cluster Hadoop, c’est 10 machinesConfiguration et maintenance à la main difficilePerte de tempsBest PracticeUtiliser un SCMPiège 4 : un SCM ? Pas le temps, SSH fera l’affaire !
  41. 41. 41© OCTO 2013Le piège500 mappers et 20 reducers520 fichiers de logs à collecter sur tout le clusterPeu d’informations utiles à long termeBest PracticePas de collecte sur les slavesCollecte sur les mastersPiège 5 : les logs c’est important, il faut tous les collecter
  42. 42. 42© OCTO 2013Le piègeIls ne sont pas optimisés pour votre clusterSous utilisation des ressourcesÉchecs possibles de certains jobsBest Practice2Go pour les démons tasktracker et datanode4Go pour le démon JobTracker4Go + 1Go par million de bloc pour le namenodeUtiliser 4Go voire 8Go par tâche de map et de reduceSuperviserPiège 6 : conserver les paramètres mémoire par défaut
  43. 43. 43© OCTO 2013Le piègePas optimisée pour un clusterLes paramètres dépendent de vos données, de votre réseau, …Best PracticeConfigurer en pensant I/O vs mémoire vs réseauChaque cas d’utilisation a sa propre configuration optimiséeSuperviserPiège 7 : conserver la configuration par défaut de HDFS
  44. 44. 44© OCTO 2013Le piègePas optimisée pour un clusterLes paramètres dépendent de votre utilisationBest PracticeUtiliser le CapacitySchedulerConfigurer avec des règles de calculAuditer l’usage réel pour optimiser les configurationsPiège 8 : conserver la configuration par défaut de MapReduce
  45. 45. 45© OCTO 2013Le piègeLenteur des jobs dû à un stockage inefficacePlus d’espace utilisé que nécessaireBest PracticeFormat de stockage : distinguer les usagesBase de donnéesDonnées binairesCompression : quelle fréquence d’accès ?Donnée utiliséeArchivagePiège 9 : utiliser les formats de fichier par défaut
  46. 46. 46© OCTO 2013Le piègeNon représentatif de l’usage réel du clusterBest PracticeUtiliser du code de productionPiège 10 : benchmarker son cluster avec TeraSort
  47. 47. 47© OCTO 2013
  48. 48. 48© OCTO 2013© OCTO 2012© OCTO 2013Hadoop CDH4 sous YARN dansles télécoms. Retour dexpérience
  49. 49. 49© OCTO 2013ContexteCaractéristiques du clusterDéroulement du projetDéploiement de HadoopDéploiement des outils supportLes alimentations de donnéesL’analyse des donnéesLa migration du clusterLe benchmark du clusterCluster en fin de missionConclusionSommaire
  50. 50. 50© OCTO 2013Durée : 3 moisEquipe opérationnelle : 8 personnesTrois enjeux majeurs :Construire une plateforme Big Data opérationnelleMontée en compétence des équipesPréconisations pour une plateforme industrielleEquipe colocaliséeContexte
  51. 51. 51© OCTO 20131 rack, 12 serveurs1 nœud pour les outils, 1 autre pour l’anonymisation2 nœuds masternamenode / resourcemanagersecondary namenode8 nœuds slave : datanode et nodemanagerCaractéristiques du clusterSlavesMastersOutilsAccès Masters etOutils
  52. 52. 52© OCTO 2013Déroulement du projet
  53. 53. 53© OCTO 2013Réseau de production : utiliser un mirroir localConfiguration OS : compétences système et réseau requisesUtiliser un SCM pour déployerNécessité d’avoir des profils polyvalentsDéploiement de HadoopA l’attaque!
  54. 54. 54© OCTO 2013Relativement facile une fois Hadoop correctement installéPeu d’impact sur le cluster en lui mêmeNe déployer que le nécessaireDéploiement des outils support
  55. 55. 55© OCTO 2013KISS : Keep It Simple StupidNe pas négliger le travail en amont de l’analyse !Les alimentations de données
  56. 56. 56© OCTO 2013Beaucoup de travail en amontUn cluster s’optimise au contact de la réalitéLimites des outilsAjustement de l’ordonnanceurConfiguration mémoireConfiguration d’HDFSL’analyse des données
  57. 57. 57© OCTO 2013Passage de CDH 4.0.1 à CDH 4.1.2Des leçonsDu travail en amontLe SCM aurait fait gagner du tempsSuivre les préconisations !La migration du cluster
  58. 58. 58© OCTO 2013Initialement en début de projet…Terasort ? Plutôt HiBenchAu final, le travail réalisé pendant le projet a été le meilleurbenchmarkLe benchmark du cluster
  59. 59. 59© OCTO 2013Cluster YARN opérationnelPlusieurs outils testés au cours de l’explorationHDFS occupé à 70% : 1 427 251 fichiers, 280ToLes jobs ne saturent pas complètement le clusterCluster en fin de mission
  60. 60. 60© OCTO 2013Des points positifsYARN : stable et ouvre à d’autres frameworks que Map ReduceDes outils polyvalentsDes points à améliorerMaturité des outils et de leur environnement de travailComplexité de la configuration de Hadoop comme de ses outilsDes documentations et des abaquesMettre en place votre cluster ?une équipe pluri disciplinairede la polyvalence techniqueBilan
  61. 61. 61© OCTO 2013
  62. 62. 62© OCTO 2013© OCTO 2012© OCTO 2013Conclusion
  63. 63. 63© OCTO 2013Use casesCost killerOuvrir le champs des possiblesL’écosystème Hadoop est riche et complexe, enmouvementL’usage a une incidence forte sur l’architecture et laconfigurationConclusion
  64. 64. 64© OCTO 2013Identifiez les use cases métiers applicables dans votre contexte, enbenchmarkant 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 lesplus early adoptersMarketingDistributionTradingRisquesValorisez les résultats du POC en termes métiersDéfinissez une architecture cible de classe industrielle pour généraliserl’approche en réduisant les coûtsComment démarrer cet après midi?
  65. 65. 65© OCTO 2013OCTO et le Big DataUne offre cohérente entre technologie et analyse prédictiveCONSEIL EN SI BIG DATA Etude et positionnement des solutionsen fonction de votre contexte Transformation de SI Décisionnel vers leBig Data Cadrage de projets Big DataARCHITECTURE DES SYSTÈMES BIG DATA POC sur Hadoop et NoSQL Conception et réalisation de systèmessous Hadoop et NoSQL Formation HadoopCONSEIL EN ANALYSE DE DONNÉES AVANCÉES Benchmarks de projets Big Data parsecteur Formation des équipes de dataminingaux techniques Big Data Accompagnent des projets pilotesmétiersCOLLECTE DE DONNÉES EXTERNES Identification de sources de données Collecte et traitements de données nonstructurées Recherche de corrélations économiquesDIRECTION SI DIRECTION MÉTIER

×