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

1. 1
© OCTO 2013© OCTO 2012© OCTO 2013
Big Data : Usages et opportunités
Retour d’expérience sur Hadoop

2. 2
© OCTO 2013
Joseph Glorieux
Directeur général
OCTO Suisse
jglorieux@octo.com
Rémy SAISSY
Architecte senior
expert Hadoop
OCTO
rsaissy@octo.com

3. 3
© OCTO 2013
Big Data
Définition
Pourquoi maintenant?
Pourquoi faire?
Questions/réponses
Big Data et Hadoop
Questions/réponses
Retour d’expérience
10 Best practices pour dimensionner et configurer un cluster
Hadoop
Hadoop CDH4 sous YARN dans les coms
Questions/réponses
Conclusion
Agenda

4. 4
© OCTO 2013© OCTO 2012© OCTO 2013
Big Data : définition

5. 5
© OCTO 2013

6. 6
© OCTO 2013
Big Data, une écosystème multiple
Web
Google, Amazon,
Facebook, Twitter,
…
Logiciel IT
IBM, Teradata,
Vmware, EMC,
…
Management
McKinsey, BC
G, Deloitte, …

7. 7
© OCTO 2013
Il n’existe pas aujourd’hui de définition claire de Big Data
Définir Big Data
Super datawarehouse?
Stockage low cost?
NoSQL?
Cloud?
Internet
Intelligence?
Analyse en temps
réel?
Non structuré? Open Data?

8. 8
© OCTO 2013
Le marché parle des 3V
Volume
Variété
Vélocité
BatchJ+1
Seconde
Temps réel
Mo ToGo PoFichier
SGBDRéseaux
sociaux
API
Photo
Video
Web
Non structurées
Audio

9. 9
© OCTO 2013
Définition technologique
Application
orientée Flux
évènementiel
Application orientée
Transaction
Application orientée
Stockage
Application orientée
Calculs
Univers
« standard »
SGBDR,
Serveur d’application,
ETL, ESB
Au-delà de 10 To en ligne, les
architectures « classiques »
nécessitent des adaptations
logiques et matérielles très
importantes.
Au-delà de 1 000
transactions/seconde, les
architectures « classiques » des
adaptations logiques et
matérielles très importantes
Au-delà de 10 threads/Core
CPU, la programmation
séquentielle classique atteint
ses limites (I/O).
Au-delà de 1 000
évènements/seconde, les
architectures « classiques »
nécessitent des adaptations
logiques et matérielles très
importantes.
Stockage
distribué
Share
nothing
XTP
Programmation
parallèle
Event Stream
Processing

10. 10
© OCTO 2013
Notre définition
Big data est l’ambition de tirer un
avantage économique
de
l’analyse quantitative des
données
internes et externes de l’entreprise

11. 11
© OCTO 2013© OCTO 2012© OCTO 2013
Big Data : pourquoi maintenant?

12. 12
© OCTO 2013
Une évolution du « hardware » toujours fantastique…

13. 13
© OCTO 2013
Evolution non uniforme de la capacité et du débit
des disques
0
10
20
30
40
50
60
70
Débit(MB/s)
Gain : x100
64 MB/s
0,7 MB/s
Seagate
Barracuda
7200.10
Seagate
Barracuda
ATA IV
IBM DTTA
35010
Gain : x100 000
1990 2010
La croissance du débit reste très inférieure de celle de la capacité

14. 14
© OCTO 2013
Evolution des architectures pour dépasser
cette limite structurelle
Architecture In Memory
• Réduire la latence en utilisant
des supports plus rapides
(DRAM, SSD)
• Bénéficier de l’évolution des
capacités des composants
• La limite structurelle n’est que
déplacée : pour
évoluer, l’architecture doit
devenir une grille In Memory
Architecture en grille
• Paralléliser les accès I/O en
divisant les volumes (sharding)
• 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 co-
localisation des données et
des traitements
• Permet de scaler à l’infini, c’est
le Warehouse scale
computing!

15. 15
© OCTO 2013
Théorème de CAP
L’univers des
SGBRD
La stratégie des sites
à gros trafic.
Avec cohérence in fine
« Consistency »
Tous les clients ont
la même vue de la
donnée
« Partition tolerance »
Le système continue a
fonctionner en cas de
« partition » - plusieurs
sous-ensembles n’arrivent
plus à communiquer
« Availability »
Les clients peuvent
toujours accéder au
système (lecture écriture)
« Il est impossible pour un système informatique de calcul distribué de garantir en
même temps la consistance, la disponibilité et la résistance au morcellement »
Eric Brewer
C
A
P

