🧟 🚴🏿 👾 Migration d'un Data Lake transparent vers un Data Mesh distribué 🤶🏼 ✉️ 🏓

Bonjour, Habr! Je vous présente la traduction de l'article «Comment passer d'un lac de données monolithique à un maillage de données distribué» par Zhamak Dehghani (Zhamak Degani) (toutes les images sont tirées du même article).

Toutes les grandes entreprises tentent désormais de construire d'énormes entrepôts de données centralisés. Ou encore un plus grand cluster Data Lakes (en règle générale, sur un hdup). Mais je ne connais pas un seul exemple de la construction réussie d'une telle plate-forme de données. Partout est la douleur et la souffrance à la fois pour ceux qui construisent une plate-forme de données et pour les utilisateurs. Dans l'article ci-dessous, l'auteur (Zhamak Degani) propose une toute nouvelle approche pour construire une plateforme de données. Il s'agit de l'architecture de la plate-forme de données de quatrième génération appelée Data Mesh. L'article original en anglais est très volumineux et franchement difficile à lire. La traduction s'est également avérée assez volumineuse et le texte n'est pas très simple: de longues phrases, un vocabulaire plutôt sec. Je n'ai pas reformulé la pensée de l'auteur afin de maintenir l'exactitude de la formulation.Mais je vous recommande vivement de continuer à parcourir ce texte difficile et de lire l'article. Pour ceux qui traitent des données, ce sera très utile et très intéressant.

Evgeny Cherny

