Data Mesh : comment travailler avec des données sans monolithe

Bonjour Habr! Chez Dodo Pizza Engineering, nous aimons les données (et qui ne les aime pas de nos jours ?). Il y aura maintenant une histoire sur la façon d'accumuler toutes les données du monde Dodo Pizza et de donner à tout employé de l'entreprise un accès pratique à ce tableau de données. La tâche sous l’astérisque : garder les nerfs de l’équipe Data Engineering.

Comme de vrais Peluches, nous accumulons toutes sortes d'informations sur le travail de nos pizzerias :

• mémoriser toutes les commandes des utilisateurs ;
• nous savons combien de temps il a fallu pour préparer la toute première pizza à Syktyvkar ;
• nous voyons combien de temps il faut actuellement à une pizza pour refroidir sur une étagère chauffante à Voronej ;
• Nous stockons des données sur les radiations de produits ;
• et bien d'autres.

Plusieurs équipes sont désormais chargées de travailler avec les données chez Dodo Pizza, l'une d'elles est l'équipe Data Engineering. Désormais, ils (c'est-à-dire nous) sommes confrontés à la tâche de donner à tout employé de l'entreprise un accès pratique à cet ensemble de données.

Lorsque nous avons commencé à réfléchir à la manière de procéder et à discuter du problème, nous avons découvert une approche très intéressante de la gestion des données : Maillage de données (suivez le lien, vous trouverez un article énorme et génial). Ses idées s'intègrent très bien dans notre idée de la façon dont nous voulons construire notre système. Plus loin dans l'article, nous repenserons l'approche et comment nous envisageons sa mise en œuvre dans Dodo Pizza Engineering.

Qu'entendons-nous par « données »

Tout d’abord, définissons ce que nous entendons par données dans Dodo Pizza Engineering :

• Événements envoyés par les services (nous avons un bus commun construit à l'aide de RabbitMQ) ;
• Enregistrements à l'intérieur de la base de données (pour nous, il s'agit de MySQL et CosmosDB) ;
• Flux de clics depuis une application mobile et un site Web.

Pour que l'entreprise Dodo Pizza puisse utiliser et s'appuyer sur ces données, il est important que les conditions suivantes soient remplies :

• Ils doivent être complets. Nous devons nous assurer que nous ne modifions pas les données pendant leur traitement, leur stockage et leur affichage. Si les entreprises ne peuvent pas faire confiance à nos données, elles ne serviront à rien.
• Ils doivent avoir un horodatage et ne pas être écrasés. Cela signifie qu'à tout moment, nous voulons pouvoir revenir en arrière et examiner les données de cette période. Découvrez par exemple combien de pizzas ont été vendues le 8 juillet 2018.
• Ils doivent être fiables. Dans le processus de collecte et de stockage des données, nous ne devons pas perdre non seulement leur intégrité, mais aussi leur fiabilité. Nous ne pouvons pas perdre de données, de tranches de temps, car avec elles nous perdons la confiance de nos clients (tant externes qu'internes).
• Ils doivent être dotés d'un circuit stable - nous écrivons des requêtes pour ces données. Nous n'aimerions vraiment pas que cela change tellement avec des changements dans le code de l'application, avec des refactorings, que nos requêtes cessent de fonctionner. La personne qui écrit les requêtes ne saura jamais que vous avez effectué une refactorisation jusqu'à ce que tout tombe en panne. Je ne voudrais pas entendre parler de cela de la part des clients.

Compte tenu de toutes ces exigences, nous sommes arrivés à la conclusion que les données de Dodo sont un produit. Identique à l'API publique du service. En conséquence, la même équipe propriétaire du service devrait être propriétaire des données. De plus, les modifications apportées au schéma de données doivent toujours être rétrocompatibles.

Approche traditionnelle – Lac de données

Pour résoudre les problèmes de stockage et de traitement fiables du Big Data, il existe une approche traditionnelle adoptée dans de nombreuses entreprises qui travaillent avec un tel pool d'informations : Data Lake. Dans le cadre de cette approche, les ingénieurs de données collectent des informations sur tous les composants du système et les placent dans un seul grand référentiel (il peut s'agir, par exemple, de Hadoop, Azure Kusto, Apache Cassandra ou même d'une réplique MySQL, si les données s'inscrivent dans il).

Ensuite, ces mêmes ingénieurs écrivent des requêtes sur un tel stockage. La mise en œuvre de cette approche dans Dodo Pizza Engineering signifie que l'équipe Data Engineering sera propriétaire du schéma de données dans l'entrepôt analytique.

Dans ce scénario, l'équipe devient des chats très tristes et voici pourquoi :

• Elle doit surveiller les changements dans Tous prestations au sein de l'entreprise. Et il y en a beaucoup et beaucoup de changements (en moyenne nous fusionnons ~100 pull request par semaine, alors que de nombreux services ne font pas du tout de pull request).
• Lors de la modification du schéma de données, le propriétaire du produit et l'équipe modifiant le schéma de données doivent attendre que Data Engineering ajoute le code nécessaire pour prendre en charge les modifications. Dans le même temps, nous sommes riches en fonctionnalités depuis longtemps et la situation où une équipe en attend une autre est très rare. Et nous ne voulons pas que cela devienne une partie « normale » du processus de développement.
• Il doit être immergé dans TOUS affaires de l'entreprise. La chaîne de pizzerias ressemble à une simple entreprise, mais ce n'est qu'en apparence. Il est très difficile de rassembler suffisamment de compétences au sein d’une seule équipe pour construire un modèle de données adéquat pour l’ensemble de l’entreprise.
• C'est un point d'échec unique. Chaque fois que vous devez modifier les données renvoyées par le service ou rédiger une requête, toutes ces tâches incombent à l'équipe Data Engineering. En conséquence, l’équipe a un arriéré surchargé.

