Guide de l'utilisateur de Data Mesh

Le framework Data Mesh for Cortex étend la base de données pour permettre la gouvernance, la visibilité et le contrôle des accès des données via les métadonnées BigQuery et Dataplex. Pour ce faire, un ensemble de ressources de métadonnées et d'annotations d'éléments BigQuery de base est fourni. Il peut être personnalisé et déployé en option avec la base de données. Ces spécifications de base fournissent une configuration personnalisée qui constitue la base de métadonnées pour compléter la base de données du framework Cortex. Consultez les concepts de Data Mesh avant de poursuivre 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 du Data Mesh dans les dossiers spécifiques à chaque charge de travail dans la section Répertoires du Data Mesh.

Architecture de maillage de données pour Cortex Framework

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

Conception

Le Data Mesh de Cortex est conçu de manière similaire à la fondation 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 de base des ressources: à chaque version, Cortex met à jour les spécifications de base des ressources, fournissant une base de métadonnées standardisée pour le Data Mesh.
  2. Personnalisation des spécifications des ressources: avant le déploiement, les utilisateurs peuvent adapter les spécifications des ressources en fonction de leurs cas d'utilisation et de leurs exigences spécifiques.
  3. Déploiement et mises à jour du Data Mesh:les utilisateurs peuvent activer le Data Mesh dans le fichier de configuration de Cortex. Il est déployé après les composants de données lors du déploiement de Cortex. De plus, les utilisateurs ont la possibilité de déployer le Data Mesh indépendamment pour d'autres mises à jour.

Conception de maillage de données pour Cortex Framework

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

Répertoires du maillage de données

Vous trouverez les fichiers de configuration de base du Data Mesh pour chaque charge de travail et chaque 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érationnel 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

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. 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 des API et vérifier les autorisations

Modifier les 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 de Data Mesh dans config.json pour implémenter des fonctionnalités au-delà des descriptions, assurez-vous que les API et les autorisations de confirmation nécessaires sont définies comme indiqué dans le tableau suivant. Lorsque vous déployez Data Mesh avec la fondation de données, accordez des autorisations à l'utilisateur qui effectue le déploiement ou au compte Cloud Build. Si le déploiement implique différents projets source et cible, assurez-vous que ces API et autorisations sont activées dans les deux projets, où que ces fonctionnalités soient 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 la section Rôles requis pour les rôles d'asset 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 pages Rôles utilisés avec le contrôle des accès au niveau des colonnes et Limiter l'accès avec le contrôle des accès au niveau des colonnes.
Balises 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 Dataplex Éditeur Dataplex Pour en savoir plus, consultez la documentation Créer un lac.

Comprendre les spécifications de base des ressources

L'interface principale pour configurer le Data Mesh pour Cortex est les 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 sont destinées à être personnalisées davantage pour répondre aux besoins des utilisateurs. Ces spécifications se répartissent en deux catégories:

  • Ressources de métadonnées pouvant être appliquées à différents composants 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'entreprise.
  • Annotations qui spécifient comment les ressources de métadonnées sont appliquées à un élément de données spécifique. Par exemple, une balise de catalogue qui associe un tableau spécifique au domaine "Sales".

Les sections suivantes vous présentent 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, 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écifications 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 composants 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 ( ) ;
  • ne peut pas commencer ni se terminer par des espaces ;
  • La longueur maximale est de 200 caractères.

Dans certains cas, 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 différents projets source et cibles, une spécification doit être définie pour chaque projet. Par exemple, Cortex Salesforce (SFDC) contient deux spécifications de lac. L'une pour les zones brutes et CDC, et l'autre pour les rapports.

Lacs Dataplex