De nombreuses entreprises investissent dans la prochaine génération de Data Lake dans l'espoir de simplifier l'accès aux données à l'échelle de l'entreprise et de fournir des informations commerciales et la possibilité de prendre automatiquement des décisions de haute qualité. Mais les approches actuelles de création de plates-formes de données ont des problèmes similaires qui ne nous permettent pas d'atteindre nos objectifs. Pour résoudre ces problèmes, nous devons abandonner le paradigme d'un Data Lake centralisé (ou de son prédécesseur, l'entrepôt de données). Et passez à un paradigme basé sur une architecture distribuée moderne: considérez les domaines d'activité comme une priorité de premier niveau, appliquez la réflexion sur la plate-forme pour créer une infrastructure avec la capacité de libre-service et percevez les données comme un produit.

Contenu

L'architecture actuelle de la plateforme de données dans une grande entreprise
- Approches architecturales problématiques
- domain driven
  - -
  - (data pipelines),
- - - (discoverable)
    - (addressable)
    - ,
- data- -
- Infrastructure de données centralisée en tant que plateforme
Changement de paradigme vers le Data Mesh

La construction d'une organisation basée sur les données reste l'un des principaux objectifs stratégiques de nombreuses entreprises avec lesquelles je travaille. Mes clients sont bien conscients des avantages de prendre des décisions basées sur des données de haute qualité: assurer la meilleure qualité de service client, l'hyper personnalisation, réduire les coûts d'exploitation et le temps grâce à l'optimisation, fournir aux employés des outils d'analyse et d'analyse commerciale. Ils investissent massivement dans la construction de plateformes de données modernes. Mais malgré les efforts et les investissements croissants dans la construction de telles plateformes, de nombreuses organisations considèrent les résultats comme médiocres.

Les entreprises sont confrontées à de nombreuses difficultés dans le processus de transformation en une entreprise axée sur les données: migration des systèmes hérités et des décennies de systèmes de développement, résistance de la culture existante et forte concurrence entre les différentes priorités commerciales. Quoi qu'il en soit, je souhaite partager avec vous une approche architecturale qui prend en compte les raisons de l'échec de nombreuses initiatives dans le domaine de la construction de plateformes de données. Je vais démontrer comment nous pouvons adapter et appliquer les leçons de la dernière décennie dans la construction d'architectures distribuées dans le domaine des données. J'ai appelé cette nouvelle approche architecturale Data Mesh .

Avant de poursuivre la lecture, je vous demande d'essayer d'abandonner les préjugés qui ont été posés par le paradigme actuel de l'architecture de plate-forme de données traditionnelle lors de la lecture de cet article. Soyez ouvert à la possibilité de passer de Data Lakes centralisés à une architecture Data Mesh délibérément distribuée. Acceptez que les données soient intrinsèquement distribuées et omniprésentes.

L'architecture actuelle de la plateforme de données dans une grande entreprise

Parlons de la signification centralisée, monolithique et indépendante des données Data Lake.

Presque tous les clients avec lesquels je travaille planifient ou construisent déjà leur plate-forme de données de troisième génération. Reconnaître les erreurs des générations précédentes.

Première génération: entrepôts de données d'entreprise propriétaires et plates-formes de veille stratégique. Ce sont des décisions portant sur d'importantes sommes d'argent qui ont laissé aux entreprises des dettes techniques aussi importantes. La dette technique se situe dans des milliers d'emplois ETL non pris en charge, de tableaux et de rapports que seul un petit groupe de spécialistes comprend, ce qui conduit à une sous-estimation de l'impact positif de cette fonctionnalité sur l'entreprise.
Deuxième génération: écosystèmes Big Data avec Data Lake comme solution miracle. Un écosystème complexe de Big Data et de travaux par lots de longue durée pris en charge par une équipe centrale d'ingénieurs de données hautement spécialisés. Au mieux, utilisé pour l'analyse R&D.

Les plateformes de données de troisième génération sont plus ou moins similaires aux générations précédentes, mais avec un biais

streaming pour fournir une disponibilité des données en temps réel avec une architecture comme Kappa ,
combinant le traitement par lots et en streaming pour transformer les données à l'aide de frameworks tels que Apache Beam ,
utilisation des services cloud pour le stockage et le traitement des données et des plateformes Cloud Machine Learning.

La plate-forme de données de troisième génération élimine certains des problèmes des générations précédentes, telles que l'analyse des données en temps réel, et réduit également le coût de gestion d'une infrastructure de Big Data. Cependant, de nombreuses caractéristiques sous-jacentes qui ont conduit aux échecs des générations précédentes sont toujours préservées.

Figure 1: trois générations de plateformes de données

Approches architecturales problématiques

Pour découvrir les limitations de base que toutes les générations de plates-formes de données ont en elles-mêmes, examinons leur architecture et leurs fonctionnalités. Dans cet article, j'utiliserai l'activité de streaming de médias Internet (tels que Spotify, SoundCloud, Apple iTunes) comme exemple pour expliquer certains concepts.

Centralisé et monolithique

D'une hauteur de 10 000 mètres, l'architecture de la plateforme de données ressemble à la figure 2 ci-dessous.

Figure 2: Vue d'une hauteur de 10 000 mètres sur une plate-forme de données monolithique La

partie centrale de l'architecture est responsable de:

(to ingest) , , . , , : ; ; ; , ; ( ..).
, , , . , , — .
(to serve) . machine learning BI . , . , Kafka.

Par défaut, l'accord généralement accepté est le fait que la plate-forme de données monolithique stocke et possède des données appartenant à différents domaines d'activité. Par exemple, "jouer des événements", "KPI de vente", "artistes", "albums", "labels", "audio", "podcasts", "événements musicaux", etc. - des données provenant d'un grand nombre de domaines disparates.

Malgré le fait qu'au cours de la dernière décennie, nous avons appliqué avec succès le concept de conception pilotée par domaine (et son modèle de contexte délimité clé ) à la conception de nos systèmes d'information, nous avons largement ignoré ces concepts dans la conception de plates-formes de données. Nous sommes passés de la propriété des données au niveau du domaine d'activité à la propriété des données, indépendamment des domaines d'activité. Nous sommes fiersqui a créé le plus grand monolithe - Big Data Platform.

Figure 3: Une plate-forme de données centralisée sans frontières claires entre les données de différents domaines d'activité. Et sans propriété des données pertinentes par le domaine d'activité,

un tel modèle centralisé peut fonctionner pour les petites organisations qui ont des domaines d'activité simples et des options de consommation de données limitées. Mais il ne convient pas aux grandes entreprises ayant des domaines commerciaux vastes et complexes, un grand nombre de sources de données et des besoins divers pour travailler avec les données des consommateurs.

Il existe deux maillons faibles dans l'architecture et la structure d'une plate-forme de données centralisée, qui conduisent souvent à l'échec du processus de construction:

Un grand nombre de sources et de grandes quantités de données. , , . , . . , , , . , data scientists . , ( ) , . , – - .
. . , . .

Ici, je dois préciser que je ne m'exprime pas en faveur de l'utilisation de données fragmentées et disparates cachées dans les profondeurs des systèmes hérités. Ces données difficiles à détecter, à comprendre et à utiliser. Je ne soutiens pas non plus les nombreux entrepôts de données disparates au sein de la même organisation, qui sont le résultat de nombreuses années de dette technique accumulée. Mais je soutiens que la réponse à ces données fragmentées inaccessibles n'est pas de créer une plate-forme de données centralisée avec une équipe centralisée qui stocke et détient les données de tous les domaines d'activité.

Cette approche n'est pas évolutive dans les grandes organisations, comme indiqué ci-dessus.

Décomposition du convoyeur hautement connecté

Figure 4: Décomposition architecturale de la plate-forme de données

Le deuxième problème avec l'architecture traditionnelle de la plate-forme de données est de savoir comment nous décomposons l'architecture. Si elle descend à 3000 mètres au-dessus de l'architecture de la plateforme de données, on trouvera une décomposition architecturale autour des fonctions de chargement, de nettoyage, d'agrégation, de diffusion des données, etc. Comme décrit dans la section précédente, la nécessité de connecter de nouvelles sources et de nouveaux consommateurs nécessite une croissance de la plateforme. Les architectes doivent trouver un moyen de faire évoluer le système en le décomposant en quanta architecturaux. Quantum architectural, tel que décrit dans le livre « Construire des architectures évolutionnaires», Est un composant déployable indépendamment avec une connectivité fonctionnelle élevée, qui comprend tous les éléments structurels nécessaires au bon fonctionnement du système. La motivation pour diviser le système en quanta architecturaux consiste principalement à créer des équipes indépendantes, chacune créant et entretenant son propre quantum architectural (sous-système fonctionnel). Cela vous permet de paralléliser le travail et d'augmenter la vitesse et l'évolutivité opérationnelle.

Influencés par les générations précédentes de plateformes de données, les architectes divisent la plateforme en une série d'étapes de traitement des données. Il s'agit d'un pipeline qui met en œuvre le traitement des données: chargement, préparation, agrégation, fourniture d'accès / déchargement, etc.

Bien que ce partitionnement offre un certain niveau de mise à l'échelle, il présente également une limitation interne qui ralentit le développement de nouvelles fonctionnalités sur la plateforme: il existe une connectivité élevée entre les étapes du pipeline, ce qui ne permet pas l'indépendance nécessaire du travail des équipes individuelles.

Revenons à notre exemple de média en streaming. Les plateformes de streaming multimédia sur Internet ont une conception de domaine solide autour du type de média qu'elles proposent. Ils commencent souvent leurs services avec des «chansons» et des «albums», puis postulent aux «événements musicaux», «podcasts», «émissions de radio», «films», etc. Activation d'une nouvelle fonctionnalité, par exemple, la visibilité des «podcasts» play rate », nécessite une modification de tous les composants du pipeline. Les équipes doivent développer de nouveaux services pour le chargement, le nettoyage et la préparation des données (y compris l'agrégation) afin d'ajouter la visibilité du «taux de lecture des podcasts». Cela nécessite une synchronisation entre les versions des différentes équipes fonctionnelles. De nombreuses plateformes de données utilisent des outils de téléchargement basés sur la configuration qui peuvent facilement gérer de telles tâches.comme simplement ajouter de nouvelles sources ou étendre celles existantes. Mais cela n'élimine pas la nécessité d'une gestion des versions de bout en bout à toutes les étapes du pipeline de traitement des données. Pour permettre aux utilisateurs d'accéder à toutes les nouvelles données, l'unité architecturale minimale à modifier est l'ensemble du pipeline. Et cela limite considérablement notre capacité à augmenter la vitesse et l'ampleur du développement de la plate-forme de données en réponse à l'émergence de nouvelles sources de données et d'utilisateurs.Et cela limite considérablement notre capacité à augmenter la vitesse et l'ampleur du développement de la plate-forme de données en réponse à l'émergence de nouvelles sources de données et d'utilisateurs.Et cela limite considérablement notre capacité à augmenter la vitesse et l'ampleur du développement de la plate-forme de données en réponse à l'émergence de nouvelles sources de données et d'utilisateurs.

Des équipes disparates et hautement spécialisées

Le troisième problème avec les plates-formes de données modernes est de savoir comment nous structurons les équipes qui créent et maintiennent la plate-forme. Lorsque nous allons assez bas sur l'architecture d'une plate-forme de données traditionnelle, nous verrons un groupe d'ingénieurs de données étroitement spécialisés séparés des unités organisationnelles dans lesquelles les données sont créées ou utilisées pour la prise de décision. Les ingénieurs de plate-forme de données sont distingués dans des équipes distinctes uniquement sur la base de leurs compétences techniques et de leur expérience avec les technologies de Big Data. La connaissance des domaines thématiques (domaines d'activité) correspondants est absente dans ces équipes.

Figure 5: Équipes de plates-formes de données dispersées étroitement spécialisées

Personnellement, je n'envie pas la vie des ingénieurs de plateformes de données. Ils devraient recevoir des données d'équipes qui ne sont pas incitées à fournir des données de qualité et correctes. Ils ne comprennent pas la signification commerciale des données que vous devez télécharger. Ils doivent préparer des données pour répondre aux besoins analytiques et opérationnels, sans une compréhension claire de l'utilisation finale de ces données et sans accès à des experts dans le domaine de la consommation de ces données.

Il convient de noter que nous avons déjà rencontré un problème similaire de séparation d'équipe. Et ils ont pu trouver une solution efficace à ce problème.

Dans notre exemple avec le streaming multimédia, nous avons la commande «media player», qui possède des données sur la façon dont les utilisateurs interagissent avec le lecteur: chansons que les utilisateurs écoutent, achats effectués, qualité audio des chansons qu'ils écoutent, etc. D'autre part, il existe des équipes de consommateurs de données pertinentes: une équipe de recommandations de chansons; équipe de suivi des ventes; équipe de paiement d'artistes, etc. Et entre eux, une triste équipe de développeurs d'une plateforme de données qui, au prix d'un gros effort, reçoit les données d'une seule équipe et leur donne accès (après traitement préalable) à tous les consommateurs.

En réalité, nous avons des équipes non impliquées de sources de données et des équipes frustrées de consommateurs de données qui doivent se battre pour une place au sommet de l'arriéré de l'équipe de développement de la plateforme de données.

Nous avons créé une architecture et une structure organisationnelle qui ne fournissent pas l'évolutivité nécessaire et ne sont pas en mesure d'atteindre les objectifs de construction d'une organisation basée sur les données.

Architecture de plate-forme de données de nouvelle génération

Et quelle est la solution aux problèmes dont nous avons discuté ci-dessus? À mon avis, un changement de paradigme est nécessaire. Un changement de paradigme à l'intersection de méthodes qui ont joué un rôle important dans la construction d'une architecture distribuée évolutive moderne et que l'industrie technologique dans son ensemble a mise en œuvre à un rythme accéléré. Des méthodes qui ont donné de bons résultats.

Je crois que l'architecture de plate-forme de données d'entreprise suivante consiste à intégrer l'architecture basée sur le domaine distribué, à concevoir des plates-formes en libre-service et à penser les produits pour les données.

Figure 6: Changement du changement de paradigme de la plate-forme de données de nouvelle génération.

Je comprends que cela puisse ressembler à beaucoup de mots à la mode en une phrase, mais chacun de ces composants a eu un impact incroyablement positif sur la modification des fondements techniques de nos systèmes d'information. Voyons comment appliquer chacune de ces disciplines au monde des données afin de s'éloigner du paradigme actuel qui a été transféré de nombreuses années de construction d'entrepôts de données des générations précédentes.

Architecture pilotée par les données et les domaines distribués

Décomposition et propriété des données en fonction de l'orientation du domaine d'activité

Le livre d'Eric Evans, Domain-Driven Design , a eu un impact profond sur la pensée architecturale contemporaine et, par conséquent, sur la modélisation organisationnelle. La nouvelle architecture de microservices a décomposé les systèmes d'information en services distribués qui sont construits dans les limites de domaines commerciaux spécifiques. Cela a fondamentalement changé la façon dont les équipes sont formées: désormais, une équipe peut posséder ses microservices de manière indépendante et autonome.

Fait intéressant, nous avons ignoré le concept de domaines d'activité dans le domaine des données. Application à venir de la conception pilotée par domaine dans l'architecture de plate-forme de données: c'est l'émergence d' événements de domaine métierdans les systèmes d'information et de les charger dans des plates-formes de données monolithiques. Cependant, une fois les données téléchargées vers le stockage centralisé, le concept de propriété des données de différents domaines d'activité par différentes équipes est perdu.

Pour décentraliser une plate-forme de données monolithique, vous devez changer votre façon de penser les données, leur emplacement et leur propriété. Au lieu de transférer des données vers un Data Lake ou une plate-forme, les domaines devraient stocker et maintenir leurs ensembles de données de manière conviviale.

Dans notre exemple, au lieu de charger les données du lecteur multimédia dans un référentiel centralisé pour un traitement ultérieur par l'équipe de support du référentiel, pourquoi ne pas stocker et traiter ces ensembles de données dans le domaine et ne pas donner accès à une autre équipe? L'endroit même où ces ensembles de données seront stockés physiquement peut être implémenté techniquement dans le domaine comme vous le souhaitez. Bien sûr, vous pouvez utiliser une architecture centralisée, mais les données des lecteurs multimédias eux-mêmes resteront la propriété et le support de l'équipe du domaine correspondant dans lequel ces données sont générées. De même, dans notre exemple, le domaine de développement des recommandations de morceaux peut créer des ensembles de données dans le format le mieux adapté à une utilisation (par exemple, sous la forme de structures graphiques) en fonction des données du lecteur multimédia. S'il y a d'autres équipes,qui jugent ce format pratique et utile, ils peuvent également y accéder.

Cela implique, bien sûr, que nous pouvons dupliquer des données dans différents domaines lorsque nous changeons leur format pour un qui convient à un consommateur particulier.

Tout cela nécessite un changement dans notre réflexion, du téléchargement de données (via ETL ou streaming) à la mise à l'échelle de ce processus vers tous les domaines. Le quantum architectural dans une plate-forme de données orientée domaine est un domaine métier, et non l'étape de chargement et de transformation des données.

Figure 7: Décomposition d'une architecture basée sur des domaines métier et des équipes propriétaires de données.

Ensembles de données du domaine source

Certains domaines d'activité sont bien alignés sur les sources de données (systèmes d'information). Dans le cas idéal, le système d'information et l'équipe qui l'accompagne sont non seulement responsables de l'ajout et du support des fonctionnalités métier, mais fournissent également des ensembles de données décrivant les faits et la réalité du domaine d'activité correspondant. Cependant, à l'échelle d'une grande organisation, il n'y a généralement pas de correspondance non ambiguë entre le domaine d'activité et le système d'information. En règle générale, pour chaque domaine, il existe plusieurs systèmes d'information qui automatisent les différents processus commerciaux d'un domaine donné et, par conséquent, stockent les données qui y sont liées. Pour ces domaines, il est nécessaire d'intégrer et d'agréger des données disparates afin d'obtenir des ensembles de données cohérents et alignés sur l'ensemble du domaine d'activité.

