Guide de l'utilisateur du maillage de données

Data Mesh pour Cortex Framework étend la base de données pour permettre la gouvernance, la détectabilité et le contrôle des accès aux données grâce aux métadonnées BigQuery et à Dataplex Universal Catalog. Pour ce faire, nous fournissons un ensemble de base de ressources de métadonnées et d'annotations d'assets BigQuery qui peuvent être personnalisées et éventuellement déployées avec la base de données. Ces spécifications de base fournissent une configuration personnalisée qui constitue la base des métadonnées pour compléter la base de données Cortex Framework. Consultez les concepts du data mesh avant de continuer à lire ce guide.

Les étapes décrites sur cette page sont spécifiquement conçues pour configurer le data mesh pour Cortex Framework. Recherchez les fichiers de configuration Data Mesh dans les dossiers spécifiques à chaque charge de travail de la section Répertoires Data Mesh.

Conception

La structure Data Mesh de Cortex est conçue de la même manière que la structure de données globale. Elle se compose de trois phases avec différents sous-composants gérés par Cortex ou les utilisateurs :

1. Mise à jour des spécifications des ressources de base : à chaque version, Cortex met à jour les spécifications des ressources de base, fournissant ainsi une base de métadonnées standardisée pour le maillage de données.
2. Personnalisation des spécifications de ressources : avant le déploiement, les utilisateurs peuvent adapter les spécifications de ressources à leurs cas d'utilisation et exigences spécifiques.
3. Déploiement et mises à jour du data mesh : les utilisateurs peuvent activer le data mesh dans le fichier de configuration Cortex. Il est déployé après les composants de données lors du déploiement de Cortex. De plus, les utilisateurs peuvent déployer le Data Mesh de manière indépendante pour effectuer d'autres mises à jour.

Répertoires du maillage de données

Vous trouverez les fichiers de configuration de base du data mesh pour chaque charge de travail et source de données aux emplacements suivants. Notez que les répertoires contiennent différentes structures de fichiers, mais que toutes les spécifications se trouvent de la même manière dans le dossier config.

Les ressources de métadonnées sont définies au niveau de la source de données avec un seul fichier YAML par projet Google Cloud et contiennent la liste de toutes les ressources. Si nécessaire, les utilisateurs peuvent étendre le fichier existant ou créer des fichiers YAML supplémentaires contenant des spécifications de ressources supplémentaires dans ce répertoire.

Les annotations d'assets sont définies au niveau de l'asset et contiennent de nombreux fichiers YAML dans le répertoire, avec une seule annotation par fichier.

Activer les API et vérifier les autorisations

La modification des valeurs par défaut pour le data mesh vous permet d'implémenter des fonctionnalités au-delà des descriptions. Si vous devez modifier les valeurs par défaut de Data Mesh dans config.json pour implémenter des fonctionnalités au-delà des descriptions, assurez-vous que les API nécessaires et les autorisations sont définies comme indiqué dans le tableau suivant. Lorsque vous déployez un data mesh avec la base de données, accordez des autorisations à l'utilisateur qui effectue le déploiement ou au compte Cloud Build. Si le déploiement implique des projets source et cible différents, assurez-vous que ces API et autorisations sont activées dans les deux projets chaque fois que ces fonctionnalités sont utilisées.

Comprendre les caractéristiques de la ressource de base

L'interface principale pour configurer le Data Mesh pour Cortex se fait par le biais des spécifications de ressources de base, qui sont un ensemble de fichiers YAML fournis prêts à l'emploi et qui définissent les ressources de métadonnées et les annotations déployées. Les spécifications de base fournissent des recommandations initiales et des exemples de syntaxe, mais sont destinées à être personnalisées davantage pour répondre aux besoins des utilisateurs. Ces spécifications se divisent en deux catégories :

• Ressources de métadonnées pouvant être appliquées à différents assets de données. Par exemple, les modèles de tag de catalogue qui définissent comment les composants peuvent être tagués avec des domaines d'activité.
• Annotations qui spécifient comment les ressources de métadonnées sont appliquées à un élément de données particulier. Par exemple, un tag de catalogue qui associe un tableau spécifique au domaine "Ventes".

Les sections suivantes vous guident à travers des exemples de base de chaque type de spécification et expliquent comment les personnaliser. Les spécifications de base sont taguées avec ## CORTEX-CUSTOMER et doivent être modifiées pour s'adapter à un déploiement si l'option de déploiement associée est activée. Pour les utilisations avancées, consultez la définition canonique de ces schémas de spécification dans src/common/data_mesh/src/data_mesh_types.py.

Ressources de métadonnées