Les lacs, les zones et les éléments Dataplex permettent d'organiser les données d'un point de vue technique. Les lacs ont un region et les zones un location_type, qui sont tous deux liés à l'emplacement Cortex (config.json > location). L'emplacement Cortex définit l'emplacement où les ensembles de données BigQuery sont stockés 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 à cela. Toutefois, les régions de lac doivent toujours être une seule région. Si l'emplacement Cortex et la zone location_type sont multirégionaux, sélectionnez une seule région de ce groupe pour la région du lac.

  • Conditions requises
    • Le display_name du lac est utilisé comme lake_id et doit respecter les exigences officielles. Il en va de même pour les zones et les éléments 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 n'accepte que l'enregistrement d'ensembles de données BigQuery plutôt que de tables individuelles en tant qu'éléments Dataplex.
    • Un élément ne peut être enregistré que dans une seule zone.
    • Dataplex n'est disponible que dans certains emplacements. Pour en savoir plus, consultez la section Emplacements de Dataplex.

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 permettent d'ajouter du contexte aux tables BigQuery ou à des colonnes individuelles. Ils vous aident à catégoriser et à comprendre vos données à la fois d'un point de vue technique et commercial, de manière intégrée aux outils de recherche Dataplex. 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, texte, nombre, 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 balises en tant que lisibles publiquement. Il introduit également un concept level supplémentaire dans les spécifications du modèle de balise, 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 cette règle ne soit pas strictement appliquée pour le moment, de futures vérifications de validation pourraient s'assurer que les balises sont appliquées au niveau approprié lors du déploiement.

Consultez l'exemple suivant.

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 décrits ci-dessous dans les annotations d'éléments.

Contrôle des accès au niveau des composants et des colonnes avec des modèles de balises

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 balise de catalogue. Par exemple, si les utilisateurs souhaitent accorder l'accès aux composants en fonction de leur secteur d'activité, ils peuvent créer des asset_policies pour le modèle de balise de catalogue line_of_business avec des principaux différents spécifiés pour chaque domaine d'entreprise. Chaque règle accepte filters, qui peut être utilisé pour ne faire correspondre que des balises avec des valeurs spécifiques. Dans ce cas, nous pouvons faire correspondre les valeurs domain. Notez que ces filters n'acceptent que les correspondances 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 des règles d'éléments correspond à 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 manière similaire 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 directe:si un tag avec stratégie est défini directement sur l'annotation de la colonne, il a la priorité.
  2. Règle de correspondance du modèle de tag: sinon, l'accès est déterminé par la première règle de correspondance définie sur un champ du 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 balises 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 du catalogue

Le glossaire est un outil qui peut être utilisé pour fournir un dictionnaire de termes utilisés par des colonnes spécifiques dans des composants de données qui ne sont pas forcément compris par tous. Les utilisateurs peuvent ajouter des termes manuellement dans la console, mais cette fonctionnalité n'est pas prise en charge par les spécifications des ressources.

Taxonomies et tags de stratégie

Les taxonomies et les tags de stratégie permettent de contrôler l'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 balises qui contrôlent les données à caractère personnel dans un secteur d'activité particulier, où seuls certains groupes peuvent lire les données masquées, les données non masquées ou ne pas avoir du tout accès en lecture.

Pour en savoir plus sur les taxonomies et les tags des stratégies, consultez la documentation Présentation du masquage des données de colonne. Les sections suivantes sont particulièrement pertinentes:

Cortex Framework fournit des exemples de tags de stratégie pour montrer comment ils sont spécifiés et les 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 du Data Mesh.

Consultez l'exemple suivant.

Les taxonomies de stratégie sont définies dans des fichiers YAML qui spécifient data_mesh_types.PolicyTaxonomies.

Annotations d'éléments

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

  • Descriptions des composants
  • Descriptions de champs
  • Balises 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 (brut, CDC et création de rapports)
  • SAP S4 HANA (brut, CDC et reporting)
  • SFDC (rapports uniquement)
  • Oracle EBS (reporting uniquement)
  • CM360 (rapports uniquement)
  • Google Ads (rapports uniquement)
  • Méta (rapports uniquement)
  • SFMC (rapports uniquement)
  • TikTok (rapports uniquement)
  • YouTube (avec DV360) (rapports uniquement)
  • Google Analytics 4 (rapports uniquement)

Consultez l'exemple suivant.

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

Balises de catalogue

Les balises 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 respecter l'un des formats suivants:

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

Consultez l'exemple suivant.

Consultez la définition de la spécification dans data_mesh_types.CatalogTag.

Spécifier des lecteurs et des principaux de stratégie d'accès