16. 16
© OCTO 2013
Panorama de solutions
Application
orientée Flux
évènementiel
Application orientée
Transaction
Application orientée
Stockage
Application orientée
Calculs
Cassandra, Mong
oDB, CouchDB
Univers
« standard »
SGBDR,
Serveur
d’application,
ETL, ESB
HDFS
SQLFire
Teradata
Hana
Grid Computing
Giga Spaces
Map Reduce
GPU
Voldemort
Exadata
HBase
Esper
Quartet
ActivePivot
Sqoop
RabbitMQ,
Zero MQ
Ultra Low
latency
Hama
Igraph
MapR
EMC
Redis
ExalyticsIn memory
Distribué

17. 17
© OCTO 2013© OCTO 2012© OCTO 2013
Big Data : pourquoi faire?

18. 18
© OCTO 2013

19. 19
© OCTO 2013
Scoring de crédit
Supply-chain
management
Les nouveaux cas d’usages
Prévention de
l’attrition
Lutte contre la
fraude
Modèle de
tarification
Segmentation client
Calcul du risque
Optimisation du réseau

20. 20
© OCTO 2013
Les opportunités peuvent être perçues sous 2
angles :
Big Data comme « Cost killer »
Big Data comme « Ouvrir le champs des possibles »
Big Data : de nouvelles opportunités?

21. 21
© OCTO 2013
Comparatif machine à « puissance équivalente (RAM/CPU) »
Comparatif stockage
Big 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-analytics
SAN
$2 - $10 par GB
0,5 PB
200 000 IOPS
1 GB per second
Filers NAS
$1 - $5 par GB
1 PB
400 000 IOPS
2 GB per second
Local storage
$0,05 par GB
20 PB
10 000 000 IOPS
800 GB per second
Available storage
for 1 million $

22. 22
© OCTO 2013
Archivage
Déchargement d’entrepôt de données
ET(L)
Fail-over
Big Data comme « cost killer » : use cases

23. 23
© OCTO 2013
Analyser des données de l’entreprise qu’il paraissait
illusoire de vouloir analyser du fait du volume ou de la
capacité de traitement sous-jacent :
Analyse des logs web
Profondeur d’analyse étendue : plusieurs années, plusieurs
dizaines d’année…
Croisement entre SI cloisonné
Analyser des données exogènes de l’entreprise et les
croiser avec les données existantes
Réseaux sociaux
Recherches internet
Internet des objets
Big Data comme « Ouvrir le champs des possibles »

24. 24
© OCTO 2013
Ouvrir le champs des possibles : grille de lecture
Segmentation Comportement Influence
Concurrence Usage / Exp Adoption / Reco
Mesure Optimisation Collaboration
Données
d’Identité
Données
d’Usage
Données de
Relation
Axesd’analyse
Sources de données
Client
Produit
Services
Processus

25. 25
© OCTO 2013

26. 26
© OCTO 2013© OCTO 2012© OCTO 2013
Big Data et Hadoop

27. 27
© OCTO 2013
Hadoop dans l’univers Big data
Application
orientée Flux
évènementiels
Application orientée
Transactions
Application orientée
Stockage
Application orientée
Calculs
Parrallel database
NoSQL
NewSQL
CEP, ESP
H
a
d
o
o
p
In Memory

28. 28
© OCTO 2013
Hadoop s’impose comme une architecture
de référence sur le marché
• Apache Hadoop
Open Source
• Cloudera CDH
• Hortonworks
• MapR
COTS
• Greenplum (EMC)
• IBM InfoSphere BigInsights (CDH)
• Oracle Big data appliance (CDH)
• Teradata (aster)
Editeurs
• Amazon EMR (MapR)
• VirtualScale (CDH)
Cloud

29. 29
© OCTO 2013
Hadoop et les outils de BI et de Data mining

30. 30
© OCTO 2013
Hadoop, un écosystème riche et complexe
Traitement
MapReduce
Framework permettant de traiter des données en parallèle
Requêtage
Pig
Langage de flux de données
Hive
DSL de requêtage « SQL-like »
Workflow
Oozie / Azkaban
Workflow pour jobs Hadoops dépendants
Infrastructure
Intégration au SI
Flume, Chukwa, Scribe…
Collection de données fiable et résiliente
Sqoop
Intégration RDBMS & Hadoop
Supervision
Platform Management
Console
Hue
Traitement distribué avancé
Mahout
Machine learning
Hama
Bulk Synchronous Processing
Stockage
HDFS
Un système de fichiers distribué write-once, read-many
Hbase
Base de données pour des accès aléatoires read/write
Reporting
Hue Beeswax
Interface web de requêtage
Pentaho
Reporting
IBM BigSheets
Outil de requêtage

