BarCamp « Big Data, ou comment retrouver
une aiguille dans une botte de foin »
Janvier 2014 @ Paris
Pierre REVELLIN
Respon...
2
Au programme
Contexte et origine du besoin
La première ébauche
Le vrai problème : les ressources CPU vs IOs
Hadoop, une ...
CONTEXTE ET ORIGINE
DU BESOIN
6
Contexte et origine du besoin
Contexte
Site de E-commerce parmi les leaders du marché
Complexe, composé d'applications m...
7
LA PREMIERE EBAUCHE
88
La première ébauche
Architecture
Centralisation des logs
Ecriture sur du SAN.
Une implémentation via syslog
Solution ép...
9
RESULTATS AU DELA
DES FAIBLESSES
TECHNIQUES
1010
Résultats au delà des faiblesses techniques
Difficulté à valoriser car méconnaissance du contenu des logs
Possibilité...
11
LE VRAI PROBLEME :
LES RESSOURCES CPU
VS LES IOS
1212
Le vrai problème : les ressources CPU vs les IOs
Problème du CPU vs IO
Test 1 : on lit un fichier de 500mo : 4s envir...
AGREGATION DE CPU
14
Agrégation de CPU
Décomposer le problème via l’algorithme MapReduce
Plusieurs implémentations
Mongo / CouchDb / Cassand...
HADOOP : UNE
VULGARISATION
16
Partie 1 : le stockage
File System issue de Google FS
Orienté : large scale (100T/Po de donnée) / lecture intensive / l...
17
Partie 1 : le stockage
HDFS
Autorise un facteur de réplication de block
Les metadatas (genre inode) sont stockés dans u...
18
Partie 1 : le stockage
HDFS en schéma :
19
Partie 1 : le stockage
HDFS en schéma :
20
Partie 2 : le traitement des données
La théorie
L'API repose sur 2 fonctions
MAP
Reduce.
Mise en avant de la programmat...
21
Partie 2 : le traitement des données
Répartition sur plusieurs nœuds
22
Partie 2 : le traitement des données
Dans la vraie vie … il faut coder
TDD via MRUnit
Difficile de debugger/profiler un...
23
Partie 2 : le traitement des données
Pour ceux qui aiment être root : tout est disponible sous apache.org
Offre hadoop ...
INTEGRATION
DANS UN SI
25
Intégration dans un SI
Attention aux effets de bord sur le cœur du SI
On parle de centaine de giga jour, switch/cœur de...
26
COMMENT
VALORISER DES
TERRA/PETAOCTETS
D’INFORMATION ?
2727
Comment valoriser des téra/pétaoctets d'informations ?
Difficulté à valoriser car méconnaissance du contenu des logs
...
28
USE CASE
2929
Problématique : trouver un mot clef dans les logs
Map / Reduce basique
Map va filtrer les logs contenant le mot clé
R...
3030
Use case 2 : facturation client sur plateforme mutualisée
Faire du SLA sur du middle tiers mutualisé
Clé de répartiti...
3131
Use case 2 : facturation client sur plateforme mutualisée
3232
Use case 3 : détection d’attaque DOS
Problématique : détection de robots qui empêchent la vente de produit
Identifier...
3333
Use case 4 : indicateur de SLA sur du middleware
Problématique : vérifier qu’on entre dans le SLA sur du middleware r...
34
LES NOUVEAUX
BESOINS
3535
Les nouveaux besoins
Mode batch pas toujours adapté
Introduction d’ElasticSearch / Kibana.
Gestion de la durée de vie...
BIG DATA AU DELA
D’UNE MODE
37
Big Data au-delà d’une mode
Solutions inventées et adoptées par et pour les leaders de marché
L’algorithme map/reduce r...
CONCLUSION
39
Conclusion
N'est qu'un moyen technique, pas la finalité
Ne pas se tromper d'acteur/profil
L'analyse statistique est un ...
40
Références
http://fr.wikipedia.org/wiki/MapReduce
Hadoop : the Definitive guide / O'Reilly
MISC Décembre 2013
Cluster M...
41
Prochain SlideShare
Chargement dans…5
×

Big Data ou comment retrouver une aiguille dans une botte de foin

588 vues

Publié le

Un parc informatique d’un millier de machines génère de nombreux Terra Octets de logs. Comment parvenir à y retrouver une information pertinente et comment valoriser les informations contenues dans ces logs ?

Au programme :

