(Obsolète) Guide de l'utilisateur de Data Mesh

Avertissement : La fonctionnalité de maillage de données de Google Cloud Cortex Framework est désormais obsolète et désactivée. Ce changement est motivé par l'évolution des services de gestion des données de Google Cloud. La solution de maillage de données a été créée à l'aide de Data Catalog pour la gestion des métadonnées, qui est désormais remplacé par le service plus avancé Knowledge Catalog. Knowledge Catalog fournit une API unifiée, des fonctionnalités de métadonnées améliorées et de nouvelles fonctionnalités pour une expérience de gouvernance des données plus complète.

Le maillage de données pour Cortex Framework étend la base de données pour permettre la gouvernance des données, la découvrabilité et le contrôle des accès via les métadonnées BigQuery et Knowledge Catalog. Pour ce faire, un ensemble de base de ressources de métadonnées et d'annotations d'éléments BigQuery est fourni. Il peut être personnalisé et éventuellement déployé 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 Cortex Framework Data Foundation. Consultez Concepts de maillage de données avant de poursuivre ce guide.

Les étapes décrites sur cette page sont spécifiquement conçues pour configurer Data Mesh pour Cortex Framework. Recherchez les fichiers de configuration du maillage de données dans les dossiers spécifiques à chaque charge de travail dans la section des répertoires du maillage de données.

Avertissement : Ce guide sur le maillage de données est susceptible d'être modifié au fil du temps. Contactez l'équipe Cortex pour tout commentaire ou problème.

Figure 1. Architecture de maillage de données pour Cortex Framework

Conception

Le maillage de données de Cortex est conçu de la même manière que la base de données globale et 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 des ressources : avant le déploiement, les utilisateurs peuvent adapter les spécifications des ressources à leurs cas d'utilisation et exigences spécifiques.
3. Déploiement et mises à jour du maillage de données : les utilisateurs peuvent activer le maillage de données dans le fichier de configuration Cortex. Il est déployé après les éléments de données lors du déploiement de Cortex. De plus, les utilisateurs peuvent déployer le maillage de données de manière indépendante pour les mises à jour ultérieures.

Figure 2. Conception de maillage de données pour Cortex Framework.

Répertoires de maillage de données

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

Charge de travail	Source de données	Chemin d'accès au répertoire
Opérations	SAP ECC	src/SAP/SAP_REPORTING/config/ecc
	SAP S/4 HANA	src/SAP/SAP_REPORTING/config/s4
	Salesforce Sales Cloud (SFDC)	src/SFDC/config
	Oracle EBS	src/OracleEBS/config
Marketing	CM360	src/marketing/src/CM360/config
	Google Ads	src/marketing/src/GoogleAds/config
	Meta	src/marketing/src/Meta/config
	Salesforce Marketing Cloud (SFMC)	src/marketing/src/SFMC/config
	TikTok	src/marketing/src/TikTok/config
	YouTube (avec DV360)	src/marketing/src/DV360/config
	Google Analytics 4	src/marketing/src/GA4/config

Remarque : Data Mesh n'est pas compatible avec les données LiveRamp ou Dun & Bradstreet (ESG).

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 une liste de toutes les ressources. 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 si nécessaire.

Les annotations d'éléments sont définies au niveau de l'élément 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 de Data Mesh vous permet d'implémenter des fonctionnalités au-delà des descriptions. Si vous devez modifier les valeurs par défaut du maillage de données dans config.json pour implémenter des fonctionnalités au-delà des descriptions, assurez-vous que les API nécessaires et les autorisations de confirmation sont définies comme indiqué dans le tableau suivant. Lorsque vous déployez 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, partout où ces fonctionnalités sont utilisées.

Fonctionnalité	Rôles d'autorisation	Documentation
Accès aux éléments et aux lignes BigQuery	Propriétaire de données BigQuery	Pour en savoir plus, consultez Rôles requis pour les rôles d'élément et Autorisations requises pour les rôles de ligne.
Accès aux colonnes BigQuery	Administrateur de tags avec stratégie	Pour en savoir plus, consultez les documentations Rôles utilisés avec le contrôle des accès au niveau des colonnes et Limiter l'accès à l'aide du contrôle des accès au niveau des colonnes.
Tags de catalogue	Propriétaire de modèles de tag Data Catalog	Pour en savoir plus, consultez les pages Taguer une table BigQuery à l'aide de Data Catalog et IAM Data Catalog.
Lacs Knowledge Catalog	Éditeur Dataplex	Pour en savoir plus, consultez la documentation Créer un lac.

Remarque : Cortex Data Mesh ne nécessite pas l'intégration des API Managed Service pour Apache Spark et Managed Service pour Apache Spark Metastore.

Comprendre les spécifications des ressources de base

L'interface principale pour configurer le maillage de données pour Cortex est constituée des spécifications de ressources de base, qui sont un ensemble de fichiers YAML fournis prêts à l'emploi 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 elles 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 à divers éléments de données. Par exemple, les modèles de tags Data Catalog qui définissent la manière dont les assets 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 une table spécifique au domaine "Ventes".

