Transférer 1 600 000 comptes utilisateurs sans douleur avec Akka Streams

Comment feriez vous pour transférer 1 600 000 comptes utilisateurs d’un système vers un autre ? Alors que vous n’avez pas de système d’ingestion en masse mais seulement des APIs REST qui prennent un seul compte à la fois. Comment rajouter une nouvelle donnée sur plusieurs millions de documents pour une évolution fonctionnelle ? Chez Groupe La Centrale il nous arrive de devoir faire des scripts de migration, d’import ou de rattrapage de données. Que ce soit parce que l’on souhaite transférer des données d’un système à un autre, parce que l’on doit corriger une donnée quelque part ou parce que l’on a changé un format et que l’on souhaite rendre d’anciens documents compatibles afin de simplifier le code.

Tous ces besoins ont en commun

• ils n’ont pas forcément vocation à être utilisé très souvent (peut-être seulement une fois)
• ils peuvent être amenés à devoir manipuler une quantité relativement importante de données
• ils peuvent causer une charge importante sur les systèmes de production au moment de leur(s) exécution(s)
• on veut avoir une idée du temps d’exécution et être capable de l’optimiser (sans écraser la prod)
  
  Parmi les solutions qui existent, j’aimerais vous en présenter l’une d’entre elles que j’aime beaucoup. Il s’agit d’Akka Streams.

Automatiser votre cycle de vie Machine Learning

Dans le cadre de la mise en place d’un système de détection de fraude sur le site La Centrale, un système de Machine Learning a été conçu pour entraîner des modèles de détection de fraude.

Comme on aime les choses bien faites chez Groupe La Centrale, on cherche toujours à automatiser les tâches : faire de l’infrastructure as code.

En général, pour automatiser les déploiements, on utilise des services AWS : CloudFormation, Serverless et AWS CDK.

Ce qu’on attend de ce pipeline est de nous permettre de :

• Récupérer les datasets nécessaires pour nos trainings
• Préparer ces données pour qu’elles soient exploitables par AWS SageMaker
• Faire les trainings
• Extract du meilleur modèle
• Évaluer les performances de notre modèle

Feature Flipping : Et si on centralisait l’état de nos micro-services ?

Bonjour à tous !

Chez Groupe LaCentrale, nous prenons très au sérieux la disponibilité et la surveillance de nos applications. Nous développons tous les jours de nouveaux services utilisés par des collaborateurs aux métiers divers de l’entreprise mais aussi par des clients externes comme vous.

C’est pour cela que nous prenons soin au sein de chaque équipe de suivre nos applications à l’aide de dashboards présents dans les open space. Ils avertissent des problèmes techniques survenus en direct et nous alertent par notification dès qu’un problème survient. Chaque équipe est responsable de son périmètre.

Cependant, une erreur applicative n’est pas nécessairement provoqué par l’équipe propriétaire de l’application. Cela peut être la conséquence d’un problème survenu précédemment dans le traitement du logiciel. Par exemple lors d’un appel à un service tiers.

Machinator pour les nuls

Le Lab

Matchinator est un projet réalisé pour le challenge « Lab » organisé par la société Carboat Média et dont la présentation finale s’est déroulée au cours du séminaire 2018 à Barcelone. L’objectif de ce challenge consistait à proposer un prototype à partir d’un des objets connectés mis à la disposition de tous les participants (Raspberry Pi, Google Home, Lego Mindstorms, Alexa, Horloge connectée, etc). Ces projets devaient être réalisés en équipe, et chaque équipe était mise en concurrence afin de déterminer, au travers d’un vote d’environ 70 personnes, le projet qui respectait au mieux les principaux critères, à savoir : idée innovante, qualité de la réalisation et qualité de la présentation.

ScalaIO 2017

La 4ème édition de ScalaIO a eu lieu les 2 et 3 novembre 2017 dans les locaux de l’école CPE à Lyon. Il s’agit de l’événement principal de la communauté Scala en France mais il y a également une forte composante internationale avec environ la moitié des talks qui sont donnés en anglais et de nombreux participants et speakers étrangers.

Comme chaque année, nous avons eu droit à une excellente conférence avec de très bonnes sessions, de nombreux speakers renommés et une organisation remarquable. Cette année un accent particulier avait été mis sur l’ouverture aux moins expérimentés avec pas mal de communication en amont sur cet aspect et les deux tiers des talks qui étaient accessibles aux débutants.

Ceux qui veulent faire fondre leurs neurones n’étaient pas en reste pour autant avec comme à l’accoutumée des sessions avancées sur des sujets complexes tels que la théorie des catégories ou bien toutes les merveilles que l’on peut faire avec le système de types de Scala. Autre nouveauté de cette année, l’ensemble des sessions a été filmé et elles devraient donc être très certainement disponibles prochainement en streaming.

Serverless : API de recherche la centrale

Plusieurs articles sur les architectures AWS API Gateway et AWS Lambda pointaient du doigt certains problèmes tout en reconnaissant les nombreux avantages de ces nouvelles stacks.
Nous avons lancé un projet pilote 100% Serverless sur Amazon Web Services afin de nous faire notre propre idée.

L’objectif était le suivant :

• Offrir une API REST de recherche utilisant ElasticSearch comme moteur de recherche
• Scalabilité totale
• Temps de réponse lors des pic à 600 requêtes par seconde :
  • Moyenne < 40ms
  • p50 < 10ms
  • p95 < 90ms
  • p99 < 200ms