Les événements de domaine sont le meilleur format pour stocker des faits décrivant un domaine d'activité . Ils peuvent être stockés sous forme de journal des événements distribué avec des horodatages. Ce journal peut être autorisé à accéder aux consommateurs autorisés.

Outre ces journaux, les sources de données doivent également fournir un accès à des instantanés périodiques des jeux de données clés de leur domaine. L'agrégation de ces images correspond à l'intervalle de temps qui reflète le mieux l'intervalle de changements pour votre domaine (généralement un jour / semaine / mois / trimestre, etc.).

Veuillez noter que les ensembles de données du domaine d'activité préparés pour les consommateurs doivent être séparés des ensembles de données internes des sources (que les systèmes d'information utilisent pour leur travail). Ils doivent être stockés dans un endroit physiquement différent et adapté pour travailler avec des mégadonnées. Ensuite, il sera décrit comment créer un tel entrepôt de données et une infrastructure de services pour lui.

Les ensembles de données spécifiques au domaine préparés pour les consommateurs sont les éléments les plus fondamentaux de toute l'architecture. Ils ne se transforment pas et ne sont pas adaptés à un consommateur spécifique, mais sont des données brutes et non traitées.

Ensembles de données de domaine grand public

D'autres domaines sont étroitement liés aux consommateurs de données. Les ensembles de données d'un tel domaine sont créés de telle manière que, lorsqu'ils sont utilisés, ils correspondent à l'ensemble de scénarios utilisateur associé. Ces jeux de données sont différents des jeux de données du domaine source. Ce ne sont pas des données brutes, mais des données passées par plusieurs étapes de transformation. La structure de ces ensembles de données et leur présentation sont adaptées aux cas spécifiques de leur utilisation. Ceux. Il s'agit d'un analogue de data marts spécialisés dans un référentiel centralisé. Pour ces ensembles de données du domaine consommateur (ensembles de données du domaine consommateur), il convient de prévoir la possibilité d'une récupération rapide à partir des données brutes.

