Transformer le Bronze en Or

Analytics Engineers

Résumé

RÎle : Nettoyer, organiser et documenter les données et calculer les indicateurs de performance propres à l'organisation afin que les Data Analysts, Data Scientists et autres utilisateurs finaux puissent les analyser efficacement

Outil principal : Un langage de programmation fait pour la manipulation de données tel que SQL

Transformation de données

Les donnĂ©es brutes collectĂ©es par les Data Engineers ne sont pas prĂȘtes Ă  ĂȘtre analysĂ©es. Les Analytics Engineers sont responsables de les transformer en jeux de donnĂ©es nettoyĂ©s, remodelĂ©s et documentĂ©s, prĂȘts Ă  ĂȘtre utilisĂ©s par les Data Analysts, Data Scientists et autres utilisateurs finaux en aval.

Les tables stockĂ©es dans un Data Warehouse sont souvent regroupĂ©es en couches successives. La premiĂšre est appelĂ©e bronze et contient les donnĂ©es brutes fournies par les Data Engineers. Les donnĂ©es sont ensuite traitĂ©es entre chaque couche afin d’atteindre progressivement l’état oĂč elles sont prĂȘtes Ă  l’emploi : c’est un processus de raffinement progressif oĂč les tables de la couche bronze sont transformĂ©es en tables des couches argent qui, Ă  leur tour, sont encore traitĂ©es pour produire les tables de la couche or, le produit final du Data Warehouse.

Ce processus est appelé transformation de données. Il se compose de plusieurs opérations : la modélisation de la donnée, la validation de la donnée et la transformation analytique.

Modélisation des Données

Les donnĂ©es brutes proviennent de divers systĂšmes sources indĂ©pendants, chacun avec ses propres rĂšgles et idiosyncrasies. Par consĂ©quent, un certain remodelage des donnĂ©es est nĂ©cessaire pour obtenir un ensemble de tables qui, malgrĂ© leur grand nombre et leur diversitĂ©, reste exploitable pour les Data Analysts et autres utilisateurs finaux en aval : toutes les tables sont remodelĂ©es en utilisant un paradigme commun (dĂ©finissant ce que chaque table reprĂ©sente et comment elle se lie aux autres) et leurs contenus sont alignĂ©s (unitĂ©s, devises, identifiants d’entitĂ©, etc. sont unifiĂ©s). Ce processus de conception est appelĂ© modĂ©lisation des donnĂ©es.

Il est important car :

  • il amĂ©liore grandement la lisibilitĂ© des donnĂ©es et facilite les liens entre les systĂšmes sources, liens d’oĂč provient une grande partie de la valeur des analyses subsĂ©quentes.
  • il permet au Data Warehouse de croĂźtre de maniĂšre saine, c’est-Ă -dire que davantage de systĂšmes sources et de tables peuvent y ĂȘtre intĂ©grĂ©s rapidement.
  • il est conçu sur la base de discussions avec les Data Analysts, Data Scientists et avec l’ensemble de l’organisation de façon Ă  ce qu’il rĂ©ponde le plus facilement possible Ă  leurs questions, c’est-Ă -dire sans avoir besoin de revenir aux donnĂ©es brutes (manquant de lisibilitĂ© et difficile Ă  analyser) et, dans la mesure du possible, sans avoir besoin de compĂ©tences techniques approfondies en manipulation de donnĂ©es.

Validation des Données

Les donnĂ©es brutes contiennent des informations invalides qui doivent ĂȘtre dĂ©tectĂ©es et traitĂ©es avant d’atteindre les utilisateurs finaux. Celles-ci peuvent ĂȘtre causĂ©es par des erreurs humaines, par des bugs quelque part dans un systĂšme source ou dans le Pipeline de DonnĂ©es, ou par un comportement frauduleux dĂ©libĂ©rĂ© effectuĂ© dans l’un des systĂšmes sources. Ces invaliditĂ©s prennent la forme d’enregistrements dupliquĂ©s, de fautes de frappe ou de valeurs incorrectes, par exemple. Les Analytics Engineers mettent en place des transformations de donnĂ©es pour gĂ©rer automatiquement les problĂšmes connus et ils dĂ©ploient des tests de validation de donnĂ©es afin de dĂ©tecter autant de problĂšmes restants que possible.

Transformations Analytiques

En plus de remodeler et de nettoyer les donnĂ©es, il appartient Ă©galement aux Analytics Engineers de rĂ©aliser un ensemble de transformations de donnĂ©es analytiques oĂč des unitĂ©s atomiques d’information (par exemple, l’utilisateur X a effectuĂ© l’action Y Ă  la date Z) sont transformĂ©es en informations plus prĂ©cieuses. Exemples :

  • DĂ©terminer quel ensemble d’attributs Ă©tait effectif pour chaque utilisateur d’une application Ă  tout moment dans le passĂ©, et ce Ă  partir des enregistrements atomiques de changement d’attributs ;
  • Identifier les sessions d’activitĂ© des utilisateurs d’une application en fonction des enregistrements atomiques de leurs actions ;
  • Plus largement, calculer un indicateur clĂ© de performance utilisĂ© par l’organisation.

L’objectif ici est d’effectuer toute transformation analytique frĂ©quente et importante (par exemple, le calcul de mĂ©triques) une fois, de maniĂšre rigoureuse, afin que les utilisateurs en aval puissent simplement utiliser une source unique de vĂ©ritĂ© au lieu d’effectuer cette transformation de maniĂšre moins performante et, potentiellement, Ă  plusieurs endroits, ce qui rend possible l’existence de rĂ©alitĂ©s parallĂšles dans lesquelles une mĂȘme mĂ©trique n’est pas dĂ©finie de la mĂȘme maniĂšre.

Formation & Documentation

Enfin, les Analytics Engineers sont responsables de documenter les jeux de donnĂ©es qu’ils crĂ©ent et de former les utilisateurs en aval Ă  leur usage.