#7 - Le vocabulaire de base d'un Data Engineer

Les termes clés pour un Data Engineer (Crédits)

👋 Hello la communauté Dataque

🙌 Bienvenue dans cette édition #7 de notre newsletter ! Que tu sois un débutant ou un expert en Data, merci de nous lire chaque semaine.

🚀 Dans cet article nous allons essayer de nous plonger un peu plus dans le métier de Data Engineer et comprendre le vocabulaire de ce métier qui peut paraître au premier abord très technique. Nous avons la chance de pouvoir échanger avec Thomas Labidoire, Senior Analytics Engineer chez Polar Analytics.

👨‍⚕️ Polar Analytics est le partenaire de croissance des e-commerçants et permet aux marques indépendantes de rivaliser avec les géants du retail grâce à la Data. En quelques clics, les utilisateurs du logiciel peuvent synchroniser l'ensemble de leurs sources de données, les centraliser et prendre les bonnes décisions en quelques minutes.

👨‍💻 Thomas va partager avec nous son expérience et nous parler un peu plus en détail du vocabulaire qu'utilisent les Data Engineers.

☝️ Avant de commencer, comme promis une petite note de vocabulaire pour vous aider à comprendre tous les termes :

• ETL/ELT¹ : ETL (Extract, Transform, Load) est un processus qui consiste à extraire, transformer et charger les données d'une source vers une destination. ELT (Extract, Load, Transform) inverse l'ordre, en chargeant d'abord les données avant de les transformer si nécessaire.

• DevOps (Development and Operations)² : Une méthode de travail qui encourage la coopération étroite entre les développeurs et les équipes d'exploitation au cours du processus de création des logiciels/applications.

• BI Engineer³ : Un ingénieur BI (Business Intelligence) crée des outils et des systèmes pour aider les entreprises à collecter, analyser et visualiser leurs données.

👋 Hello Thomas,

Est-ce que tu peux nous parler de ton parcours professionnel et comment tu as acquis des compétences en Data Engineering ?

Après des études de commerce classiques et un master en finance, j’ai rejoint Amazon en tant que Financial Analyst. C’est là que j’ai découvert la Data, le poste ressemblait plus à celui d’un Data Analyst que d’un Financial Analyst. Des données variées sur différents aspects du e-commerce, beaucoup de SQL et beaucoup d’Excel.

Chez Amazon, je me suis ensuite orienté vers un poste de BI Engineer³ légèrement plus technique en termes de Data Modeling et de volume de données à gérer. Par la suite, j’ai rejoint Doctolib, toujours en tant que BI Engineer. Après une fusion des équipes BI et Data Engineering j’ai eu l’occasion de commencer à apprendre sur la partie Data Engineering.

Je suis maintenant Analytics Engineer chez Polar Analytics, une start-up de 25 personnes où il faut apprendre à faire beaucoup de choses soi-même, et notamment continuer d’apprendre sur la partie Data Engineering.

La frontière entre Data Engineer et Analytics Engineer a l’air très fine dans certaines entreprises, quelles différences vois-tu entre les deux métiers ?

Dans le processus d’intégration de la donnée, l'Analytics Engineer va être responsable de la partie transformation des données, le 'T' dans ELT (Extract, Load, Transform)¹, alors que le Data Engineer va être responsable de la partie 'E' et 'L'.

Chez Polar Analytics, cela n’empêche pas l’Analytics Engineer d’extraire les données lui-même pour pouvoir les explorer et commencer la partie modélisation des données sans être dépendant du Data Engineer.

Mais pour moi, l’important reste que le Data Engineer est responsable de l’industrialisation de la partie Extract et Load. En dehors du processus d’intégration de la donnée, et dans la mesure où la Data reprend les bonnes pratiques de Software Development existantes, le Data Engineer aura également la plupart du temps une casquette DevOps².

Quels sont les termes les plus couramment utilisés par les Data Engineer et à quoi correspondent t-ils ?

Il y en a beaucoup, mais ceux que j’entends le plus souvent sont :