Pipelines de données distribués implémentés dans leurs domaines

La propriété des données dans notre nouvelle architecture est déléguée de la plate-forme centrale aux équipes des domaines d'activité, mais le besoin de nettoyage, de préparation et d'agrégation des données (à l'aide du pipeline de données) ne disparaît pas. Par conséquent, la mise en œuvre de son propre pipeline de données devient une tâche interne de l'équipe du domaine métier. En conséquence, nous obtenons nos propres pipelines de données de domaine distribués sur tous les domaines.

Par exemple, les domaines source doivent inclure le nettoyage des données, la suppression des doublons, l'enrichissement des données, etc., afin que d'autres domaines puissent utiliser ces données sans traitement préalable. Chacun de ces ensembles de données doit respecter son objectif de niveau de service en termes de qualité des données.

De même, les étapes de construction de vitrines spécialisées d'un pipeline centralisé pour le traitement des données vont dans les propres pipelines de données des domaines de consommation qui créent des ensembles de données de domaine de consommation.

Figure 8: Pipelines de traitement de données distribués implémentés dans leurs domaines

Il peut sembler qu'un tel modèle entraînera une grande duplication des efforts dans chaque domaine pour créer sa propre implémentation d'un pipeline de traitement de données. Nous parlerons de ce problème dans la section «Infrastructure de données centralisée en tant que plate-forme».

Réflexion sur les données et les produits

Le transfert de propriété des données et la responsabilité du développement et de la maintenance des pipelines de traitement des données du côté des domaines d'activité peuvent entraîner de sérieuses inquiétudes quant à la disponibilité et à la facilité d'utilisation de ces ensembles de données distribués. Par conséquent, nous arrivons ici à une réflexion pratique sur les produits en relation avec les données.

Données de domaine en tant que produit

Au cours des dix dernières années, la réflexion sur les produits a profondément pénétré le développement des systèmes d'information des organisations et a sérieusement transformé l'approche de ce développement. Les équipes de domaine pour le développement de systèmes d'information fournissent de nouvelles capacités sous la forme d'API que les développeurs utilisent dans les organisations comme blocs de construction pour créer des fonctionnalités d'ordre supérieur et une valeur plus élevée. Les équipes s'efforcent de créer la meilleure expérience pour les utilisateurs de leurs API grâce à une documentation claire et détaillée à laquelle les utilisateurs ont facilement accès; environnements de test des indicateurs de qualité soigneusement suivis.

Pour qu'une plate-forme de données distribuées réussisse, les équipes de données des domaines d'activité doivent appliquer la réflexion sur les produits par rapport à la fourniture d'ensembles de données: percevoir les données qu'elles préparent en tant que produit et les consommateurs (analystes, scientifiques des données, ingénieurs des données, spécialistes du ML) etc.) en tant que vos clients.

