• Save
OCTO 2012 : l'analyse décisionnelle en temps réel - BigData, Complex
Upcoming SlideShare
Loading in...5
×
 

OCTO 2012 : l'analyse décisionnelle en temps réel - BigData, Complex

on

  • 1,630 views

Le pilotage des activités opérationnelles devrait pouvoir se faire au rythme du business et avec une connaissance précise de son état courant. ...

Le pilotage des activités opérationnelles devrait pouvoir se faire au rythme du business et avec une connaissance précise de son état courant.
La lutte contre la fraude, l’analyse des parcours clients en temps réel ou le suivi des liquidités permettent d’améliorer vos profits et demandent une analyse complexe instantanée sur d’importants volumes d’évènements.
Ces nouveaux usages en matière d’analyse des flux de données introduisent de nouveaux défis techniques et d’architecture des SI : comment faire converger analyse temps réel et gestion de volume de données important ?
Les évolutions des marchés du Décisionnel et du CEP permettent d’y apporter aujourd’hui des réponses concrètes. Des solutions sont déjà opérationnelles dans différents secteurs : finance, telecoms, logistique, e-commerce, …
OCTO Technology et Quartet FS vous proposent de découvrir les nouvelles opportunités métiers liées à ces évolutions technologiques, positionner ces nouvelles architectures dans vos SI et les possibilités de ActivePivot Sentinel.

Statistics

Views

