Snowflake Data Clean Rooms : salles blanches multi-fournisseurs¶

Cette rubrique fournit un exemple d’exécution d’une analyse sur un cluster de salles blanches provenant de plusieurs fournisseurs. Il démontre comment une requête peut accéder à des données dans plusieurs salles blanches tout en maintenant les garanties de sécurité de chaque salle blanche. Il montre également comment le consommateur peut définir le modèle utilisé pour exécuter l’analyse, ce qui est un cas d’utilisation courant pour les salles blanches multi-fournisseurs.

Dans le cadre d’une analyse multi-fournisseurs, les données sont utilisées à partir de chaque salle blanche de manière totalement sécurisée. Snowflake Data Clean Rooms garantit la conformité avec la politique de sécurité de chaque salle blanche, tout en attestant que toutes les opérations SQL effectuées sur les données correspondent exactement aux attentes de chaque participant à la salle blanche.

Dans de nombreux cas, le consommateur exécutant une analyse multi-fournisseurs souhaite pouvoir définir le modèle pour l’analyse plutôt que d’utiliser un modèle défini par les fournisseurs. Cela permet aux consommateurs de contrôler la manière dont ils obtiennent des informations lors de l’analyse des données provenant de plusieurs parties. Pour plus d’informations sur les modèles définis par le consommateur, voir Utilisation de l’API du développeur pour ajouter des modèles définis par le consommateur.

Note

Les analyses en salle blanche multi-fournisseurs ne sont pas autorisées dans les salles blanches qui ont été partagées entre plusieurs régions.

L’exemple d’analyse multi-fournisseurs comprend les étapes suivantes :

Fournisseur :

a. Créez deux salles blanches, ce qui simule deux fournisseurs différents.

b. Partagez les salles blanches avec le même consommateur.
Consommateur :

a. Installez les deux salles blanches fournisseurs.

b. Envoyez des requêtes pour ajouter un modèle défini par le consommateur aux salles blanches.
Fournisseur :

a. Approuvez les requêtes du consommateur pour ajouter un modèle défini par le consommateur.

b. Définissez les politiques de colonne pour le modèle défini par le consommateur.
Consommateur :

a. Approuvez les requêtes d’analyse multi-fournisseurs.
Fournisseur :

a. Permettez aux salles blanches de procéder à des analyses multi-fournisseurs.

b. Approuvez les requêtes d’analyse multi-fournisseurs émanant du consommateur.
Consommateur

a. Exécutez l’analyse sur l’ensemble du cluster de la salle blanche.

Conditions préalables¶

Vous avez besoin de deux comptes Snowflake distincts pour réaliser cet exemple. Utilisez le premier compte pour exécuter les commandes fournisseur, puis passez au second compte pour exécuter les commandes consommateur.

Consommateur : installer des salles blanches¶

Utilisez une feuille de calcul Snowflake dans le compte du consommateur pour exécuter les commandes de cette section.

En tant que consommateur, vous pouvez avoir plusieurs salles blanches partagées avec vous. Avant d’effectuer une analyse multi-fournisseurs, vous devez installer chacun d’entre eux dans votre compte et lier les ensembles de données que vous avez l’intention d’utiliser pour les analyses.

Mise en place de l’environnement¶

Avant d’utiliser les APIs du développeur, vous devez assumer le rôle SAMOOHA_APP_ROLE et spécifier l’entrepôt utilisé pour exécuter les APIs. Si vous n’avez pas le rôle SAMOOHA_APP_ROLE, contactez votre administrateur de compte.

Exécutez les commandes suivantes pour configurer votre environnement :

USE ROLE samooha_app_role;
USE WAREHOUSE app_wh;

Copy

Installer les salles blanches¶

Avant d’installer les salles blanches, attribuez à chacune d’elles un nom que le fournisseur vous a communiqué.

set cleanroom_name_1 = 'Samooha Cleanroom Multiprovider Clean Room 1';
set cleanroom_name_2 = 'Samooha Cleanroom Multiprovider Clean Room 2';

Copy

Les commandes suivantes installent les salles blanches dans le compte du consommateur :