Les ressources de métadonnées sont des entités partagées qui existent dans un projet et qui peuvent être appliquées à de nombreux assets de données. La plupart des spécifications incluent un champ display_name soumis aux critères suivants :

• Ne contenir que des lettres Unicode, des chiffres (0 à 9), des traits de soulignement (_), des tirets (-) et des espaces ( ).
• Il ne doit pas commencer ni se terminer par des espaces.
• Ne doit pas dépasser 200 caractères.

Dans certains cas, le display_name est également utilisé comme ID, ce qui peut entraîner des exigences supplémentaires. Dans ce cas, des liens vers la documentation canonique sont inclus.

Si le déploiement fait référence à des ressources de métadonnées dans des projets source et cible différents, une spécification doit être définie pour chaque projet. Par exemple, Cortex Salesforce (SFDC) contient deux spécifications de lac. L'un pour les zones brutes et CDC, et l'autre pour les rapports.

Lacs Dataplex Universal Catalog

Les lacs, zones et éléments Dataplex Universal Catalog permettent d'organiser les données d'un point de vue technique. Les lacs ont un region et les zones ont un location_type. Ces deux éléments sont liés à l'emplacement Cortex (config.json > location). L'emplacement Cortex définit l'endroit où les ensembles de données BigQuery sont stockés. Il peut s'agir d'une région unique ou multirégionale. La zone location_type doit être définie sur SINGLE_REGION | MULTI_REGION pour correspondre. Toutefois, les régions Lake doivent toujours être une seule région. Si l'emplacement et la zone Cortex location_type sont multirégionaux, sélectionnez une seule région dans ce groupe pour la région du lac.

• Conditions requises
  • Le lac display_name est utilisé comme lake_id et doit respecter les exigences officielles. Il en va de même pour les zones et les composants display_name. Les ID de zone doivent être uniques pour tous les lacs du projet.
  • Les spécifications du lac doivent être associées à une seule région.
  • asset_name doit correspondre à l'ID de l'ensemble de données BigQuery, mais display_name peut être un libellé plus convivial.
• Limites
  • Dataplex Universal Catalog n'accepte que l'enregistrement des ensembles de données BigQuery, et non des tables individuelles, en tant qu'éléments Dataplex Universal Catalog.
  • Il est possible qu'un élément ne soit enregistré que dans une seule zone.
  • Dataplex Universal Catalog n'est disponible que dans certaines régions. Pour en savoir plus, consultez Emplacements de Dataplex Universal Catalog.

Consultez l'exemple suivant dans lakes.yaml.

Ces ressources sont définies dans des fichiers YAML qui spécifient data_mesh_types.Lakes.

Modèles de tags de catalogue

Les modèles de tags Data Catalog peuvent être utilisés pour ajouter du contexte aux tables BigQuery ou à des colonnes individuelles. Ils vous aident à catégoriser et à comprendre vos données d'un point de vue technique et commercial, de manière intégrée aux outils de recherche Dataplex Universal Catalog. Ils définissent les champs spécifiques que vous pouvez utiliser pour libeller vos données et le type d'informations que chaque champ peut contenir (par exemple, du texte, un nombre ou une date). Les tags de catalogue sont des instances des modèles avec des valeurs de champ réelles.

Le champ de modèle display_name est utilisé comme ID de champ et doit respecter les exigences de TagTemplate.fields spécifiées dans Class TagTemplate. Pour en savoir plus sur les types de champs acceptés, consultez Types de champs Data Catalog.

Cortex Data Mesh crée tous les modèles de tag en lecture publique. Il introduit également un concept level supplémentaire dans les spécifications des modèles de balises, qui définit si une balise doit être appliquée à un élément entier, à des champs individuels d'un élément ou aux deux, avec les valeurs possibles : ASSET | FIELD | ANY. Bien que cela ne soit pas strictement appliqué pour le moment, les futures vérifications de validation pourront garantir que les tags sont appliqués au niveau approprié lors du déploiement.

Consultez l'exemple ci-dessous.

Les modèles sont définis dans des fichiers YAML qui spécifient data_mesh_types.CatalogTagTemplates.

Les tags de catalogue sont des instances des modèles. Ils sont abordés ci-dessous dans la section "Annotations des composants".

Contrôle des accès au niveau des éléments et des colonnes avec les modèles de tags