Les sections suivantes vous guident à travers des exemples de base de chaque type de spécification et vous expliquent comment les personnaliser. Les spécifications de base sont taguées avec ## CORTEX-CUSTOMER, où elles 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 éléments de données. La plupart des spécifications incluent un champ display_name soumis aux critères suivants :

• Contient uniquement 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.
• Longueur maximale de 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. Un pour les zones brutes et CDC, et un autre pour les rapports.

Lacs Knowledge Catalog

Les lacs, les zones et les assets Knowledge 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, tous deux liés à l'emplacement Cortex (config.json > location). L'emplacement Cortex définit l'emplacement de stockage des ensembles de données BigQuery et peut être une région unique ou multirégionale. La zone location_type doit être définie sur SINGLE_REGION | MULTI_REGION pour correspondre à cette région. Toutefois, les régions de lac 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. C'est également le cas pour la zone et l'élément display_name. Les ID de zone doivent être uniques pour tous les lacs du projet.
  • Les spécifications de lac doivent être associées à une seule région.
  • L'ID asset_name doit correspondre à l'ID de l'ensemble de données BigQuery, mais le libellé display_name peut être plus convivial.
• Limites
  • Knowledge Catalog ne permet d'enregistrer que des ensembles de données BigQuery en tant qu'éléments Knowledge Catalog, et non des tables individuelles.
  • Un asset ne peut être enregistré que dans une seule zone.
  • Knowledge Catalog n'est disponible que dans certains emplacements. Pour en savoir plus, consultez Emplacements de Knowledge 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 de Knowledge Catalog. Ils définissent les champs spécifiques que vous pouvez utiliser pour étiqueter 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 compatibles, consultez Types de champs Data Catalog.

Cortex Data Mesh crée tous les modèles de tags en lecture publique. Il introduit également un concept level supplémentaire dans les spécifications des modèles de tag, qui définit si un tag doit être appliqué à 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 pourraient 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 d'éléments".

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

Cortex Framework permet d'activer le contrôle des accès au niveau de l'élément ou de la colonne sur tous les artefacts associés à un modèle de tag de catalogue. Par exemple, si les utilisateurs souhaitent accorder l'accès aux éléments en fonction du secteur d'activité, ils peuvent créer des asset_policies pour le modèle de tag de catalogue line_of_business avec différents comptes principaux spécifiés pour chaque domaine d'activité. Chaque règle accepte filters, qui ne peut être utilisé que pour faire correspondre des 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 d'égalité et aucun autre opérateur. Si plusieurs filtres sont listés, les résultats doivent satisfaire tous les filtres (par exemple, filter_a AND filter_b). L'ensemble final de règles d'éléments est l'union de celles définies directement dans les annotations et de celles des règles de modèle.

Le contrôle des accès au niveau des colonnes avec des tags de catalogue se comporte 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 sur l'annotation de la colonne, il est prioritaire.
2. Règle de modèle de tag correspondante : sinon, l'accès est déterminé par la première règle correspondante définie sur un champ du modèle de tag Catalog 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 permet de s'assurer que les LCA 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 du catalogue

Le glossaire est un outil qui peut être utilisé pour fournir un dictionnaire des termes utilisés par des colonnes spécifiques dans des éléments de données qui ne sont pas forcément compris par tous. Les utilisateurs peuvent ajouter des termes manuellement dans la console, mais ils ne sont pas acceptés via les spécifications de ressources.

Taxonomies et tags avec stratégie

Les taxonomies et les tags avec stratégie permettent de contrôler l'accès au niveau des colonnes aux éléments de données sensibles de manière standardisée. Par exemple, il peut exister une taxonomie pour les tags contrôlant les informations permettant d'identifier personnellement l'utilisateur sur un secteur d'activité particulier, où seuls certains groupes peuvent lire les données masquées, les données non masquées ou n'ont aucun accès en lecture.

Pour en savoir plus sur les taxonomies et les tags avec stratégie, consultez la documentation Présentation du 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 avec stratégie

Cortex Framework fournit des exemples de tags avec stratégie 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 de maillage de données.

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. Les annotations incluent :

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

Remarque : Si vous modifiez un fichier d'annotation, tenez compte du fait que la console n'affiche les nouvelles lignes dans les descriptions que sous forme d'espace blanc.

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