Il s'avère que l'équipe est à l'intersection d'un grand nombre de besoins et qu'il est peu probable qu'elle soit en mesure de les satisfaire. En même temps, vous serez constamment soumis à une pression temporelle et à un stress. Nous ne voulons vraiment pas de cela. Nous devons donc réfléchir à la manière de résoudre ces problèmes tout en étant capables d’analyser les données.

Passer de Data Lake à Data Mesh

Heureusement, nous n’étions pas les seuls à nous poser cette question. En fait, un problème similaire a déjà été résolu dans l’industrie (alléluia !). Juste dans un domaine différent : le déploiement d’applications. Oui, je parle de l'approche DevOps, où l'équipe détermine comment déployer le produit qu'elle crée.

Une approche similaire pour résoudre les problèmes de Data Lake a été proposée par Zhamak Dehghani, consultant ThoughtWorks. En regardant comment Netflix et Spotify résolvent des problèmes similaires, elle a écrit un article étonnant Comment passer d'un lac de données monolithique à un maillage de données distribué(le lien vers celui-ci était au début de l'article). Les idées principales que nous en avons retenues :

• Divisez un grand Data Lake en domaines de données, qui sont très similaires aux domaines de conception pilotés par domaine. Chaque domaine est un petit contexte délimité.
• Les Feature Teams, qui sont responsables des domaines DDD, sont également responsables des domaines de données correspondants. Ils stockent le schéma, y ​​apportent des modifications et y chargent des données. En même temps, ils savent tout eux-mêmes : comment modifier le chargement des données et ne rien casser lorsque l'application change. La connaissance ne disparaît pas. Ils n'ont pas besoin d'aller nulle part pour ouvrir les données. L'équipe elle-même dirige le cycle de développement complet, depuis la modification des données opérationnelles jusqu'à la fourniture de données analytiques à des tiers. Une équipe possède tout ce qui est associé au domaine (à la fois le domaine métier et le domaine des données).
• Data Engineer – rôle au sein de l’équipe Feature. Il n’est pas nécessaire que ce soit un individu, mais il est impératif que l’équipe possède cette compétence.

Pendant ce temps, l'équipe Data Engineering...

Si vous imaginez que tout cela se réalise en un claquement de doigts, alors il vous suffit de répondre à deux questions :

Que va faire l’équipe Data Engineering maintenant ? Dodo Pizza Engineering dispose déjà d’une équipe plateforme/SRE. Son objectif est de donner aux développeurs les outils nécessaires pour déployer facilement des services. L'équipe Data Engineering remplira le même rôle pour les données uniquement.

Transformer des données opérationnelles en données analytiques est un processus complexe. Rendre les données analytiques accessibles à l’ensemble de l’entreprise est encore plus difficile. Ce sont ces problématiques que l’équipe Data Engineering va traiter.

Nous allons fournir à l'équipe Feature un ensemble pratique d'outils et de pratiques afin qu'elle puisse publier les données de son service vers le reste de l'entreprise. Nous serons également responsables des parties générales de l'infrastructure du pipeline de données (files d'attente, stockage fiable, clusters pour effectuer des transformations sur les données).

Comment les compétences de Data Engineer apparaîtront-elles au sein de la Feature Team ? Avec la Feature Team, c'est plus compliqué. Bien entendu, nous pourrions essayer d’embaucher un Data Engineer pour chacune de nos équipes. Mais c'est tellement dur. Trouver quelqu'un avec une bonne formation en science des données et le convaincre de travailler au sein d'une équipe produit est difficile.

Le gros plus de Dodo, c’est que nous aimons les formations internes. Alors maintenant, notre plan est le suivant : l'équipe Data Engineering commence à publier les données de certains services, pleure, s'injecte, mais continue de manger du cactus. Une fois que nous savons que nous avons mis en place un processus de publication, nous commençons à le communiquer à l'équipe chargée des fonctionnalités.

Nous avons plusieurs façons de procéder :

1. Forum des développeurs, où nous vous expliquerons à quoi ressemble le processus que nous avons créé, quels outils sont disponibles et comment les utiliser le plus efficacement possible.
2. Prendre la parole au DevForum nous aidera à recueillir les commentaires des développeurs de produits. Après cela, nous pourrons rejoindre les équipes produit et les aider à résoudre des problèmes de publication de données, et organiser des formations pour les équipes.

Consommation de données

Maintenant, j'ai beaucoup parlé de la publication de données. Mais il y a aussi la consommation. Qu'en est-il de ce problème ?

Nous avons une formidable équipe BI qui rédige des rapports très complexes pour la société de gestion. Dans Dodo IS, vous trouverez de nombreux rapports destinés à nos partenaires qui les aident à gérer leurs pizzerias. Dans notre nouveau modèle, nous les considérons comme des consommateurs de données possédant leurs propres domaines de données. Et ce sont les consommateurs qui seront responsables de leurs propres domaines. Parfois, le domaine d'un consommateur peut être décrit en une seule requête adressée à l'entrepôt analytique - et c'est une bonne chose. Mais nous comprenons que cela ne fonctionnera pas toujours. C'est pourquoi nous voulons que la plateforme que nous allons créer pour les équipes produit puisse également être utilisée par les consommateurs de données (après tout, dans le cas des rapports au sein de Dodo IS, ce seront les mêmes équipes).

C’est ainsi que nous envisageons le travail avec les données dans Dodo Pizza Engineering. Nous serons heureux de lire vos réflexions à ce sujet dans les commentaires.

Source: habr.com