Mettre en place une approche Analytics Engineering avec Swile
Hello,
J'espĂšre que tu vas bien ! đ
Je suis ravi de te retrouver pour cette 2Ăšme Ă©dition depuis le lancement de la communautĂ© Data Gen. Si tu la reçois, câest que tu fais partie de mes 513 personnes prĂ©fĂ©rĂ©es !
En train de rĂ©diger cette Ă©dition dans un Coffee Shop aux Abbesses. Dis-moi si tu passes dans le coin, le cafĂ© est excellent et je tâinvite ! đâïž
Avant tout, voici quelques infos utiles :
Inscris-toi au prochain webinar sur la stratégie data de BlaBlaCar.
On t'a transféré ce mail ? Inscris-toi à la communauté pour recevoir les prochaines éditions.
Tâes Data Engineer et tu cherches ta nouvelle aventure ? Dis-le moi en rĂ©ponse Ă ce mail, je te mets en relation avec un Head of Data qui recrute.
L'agenda de la semaine :
đ Le zoom sur l'approche Analytics Engineering.
đ Le podcast avec Arthur de Swile sur l'Analytics Engineering.
đ Les ressources recommandĂ©es par Arthur.
đââïž Les mouv' de la communautĂ© Data de cet Ă©tĂ©.
đĄÂ Le projet open source d'un membre de la communautĂ©.
đą Les Ă©ditions de septembre sont rendues possibles par Artefact, le cabinet de conseil spĂ©cialisĂ© sur la Data đą
Lien vers leurs postes ouverts : ici
đ Le zoom sur l'approche Analytics Engineering (4 min)
Cette semaine, jâai eu le plaisir dâĂ©changer avec Arthur PĂ©ligry, Senior Analytics Engineer chez Swile, qui mâa parlĂ© de ce que fait un Analytics Engineer au sein dâune organisation.
Jâen ai profitĂ© pour lui poser une question que jâavais en tĂȘte depuis un moment : dans quel contexte est-il recommandĂ© de crĂ©er un dĂ©partement Analytics Engineering ? Il a insistĂ© sur 4 points.
Â
1) Il n'y a pas de stratégie de modélisation commune
En bref :
TrĂšs souvent, les modĂšles sont crĂ©Ă©s en silo pour rĂ©pondre Ă un besoin ou un projet data spĂ©cifique, sans ĂȘtre intĂ©grĂ©s dans la vision globale. Chaque Data Analyst a ses propres requĂȘtes sur son ordinateur quâil ou elle va utiliser pour calculer les mĂ©triques en fonction de ses besoins.Â
"On se partage des requĂȘtes SQL sur Slack, on s'envoie des petits bouts de code Ă droite Ă gauche mais on nâa pas vraiment de source de vĂ©ritĂ© pour notre nombre de clients, notre revenu ou notre MRR (Monthly Recurring Revenue).â
Comment les Analytics Engineers interviennent-ils ?
Leur objectif est dâharmoniser la maniĂšre dont les requĂȘtes sont Ă©crites entre les Data Analysts. Cela se fait via la centralisation des fichiers SQL dans un outil (ex : DBT, cf. dĂ©finition ci-dessous). Les Analytics Engineers dĂ©finissent avec les autres Ă©quipes la façon dont les modĂšles doivent ĂȘtre organisĂ©s, puis ils forment et accompagnent les Data Analysts dans lâusage de lâoutil. Lorsque les Data Analysts ont besoin dâĂ©crire une requĂȘte pour calculer une mĂ©trique, ils regardent dans DBT ou contactent leurs collĂšgues pour vĂ©rifier si la requĂȘte nâexiste pas dĂ©jĂ avant de lâĂ©crire.
"DBT permet de déployer en collaboration des modÚles de données tout en respectant les bonnes pratiques de développement (ex : code modulaire et portable, intégration continue, documentation, etc.)."
Lâoutil centralise lâensemble des fichiers SQL (rangĂ©s dans des dossiers et sous-dossiers) qui dĂ©finissent les modĂšles de donnĂ©es et donc les tables. Tous les Data Analysts peuvent retrouver les fichiers SQL dont ils ont besoin ou en ajouter de nouveaux. Il est possible de retrouver lâhistorique dans la mesure oĂč les modĂšles sont versionnĂ©s avec git.
Â
2) Les métriques clés qui ont des définitions différentes
En bref :
Ce deuxiĂšme point est une consĂ©quence du premier. Si les Data Analysts Ă©crivent leurs requĂȘtes en silo et donc potentiellement en doublon, il y a de fortes chances que certaines mĂ©triques soient calculĂ©es diffĂ©remment dâun dĂ©partement ou dâun projet Ă lâautre. Par exemple, le nombre dâutilisateurs actifs peut ĂȘtre diffĂ©rent pour les Ă©quipes Finance et Marketing car leurs membres nâen ont pas la mĂȘme dĂ©finition.
Comment les Analytics Engineers interviennent-ils ?
Leur objectif est dâaligner toutes les Ă©quipes sur des dĂ©finitions de KPIs, ce qui reprĂ©sente un Ă©norme chantier. Pour commencer, Arthur recommande dâidentifier ses objets data prioritaires et ce quâil appelle ses âchampionsâ :Â
Les objets data prioritaires sont ceux pour lesquels aucune marge dâerreur nâest acceptable. Ce sont souvent les donnĂ©es liĂ©es aux transactions et aux clients.Â
Les âchampionsâ sont les Ă©quipes qui sont les plus Ă mĂȘme de consommer les donnĂ©es de maniĂšre autonome, qui connaissent bien les mĂ©triques et peuvent Ă©ventuellement faire des requĂȘtes. Ce sont souvent les Ă©quipes Finance car elles ont lâhabitude de travailler avec de la donnĂ©e, de faire des tableurs, etc.
Les Analytics Engineers doivent construire dans un premier temps le modĂšle liĂ© aux KPIs prioritaires (ex : Revenu, Nombre de clients, etc.) tout en incluant les autres Ă©quipes (ex : Data, Marketing, Sales, etc.) afin quâelles participent Ă leurs dĂ©finition et quâelles ne les dĂ©couvrent pas au dernier moment.
"Si on arrive Ă servir des modĂšles Ă l'Ă©quipe finance et quâelle a confiance dans la donnĂ©e, on a tout gagnĂ©."
Â
Une fois que la modélisation et le processus fonctionne sur ce premier périmÚtre, les Analytics Engineers vont inclure les suivants de maniÚre itérative.
Â
3) Le pipeline de transformation des donnĂ©es nâest pas documentĂ©
En bref :
Les Data Analysts ne parviennent pas toujours Ă savoir quand une table a Ă©tĂ© mise Ă jour, depuis quand une donnĂ©e a Ă©tĂ© calculĂ©e, Ă partir de quelle source, etc. ce qui complique leur usage. Comme expliquĂ© dans le premier point, lâapproche Analytics Engineering nĂ©cessite que les Data Analysts rĂ©utilisent des modĂšles construits par leurs collĂšgues. Or, on ne peut pas ĂȘtre sĂ»r que le modĂšle en question est le bon si on nâa pas accĂšs Ă ces informations.
Comment les Analytics Engineers interviennent-ils ?
Ici, une fois de plus, DBT va permettre de documenter en dĂ©tail tous les Ă©lĂ©ments sur les modĂšles qui sont nĂ©cessaires Ă leur usage. Câest le rĂŽle des Analytics Engineers de dĂ©finir quelles sont ces informations et de sâassurer que les Data Analysts les documentent Ă chaque fois quâune modification est apportĂ©e aux modĂšles.Â
âOn est garants que tout ce qui est fait est documentĂ©, peut ĂȘtre consultĂ© et est comprĂ©hensible par une personne de l'Ă©quipe Data mais aussi par une personne extĂ©rieure Ă l'Ă©quipe qui souhaite savoir ce qui se cache derriĂšre telle ou telle mĂ©trique.â
Â
4) Il n'y a pas de bonnes pratiques communes dans le code
En bref :
Lorsque les Ă©quipes ne suivent pas de bonnes pratiques de code communes (ex : un code de qualitĂ© optimisĂ© par des profils plus seniors, des tests, une documentation systĂ©matique, etc.), les dĂ©veloppements sont difficiles Ă maintenir dans le temps. Par exemple, dĂšs quâun membre de lâĂ©quipe sâen va, ses anciens collĂšgues ont du mal Ă comprendre son code ou inversement, lorsque des nouvelles recrues arrivent, leur onboarding est difficile. Au fur et Ă mesure que lâentreprise grossit, de plus en plus de projets doivent ĂȘtre re-codĂ©s entiĂšrement parce que lâĂ©quipe nâarrive plus Ă les faire Ă©voluer.Â
Comment les Analytics Engineers interviennent-ils ?
Ici, lâobjectif des Analytics Engineers est de dĂ©finir ces bonnes pratiques en collaboration avec les autres Ă©quipes Data et puis de garantir quâelles sont bien suivies (ex : relecture de code, vĂ©rification des tests, etc.). Ils sâinspirent notamment du professionnalisme de lâindustrie logicielle traditionnelle.
âAvant chaque modification, suppression ou addition de code en production, il y a une relecture des pairs qui est faite. Il faut que le code soit cohĂ©rent avec les rĂšgles Ă©tablies.â
VoilĂ pour le zoom de cette semaine, j'espĂšre que ces Ă©lĂ©ments t'ont permis comme moi de mieux comprendre pourquoi certaines entreprises choisissent de crĂ©er un rĂŽle dĂ©diĂ© pour rĂ©soudre les problĂšmes Ă©voquĂ©s. Initialement, ces activitĂ©s Ă©taient toujours partagĂ©es entre les Data Engineers et les Data Analysts mais ces derniers nâont pas toujours le temps de les mener Ă bien.
Pour rappel, il nây a pas de bonne ou de mauvaise organisation, il faut identifier laquelle est la plus pertinente par rapport au contexte de lâentreprise. đ
đ Le podcast avec Arthur de Swile sur l'Analytics Engineering
Dans cet épisode, Arthur nous parle de son rÎle de Senior Analytics Engineer, des problÚmes qui justifient la création d'un département Analytics Engineer, de l'utilisation de DBT et du challenge de passer d'une approche individualiste à une approche collaborative.
Liens vers lâĂ©pisode : Spotify | Apple Podcasts | Deezer | Google Podcasts
đ Les ressources recommandĂ©es par Arthur
 La premiĂšre est la newsletter blef.fr : elle propose chaque semaine un concentrĂ© d'articles et d'analyses data trĂšs pertinentes (đ Christophe Blefari). La seconde est le blog Hacker Feed de YCombinator (l'incubateur le plus rĂ©putĂ© des Etats-Unis) : il recense chaque jour de nombreux articles sur le business et la tech dont certains passionnants sur le data.Â
đââïž Les mouv' de la communautĂ© Data de cet Ă©tĂ©
đĄÂ Le projet open source d'un membre de la communautĂ©
Paul, Head of Data chez Nickel, dĂ©veloppe en open source des fonctions BigQuery pour faciliter le travail des Data Analysts. Par exemple, la premiĂšre permet d'afficher les statistiques d'une table directement dans l'UI de BigQuery. Et il cherche des bĂȘta-testeurs pour avoir des retours !
Lien pour tester : ici (aucune installation ni compte à créer).
Tu peux lui faire un retour par mail (paul.marcombes@unytics.io) ou via Linkedin.
Si vous souhaitez partager un projet ou un challenge dans les prochaines Ă©ditions pour obtenir du feedback ou de l'aide de la communautĂ©, n'hĂ©sitez pas Ă me contacter en rĂ©pondant Ă ce mail ! J'en profite pour remercier Michael et Paul qui m'ont donnĂ© l'idĂ©e de cette rubrique. đ