du batch au temps réel Maxime Mézin Data & Photo Science Director
Leader Européen du tirage et du livre photo Plus 30 millions de membres 17 pays Stockage de milliards de photos
Développement international
Une stratégie de couverture géographique France et Angleterre Europe continentale Angleterre, Australie et Etats- Unis France, Angleterre et Allemagne Global Europe du Sud (Espagne et Portugal) et région DACH Multi-produits, multi-channel et multi géographies
Projet Redshift / Batch
Problématique Des traitements de rafraichissement du datawarehouse trop long 8h en temps normal Jusqu à 12h en période de Noël Une limitation en terme de stockage 5 To avec uniquement les données de ventes du site Nécessité de remplacer le Hardware Acquisition d un environnement de développement à un prix élevé Nécessite un contrat administration distante (DBA externe) Problème de modèle de licence pour connecter notre outil de reporting
Les besoins pour le futur Croiser l ensemble des sources de données de l entreprise afin d améliorer : La satisfaction client Le ciblage CRM Le reporting Affiner le reporting au niveau le plus fin : la photo
Résultat du POC Chargement : 4 jours pour extraire les données côté Photobox Entre 50 minutes et 5 minutes pour charger les données dans Redshift Performances : Count(*) impossible à lancer sur la table photos sur le slave Mysql 3 secondes sur Redshift Fonctions : Quasiment équivalentes (ex: manque le pivot/unpivot) Flexibilité : Passage de 1 à 8 nœuds en 6h Création d un environnement de dev en quelques minutes
Architecture Actuelle
Performance Avant / Après L alimentation quotidienne du datawarehouse se fait en 2 étapes Récupération des données sur une base slave du site Calcul des agrégats Avant EMR / Redshift Chargement : 1h30 Chargement : 1h (limitation DB slave) Agrégation : 6h Agrégation : 40 min (9 x plus rapide)
Performance Temps de traitement observé en fonction du nombre de nœuds 120 100 80 60 40 Perf (min) 20 Perf (min) 0 2 4 8 5 To avant (données + index), 500 Go sur Redshift!
Coût avant / après Avant Opex : 70 k Support Licence : 30 k External DBA : 40 k Capex : 20 k / an (amorti) Total : 90 k Redshift Opex : Redshift + EMR = 17 k$ = 13 k => 7 x moins cher Pourquoi la région US East? Initialement le service n était pas disponible dans les autres régions Pas de contrainte de latence (90 ms US East vs 30 ms IRL)
Sécurité VPN / VPC et ou Firewall SSH Cryptage Légal : Safe Harbor Act La sphère de sécurité (Safe Harbor) permet à une entreprise américaine de certifier qu'elle respecte la législation de l'espace économique européen (EEE) afin d'obtenir l'autorisation de transférer des données personnelles de l'eee vers les Etats-Unis.
Conclusion Plus de fiabilité Un budget divisé par 7 Des performances a minima 10 fois meilleures Une capacité de stockage multipliée par 32 Une scalabilité simplifiée
Projet Kinesis / Temps Réel
Objectifs Gestion de la relation client en temps réel Cas d utilisations : Envoyer un email d inscription basé sur le produits qui intéresse le membre Tracking des pages produits vues en tant que non inscrit Détecter les nouveaux inscrits et tenter de les réactiver s ils quittent le site sans action engageante (upload photos, création d un produit, achat) Personnaliser le site en fonction des actions, pages vues précédentes
Website Architecture Put Put Get KCL Apps Copy Put Put Photos upload Put Log records sent to Neolane Buffer Backup Put Get & Put Master Workers.. Get Put Slave Babel Metrics Emitter Put
Métriques du système Item Kinesis Stream Elasticache (Redis) Master Worker KCL Apps Max Capacity 1000 msg/second per shard 30 000 msg/second Plus de 500 req/second N x 30msg/second 2000 req/second Site Web + Upload envoient très peu de messages (5% de la capacité du stream) GA peut envoyer jusqu à 200 msg/second (20% de la capacité du stream) Plusieurs workers peuvent être lancés en cas d augmentation de la charge
Processus détaillé Emetteurs GA & Site web (Step 1) 1. Ajoute l événement à User Events List 2. Met à jour le dernier événement de l utilisateur dans Active Users Zset Master (Step 2) Toutes les 20 secondes: 1. Listes des utilisateurs dont le dernier événement est supérieur à X min dans Active Users Zset 2. Pousser l utilisateur vers la file de traitement Workers Queue 3. Effacer l utilisateur de Active Users Zset Active Users Zset User Events List Workers Queue Processed Users Zset Worker (Step 3) 1. Lit les utilisateurs de la file de traitement Workers Queue 2. Exécute le traitement lié à l évènement 3. Ajoute à la liste Processed Users Zset Redis
Site Web Nb Put Requests Monitoring Nb Get Requests Nb Processed Records Select count(*) Upload Nb Put Requests Master Processed Buffer Queue Size Workers Processed Workers.. Backup Master Slave Web Site CPU Memory Evictions Reclaimed Metrics Emitter
Améliorations en cours Intégrer des modèles de machine learning Recommandation produit sur les pages du site web Proposition d upsell en cohérence avec le panier Sécuriser les données stockées dans ElastiCache en cas de crash
Merci