Cortex Framework permet d'activer le contrôle des accès au niveau des composants ou des colonnes pour tous les artefacts associés à un modèle de tag de catalogue. Par exemple, si les utilisateurs souhaitent accorder l'accès aux composants en fonction du secteur d'activité, ils peuvent créer asset_policies pour le modèle de balise de catalogue line_of_business avec différents principaux spécifiés pour chaque domaine d'activité. Chaque règle accepte filters qui peut être utilisé pour ne faire correspondre que les tags avec des valeurs spécifiques. Dans ce cas, nous pourrions faire correspondre les valeurs domain. Notez que ces filters ne sont compatibles qu'avec la correspondance pour l'égalité et aucun autre opérateur. Si plusieurs filtres sont listés, les résultats doivent les satisfaire tous (par exemple, filter_a AND filter_b). L'ensemble final de règles relatives aux composants est l'union de celles définies directement dans les annotations et de celles des règles du modèle.

Le contrôle des accès au niveau des colonnes avec les tags de catalogue fonctionne de la même manière en appliquant des tags avec stratégie aux champs correspondants. Toutefois, comme un seul tag avec stratégie peut être appliqué à une colonne, la priorité est la suivante :

1. Tag avec stratégie direct : si un tag avec stratégie est défini directement dans l'annotation de colonne, il est prioritaire.
2. Règles relatives aux modèles de tags correspondants : sinon, l'accès est déterminé par la première règle correspondante définie sur un champ dans le modèle de tag de catalogue associé.

Lorsque vous utilisez cette fonctionnalité, nous vous recommandons vivement d'activer ou de désactiver le déploiement des tags de catalogue et des listes de contrôle d'accès (LCA) ensemble. Cela garantit que les ACL sont correctement déployées.

Pour comprendre les spécifications de cette fonctionnalité avancée, consultez les définitions des paramètres asset_policies et field_policies dans data_mesh_types.CatalogTagTemplate.

Glossaire des catalogues

Le glossaire est un outil qui peut être utilisé pour fournir un dictionnaire des termes utilisés par des colonnes spécifiques dans les composants de données qui ne sont pas universellement compris. Les utilisateurs peuvent ajouter des termes manuellement dans la console, mais les spécifications de ressources ne sont pas compatibles.

Taxonomies et tags de stratégie

Les taxonomies et les tags de règles permettent un contrôle des accès au niveau des colonnes sur les éléments de données sensibles de manière standardisée. Par exemple, il peut exister une taxonomie pour les tags contrôlant les données PII dans un secteur d'activité spécifique, où seuls certains groupes peuvent lire les données masquées, les données non masquées ou n'ont pas du tout accès en lecture.

Pour en savoir plus sur les taxonomies et les tags de règles, consultez la documentation Introduction au masquage des données de colonne. Les sections suivantes sont particulièrement pertinentes :

• Interaction entre les rôles
• Héritage des autorisations
• Règles de masquage et hiérarchie
• Bonnes pratiques concernant les tags de règlement

Cortex Framework fournit des exemples de tags de règles pour montrer comment ils sont spécifiés et leurs utilisations potentielles. Toutefois, les ressources qui affectent le contrôle des accès ne sont pas activées par défaut dans le déploiement Data Mesh.

Consultez l'exemple ci-dessous.

Les taxonomies de règles sont définies dans des fichiers YAML qui spécifient data_mesh_types.PolicyTaxonomies.

Annotations de composants

Les annotations spécifient les métadonnées applicables à un élément particulier et peuvent faire référence aux ressources de métadonnées partagées qui ont été définies. Voici quelques exemples d'annotations :

• Descriptions des composants
• Descriptions de champs
• Tags de catalogue
• Contrôle des accès au niveau des composants, des lignes et des colonnes

La base de données Cortex Framework propose des annotations (descriptions) préconfigurées pour les charges de travail suivantes.

• SAP ECC (données brutes, CDC et rapports)
• SAP S4 HANA (données brutes, CDC et reporting)
• SFDC (rapports uniquement)
• Oracle EBS (reporting uniquement)
• CM360 (reporting uniquement)
• Google Ads (rapports uniquement)
• Meta (rapports uniquement)
• SFMC (rapports uniquement)
• TikTok (rapports uniquement)
• YouTube (avec DV360) (rapports uniquement)
• Google Analytics 4 (rapports uniquement)

Consultez l'exemple ci-dessous.

Les annotations sont définies dans des fichiers YAML qui spécifient data_mesh_types.BqAssetAnnotation.

Tags de catalogue

Les tags de catalogue sont des instances des modèles définis, dans lesquelles des valeurs de champ sont attribuées et s'appliquent à l'élément spécifique. Veillez à attribuer des valeurs qui correspondent aux types de champs déclarés dans le modèle associé.

Les valeurs TIMESTAMP doivent être dans l'un des formats suivants :

  "%Y-%m-%d %H:%M:%S%z"
  "%Y-%m-%d %H:%M:%S"
  "%Y-%m-%d"

