Get best of the week

Ingénieur de données ou mourir: une histoire de développeur unique

Début décembre, j'ai fait une erreur fatale, pris une décision cruciale dans ma vie de développeur et transféré à l'équipe Data Engineering (DE) au sein de l'entreprise. Dans l'article, je partagerai certaines des observations que j'ai faites pendant deux mois de travail dans l'équipe DE.




Pourquoi l'ingénierie des données?


Mon voyage à DE a commencé à l'été 2019, lorsque nous Xnegconduit à l'école de calcul distribué , et là, j'ai atteint l'illumination. J'ai commencé à m'intéresser au sujet, à étudier des algorithmes et même à écrire à leur sujet , puis j'ai réfléchi au domaine d'application et j'ai rapidement découvert que l'application pratique dans notre entreprise était des bases de données distribuées.

Que fait notre équipe en général? Nous, comme tous les garçons et filles à la mode, voulons devenir une entreprise axée sur les données. Et pour rendre cela possible, nous devons au moins construire un référentiel fiable, sur lequel il sera possible de construire tous les rapports requis par l'entreprise. Mais le plus important est que les données de ce stockage doivent être fiables. De plus, selon ces données, il est nécessaire de pouvoir restaurer l'état du système à l'instant t. Tout cela est compliqué par le fait que nous vivons dans un nouveau monde courageux de microservices, et cette idéologie implique que chaque service implémente sa petite fonctionnalité, sa base de données est sa propre entreprise, et il peut le supprimer au moins tous les jours, mais en même temps, nous devons Être en mesure de recevoir et de traiter l'état du service.

Vous voulez être piloté par les données, d'abord devenir un événement


Pas si simple. Les événements sont différents et le développeur et l'ingénieur de datation les regardent différemment. La conversation sur les événements fait l'objet d'un article séparé, donc ici je ne vais pas y entrer. De plus, quelqu'un Martin Fowler a déjà écrit un tel article , je ne lui prendrai pas ses lauriers, le laisser devenir célèbre aussi.

En général, il y a de quoi réfléchir et le quartier est attractif. Il se trouve que dans notre entreprise, Data Engineer est un domaine de responsabilité beaucoup plus large qu'une simple personne qui écrit des pipelines ETL / ELT (si vous ne savez pas ce que ces abréviations signifient - venez à mitap . En tant que publicité contextuelle ).

Nous nous consacrons à l'architecture de la construction d'un entrepôt, à la modélisation des données et aux problèmes liés à la sécurité des données, et aux pipelines eux-mêmes, bien sûr. Et nous devons nous assurer que, d'une part, les développeurs de produits n'étaient pas très contraignants pour notre présence et devaient être distraits le moins possible par nos exigences lorsqu'ils ont vu de nouvelles fonctionnalités dans le système, et d'autre part, nous devons fournir des services stockés de manière pratique données pour les analystes et les équipes BI. Voilà comment nous vivons.

Difficultés à sortir du développement


Le tout premier jour de mon travail, j'ai rencontré un certain nombre de difficultés que je souhaite partager avec vous.

1. La première chose que j'ai vue est le manque de réglage et de certaines pratiques. Prenez, par exemple, la couverture du code avec des tests. En cours de développement, nous avons des centaines de frameworks pour les tests. Lorsque vous travaillez avec des données, tout est plus compliqué. Oui, nous pouvons tester des pipelines ETL sur des données de test, mais nous devons faire tout cela de nos propres mains et rechercher des solutions pour chaque cas spécifique. En conséquence, la couverture des tests est bien pire. Heureusement, il existe une autre couche de rétroaction sous la forme de surveillance et de journaux, mais cela nous oblige déjà à réagir plutôt que proactif, ce qui nous exaspère .