Total Views
1,630
Views on SlideShare
1,630
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OCTO 2012 : l'analyse décisionnelle en temps réel - BigData, Complex OCTO 2012 : l'analyse décisionnelle en temps réel - BigData, Complex Presentation Transcript

  • L’analyse décisionnelle en temps réel Convergence entre Big Data et Complex Event Processing
  • Agenda Introduction aux enjeux d’analyse de données en temps réel Présentation des architectures d’analyse de données en temps réel Présentation de la solution Open Source ESPER Présentation de la solution ActivePivot Sentinel, de Quartet FS Questions/réponses 2
  • Présentation OCTO et Quartet FS • OCTO est un cabinet de conseil en  Quartet FS est un éditeur de Système d’Information et en logiciels Technologie  Créé en 2005 par 4 • 150 consultants et architectes, basés entrepreneurs, ayant chacun plus de à Paris 20 ans d’expériences dans les salles • Missions de marché financières  Expertise en architecture  Delivery de projets clef en main (BA+Dev)  A développé ActivePivot™, une  Conseil en stratégie SI solution innovante d’analytique en • 6 business units : temps réél • Banque • Capital Markets • Assurance  Est présente à travers le monde: • Industrie − Paris avec le centre de R&D • Télécoms/Services − Londres • Media/Internet − New York • 20% de budget R&D, éligible au CIR − Singapour© OCTO 2011 3
  • Introduction aux enjeux de l’analyse de données en temps réel Julien Cabot, Associé OCTO jcabot@octo.com
  • Qu’est ce que l’analyse de données en temps réel? Définition  « Un système d’analyse de données temps réel est un système évènementiel disponible, scalable et stable capable de prendre des décisions (actions) avec une latence inférieure à 100ms » Pourquoi est-ce différent de l’analyse de données « traditionnelle »?  L’analyse de données repose traditionnellement sur une architecture de bases de données relationnelle : • Base décisionnelle – La recopie des évènements dans une base dédiée via un ETL ou ESB traditionnel ne permet pas de répondre à l’exigence de latence • Base opérationnelle – L’augmentation du nombre de transactions/seconde (TPS) augmente le temps de réponse autour de 1 000 TPS sur un SGBD type Oracle, SQLServer, etc – Au-delà de 1 000 TPS, des optimisations significatives sont nécessaires pour conserver la latence : mise en place de caches, modélisation des données, configuration serveurs, SSD, Eléments réseaux • Les SGBD actuels plafonnent autour de 4 500 TPS (source TPC.ORG) sur des configurations optimisées.  La prise de décision ne peut donc pas se prendre dans le système de stockage des données au-delà de 1000 TPS (opérations + analyse)© OCTO 2012
  • Quels intérêts pour les entreprises? Les entreprises qui doivent opérer des systèmes critiques sont déjà aujourd’hui confrontés à cette problématique  Capital Markets  Télécoms  Transport  Grandes distributions,  E-Commerce  « Grands » du Web (Google, Amazon, Paypal, etc.)  Online gaming  Gouvernement  Défense De nouveaux drivers, qui vont augmenter le nombre d’évènements, apparaissent  Multiplication des devices connectés : smartphone, tablette, tv connectée, véhicule connecté, RFID, NFC, …  Fusion des poches utilisateurs : la mutualisation des SI multi-pays, fusion de lignes d’activités, modèle marque blanche, …  Volatilité du rythme des opérations métiers généré par la volatilité du trafic sur les plateformes internet et l’évolution du climat des « affaires » Le pilotage opérationnel au rythme de vie du « business » devient une problématique pour une population d’entreprise plus large© OCTO 2012
  • Illustrations par des cas d’utilisation Souscription en ligne Recouvrement Optimisation de de la d’OPCVM amiable trésorerie Multicanal Web, Mobile Utilisation des données Optimisation du coût de pour une société sociales pour un refinancement pour une d’Assurance-Vie établissement de Crédit Banque d’investissement Conso • L’enjeu est d’amener l’internaute • L’enjeu est de traiter le défaut en • L’enjeu est d’optimiser le P&L de au processus de souscription amiable, et non en contentieux la banque en diminuant son coût • Le remarketing dans une de refinancement en • L’analyse des données sociales devises, directement au niveau plateforme de souscription en ligne lors du recouvrement permet nécessite de corréler dans le salle de marché d’améliorer significativement le temps des évènements unitaires recouvrement amiable auprès des • L’analyse des cashflows et des en nombre important (click, temps populations jeunes traces de pricing front office passé sur les pages, simulation permet de simuler les besoins faite, actualités, etc.) • L’analyse des flux provenant des futurs en liquidité à une date réseaux sociaux complète de donnée et de déterminer l’impasse • La plateforme concentre un flux manière efficace les outils d’aide d’évènements importants car elle dynamique stressée associée au recouvrement amiable concentre les canaux • La plateforme concentre les flux Web, Mobile, tablette et la • Les flux à analyser sont très des activités de pricing des distribution en marque blanche nombreux et augmentent activités de la banque sur une géométriquement avec le nombre unique plateforme d’analyse de la de dossiers à recouvrer consommation de la liquidité© OCTO 2012
  • Pourquoi le CEP est une opportunité pour l’analyse des données en temps réel? Les technologies de Cache arrivent rapidement à leurs limites, car la gestion de la synchronisation mémoire-stockage devient elle-même limitante  Les exemples de diminution de performance sur des caches type Hibernate sont fréquents  La prise de décision implique des requêtes complexes : corrélation dans le temps, comparaison multidimensionnelle, scoring, … Qu’est ce que le Complex Event Processing (CEP)?  Le CEP est une technique permettant de manipuler des ensembles dévénements au fur et à mesure de leur prise en compte, didentifier des relations entre ces événements (corrélation, causalité, patterns), et den tirer de linformation sous forme de nouveaux événements dits "dérivés" ou "complexes".  Cette approche au fil de leau implique un traitement principalement en mémoire, afin de satisfaire les contraintes de latence et de débit de traitement des événements dentrée.  Le stockage des évènements est réalisé a postériori de leurs traitements Le coût d’accès à la technologie diminue rapidement depuis 3 ans, avec l’apparition de nouveaux acteurs© OCTO 2012
  • La convergence entre Big Data et CEP dans l’analyse des données en temps réel Une augmentation importante des données  Volume d’évènements à stocker  profondeur historique Complexité d’analyse  Règles métiers  Multi-dimensionnelle  Pattern matching CEP  Géographique Analyse des  Non structuré – langage naturel données en  Machine learning/data mining temps réel Nouvelles sources de données Big Data  Données sociales  Données peu structurées Expérimentation  Les règles de décision ne sont pas connues a priori  Simulation, What-if  Back testing, stress testing© OCTO 2012
  • L’Analyse de données en temps réel Complexité d’analyse OLAP CEP Fréquence d’analyse SGBDR Volume© OCTO 2012
  • L’Analyse de données en temps réel Complexité d’analyse Quelle souche utilisée pour construire un système d’analyse de données de grande capacité? Hadoop CEP Fréquence d’analyse SGBDR Volume© OCTO 2012
  • Analyse de données en temps réel Architecture Enjeux Approches et outils© OCTO 2012
  • Traitement évènementiel à faible latence latence : 100 msévènementsstructurés Capture Applis décision / Moteur évènementiel transactionnelles, action BPM, ESBévènementsnon-structurés © OCTO 2011 13
  • Traitement en mémoire latence : 100 msévènements Moteur CEPstructurés Calculs et état en Capture Applis mémoire : décision / transactionnelles, fenêtres de temps, action BPM, ESB opérateurs, règlesévènementsnon-structurés © OCTO 2011 14
  • Fonctionnalités de traitement des évènements latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés © OCTO 2011 15
  • Analyse et décision s’inscrivent dans un contexte latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Données de référence, DWH, © OCTO 2011 interrogation de services 16
  • Historisation des évènements latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 17
  • IHM d’analyse de données IHM données historiques IHM données temps-réel latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 18
  • Edition des régles IHM édition des règles IHM données historiques IHM données temps-réel latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 19
  • Enjeux technologiques© OCTO 2011 20
  • Enjeux technologiques IHM édition des règles IHM données historiques IHM données temps-réel Enjeux : - Gestion de la latence ( < 100 ms ) - Débit ( 10’000 msg / sec ) latence : 100 ms - Consommation mémoire Moteur CEP - Répartition sur plusieurs nœudsévènementsstructurés Event/Condition/Action Calculs et état en - Reprise sur panne Capture Stream-based querying Applis mémoire : décision / - Reprise de l’état transactionnelles, fenêtres de temps, action opérateurs, règles - Quid des évènements perdus ? BPM, ESB Analyse multi-dim. …évènementsnon-structurés - Initialisation à partir de l’historique Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 21
  • Enjeux technologiques IHM édition des règles IHM données historiques IHM données temps-réel Enjeux : latence : 100 ms Moteur CEPévènements - Débit ( 10’000 msg / sec )structurés Event/Condition/Action Calculs et état en Capture - Reprise sur :panne : rejeu de Stream-based querying Applis mémoire décision / transactionnelles, messages ? fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 22
  • Enjeux technologiques IHM édition des règles IHM données historiques IHM données temps-réel latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règlesEnjeux : …évènementsnon-structurés - Grande capacité - Performance en écriture Cache / Cache distribué - Performance des requêtes sur données historiques - Modélisation flexible Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 23
  • Enjeux technologiques IHM édition des règles IHM données historiques IHM données temps-réel latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Enjeux : Cache / Cache distribué - Performance en lecture pour respect de la latence - Bonne gestion du cache Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 24
  • Enjeux technologiques IHM édition des règles IHM données historiques IHM données temps-réel latence : 100 ms Enjeux :évènements Moteur CEPstructurés - IHMs dynamiques Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : - Exploration des données/selon décision transactionnelles, fenêtres de temps, opérateurs, règles des axes, des critèresaction Analyse multi-dim. BPM, ESB …évènementsnon-structurés - IHM temps réel : évènementielle type « web-push » Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 25
  • Enjeux technologiques IHM édition des règles IHM données historiques IHM données temps-réel Enjeux : - « WYSIWYG », utilisable par les métiers latence : 100 ms - Modification de règles à chaudévènements Moteur CEPstructurés - Backtesting Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 26
  • Approches et outils© OCTO 2011 27
  • Approches technologiques Complexité d’analyse  CEP OLAP  Grilles de stockage de données en mémoire Fréquence (datagrid) CEP d’analyse SGBD R  OLAP en mémoireVolume © OCTO 2012 28
  • Approche « CEP » IHM édition des règles IHM données historiques IHM données temps-réel latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 29
  • Approche « Datagrid » IHM édition des règles IHM données historiques IHM données temps-réel STORM latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 30
  • Approche « In-memory OLAP » IHM édition des règles IHM données historiques IHM données temps-réel latence : 100 msévènements Moteur CEPstructurés Event/Condition/Action Calculs et état en Capture Stream-based querying Applis mémoire : décision / transactionnelles, fenêtres de temps, Analyse multi-dim. action BPM, ESB opérateurs, règles …évènementsnon-structurés Cache / Cache distribué Historique des Données de référence, DWH, évènements © OCTO 2011 interrogation de services 31
  • Take away Paradigme nouveau pour le décisionnel : « évènementiel + traitement mémoire »  de nouvelles architectures pour l’analyse de données, en interaction forte avec le SI Des approches technologiques variées, à adapter au besoin, et émergence de nouveaux acteurs© OCTO 2012 32
  • Esper© OCTO 2012
  • EsperTech et la suite Esper Esper : le moteur CEP Java  Projet démarré en 2004, version 1.0.0 sortie en 2006  Aujourd’hui en version 4.4.0  Existe aussi en version .NET, isofonctionnelle avec la version Java EsperTech : éditeur d’Esper, EsperEE et EsperHA  Société américaine fondée en 2006  Maintient Esper sous licence GPLv2 open source, et EsperEE et EsperHA sous licence commerciale Quelques clients ou utilisateurs du moteur  Inter-connected Stock Exchange of India Ltd.  Rackspace  Oracle CEP, basé sur Esper 1.x© OCTO 2011 38
  • Les modules d’Esper Trois modules complémentaires, trois éditions Haute disponibilité PersistanceHQ : console de gestion Reprise sur erreurDDS : bus de communicationIO : connecteurs (JMS, …) EsperEE EsperHA Esper CEP Engine Moteur de processing (JAR) GPLv2 Statements (EPL) & variables Flux d’événements Croisement données de référence© OCTO 2011 39
  • Le statement : brique de base d’Esper Un statement est une requête continue observant des flux d’événements Il est écrit en Event Processing Language (EPL) Il produit des événements dérivés Flux Listener Java Flux Statement Evénements dérivés d’événements (EPL) Dashboard Variables MOM Persistance (EsperHA)© OCTO 2011 40
  • Exemple d’EPLcreate schema AbandonEvent (...); Typage d’événementscreate variable long varAbandonTimeout = 20; Variables@Name("Detect abandon")insert into AbandonEvent select Flux de sortie pour composition login.loginTime as loginTime, login.customerId as customerId, Attributs de l’événement dérivé customer.lastNamefrom pattern [ every login=LoginEvent -> ( timer:interval(varAbandonTimeout min) Détection de and not CheckoutEvent(sessId = patternslogin.sessId) ) ], sql:refData [ select last_name as lastName Jointure avec des from customer données relationnelles where customer_id = ${login.customerId} ] as customer;© OCTO 2011 41
  • Composition de statements Chaque statement peut injecter ses événements dérivés dans un flux, lui-même servant de source pour un autre statement EPL EPL EPL Application Requêtage Connectivité et intégration Mappings d’événements Requêtage ad-hoc Statements de 1er niveau Statements de 2ème niveau Déclaration des variables Modification des variables Paramétrage des moteurs Simulation Profil Création d’applications Profil Création de dashboards « custom » Technique Création de dashboards « standard » Métier© OCTO 2011 42
  • EsperHQ : console de gestion pour moteurs CEP Plateforme de runtime pour modules Esper packagés  Code EPL de statements EsperHQ  Code Java éventuel (WAR) Administration de moteurs Esper  Statements : création ou composition, suppression, pause, reprise Moteur Moteur  Variables : création, modification Esper Esper Simulation Nuage  Injection de jeux d’événements de test d’événements Dashboards  Branchement d’« eventlets » sur des flux  Agrégation d’eventlets en dashboards© OCTO 2011 43
  • Démonstration Suivi des paniers sur un site d’e-Commerce Site e- CommerceClient Utilisateur métier Ajoute au panier Statistiques d’abandon par produit Valide la commande Alertes en cas de dépassement Abandonne en cours de route Module « App » Module « Query » AddToCartEvent Simulation CheckoutEvent AbandonStats AbandonEvent© OCTO 2011 44
  • Vision pour l’analytique temps réel Un moteur CEP multi-plateforme et performant  Capacités algorithmiques très élaborées avec EPL • Approche du langage familière pour un développeur SQL • Mais les constructions avancées apportent une complexité importante  500 k evt/s avec une latence < 10 µs sur un dual core 2 GHz (source : site) Pas de fonctionnalités natives d’historisation des événements EsperHA : un « socle » pour la mise en place d’une haute disponibilité  Les fonctionnalités concernent surtout la reprise sur panne  Les bascules, le load balancing doivent être mis en place manuellement Des IHM encore limitées  Peu d’aide graphique pour la construction d’EPL  Pas de notion d’utilisateurs, d’espace de travail, de sécurité  Des composants graphiques « push temps réel », mais basiques • Graphiques simples, tableaux de données et dashboards agrégés • Pas de notion d’alerteur pour les composants fournis en natif • Des composants plus élaborés peuvent être développés avec Adobe Flex© OCTO 2011 45