Figure 9: Caractéristiques des jeux de données de domaine en tant que produits

Prenons notre exemple: diffuser du contenu multimédia sur Internet. Le domaine commercial le plus important est l'histoire de la reproduction: par qui, où, quand et quelles chansons ont été écoutées. Ce domaine possède divers consommateurs de données clés au sein de l'organisation. L'une nécessite des données en mode quasi-temps réel pour étudier l'expérience utilisateur et la détection en temps opportun de tout problème et erreur de lecture. D'autres sont intéressés par des instantanés historiques agrégés par jour ou par mois. Par conséquent, notre domaine fournit des données sous deux formats: événements de lecture sous forme de streaming (streaming, sujet en kafka ou quelque chose comme ça) et événements de lecture agrégés en format batch (fichier, table dans la ruche, etc.).

Pour offrir la meilleure expérience utilisateur aux consommateurs, les produits de données de domaine métier doivent avoir les fonctionnalités clés suivantes.

Commodité et facilité de détection (découvrable)

Il est nécessaire de garantir les conditions dans lesquelles tout produit de données peut être facilement trouvé. La mise en œuvre la plus courante de cette exigence est la présence d'un registre - un catalogue de tous les produits de données disponibles avec les méta-informations nécessaires (tels que les propriétaires, les sources d'origine, les échantillons d'ensembles de données, la fréquence de mise à jour, la structure des ensembles de données, etc.). Un tel service centralisé permet aux consommateurs de données de trouver facilement l'ensemble de données qui les intéresse. Chaque produit de données de n'importe quel domaine d'activité doit être enregistré dans un répertoire de données centralisé.

