Comprendre les politiques relatives aux tables de clean room¶

Clean rooms fournit certaines politiques de données pour contrôler la façon dont les données peuvent être utilisées par les collaborateurs. Ces politiques s’ajoutent à toutes les politiques de la table Snowflake fixées sur les tables sous-jacentes liées à la clean room. Toute modification des politiques dans les tables sous-jacentes est propagée aux vues liées dans la clean room sans qu’il soit nécessaire d’appeler create_or_update_cleanroom_listing ou de relier à nouveau les tables sources.

Chaque collaborateur d’une clean room établit ses propres paramètres sur ses propres données.

Note

Lorsque vous liez des tables dans une clean room, les politiques des tables Snowflake sur les tables sources sont appliquées dans les tables liées dans la clean room, mais ces politiques ne sont pas nécessairement rapportées par l’API ou l’UI de la clean room. Par instance, une politique de jonction Snowflake continue d’être appliquée dans la clean room, mais cette politique de jonction n’est pas visible en appelant consumer.view_provider_join_policy ou consumer.view_join_policy. Par conséquent, vous devez soit supprimer les politiques des tables liées sous-jacentes, soit créer des politiques de clean room équivalentes (lorsqu’elles existent), soit communiquer clairement l’existence de ces politiques à vos collaborateurs afin que leurs requêtes n’échouent pas ou ne se comportent pas de manière inattendue (pourquoi ne puis-je pas effectuer une jointure sur cette colonne ?).

Les politiques Clean room peuvent être paramétrées à l’aide de l’API ou l’UI de la clean room.

Les politiques de confidentialité de Snowflake empêchent la création d’une vue à partir d’une table protégée, de sorte que vous ne pouvez pas créer de liens dans les tables qui ont des politiques de confidentialité.

Clean rooms expose les politiques suivantes :

Politique Clean room	Description	Politique équivalente de Snowflake
Politiques de jointure	Indiquez quelles colonnes peuvent faire l’objet d’une jointure.	Politiques de jointure
Politiques des colonnes	Précisez lesquelles de vos colonnes peuvent être projetées.	Politiques de projection
Politiques d’activation	Précisez lesquelles de vos colonnes peuvent être exportées de la clean room.	Aucune politique équivalente à celle de Snowflake.
Respecte les politiques d’agrégation de Snowflake	Exigence d’agrégation des lignes dans les requêtes et nombre minimum de lignes par groupe.	Aggregation policies

Politiques de jointure¶

Une politique de jointure en clean room spécifie quelles colonnes de vos tables peuvent être jointes par à n’importe quel modèle de clean room. Les politiques d’adhésion sont ensemble au niveau de la clean room.

Les colonnes de la politique de jonction ne peuvent pas être projetées (une colonne ne peut pas être à la fois dans une politique de jonction de clean room et dans une politique de colonne). Si vous souhaitez qu’une colonne de jointure puisse être projetée, vous devez paramétrer les politiques de jointure en dehors de la clean room et les politiques de projection dans la salle blanche (ou l’inverse).

Les colonnes de la politique de jonction peuvent également être des colonnes de la politique d’activation.

Les politiques de jointure Clean room ne sont pas les mêmes que les politiques de jointure Snowflake, qui spécifient les colonnes à joindre.

Si vous ne spécifiez pas de politique de jointure pour vos données, toutes les colonnes peuvent être jointes (et également projetées).

Mise en œuvre d’une politique de jonction¶

Les politiques de jointure Clean room ne sont appliquées à une colonne que si le modèle utilise le filtre join_policy ou join_and_column_policy. Vous pouvez inspecter un modèle pour voir où les politiques de jonction sont appliquées en voyant la définition du modèle et en confirmant la présence de ce filtre dans une syntaxe comme celle-ci :

{{ my_column | join_policy }}

Copy

Les politiques de jointure Snowflake sur les tables sous-jacentes sont appliquées, que le modèle ait ou non un filtre join_policy sur la colonne.

Le code suivant montre comment permettre la jonction de deux colonnes provenant de deux tables différentes. Cette politique concerne tous les utilisateurs et tous les modèles de cette clean room. Il existe des procédures équivalentes pour les fournisseurs et les consommateurs dans une clean room ; appelez la procédure qui correspond à votre rôle dans la clean room. Vous pouvez paramétrer la politique de jonction à tout moment après que vos données ont été liées à une clean room.