• Rester dans des couts comparables à une architecture REST classique
• Temps avant mise en production : 1 mois

Comment j’ai vécu mon premier Hackathon

Qui veut aller à un hackathon ?

Quand on nous a parlé du hackathon je me suis dit ‘c’est pas pour moi, c’est pour les gens qui dorment avec leur ordinateur’.

Après quelques jours de réflexion je me suis dit que moi-même je passe quand même environ 16 heures par jour sur l’ordinateur (le temps cumulé entre le travail et à la maison), que moi aussi je suis curieux,  et que moi aussi j’aime bien faire ceci cela (la preuve c’est que j’ai toujours un projet perso en cours sur lequel je bosse sur mon temps libre).

Quand nos annonces prennent l’R : Nettoyage

Cette article fait suite au premier article sur la découverte des données.

Après avoir identifié nos données, l’étape suivante dans tous projets de machine learning est de “nettoyer la donnée”, ceci afin de la rendre plus facilement exploitable et de supprimer les cas incohérents ou trop marginaux (outliers)

cars <- read.csv("finalcars.csv", sep=",", header=TRUE, stringsAsFactors = FALSE)

stringsAsFactors = FALSE nous permet de désactiver la conversion automatique en Factor, cela nous permet d’éviter des optimisations intempestives et notamment de conserver le millésime (yearModel) en tant qu’entier

• En visualisant le résumé du dataframe, nous observons des NA que nous supprimons :

summary(cars)

##     brand              model             version         
##  Length:258320      Length:258320      Length:258320     
##  Class :character   Class :character   Class :character  
##  Mode  :character   Mode  :character   Mode  :character  
##                                                          
##                                                          
##                                                          
##                                                          
##   yearModel           mileage             gearbox             energy      
##  Length:258320      Length:258320      Min.   :     0.0   Min.   : 1.000  
##  Class :character   Class :character   1st Qu.:     2.0   1st Qu.: 2.000  
##  Mode  :character   Mode  :character   Median :     2.0   Median : 2.000  
##                                        Mean   :    13.7   Mean   : 1.905  
##                                        3rd Qu.:     2.0   3rd Qu.: 2.000  
##                                        Max.   :999999.0   Max.   :11.000  
##                                        NA's   :123        NA's   :7       
##      doors           powerDin         priceNew           price        
##  Min.   : 0.000   Min.   :    -1   Min.   :      0   Min.   :      0  
##  1st Qu.: 4.000   1st Qu.:    90   1st Qu.:  17200   1st Qu.:   9600  
##  Median : 5.000   Median :   111   Median :  24000   Median :  13990  
##  Mean   : 4.314   Mean   : 65529   Mean   :  26400   Mean   :  17384  
##  3rd Qu.: 5.000   3rd Qu.:   149   3rd Qu.:  31000   3rd Qu.:  20500  
##  Max.   :11.000   Max.   :999999   Max.   :1076400   Max.   :4190000  
##  NA's   :1

Quand nos annonces prennent l’R

Cette présentation fait suite au tools in action que nous avons donné à Devoxx cette année. L’objectif étant de montrer l’intérêt de R pour découvrir, nettoyer puis enrichir nos données avec des approches de type machine learning.

Chez Car&Boat Media, grâce au site de dépot d’annonces de véhicules d’occasions lacentrale.fr, nous avons à notre disposition plus de 280 000 annonces en publication. Nous souhaitons dans cette présentation vous montrer ce que l’on peut faire très facilement avec R pour découvrir, manipuler et jouer avec la donnée en partant d’un simple dump de ces annonces.

Pour illustrer cela de façon concrète nous allons élaborer un modèle simple de prédiction de prix de vente d’un véhicule (algo supervisé), un équivalent de la cote automobile.

Ensuite nous formerons des groupes de données proches en utilisant un algo non supervisé cette fois (kmeans) pour définir des catégories de véhicules.

Partie 1 : découverte du dataset

Nous avons obtenu un dump au format CSV de toutes les annonces en cours de publication, nous allons l’explorer pour déterminer ce que nous allons pouvoir en faire.

• Chargement du fichier csv :

cars <- read.csv("finalcars.csv", sep=",", header=TRUE)

Nous créeons ainsi le dataframe cars, structure composée de lignes et de colonnes, que l’on peut assimiler à une table en BDD relationelle.

• A quoi ressemblent nos premières lignes :

head(cars)

##    brand model                                   version yearModel mileage
## 1 ABARTH   500      1.4 16V T-JET 595 50EME ANNIVERSAIRE      2014     500
## 2 ABARTH   500                      1.4 16V T-JET ABARTH      2012   46750
## 3 ABARTH   500                   1.4 16V TURBO T-JET 140      2012   52250
## 4 ABARTH   500 1.4 16V TURBO T-JET 160CH 595 TURISMO BVR      2012    8800
## 5 ABARTH   500 1.4 16V TURBO T-JET 160CH 595 TURISMO BVR      2013   17850
## 6 ABARTH   500 1.4 16V TURBO T-JET 160CH 595 TURISMO BVR      2013    6911
##   gearbox energy doors powerDin priceNew price
## 1       1      1     3   999999        0 31990
## 2       2      1     3      134        0 13500
## 3       2      1     2   999999        0 14500
## 4       1      1     3      140        0 20690
## 5       1      1     2      140        0 19990
## 6       1      1     2      160        0 21980