Veuillez noter qu'il y a un passage d'une plate-forme centralisée unique qui détient toutes les données à des produits de données distribués de différents domaines commerciaux qui sont enregistrés dans un répertoire de données unique.

Adresse unique (adressable)

Chaque produit de données doit avoir une adresse unique (conformément à l'accord global), qui permettra à ses consommateurs d'y accéder par programmation. Les organisations peuvent adopter divers accords sur le nom des produits de données et leur emplacement, en fonction des méthodes disponibles de stockage physique des données et des formats des données elles-mêmes. Pour l'architecture décentralisée distribuée, de telles conventions générales sont nécessaires. Les normes d'adresse de jeu de données élimineront les frictions lors de la recherche et de l'accès aux produits de données.

Qualité des données

Personne n'utilisera un produit qui n'est pas crédible. Dans les plates-formes de données de génération actuelle, le téléchargement et la publication de données contenant des erreurs et ne reflétant pas toute la vérité métier sont répandus, c'est-à-dire données qui ne peuvent pas faire confiance. C'est dans cette partie qu'un nombre important de travaux ETL sont concentrés, ce qui efface les données après le chargement.

La nouvelle architecture oblige les propriétaires de produits de données à adopter SLO (Service Level Objective) en termes d'exactitude, de fiabilité et de pertinence des données. Pour garantir une qualité acceptable, il est nécessaire d'utiliser des méthodes telles que le nettoyage des données et les tests automatiques d'intégrité des données au stade de la création d'un produit de données. Les informations sur la lignée de données dans les métadonnées de chaque produit de données donnent aux consommateurs une confiance supplémentaire dans le produit lui-même et sa pertinence pour des besoins spécifiques.

La valeur cible de l'indicateur de qualité des données (ou la plage acceptable) varie en fonction du produit de données d'un domaine d'activité particulier. Par exemple, un domaine «événement de relecture» peut fournir deux produits différents: un en mode temps quasi réel avec un niveau de précision inférieur (y compris les événements manqués ou répétés); et le second avec un délai plus long et un niveau de qualité des données plus élevé. Chaque produit de données définit et maintient un niveau cible d'intégrité et de fiabilité de ses données sous la forme d'un ensemble de SLO (Service Level Objective).

Description claire de la sémantique et de la syntaxe des données

Les produits de qualité doivent être faciles à utiliser. La création de produits de données aussi simples que possible à utiliser par les analystes, les ingénieurs et les scientifiques des données nécessite la présence d'une sémantique et d'une syntaxe de données bien décrites. Idéalement, des exemples d'ensembles de données sont fournis à titre d'exemples.

Intégrabilité des données et normes à l'échelle de l'organisation

L'un des principaux problèmes d'une architecture de données basée sur un domaine distribué est la nécessité d'intégrer des données de différents domaines. La clé d'une intégration de données simple et efficace entre les domaines est de définir et de suivre des règles et des normes. Ces normes devraient être définies au niveau de l'organisation. La normalisation est requise dans le domaine de la détermination des types de données acceptables et des règles pour leur application, des conventions sur les noms et adresses des produits de données, des formats de métadonnées, etc.

Pour les entités qui peuvent être stockées sous une forme différente et avec un ensemble d'attributs différent dans différents domaines, il est nécessaire de mettre en œuvre la pratique de la gestion des données de base. Attribuez-leur des identificateurs globaux et alignez l'ensemble et, surtout, attribuez des valeurs à tous les domaines.

Garantir l'interopérabilité des données pour leur intégration efficace, ainsi que définir des normes de stockage et de présentation des produits de données au niveau de l'organisation, est l'un des principes fondamentaux pour la construction de tels systèmes distribués.

Sécurité des données et contrôle d'accès

Garantir un accès sécurisé aux données est indispensable, que l'architecture soit centralisée ou non. Dans le monde des produits de données orientés domaine métier décentralisé, le contrôle d'accès est possible (et doit être appliqué) avec un degré de granularité plus élevé pour chaque ensemble de données. Les politiques de contrôle d'accès aux données peuvent être définies de manière centralisée, mais mises en œuvre séparément pour chaque produit de données. Comme moyen pratique d'implémenter le contrôle d'accès aux ensembles de données, vous pouvez utiliser le système Enterprise Identity Management et le contrôle d'accès basé sur les rôles .

Ensuite, une infrastructure unique sera décrite, ce qui vous permet de mettre en œuvre facilement et automatiquement les fonctionnalités ci-dessus pour chaque produit de données.

Commande de données de domaine métier interfonctionnelle

Les rôles suivants doivent être représentés dans les équipes fournissant des données sous forme de produits de données: propriétaire du produit de données et ingénieur de données.

Le propriétaire du produit de données est responsable du concept et de la feuille de route, du cycle de vie de ses produits. Mesure la satisfaction de ses clients et mesure et améliore constamment la qualité des données de son domaine d'activité. Il remplit et équilibre l'arriéré de ses produits de données avec les exigences des consommateurs de données.

En outre, les propriétaires de produits de données doivent définir des métriques clés et des indicateurs de performance (KPI) pour leurs produits. Par exemple, le temps requis pour vous familiariser et commencer à utiliser le produit de données par l'utilisateur peut être l'une de ces mesures.

Afin de créer et de maintenir leurs propres pipelines de données dans un domaine métier, l'équipe doit inclure des ingénieurs de données. Un bon effet secondaire de cela sera la diffusion des compétences pertinentes dans le domaine des affaires. Selon mes observations, à l'heure actuelle, certains ingénieurs de données, bien que compétents dans l'utilisation de leurs outils et technologies, manquent de connaissances sur les pratiques de développement de logiciels standard lorsqu'il s'agit de créer des produits de données. Tout d'abord, des pratiques DevOps telles que la livraison continue et les tests automatiques. D'autre part, les développeurs de logiciels qui développent des systèmes d'information n'ont souvent pas suffisamment d'expérience et de connaissances dans le domaine des technologies et des outils pour travailler avec les données en tant que produit.Leur regroupement en équipes multifonctionnelles au sein du domaine de l'entreprise conduira à l'émergence de spécialistes d'un profil plus large. Nous avons observé quelque chose de similaire pendant le développement de DevOps lorsque de nouveaux types d'ingénieurs sont apparus, tels queSRE .

Figure 10: Commande de données de domaine fonctionnel croisé

Infrastructure de données centralisée en tant que plateforme

L'un des aspects sensibles de l'architecture pilotée par domaine distribué de la plate-forme de données est la nécessité de dupliquer dans chaque domaine les efforts et les compétences nécessaires pour exploiter l'infrastructure et la pile technologique utilisées dans les pipelines de données. Heureusement, la création d'une infrastructure commune en tant que plate-forme est une tâche bien apprise à résoudre en informatique (mais pas dans le domaine du travail avec les données).

L'équipe d'infrastructure de données doit posséder et fournir en tant que service les outils nécessaires aux domaines d'activité pour collecter, traiter et stocker leurs produits de données.

Figure 11: Infrastructure de données en tant que plate-forme

L'infrastructure de données en tant que plateforme doit être exempte de tout concept ou logique métier spécifique au domaine. En outre, la plate-forme doit cacher aux utilisateurs la complexité de sa mise en œuvre et fournir le maximum de ses fonctionnalités pour une utilisation en mode libre-service. Voici une liste de certaines des fonctionnalités qu'une infrastructure de données centralisée telle qu'une plate-forme devrait fournir:

Stockage de données évolutif dans différents formats
Cryptage des données (ici hachage, dépersonnalisation, etc.)
Gestion des versions des produits de données
Stockage du schéma de données du produit de données
Contrôle d'accès aux données
Enregistrement
Orchestration des threads / processus de traitement des données
Mise en cache en mémoire
Stockage des métadonnées et de la lignée de données
Surveillance, alertes, journalisation
Calcul des métriques de qualité pour les produits de données
Maintenance du catalogue de données
Normalisation et politiques, la capacité de contrôler la conformité
Adressage des produits de données
Pipelines CI / CD pour les produits de données

Lors de la création d'une infrastructure de données centralisée, il est nécessaire de veiller à ce que la création d'un produit de données sur une telle infrastructure prenne le moins de temps possible. Par conséquent, l'automatisation maximale des fonctionnalités clés est très importante, comme: la possibilité de télécharger des données à l'aide de configurations simples, l'enregistrement automatique d'un produit de données dans le répertoire de données, etc. L'utilisation d'une infrastructure cloud peut réduire les coûts d'exploitation et augmenter la vitesse d'accès à l'infrastructure de données à la demande.

Changement de paradigme vers le Data Mesh

C'était une longue lecture! Résumons brièvement tout ce qui est écrit ci-dessus. Nous avons examiné certaines des caractéristiques clés des plates-formes de données modernes: des pipelines de données centralisés, monolithiques et complexes (avec des centaines et des milliers d'emplois étroitement liés les uns aux autres), des équipes disparates hautement spécialisées. Après, nous avons parlé d'une nouvelle approche de maille de données, qui comprend des produits de données distribués axés sur des domaines commerciaux gérés par des équipes interfonctionnelles (avec des propriétaires de produits de données et des ingénieurs de données), utilisant une infrastructure de données commune comme plate-forme d'hébergement.

