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

3. | 3

4. | 4
UN SYSTÈME ELECTRIQUE EN MUTATION
Mots Clefs :
Centralisé
Intégré
Descendant
Mots Clefs :
Centralisé / Décentralisé
Local
Diversité
Nouveaux Usages
Clients Acteurs
Multiplication des acteurs
Enjeux climatiques
Eco-Efficacité
…
(src image : ERDF )

6. LIGHTS MUST GO ON!

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

9. | 9
LOCAL

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

11. | 11
MODELES GAM : GENERALIZED ADDITIVE MODEL

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

16. | 16
DESCRIPTION GÉNÉRALE
16
16
Predictive model
Développement R
mono-nœud
Production - Hadoop

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