CARREFOUR LINKS PILOTE LES TRANSFERTS DE DONNÉES AVEC LE SERVERLESS
Le groupe Carrefour compte 100 millions de clients dans 31 pays, ce qui représente une masse de 3 milliards de tickets de caisse par an. Des données que Carrefour centralise grâce au Serverless pour les commercialiser auprès des industriels.
CARREFOUR LINKS a été créé en 2021 afin de commercialiser les données du groupe à destination des industriels du CPG («Consumer Packaged Goods », biens de consommation emballés) comme Coca-Cola, Nestlé, L’Oréal. Le groupe Carrefour se compose de huit pays intégrés et de 23 pays franchisés. Pour alimenter le data lake de Carrefour Link, il faut collecter les données auprès de chacun de ces pays.
«Ce sont des milliards de lignes de tickets de caisse qu’il faut décomposer en produits, puis ensuite rassembler par CPG » résume Guillaume Blaquiere, Group Data Architect chez Carrefour. « C’est un gros chantier, car nous avons aujourd’hui 7 Po de données sur Google BigQuery et lorsqu’il est nécessaire d’effectuer un Full Refresh de notre data lake, ce sont 72 Po de données qu’il faut traiter. » Or chaque pays fédéré dispose de son propre Data Warehouse et la synchronisation quotidienne ne peut démarrer avec un pays qu’à partir du moment où celui-ci a achevé le chargement des tickets de caisse de la journée.
Un Data Lake et un scheduler pour exécuter le code
Au moment de la création du data lake, un « scheduler» (module choisissant l’ordre d’exécutiuon des tâches) a été mis en place afin d’exécuter le code venant récupérer les données en mode séquentiel, avec des traitements qui ne s’achevaient que vers 7/8 heures du matin. « Une telle approche n’est pas scalable car on fait de plus en plus de traitements. Nous avons donc voulu lancer les chargements en parallèle. Cela a permis de réduire les temps de traitement et achever les traitements vers 5 heures du matin. » L’équipe technique a mis en oeuvre la solution dbt pour lancer de multiples requêtes en parallèle, puis attendre la fin de celles-ci pour finaliser la table de destination. L’inconvénient de l’approche est de perdre du temps entre la phase Fan In (collecte des données) et Fan Out (constitution du «Data Mart» [comptoir de données à des fins précises]), car un délai est nécessaire au cas où un pays mettrait ses données à disposition plus tardivement.
L’équipe technique souhaite aller vers un système événementiel, avec une notification lorsque la synchronisation de données s’achève, avec l’envoi d’un message sur le bus Google Cloud Pub/Sub. «Le message va invoquer un Cloud Run [solution Serverless à base de conteneurs de Google Cloud Platform] qui va ensuite dérouler l’ensemble des process que nous avions précédemment. Cela nous permet d’achever les traitements plus tôt, vers 4 heures du matin. Cela nous donne le temps de rejouer des traitements le matin en cas d’incident. » L’architecture suppose que le scheduler se mette
72 Po 72 petaoctet, c’est le volume de données à traiter lors d’un Full Refresh du data lake.
en attente à partir de 22 heures, mais il est difficile de savoir si les données sont prêtes ou pas.
Au sein du groupe, chaque pays a une maturité différente vis-à-vis de la donnée. En France, les tickets sont chargés 2-3 minutes après le passage en caisse, alors que le Brésil met à jour sa base de données vers 22 heures et l’Espagne exploite une plateforme Cloudera, ce qui les oblige à faire une extraction sur BigQuery pour que les données puissent être lues par la maison-mère.
Implémentation de EventSync sur GCP
Chaque pays étant indépendant, il est impossible d’imposer un même scheduler pour tous. Nous voulons que les pays nous envoient un événement lorsqu’ils ont terminé les traitements de leur côté, pour que les traitements puissent démarrer en central lorsque tous les pays ont envoyé leur message. « Sur GCP [Google Cloud Platform], cela n’existe pas. J’ai donc implémenté sur GCP un outil open source baptisé EventSync. Il exploite Cloud Run pour la partie runtime, FileStore pour le stockage et Google Cloud Pub/Sub pour envoyer les messages. Chaque pays peut ainsi déclencher les traitements quand il le souhaite, dispose d’une URL de notification statique et va envoyer le message de disponibilité des données sur le bus de message.» L’ensemble des briques d’infrastructures sont gérées par Google en mode Serverless et l’application est sécurisée avec Cloud Identity and Access Management (IAM).