Le Data Mesh est une architecture distribuée, avec une gestion centralisée et des normes développées qui garantissent l'intégrabilité des données, et avec une infrastructure centralisée qui permet l'utilisation du libre-service. J'espère que le lecteur est tout à fait évident qu'une telle architecture est très loin d'un ensemble de stockage faiblement couplé de données inaccessibles, développé indépendamment dans différents départements.

Figure 12: Architecture de maillage de données de 10 000 mètres

Vous pouvez vous demander: comment Data Lake ou l'entrepôt de données s'intègrent-ils dans cette architecture? Ce sont simplement des nœuds (domaines) séparés dans cette architecture distribuée. Il est fort probable que dans une telle architecture, nous n'aurons plus besoin de Data Lake. Après tout, nous aurons accès à la recherche des données originales de différents domaines d'activité, conçues sous la forme de produits de données.

Par conséquent, Data Lake n'est plus l'élément central de toute l'architecture. Mais nous continuerons à utiliser les technologies et les outils utilisés pour construire Data Lake, soit pour créer une infrastructure de données commune, soit pour la mise en œuvre interne de nos produits de données.

Cela nous ramène en fait là où tout a commencé. James Dicksonen 2010, il avait l'intention d'utiliser Data Lake pour un domaine d'activité, et plusieurs domaines de données formeraient Water Garden.

