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

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

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 10.000 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 ;-)

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 : 225 000 msg / seconde Trackers Ads Targeting Total : 2.4 Milliards de documents 1.3 To Pic : 26 100 read / s

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 : 400-800M 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

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

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

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

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

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

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 

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

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

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

Merci pour votre attention Questions / Réponses Chris - CTO christophe@ogury.co Boris – Senior Data Scientist boris@ogury.co