Contrôlez l'accès à vos données BigQuery dans Cortex Framework à l'aide de stratégies d'accès. Ces stratégies définissent les utilisateurs (principaux) autorisés à 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 à l'ensemble des composants BigQuery 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 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'indicateur d'écrasement ne supprime pas les principaux existants avec le rôle OWNERS. Lorsque vous ajoutez des propriétaires avec l'écrasement activé, ils ne sont ajoutés qu'aux propriétaires existants. Il s'agit d'une mesure de protection pour éviter toute perte d'accès involontaire. Pour supprimer des propriétaires d'éléments, utilisez la console. L'écrasement supprime les principaux existants avec le rôle READER ou WRITER.

Consultez l'exemple suivant.

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 stratégie 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 d'en appliquer de nouvelles.

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

  • Si vous ajoutez des stratégies d'accès aux lignes, les utilisateurs qui ne sont pas spécifiés dans ces stratégies n'auront pas accès aux lignes.
  • Les règles de ligne ne fonctionnent qu'avec les tables, et non avec les vues.
  • Évitez d'utiliser des colonnes partitionnées dans vos filtres de règles d'accès aux lignes. Consultez le fichier YAML des paramètres de création de rapports associés pour en savoir plus sur le type d'asset 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 suivant.

Consultez la définition de la spécification dans data_mesh_types.BqRowPolicy.

Accès au niveau des colonnes

Pour activer l'accès au niveau des colonnes, annotez des 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 suivant.

Consultez la définition de la spécification 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 fondation de données ou seul. 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 ou annotation existante pour éviter toute perte accidentelle. 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 et des contraintes de dépenses de l'utilisateur dans config.json > DataMesh.

Option Remarques
deployDescriptions Il s'agit de la seule option activée par défaut. Elle déploie des annotations BigQuery avec des descriptions d'éléments et de colonnes. Aucune API ni autorisation supplémentaire n'est requise.
deployLakes Déploie des lacs et des zones.
deployCatalog Déploie les ressources du modèle de catalogue et les tags associés dans les annotations des é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 composants, des lignes et des colonnes via des annotations de composants. Les journaux contiennent des messages indiquant comment les règles d'accès ont changé.

Déployer avec Data Foundation

Par défaut, config.json > deployDataMesh permet de déployer les descriptions des composants Data Mesh à la fin de chaque étape de compilation de la charge de travail. Cette configuration par défaut ne nécessite pas d'activer d'API ni de rôles supplémentaires. Vous pouvez déployer d'autres fonctionnalités du Data Mesh 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éployer seul

Pour déployer uniquement le maillage de données, 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 réseau 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 des 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 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 utilisée par le processus de déploiement de 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 Data Mesh.

Remplacer

Par défaut, le déploiement de Data Mesh n'écrasera aucune ressource ni annotation existante. Toutefois, l'option --overwrite peut être activée lors du déploiement du Data Mesh seul pour modifier le déploiement de différentes manières.

L'écrasement des ressources de métadonnées telles que les lacs, les modèles de tags de catalogue et les tags de 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 réseau de données est redéployé avec l'écrasement activé, cette spécification de ressource ne sera pas supprimée, car il n'y aura pas de conflit de nom. Cela permet de s'assurer que le déploiement du Cortex Data Mesh n'a pas d'impact sur 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 de règles écrasés, les références d'annotation associées existantes sont également supprimées des éléments. L'écrasement des balises de catalogue sur une annotation d'élément n'écrase que les instances existantes de balises de catalogue qui partagent le même modèle.

Les remplacements de description des éléments et des champs 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 ACL se comportent différemment. L'écrasement des LCA supprime tous les principaux existants (à l'exception des propriétaires au niveau des composants). En effet, les comptes principaux exclus des stratégies d'accès sont tout aussi importants que ceux auxquels l'accès est accordé.

Explorer le Data Mesh

Après avoir déployé le Data Mesh, 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 balise de catalogue appliquées. Si nécessaire, les utilisateurs peuvent également créer et appliquer manuellement des termes du glossaire du catalogue.

Vous pouvez consulter 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 particulier à 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 automatisée via l'API. La traçabilité des données n'est compatible qu'avec la traçabilité au niveau des composants. La généalogie des données n'est pas étroitement liée au Data Mesh Cortex. Toutefois, de nouvelles fonctionnalités utilisant la généalogie des données pourraient être introduites à l'avenir.

Pour toute demande concernant Cortex Data Mesh ou Cortex Framework, consultez la section Assistance.