Bonjour, Habr! Chez Dodo Pizza Engineering, nous aimons vraiment les données (et qui ne les aime pas maintenant?). Maintenant, il y aura 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. Défiez sous l'astérisque: sauvez les nerfs de l'équipe Data Engineering.
Comme les vrais Plyushkins, nous enregistrons toutes sortes d'informations sur le travail de nos pizzerias:
- rappelez-vous toutes les commandes des utilisateurs;
- nous savons combien de temps il a fallu pour faire la toute première pizza à Syktyvkar;
- Nous voyons combien de temps la pizza refroidit sur la tablette chauffante de Voronej en ce moment;
- stocker des données sur les radiations de produits;
- et bien plus encore.
Plusieurs équipes sont actuellement chargées de travailler avec les données chez Dodo Pizza, l'une d'entre elles est l'équipe d'ingénierie des données. Maintenant, ils (c'est-à-dire nous) ont une tâche: donner à tout employé de l'entreprise un accès pratique à ce tableau de données.
Lorsque nous avons commencé à réfléchir à la façon de procéder et commencé à discuter du problème, nous avons trouvé une approche très intéressante de la gestion des données - Data Mesh (vous trouverez ici un énorme article chic). Ses idées sont très bien tombées sur notre idée de la façon dont nous voulons construire notre système. Le reste de l'article sera notre réflexion sur l'approche et la façon dont nous la voyons mise en œuvre dans Dodo Pizza Engineering.
Qu'entendons-nous par «données»
Pour commencer, décidons de ce que nous entendons par les données de Dodo Pizza Engineering:
- Les événements qui envoient des services (nous avons un bus commun construit en utilisant RabbitMQ);
- Enregistrements à l'intérieur de la base de données (pour nous, c'est MySQL et CosmosDB);
- Clickstream à partir d'une application mobile et d'un site Web.
Pour que l'entreprise Dodo Pizza utilise et s'appuie sur ces données, il est important que les conditions suivantes soient remplies:
- Ils doivent être holistiques. Nous devons être sûrs que nous ne modifions pas les données au cours de leur traitement, stockage et affichage. Si une entreprise ne peut pas faire confiance à nos données, elles ne seront d'aucune utilité.
- Ils doivent être horodatés et non écrasés. Cela signifie qu'à tout moment, nous voulons pouvoir revenir en arrière et regarder les données de cette période. Par exemple, découvrez 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 devons non seulement perdre l'intégrité, mais aussi la fiabilité. Nous ne pouvons pas perdre de données, de tranches de temps, car avec eux, nous perdons la confiance de nos clients (externes et internes).
- Ils devraient être avec un schéma stable - nous écrivons des demandes pour ces données. Nous ne voudrions vraiment pas qu'ils changent tellement avec le changement de code d'application, avec le refactoring, que nos demandes cessent de fonctionner. Celui qui rédige les demandes ne saura jamais que vous avez fait la refactorisation jusqu'à ce que tout se brise. Je ne voudrais pas savoir cela 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 de service public. Par conséquent, la même équipe propriétaire du service devrait être propriétaire des données. De plus, les modifications du schéma de données doivent toujours être rétrocompatibles.
Approche traditionnelle - Data Lake
Pour résoudre les problèmes de stockage et de traitement fiables des mégadonnées, il existe une approche traditionnelle adoptée par 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 de tous les composants du système et les placent dans un grand stockage (cela peut être, par exemple, Hadoop, Azure Kusto, Apache Cassandra ou même une réplique MySQL si des données y pénètrent).
En outre, ces mêmes ingénieurs écrivent des demandes à un tel stockage. La mise en œuvre de cette approche chez Dodo Pizza Engineering implique que l'équipe d'ingénierie des données sera propriétaire du schéma de données dans le référentiel analytique.
Avec ce scénario, l'équipe devient des chats très tristes et c'est pourquoi:
- Elle doit surveiller les changements dans TOUS les services au sein de l'entreprise. Et il y en a beaucoup et il y a beaucoup de changements (en moyenne, nous fusionnons ~ 100 demandes de tirage par semaine, alors que de nombreux services ne font pas du tout de demandes de tirage).
- Lors de la modification du schéma de données, le chef de produit et l'équipe qui modifient le schéma de données doivent attendre que l'ingénierie des données termine le code nécessaire pour que les modifications soient prises en charge. De plus, nous figurons 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.
- Elle doit être immergée dans l' ensemble des activités de l'entreprise. Une chaîne de pizzerias ressemble à une entreprise simple, mais il semble juste. Il est très difficile de rassembler suffisamment de compétences en une seule équipe pour construire un modèle de données adéquat pour l'ensemble de l'entreprise.
- Il s'agit d'un seul point d'échec. Chaque fois que vous devez modifier les données renvoyées par le service ou écrire une requête, toutes ces tâches incombent à l'équipe d'ingénierie des données. 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 a peu de chances de pouvoir les satisfaire. En même temps, il sera soumis à une pression et à un stress constants. Nous ne voulons vraiment pas cela. Par conséquent, vous devez réfléchir à la manière de résoudre ces problèmes et en même temps avoir la possibilité d'analyser les données.
Circulation de Data Lake vers Data Mesh
Heureusement, non seulement nous nous sommes posé cette question. En fait, un problème similaire a déjà été résolu dans l'industrie (alléluia!). Uniquement dans un autre domaine: 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 de la résolution de problèmes de Data Lake a été suggérée par Zhamak Dehghani, consultant de ThoughtWorks. Regardant Netflix et Spotify résoudre de tels problèmes, elle a écrit un article étonnant sur 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 principales idées que nous en avons sorties:
- Divisez le grand Data Lake en domaines de données très similaires aux domaines de conception pilotés par domaine. Chaque domaine est un petit contexte borné.
- L'équipe technique, qui est responsable des domaines DDD, est également responsable des domaines de données correspondants. Ils stockent le circuit, y apportent des modifications, y chargent des données. Dans le même temps, ils savent tout eux-mêmes: comment changer le chargement des données et ne rien casser lorsque l'application change. La connaissance ne va nulle part. Pour ouvrir les données, ils ne doivent aller nulle part. L'équipe elle-même mène un cycle de développement complet, de la modification des données opérationnelles à la fourniture de données analytiques à des tiers. Une équipe possède tout ce qui est associé au domaine (à la fois le domaine commercial et le domaine de données).
- Ingénieur de données - Un rôle au sein de l'équipe technique. Il ne s'agit pas nécessairement d'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 au clic d'un doigt, alors il reste à répondre à deux questions:
Que fera l'équipe d'ingénierie des données maintenant? Dodo Pizza Engineering dispose déjà d'une équipe de plateforme / SRE. Sa tâche est de donner aux développeurs des outils pour un déploiement facile des services. L'équipe d'ingénierie des données remplira le même rôle pour les données uniquement.
La transformation des données opérationnelles en données analytiques est un processus complexe. Rendre l'analytique accessible à l'ensemble de l'entreprise est encore plus difficile. C'est la solution à ces problèmes que l'équipe d'ingénierie des données traitera.
Nous allons fournir à l'équipe technique un ensemble d'outils et de pratiques pratiques grâce auxquels elle pourra 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 Data Engineer apparaîtront-elles dans Feature Team? L'équipe technique devient plus difficile. Bien sûr, nous pourrions essayer d'embaucher un Data Engineer dans chacune de nos équipes. Mais c'est très difficile. Trouver une personne ayant une bonne formation en informatique et la convaincre de travailler au sein d'une équipe d'épicerie est difficile.
Le grand avantage de Dodo est que nous aimons l'apprentissage interne. Alors maintenant, notre plan est le suivant: l'équipe d'ingénierie des données commence à publier les données de certains services, pleure, pique, mais continue de manger le cactus. Dès que nous comprenons que nous avons un processus prêt à l'emploi pour la publication, nous commençons à en parler dans Feature Team.
Nous avons plusieurs façons de procéder:
- DevForum , dans lequel nous vous dirons à quoi ressemble le processus que nous avons créé, quels outils sont là et comment les utiliser le plus efficacement possible.
- S'exprimer au DevForum nous aidera à recueillir les commentaires des développeurs de produits. Après cela, nous pourrons rejoindre les équipes produits et les aider à résoudre les problèmes de publication des données, organiser la formation des équipes.
Consommation de données
Maintenant, j'ai beaucoup parlé de la publication des données. Mais il y a aussi la consommation. Et ce problème?
Nous avons une merveilleuse équipe de BI qui rédige des rapports très complexes pour une société de gestion. À l'intérieur de Dodo IS, il existe de nombreux rapports pour nos partenaires qui les aident à gérer les pizzerias. Dans notre nouveau modèle, nous les considérons comme des consommateurs de données qui ont leurs propres domaines de données. Et ce sont les consommateurs qui seront responsables de leurs propres domaines. Parfois, un domaine consommateur peut être décrit avec une seule demande au référentiel analytique - et c'est bien. Mais nous comprenons que cela ne fonctionnera pas toujours. C'est pourquoi nous souhaitons que la plate-forme que nous allons créer pour les équipes de produits soit également utilisée par les consommateurs de données (dans le cas des rapports au sein de Dodo IS, ce ne seront que des équipes).
C'est ainsi que nous voyons travailler avec les données dans Dodo Pizza Engineering. Nous sommes heureux de lire vos réflexions à ce sujet dans les commentaires.