- La centralisation des logs : back to basics;
- Cas pratiques : détection d’attaques DoS et refacturation sur plateforme mutualisée;
- Une grille Hadoop : en quoi ça consiste ?

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
588
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Big Data ou comment retrouver une aiguille dans une botte de foin

  1. 1. BarCamp « Big Data, ou comment retrouver une aiguille dans une botte de foin » Janvier 2014 @ Paris Pierre REVELLIN Responsable Architecture et Performance
  2. 2. 2 Au programme Contexte et origine du besoin La première ébauche Le vrai problème : les ressources CPU vs IOs Hadoop, une vulgarisation : Partie 1 : Le stockage Partie 2 : Le traitement de données Partie 3 : Quelle implémentation ? Intégration dans un SI Big Data au delà d'une mode Comment valoriser des téra/pétaoctets d'informations ? Use cases Le Big Data en France
  3. 3. CONTEXTE ET ORIGINE DU BESOIN
  4. 4. 6 Contexte et origine du besoin Contexte Site de E-commerce parmi les leaders du marché Complexe, composé d'applications multi-tiers / instances / multi-sites Forte visibilité avec un besoin de réactivité très fort. Problèmes pour exploiter des applications réparties Répartition sur des périmètres différents des équipes supports /exploitations Application statefull pour simplifier l'analyse puis statefull'less' Quid du reporting global ? Besoin de centraliser l'information Les logs constituent la première source d’information.
  5. 5. 7 LA PREMIERE EBAUCHE
  6. 6. 88 La première ébauche Architecture Centralisation des logs Ecriture sur du SAN. Une implémentation via syslog Solution éprouvée, multiplateforme Plusieurs datasources : streaming / fichier Niveau de Qos : UDP / TCP, bufferisation Enrichissement de message post émission. Faiblesse de la solution Pas de loadbalancing ou failover natif Pas de travail à la volée des messages Périmètre de responsabilité diffus ( équ système / équ applicative /dev ) IO concentré nécessite du SAN (10000 à 30000 IO/s ).
  7. 7. 9 RESULTATS AU DELA DES FAIBLESSES TECHNIQUES
  8. 8. 1010 Résultats au delà des faiblesses techniques Difficulté à valoriser car méconnaissance du contenu des logs Possibilité quasi infinie, seule limite : l'information est-elle disponible ? Information mélangée car pas de 'contextualisation' du log mais : Information commerciale : activité clientèle Information technique : performance du SI malgré son hétérogénéité. Problèmes de fond : le traitement des données Temps nécessaire pour retrouver/traiter une information Pour traiter il faut normaliser les évènements Sécurité des informations Pas de réponse simple au problème du périmètre des équipes supports/exploitations.
  9. 9. 11 LE VRAI PROBLEME : LES RESSOURCES CPU VS LES IOS
  10. 10. 1212 Le vrai problème : les ressources CPU vs les IOs Problème du CPU vs IO Test 1 : on lit un fichier de 500mo : 4s environ 123Mos, limité par les IO disques Test 2 : on grep une ip dans un fichier de 500mo : 12s soit 42Mo/s Test 3 : on passe en multithread sur le grep : 118Mo/s La contention est la CPU ou la bande passante pour alimenter le processus. Optimisation par agrégation de ressources Problème historique touchant toutes les strates : Cas des supercalculateurs / RAID / Chunk&Tap sur le réseau. Ne pas oublier qu'au delà de la largeur des données, la latence d'accès est maîtresse Pas d'invention : c'est LE moteur de l'évolution des ordinateurs : Augmenter le nombre d'opération en 'parallèle' : pipelining / hypethreading La problématique d'IO est résolue par des niveaux de cache (cache niveau 2/3 partagé) Bank RAM appairé pour doubler la BP Enfin le multi-core.
  11. 11. AGREGATION DE CPU
  12. 12. 14 Agrégation de CPU Décomposer le problème via l’algorithme MapReduce Plusieurs implémentations Mongo / CouchDb / Cassandra / Hadoop.
  13. 13. HADOOP : UNE VULGARISATION
  14. 14. 16 Partie 1 : le stockage File System issue de Google FS Orienté : large scale (100T/Po de donnée) / lecture intensive / lowcost. Back to basics Un disque dur est décomposé en secteur de 512 octets Les secteurs sont organisés en bloc par un système de fichier (FS) Bloc totalement alloué même pour 10 utilisations. Hadoop FileSystem : HDFS Se repose sur les FS natif OS Utilise des block de 64Mo par défaut Avec un débit de 100Mo/s et un seek time de 10ms : 1% du temps en latence Allocation optimisée.
  15. 15. 17 Partie 1 : le stockage HDFS Autorise un facteur de réplication de block Les metadatas (genre inode) sont stockés dans un NameNode Distribution des blocs de données pour améliorer la lecture : anti-défragmentation Adopte les normes posix. Méthode d’accès Accès console Webapp Par API (pyhon/java/ruby) FuseFS.
  16. 16. 18 Partie 1 : le stockage HDFS en schéma :
  17. 17. 19 Partie 1 : le stockage HDFS en schéma :
  18. 18. 20 Partie 2 : le traitement des données La théorie L'API repose sur 2 fonctions MAP Reduce. Mise en avant de la programmation fonctionnelle vs impérative Impact fort suivant les indicateurs attendus. Optimisations 'cachées' Les maps sont lancés au plus proche des données Attention à la compression.
  19. 19. 21 Partie 2 : le traitement des données Répartition sur plusieurs nœuds
  20. 20. 22 Partie 2 : le traitement des données Dans la vraie vie … il faut coder TDD via MRUnit Difficile de debugger/profiler une application Le fait d'être en large scale provoque un effet loupe sur le moindre problème de code. … ou sous traiter Hive PIG SPSS.
  21. 21. 23 Partie 2 : le traitement des données Pour ceux qui aiment être root : tout est disponible sous apache.org Offre hadoop packagée En pleine explosion ( HortonWorks/ cloudera / ….) Attention au mode de licencing Exemple Splunk : 800k +100k par 500g Cloudera : au début limité à 10 nœuds puis modification du mode de licencing Pas à l'abri d'un revirement à la Oracle. Aucune implémentation ne remplace un expert pour l'exploitation Les coûts cachés Injection des données Nettoyage des données.
  22. 22. INTEGRATION DANS UN SI
  23. 23. 25 Intégration dans un SI Attention aux effets de bord sur le cœur du SI On parle de centaine de giga jour, switch/cœur de réseau mutualisés Bande passante inter-sites (Qos MPLS) CPU/RAM consommé sur les serveurs applicatifs Lock des ressources (Map/Reduce) de la grille : mise en place de quota Durée de vie des données ? Pas de place dans vos travées ? Utilisation de serveur MoonShot HP 4U : 125 slots à repartir entre CPU est stockage Cartouche 16 core Disque de 1 tera. Recyclage Faire du capacity planning en recyclant les vieux serveurs en nœuds déstockage. Externalisation de l’infra Infra cloud dédiée, coûteuse si vous avez des exigences de temps de traitement.
  24. 24. 26 COMMENT VALORISER DES TERRA/PETAOCTETS D’INFORMATION ?
  25. 25. 2727 Comment valoriser des téra/pétaoctets d'informations ? Difficulté à valoriser car méconnaissance du contenu des logs L'information est-elle disponible ? Possibilité quasi infinie mais : Un expert Big Data ne remplacera pas un datascientist L'information a force de valeur uniquement par sa qualité et sa date de péremption. Use case réel GrepIt ! Facturation cliente sur plateforme mutualise Indicateur de SLA sur du middleware Détection d'attaque par analyse comportementale.
  26. 26. 28 USE CASE
  27. 27. 2929 Problématique : trouver un mot clef dans les logs Map / Reduce basique Map va filtrer les logs contenant le mot clé Reduce va simplement écrire les logs lui arrivant. Use Case 1 : GrepIT
  28. 28. 3030 Use case 2 : facturation client sur plateforme mutualisée Faire du SLA sur du middle tiers mutualisé Clé de répartition composite IP / Stats / Htpp Code / Login / URL /Plateforme. 90 percentiles sur 2 sites
  29. 29. 3131 Use case 2 : facturation client sur plateforme mutualisée
  30. 30. 3232 Use case 3 : détection d’attaque DOS Problématique : détection de robots qui empêchent la vente de produit Identifier les comportements anormaux Map va filtrer les URL utiles, la clé de répartition est l’ip Reduce va calculer des compteurs : Nombre de mise en panier Délai entre 2 mise en panier Nombre de paiement versus nombre de mise en panier En sortie on corrèle avec des seuils prédéfinies. Bannissement d’IP non automatique
  31. 31. 3333 Use case 4 : indicateur de SLA sur du middleware Problématique : vérifier qu’on entre dans le SLA sur du middleware répartie Identifier les comportements anormaux Agrégation Corrélation Gestion de plusieurs datasources.
  32. 32. 34 LES NOUVEAUX BESOINS
  33. 33. 3535 Les nouveaux besoins Mode batch pas toujours adapté Introduction d’ElasticSearch / Kibana. Gestion de la durée de vie de l’information : besoin de streaming
  34. 34. BIG DATA AU DELA D’UNE MODE
  35. 35. 37 Big Data au-delà d’une mode Solutions inventées et adoptées par et pour les leaders de marché L’algorithme map/reduce remis au goût du jour par Google pour indexer le Web Hadoop core vient des équipe de Yahoo pour indexer le Web Difficile de faire mieux avec un équipe R&D (on RivoDB). Sans engagement : Pas de technologie propriétaire Hardware standard Produit Open Source massivement adopté qui devient donc un standard. Implications stratégiques au delà du rêve Permet d'établir des stratégies marketing a court et moyen terme, comment ? Toute la matière première est là Nécessite de réelles compétences de Data Scientist Permet une évolution « maîtrisée » du SI au delà de l'amortissement CAPEX/OPEX étalé.
  36. 36. CONCLUSION
  37. 37. 39 Conclusion N'est qu'un moyen technique, pas la finalité Ne pas se tromper d'acteur/profil L'analyse statistique est un métier à par entière (Data Scientist) Exploitation d'un cluster nécessite un bon niveau d'expertise De même pour les développements : peu très vite déraper. Attention aux promesses des sociétés de consulting Pose des problèmes organisationnels importants Peu de société en France sont dotées d’un vrai retour d'expérience
  38. 38. 40 Références http://fr.wikipedia.org/wiki/MapReduce Hadoop : the Definitive guide / O'Reilly MISC Décembre 2013 Cluster Multiprocesseur / Architecture Paralelle Eyrolles.
  39. 39. 41

×