Le principal changement de paradigme consiste à considérer le produit de données du domaine commercial comme une tâche prioritaire, et les outils et technologies comme une deuxième tâche prioritaire (comme détail d'implémentation). Il s'agit de détourner le modèle mental d'un Data Lake centralisé vers un écosystème de produits de données qui s'intègrent de manière transparente et efficace les uns aux autres.

Quelques mots sur le reporting et la visualisation (à l'aide d'outils BI, etc.). Le même principe s'applique à eux: dans cette architecture ce sont des nœuds séparés. Ceux. ce sont des produits de données indépendants dans un domaine commercial, axés principalement sur le consommateur et non sur la source de données.

J'admets que même si je vois l'application réussie des principes du maillage de données par mes clients, la mise à l'échelle de ces principes dans les grandes organisations a un long chemin à parcourir. Mais la technologie n'est évidemment pas une limitation ici. Tous les outils que nous utilisons aujourd'hui peuvent également être utilisés pour la distribution et la propriété des produits de données par différentes équipes. En particulier, la transition vers la standardisation des travaux de traitement des données par paquets et en flux, ainsi que l'utilisation d'outils comme Apache Beam ou Google Cloud DataFlow , facilitent le traitement d'une variété d'ensembles de données avec des adresses uniques.

Plateformes de catalogue de données telles que Google Cloud Data Catalog, facilitent la découverte, le contrôle d'accès et la gestion centralisée des ensembles de données des domaines commerciaux distribués. Un grand nombre de plates-formes cloud permet aux domaines d'activité de choisir appropriés pour le stockage ciblé de leurs produits de données.

La nécessité d'un changement de paradigme est évidente. Il y a toutes les technologies et tous les outils nécessaires pour cela. Les dirigeants d'entreprise et les professionnels du traitement des données doivent reconnaître que le paradigme et l'approche actuels du Big Data avec une seule grande plate-forme Data Lake ne feront que répéter les échecs du passé, en utilisant les nouvelles technologies et outils cloud.

Passons d'une plateforme de données monolithique centralisée à un écosystème de produits de données.

Migration d'un Data Lake transparent vers un Data Mesh distribué

L'architecture actuelle de la plateforme de données dans une grande entreprise

Approches architecturales problématiques

Centralisé et monolithique

Décomposition du convoyeur hautement connecté

Des équipes disparates et hautement spécialisées

Architecture de plate-forme de données de nouvelle génération

Architecture pilotée par les données et les domaines distribués

Décomposition et propriété des données en fonction de l'orientation du domaine d'activité

Ensembles de données du domaine source

Ensembles de données de domaine grand public

Pipelines de données distribués implémentés dans leurs domaines

Réflexion sur les données et les produits

Données de domaine en tant que produit

Commodité et facilité de détection (découvrable)

Adresse unique (adressable)

Qualité des données

Description claire de la sémantique et de la syntaxe des données

Intégrabilité des données et normes à l'échelle de l'organisation

Sécurité des données et contrôle d'accès

Commande de données de domaine métier interfonctionnelle

Infrastructure de données centralisée en tant que plateforme

Changement de paradigme vers le Data Mesh

Liens vers des sources primaires et des documents supplémentaires sur le sujet

More articles: