L'approche Model as Code par Benoit Grossin (EDF-R&D) et Matthieu Vautrot (Quantmetry)
La mise en production de modèles est une étape charnière du cycle de vie d’un projet Data Science mené au sein d’une entreprise.
On observe que cette partie est encore rarement industrialisée alors qu’elle est indispensable pour l’exploitation continue des résultats des modèles.
Lorsque qu’un modèle finalisé présente un pouvoir prédictif satisfaisant en phase de développement, l'industrialisation de sa mise en production permet de le déployer et de l’exploiter de manière continue et automatique et ce, en minimisant la charge de travail.
Notre intervention présentera notre retour d'expérience dans le contexte EDF sur la mise en place d'une approche capable de raccourcir voire d'annuler le temps de mise en production dans un environnement Hadoop et plus particulièrement Hive.
Benoit Grossin est Ingénieur de Recherche chez EDF-R&D ICAM
Matthieu Vautrot est Consultant Analytics & Big Data chez Quantmetry
1. « MODEL AS CODE » A LA R&D D’EDF
ETUDE DE MISE EN PRODUCTION DE MODÈLES DE PRÉVISIONS DE CONSOMMATION ÉLECTRIQUE
HUG – Janvier 2016
Contact : benoit.grossin@edf.fr + mvautrot@quantmetry.com
Contributeurs : Département ICAME/OSIRIS de
la R&D d’EDF + QuantMetry
2. | 2
« MODEL AS CODE » À LA R&D D’EDF
1. EVOLUTION DU SYSTÈME ÉLECTRIQUE ET RÉVOLUTION DE LA DONNÉE DANS LE SECTEUR
2. LA PRÉVISION LOCALE DE CONSOMMATION D’ÉLECTRICITÉ
LES MODÈLES STATISTIQUES GAM, UNE APPROCHE NOUVELLE ET EFFICACE
3. SORTIR LES MODÈLES GAM DES OUTILS STATISTIQUES POUR LES METTRE EN PRODUCTION
MODEL AS CODE : APPROCHE IN-DATABASE / APPROCHE WEB-SERVICES
4. PRÉSENTATION TECHNIQUE DE L’APPROCHE
5. CONCLUSION & PERSPECTIVES
7. | 7
CONTINUER À BIEN PILOTER UN SYSTÈME DE
PLUS EN PLUS COMPLEXE
Continuer à assurer l'équilibre offre/demande d'électricité, détecter les incidents,
éviter les temps de coupure … dans un système qui se complexifie
« Depuis cinq ans, le nombre des producteurs
d’énergie photovoltaïque et éolienne a décuplé.
Ils devraient être 1 million d’ici 2020 »
« 2 millions de véhicules électriques pourraient circuler
en France d’ici 2020. La recharge de ces véhicules est
mobile et imprévisible : au domicile du conducteur le
soir, au bureau, dans la rue, …»
Tous les acteurs du secteur Electrique sont impactés
ERDF (principal gestionnaire du réseau de distribution en France) est l’acteur
clef et incontournable de la réussite des évolutions en cours du système
électrique – et se donne pleinement les moyens de le faire : Linky par exemple
(src image : Wikipedia)
(src citation : site ERDF)
8. | 8
SMART METERING DATA & ANALYTICS :
UN CHANTIER À FORT ENJEU POUR EDF
Projet Linky par ERDF : un besoin pour les enjeux énergétiques de demain
35 millions de Smart Meters (horizon 2020) = un levier formidable pour mieux observer
et mieux exploiter un tel réseau de distribution
Des données nécessaires : par exemple pour mettre en place des stratégies de gestion
de l’équilibre offre / demande au niveau local
(Big) Data, un enjeu nouveau pour le secteur Electrique
Les données et leurs traitements avancés sont au cœur de nombreux travaux dans le
groupe EDF
On n’a jamais autant parlé de Big Data et de Data Science à EDF que maintenant !
Défis pour nos métiers : bien exploiter les opportunités liées au Data - faire mieux ou
faire plus –
Défi associé pour nos équipes SI : comment intégrer et mettre en production dans les
SI ces nouveaux traitements proposés ?
Etude « MODEL AS CODE » par la R&D d’EDF
10. | 10
PREVISIONS DE CONSOMMATIONS ELECTRIQUES
Prévision nationale = domaine bien maîtrisé par EDF depuis de nombreuses années
avec 1 modèle de prévision performant – en lien avec la météo
Prévision à la maille locale (maille fine réseau de distribution, ville, quartier, …) =
domaine en forte émergence, nécessaire sur des enjeux de gestion locale de l’équilibre
d’offre/demande et de smart city par exemple
2 problèmes différents
L’agrégat de consommation France est relativement stable : effet foisonnement
La prévision locale est plus difficile : effet de foisonnement moindre, impact plus
important d’évènements locaux, multiplication des modèles de prévisions à gérer, …
Les modèles GAM pour la prévision locale
La R&D d’EDF met au point différents modèles et approches pour bien prévoir à la
maille locale
Les modèles GAM se sont révélés d’excellents candidats : performants et interprétables
12. | 12
MODELES GAM : GENERALIZED ADDITIVE MODEL
Prévisions CT à la maille PS avec GAM
13. | 13
MISE EN PRODUCTION DES PRÉVISIONS GAM :
PMML ?
Une version spécifique des modèles GAM …
GAM est une famille de modèle, disponibles dans plusieurs outils statistiques
Ceux disponibles dans le package R / MGCV sont ceux qui performent le mieux sur nos
problématiques
… à mettre en production
GAM n’est pas supporté par le standard PMML
PMML = Predictive Model Markup Language uses XML to represent models (www.dmg.org/v4-1/GeneralStructure.html)
(src image : OpenScoring)
14. | 14
MISE EN PRODUCTION DES PRÉVISIONS GAM :
L’APPROCHE MODEL AS CODE
Comment mettre en production des modèles GAM, ajustés dans R / MGCV ?
Plusieurs pistes explorées par la R&D d’EDF, dont :
Le mode « in-database », présenté ici dans l’environnement Hadoop/HIVE
Le mode « web-services » pour consommer des modèles de prévisions
Travail présenté par Matthieu ce soir
15. | 15
MISE EN PRODUCTION DES PRÉVISIONS GAM :
L’APPROCHE MODEL AS CODE
Model as code :
déployer et utiliser un modèle R en l’état
Trois objectifs :
1. Réduire sensiblement le temps de déploiement des modèles R
2. Une approche générale : même code pour tous modèles
3. Stabilité en performance
15
17. | 17
DESCRIPTION GÉNÉRALE
17
17
1 Sérialisation
Predictive model
(rds, rda)
1
Développement R
mono-nœud
Production - Hadoop
Sérialisation : Objet R de la RAM au FS
18. | 18
DESCRIPTION GÉNÉRALE
18
18
1 Sérialisation
2 Déploiement
Predictive model
(rds, rda)
1
2
Développement R
mono-nœud
Production - Hadoop
Déploiement : push du fichier RDS vers la plateforme de prod - exemple scp
19. | 19
DESCRIPTION GÉNÉRALE
19
19
1 Sérialisation
2 Déploiement
3 Prédiction ?
Predictive model
(rds, rda)
1
2
3
Développement R
mono-nœud
Production - Hadoop
Prédiction : interaction entre l’objet R (rds) et la plateforme de production – call du
predict()
20. | 20
STREAMING OU ENCAPSULATION ?
20
Hadoop (Pig, Hive) streaming :
• très peu de configurations
• facile à implémenter
• utilisation de l’I/O standard
hadoop jar $HADOOP_PATH/hadoop-
streaming-XXX.jar
-input dir_input
-output dir_output
-mapper script.r
-files script.r, model.rds
21. | 21
STREAMING OU ENCAPSULATION ?
21
hadoop jar $HADOOP_PATH/hadoop-
streaming-XXX.jar
-input dir_input
-output dir_output
-mapper script.r
-files script.r, model.rds
Encapsulation (MR, ou UDF):
• meilleur contrôle sur les données
d’input
• du code java qui tourne du code
java
• besoin de faire communiquer
Java et R
Hive
UDF
Hadoop (Pig, Hive) streaming :
• très peu de configurations
• facile à implémenter
• utilisation de l’I/O standard
22. | 22
rJava est une librairie qui fusionne deux projets :
JRI permet d’ouvrir une session R dans Java
rJava permet d’utiliser du Java dans R
1 – Lancement du moteur R : Rengine engine = Rengine.getMainEngine();
2 – Exécution de commande R : rengine.eval("dt <- read.csv("myfile.csv')");
rJava
COMMUNICATION ENTRE JAVA ET R - RJAVA
22
la requête R en paramètre
rJava JRI
23. | 23
UDF : CYCLE DES DONNÉES
23
cheminement input cheminement résultats
Lance le modèle sur les données reçuesR
Gère la session R et le
lancement du code R
UDF
JRI
Récupère les résultats
d’output de R
gère les données
d’input et prépare le
code R
UDF
Envoie les résultats à
Hive
lancement de la
requête HQL
Hive
Agrège et retourne les
résultats
JRI
Predictive model
24. | 24
HIVE UDF OU HIVE GENERIC UDF ?
24
Hive UDF : structure minimaliste pour tests ou cas simples
Hive generic UDF – un peu plus complexe à écrire mais …
• Gère un nombre dynamique de paramètres
• Meilleur gestion des valeurs NULL
• Gestion de paramètre constant
25. | 25
HIVE UDF OU HIVE GENERIC UDF ?
25
Hive UDF : structure minimaliste pour tests ou cas simples ou
Hive generic UDF – un peu plus complexe à écrire mais …
• Gère un nombre dynamique de paramètres
• Meilleur gestion des valeurs NULL
• Gestion de paramètre constant
import org.apache.hadoop.hive.ql.udf.generic.GenericUDF;
Best practice :
26. | 26
Sur chaque nœud :
1. Installation de R et rJava (+JRI) ;
2. Installation des packages R requis par le modèle ici {mgcv} ;
3. Set des variables d’environnement ($R_HOME, et ajout de jri dans
$LD_LIBRARY_PATH) ;
4. Lien symbolique de fichiers .so de jri vers hadoop native lib ;
STEP 1 – CONFIGURATION DES NŒUDS
26
DN_1
…
DN_2
…
DN_N
…
…
27. | 27
UDF – MAPS PARAMETERS AND VALUES
- ENTRAINEMENT DU MODÈLE SUR R
27
new_model <- gbm(formula=‘y~R1+R2’)
Features
target
28. | 28
UDF – MAPS PARAMETERS AND VALUES
28
data <-dataframe(R1=f1,R2=f2)
…
predict(new_model, data);
JRI
new_model <- gbm(formula=‘y~R1+R2’)
Features
29. | 29
UDF – MAPS PARAMETERS AND VALUES
29
SELECT my_udf(
"new_model:R1+R2",
f1, f2
)
FROM data_table ;
UDF
data <-dataframe(R1=f1,R2=f2)
…
predict(new_model, data);
JRI
new_model <- gbm(formula=‘y~R1+R2’)
Features
30. | 30
REQUÊTE SQL ET CODE JAVA
30
add jar JRI.jar genUdf.jar;
add file new_model.rds;
SELECT my_udf(
"new_model:R1+R2",
f1, f2
)
FROM table_data ;
31. | 31
31
Number of
rows
Data size
(o)
Nb. Mappers Time (s) Memory
1 34 1 51 OK
… … … … OK
10,000,000 441M 2 110 OK
100,000,000 4.4G 18 1312 OK
Hive UDF
RESULTATS – VM CLOUDERA
IT SCALES !!
32. | 32
32
SPARK ?
PySpark (API Python de Spark) :
• setup entre python et R avec rpy2 ~1 ligne
• load de la table à scorer en RDD (via sparkQL ou DataFrame) ~ 1 ligne
• une fonction map avec une fonction appel du predict de R ~ 1 ligne
33. | 33
33
SPARK ?
PySpark (API Python de Spark) :
• setup entre python et R avec rpy2 ~1 ligne
• load de la table à scorer en RDD (via sparkQL ou DataFrame) ~ 1 ligne
• une fonction map avec une fonction appel du predict de R ~ 1 ligne
SparkR (API R de Spark depuis v. 1.4 ) :
• load de la table à scorer en RDD (via sparkQL ou DataFrame) ~ 1 ligne
• une fonction map avec une fonction appel du predict de R ~ 1 ligne
34. | 34
CONLUSIONS & PERSPECTIVES
Etude d’intégration des modèles GAM (R / MGCV) dans Hadoop pour la problématique
de la prévision locale de consommation d’électricité
L’approche « Model As Code » est séduisante :
Pour les métiers : mettre en production rapidement des modèles et analytics innovants
Pour les équipes SI : intégrer les besoins nouveaux des métiers en analytics sans
développement long ou trop complexe
Depuis cette étude réalisée début 2015, on a prototypé l’intégration d’autres traitements
analytiques dans des environnements SI opérationnels avec plusieurs techniques :
Celles en mode « in-database » : au plus proche de données, couplées avec la
mécanique distribuée de la base de données
Celles en mode « webservices » : découplées des entrepôt de données, mais
facilement consommables par différentes applications et des besoins divers
scalabilité
accessibilité
RRO/RREDEPLOYR