le choix mongodb dans l’architecture...- données et traitements du rm 2. utilisation d’hadoop...
TRANSCRIPT
Le choix MongoDB dans l’architecture
BIG DATA du projet KARMA Refonte du Système de Revenue Management d'Air
France KLM
Conférence BIG DATA - Master MBDS
Université de Nice Sophia Antipolis
26 Janvier 2016
Martial AYAS – [email protected]
Agenda
1. Présentation de KARMA
- Le Revenue Management
- Définitions et concepts
- Chiffres clés
- Données et traitements du RM
2. Utilisation d’Hadoop dans KARMA
- Le choix d’Hadoop
- L’architecture technique
- Design d’un batch Hadoop
- Etat des lieux technique et
fonctionnel
3. Axes d’amélioration
- Les performances
- Accès aux données
2
4. Utilisation de MongoDB dans KARMA
- Objectifs & contraintes
- Technologies et critères d’évaluation
- Le choix MongoDB
- Architecture et fonctionnement
5. Cas d’utilisation
- POC Flights Availability
- Eureka
6. Evolutions à venir
Présentation de KARMA
Le Revenue Management 3
Contribution moyenne :
260€
Contribution moyenne :
310 €
Maximalisation du revenu
par contrôle des ventes
M-12 : Ouverture du vol
Remplissage
« naturel »
J : Départ vol
M-2 : Saturation vol
M-4 : Fermeture BC M-1 : Fermeture MC
Haute
contribution
500€
Moyenne
contribution
350€
Faible
contribution
200€
Présentation de KARMA
Définitions et concepts
• KARMA KLM Air France
Revenue Management
Application
• RMS : Revenue Management
System
• KARMA permet d’optimiser le
revenu grâce à la prévision :
- Demande
- Annulation
- Overbooking
• Permet aux analystes de vols
d’agir sur les recommandations
du système en fonctions :
- Des marchés
- Des périodes
- Des évènements
4
L’objectif principal de
KARMA
« To sell the right seat
to the right person
at the right moment »
Et d’influer sur la disponibilité des
sièges à vendre pour un tarif
donné à une date donnée.
Présentation de KARMA
Chiffres clés (2015)
• Le programme de vol
- 2500 vols / jour
- 231 destinations / 103 pays
• L’activité « Passage »
- 77,5 millions de passagers
• Les avions
- 569 avions
- De 40 à 520 sièges
• La tarification
- 26 classes
- 30 000 tarifs
- Prix carburant
- La concurrence
- La demande
Volumes initiaux + Combinatoire = Démultiplication des volumes
Augmentation des volumes = Problématiques de performances
5
Utilisation d’Hadoop dans KARMA
Le choix d’Hadoop (1/2)
• Contexte fonctionnel et technique au démarrage du projet :
- Refonte du RM = Nouvelle approche + Nouveaux besoins
- Forte augmentation des volumes nécessaires aux calculs de prévision
- Forte augmentation de la fréquence des évènements à prendre en compte
pour avoir un système réactif
Augmentation des volumes et du stockage
Augmentation de la puissance de traitement
- Infaisabilité des traitements batch en BD
- Le volume des données lié aux évènements et aux combinaisons possibles
- Temps de traitements incompatibles avec la fréquence nécessaire des MAJ
Nécessité de paralléliser et distribuer les traitements et les données
- Interfaçage avec les moteurs de RO
- Les moteurs de Recherche Opérationnelle (Prévision + Optimisation)
- Développés en C++ (CPlex), utilisent l’approche Map Reduce / Fichiers
L’alimentation des moteurs doit se faire sous la forme de fichiers
6
Utilisation d’Hadoop dans KARMA
Le choix d’Hadoop (2/2)
• Le choix Hadoop n’est pas sans contraintes …
- Contraintes d’exploitation
- Haute disponibilité / Tolérance aux pannes
- Seuls la Base de données et le NFS sont supportés (backup) par la production
Mécanisme de synchronisation entre la BD, le NFS et le HDFS
- Maitrise du stockage malgré les volumes Utilisation du format Avro + compression
- Contraintes de développement / Maintenabilité
- Apprentissage de l’approche et des API
- Démultiplication des composants : 1 req SQL 1 à n jobs Hadoop
Ex : Le traitement d’optimisation quotidien comporte 765 jobs dont 376 en Hadoop
Création d’un Framework de développement pour harmoniser le dev des jobs Hadoop
- Chaque job de MapReduce crée une nouvelle copie des données
Besoin d’un outil de design des jobs est de suivi du cycle de vie des traitements et des
données produits par Hadoop (Voir diagramme)
- Contraintes métier
- Concilier les 3 activités : Batch / Utilisateur / Evènementielle (Problématique de
concurrence sur l’accès et la mise à jour des données)
Séparation des traitements par la planification / contraintes de perfs importantes
7
Utilisation d’Hadoop dans KARMA Design technique d’un Batch Hadoop
8
DB Oracle 11g
3To ~350 tables
Extractions
DB HDFS
SQOOP
Transformations
Agrégations
Hadoop / PIG
Traitements
Métier
C++ CPlex
Traitements
Métier
Hadoop / PIG
Transformations
Formatage
Hadoop / PIG NFS
1,5To
CSV, XML, …
Copies
NFS HDFS
DistCp
Injections
DB HDFS
SQL*Loader
Copies
HDFS NFS
DistCp
DB Oracle 11g
3To ~350 tables
NFS
1,5To
CSV, XML, …
Avro, CSV, XML
Avro, CSV, XML
Avro
Avro, CSV
Avro, CSV
• Accès aux données DB - SQOOP + OraOop : Extractions en //
- SQL*Loader : Injection en //
(Suppression des contraintes d’intégrité,
dénormalisation, recalcul des indexs)
• Accès aux données NFS - DistCp : Copies HDFS NFS
• Préparation des données - Hadoop MapReduce : Transformation,
comparaisons, jointures, agrégations,
filtres, fusion, …
• Traitements métier - Hadoop MapReduce : traitements hors RO
- C++ Cplex : Moteurs de prévisions,
d’optimisations (Recherche Opérationnelle)
• Reporting - PIG : Statistiques et KPI vérification de la
qualité des données
• Exploitation / Supervision - Error collector, compacteurs, archivage,
purge
Utilisation d’Hadoop dans KARMA Etat des lieux technique et fonctionnel
9
Revue Technique
Ferme de serveurs
- 21 Serveurs : 32 CPU et 128 Go de RAM par serveur
Grille de calcul
- Pour une capacité d’environ 850 slots d’exécution en
parallèle
Grille de stockage (HDFS)
- Répartit sur les 21 serveurs
- 3,2 To par serveur soit 67 To au total
Revue Fonctionnelle
Traitements Batchs (uniquement)
- 45 batch (métiers / techniques / KPI)
- 8 process planifiés > 1H dont 7 utilisent Hadoop
- 7 process à la demande > 1H dont 7 utilisent Hadoop
Exemple du RSU (OAC27)
Profil du batch (MAJ 01/2016)
- Exécution quotidienne
- Durée approximative : 10 Heures (11h30)
- Nombre d’Unités de tâches : 117 (128)
- Nombre de jobs total : 603 (765)
- Nombre de jobs en séquence : 244 (232)
- Nombre de jobs en parallèle : 359 (533)
- Nombre de jobs Hadoop : 313 (376)
Stockage nécessaires (HDFS)
- 700GB, soit 2,1TB avec la réplication x3
(1,2TB soit 3,6 TB avec la réplication x3)
Typologie des traitements
- Job Java Hibernate
- Job techniques Shell
- Jobs techniques Hadoop
(préparation / transformation / agrégation)
- Jobs fonctionnels Hadoop
- Moteurs de RO (C++)
Axes d’amélioration Performances et accès aux données
• La performance des batch
- Optimisation du séquencement des jobs au sein des Batchs
- Optimisation / limitation des extractions / injections entre la DB et le
HDFS
• La performance des traitements interactifs et évènementiels
- Normalisation + Volumes = Jointures et agrégations couteuses
• Multiplication et diversification de l’accès aux données
- A des traitements batch d’applications tierces
- A des traitements non batch
- Traitements interactifs
- Traitements évènementiels
Les pistes : Nouvelles approches + nouvelles technologies
10
Utilisation de mongoDB dans KARMA
Objectifs et contraintes
• Constats
- KARMA bénéficie d’une architecture et de moyens uniques au sein du SI
- Cependant la puissance de calcul et les données sont « sous utilisées »
- Traitements batch très évolués / optimisés
- Traitements interactifs limités / optimisation couteuse
• Objectifs
- Réutiliser la puissance de calcul et les données de KARMA pour
améliorer les traitements interactifs
- Améliorer et faire évoluer KARMA
- Proposer de nouveaux services
- Ouvrir les données à des applications tierces
• Contraintes
- Pas d’impact sur les performances
- Activité batch la nuit et les week-ends
- Base de données Oracle dédiée au RM (Forte sensibilité qualité / perfs)
- Sortir des contraintes propres à KARMA
- Eclipse RCP
11
Utilisation de MongoDB dans KARMA
Technologies et critères d’évaluation
12
Techno Type Support Performances Compatibilité / Impacts
Hive Metastore HDFS Usage interactif
exclu
Impact uniquement lors de l’utilisation
couteux
HBase BD NoSQL – Colonne HDFS OK Impact continu sur la grille Hadoop
mongoDB BD NoSQL – Document FS OK Pas d’impact direct mais de nouveaux
investissements
• Points faibles de l’accès interactif aux données
- Jointure et Agrégation des données
- Oracle est déjà surchargée (GUI + Alimentation temps réel)
- La plupart des jointures et agrégations existent déjà sur le HDFS
• Aucune technologie ne se démarque vraiment - D’autres critères doivent être pris en compte …
Utilisation de mongoDB dans KARMA
Le choix mongoDB
• Choix de privilégier mongoDB pour ses autres atouts :
- Approche document
- Dénormalisation de l’information
- Plus proche de l’utilisation de la donnée que du stockage
- Interopérabilité : JSON, Drivers
- Format optimisé BJSON
- Agrégation Framework Performances
• Développement / Exploitation
- Courbe d’apprentissage et mise en œuvre rapide
- Communauté très active
- HA (Haute Disponibilité) / Sharding (Scalabilité horizontale)
• MongoDB et nouvelles tendances : - Développements Agile
- MongoDB + AS + AngularJs + D3.js + CSS = Rich Modern Web Apps
- Applications Web mono page
- Applications multi supports (PC, Smartphones, Tablettes, …)
13
Cas d’utilisation
POC Flight Availability
• Proposer un outils de recherche de disponibilité des vols
- Réutilisation des données du HDFS
- Client léger (Navigateur Web)
- Interface graphique riche et dynamique
• Données
- Oracle : YS_DFLS (15M), YS_DFLCS (25M), référentiel géographique
- MongoDB : Vols (3,7M), Trajets (~1000), référentiel géographique
• Démo
14
Cas d’utilisation
Eureka
• Proposer un outils de monitoring de l’activité utilisateur
- Analyser de quelle façon les utilisateurs maximisent le revenue
- Analyser la couverture des marchés
- Identifier les bonnes pratiques afin de les diffuser
- Identifier les lacunes et les combler
• Démo
15
Evolutions à venir
• MongoDB en complément et non en remplacement d’Oracle
• L’idée est donc de spécialiser chaque technologie en fonction des
usages
- Oracle :
- Normalisation et intégrité des données
- Usage transactionnel / interactif
- MongoDB :
- Performances liées à l’agrégation des données
- Usage interactif / BI dynamique
- Hadoop (MapReduce + HDFS) :
- Performances des batch
- Préparation / spécialisation des données
• Prochaine étape :
- Spark Streaming / Kafka
- Usage temps réel / évènementiel
16
Annexes
Hadoop Master
Présentation d’Hadoop Fonctionnement général / Architecture
• Objectifs d’Hadoop
- Paralléliser et distribuer des
traitements sur une ferme de serveurs
pour améliorer les performances et
permettre des traitements dont les
volumes de données sont (très)
importants.
• Ce que fournit Hadoop
- Moteur d’exécution - Gère la // et la distribution des traitements
- Gère la distribution et la réplication des
données
- Des API qui implémentent l’approche
MapReduce et l’accés au HDFS
- Un système de stockage distribué le
HDFS (Supporte différents formats (CSV,
XML, JSON, AVRO, …)
• Des outils complémentaires - Supervision
- Import / Export DB HDFS
- Abstraction (PIG, HIVE, …)
18
Serveur 1
UC
(CPU)
US
(HDD)
Grille
de
calcul
TWS
Planification des Jobs
JobTracker
Gestion de la
soumission et de
l’exécution des jobs
Grille
de
stockage
HDFS
NameNode
Gestion du HDFS
répartition et
réplication des données
TaskTracker
DataNode
Serveur 2
UC
(CPU)
US
(HDD)
TaskTracker
DataNode
Serveur N
UC
(CPU)
US
(HDD)
TaskTracker
DataNode
Nœud
d’exécution
Nœud
de
stockage
Présentation d’Hadoop L’approche MapReduce
19
Contexte d’exécution Hadoop
~1GB
Job Hadoop
Map
~Z MB
~64 MB
~X MB
Map
Reduce
~64 MB
~Y MB Map Reduce
~64 MB
• Un traitement MapReduce se décompose en 3 étapes :
1 - L’étape de Map : Préparation des données
Permet de lire, extraire / créer une clé de regroupement, transformer / formater, filtrer, …
2 - L’étape de Shuffle : Tri, regroupement et distribution
Les données en sortie du Mapper sont automatiquement triées et regroupées par clé dans
différents blocks.
3 - L’étape de Reduce : Traitement métier
Applique les règles métier sur les données regroupées par clé : Filtrer, agréger, sommer,
transformer, …
Shuffle
key
Grp2
key
Grp1
Hadoop Master
Présentation d’Hadoop Fonctionnement général
• Objectifs d’Hadoop
- Paralléliser et distribuer des traitements
sur une ferme de serveurs pour
améliorer les performances et permettre
des traitements dont les volumes de
données sont (très) importants.
• Ce que fournit Hadoop
- Moteur d’exécution - Gère la // et la distribution des traitements
- Gère la distribution et la réplication des
données
- Des API de développement qui
implémentent l’approche MapReduce et
permet d’accéder au HDFS
- Un système de stockage distribué le
HDFS (fichiers) - Supporte différents formats (CSV, XML,
JSON, AVRO, …)
• Des outils complémentaires - Supervision
- Import / Export DB HDFS
- Abstraction (PIG, HIVE, …)
20
Serveur 1
UC
(CPU)
US
(HDD)
Grille de
calcul
TWS
Planification des Jobs
JobTracker
Gestion de la
soumission et de
l’exécution des jobs
Grille de
stockage
HDFS
NameNode
Gestion du HDFS
répartition et
réplication des données
TaskTracker
DataNode
Serveur 2
UC
(CPU)
US
(HDD)
TaskTracker
DataNode
Serveur N
UC
(CPU)
US
(HDD)
TaskTracker
DataNode
Cas d’utilisation Mise à jour du programme de vol
21
D Compare Job
D Purge Job
Map Task
Read
blocks
from
splited
files
64 MB
Xml
64 MB
Xml
64 MB
Xml
Extract
Keys
Purge
XML
Xml
Xml
Xml
Sort
keys
store
Into
blocks
Map Task
Read
blocks
from
splited
files D-1 Purge Jobs
Purge Purge
Actions implemented by Developers Actions supported by Hadoop Framework
20 GB
Xml
Reduce Task
Read
data,
extract
keys,
and
values
Process all
grouped
keys
together
apply
business
rules
determine
new
Cxl, upd,
unchanged
flights
Xml
Xml
Xml
Xml
Xml
Sort
keys
store
Into
blocks
Canc.
Flights
20 GB
Xml
Xml
Xml
Xml
Xml
Xml
Purge
Xml Xml
Xml
New
Flights
Modif.
Flights
Unch.
Flights
Xml
20 GB
Xml
Avec Hadoop
Sort
keys
store
Into
blocks
Split and
purge data
Xml
Xml
Xml
Launch and
manage
Threads
Resquest, compare, apply rules, and update data
Resquest, compare, apply rules, and update data
Resquest, compare, apply rules, and update data
Avec un
SGBD
Complexité à la charge du développeur La quasi-totalité du traitement repose sur la BD PB Contention
PB Puissance
Cas d’utilisation
Optimisation des traitements (1/2)
Décomposer pour mieux paralléliser
• Approche séquentielle
• Approche optimisée
22
Donnée X
• A
• B
• C
• D
Job 1
Donnée X
• A
• B
• C
• D
Job 2
Donnée X
• A
• B
• C
• D
Donnée X
• A
• B
• C
• D
Job 1
Job 2 Job 3
Merger
Donnée X • A
• B
• C
• D
• Signature
Donnée X
• A
• B
• C
• D
Conf.
règles
Job 3
Donnée X
• A
• B
• C
• D
Job 3
Donnée X • A
• B
• C
• D
• Signature
Donnée X • A
• B
• C
• D
• Signature
Cas d’utilisation
Optimisation des traitements (2/2) 23
• Optimiser par le séquencement et la disponibilité des données
- Démultiplication du nombre de jobs Hadoop
- Analyse des entrées / sorties de chaque jobs
- Déterminer le séquencement optimal des traitements
- Les traitements se lancent uniquement lorsque l’ensemble des données
sont prêtes
- Plus il y a de traitements parallélisés mieux on utilise la grille
Cas d’utilisation
Equilibrage des traitements (1/2) 24
Donnée X Job 1
Donnée Y
L’application des
règles métier créent
un déséquilibre dans
le volume des
données regroupées
selon la clé choisie
Job 2
Map Reduce
Map Reduce
Map Reduce
Map Reduce
Grp clé 3
Grp clé 2
Grp clé 1
Grp clé 4
Donnée Z
Le temps de traitement est égal au temps du job le plus long
(dont le volume de données à traiter et le plus important)
Risque qu’un reducer ne tienne pas en mémoire
Cas d’utilisation
Equilibrage des traitements (2/2) 25
Donnée
X Job 1
Donnée Y
L’application des règles
métier créent un
déséquilibre dans le
volume des données
regroupées
Job 2
Map Reduce
Grp clé 3
Grp clé 2
Grp clé 1
Grp clé 4
Donnée Z
Les temps de traitement sont
équilibrés
Levée du risque lié à la
mémoire nécessaire au
traitement du reduce
Map Reduce
Map Reduce
Map Reduce
Map Reduce
Map Reduce
Job
Stats
(Map)
Analyse les volumes / clé
et calcul un discriminant
technique pour mieux
équilibrer les groupes de
clés
Stats
volumes
Donnée Y
Grp clé 3
Grp clé 1
Grp clé 2a
Grp clé 2b
Grp clé 4a
Grp clé 4b
Grp clé 4c
Job
Stats
(Map)
Axes d’amélioration et évolutions
Migration vers Hadoop 2
• Introduction de YARN
- Plusieurs moteurs
d’exécution
- Meilleure gestion des
ressources
- amélioration des
performances
- Permet de gérer
plusieurs applications
26
• Traitement interactifs
- HIVE, HBASE, …
- Ouverture des données du HDFS à des applications tierces
- Accès aux données simplifié par l’utilisation de langages de Scripts / SQL Like
• Traitement temps réel :
- Storm, Spark Streaming, …
- Intégration des évènements / CEP