Consultez l'exemple ci-dessous.

Consultez la définition des spécifications dans data_mesh_types.CatalogTag.

Spécifier les lecteurs et les comptes principaux de la stratégie d'accès

Contrôlez l'accès à vos données BigQuery dans Cortex Framework à l'aide de règles d'accès. Ces règles définissent qui (comptes principaux) peut accéder à des éléments de données spécifiques, à des lignes d'un élément ou même à des colonnes individuelles. Les comptes principaux doivent respecter un format spécifique défini par IAM Policy Binding member.

Accès au niveau des composants

Vous pouvez accorder l'accès à des composants BigQuery entiers avec différentes autorisations :

• READER : afficher les données de l'élément.
• WRITER : modifiez et ajoutez des données à l'élément.
• OWNER : contrôle total sur le composant, y compris la gestion de l'accès.

Ces autorisations sont équivalentes à l'instruction GRANT DCL en SQL.

Contrairement au comportement de la plupart des ressources et annotations, l'indicateur d'écrasement ne supprime pas les comptes principaux existants avec le rôle OWNERS. Lorsque vous ajoutez des propriétaires en activant l'option d'écrasement, ils sont uniquement ajoutés aux propriétaires existants. Il s'agit d'une mesure de protection visant à éviter toute perte d'accès involontaire. Pour supprimer des propriétaires d'éléments, utilisez la console. L'écrasement supprime les comptes principaux existants avec le rôle READER ou WRITER.

Consultez l'exemple ci-dessous.

Consultez la définition des spécifications dans data_mesh_types.BqAssetPolicy.

Accès au niveau des lignes

Vous pouvez accorder l'accès à des ensembles de lignes en fonction de certains filtres de valeurs de colonnes. Lorsque vous spécifiez la règle d'accès aux lignes, la chaîne de filtre fournie est insérée dans un CREATE DDL statement. Si l'indicateur overwrite est activé, toutes les règles d'accès aux lignes existantes sont supprimées avant l'application de nouvelles règles.

Voici quelques points à prendre en compte concernant l'accès au niveau des lignes :

• Si vous ajoutez des règles d'accès aux lignes, les utilisateurs qui ne sont pas spécifiés dans ces règles n'auront accès à aucune ligne.
• Les règles de ligne ne fonctionnent qu'avec les tables, et non avec les vues.
• Évitez d'utiliser des colonnes partitionnées dans les filtres de vos règles d'accès aux lignes. Consultez le fichier YAML des paramètres de création de rapports associés pour obtenir des informations sur le type d'actif et les colonnes partitionnées.

Pour en savoir plus sur les règles d'accès au niveau des lignes, consultez les bonnes pratiques en matière de sécurité au niveau des lignes.

Consultez l'exemple ci-dessous.

Consultez la définition des spécifications dans data_mesh_types.BqRowPolicy.

Accès au niveau des colonnes

Pour activer l'accès au niveau des colonnes, annotez les champs individuels avec un tag avec stratégie identifié par le nom du tag avec stratégie et le nom de la taxonomie. Mettez à jour la ressource de métadonnées du tag avec stratégie pour configurer le contrôle des accès.

Consultez l'exemple ci-dessous.

Consultez la définition des spécifications dans data_mesh_types.PolicyTagId.

Déployer le maillage de données

Le Data Mesh peut être déployé dans le cadre du déploiement de la base de données ou de manière autonome. Dans les deux cas, il utilise le fichier Cortex config.json pour déterminer les variables pertinentes, telles que les noms des ensembles de données BigQuery et les options de déploiement. Par défaut, le déploiement du Data Mesh ne supprime ni n'écrase aucune ressource ni annotation existantes pour éviter toute perte involontaire. Toutefois, il est également possible d'écraser les ressources existantes lorsqu'il est déployé seul.

Options de déploiement

Les options de déploiement suivantes peuvent être activées ou désactivées en fonction des besoins de l'utilisateur et des contraintes de dépenses dans config.json > DataMesh.

Déployer avec Data Foundation

Par défaut, config.json > deployDataMesh permet de déployer les descriptions des composants du data mesh à la fin de chaque étape de compilation de charge de travail. Cette configuration par défaut ne nécessite l'activation d'aucune API ni d'aucun rôle supplémentaires. Des fonctionnalités supplémentaires du Data Mesh peuvent être déployées avec la base de données en activant les options de déploiement, les API et les rôles requis, et en modifiant les spécifications de ressources associées.

Déploiement seul

