Big Data: noSql, Map Reduce, RDBMS - Quoi utiliser et quand ?

Transcript

1. !   Romain Chaumais – romain.chaumais@ysance.com Directeur du pôle Business Intelligence Big Data : noSql, Map&Reduce, RDBMS Quoi utiliser et quand ?
2. Les origines du phénomène Big Data
3. Big Data ? + 1 203 900 000 164 500 000 1 368 400 000 Le nombre de transactions aux péages des autoroutes de France en 2010 41,5M de véhicules / 84,1Mrd de Km
4. Evolution d’un péage autoroutier Analogique Anonyme Product Centric
5. Vers un télépéage et le Big Data Numérique Historisé et analysé Customer Centric
6. L’ampleur du déluge de données ! Plus de 1 million de transactions clients / heure ! 2 500 To de données en base !  500 millions de visiteurs / jours !  50 milliards de photos stockées !  90 milliards de contenus partagés chaque mois !  7,2 milliards de pages vues / jour !  88 milliards de recherches / mois !  20 Po de données traitées / jour Web-Scale
7. Volume de données •  Démarré en 2000 •  En quelques semaines, a collecté plus de données que dans toute l’histoire de l’astronomie •  A ce jour, a généré plus de 160 To de data archivées Sloan Digital Sky Survey - Nouveau Mexique
8. Volume de données •  Démarrera en 2016 •  Génèrera plus de 160 To de data en ... Large Synoptic Survey Telescope - Chili 4 jours !!
9. 9 Raw Data ? B
10. Raw Data = Plus d’explorations
11. Qui aujourd’hui produit et consomme la donnée ? Human generated data Machine generated data
12. Big Data : Proposition de définition La règle des 3 V Volume Vélocité Variété Collecte & stockage d’un grand volume de données Intégration, traitement et restitution en temps limité Données structurées mais aussi non structurées (texte, audio, vidéos, click streams, log files, etc.
13. Exemples de projets Big Data
14. Exemples Map & Reduce
15. Exemple projet Big Data Ysance •  Casual Game consistant à échanger des objets avec ses amis ! 1,3 millions de joueurs mensuels •  Analyse des interactions entre les joueurs et leurs amis ! Analyse du graphe social des joueurs ! Catégorisation des joueurs selon le nombre d'amis jouant aussi à IsCool •  Mise en place d'un parcours de jeux personnalisé selon le nombre d'amis ! Objectif : Avoir au moins 10 amis avec qui jouer à IsCool •  >> Multiplication du CA
16. VSC : CHALLENGE TECHNO POUR UNE PROMESSE BUSINESS ! Comment  offrir  plus  d’usage  B2C  aux  clients  sur  un  legacy  limité  au  B2B  ?     Des  clients  qui  exprimaient  leur  mécontentement     «  trop  d'informa.ons  "accrocheuses",  décalage  avec  ce  que  l'on  trouve   ensuite.\je  trouve  rarement  un  trajet  en  promo.on  à  par.r  de  ma  ville   (Tours  )  »       «  J'aDendais  de  pouvoir  avoir  un  tarif  très  avantageux  avec  une  date   libre  en  complétant  simplement  départ  et  arrivée  du  train  ou  autre   mode  de  locomo.on  choisi.  »  
17. Calendrier des prix : projet Big Data •  Voyages-sncf : Calendrier des prix Volume Vélocité Variété
18. Comment le Big Data peut-il créer de la valeur ? •  En apportant de la transparence et la suppression des silos de données •  En simplifiant l’exploration des données, l’expérimentation, la compréhension de phénomènes, l’identification de nouvelles tendances : Data discovery / Data visualization •  En permettant la mise en place d’un CRM hyper segmenté tendant vers du One-To-One •  En offrant une véritable aide à la décision via des algorithmes riches exécutés automatiquement : Datamining / prédictif •  En devant le socle actif de nouveaux produits, services et Business modèle orientés données
19. Paysage Big Data / No SQL
20. Les problématiques du Big Data Capturer / Acheminer Stocker / Organiser Traiter / Consolider Partager / Sécuriser Analyser / Visualiser
21. Des acteurs du Big Data MS  PowerPivot  
22. Classification des « bases de données » The CAP Theorem Source : http://blog.nahurst.com A P C Partition tolerance means that the system works well across physical network partitions Consistency means that each client always has the same view of the data Availability means that all clients can always read and write Pick only 2 CA AP CP •  RDBMSs (Oracle, SQLServer, MySQL) •  Teradata, Exadata, Netezza, Fast Track •  Vertica, Greenplum, InfiniDB •  Azure Table Storage •  BigTable, Hypertable, Hbase, •  Hive, Aster Data •  MongoDB, Terrastore •  Scalaris, Berkeley DB, MemcacheDB •  Redis, Scalaris •  Dynamo, Voldemort, Tokyo Cabinet, KAI •  SimpleDB, CouchDB, Riak •  Cassandra, Data Models •  Relational •  Relational MPP •  Key - Value •  Column Oriented / Tabular •  Document Oriented Big Data : architecture alternative
23. Classification des moteurs de traitement des données de type Big Data Moteur spécialisé Appliance MPP Framework Map & Reduce Performance  /  CPU   + _ Volume  de  données  traitées   + _ Structura:on  des  données   + _
24. Hadoop : Plate-forme Big Data de référence •  Hadoop : HDFS + MapReduce = Stockage + Traitement •  Historique d’Hadoop : ! Inspiré de Google Map Reduce - Première version en 2008 (Yahoo) ! Projet de la fondation Apache. Version 1.0 en janvier 2012. ! Utilisateurs : Yahoo, Facebook, Tweeter, LinkedIn, eBay, etc. •  Hadoop : Leader des solutions de MapReduce Natives Hadoop Dérivées Hadoop Autres BIGDATA
25. L’écosystème Hadoop = Distribution Data Integration layer Flume   Sqoop   Log  Data   RDBMS   File Data Row / Column HBase MR : Distributed Data Processing HDFS : Distributed File System API  HBase   Advanced Query Engine (Hive, Pig, Cascalog…) Data Mining Index / search ODBC / JDBC Mahout   Pegasus   Lucene   SolR   Hive     Add-­‐In   ZooKeeper   Oozie   Hue   Orchestration, Administration, Monitoring, Security Cluster : CPU / RAM / Disk / Network Fuse   File  System   OS + JVM Transac:ons   Distribution Hadoop Principal élément de différenciation entre les distributions
26. Architectures Big Data
27. En complément ou en remplacement du SID traditionnel ? Le Big Data en complément de la BI traditionnelle Le Big Data en remplacement de la BI traditionnelle
28. Comment résoudre cette équation ? Serveurs Web Base opérationnelle Serveurs applicatifs Serveurs Web Analytics Données opérationnelles Logs Transactionnels Clics Streaming Email / Marketing automation Web Analytics Emailing tracking CRM / MDM Historiques / Données référentielles DWH   Applica:ons  décisionnelles   Mobile / Média sociaux Géoloc / feeds
29. Architecture de type Big Data Text files Archives J-N Stockage réseau haute disponibilité API Traitements massivement parallèles BI traditionnelle Données agrégées BI « Big Data » Données brutes Usages « temps réel » Sources de données Search / Indexation
30. Cas client : Dans le monde du jeu
31. L’existant 31 Job Talend Input Logs Base Pivot MySQL Game Server Game Server Game Server
32. Problématique •  Problème de montée en charge avec la volumétrie effective ! L’augmentation des volumes de données sources dépasse les prévisions ! Ces volumes engendrent des problèmes bloquants de performance sur les calculs d’agrégation des indicateurs de type « patrimoine » ! Nécessité de désactiver des agrégations (18%) afin de retrouver des performances acceptables ! Les optimisations « standard » ont été réalisées, mais elles ne permettent pas de résoudre les problèmes (qui vont s’aggraver) 32
33. Basculer sur une architecture de rupture type « Big Data » 33
34. SGBD colonnes : Objectifs •  S’appuyer sur un moteur de base de données taillé pour des grands volumes de données et des usages analytiques ! Le stockage des données en colonnes permet un très haut niveau de compression des données et accélère les requêtes de type agrégation ! Les performances attendues devraient être très supérieures à celles de MySQL 34 Job Talend Input Logs Pivot New SGBD
35. Sharding : Objectifs •  Bâtir une plate-forme de type Scale Out ! Gérer la montée en charge consiste à ajouter de nouveau nœuds à la plate-forme ! Chaque nœud est techniquement identique et autonome en données ! Le sharding permet d’augmenter la tolérance aux pannes ! Le sharding est indépendant de la base de données 35 Job Talend Sharding Pivot #1 Job Talend Traitement Server #1 Input Logs Pivot #n Job Talend Traitement Server #n Job Talend Consolidation Pivot Full . . .
36. MapReduce : Objectifs •  Apport de MapReduce : calculs parallélisés et distribués ! Changer l’approche et la méthode de calcul des agrégats complexes ! Linéariser la montée en charge ! S’appuyer sur le parallélisme et la distribution via AWS 36 Job Talend Sharding Pivot Job Talend agreg. simples Input Logs Server MR Job Talend Update Job MapReduce agreg. complexes
37. Combination des techniques 37 Job Talend Sharding Pivot #1 Job Talend Traitement Server #1 Input Logs Pivot #n Job Talend Traitement Server #n Job Talend Consolidation Pivot Full . . . Server MR Job MapReduce agreg. complexes
38. Merci