2. Le monde de la position de DE n'est pas du tout ce qu'il semble à un développeur de produit ordinaire (enfin, bien sûr, le lecteur n'est pas comme ça, et il sait déjà tout, mais je ne le savais pas et maintenant il ratisse). En tant que développeur, j'ai vu mon microservice, mis les données dans [la base de données de votre choix], enregistré mon état là-bas, obtenu quelque chose par ID et c'est normal. Le service tourne, les commandes sont confuses, c'est tout. Ils me demandent dans un autre service de fouiller mon état, eh bien, je lancerai un événement dans un RabbitMQ et c'est tout. Et là, nous sommes de nouveau revenus sur la question des événements décrits ci-dessus.

Ce dont le service a besoin pour le travail opérationnel ne nous convient pas pour les données historiques, la question du traitement des contrats de service et de la collaboration étroite avec les équipes de développement commence. Vous ne pouvez même pas imaginer combien d'heures il nous a fallu pour nous mettre d'accord: quel genre d'événement est-il motivé dans notre entreprise.

3. Vous devez penser avec votre tête. Non, je ne veux pas dire que les développeurs ne pensent pas (bien que qui sois-je pour tout le monde), c'est juste que dans le développement de produits, vous avez souvent déjà une sorte d'architecture, et vous réduisez les arriérés divers. Bien sûr, cela nécessite une planification et une réflexion, mais c'est un travail de streaming, où le problème principal est tout simplement bon et de haute qualité à faire.

Ce n'est pas si simple ici parce que le transfert de divers composants du système d'un monolithe chaleureux et confortable vers le monde de la jungle sauvage des microservices n'est pas si simple. Lorsque le service commence à saupoudrer d'événements, vous devez réviser la logique de remplissage du stockage, car les données sont désormais différentes. Ici, vous devez réfléchir beaucoup et minutieusement, non pas en tant que développeur, mais en tant qu'ingénieur des données. C'est une histoire normale lorsque vous passez des jours avec un carnet et un stylo ou avec un marqueur près du tableau. C'est très difficile, je n'aime pas penser, j'adore les figues-figues et en production.

4. Peut-être le plus important est l'information. Que faisons-nous lorsque nous manquons de connaissances? Qui a dit stackoverflow? Sortez cette personne de la pièce. Nous allons lire des documents, des livres sur le sujet, et il y a toujours une communauté qui organise des forums, des réunions et des conférences. La documentation est cool, mais malheureusement elle est incomplète. Nous utilisons Cosmos DB dans un certain nombre de projets. Bonne chance pour lire la documentation de ce produit. Les livres sont le seul salut, heureusement, ils existent et se trouvent, ils ont beaucoup de connaissances fondamentales et il faut lire beaucoup et constamment. Mais la communauté est en difficulté.

Maintenant, dans notre direction, il est difficile de trouver au moins une conférence ou une réunion adéquate. Bien sûr, il y a beaucoup de mitaps avec le mot Data, mais des abréviations étranges comme ML ou AI apparaissent généralement à côté de ce mot. Donc, ce n'est pas pour nous, nous parlons de la façon de construire des installations de stockage, et non de la façon de maculer les neurones. Ces hipsters remplissaient tout. En conséquence, nous sommes sans communauté. Soit dit en passant, si vous êtes un ingénieur de données et que vous connaissez de bonnes communautés, veuillez écrire dans les commentaires.

Conclusions et annonce du mitap


Qu'avons-nous finalement? Ma première expérience me dit que se sentir à la place de la date d’un ingénieur sera utile à chaque développeur. Cela nous permet simplement de voir les choses différemment et de ne pas être surpris lorsque nos yeux saignent à la vue de la façon dont les développeurs traitent leurs données. Donc, si votre entreprise a DE, il suffit de discuter avec ces gars et d'en apprendre beaucoup (sur vous-même).

Et enfin, l'annonce. Comme il est impossible de trouver des mitaps sur notre sujet pendant la journée, nous avons décidé de créer le notre. Et quoi, qu'est-ce qu'on est pire? Heureusement, nous avons un incroyableSchvepssset nos amis de New Professions Lab , qui, comme nous, pensent que les ingénieurs de datation sont injustement privés d'attention.

J'en profite pour inviter toutes les personnes concernées à venir à notre première réunion communautaire avec le nom prometteur «DE or DIE», qui se tiendra le 27/02/2020 dans le bureau de Dodo Pizza. Détails sur TimePad .

Si quoi que ce soit, je serai là, vous pouvez personnellement me dire en personne, à quel point je me trompe sur les développeurs.

More articles:


All Articles