Comment Criteo gère la traçabilité de ses données
Publié par La rédaction le | Mis à jour le
Criteo a monté, autour de son cluster Hadoop, un système de data lineage. Sur quelles techniques s’appuie-t-il ?
Que faire avec un système de gestion de la traçabilité des données (data lineage) ? Par exemple, automatiser le regroupement des problèmes de data quality ou la réparation des datasets impactés par des incidents.
Criteo explore en tout cas ces deux pistes désormais qu’il a mis en place son propre système. Celui-ci œuvre à différents niveaux : tables (qui, dans la pratique, comprend aussi les assets non adossés à des tables et/ou à des rapports Power BI), partitions et colonnes.
Cette traçabilité soutient, entre autres cas d’usage, l’analyse d’impact, la recherche de cause racine, la conformité (audit, suivi des PII) et l’enrichissement de métadonnées. Elle est exposée, d’une part, à travers une série de datasets. De l’autre, par l’intermédiaire d’une web app Datadoc incluant des fonctionnalités de catalogue et d’observabilité.
Le processus s’inscrit dans un pipeline plus global de collecte et d’analyse de données d’usage à l’échelle de la data platform de Criteo. Datadoc expose ainsi également des éléments relatifs aux requêtes, tâches et applications qui entraînent des transformations.
Pour soutenir sa démarche data lineage, Criteo exploite plusieurs techniques, dont :
– Renseigner manuellement les relations source-destination (c’est généralement le fait des owners ou des stewards)
– Rechercher des patterns spécifiques dans les métadonnées des assets
– Exploiter les journaux d’exécution des services de la data platform (logs-as-source)
– Exploiter le code source spécifiant les transformations (source-as-code)
– Intégrer des capacités de traçabilité à même certains systèmes
Un suivi multicouche au sein du cluster Hadoop
Chez Criteo, la plupart des traitements hors ligne se passent sur le data lake, un cluster Hadoop de 3000 machines stockant 180 Po. S’y exécutent principalement des jobs Spark et des requêtes Hive. Le tout orchestré par deux outils maison (Cuttle, BigDataflow).
La plupart des données brutes ingérées proviennent de Kafka – un système centralisé les transmet par lots. Une fois les transformations effectuées, les utilisateurs consomment les données avec Presto/Trino. Ou bien elles sont exportées vers Vertica. Certains clusters alimentent un déploiement Tableau.
La plupart des entrées et sorties du cluster reposent sur des systèmes centralisés. Cela permet d’exposer les infos de traçabilité sur leur API. Dans certains cas, on peut examiner le coder et l’intégrer au CI pour l’étape de validation.
La partie la plus complexe consiste à suivre les transformations qui se déroulent dans le cluster. Plusieurs strates de data lineage sont mises à contribution dans ce but.
Sur les moteurs SQL comme Hive et Presto/Trino, le parser permet d’exposer l’info. Criteo a paramétré des hooks qui stockent le contexte d’exécution des requêtes dans un topic Kafka, ensuite transmis au pipeline global. On passe également par Kafka pour les transformations qu’orchestre Bigdataflow.
Pour le reste, on utilise Garmadon, un service de collecte d’événements qui suit les interactions avec le système de fichiers sous-jacent.
Enrichissement et déduplication
Les données que produit Garmadon n’indiquent que les relations entre les applications et les chemins bruts. Elles nécessitent donc un enrichissement sémantique. Pour cela, on exécute deux tâches :
– Fusionner les applications impliquées dans la même transformation logique
Cette étape se fonde essentiellement sur des techniques de détection de patterns. Garmadon permet aussi d’injecter, dans les applications, des tags destinés à lier les exécutions aux unités logiques déclarées dans les orchestrateurs.
– Associer les chemins bruts à la sémantique déjà disponible dans le magasin de métadonnées Hive
Au moment de l’assemblage des sources de traçabilité a lieu une déduplication. On conserve alors la source la plus qualitative ; par exemple, les données provenant des hooks plutôt que de Garmadon. Partant, on peut effectuer d’autres transformations pour exposer les données sous des formes plus adaptées à des use cases spécifiques.
Le data lineage est utilisé notamment dans un moteur de recherche interne, pour influer sur le classement des résultats : plus un asset a de dépendances transitives, plus il est probablement important.
Datadoc peut aussi faire remonter des alertes de performance sur la base des infos de SLO extraites des définitions des datasets. Et fournir aux utilisateurs des éléments sur la cause racine.
Illustration principale générée par IA