-- Set join policies on a clean room where you are a provider
CALL samooha_by_snowflake_local_db.provider.set_join_policy('my_provider_cleanroom',
  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL', 'MYDB.MYSCH.EXPOSURES:HASHED_EMAIL']);

-- Set join policies on a clean room where you are a consumer
CALL samooha_by_snowflake_local_db.consumer.set_join_policy('my_consumer_cleanroom',
  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL', 'MYDB.MYSCH.EXPOSURES:HASHED_EMAIL']);

Copy

set_join_policy remplace la politique de jonction précédente par la nouvelle politique de jonction.

Les procédures suivantes permettent de voir ou de gérer les politiques de jonction dans le code :

consumer.set_join_policy
consumer.view_provider_join_policy
consumer.view_join_policy
provider.view_join_policy
provider.set_join_policy

Politiques des colonnes¶

Les politiques relatives aux colonnes précisent lesquelles de vos colonnes peuvent être projetées dans les résultats d’analyse lorsqu’elles sont accédées par un modèle spécifique. Vous pouvez définir une politique de colonne à tout moment après avoir lié les données et ajouté des modèles à la clean room.

Une colonne ne peut pas figurer à la fois dans une politique de jointure et dans une politique de colonne. Une colonne peut faire partie à la fois d’une politique d’activation et d’une politique de colonne.

Si vous ne spécifiez pas de politique de colonne pour vos données, toutes vos colonnes peuvent être projetées.

Mise en œuvre d’une politique des colonnes¶

Les politiques relatives aux colonnes peuvent être paramétrées dans les UI de clean rooms si le modèle le permet.

Les politiques des colonnes Clean room ne sont appliquées à une colonne que si le modèle utilise le filtre column_policy ou join_and_column_policy. Vous pouvez inspecter un modèle pour voir où les politiques de colonne sont appliquées en voyant la définition du modèle et en confirmant la présence de ce filtre dans une syntaxe comme celle-ci :

{{ my_column | column_policy }}

Copy

Les politiques de projection de Snowflake sur les tables sous-jacentes sont appliquées, que le modèle ait ou non un filtre column_policy sur la colonne.

Le code suivant montre qu’il est possible de projeter trois colonnes uniquement à l’aide du modèle prod_overlap_analysis. Le nom du modèle est fourni dans le cadre de la syntaxe de désignation des colonnes lors de la spécification d’une politique de colonne. Cette politique concerne tous les utilisateurs de la clean room, mais uniquement ce modèle. Il existe des procédures équivalentes pour les fournisseurs et les consommateurs dans une clean room ; appelez la procédure qui correspond à votre rôle dans la clean room.

-- Set column policies on a clean room where you are a provider
call samooha_by_snowflake_local_db.provider.set_column_policy('my_provider_cleanroom',
  ['prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:AGE_BAND',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:DAYS_ACTIVE']);

-- Set column policies on a clean room where you are a consumer
call samooha_by_snowflake_local_db.consumer.set_column_policy('my_consumer_cleanroom',
  ['prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:AGE_BAND',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:DAYS_ACTIVE']);

Copy

Un nouvel appel à cette procédure supprime la politique de colonne précédente et la remplace par la nouvelle politique de colonne.

Les procédures suivantes permettent de voir ou de gérer les politiques de colonne dans le code :

consumer.set_column_policy
consumer.view_column_policy
consumer.view_provider_column_policy
provider.set_column_policy
provider.view_column_policy

Politiques d’activation¶

Les politiques d’activation précisent lesquelles de vos colonnes peuvent être activées par un modèle d’activation. Un modèle d’activation enregistre les résultats de la requête dans une table du compte Snowflake du fournisseur ou du consommateur, ou dans un connecteur d’activation tiers.

Une colonne peut faire partie d’une politique d’activation comme de toute autre politique.

Si vous ne spécifiez pas de politique d’activation pour vos données, aucune colonne de vos données ne peut être activée.

Mise en œuvre d’une politique d’activation¶

Les politiques d’activation peuvent être paramétrées dans les UI de clean rooms si le modèle autorise l’activation.

Les politiques d’activation ne sont appliquées à une colonne que si le modèle utilise le filtre activation_policy. Vous pouvez inspecter un modèle pour voir où les politiques d’activation sont appliquées en voyant la définition du modèle et en confirmant la présence de ce filtre dans une syntaxe comme celle-ci :

{{ my_column | activation_policy }}

Copy

Le code suivant montre que les colonnes HASHED_EMAIL et REGION_CODE peuvent être activées dans une clean room. Cette politique concerne tous les utilisateurs et tous les modèles d’activation de la clean room. Il existe des procédures équivalentes pour les fournisseurs et les consommateurs dans une clean room. Appelez la procédure qui correspond à votre rôle dans la clean room.

-- Set column policies on a clean room where you are a provider
call samooha_by_snowflake_local_db.provider.set_activation_policy('my_cleanroom', [
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL',
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:REGION_CODE' ]);

-- Set column policies on a clean room where you are a consumer
call samooha_by_snowflake_local_db.consumer.set_activation_policy('my_cleanroom', [
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE_NAME.DEMO.CUSTOMERS:HASHED_EMAIL',
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE_NAME.DEMO.CUSTOMERS:REGION_CODE' ]);

Copy

Un nouvel appel à cette procédure supprime la politique d’activation précédente et la remplace par la nouvelle politique d’activation.

Les procédures suivantes permettent de gérer les politiques d’activation dans le code :

consumer.set_activation_policy
provider.set_activation_policy

Politiques d’agrégation¶

Les politiques d’agrégation exigent que toutes les requêtes effectuées sur une table contiennent des agrégations (GROUP BY, COUNT, et autres fonctions) et spécifient également un nombre minimum de lignes par groupe de résultats, faute de quoi le groupe sera omis des résultats. Les politiques d’agrégation exigent que toutes les requêtes effectuées sur une table faisant l’objet d’une politique d’agrégation soient agrégées (GROUP BY, COUNT, et autres fonctions d’agrégation) et spécifient également un nombre minimum de lignes par groupe de résultats, faute de quoi le groupe sera omis des résultats.

Clean rooms ne dispose pas de sa propre implémentation des politiques d’agrégation ; pour appliquer des contraintes d’agrégation à vos données liées, vous devez soit appliquer une politique d’agrégation à la table source, soit implémenter des contraintes d’agrégation dans votre modèle.

Certains modèles fournis par Snowflake utilisent les paramètres threshold et threshold_value établis pour un utilisateur ou un modèle. Ces valeurs peuvent être modifiées dans les UI de clean rooms, ou en appelant provider.add_consumers ou provider/consumer.set_privacy. Si elles sont paramétrées pour un consommateur, vous pouvez accéder à ces valeurs dans votre modèle.