Offres de données¶

Une offre de données est un ensemble d’une ou plusieurs vues, appelées ensemble de données, partagée avec des gestionnaires d’analyses spécifiques dans le cadre d’une collaboration. Vous pouvez partager des données avec des gestionnaires d’analyses pour lesquels vous êtes défini comme fournisseur de données dans la Spécification de collaboration.

Une offre de données est une vue en direct des données source, et non un instantané des données au moment de l’enregistrement de l’offre de données. Toutes les politiques de Snowflake appliquées aux données sources sont actives dans l’offre de données.

Lorsque vous enregistrez une offre de données, Snowflake crée une vue pour chaque source de données répertoriée dans la spécification de l’offre de données. La vue ne comprend que les colonnes répertoriées dans la spécification de l’offre de données. Certaines colonnes, selon leur catégorie, sont sujettes au renommage à ce stade.

De plus, lorsque vous liez une offre de données dans une collaboration, Snowflake crée une copie de la vue enregistrée et limite l’accès à cette vue aux gestionnaires d’analyse spécifiés, conformément à la Spécification de collaboration.

Important

Si vous déplacez, renommez ou modifiez les autorisations d’accès aux tables sous-jacentes, l’offre de données deviendra inutilisable via les liens précédemment enregistrés.

Si vous utilisez Snowflake Standard Edition, vous ne pouvez pas partager des données via une salle blanche de données avec application de la politique. Par conséquent, vous n’êtes pas en mesure de partager des données avec d’autres parties ou de tirer parti des politiques de salle blanche de données spécifiées dans les offres, même pour les utilisateurs de votre propre compte. Toutefois, vous pouvez accéder aux offres de données d’autres collaborateurs, ou utiliser vos propres données comme offre de données locale sans politiques.

Exigences relatives à l’offre de données :

Vous devez avoir le REFERENCE_USAGE privilège avec GRANTOPTION sur toutes les données que vous souhaitez partager. Si cela n’est pas le cas, vous recevez une erreur de type « octroi d’utilisation de référence manquante » lorsque vous essayez de rejoindre la collaboration ou de lier les données.
```
GRANT REFERENCE_USAGE ON DATABASE my_database TO ROLE my_role WITH GRANT OPTION;
```
Vous devez disposer du rôle de collaboration du fournisseur de données dans une collaboration.
Actuellement, seul le rôle d’utilisateur qui a créé ou rejoint la collaboration peut lier ou dissocier des données dans une collaboration.

Poursuivez la lecture pour voir comment enregistrer et lier une offre de données à une collaboration :

Enregistrer une offre de données¶

Créez une spécification de l’offre de données pour vos données. Précisez les détails suivants concernant votre offre de données :
- L’objet source de chaque ensemble de données dans votre offre de données.
- Quelles colonnes inclure dans chaque ensemble de données.
- Le type (jointure ou autre) de chaque colonne, utilisé pour remplir les politiques de salle blanche. Dans certains cas, vous spécifierez également le format des colonnes individuelles.
- N’importe quelle politique de protection des données Snowflake à appliquer aux colonnes de votre offre de données.
- Comment les utilisateurs peuvent accéder aux données : par modèle uniquement, ou également par :doc:` requête SQL de forme libre </user-guide/cleanrooms/free-form-sql>`.
Enregistrez l’offre de données en appelant REGISTER_DATA_OFFERING, qui renvoie un ID d’offre de données.

Cette étape rend l’offre de données disponible pour être liée à toute collaboration par n’importe quel rôle de votre compte qui a un accès en lecture au registre. Vous pouvez utiliser le même ID d’offre de données pour partager une offre de données entre plusieurs collaborations.

Lier une offre de données¶

Le processus de liaison dépend de la création de la collaboration :

Si la collaboration n’a pas encore été créée, le fournisseur de données peut donner l’ID de l’ offre de données au propriétaire de la collaboration à inclure dans la spécification de collaboration. Lorsqu’une offre de données est incluse dans la spécification de la collaboration, l’ID de l’offre de données sera visible dans la spécification de la collaboration pour vérification par le fournisseur de données avant de rejoindre la collaboration.
Si la collaboration a déjà été créée, le fournisseur de données rejoint la collaboration et appelle LINK_DATA_OFFERING avec l’ID d’offre de données, le nom de la collaboration et les personnes avec lesquelles les données peuvent être partagées Il se peut qu’il y ait un léger délai entre le moment où une offre de données est associée et celui où elle devient disponible. Appelez VIEW_UPDATE_REQUESTS si vous voulez vous assurer que la demande d’association d’offre de données a abouti. Une fois l’association établie, l’offre de données sera visible et prête à être utilisée lors de l’appel de VIEW_DATA_OFFERINGS.

Lorsque vous liez des données, vous indiquez quels gestionnaires d’analyses peuvent accéder aux données.

