J’adore les données ! Que ce soit la data science ou le data engineering, ces deux sujets me passionnent. Mais dans la vie, rien n’est parfait. Alors voici 5 points qui m’ennuient en tant que Data Engineer. Néanmoins, pour moi, ces problématiques ont une (ou plusieurs) solution·s, alors je vous propose également des idées pour surmonter ces points.
1. Beaucoup de technologies et d’outils
Depuis quelques mois, un de mes amis souhaite devenir data engineer, mais il a vite remarqué la complexité de l’environnement en Data Science et Data Engineering. Il est difficile de savoir par quelle technologie commencer.
Mes suggestions :
Une des suggestions est qu’il n’est pas utile d’apprendre tous les outils et technologies disponibles (évidemment). Le plus important est d’apprendre les bases :
Autre élément important est d’apprendre les patterns d’architecture. Un pattern est une manière simplifiée de voir une architecture et de l’appliquer. En tant que Data Engineer (et en développeur en général), le plus important est d’avoir une vision globale de son métier, et de savoir quand utiliser les outils.
Parmi ces quatre parties (Collection/ Ingestion/ Preparation & Computation/ Presentation), l’idée est de maitriser au moins deux parties (ainsi que les outils) et de connaitre à haut niveau les autres parties.
Sans oublier que monter en compétence n’est pas une course, mais un marathon. Du temps sera nécessaire pour devenir Data Engineer ou pour apprendre de nouvelles connaissances.
2. Le syndrome de l’imposteur
Dans un métier qui évolue constamment, il est important de s’autoformer pour rester à jour. Le problème de l’autoformation, c’est qu’il peut être difficile de savoir si l’on est bon ou pas et donc de s’enfermer dans l’autocritique.
Mes suggestions :
- Distinguer les faits (objectifs) des sentiments (subjectifs) :
Durant nos apprentissages, on a tous des réussites. Le sentiment d’échec ou de ne pas « être assez » est souvent un mauvais indicateur de nos compétences. Célébrer vos réussites (même les plus petites) aident à garder le cap et à avancer.
- Arrêter de courir après la perfection et accepter l’échec :
Pour apprendre, il faut échouer. C’est quelque chose d’inévitable. C’est grâce à ces échecs et de la patience que viendra l’excellence.
3. Data Science vs Data Engineering : La limite peut être floue
Avec ces nouvelles compétences très convoitées sur le marché, une des erreurs classiques est de recruter des data scientists et de leur demander de créer des algorithmes. Sauf que très vite, les data scientists se mettent à développer des ETLs afin d’améliorer la qualité de données. On arrive rapidement avec une infrastructure pleine de dette technique, dont il sera difficile de se débarrasser.
Ma suggestion :
Je pense très honnêtement qu’il faut entre 2 et 3 Data Engineers pour 1 Data Scientist en poste. Il est fondamental d’avoir une infrastructure fiable pour qu’accueillir aux mieux les data scientists.
Lorsqu’un projet en data science est bloqué ou sur la voie de l’échec, Il est important que les managers/lead tech prennent un pas de recul. Il serait dommage de persister sur un chemin inefficace.
Je vous conseille le blog (en anglais) de Jesse Anderson qui donnent une vision intéressante sur mise en place d’une équipe data.
4. S’occuper de « qualité de la donnée » trop tard dans un projet
Pour moi, la qualité de donnée est l’un des sujets les plus complexes. L’impact d’une mauvaise qualité de donnée peut être désastreux pour votre business et la relation avec les utilisateurs de ces données.
Ma suggestion :
Il est important de prendre le sujet en considération très tôt dans la vie d’un projet, avec ces 6 points :
1- Exactitude : Les données sont-elles valides ?
2- Complétude : Les données sont-elles complètes ?
3 – Cohérence : Les données sont-elles logiques dans le contexte ?
4- Duplication : Les données sont-elles (si besoin) uniques dans le contexte ?
5 – Opportunité : Les données sont-elles à jour à la bonne fréquence ?
6 – Validité : Les données sont-elles au bon format ?
Et « scale » par la suite :
- Data quality chez Netflix (en anglais)
- Data quality chez Uber (en anglais)
6 – La visibilité des Data Engineers sur un projet
Dépendamment de la culture de l’entreprise, il est possible que les data engineers aient un manque de reconnaissance (et quelquefois des salaires plus bas) comparé à d’autres postes de type data scientist/ML Engineer. Nous faisons un travail caché et complexe, et il est parfois difficile pour les utilisateurs finaux de comprendre notre travail.
C’est un problème connu dont Maxime Beauchemin (un des pionniers du Data Engineering) en parle dans la partie « The worst seat at the table » de son article « The downfall of the Data Engineer » :
« In some organization the role is different and may have different [lower] salary bands. Casual observation may suggest that the rate of data engineers with a computer science degree may be significantly lower than across software engineering as a whole.»
En substance, Maxime Beauchemin dit que le « chemin » de la Data Science et Data Engineering serait moins payant que le « chemin » Software engineer / Dev. Cependant, cela est très dépendant du pays, du niveau d’expérience et de l’entreprise. Et je pense que l’argent ne devrait pas être la seule raison de travailler en Data Science.
Ma suggestion :
Je pense réellement qu’un data engineer ne devrait pas seulement se positionner en tant qu’expert en création de data pipeline et architecture. Il doit être capable de soutenir une équipe analytique pour de faire des présentations métier, être une force de proposition et avoir un leadership (pour les data engineers plus seniors).
Pour moi, « Sharing is caring« . Avoir la capacité de vulgariser des principes complexes ou encore accompagner les data analyts et data scientists sur la sélection de KPI permettra aux data engineers d’avoir plus d’impact et donc être « mieux considérés ».
Data From Scratch 