• API (Application Programming Interface) : Un standard qui permet à deux applications informatiques de communiquer entre elles. L’extraction des données passe régulièrement par une interaction avec l’API de l’outil informatique qui contient les données auxquelles on veut accéder. De la même façon, renvoyer des données qui ont été traitées vers un outil informatique nécessite d'interagir avec l’API de cet outil.

• Data Orchestration : L’automatisation et la coordination de multiples applications/services afin d’optimiser un flux de données. Par exemple, un outil d’orchestration comme Airflow permettra de coordonner différentes tâches participant à un Workflow global.

• Data Observability : La pratique qui consiste à surveiller et à comprendre le comportement des données en temps réel, lorsqu'elles circulent dans un système. Il s’agit souvent de comprendre et d’identifier les erreurs dans le pipeline de données grâce à des alertes pour pouvoir les corriger le plus rapidement possible. Une des pratiques courantes est d’avoir des Channels d’alertes sur Slack pour pouvoir identifier et intervenir rapidement pour résoudre un problème dans le flux de données.

• CI/CD (Continuous Integration / Continuous Deployment) : À l’origine utilisés pour le développement logiciel, l’intégration continue/le déploiement continu sont maintenant utilisés également côté Data. Il s’agit de pratiques visant à automatiser la création, les tests et le déploiement des applications. Concrètement, cela permet de faire évoluer rapidement la base de code en production tout en étant confiant grâce aux tests effectués.

Que conseillerais-tu à une personne qui hésiterait entre un rôle d’Analytics Engineer et de Data Engineer ?

Je pense qu’il est judicieux de se former, au moins en surface, dans les deux domaines. Cela aidera à mieux appréhender le domaine dans lequel on se sent le plus à l’aise, ce qui est toujours bénéfique étant donné que les Analytics Engineers et les Data Engineers collaborent étroitement. Comprendre le travail de l’autre permet une coopération plus efficace.

Pour moi, une des questions principales à se poser pour s’orienter vers l’un ou vers l’autre est la préférence entre des problématiques business et des problématiques techniques.

Un Analytics Engineer devra avoir une bonne compréhension des enjeux métierspour pouvoir modéliser les données de manière à les rendre exploitables par les Data Analysts et le business. À l’inverse, il ne sera pas nécessaire pour un Data Engineer d’être au fait de toutes ces problématiques business; il sera plus concentré sur les problématiques techniques.

Évidemment, le périmètre des rôles varie d’une entreprise à l’autre.Il est important, lors des entretiens, de chercher à comprendre précisément quels sont les sujets et technologies sur lesquels le poste exige de travailler.

Est-ce que tu as des ressources ou des conseils à partager aux personnes qui veulent se former en Data Engineering ?

Plutôt que de recommander des ressources particulières, je pense que des conseils sont plus appropriés, car il existe de nombreux ressources de qualité accessibles facilement. Mon impression est qu’il n’est pas nécessaire de passer par des formations encadrées et payantes. Vous pouvez vous former par vous-même, et démontrer vos connaissances en entretien sera plus important que d’avoir suivi une formation X ou Y.

Bien sûr s’autoformer n’est pas facile, il faut beaucoup de motivation. Si vous avez du mal à rester régulier, une formation encadrée pourra toujours vous permettre de compenser ce point.

Le marché et les technologies évoluent rapidement, donc je pense qu’il est pertinent de parcourir en amont les offres d'emploi qui vous intéressent, afin de voir quelles sont les technologies les plus demandées, et ainsi déterminer comment vous souhaitez organiser votre formation.

Personnellement, j’assimile les concepts de manière beaucoup plus complète grâce à la pratique, donc je pense qu’il ne faut pas hésiter à se lancer dans des projets personnels pour mettre en application ce que l’on a appris, plutôt que de passer beaucoup de temps sur la théorie avant de se lancer.

Merci beaucoup pour votre lecture et à la semaine prochaine pour un nouvel article.

🚨 PS: Si vous aimez notre newsletter, n'hésitez pas à la partager autour de vous et à nous suivre sur Linkedin pour ne rater aucune de nos aventures.