Un fournisseur de données peut supprimer les offres de données d’une collaboration ou de collaborateurs spécifiques en appelant UNLINK_DATA_OFFERING.

Pour voir les offres de données enregistrées dans votre compte, appelez VIEW_REGISTERED_DATA_OFFERINGS.

Astuce

Les offres de données ne sont pas visibles dans une collaboration tant que l’utilisateur qui a enregistré l’offre de données ne rejoint pas la collaboration.

Voir Effectuer une analyse pour savoir comment exécuter une analyse.

Renommage de colonne source¶

Les noms des colonnes d’une offre de données peuvent être renommés avant d’être exposés au gestionnaire d’analyse. Le renommage dépend des valeurs category et column_type qui définissent la colonne dans la spécification de l’offre de données, comme décrit dans ce tableau :


Colonne `category`	Nom de la nouvelle colonne
`join_standard`	Valeur `column_type`
`timestamp`	`timestamp`
`join_custom`, `passthrough` ou `event_type`	Le nom original de la colonne est utilisé.

Par exemple, si la colonne de la table source est nommée user_email_address, la façon dont cette colonne est exposée à un gestionnaire d’analyse dépend de la manière dont elle est définie dans la spécification de l’offre de données :


Spécification de l’offre de données	Comment la colonne est-elle référencée
... schema_and_template_policies: user_email_address: category: join_standard column_type: hashed_email_sha256	`column_type` est utilisé pour les colonnes `join_standard` : SELECT HASHED_EMAIL_SHA256 FROM source_table[0];

Application de politiques de protection des données aux offres de données¶

Les données partagées dans une salle blanche sont protégées de plusieurs manières :

Les données enregistrées avec l’environnement de la salle blanche sont créées sous la forme d’une vue sécurisée qui omet toutes les colonnes non répertoriées dans la spécification de l’offre de données.
La vue sécurisée n’est partagée qu’avec les utilisateurs et les modèles spécifiques spécifiés par la spécification de collaboration.
Vous pouvez ajouter des politiques Snowflake à vos données pour gérer davantage la manière dont elles sont utilisées.
Des politiques de modèle de Data Clean Room sont également appliquées en fonction de la classification des colonnes de l’offre de données.

Il existe deux façons d’appliquer une politique de protection des données Snowflake, telle qu’une politique de jointure ou d’agrégation, à vos données partagées :

Appliquez la politique aux données sources. Toutes les politiques appliquées aux données sources sont appliquées dans les ensembles de données exposés dans une collaboration. Communiquez votre politique à vos collaborateurs.
Appliquez la politique sur l’offre de données lorsqu’elle est utilisée dans des requêtes de forme libre. Si vous autorisez les requêtes de forme libre sur vos offres de données, vous pouvez spécifier des politiques à appliquer à ces requêtes dans la spécification de l’offre de données. Ces politiques sont appliquées par-dessus toutes les politiques Snowflake existantes sur vos tables sources.

Appliquer la politique Snowflake à vos données sources¶

Toutes les politiques de Snowflake appliquées aux données sources s’appliquent également à la vue de l’offre des données dans la collaboration.

Si vous appliquez des politiques Snowflake à vos données sources, informez-en vos collaborateurs afin qu’ils n’exécutent pas, par inadvertance, une requête qui effectue une jointure sur une colonne non joignable ou qui ne respecte pas les exigences d’agrégation. Mentionnez les politiques de Snowflake dans le champ description de votre offre de données.

Important

Lors de l’enregistrement d’une offre de données contenant des politiques de données Snowflake, vous devez soit utiliser un rôle qui n’est pas soumis à ces politiques, soit suspendre temporairement la politique jusqu’à ce que les données soient enregistrées.

En effet, Snowflake Data Clean Rooms exécute une requête de validation sur la table source dans le cadre du processus d’enregistrement. Si la requête de test ne parvient pas à renvoyer des résultats significatifs, l’enregistrement échoue. Certaines politiques de données Snowflake peuvent entraîner l’échec du test. Par exemple, une table peut avoir une politique d’agrégation et la requête de validation ne renverra pas suffisamment de lignes pour satisfaire l’exigence de taille de groupe minimale imposée par la politique d’agrégation.

Appliquer la politique de Snowflake à l’offre de données (utilisation des requêtes à forme libre uniquement)¶

Vous pouvez appliquer des politiques Snowflake à vos données partagées lorsque vous y accédez via les requêtes à forme libre, sans les appliquer aux données sources. Ces politiques sont appliquées en plus des politiques Snowflake appliquées directement à la table source.

Pour ajouter des politiques SQL de forme libre à vos données :