31. 31
© OCTO 2013
Répartition des données sur plusieurs machines
Réplication des données pour assurer le « fail-over » : « rack
awareness »
Hadoop Distributed File System (HDFS)

32. 32
© OCTO 2013
Paralléliser et distribuer les traitements
Traiter plus rapidement des volumes de données unitaires plus faibles
Co-localiser traitements / données
MapReduce, le système de traitement

33. 33
© OCTO 2013
Hadoop est à la fois :
Un système de stockage distribué pour les grands fichiers
Un système d’agrégation et de traitement parallèle en mode batch
à la demande, reposant sur la grille de stockage
Hadoop n’est pas :
Un système d’accès à la donnée unitaire (random access)
Un système temps réel, mais batch à la demande
Hadoop nécessite des composants externes pour compléter le
puzzle
Des outils de visualisation graphique des données
Une librairie de traitements statistiques et text mining finalisée
Mahout, Hama fournissent des algorithmes parallèles
…
Les mythes et réalités sur Hadoop

34. 34
© OCTO 2013

35. 35
© OCTO 2013© OCTO 2012© OCTO 2013
10 best practices pour
dimensionner et configurer un
cluster Hadoop

36. 36
© OCTO 2013
Piège 1 : la tentation des machines « monstres de guerre »
Piège 2 : le réseau, mieux vaut 10Gb/s c’est plus sûr
Piè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 collecter
Piège 6 : conserver les paramètres mémoire par défaut
Piège 7 : conserver la configuration par défaut de HDFS
Piège 8 : conserver la configuration par défaut de MapReduce
Piège 9 : utiliser les formats de fichier par défaut
Piège 10 : benchmarker son cluster avec TeraSort
Sommaire

37. 37
© OCTO 2013
Le piège
Des ressources inutilisées
Un niveau de parallélisme insuffisant
Un surcoût aux performances non garanties
Best Practice
Penser parallélisation
Notion de conteneur : 1 CPU physique / xGo de RAM / Disque dur
HDFS
Dimensionner pour du temps de traitement
Piège 1 : la tentation des machines « monstres de guerre »

38. 38
© OCTO 2013
Le piège
Pour garder de bonnes perfs, il faut éviter la sursouscription
Switchs de rack plus gros, donc plus cher
10Gb/s = 1Go/s = 40Go/s au niveau du switch
Backbone encore plus gros, donc encore plus cher
40Go/s * <nombre de racks> = ?
Best Practice
Utiliser deux cartes 1Gb/s FD
Moins de disque sur chaque serveur
Superviser
Piège 2 : le réseau, mieux vaut 10Gb/s c’est plus sûr

39. 39
© OCTO 2013
Le piège
Pas de détail sur les métriques internes d’Hadoop
Lectures / écritures de HDFS par nœud
Consommation mémoire pendant les étapes d’un job
Best Practice
Pensez aux développeurs !
Utiliser Ganglia pour des métriques fines
Piège 3 : pour superviser, mes outils actuels suffisent !

40. 40
© OCTO 2013
Le piège
Un petit cluster Hadoop, c’est 10 machines
Configuration et maintenance à la main difficile
Perte de temps
Best Practice
Utiliser un SCM
Piège 4 : un SCM ? Pas le temps, SSH fera l’affaire !

41. 41
© OCTO 2013
Le piège
500 mappers et 20 reducers
520 fichiers de logs à collecter sur tout le cluster
Peu d’informations utiles à long terme
Best Practice
Pas de collecte sur les slaves
Collecte sur les masters
Piège 5 : les logs c’est important, il faut tous les collecter

42. 42
© OCTO 2013
Le piège
Ils ne sont pas optimisés pour votre cluster
Sous utilisation des ressources
Échecs possibles de certains jobs
Best Practice
2Go pour les démons tasktracker et datanode
4Go pour le démon JobTracker
4Go + 1Go par million de bloc pour le namenode
Utiliser 4Go voire 8Go par tâche de map et de reduce
Superviser
Piège 6 : conserver les paramètres mémoire par défaut

43. 43
© OCTO 2013
Le piège
Pas optimisée pour un cluster
Les paramètres dépendent de vos données, de votre réseau, …
Best Practice
Configurer en pensant I/O vs mémoire vs réseau
Chaque cas d’utilisation a sa propre configuration optimisée
Superviser
Piège 7 : conserver la configuration par défaut de HDFS

44. 44
© OCTO 2013
Le piège
Pas optimisée pour un cluster
Les paramètres dépendent de votre utilisation
Best Practice
Utiliser le CapacityScheduler
Configurer avec des règles de calcul
Auditer l’usage réel pour optimiser les configurations
Piège 8 : conserver la configuration par défaut de MapReduce

