Début décembre, j'ai commis une erreur fatale et franchi un tournant dans ma vie de développeur en rejoignant l'équipe Data Engineering (DE) au sein de l'entreprise. Dans cet article je partagerai quelques observations que j'ai faites au cours de deux mois de travail dans l'équipe DE.
Pourquoi l’ingénierie des données ?
Mon voyage vers DE a commencé à l'été 2019, lorsque nous allons à , et là j'ai atteint l'illumination. J'ai commencé à m'intéresser au sujet, à étudier les algorithmes et même à leur sujet , puis réfléchi au champ d'application et découvert rapidement que l'application pratique dans notre entreprise réside dans les bases de données distribuées.
Que fait exactement notre équipe ? Comme tous les garçons et filles à la mode, nous voulons devenir une entreprise axée sur les données. Et pour que cela devienne possible, nous devons au moins construire une installation de stockage fiable, qui peut être utilisée pour créer tous les rapports dont l'entreprise a besoin. Mais le plus important est que les données contenues dans ce stockage soient fiables. De plus, à l’aide de ces données, il faut pouvoir restaurer l’état du système à l’instant t. Tout cela est compliqué par le fait que nous vivons dans un nouveau monde de microservices, et cette idéologie implique que chaque service implémente sa propre petite fonctionnalité, que sa base de données est sa propre affaire et qu'il peut la supprimer au moins tous les jours, mais à en même temps, nous devons être capables de recevoir et de traiter l'état du service.
Si vous souhaitez être Data Driven, devenez d'abord Event Driven
Pas si simple. Les événements sont différents et le développeur et l'ingénieur de données les regardent différemment. Parler d’événements fait l’objet d’un article séparé, je n’y reviendrai donc pas ici. De plus, un tel article a déjà un certain Martin Fowler, je ne lui enlèverai pas ses lauriers, qu'il devienne aussi célèbre.
En général, il y a beaucoup de choses à penser et c'est pourquoi ce quartier est attractif. Il se trouve que dans notre entreprise, un Data Engineer représente un domaine de responsabilité beaucoup plus large qu'une simple personne qui écrit des pipelines ETL/ELT (si vous ne savez pas ce que signifient ces abréviations, venez sur . En tant que publicité contextuelle).
Nous traitons de l'architecture de stockage, de la modélisation des données, des questions liées à la sécurité des données et bien sûr des pipelines eux-mêmes. Nous devons également veiller à ce que, d'une part, notre présence ne soit pas très contraignante pour les développeurs de produits et qu'ils soient le moins possible distraits par nos exigences lors de l'intégration de nouvelles fonctionnalités dans le système, et d'autre part, nous Nous devons les fournir de manière pratique dans les données de stockage pour les analystes et l'équipe BI. C'est ainsi que nous vivons.
Difficultés lors de la transition du développement
Lors de mon premier jour de 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, c'est l'absence de tuling et de certaines pratiques. Prenons, par exemple, la couverture du code avec des tests. Nous avons des centaines de frameworks de tests en développement. Lorsque l’on travaille avec des données, tout est plus compliqué. Oui, nous pouvons tester les pipelines ETL sur des données de test, mais nous devons tout faire manuellement et rechercher des solutions pour chaque cas spécifique. En conséquence, la couverture des tests est bien pire. Heureusement, il existe un autre niveau de feedback sous forme de surveillance et de journaux, mais cela nous oblige déjà à réagir de manière réactive plutôt que proactive, ce qui est exaspérant et énervant.
2. Le monde du point de vue DE n'est pas du tout ce qu'il semble à un développeur de produits ordinaire (enfin, bien sûr, le lecteur n'est pas comme ça, et il sait déjà tout, mais je ne savais pas et maintenant je me trompe ça monte). En tant que développeur, je crée mon propre microservice, je mets les données dans [la base de données de votre choix], j'y sauvegarde mon état, j'obtiens quelque chose par identifiant et tout va bien. Le service est lent, les commandes sont confuses, c'est tout. Ils me demandent de rechercher mon état dans un autre service, je vais donc lancer un événement dans RabbitMQ et c'est tout. Et là, nous revenons à nouveau à 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, c'est pourquoi la question de la refonte des contrats de service et du travail étroit 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énementiel il est dans notre entreprise.
3. Vous devez penser avec votre tête. Non, je ne veux pas dire que les développeurs ne réfléchissent pas (mais qui suis-je pour parler au nom de tout le monde), c'est juste que dans le développement de produits, très souvent, vous avez déjà une sorte d'architecture et vous supprimez différents remaniements du backlog. Bien sûr, cela nécessite de la planification et de la réflexion, mais il s’agit d’un travail de type « flux », dont le principal problème est simplement de le faire correctement et efficacement.
Pour nous, ce n'est pas si simple, car 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 à générer des événements, vous devez reconsidérer la logique de remplissage du stockage, car les données sont désormais différentes. C’est là qu’il faut réfléchir longuement et en profondeur, non plus en tant que développeur, mais en tant qu’ingénieur de données. C’est une histoire normale quand on passe des journées avec un cahier et un stylo ou avec un marqueur au tableau. C’est très difficile, je n’aime pas réfléchir, j’aime aussi la production.
4. La chose la plus importante est peut-être l’information. Que faisons-nous lorsque nous manquons de connaissances ? Qui a dit stackoverflow ? Sortez cette personne de la pièce. On va lire des documents, des livres sur le sujet, et il y a aussi une communauté qui organise des forums, des rencontres et des conférences. La documentation est excellente, mais malheureusement, elle peut être 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 peuvent être trouvés, ils contiennent beaucoup de connaissances fondamentales et il faut lire beaucoup et constamment. Mais le problème vient de la communauté.
Il est désormais difficile de trouver au moins une conférence ou une rencontre adéquate dans notre région. Non, bien sûr, il y a beaucoup de rencontres avec le mot Data, mais à côté de ce mot il y a généralement des abréviations étranges comme ML ou AI. Donc, ce n'est pas pour nous, nous parlons de comment construire des installations de stockage, et non de comment nous enduire de neurones. Ces hipsters ont tout pris. En conséquence, nous sommes sans communauté. D’ailleurs, si vous êtes Data Engineer et connaissez de bonnes communautés, merci d’écrire dans les commentaires.
Conclusions et annonce du meetup
On se retrouve avec quoi ? Ma première expérience me dit que se sentir dans la peau d'un ingénieur de données sera utile à tout développeur. Cela nous permet simplement de voir les choses différemment et de ne pas être surpris lorsque nos yeux deviennent injectés de sang lorsque nous voyons comment les développeurs traitent leurs données. Donc, s'il y a un DE dans votre entreprise, parlez-en simplement à ces gars-là, vous apprendrez beaucoup de nouvelles choses (sur vous-même).
Et enfin, l'annonce. Comme il est difficile de trouver des rencontres sur notre sujet dans la journée, nous avons décidé de créer les nôtres. Pourquoi sommes-nous pires ? Heureusement, nous avons un incroyable et nos amis de , qui, comme nous, estiment que les data ingénieurs sont injustement privés d’attention.
Profitant de cette occasion, j'invite tous ceux qui le souhaitent à venir à notre première rencontre communautaire au titre prometteur « DE or DIE », qui aura lieu le 27.02.2020 février XNUMX au bureau de Dodo Pizza. Détails sur .
Si quelque chose arrive, je serai là, vous pourrez me dire personnellement en face à quel point je me trompe à propos des développeurs.
Source: habr.com