• SAP ECC (brut, CDC et reporting)
• SAP S4 HANA (brut, CDC et reporting)
• SFDC (rapports uniquement)
• Oracle EBS (rapports uniquement)
• CM360 (rapports 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, où 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 de la spécification dans data_mesh_types.CatalogTag.

Spécifier les lecteurs et les comptes principaux de la règle 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 (les 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 le membre de la liaison de stratégie IAM.

Accès au niveau des composants

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

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

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

Contrairement au comportement de la plupart des ressources et des annotations, l'option d'écrasement ne supprime pas les comptes principaux existants dotés du rôle OWNERS. Lorsque vous ajoutez de nouveaux propriétaires avec l'option d'écrasement activée, ils sont simplement ajoutés aux propriétaires existants. Cette mesure de protection permet d'é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 disposant du rôle READER ou WRITER.

Consultez l'exemple ci-dessous.

Consultez la définition de la spécification 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 colonne. Lorsque vous spécifiez la règle d'accès aux lignes, la chaîne de filtre fournie est insérée dans une clause CREATE DDL statement. Si l'option overwrite est activée, elle supprime toutes les règles d'accès aux lignes existantes avant d'en appliquer de nouvelles.

Tenez compte des points suivants concernant l'accès au niveau des lignes :

• L'ajout de règles d'accès aux lignes signifie que les utilisateurs non spécifiés dans ces règles ne pourront pas voir les lignes.
• Les règles d'accès au niveau des lignes ne fonctionnent qu'avec les tables, pas avec les vues.
• Évitez d'utiliser des colonnes partitionnées dans les filtres de vos règles d'accès aux lignes. Pour en savoir plus sur le type d'élément et les colonnes partitionnées, consultez le fichier YAML des paramètres de reporting associé.

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 de la spécification dans data_mesh_types.BqRowPolicy.

Accès au niveau de la colonne

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 de la spécification dans data_mesh_types.PolicyTagId.

Déployer le maillage de données

Le maillage de données 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 maillage de données ne supprime ni n'écrase les ressources ou annotations existantes afin d'éviter toute perte involontaire. Toutefois, il est également possible d'écraser les ressources existantes lorsqu'elles sont déployées seules.

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.

Remarque : Nous vous recommandons vivement d'effectuer le contrôle des accès uniquement via ces spécifications de ressources si deployACLs est activé. Cela évite d'ajouter ou de supprimer des accès par inadvertance.

Option	Remarques
deployDescriptions	Il s'agit de la seule option activée par défaut. Elle déploie les annotations BigQuery avec les descriptions des éléments et des colonnes. Il ne nécessite pas l'activation d'API ou d'autorisations supplémentaires.
deployLakes	Déploie des lacs et des zones.
deployCatalog	Déploie les ressources de modèle de catalogue et leurs tags associés dans les annotations d'éléments.
deployACLs	Déploie des ressources de taxonomie de règles et des règles de contrôle des accès au niveau des éléments, des lignes et des colonnes via des annotations d'éléments. Les journaux contiennent des messages indiquant comment les règles d'accès ont changé.

Déployer avec la base de données

Par défaut, config.json > deployDataMesh permet de déployer les descriptions des assets de maillage de données à la fin de chaque étape de compilation de la charge de travail. Cette configuration par défaut ne nécessite l'activation d'aucune API ni d'aucun rôle supplémentaires. Vous pouvez déployer des fonctionnalités supplémentaires du maillage de donné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 des 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é pendant les processus de compilation pour déployer le maillage de données 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 les spécifications à déployer doivent être activées dans le fichier config.json. Par exemple, assurez-vous que deploySAP=true si vous déployez le maillage de données 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 à l'aide des 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 l'emplacement des répertoires, consultez la section Répertoires Data Mesh.

Écraser

Avertissement : Lisez attentivement cette section avant d'utiliser l'option d'écrasement.

Par défaut, le déploiement du maillage de données n'écrase pas les ressources ni les annotations existantes. Toutefois, l'option --overwrite peut être activée lors du déploiement du maillage de données seul pour modifier le déploiement de l'une des manières suivantes.

L'écrasement des ressources de métadonnées telles que les lacs, les modèles de tags de catalogue et les tags avec stratégie supprime toutes les ressources existantes portant le même nom, mais ne modifie pas les ressources existantes portant des noms différents. 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 d'éviter que le déploiement de Cortex Data Mesh n'affecte les ressources existantes qui pourraient être utilisées.

Pour les ressources imbriquées telles que les lacs et les zones, l'écrasement d'une ressource supprime tous ses enfants. Par exemple, l'écrasement d'un lac supprime également ses zones et références d'éléments existantes. Pour les modèles de tags de catalogue et les tags avec stratégie qui sont écrasés, les références d'annotation associées existantes sont également supprimées des éléments. L'écrasement des tags de catalogue sur une annotation d'élément n'écrase que les instances existantes de tags de catalogue qui partagent le même modèle.

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

En revanche, les LCA se comportent différemment. L'écrasement des LCA supprime tous les comptes principaux existants (à l'exception des propriétaires au niveau de l'élément). En effet, les comptes principaux exclus des stratégies d'accès sont tout aussi importants que ceux qui y sont autorisés.

Explorer le maillage de données

Après avoir déployé le maillage de données, les utilisateurs peuvent rechercher et afficher les éléments de données avec Data Catalog. Cela inclut la possibilité de découvrir des éléments en fonction des valeurs de tag de catalogue qui ont été appliquées. Les utilisateurs peuvent également créer et appliquer manuellement des termes du glossaire du catalogue si nécessaire.

Les règles d'accès déployées peuvent être consultées sur la page "Schéma BigQuery" pour voir les règles appliquées à un élément particulier à chaque niveau.

Traçabilité des données

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

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