45. 45
© OCTO 2013
Le piège
Lenteur des jobs dû à un stockage inefficace
Plus d’espace utilisé que nécessaire
Best Practice
Format de stockage : distinguer les usages
Base de données
Données binaires
Compression : quelle fréquence d’accès ?
Donnée utilisée
Archivage
Piège 9 : utiliser les formats de fichier par défaut

46. 46
© OCTO 2013
Le piège
Non représentatif de l’usage réel du cluster
Best Practice
Utiliser du code de production
Piège 10 : benchmarker son cluster avec TeraSort

47. 47
© OCTO 2013

48. 48
© OCTO 2013© OCTO 2012© OCTO 2013
Hadoop CDH4 sous YARN dans
les télécoms. Retour d'expérience

49. 49
© OCTO 2013
Contexte
Caractéristiques du cluster
Déroulement du projet
Déploiement de Hadoop
Déploiement des outils support
Les alimentations de données
L’analyse des données
La migration du cluster
Le benchmark du cluster
Cluster en fin de mission
Conclusion
Sommaire

50. 50
© OCTO 2013
Durée : 3 mois
Equipe opérationnelle : 8 personnes
Trois enjeux majeurs :
Construire une plateforme Big Data opérationnelle
Montée en compétence des équipes
Préconisations pour une plateforme industrielle
Equipe colocalisée
Contexte

51. 51
© OCTO 2013
1 rack, 12 serveurs
1 nœud pour les outils, 1 autre pour l’anonymisation
2 nœuds master
namenode / resourcemanager
secondary namenode
8 nœuds slave : datanode et nodemanager
Caractéristiques du cluster
Slaves
Masters
Outils
Accès Masters et
Outils

52. 52
© OCTO 2013
Déroulement du projet

53. 53
© OCTO 2013
Réseau de production : utiliser un mirroir local
Configuration OS : compétences système et réseau requises
Utiliser un SCM pour déployer
Nécessité d’avoir des profils polyvalents
Déploiement de Hadoop
A l’attaque
!

54. 54
© OCTO 2013
Relativement facile une fois Hadoop correctement installé
Peu d’impact sur le cluster en lui même
Ne déployer que le nécessaire
Déploiement des outils support

55. 55
© OCTO 2013
KISS : Keep It Simple Stupid
Ne pas négliger le travail en amont de l’analyse !
Les alimentations de données

56. 56
© OCTO 2013
Beaucoup de travail en amont
Un cluster s’optimise au contact de la réalité
Limites des outils
Ajustement de l’ordonnanceur
Configuration mémoire
Configuration d’HDFS
L’analyse des données

57. 57
© OCTO 2013
Passage de CDH 4.0.1 à CDH 4.1.2
Des leçons
Du travail en amont
Le SCM aurait fait gagner du temps
Suivre les préconisations !
La migration du cluster

58. 58
© OCTO 2013
Initialement en début de projet…
Terasort ? Plutôt HiBench
Au final, le travail réalisé pendant le projet a été le meilleur
benchmark
Le benchmark du cluster

59. 59
© OCTO 2013
Cluster YARN opérationnel
Plusieurs outils testés au cours de l’exploration
HDFS occupé à 70% : 1 427 251 fichiers, 280To
Les jobs ne saturent pas complètement le cluster
Cluster en fin de mission

60. 60
© OCTO 2013
Des points positifs
YARN : stable et ouvre à d’autres frameworks que Map Reduce
Des outils polyvalents
Des points à améliorer
Maturité des outils et de leur environnement de travail
Complexité de la configuration de Hadoop comme de ses outils
Des documentations et des abaques
Mettre en place votre cluster ?
une équipe pluri disciplinaire
de la polyvalence technique
Bilan

61. 61
© OCTO 2013

62. 62
© OCTO 2013© OCTO 2012© OCTO 2013
Conclusion

63. 63
© OCTO 2013
Use cases
Cost killer
Ouvrir le champs des possibles
L’écosystème Hadoop est riche et complexe, en
mouvement
L’usage a une incidence forte sur l’architecture et la
configuration
Conclusion

64. 64
© OCTO 2013
Identifiez les use cases métiers applicables dans votre contexte, en
benchmarkant 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 les
plus early adopters
Marketing
Distribution
Trading
Risques
Valorisez les résultats du POC en termes métiers
Définissez une architecture cible de classe industrielle pour généraliser
l’approche en réduisant les coûts
Comment démarrer cet après midi?

65. 65
© OCTO 2013
OCTO et le Big Data
Une offre cohérente entre technologie et analyse prédictive
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
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 pilotes
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
DIRECTION SI DIRECTION MÉTIER