Un maillage de données est un framework architectural et organisationnel qui traite les données comme un produit (appelé produits de données dans ce document). Dans ce framework, les produits de données sont développés par les équipes qui comprennent le mieux ces données et qui suivent un ensemble de normes de gouvernance des données à l'échelle de l'organisation. Une fois les produits de données déployés dans le maillage de données, les équipes distribuées d'une organisation peuvent découvrir et accéder aux données correspondant à leurs besoins plus rapidement et plus efficacement. Pour obtenir un tel maillage de données, vous devez d'abord établir les composants architecturaux et les rôles organisationnels de premier niveau décrits dans ce document.
Ce document fait partie d'une série qui décrit comment mettre en œuvre un maillage de données sur Google Cloud. Nous partons du principe que vous avez lu et que vous connaissez les concepts décrits sur la page Créer un maillage de données moderne et distribué avec Google Cloud.
La série se compose des parties suivantes :
- Architecture et fonctions dans un maillage de données (ce document)
- Concevoir une plate-forme de données en libre-service pour un maillage de données
- Créer des produits de données dans un maillage de données
- Découvrir et consommer des produits de données dans un maillage de données
Dans cette série, le maillage de données décrit est interne à une organisation. Bien qu'il soit possible d'étendre une architecture de maillage de données pour fournir des produits de données à des tiers, cette approche étendue n'entre pas dans le cadre de ce document. L'extension d'un maillage de données implique des considérations supplémentaires au-delà de l'utilisation au sein d'une organisation.
Architecture
Les termes clés suivants sont utilisés pour définir les composants architecturaux décrits dans cette série :
- Produit de données : un produit de données est un conteneur logique ou un regroupement d'une ou de plusieurs ressources de données associées.
- Ressource de données : une ressource de données est un élément physique dans un système de stockage qui contient des données structurées ou stocke une requête qui génère des données structurées.
- Attribut de données : un attribut de données est un champ ou un élément d'une ressource de données.
Le schéma suivant présente les principaux composants architecturaux d'un maillage de données implémenté sur Google Cloud.
Le schéma précédent montre les éléments suivants :
- Les services centraux permettent de créer et de gérer des produits de données, y compris des règles d'administration qui affectent les participants au maillage de données, des contrôles d'accès (via des groupes Identity and Access Management) et des artefacts spécifiques à l'infrastructure. Des exemples de ces engagements et réservations, ainsi que les infrastructures qui facilitent le fonctionnement du maillage de données, sont décrits dans la section Créer des composants et des solutions de plate-forme.
- Les services centraux fournissent principalement le catalogue de données pour tous les produits de données du maillage de données et le mécanisme de découverte pour les clients potentiels de ces produits.
- Les domaines de données exposent des sous-ensembles de leurs données sous forme de produits de données via des interfaces de consommation de données bien définies. Ces produits de données peuvent être une table, une vue, un fichier structuré, un sujet ou un flux. Dans BigQuery, il s'agit d'un ensemble de données et, dans Cloud Storage, d'un dossier ou d'un bucket. Plusieurs types d'interfaces peuvent être exposés en tant que produit de données. Une vue BigQuery constitue un exemple d'interface sur une table BigQuery. Les types d'interfaces les plus couramment utilisés à des fins d'analyse sont décrits dans la section Créer des produits de données dans un maillage de données.
Mise en œuvre de référence d'un maillage de données
Vous trouverez une mise en œuvre de référence de cette architecture dans le dépôt data-mesh-demo.
Les scripts Terraform utilisés dans la mise en œuvre de référence illustrent les concepts du maillage de données et ne sont pas destinés à être utilisés en production. En exécutant ces scripts, vous allez apprendre à effectuer les opérations suivantes :
- séparer les définitions de produit des données sous-jacentes ;
- créer des modèles Data Catalog pour décrire les interfaces de produit ;
- ajouter des tags aux interfaces de produit à l'aide de ces modèles ;
- accorder des autorisations aux utilisateurs des produits.
Pour les interfaces de produit, la mise en œuvre de référence crée et utilise les types d'interfaces suivants :
- Vues autorisées sur les tables BigQuery.
- Flux de données basés sur des sujets Pub/Sub.
Pour plus de détails, consultez le fichier README du dépôt.
Fonctions dans un maillage de données
Pour qu'un maillage de données fonctionne correctement, vous devez définir des rôles clairs pour les personnes qui effectuent des tâches au sein du maillage de données. La propriété est attribuée aux archétypes ou aux fonctions de l'équipe. Ces fonctions contiennent les parcours utilisateur principaux pour les personnes qui travaillent dans le maillage de données. Pour décrire clairement les parcours utilisateur, ils ont été affectés à des rôles utilisateur. Ces rôles utilisateur peuvent être divisés et combinés en fonction des circonstances de chaque entreprise. Vous n'avez pas besoin de mapper les rôles directement aux employés ou équipes de votre organisation.
Un domaine de données est aligné sur une unité commerciale (BU) ou sur une fonction au sein d'une entreprise. Le service des prêts hypothécaires d'une banque ou les services client, de distribution, financiers ou des ressources humaines d'une entreprise en sont des exemples courants. Conceptuellement, un maillage de données comporte deux fonctions liées au domaine : les équipes des producteurs de données et les équipes des consommateurs de données. Il est important de comprendre qu'un seul domaine de données est susceptible de diffuser les deux fonctions à la fois. Une équipe de domaine de données produit des produits de données à partir de ses propres données. L'équipe utilise également des produits de données pour obtenir des insights métier et des produits de données dérivés destinés à l'utilisation d'autres domaines.
En plus des fonctions basées sur le domaine, un maillage de données comprend également un ensemble de fonctions effectuées par des équipes centralisées au sein de l'organisation. Ces équipes centrales permettent le fonctionnement du maillage de données en fournissant une surveillance interdomaine, des services et une gouvernance. Elles réduisent la charge opérationnelle des domaines de données dans la production et la consommation de produits de données, et facilitent les relations interdomaines requises pour le fonctionnement du maillage de données.
Ce document ne décrit que les fonctions ayant un rôle spécifique au maillage de données. Plusieurs autres rôles sont requis dans toute entreprise, quelle que soit l'architecture employée pour la plate-forme. Toutefois, ces autres rôles n'entrent pas dans le cadre de ce document.
Les quatre fonctions principales d'un maillage de données sont les suivantes :
- Équipes de producteurs basées sur le domaine des données : créent et gèrent des produits de données tout au long de leur cycle de vie. Ces équipes sont souvent appelées producteurs de données.
- Équipes de consommateurs de données basées sur le domaine : découvrent les produits de données et les utilisent dans diverses applications analytiques. Ces équipes peuvent consommer des produits de données pour créer des produits de données. Ces équipes sont souvent appelées consommateurs de données.
- Équipe centrale de gouvernance des données : définit et applique des règles de gouvernance des données entre les producteurs de données, afin d'assurer la qualité et la fiabilité des données pour les consommateurs. Cette équipe est souvent appelée équipe de gouvernance des données.
- Équipe centralisée de plate-forme d'infrastructure en libre-service : fournit une plate-forme de données en libre-service aux producteurs de données. Elle fournit également les outils nécessaires à la découverte centrale de données et à l'observabilité des produits de données, que les consommateurs et les producteurs de données utilisent. Cette équipe est souvent appelée équipe chargée de la plate-forme de données.
Une fonction supplémentaire facultative à prendre en compte est celle d'un centre d'excellence pour le maillage de données. L'objectif de la COE est de permettre la gestion du maillage de données. Cette équipe est également l'équipe d'arbitrage désignée, qui résout les conflits générés par l'une des autres fonctions. Cette fonction est utile pour connecter les quatre autres fonctions.
Équipe de producteurs basée sur les domaines de données
En règle générale, les produits de données sont basés sur un dépôt physique de données (entrepôts de données uniques ou multiples, lacs ou flux). Une organisation a besoin de rôles traditionnels pour les plates-formes de données afin de créer et de gérer ces dépôts physiques. Cependant, ces rôles traditionnels ne sont généralement pas ceux qui créent le produit de données.
Pour créer des produits de données à partir de ces dépôts physiques, une organisation doit combiner des experts en données, tels que des ingénieurs de données et des architectes de données. Le tableau suivant répertorie tous les rôles utilisateur spécifiques au domaine dont les équipes de producteurs de données ont besoin.
Rôle |
Responsabilités |
Compétences requises |
Résultats escomptés |
|---|---|---|---|
Propriétaire de produits de données |
|
Analyse de données Architecture de données Gestion des produits |
|
Responsable technique des produits de données |
|
Ingénierie des données Architecture des données Ingénierie logicielle |
|
Assistance produit sur les données |
|
Ingénierie technique Ingénierie en fiabilité des sites (SRE) |
|
Expertise en matière de domaine de données |
|
Analyse de données Architecture des données |
|
Propriétaire des données |
|
|
|
Équipes grand public basées sur les domaines
Dans un maillage de données, les personnes qui utilisent un produit de données sont généralement des utilisateurs de données qui ne font pas partie du domaine du produit de données. Ces consommateurs de données utilisent un catalogue de données central pour trouver des produits de données adaptés à leurs besoins. Étant donné que plusieurs produits de données peuvent répondre à leurs besoins, les consommateurs de données peuvent s'abonner à plusieurs produits de données.
Si les consommateurs de données ne parviennent pas à trouver le produit de données requis pour leur cas d'utilisation, ils doivent consulter directement le COE du maillage de données. Au cours de cette consultation, les consommateurs de données peuvent exposer leurs besoins et obtenir des conseils sur la manière dont ces besoins peuvent être satisfaits par un ou plusieurs domaines.
Lorsqu'ils recherchent un produit de données, les utilisateurs recherchent des données qui les aident à exécuter divers cas d'utilisation, tels que des tableaux de bord et des rapports d'analyse persistants, des rapports sur les performances individuelles et d'autres métriques de performances métier. Les clients de données peuvent également rechercher des produits de données pouvant être utilisés dans les cas d'utilisation de l'intelligence artificielle (IA) et du machine learning (ML). Pour exécuter ces différents cas d'utilisation, les consommateurs de données doivent combiner différents personas de données comme suit :
Rôle |
Responsabilités |
Compétences requises |
Résultats escomptés |
|---|---|---|---|
Analyste de données |
Recherche, identifie, évalue et s'abonne aux produits de données monodomaine ou interdomaines pour créer les bases des frameworks d'informatique décisionnelle. |
Ingénierie d'analyse Analyse commerciale |
|
Développeur d'applications |
Développe un framework d'application pour la consommation de données dans un ou plusieurs produits de données, à l'intérieur ou à l'extérieur du domaine. |
Développement d'applications Ingénierie des données |
|
Spécialiste en visualisation des données |
|
Analyse des exigences Visualisation des données |
|
Data scientist |
|
Ingénierie ML Ingénierie d'analyse |
|
Équipe centrale de gouvernance des données
L'équipe chargée de la gouvernance des données permet aux producteurs et aux consommateurs de partager, d'agréger et de calculer en toute sécurité des données en libre-service, sans présenter de risques de conformité pour l'organisation.
Pour répondre aux exigences de conformité de l'organisation, l'équipe de gouvernance des données est constituée de spécialistes du domaine des données comme suit :
Rôle |
Responsabilités |
Compétences requises |
Résultats escomptés |
|---|---|---|---|
Spécialiste en gouvernance des données |
|
Expert juridique Expert de la sécurité Expert de la confidentialité des données |
|
Responsable des données (position dans chaque domaine) |
|
Architecture de données Intendance des données |
|
Ingénieur de gouvernance des données |
|
Ingénierie logicielle |
|
Équipe centrale de la plate-forme d'infrastructure de données en libre-service
L'équipe en charge de la plate-forme d'infrastructure de données en libre-service, ou seulement celle de la plate-forme de données, est chargée de créer un ensemble de composants d'infrastructure de données. Les équipes de domaine de données distribuées utilisent ces composants pour créer et déployer leurs produits de données. L'équipe chargée de la plate-forme de données favorise également les bonnes pratiques, et présente des outils et des méthodologies qui permettent de réduire la charge cognitive pour les équipes distribuées lors de l'adoption de nouvelles technologies.
L'infrastructure de la plate-forme doit fournir une intégration facile aux outils d'opérations pour l'observabilité globale, l'instrumentation et l'automatisation de la conformité. L'infrastructure doit également faciliter cette intégration pour mettre en place des équipes distribuées performantes.
L'équipe chargée de la plate-forme de données utilise un modèle de responsabilité partagée qu'elle exploite avec les équipes de domaines distribués et l'équipe chargée de l'infrastructure sous-jacente. Le modèle indique les responsabilités attendues des consommateurs de la plate-forme et les composants de la plate-forme compatibles avec l'équipe.
La plate-forme de données étant elle-même un produit interne, elle n'est pas compatible avec tous les cas d'utilisation. À la place, l'équipe chargée de la plate-forme de données publie en permanence de nouveaux services et fonctionnalités selon une feuille de route prioritaire.
L'équipe chargée de la plate-forme de données peut disposer d'un ensemble standard de composants en place et en développement. Toutefois, les équipes chargées des domaines de données peuvent choisir d'utiliser un ensemble de composants différent, si les besoins d'une équipe ne correspondent pas à ceux fournis par la plate-forme de données. Si les équipes chargées des domaines des données adoptent une approche différente, elles doivent s'assurer que toute infrastructure de plate-forme qu'elles créent et gèrent respecte les règles et les garde-fous à l'échelle de l'organisation en matière de sécurité et de gouvernance des données. Pour l'infrastructure de plate-forme de données développée en dehors de l'équipe centrale de la plate-forme de données, l'équipe peut choisir d'investir dans ses propres ingénieurs ou d'y intégrer ses propres ingénieurs. Le fait que l'équipe chargée de la plate-forme de données choisisse de co-investir ou d'intégrer les ingénieurs peut dépendre de l'importance stratégique de l'infrastructure de la plate-forme de données pour l'organisation. En restant impliquées dans le développement de l'infrastructure par le biais des équipes de domaines de données, les entreprises peuvent fournir l'alignement et l'expertise technique nécessaires pour regrouper de nouveaux composants d'infrastructure de plate-forme en cours de développement.
Vous devrez peut-être limiter l'autonomie aux premières étapes de la création d'un maillage de données si votre objectif initial est d'obtenir l'approbation des personnes concernées pour faire évoluer le maillage de données. Cependant, limiter l'autonomie risque de créer un goulot d'étranglement au niveau de l'équipe centrale des plates-formes de données. Ce goulot d'étranglement peut entraver le redimensionnement du maillage des données. Par conséquent, toutes les décisions de centralisation doivent être prises avec précaution. Pour les producteurs de données, il est préférable de faire les choix techniques parmi un ensemble limité d'options disponibles afin d'évaluer et de choisir parmi une liste illimitée d'options elles-mêmes. Promouvoir l'autonomie des producteurs de données ne doit pas se traduire par un environnement technologique surchargé. L'objectif est plutôt de favoriser la conformité et l'adoption de la plate-forme en trouvant le juste équilibre entre liberté de choix et standardisation.
Enfin, une bonne équipe en charge de la plate-forme de données est une source centrale de formation et de bonnes pratiques pour le reste de l'entreprise. Voici quelques-unes des activités les plus utiles que nous recommandons aux équipes chargées de la plate-forme de données centrale :
- Encourager les examens réguliers de la conception architecturale pour de nouveaux projets fonctionnels et proposer des méthodes de développement communes aux équipes de développement.
- Partager les connaissances et les expériences, et définir collectivement les bonnes pratiques et les consignes d'architecture.
- S'assurer que les ingénieurs disposent des outils appropriés pour valider et vérifier les problèmes courants, tels que les problèmes de code, de bugs et de dégradation des performances.
- Organiser des hackathons internes afin que les équipes de développement puissent répondre à leurs besoins en termes d'outils internes.
Voici quelques exemples de rôles et de responsabilités pour l'équipe chargée de la plate-forme de données centrale :
| Rôle | Responsabilités | Compétences requises |
Résultats escomptés |
|---|---|---|---|
Propriétaire de produits de plate-forme de données |
|
Stratégie et opérations sur les données Gestion des produits Gestion des personnes concernées |
|
Ingénieur de plate-forme de données |
|
Ingénierie des données Ingénierie logicielle |
|
Ingénieur de plate-forme et de sécurité (représentant des équipes informatiques centrales, telles que la mise en réseau et la sécurité), intégré à l'équipe chargée de la plate-forme de données. |
|
Ingénierie en infrastructure Ingénierie logicielle |
|
Architecte d'entreprise |
|
Architecture de données Itération de solutions et résolution de problèmes Création d'un consensus |
|
Informations complémentaires pour un maillage de données
Il existe plusieurs options architecturales pour une plate-forme de données d'analyse, chacune avec des conditions préalables différentes. Pour activer chaque architecture de maillage de données, nous vous recommandons de respecter les bonnes pratiques décrites dans cette section.
Obtenir un financement de la plate-forme
Comme expliqué dans l'article du blog If you want to transform start with finance ("Si vous recherchez des financements pour transformer votre activité"), la plate-forme n'est jamais terminée. Elle fonctionne toujours sur la base d'une feuille de route prioritaire. Par conséquent, la plate-forme doit être financée en tant que produit, et non en tant que projet avec un point de terminaison fixe.
Le premier utilisateur du maillage de données supporte le coût. En règle générale, le coût est partagé entre l'entreprise qui constitue le premier domaine de données pour lancer le maillage de données et l'équipe technologique centrale, qui héberge généralement l'équipe chargée de la plate-forme de données centrale.
Pour inciter les équipes financières à approuver le financement de la plate-forme centrale, nous vous recommandons d'effectuer une analyse de la valeur de la plate-forme centralisée qui sera mise en œuvre au fil du temps. Cette valeur provient de l'implémentation des mêmes composants dans des équipes de diffusion individuelles.
Définir la plate-forme minimale viable pour le maillage de données
Pour vous aider à définir la plate-forme minimale viable pour le maillage de données, nous vous recommandons de tester et d'itérer un ou plusieurs cas d'utilisation. Pour votre pilote, trouvez les cas d'utilisation nécessaires et ceux où un consommateur est prêt à adopter le produit de données correspondant. Les cas d'utilisation devraient déjà disposer d'un financement pour développer les produits de données, mais l'intervention des équipes techniques peut être nécessaire.
Assurez-vous que l'équipe qui implémente le pilote comprend le modèle d'exploitation du maillage de données comme suit :
- L'entreprise (c'est-à-dire l'équipe du producteur de données) est propriétaire des tâches en attente, de l'assistance et de la maintenance.
- L'équipe centrale définit les modèles en libre-service et aide l'entreprise à créer le produit de données, mais elle transmet le produit de données à l'entreprise pour qu'elle l'exécute et la gère une fois l'opération terminée.
- L'objectif principal est de démontrer le modèle d'exploitation métier (domaines de produits, consommation de domaines). L'objectif secondaire est de démontrer le modèle d'exploitation technique (modèles en libre-service développés par l'équipe centrale).
- Comme les ressources de l'équipe chargée de la plate-forme sont limitées, utilisez le modèle d'équipes de type "trunk and branch" pour regrouper les connaissances tout en permettant le développement de services et de produits spécialisés sur la plate-forme.
Nous vous recommandons également d'effectuer les opérations suivantes :
- Planifiez vos feuilles de route plutôt que de laisser vos services et fonctionnalités évoluer de façon naturelle.
- Définissez les capacités minimales des plates-formes viables, telles que l'ingestion, le stockage, le traitement, l'analyse et le ML
- Intégrez la gouvernance des données à chaque étape, et non en tant que flux de travail distinct.
- Mettez en place les capacités minimales pour la gouvernance, la plate-forme, le flux de valeur et la gestion du changement. Les capacités minimales sont celles qui répondent à 80 % des cas d'utilisation.
Planifier la coexistence du maillage de données avec une plate-forme de données existante
De nombreuses organisations souhaitant mettre en œuvre un maillage de données disposent probablement déjà d'une plate-forme de données existante, telle qu'un lac de données, un entrepôt de données ou une combinaison des deux. Avant de mettre en œuvre un maillage de données, ces organisations doivent planifier la manière dont leur plate-forme de données existante peut évoluer à mesure que le maillage de données se développe.
Ces organisations doivent tenir compte de facteurs tels que les suivants :
- Ressources de données les plus efficaces sur le maillage de données.
- Éléments qui doivent rester dans la plate-forme de données existante.
- Les éléments doivent-ils être déplacés ou conservés sur la plate-forme existante tout en continuant à participer au maillage de données.
Étapes suivantes
- Pour en savoir plus sur la conception et l'exploitation d'une topologie cloud, consultez le framework d'architecture Google Cloud.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.