Contenu connexe
Similaire à Petit-déjeuner OCTO Technology : Calculez vos indicateurs en temps réel avec storm
Petit-déjeuner OCTO Technology : Calculez vos indicateurs en temps réel avec storm
- 1. Calculez vos indicateursen temps réel En partenariat avec EDF R&D 1 © OCTO 2013
- 2. OCTO et leBig Data Une offre cohérente entre technologie et analyse prédictive DIRECTION SI 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 2 © OCTO 2013 DIRECTION MÉTIER 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 pilote 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
- 3. L’équipe OCTO BigData Analytics Une équipe dédiée, composée de Experts et architectes sur les clusters de stockage et de calcul Statisticiens et consultants en machine learning Une R&D spécifique sur Hadoop, NoSQL et le machine learning Des relations très approfondies avec les équipes R&D de nos partenaires Hortonworks MapR Cloudera 10Gen Mongodb Datastax Cassandra 3 © OCTO 2013
- 4. Intervenants Julien CABOT Directeur BigData Analytics OCTO [email protected] Marie-Luce PICARD Chef de projet EDF R&D [email protected] Benoît Grossin Ingénieur Chercheur EDF R&D [email protected] 4 © OCTO 2013 Rémy SAISSY Architecte OCTO [email protected]
- 5. Agenda Etat des lieuxdu Big Data Les enjeux du Big Data chez EDF par EDF R&D Questions/réponses Retour d’expérience sur une expérimentation d’analyse d’indicateurs en temps réel avec Storm chez EDF R&D Questions/réponses Bilan 5 © OCTO 2013
- 6. Etat des lieuxdu Big Data 6 © OCTO 2013
- 7. Big Data, uneécosystème multiple WEB Google, Amazon, Facebook, Twitter, … Management McKinsey, BC G, Deloitte, … Logiciel IT IBM, Teradata, Vmware, EMC, … Un concept devenant une réalité pour les entreprises françaises 7 © OCTO 2013
- 8. Projets Big Dataen 2013-2014 Le Data mining sur signaux forts et faibles Données exogènes Données issues des infrastructures de production Le dépassement du « mur capacitaire » des appliances décisionnelles Stocker plus pour un coût significativement inférieur Banalisation des technologies de calculs 8 © OCTO 2013
- 9. Big Data, ununivers technologique pour construire des systèmes à haute performance Au-delà de 10 To en ligne, les architectures « classiques » nécessitent des adaptations logiques et matérielles très importantes. Application orientée Flux évènementiel Event Stream Processing Au-delà de 1 000 évènements/seconde, les architectures « classiques » nécessitent des adaptations logiques et matérielles très importantes. 9 © OCTO 2013 Application orientée Au-delà de 1 000 transactions/seconde, les Stockage architectures « classiques » des Stockage adaptations logiques et distribué matérielles très importantes Share nothing Univers « standard » SGBDR, Serveur d’application, ETL, ESB Programmation parallèle Application orientée Calculs XTP Application orientée Transaction Au-delà de 10 threads/Core CPU, la programmation séquentielle classique atteint ses limites (IO).
- 10. Types de solutions Applicationorientée Stockage Parrallel database Stream Processing Base de données Application orientée Flux évènementiel Application orientée Transaction NoSQL NewSQL Hadoop Application orientée Calculs 10 © OCTO 2013 Grid Computing GPU
- 11. Une limite communeaux systèmes informatique! La racine commune à toutes ces limites est le « throughput » des I/O 11 © OCTO 2013
- 12. Le problème :le gain en débit des disques est très en retard par rapport à leur capacité 70 Seagate Barracuda 7200.10 64 MB/s 60 Gain : x100 000 Débit (MB/s) 50 40 Gain : < x100 seulement ! Seagate Barracuda ATA IV 30 Gain : x91 20 IBM DTTA 35010 10 0,7 MB/s 0 1991 1990 12 © OCTO 2013 1996 1998 2001 2006
- 13. Stratégies pour dépasserles limites du troughput Architecture InMemory Architecture en grille • Réduire la latence en utilisant des supports plus rapide (DRAM, SSD) • Paralléliser les accès IO en divisant les volumes (sharding) • Bénéficier de l’évolution des capacités des composants • La limite structurelle n’est pas que déplacée • Pour évoluer, l’architecture doit devenir une grille InMemory • 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 colocalisation des données et des traitements • Permet de scaler à l’infini, c’est le Warehouse scale computing! 13 © OCTO 2013
- 14. Familles de solutionsd’analyse en streaming Complex Event Processing • • • • Solution dédiée au stream processing Pas de capacité de stockage Architecture orientée serveur Options de streaming Streaming Grid In Memory • • • • Base de données In Memory Event triggers Partitionnement Le temps comme une dimension d’analyse HANA • • • • Grille de traitement In memory Event triggers, pub/sub Share nothing sharding Le Temps comme une partie de la clef STORM STREAMS 14 © OCTO 2013
- 15. LES ENJEUX DUBIG DATA À EDF, LE POINT DE VUE D’EDF R&D
- 16. SMART GRIDS SMARTMETERS SMART DATA Partout dans le monde des projets smart-grids voient le jour, motivés par des contraintes économiques ou régulatoires, ou encore par des besoins environnementaux. Avec le développement de nouveaux usages comme le véhicule électrique, avec l’augmentation des moyens de production décentralisée, de nouvelles perspectives apparaissent pour la gestion de l’énergie. Un très grand nombre de compteurs communicants, et plus généralement de capteurs vont être déployés: ils vont | 16 provoquer un déluge de données auquel les compagnies énergétiques vont devoir faire face. •
- 17. SMART METERING: UNDELUGE DE DONNEES En France : 35+ millions de compteurs intelligents des milliards d’enregistrements Actuellement, un projet pilote a déployé 300K compteurs • • | 17
- 18. DONNÉES MASSIVES DANS LEDOMAINE DE L’ ÉNERGIE Enjeux, challenges: Plus de complexité dans le système électrique (production décentralisée, gestion de la demande ….) Multiplication des acteurs Push technologique (compteurs communicants, internet des objets ….) Nécessité d’une bonne traçabilité des actions Le management des données et les nouvelles technologies vont être au cœur des métiers d’EDF EDF R&D SIGMA² | 18
- 19. DONNÉES MASSIVES DANSLE DOMAINE DE L’ ÉNERGIE Qu’y a-t-il de nouveau ? Nouvelles sources de données (données de comptage, données de consommation détaillées, services, données web, open data, …) ‘Digital utility’ : les systèmes physiques s’accompagnent de systèmes numériques (transport, distribution, production), nouveaux acteurs, process de décisions plus rapides Difficultés et opportunités (facile) La technologie est là (difficile) Savoir quoi faire de la donnée? Intégration des données ; Sécurité et privacy; Culture de la donnée; Compétences; comment encourager l’innovation ? Opportunités: voir “Utility AMI analytics for the smart grid” • | 19
- 20. DONNÉES MASSIVES DANSLE DOMAINE DE L’ ÉNERGIE Un volume très important de données à gérer (smart meters, capteurs, …), mais les volumes ne sont pourtant pas si gros Des traitements complexes : Séries temporelles Données distribuées, analyses multi-échelles, niveaux local et global (analytics, optimisation) Temps réel Demain Decision support Integrated communication AMI / smart metering Aujourd’hui | 20
- 21. PROJET DE RECHERCHEÀ EDF R&D : SIGMA² Objectifs : Maîtriser les techniques associées au Big Data, assurer veille/anticipation, développer des méthodes innovantes Poursuivre et renforcer la diffusion et l’intégration de ces approches au sein de l’entreprise • Ces objectifs passent par la réalisation de prototypes, d’études de faisabilité, d’expérimentations en réponse à des problématiques métiers EDF R&D SIGMA² | 21
- 22. POC STORM :ENJEUX POUR EDF R&D Le « Proof Of Concept » (POC) Storm s’inscrit pleinement dans les objectifs de SIGMA² , notamment la maîtrise des technologies Big Data en lien avec le contexte EDF présent ou à venir Les solutions Stream Processing / CEP déjà maitrisées : StreamBase (TIBCO) et InfoSphere Streams (IBM) Objectifs du POC : Mieux connaître Storm et le positionner par rapport aux outils déjà maitrisés Juger de la capacité de Storm à répondre à un scénario riche de « traitements EDF » à la volée sur des données en provenance de compteurs communicants : couverture fonctionnelle ? Capacité à absorber le flux ? EDF R&D SIGMA² | 22
- 23. POC STORM :SCHEMA FONCTIONNEL GLOBAL Data in motion Entrées Smart Metering Data Stream Sorties • Agrégats simples : ex. synchrone globale http://storm-project.net/ •Agrégats ventilés : ex. synchrones par groupe tarifaire Data at rest Prévisions Météo Tarifs statiques / dynamiques •Analytics : ex. scoring par compteur •Prévisions : ex. Prévisions J+1 en Wh et en CA Données clients (par exemple tarif) EDF R&D - SIGMA - FROST | 23
- 24. Focus sur 3points clefs Sorties 1 Smart Metering Data Stream DATA • Agrégats simples : ex. synchrone globale 10 5 0 1 229 457 685 913 1141 1369 1597 1825 2053 2281 2509 2737 2965 3193 3421 3649 3877 4105 Data in motion Entrées Prévisions Météo Data at rest ANALYTICS Tarifs statiques / dynamiques FORECASTING •Agrégats ventilés : ex. synchrones par groupe tarifaire 2 •Analytics : ex. scoring par compteur 3 •Prévisions : ex. Prévisions J+1 en Wh et en CA Données clients (par exemple tarif) EDF R&D - SIGMA - FROST | 24
- 25. 1- DATA :SIMULER MASSIVEMENT ET FIDELEMENT LES COURBES DE CONSOMMATION ELECTIQUE Utilisation d’un générateur / simulateur de courbes de charges électrique, développé par EDF R&D Consommations individuelles réelles Consommations individuelles simulées Modèle génératif Apprentissage Utilisations possibles : Simulation • CARACTERISTIQUE DU GENERATEUR : •Conserver la diversité des comportements individuels •Reproduire des courbes ayant une volatilité comparable aux courbes réelles •Conserver le comportement global de l’agrégation des courbes individuelles • sans paramètres utilisateurs •Simuler rapidement de gros volumes de données • Tester des outils informatiques et des méthodes statistiques Echanger des données simulées EDF R&D - SIGMA - FROST | 25
- 26. 1 - DATA: EXEMPLES DE COURBES INDIVIDUELLES GENEREES Performance du processus de génération : Code JAVA CPU 2 GHz (Xenon E5405) 360.000 tuples / seconde / CPU 1 CPU = 18 x plus rapide que le temps réel (35 M de compteurs, au pas demi-horaire) | 26
- 27. 2 – ANALYTICS: TRAVAILLER SUR DES SERIES TEMPORELLES SIMPLIFIEES Les Séries temporellessont des données de forte dimentionnalité, difficile à exploiter dans un contexte Big Data Notre approche ici : SIMPLIFIER l’objet « Courbe de Charge » pour faciliter sa manipulation et son analyse, surtout quand on travaille avec plusieurs millions de séries temporelles SAX : Passer d’une série de mesures à un mot plus compact Ensuite, nous utilisons cette forme plus simple pour « scorer » chaque courbe selon que la forme de la courbe est plus ou moins commun dans l’ensemble de la population Principe de la transformée SAX EDF R&D - SIGMA - FROST | 27
- 28. 3 – FORECASTING: LES MODELES GAM GAM = Generalized Additive Model Modèles étudiés depuis 2006 à EDF R&D (Dépt. OSIRIS) et à EDF depuis quelques années Utilisés sur de nombreux signaux : consommation Electrique au niveau agrégé et niveau local, consommation de Gaz, … Structure très générique: Fonction de transferts linéaires ou non-linéaires Effets mono ou multi-varies Littérature scientifique sur le sujet: Hastie and Tibshirani (1986), Hastie and Tibshirani (1990), plus récemment Wood (2006) EDF R&D - SIGMA - FROST | 28
- 29. 3 – FORECASTING: EXEMPLE DE MODÈLE GAM • Le Département OSIRIS utilise R pour la modélisation GAM EDF R&D - SIGMA - FROST | 29
- 30. Questions / Réponses 30 ©OCTO 2013
- 31. Retour d’expérience surune expérimentation d’analyse d’indicateurs en temps réel avec Storm chez EDF R&D 31 © OCTO 2013
- 32. Sommaire Contexte Présentation de Storm Déroulementdu projet Méthodologie de travail Choix de l’architecture Déploiement de Storm Fonctionnalités implémentées Spécificités et limites d’une implémentation Storm Tests de performances Bilan 32 © OCTO 2013
- 33.
- 34. Contexte Durée : 3mois, entre Juillet et Septembre 2013 Client : Le projet SIGMA² de EDF R&D Sujet : Etude du positionnement des solutions CEP dans un contexte Hadoop Performance et la scalabilité de Twitter Storm Equipe : 3 OCTOs Traitements à réaliser : Agrégats en temps réel par dimension géographique, tarifaire sur la base des attributs attachés aux courbes de charges Scoring en temps réel, basé sur des règles en partie définies à l’avance et en partie évolutives Prévisions de charge basées sur des fonctions R développées par EDF R&D Développement d’une interface de restitution 34 © OCTO 2013
- 35. Contexte Les moyens logicielset humains fournis par EDF R&D Des moyens humains en support 2 experts système & réseaux 2 experts métiers pour le scoring et le modèle de prédiction R L’auteur du générateur de relevés de consommation Du logiciel fourni Un générateur réaliste de relevés de consommation Des modèles de prédictions fixes et adaptatifs ainsi que des codes source en R les exploitant Des CSV contenant des données de références Jointures groupe tarifaire / compteur Données météo Des codes sources d’exemple D’utilisation du générateur de relevés de consommation D’implémentation de SAX 35 © OCTO 2013
- 36. Contexte Caractéristiques du cluster 8serveurs « commodity » 2 noeuds maître CPU : AMD Opteron Processor 6128 Mémoire : 64Go Réseau : 1Gb/s 6 noeuds de traitement CPU : AMD Opteron Processor 6128 Mémoire : 32Go Réseau : 1Gb/s Autres caractéristiques co-localisation sur le même rack Livrés installés avec une distribution CentOS 64bits Accès réseau limité en dehors du centre R&D Accès total de l’équipe sur le cluster 36 © OCTO 2013
- 37. Présentation de Storm 37 ©OCTO 2013
- 38. Présentation de Storm Stormest une solution de traitement de données orientée flux Caractérisques principales de Storm Garantie de traitement des données Scalabilité horizontale Tolérance aux pannes et transactionnalité Pas d’intermédiaire Abstraction plus haut niveau que le message passing Robustesse Traitement de Flux 38 © OCTO 2013 RPC Distribués Calcul en continu
- 39. Présentation de Storm Conceptsde Storm 39 © OCTO 2013
- 40. Présentation de Storm Trident Abstractiontransactionnelle sur les bolts et les spouts Traitement par mini-batchs de N tuples Garantie de traitement ordonné des mini batchs Facilite les calculs d’agrégation 40 © OCTO 2013
- 41. Déroulement du projet 41 ©OCTO 2013
- 42. Méthodologie de travail Uneméthodologie itérative Pourquoi ? Peu de temps pour tout réaliser 3 sujets dans le projet Comment ? Notre storyboard Equipe Co-localisée Backlog priorisé Réunion d’avancement et démo hebdomadaire Notre lieu de débats 42 © OCTO 2013
- 43. Méthodologie de travail Unprojet varié Backlog : 60% des tâches réalisées 55 identifiées, 33 priorisées et réalisées 43 © OCTO 2013
- 44. Choix de l’architecture DataFlowfonctionnel DONNÉES • Relevés de compteurs EDF (générateur) • 48 points de mesures en KWh par jour et par compteur • 6 millions de compteurs • Les compteurs sont segmentés par groupe tarifaire 44 © OCTO 2013 ACQUISITION ET TRAITEMENT Calcul de métriques en continu, par jour et par groupe tarifaire : • Moyenne de consommation • CA • Prévision pour les métriques précédentes à J+1 • Scoring typicité des courbes compressées par SAX REQUETAGE • Vues pré calculées par agrégat disponibles au requêtage • Agrégation des vues en agrégats plus grands • Affichage en tableaux de bords (courbes, histogrammes)
- 45. Choix de l’architecture Architecturetechnique Interface de Suivi de restitution Questionne la topologie à la demande (DRPC) Utilisateurs Calculs d’agrégats Calcul de scores Calcul de Prévisions TridentState TridentState TridentState Tables de référence Topologie de calcul Storm Générateur 42,63…2,0…24…1,0484,… 45 © OCTO 2013 Envoi du stream aux différents TridentStates Les données générées sont • regroupées par compteur et par jour (tuple) • ajoutées sur une liste Redis Récupère des mini batchs Stockée sur chaque serveur en CSV Spout A intervalle régulier, les Spouts lisent entre 500 et 10000 tuples chacun de la liste Redis
- 46. Déploiement de Storm Composantsinstallés Storm Nimbus DRPC UI Supervisor(s) Zookeeper Support Redis Tomcat Outils de dev : nexus, gitolite 46 © OCTO 2013
- 47. Déploiement de Storm Vuephysique du cluster Rack 1Gb/s intra rack Nœud maître • • Storm • Nimbus • UI • Drpc Tomcat Nœud maître • • • Storm supervisor Redis Zookeeper Nœuds de traitement • Storm supervisor 47 © OCTO 2013 Réseau 10Gb/s Développeurs et Utilisateurs
- 48. Fonctionnalités implémentées 3 traitementsà implémenter Calcul d’agrégats de consommation journalière par groupe tarifaire et national Calcul des scores du degré de typicité des consommations Par compteur et par jour Calcul des prévisions J+1 de consommation par groupe tarifaire et national Sur chaque agrégat disponible 48 © OCTO 2013
- 49.
- 50. Fonctionnalités implémentées Calculs descores de normalité des relevés 50 © OCTO 2013
- 51. Fonctionnalités implémentées Calculs deprévisions pré-calibrées 51 © OCTO 2013
- 52. Fonctionnalités implémentées Calculs deprévisions adaptatives 52 © OCTO 2013
- 53. Fonctionnalités implémentées Interface derestitution des moyennes de consommation avec prévision 53 © OCTO 2013
- 54. Fonctionnalités implémentées Interface derestitution du nombre de métriques collectées 54 © OCTO 2013
- 55. Spécificités d’une implémentationsur Storm Implémentation de calculs sous une forme distribuée La nature distribuée de Storm rend parfois des algorithmes relativement « simples » difficiles à implémenter : Les streams imposent de calculer de manière incrémentale Trident, la couche transactionnelle de Storm impose primitives particulières Spécificités d’utilisation de R avec jRI 55 © OCTO 2013
- 56. Limites constatées del’implémentation sur Storm L’interface de Storm fourni les métriques de latence mais… D’autres composants entre en jeu (Zookeeper, Redis, …) Cela rend la mesure de performance globale et fiable (traitements + comportement du cluster) difficile 56 © OCTO 2013
- 57. Tests de performances Sourcede données Une journée / compteur 48 relevés de consommation par compteur et par jour + identifiant compteur 300 octets de taille moyenne Jeux de données pré-générés Consommation de 1 million de compteurs sur 2 jours Consommation de 6 millions de compteurs sur 2 jours 57 © OCTO 2013
- 58. Tests de performances Performancesen lecture de Redis 413 850 journées / compteur / seconde 19 864 800 relevés / seconde En terme réseau : 120Mo / seconde (max 125Mo/s) A titre de comparaison, un macbook pro SSD 16Go DDR3 obtient : 791 565 journées / compteur / seconde soit une augmentation de 47% 58 © OCTO 2013
- 59. Tests de performances Calculsd’agrégats 4m5s pour traiter 576 millions de relevés 1,98 million de relevés / seconde Les machines n’étaient pas surchargées : charge CPU < 50% Nombre de relevés émis Temps de traitement 59 © OCTO 2013
- 60. Tests de performances Calculsde scores de normalité des relevés 5m27s pour traiter 180 millions de relevés 550 458 relevés / seconde Nombre de relevés émis Temps de traitement 60 © OCTO 2013
- 61. Tests de performances Calculsde prévisions pré-calibrées 4m23s pour traiter 576 millions de relevés 2,19 millions de relevés / seconde Les machines du cluster n’étaient pas surchargées : charge CPU < 50% Nombre de relevés émis Temps de traitement 61 © OCTO 2013
- 62. Tests de performances Calculsde prévisions adaptatives 6m41s pour traiter 576 millions de relevés 1,43 million de relevés / seconde Les machines du cluster n’étaient pas surchargées : charge CPU < 50% Nombre de relevés émis Temps de traitement 62 © OCTO 2013
- 63. Questions / Réponses 63 ©OCTO 2013
- 64.
- 65. Bilan Sur Storm Points positifs Traitementde gros volumes au fil de l’eau Prévisions en quasi temps réel avec R Facile à mettre en œuvre, à configurer Polyvalent Jeune, pourtant bien documenté et stable Points à creuser Mesure de performances Reprise sur erreur de traitements Intégration dans Hadoop 65 © OCTO 2013
- 66. Bilan Storm dans uneperspective industrielle Hadoop est adapté en traitements batchs mais mauvais en temps réel Storm est adapté en temps réel mais n’a pas de couche de stockage de big data 66 © OCTO 2013
- 67. BILAN POC STORMPAR EDF R&D Points positifs : Solution crédible, qui couvre le spectre fonctionnel du scénario proposé Coût , renforcé par l’intégration de Storm dans Hadoop (HDP Q1 2014) Points négatifs : Nécessité de s’investir dans un nouvel outil, avec sa logique et sa syntaxe NB : trident offre cependant un niveau d’abstraction intéressant Manque d’un studio de développement (cf. Streambase) Ex : visualiser le graphe de traitements Suite envisagée : Prototype STORM d’un système d’estimation temps-réel des volumes d’effacements électrique • EDF R&D SIGMA² | 67
- 68. Remerciements L’équipe côté EDF AlexisBONDU – Ingénieur chercheur, auteur du générateur Bruno JACQUIN – Ingénieur chercheur Charles BERNARD – Consultant IT Leely DAIO PIRES DOS SANTOS – Ingénieur chercheur Yannig GOUDE – Expert prévision L’équipe côté OCTO Simon MABY – Consultant Cyrille MAILLEY - Consultant 68 © OCTO 2013
- 69.
Notes de l'éditeur
- #43 3 sujets :Infra : Mise en place du clusterBackend : développement des analyses en StormFrontend : développement d’une interface de restitutionComment ?Co-localisation de l’équipeManagement visuel, Proximité avec les experts EDFMise au point et priorisation d’un backlogRéunion d’avancement et démo hebdomadaireOn y aborde les réussites et les points bloquantsOn y valide le travail réaliséOn y ajuste le backlog pour la semaine suivanteObjectifsPermettre à EDF de suivre facilement l’avancementFavoriser les échanges en directEviter les blocages, les non ditsApprendre à marcher ensembleToute l’équipe s’approprie le projet et en comprend mieux les tenants et aboutissantsGarde la motivation !
- #49 Calcul d’agrégats de consommation journalière Agrégats calculés-Synchrones-Moyennes de consommation-CA-Nombre de compteurs acquisCalcul des scores de normalité des compteursAlgorithme SAX fourni par EDFCalcul des prévisions de consommation Modèle GAM pré-calibréModèle GAM adaptatif-Visualisation dans l’interface de suivi -Par groupe tarifaire et national -Par compteur -Entre deux dates