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 – maayas@airfrance.fr

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