Pour déployer le maillage de données seul, les utilisateurs peuvent utiliser le fichier common/data_mesh/deploy_data_mesh.py. Cet utilitaire est utilisé lors des processus de compilation pour déployer le data mesh une charge de travail à la fois, mais lorsqu'il est appelé directement, il peut également être utilisé pour déployer plusieurs charges de travail à la fois. Les charges de travail pour lesquelles les spécifications doivent être déployées doivent être activées dans le fichier config.json. Par exemple, assurez-vous que deploySAP=true est activé si vous déployez le data mesh pour SAP.

Pour vous assurer que vous effectuez le déploiement avec les packages et les versions requis, vous pouvez exécuter l'utilitaire à partir de la même image que celle utilisée par le processus de déploiement Cortex avec les commandes suivantes :

  # Run container interactively
  docker container run -it gcr.io/kittycorn-public/deploy-kittycorn:v2.0

  # Clone the repo
  git clone https://github.com/GoogleCloudPlatform/cortex-data-foundation

  # Navigate into the repo
  cd cortex-data-foundation

Pour obtenir de l'aide sur les paramètres disponibles et leur utilisation, exécutez la commande suivante :

  python src/common/data_mesh/deploy_data_mesh.py -h

Voici un exemple d'appel pour SAP ECC :

  python src/common/data_mesh/deploy_data_mesh.py \
    --config-file config/config.json \
    --lake-directories \
        src/SAP/SAP_REPORTING/config/ecc/lakes \
    --tag-template-directories \
        src/SAP/SAP_REPORTING/config/ecc/tag_templates \
    --policy-directories \
        src/SAP/SAP_REPORTING/config/ecc/policy_taxonomies \
    --annotation-directories \
        src/SAP/SAP_REPORTING/config/ecc/annotations

Pour en savoir plus sur les emplacements des répertoires, consultez la section Répertoires du data mesh.

Remplacer

Par défaut, le déploiement de Data Mesh n'écrase aucune ressource ni annotation existantes. Toutefois, l'option --overwrite peut être activée lors du déploiement du Data Mesh seul pour modifier le déploiement de la manière suivante.

L'écrasement des ressources de métadonnées telles que les lacs, les modèles de tags de catalogue et les tags de règles supprime toutes les ressources existantes portant le même nom, mais ne modifie pas les ressources existantes portant un nom différent. Cela signifie que si une spécification de ressource est entièrement supprimée du fichier YAML, puis que le maillage de données est redéployé avec l'option d'écrasement activée, cette spécification de ressource ne sera pas supprimée, car il n'y aura pas de conflit de noms. Cela permet au déploiement Cortex Data Mesh de ne pas avoir d'impact sur les ressources existantes qui pourraient être utilisées.

Pour les ressources imbriquées telles que les lacs et les zones, le remplacement d'une ressource supprime tous ses enfants. Par exemple, si vous écrasez un lac, ses zones et ses références d'éléments existantes sont également supprimées. Pour les modèles de tag de catalogue et les tags de règles qui sont écrasés, les références d'annotation associées existantes sont également supprimées des composants. Écraser les tags de catalogue dans une annotation d'asset n'écrase que les instances existantes de tags de catalogue qui partagent le même modèle.

Les remplacements de descriptions d'éléments et de champs ne prennent effet que si une nouvelle description non vide et valide est fournie et qu'elle est en conflit avec la description existante.

En revanche, les LCA se comportent différemment. Le remplacement des LCA supprime tous les comptes principaux existants (à l'exception des propriétaires au niveau des composants). En effet, les comptes principaux qui sont omis des règles d'accès sont tout aussi importants que ceux auxquels l'accès est accordé.

Explorer le data mesh

Une fois le data mesh déployé, les utilisateurs peuvent rechercher et afficher les éléments de données avec Data Catalog. Cela inclut la possibilité de découvrir des composants en fonction des valeurs de tags de catalogue qui ont été appliquées. Si nécessaire, les utilisateurs peuvent également créer et appliquer manuellement des termes du glossaire du catalogue.

Vous pouvez afficher les règles d'accès déployées sur la page "Schéma BigQuery" pour voir les règles appliquées à un élément spécifique à chaque niveau.

Traçabilité des données

Les utilisateurs peuvent trouver utile d'activer et de visualiser la lignée entre les composants BigQuery. Vous pouvez également accéder à la lignée de manière programmatique via l'API. La traçabilité des données n'est compatible qu'avec la traçabilité au niveau des composants. Le lineage des données n'est pas lié au maillage de données Cortex. Toutefois, de nouvelles fonctionnalités utilisant le lineage pourront être introduites à l'avenir.

Pour toute demande concernant Cortex Data Mesh ou Cortex Framework, accédez à la section Assistance.