CALL samooha_by_snowflake_local_db.consumer.install_cleanroom($cleanroom_name_1, '<PROVIDER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.consumer.install_cleanroom($cleanroom_name_2, '<PROVIDER_ACCOUNT_LOCATOR>');

Copy

Après l’installation de la salle blanche, le fournisseur doit terminer la configuration de la salle blanche de son côté avant de pouvoir l’utiliser. La fonction ci-dessous vous permet de vérifier le statut de la salle blanche. Une fois qu’elle a été activée, vous devriez être en mesure d’exécuter la commande Run Analysis ci-dessous. Il faut généralement environ une minute pour que la salle blanche soit activée.

CALL samooha_by_snowflake_local_db.consumer.is_enabled($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.consumer.is_enabled($cleanroom_name_2);

Copy

Après l’installation d’un partage de salle blanche, la liste des salles blanches disponibles peut être affichée à l’aide de la commande ci-dessous.

CALL samooha_by_snowflake_local_db.consumer.view_cleanrooms();

Copy

Lier l’ensemble de données¶

Liez les ensembles de données dans la salle blanche pour effectuer des calculs sécurisés avec les données du fournisseur.

CALL samooha_by_snowflake_local_db.consumer.link_datasets($cleanroom_name_1, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']);

CALL samooha_by_snowflake_local_db.consumer.link_datasets($cleanroom_name_2, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']);

Copy

Note

Si cette étape ne fonctionne pas alors que votre table existe, il se peut que la base de données qui contient la table ne soit pas enregistrée. Pour enregistrer la base de données, exécutez les commandes suivantes en tant qu’utilisateur ayant le rôle ACCOUNTADMIN.

USE ROLE accountadmin;
CALL samooha_by_snowflake_local_db.provider.register_db('<DATABASE_NAME>');
USE ROLE samooha_app_role;

Copy

Si vous souhaitez voir les ensembles de données que vous avez ajoutés à la salle blanche, appelez la procédure suivante.

CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name_2);

Copy

Consommateur : envoyer une requête pour ajouter un modèle défini par le consommateur aux salles blanches¶

Le consommateur qui effectue une analyse multi-fournisseurs est souvent le mieux placé pour savoir comment extraire la valeur des données provenant de plusieurs parties. Un consommateur peut envoyer une demande aux fournisseurs de salles blanches pour inclure un modèle défini par le consommateur dans la salle blanche afin que le consommateur puisse l’utiliser pour exécuter des analyses. Pour plus d’informations sur l’ajout de modèles définis par le consommateur à une salle blanche, consultez Ajout de modèles définis par le consommateur.

Note

Les analyses dans les salles blanches multi-fournisseurs fonctionnent en rendant toutes les tables des autres salles blanches, ainsi que de la salle blanche actuelle, dans l’argument source_tables du modèle. Cependant, lors des validations de sécurité et de l’approbation des requêtes, chaque salle blanche reçoit également uniquement les tables qui la concernent. Par conséquent, le modèle doit être écrit de manière générique sans supposer un nombre spécifique d’arguments source_table, ce qui lui permet de s’étendre sur une ou plusieurs entrées source_table. Vous pouvez utiliser une boucle for de Jinja pour mettre cela en œuvre.

Pour cet exemple, le consommateur envoie les requêtes suivantes. Chaque requête inclut le code Jinja qui définit le modèle.

CALL samooha_by_snowflake_local_db.consumer.create_template_request($cleanroom_name_1, 'multiprovider_overlap_analysis', $$
WITH union_data AS (
    select identifier({{ hem_col[0] | join_policy }}) as join_col, identifier({{ dimensions[0] | column_policy }}) as group_col 
    {% for dim in dimensions[1:] %}
        , identifier({{ dim }}) as group_col_{{ loop.index }}
    {% endfor %}
    from identifier({{ source_table[0] }}) p1
    {% for src in source_table[1:] %}
        inner join (
        select identifier({{ hem_col[loop.index] | join_policy }}), identifier({{ dimensions[loop.index] | column_policy  }})  from identifier({{ src }}) p{{ loop.index + 1}} )  p{{ loop.index + 1}} 
        on identifier({{ hem_col[0] }}) = identifier({{ hem_col[loop.index] }})
    {% endfor %}
)
select count(distinct join_col), group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
from union_data u
inner join identifier({{ my_table[0] }}) c
on u.join_col = c.{{ consumer_join_col | sqlsafe }}
group by group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
$$);

CALL samooha_by_snowflake_local_db.consumer.create_template_request($cleanroom_name_2, 'multiprovider_overlap_analysis', $$
WITH union_data AS (
    select identifier({{ hem_col[0] | join_policy }}) as join_col, identifier({{ dimensions[0] | column_policy }}) as group_col 
    {% for dim in dimensions[1:] %}
        , identifier({{ dim }}) as group_col_{{ loop.index }}
    {% endfor %}
    from identifier({{ source_table[0] }}) p1
    {% for src in source_table[1:] %}
        inner join (
        select identifier({{ hem_col[loop.index] | join_policy }}), identifier({{ dimensions[loop.index] | column_policy  }})  from identifier({{ src }}) p{{ loop.index + 1}} )  p{{ loop.index + 1}} 
        on identifier({{ hem_col[0] }}) = identifier({{ hem_col[loop.index] }})
    {% endfor %}
)
select count(distinct join_col), group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
from union_data u
inner join identifier({{ my_table[0] }}) c
on u.join_col = c.{{ consumer_join_col | sqlsafe }}
group by group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
$$);

Copy

Fournisseur : approuver la demande du consommateur d’ajouter un modèle¶

Le fournisseur doit approuver les requêtes du consommateur pour inclure un modèle défini par le consommateur dans les salles blanches.

Le fournisseur utilise la commande provider.list_template_requests permettant de lister les requêtes, y compris l’obtention des UUID de la nouvelle requête. Le fournisseur approuve ensuite les requêtes en exécutant la commande provider.approve_template_request. Pour plus d’informations sur ce processus, voir Ajout de modèles définis par le consommateur.

CALL samooha_snowflake_local_db.provider.list_template_requests($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.provider.approve_template_request($cleanroom_name_1, <REQUEST_UUID>);


CALL samooha_snowflake_local_db.provider.list_template_requests($cleanroom_name_2);
CALL samooha_by_snowflake_local_db.provider.approve_template_request($cleanroom_name_2, <REQUEST_UUID>);

Copy

Définir la politique des colonnes pour chaque table¶

Pour chaque combinaison de table et de modèle, définissez les colonnes que le consommateur peut utiliser dans une analyse, par exemple les colonnes sur lesquelles il peut faire des groupes ou des agrégats. Cela offre une certaine souplesse, de sorte qu’une même table peut permettre différentes sélections de colonnes en fonction du modèle sous-jacent. Attendez d’avoir ajouté un modèle pour définir la politique de colonne d’une table.

Notez que la politique de colonnes est remplacement uniquement, donc si la fonction est appelée à nouveau, la politique de colonnes précédemment définie est complètement remplacée par la nouvelle.

Les politiques de colonnes ne doivent pas être utilisées pour les colonnes d’identité telles que l’adresse e-mail, HEM ou RampID, car vous ne souhaitez pas que le consommateur puisse effectuer des groupes en fonction de ces colonnes. Dans l’environnement de production, Snowflake déduit des colonnes PII et bloque cette opération, mais cette inférence n’est pas disponible dans un environnement sandbox. Elle ne doit être utilisée que pour les colonnes par lesquelles vous souhaitez que le consommateur puisse faire des agrégations et des groupes, comme le statut, la tranche d’âge, le code de région ou le nombre de jours d’activité.

Pour que les « column_policy » et « join_policy » effectuent des contrôles sur les requêtes d’analyse des consommateurs, il faut faire référence à tous les noms de colonnes en tant que dimensions ou measure_columns dans le modèle SQL Jinja. Veillez à utiliser ces balises pour faire référence aux colonnes que vous souhaitez vérifier dans les modèles personnalisés SQL Jinja.

Pour définir la politique de colonne pour une combinaison modèle/table, exécutez les commandes suivantes :

CALL samooha_by_snowflake_local_db.provider.set_column_policy($cleanroom_name_1, [ 'multiprovider_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS']);

CALL samooha_by_snowflake_local_db.provider.set_column_policy($cleanroom_name_2, [
'multiprovider_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:REGION_CODE']);

Copy

Consommateur : établir une requête d’analyse de salle blanche multi-fournisseurs¶

L’étape suivante consiste à établir une analyse multi-fournisseurs pour l’ensemble des salles blanches que vous avez installées. Cet ensemble de salles blanches est appelé cluster de salles blanches. Ce processus consiste à demander à chaque fournisseur si cette analyse multi-fournisseurs peut être approuvée et exécutée. Ces requêtes sont traitées de manière asynchrone par le fournisseur selon un flux automatisé ou manuel. Si un flux d’approbation automatisé est utilisé, le traitement de la requête se fait en 2 minutes environ et si l’approbation est donnée par chaque salle blanche (après avoir vérifié la conformité de la demande avec les politiques de sécurité de la salle blanche), le flux peut être exécuté.

Le flux de requêtes de salle blanche multi-fournisseurs exige que les tables des fournisseurs soient spécifiées sous l’argument de tableau source_table. Les tables doivent commencer par le nom de la salle blanche dans laquelle ils se trouvent. La forme générale est la suivante : <CLEANROOM_NAME>.<DB>.<SCHEMA>.<TABLE> . Les tables de consommateurs peuvent être fournies sous l’argument de tableau my_table.

CALL samooha_by_snowflake_local_db.consumer.prepare_multiprovider_flow(
    [$cleanroom_name_1, $cleanroom_name_2],
    'prod_aggregate_data',
    object_construct(
        'source_table', [
            concat($cleanroom_name_1, '.SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'), 
            concat($cleanroom_name_2, '.SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS')
        ],
        'my_table', ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']),
        'hem_col', ['p1.HASHED_EMAIL', 'p2.HASHED_EMAIL'],
        'dimensions', ['p1.STATUS', 'p2.STATUS'],
        'consumer_join_col', 'HASHED_EMAIL'
    )
);

Copy

Cette API vérifie d’abord que la requête est conforme aux politiques de sécurité de chaque salle blanche avant d’adresser la requête d’analyse multi-fournisseurs à chaque fournisseur de salle blanche. Si ces vérifications échouent, cette API renvoie le message d’erreur qu’elle a rencontré.

Comment déterminer les entrées de prepare_multiprovider_flow ?¶

Pour exécuter l’analyse, vous devez transmettre certains paramètres à la fonction run_analysis. Cette section vous montre comment déterminer les paramètres à transmettre.

Noms de modèles

Tout d’abord, vous pouvez voir les modèles d’analyse pris en charge en exécutant la commande suivante :

CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name);

Copy

Avant d’exécuter une analyse avec un modèle, vous devez savoir quels arguments spécifier et quels types sont attendus. Pour les modèles personnalisés, vous pouvez exécuter la commande suivante :

CALL samooha_by_snowflake_local_db.consumer.view_template_definition($cleanroom_name, 'prod_custom_template');

Copy

Cette fonction renvoie un grand nombre de paramètres SQL Jinja différents. Pour analyser le modèle SQL Jinja et extraire dans une liste les arguments qui doivent être spécifiés dans run_analysis, exécutez la commande suivante.

CALL samooha_by_snowflake_local_db.consumer.get_arguments_from_template($cleanroom_name, 'prod_custom_template');

Copy

Noms des ensembles de données

Si vous souhaitez voir les noms des ensembles de données qui ont été ajoutés à la salle blanche par le fournisseur, exécutez la commande suivante. Notez que vous ne pouvez pas voir les données présentes dans les ensembles de données qui ont été ajoutés à la salle blanche par le fournisseur.

CALL samooha_by_snowflake_local_db.consumer.view_provider_datasets($cleanroom_name);

Copy

Vous pouvez également voir les tables que vous avez liées à la salle blanche en exécutant la commande suivante :

CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name);

Copy

Colonnes de dimensions et de mesures

Lors de l’exécution de l’analyse, il se peut que vous souhaitiez filtrer, grouper et agréger certaines colonnes. Si vous souhaitez voir la politique de colonne qui a été ajoutée à la salle blanche par le fournisseur, exécutez la commande suivante :

CALL samooha_by_snowflake_local_db.consumer.view_provider_column_policy($cleanroom_name);

Copy

Erreurs courantes

Si vous obtenez l’erreur Not approved : unauthorized columns used à la suite de l’analyse de l’exécution, essayez de voir la politique de jointure et la politique de colonne définies par le fournisseur.

CALL samooha_by_snowflake_local_db.consumer.view_provider_join_policy($cleanroom_name);
CALL samooha_by_snowflake_local_db.consumer.view_provider_column_policy($cleanroom_name);

Copy

Il est également possible que vous ayez épuisé votre budget de confidentialité, ce qui vous empêche d’exécuter d’autres requêtes. Le budget de confidentialité restant peut être vu à l’aide de la commande suivante. Le budget se réinitialise tous les jours, sinon le fournisseur de la salle blanche peut le faire manuellement.

CALL samooha_by_snowflake_local_db.consumer.view_remaining_privacy_budget($cleanroom_name);

Copy

Vous pouvez vérifier si la confidentialité différentielle a été activée pour votre salle blanche en utilisant l’API suivante :

CALL samooha_by_snowflake_local_db.consumer.is_dp_enabled($cleanroom_name);

Copy

Fournisseur : activer l’analyse multi-fournisseurs et approuver les requêtes¶

Vous allez maintenant repasser sur le compte du fournisseur afin d’activer l’analyse multi-fournisseurs pour le consommateur et de traiter les requêtes émises.

Permettre aux salles blanches d’effectuer des analyses multi-fournisseurs¶

Un consommateur ne peut pas effectuer avec succès une analyse multi-fournisseurs tant que vous n’avez pas activé la salle blanche à cet effet. Lorsque vous activez la salle blanche pour le consommateur, vous indiquez également quelles salles blanches peuvent être incluses dans l’analyse multi-fournisseurs. Le consommateur ne peut pas effectuer une analyse multi-fournisseurs impliquant votre salle blanche et la salle blanche d’un autre fournisseur, à moins que vous n’approuviez expressément la salle blanche de l’autre fournisseur.

Pour permettre à un consommateur d’effectuer une analyse multi-fournisseurs en utilisant une salle blanche de n’importe quel autre fournisseur, spécifiez une liste vide lors de l’exécution des commandes suivantes.

Note

Elle ne peut être demandée qu’aux consommateurs qui ont déjà installé la salle blanche.

CALL samooha_by_snowflake_local_db.provider.enable_multiprovider_computation($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>', [concat('<PROVIDER_ORG_NAME>.<PROVIDER_ACCOUNT_NAME>.', $cleanroom_name_2)]);

CALL samooha_by_snowflake_local_db.provider.enable_multiprovider_computation($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>', [concat('<PROVIDER_ORG_NAME>.<PROVIDER_ACCOUNT_NAME>.', $cleanroom_name_1)]);

Copy

Approuver les requêtes d’analyse multi-fournisseurs¶

Une fois que l’analyse multi-fournisseurs a été activée dans chaque salle blanche, toutes les requêtes d’analyse multi-fournisseurs émises pour les salles blanches peuvent être vues à l’aide de l’API suivante :

CALL samooha_by_snowflake_local_db.provider.view_multiprovider_requests($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.provider.view_multiprovider_requests($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>');

Copy

L’approbation d’une requête peut se faire de deux manières :

Utilisation automatique d’une tâche qui écoute les requêtes entrantes et se déclenche lorsque c’est nécessaire.
Manuellement par un utilisateur qui traite explicitement les requêtes d’analyse multi-fournisseurs entrantes.

Par défaut, les approbations sont manuelles et la tâche est créée dans un état suspendu par l’API enable_multiprovider_computation. Cela nécessite qu’un utilisateur traite manuellement les requêtes entrantes. Vous pouvez le faire en exécutant les commandes suivantes :

CALL samooha_by_snowflake_local_db.provider.process_multiprovider_request($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>', '<REQUEST_ID>');

CALL samooha_by_snowflake_local_db.provider.process_multiprovider_request($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>', '<REQUEST_ID>');

Copy

Note

Cette API peut être utilisée au niveau d’un ID de requête en spécifiant un ID de requête particulière à partir de la sortie de l’API view_multiprovider_requests, ou REQUEST_ID peut être transmis à “-1” pour traiter toutes les requêtes entrantes.

Ce processus n’approuve pas les requêtes entrantes, mais les fait passer par une logique de traitement pour vérifier si elles peuvent être approuvées sur la base de facteurs tels que l’ancienneté de la requête et si les collaborateurs demandés figurent dans votre liste de collaborateurs approuvés que vous avez définie lors de enable_multiprovider_compomputation.

Une fois la requête traitée, elle est écrite dans la table samooha_cleanroom_${UUID}.admin.request_log_multiprovider. Vous pouvez consulter la liste des requêtes et savoir si elles ont été approuvées ou non au moyen de requêtes telles que les suivantes :

SELECT * FROM samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider;
SELECT * FROM samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider;

Copy

Les requêtes antérieures qui n’ont pas été approuvées peuvent également être remplacées par APPROVE=True, ou à l’inverse, l’accès peut être supprimé en définissant APPROVE=False à l’aide des requêtes suivantes. Voir la section Remarques relatives à la sécurité ci-dessous pour plus de détails sur les <CONDITIONS>.

-- Override and approve a request that had previously been rejected
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider set APPROVED=True where <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider set APPROVED=True where <CONDITIONS>;

-- Revoke access to a query you had previously approved
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider set APPROVED=False where <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider set APPROVED=False where <CONDITIONS>;

Copy

Si le flux d’approbation automatisé est préféré aux approbations manuelles, les tâches d’analyse multi-fournisseurs doivent être reprises en exécutant les commandes suivantes :

CALL samooha_by_snowflake_local_db.provider.resume_multiprovider_tasks($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.provider.resume_multiprovider_tasks($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>');

Copy

Inversement, si le flux d’approbation automatisé est actuellement activé, il peut être désactivé en exécutant les commandes suivantes :

CALL samooha_by_snowflake_local_db.provider.suspend_multiprovider_tasks($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.provider.suspend_multiprovider_tasks($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>');

Copy

Remarques relatives à la sécurité : gestion des requêtes d’analyse multi-fournisseurs¶

Les analyses multi-fournisseurs consistent à ajouter le hachage d’une requête approuvée à une politique d’accès aux lignes La politique d’accès aux lignes est généralement créée sous le schéma samooha_cleanroom_${UUID}.shared_schema et la définition de la politique d’accès aux lignes est la suivante :

CREATE OR REPLACE ROW ACCESS POLICY samooha_cleanroom_${UUID}.shared_schema.${firewall_name} AS (foo varchar) RETURNS BOOLEAN ->
    EXISTS  (SELECT request_id FROM samooha_cleanroom_${UUID}.admin.REQUEST_LOG_MULTIPROVIDER w
        WHERE party_account=current_account()
            AND approved=true
            AND sha2(current_statement()) = query_hash
        );

Copy

La politique d’accès aux lignes fonctionne en trouvant les requêtes approuvées dans la table samooha_cleanroom_${UUID}.admin.request_log_multiprovider sur votre compte pour le consommateur spécifique de votre salle blanche et en vérifiant que le hachage de la requête en cours d’exécution dans leur compte correspond à la requête qui a été approuvée.

Tous les accès de sécurité à vos données pour les flux multi-fournisseurs sont régis par les approbations indiquées dans cette table (samooha_cleanroom_${UUID}.admin.request_log_multiprovider). Vous devez la gérer de manière proactive afin de vous assurer que seules les requêtes pour lesquelles vous souhaitez avoir accès à vos données sont autorisées à s’exécuter.

Des requêtes simples peuvent être utilisées pour approuver ou désapprouver (c’est-à-dire supprimer les approbations) des requêtes traitées précédemment. Par exemple, vous pouvez exécuter les requêtes suivantes :

-- Override and approve a request that had previously been rejected
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider SET APPROVED=True WHERE <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider SET APPROVED=True WHERE <CONDITIONS>;

-- Revoke access to a query you had previously approved
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider SET APPROVED=False WHERE <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider SET APPROVED=False WHERE <CONDITIONS>;

Copy

Comme le montre la politique d’accès aux lignes, l’accès aux données est accordé en fonction de query_hash. Cependant, query_hash peut également dépendre de la salle blanche sélectionnée au hasard pour exécuter la requête, de sorte que <CONDITIONS> transmis dans la requête ci-dessus pour déterminer les requêtes auxquelles révoquer l’accès/qu’il faut approuver doit suivre ces bonnes pratiques :

Si vous approuvez manuellement une requête, essayez d’être aussi précis que possible en filtrant sur request_id et/ou cleanroom_names, requester_account et template_name.
Si vous révoquez une approbation antérieure pour une requête, révoquez toutes les requêtes pour lesquelles query_hash correspond, et aussi toutes les requêtes pour requester_account et template_name et cleanroom_names (voir l’exemple ci-dessous).
Si une nouvelle requête n’est pas approuvée, cela ne modifie pas l’approbation des requêtes précédentes. Si vous souhaitez révoquer l’accès aux requêtes précédentes, vous devez marquer les requêtes correspondantes avec APPROVED=False dans la table samooha_cleanroom_${UUID}.admin.request_log_multiprovider.
Si vous modifiez l’ensemble des collaborateurs autorisés en exécutant à nouveau enable_multiprovider_computation, les requêtes précédentes ne sont pas révoquées par défaut. Vous devez gérer les approbations en révoquant l’accès aux collaborations précédentes en définissant APPROVED=False dans la table samooha_cleanroom_${UUID}.admin.request_log_multiprovider.

Un exemple de la façon de révoquer complètement la capacité d’une collaboration particulière à faire des requêtes. Supposons qu’il existe une collaboration active sur requester_account=ABC123 que vous souhaitez révoquer. Vous pouvez exécuter les requêtes suivantes :

UPDATE samooha_cleanroom_{UUID}.admin.request_log_multiprovider SET APPROVED=False WHERE requester_account = 'ABC123' AND query_hash = '<HASH>';
UPDATE samooha_cleanroom_{UUID}.admin.request_log_multiprovider SET APPROVED=False WHERE requester_account = 'ABC123' AND template_name = '<TEMPLATE_NAME>' AND request:CLEANROOM_NAMES = [$cleanroom_name1, $cleanroom_name2];

Copy

L’accès au hachage de la requête et à ce modèle dans la salle blanche de collaboration est révoqué.

Voici quelques exemples de requêtes qui vous permettent de voir combien de requêtes ont été établies par chaque compte de demandeur :

SELECT requester_account, count(*) FROM samooha_cleanroom_{UUID}.admin.request_log_multiprovider;

-- If there is a requester_account raising too many queries they can be disallowed in bulk
UPDATE samooha_cleanroom_{UUID}.admin.request_log_multiprovider SET APPROVED=False WHERE requester_account = '<ACCOUNT>';

Copy

Consommateur - Exécuter la requête¶

Une fois que la requête établie par l’API prepare_multiprovider_flow a été approuvée, elle peut être exécutée à l’aide de l’API suivante dans le cluster de la salle blanche. Pour ce faire, une salle blanche est sélectionnée au hasard pour exécuter le flux, et tant que les deux salles blanches ont approuvé la requête, l’analyse multi-fournisseurs est autorisée à se poursuivre.

CALL samooha_by_snowflake_local_db.consumer.execute_multiprovider_flow([$cleanroom_name_1, $cleanroom_name_2]);

Copy

Notez également que lorsqu’une requête a été approuvée après la procédure prepare_multiprovider_flow, la procédure execute_multiprovider_flow peut être appelée autant de fois que nécessaire sans qu’il soit nécessaire d’appeler à nouveau prepare_multiprovider_flow. Cependant, pour effectuer une analyse différente ou une analyse sur un cluster de salle blanche différent, la procédure prepare_multiprovider_flow doit être appelée à nouveau.

Fonctions utiles¶

Une fois que les requêtes d’interopérabilité sont adressées à chaque fournisseur, l’approbation prend la forme de modèles clients spécifiques à la requête qui sont ajoutés à la salle blanche et exécutés au cours de l’analyse. Ces derniers mettent en place l’infrastructure nécessaire. Vous pouvez voir ces modèles ajoutés en temps réel par le processus d’approbation de la requête en exécutant les commandes suivantes.

CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name_2);

Copy

Snowflake Data Clean Rooms : salles blanches multi-fournisseurs¶

Conditions préalables¶

Fournisseur : Créer et partager une salle blanche¶

Mise en place de l’environnement¶

Créer la salle blanche¶

Lier l’ensemble de données¶

Définir la politique de jointure pour l’ensemble de données¶

Partager avec un consommateur¶

Consommateur : installer des salles blanches¶

Mise en place de l’environnement¶

Installer les salles blanches¶

Lier l’ensemble de données¶

Consommateur : envoyer une requête pour ajouter un modèle défini par le consommateur aux salles blanches¶

Fournisseur : approuver la demande du consommateur d’ajouter un modèle¶

Définir la politique des colonnes pour chaque table¶

Consommateur : établir une requête d’analyse de salle blanche multi-fournisseurs¶

Comment déterminer les entrées de prepare_multiprovider_flow ?¶

Fournisseur : activer l’analyse multi-fournisseurs et approuver les requêtes¶

Permettre aux salles blanches d’effectuer des analyses multi-fournisseurs¶

Approuver les requêtes d’analyse multi-fournisseurs¶

Remarques relatives à la sécurité : gestion des requêtes d’analyse multi-fournisseurs¶

Consommateur - Exécuter la requête¶

Fonctions utiles¶