Créez un type de politique pris en charge par Collaboration Data Clean Rooms.
Ajoutez les informations suivantes à la spécification de vos offres de données :
- Définissez allowed_analyses: template_and_freeform_sql.
- Ajoutez une section freeform_sql_policies à l’entrée de l’ensemble de données.
- Ajoutez les sections des types de politiques appropriés sous freeform_sql_policies, répertoriant les politiques Snowflake que vous avez créées, et les colonnes de collaboration auxquelles elles s’appliquent. Les types de politiques pris en charge sont les suivants :
  - aggregation_policy : Une seule politique d’agrégation avec des clés d’entité facultatives.
  - projection_policies : Un tableau de politiques de projection, chacune avec des liaisons de colonnes.
  - join_policy : Une politique de jointure unique avec des liaisons de colonnes facultatives.
  - masking_policies : Un tableau de politiques de masquage, chacune avec des liaisons de colonnes.
  - row_access_policy : Une seule politique d’accès aux lignes avec des liaisons de colonnes facultatives.
Le rôle qui enregistre l’offre de données doit avoir le privilège USAGE sur les politiques.

Les collaborateurs voient les types de politiques appliqués à vos données lorsqu’ils appellent COLLABORATION.VIEW_DATA_OFFERINGS.

Vous pouvez réutiliser une politique sur plusieurs colonnes sur plusieurs tables.

Exemple :

CREATE OR REPLACE AGGREGATION POLICY my_db.public.my_agg_policy AS ()
  RETURNS AGGREGATION_CONSTRAINT ->
    AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5);

# Tell data clean rooms to set your aggregation policy on the hashed_email column of
# the data offering
api_version: 2.0.0
spec_type: data_offering
version: 1
name: my_favorite_dataset
datasets:
  - alias: test_freeform_restricted_agg
    data_object_fqn: samooha_provider_sample_database.audience_overlap.customers
    allowed_analyses: template_and_freeform_sql
    object_class: custom
    freeform_sql_policies:
      aggregation_policy:
        name: my_db.public.my_agg_policy
        entity_keys:
          - hashed_email
...

Politiques des modèles de Snowflake Data Clean Room¶

Les Snowflake Data Clean Rooms prennent également en charge leur propre système de politiques en plus du système de politiques de Snowflake. Chaque fournisseur de données d’une collaboration peut définir les politiques suivantes sur son offre de données :

Une politique de jointure, qui spécifie quelles colonnes peuvent être jointes.
Une politique de colonnes, qui spécifie quelles colonnes peuvent être projetées.
Une politique d’activation, qui spécifie quelles colonnes peuvent être activées.

Un fournisseur de données peut définir ces politiques dans sa spécification d’offre de données :

Si la category de la colonne est join_standard ou``join_custom``, la colonne est ajoutée à la politique de jointure de la salle blanche.
Si la category de la colonne est définie sur toute autre valeur, la colonne est ajoutée à la politique de colonnes de la salle blanche.
Si la valeur activation_allowed de la colonne est définie sur TRUE, elle est également ajoutée à la politique d’activation de la salle blanche.

Les politiques sont appliquées lorsqu’un modèle dispose du filtre de vérification des politiques approprié. Ces filtres sont les suivants :join_policy, column_policy, activation_policy, join_and_column_policy. Au moment de l’exécution du modèle, ces filtres valident que les colonnes référencées sont autorisées par la politique correspondante définie dans la spécification de l’offre de données. Un modèle échoue si un filtre est appliqué à une colonne qui ne fait pas partie de la politique spécifiée.

Par exemple, col1 et``col2`` doivent faire partie des politiques de jointure du fournisseur de données (category: join_standard ou``category: join_custom``), ou l’extrait de modèle suivant générera une erreur :

SELECT *
FROM T1
JOIN T2
ON {{ t1_col | sqlsafe | join_policy }} = {{ t2_col | sqlsafe | join_policy }}

Organisation des offres de données avec des chemins de dénomination¶

Vous pouvez utiliser des chemins de dénomination pour regrouper conceptuellement les offres de données. Cela est particulièrement efficace car chaque offre de données représente une ou plusieurs tables ou vues. Les tables individuelles sont accessibles en utilisant la syntaxe collaborator alias.data offering ID.dataset alias, où l’ID d’offre de données est une combinaison des valeurs de nom et de version fournies par l’utilisateur, et l’alias est une table unique dans l’offre.

Considérez le nom, la version et l’alias comme un système de portée lors de l’enregistrement de vos offres de données, ce qui vous permet d’organiser vos données par offre et alias. Par exemple, vous pouvez enregistrer l’offre de données suivante concernant les données de vente, où chaque table est spécifique à un État US :

api_version: 2.0.0
spec_type: data_offering
version: v0
name: examplecorp_sales_by_state
datasets:
 - alias: AL
   data_object_fqn: mydb.mysch.al_data
 - alias: NY
   data_object_fqn: mydb.mysch.ny_data
 - alias: CA
   data_object_fqn: mydb.mysch.ca_data

L’exécuteur d’analyse fait référence à ces tables comme suit :user_alias.offering_id.AL,``user_alias.offering_id.NY``, et``user_alias.offering_id.CA``.