Big Data, Machine Learning & Targeting sur 400 Millions de users

Présentation au sujet: "Big Data, Machine Learning & Targeting sur 400 Millions de users"— Transcription de la présentation:

1

2 Big Data, Machine Learning & Targeting sur 400 Millions de users
Evolution de l’architecture et des process de traitement

3 Présentation de la société
Création en 2014 A l’origine un SDK Android, 2 tâches - Récolte de données - Affichage publicitaire in-app ultra ciblée Maitrise à la fois la récolte de données, son stockage et les différents traitements Vient de l’adtech mais en transformation depuis fin 2015 vers une Mobile Big Data Company

4 Quelques chiffres clés
CA 2015 : 10M$ (rentable dès sa première année d’existence) CA 2016 : Croissance à 3 chiffres Notre SDK est présent dans près de apps et 400 Millions de téléphones 2 milliards de call APIs journalier sur le backend (data & advertising) Près de 8 To de données récoltées chaque jour (donnée brute) Staff Ogury : - Plus de 100 personnes (35 personnes fin 2015) - Bureaux à Londres, Paris, Madrid, Milan, NYC - Equipe IT de 30 personnes …. Et nous recrutons tout type de talent ;-)

5 Flux de données et traitements fin 2015
Total (S3 / Glacier) : 460 To Calls Datas & Ads Datas devices Pic: 1.2 million requêtes / mn Moyen: ~ 1.9 milliards / jour Pic : msg / seconde Trackers Ads Targeting Total : 2.4 Milliards de documents 1.3 To Pic : read / s

6 Targeting Tâche principale : Matching de patterns (urls/domaines ou noms d’application) sur des logs de navigation et d’usage. Nombre N de patterns : 40-60K - Entrées M dans logs : M Job EMR Map/Reduce sur bucket S3 Cluster d’une dizaine de machines c3.8xlarge Algorithme initial (complexité N*M) : 13H de traitement pour 2 jours de données Algorithme optimisé par compilation des patterns via un automate (complexité M) : 1.5H pour 10 jours de données

7 Suivi des KPIs de déliverabiltié des publicités
Le duo ElasticSearch/Kibana permet une gestion aisée : - Constitution de dashboards de suivi opérationnel par les équipes - Plug de l’interface web de gestion (interne & client) pour requêtage - Outils pour l’exploration des données Seul les données relatives aux KPIs des publicités se trouvent dans ElasticSearch

8 Processus de traitement des données
Avant: Cher, long, non scalable

9 Processus de traitement des données
Aujourd'hui: Économique, efficace, scalable

10 Objectif : AdTech vers Mobile Big Data Company
Rendre la donnée plus facilement exploitable "Densifier" l'information contenu dans les données Améliorer la qualité des données Optimiser la vitesse de lecture Facilité la gouvernance et la sécurité des données Permettre un accès aisé à tout type d’utilisateur (BA, Développeurs, Data Scientist) Choix de l’outil : Redshift Pourquoi redshift Massivement distribué Scalable Performant Requêtage SQL, donc simple d’accès Bench de Vertica prévu sur Janvier

11 Point central : Base de données OLAP
ETL Entreposage Cas d’utilisation RDS Autres BD relationnelles (administration, campagnes, …) 3 To de données utiles 25 Milliards d’enregistrements API web analytique Datamart BD dédiée à une application Intégration Agrégation et croisement des données sources Exploration Dataviz, tests d'hypotheses, tendance, nouvelles features, ... chargement Web restful APi (external data) Redshift SGBDR Machine learning Apprentissage automatique S3 (device data) Daily-cleansing: Dédoublonnage, standardisation, réparation, écriture en Parquet Analytics Études et tableaux de bord trash Données non réparables

12 Exploration des données
Prototypage rapide et génération d'études marketing Idée du slide : Présenter les travaux d’exploration de données effectuées, les orders de grandeur des données manipulées et les temps de réponse  Parler aussi du plug d’une solution style tableau par dessus 

13 Apprentissage supervisé Test de nouvelles features et génération de jeux de données

14 Apprentissage supervisé & Datamining
Génération des données d'apprentissage et de test Exploration, analyse et apprentissage supervisé Stockage des données Features issues de données structurées (sites visités, apps installés) Spark-ml: (Lasso, ALS, clustering, …) > 16 Go ~ 400 Go Redshift ~ 80Go < 1 To S3 < 16Go R: glmnet, irlba, Factominer, shiny, … Python: scikit-learn, numpy, panda Features issues de données trop volumineuses ou peu structurées (Scores collaborative filtering,  clustering, NLP, …) S3

15 Points clés Structuration des données en cube OLAP
Des processus ETL efficaces et fiables Création de datamarts dédiés pour soulager Redshift  Dimensionnement du cluster  Ne pas intégrer tout type de données dans Redshift (description des apps pour classification NLP) La techno ne fait pas tout : Passer du temps sur l’optimisation Clé de distribution  Clé de tri

16 Merci pour votre attention
Questions / Réponses Chris - CTO Boris – Senior Data Scientist