Snowflake Data Clean Rooms : analyse de chevauchement¶
Cette rubrique décrit les flux de fournisseurs et de consommateurs nécessaires à la mise en place programmatique d’une salle blanche, à son partage avec un consommateur et à l’exécution d’analyses de données du côté du fournisseur. Dans le cas d’une analyse de données côté fournisseur, le consommateur n’a pas besoin d’apporter ses propres ensembles de données, mais souhaite simplement obtenir des informations agrégées sur les ensembles de données du fournisseur.
Les points suivants seront couverts :
Fournisseur :
a. Création d’une nouvelle salle blanche.
b. L’établissement de liens sécurisés avec les ensembles de données.
c. Ajout de règles régissant les colonnes qui peuvent être jointes et utilisées dans l’analyse.
d. Activation d’un modèle d’analyse de chevauchement prédéfini.
e. Partage avec un consommateur.
Consommateur :
a. Installation d’une salle blanche partagée par le fournisseur.
b. Ajout de vos ensembles de données à la salle blanche.
c. Examen du modèle fourni dans la salle blanche.
d. Exécution d’une analyse dans la salle blanche à l’aide du modèle.
Conditions préalables¶
Vous avez besoin de deux comptes Snowflake distincts pour réaliser ce flux. Utilisez le premier compte pour exécuter les commandes fournisseur, puis passez au second compte pour exécuter les commandes consommateur.
Fournisseur¶
Note
Les commandes suivantes doivent être exécutées dans une feuille de calcul Snowflake du compte fournisseur.
Mise en place de l’environnement¶
Exécutez les commandes suivantes pour configurer l’environnement Snowflake avant d’utiliser les APIs du développeur pour travailler avec une Snowflake Data Clean Room. Si vous n’avez pas le rôle SAMOOHA_APP_ROLE, contactez votre administrateur de compte.
use role samooha_app_role;
use warehouse app_wh;
Créer la salle blanche¶
Créez un nom pour la salle blanche. Saisissez un nouveau nom de salle blanche pour éviter toute collision avec des noms de salle blanche existants. Notez que les noms des salles blanches ne peuvent être que alphanumériques. Les noms des salles blanches ne peuvent pas contenir de caractères spéciaux autres que des espaces et des traits de soulignement.
set cleanroom_name = 'Overlap Analysis Demo Clean Room';
Vous pouvez créer une nouvelle salle blanche avec le nom de la salle blanche défini ci-dessus. Si le nom de la salle blanche défini ci-dessus existe déjà en tant que salle blanche existante, ce processus échoue.
Cette procédure dure généralement une demi-minute.
Le deuxième argument de provider.cleanroom_init est la distribution de la salle blanche. Il peut s’agir de INTERNAL ou de EXTERNAL. À des fins de test, si vous partagez la salle blanche avec un compte de la même organisation, vous pouvez utiliser INTERNAL pour contourner l’analyse de sécurité automatisée qui doit avoir lieu avant qu’un paquet d’applications ne soit publié aux collaborateurs. Cependant, si vous partagez cette salle blanche avec un compte dans une autre organisation, vous devez utiliser une distribution de salle blanche EXTERNAL.
call samooha_by_snowflake_local_db.provider.cleanroom_init($cleanroom_name, 'INTERNAL');
Pour voir le statut de l’analyse de sécurité, utilisez :
call samooha_by_snowflake_local_db.provider.view_cleanroom_scan_status($cleanroom_name);
Une fois que vous avez créé votre salle blanche, vous devez définir sa directive de version avant de pouvoir la partager avec un collaborateur. Toutefois, si votre distribution a été définie sur EXTERNAL, vous devez d’abord attendre la fin de l’analyse de sécurité avant de définir la directive de version. Vous pouvez continuer à exécuter le reste des étapes pendant que l’analyse se termine et revenir ici avant l’étape provider.create_cleanroom_listing.
Pour définir la directive de version, appelez :
call samooha_by_snowflake_local_db.provider.set_default_release_directive($cleanroom_name, 'V1_0', '0');
Partage interrégional¶
Pour partager une salle blanche avec un client de Snowflake dont le compte se trouve dans une région différente de votre compte, vous devez activer [l’exécution automatique inter-Cloud] (https://other-docs.snowflake.com/fr/collaboration/provider-listings-auto-fulfillment). Pour des informations sur les coûts supplémentaires liés à la collaboration avec des consommateurs d’autres régions, voir Coûts de l’exécution automatique inter-Cloud.
Lorsque vous utilisez les APIs du développeur, l’activation du partage interrégional se fait en deux étapes :
Un administrateur Snowflake ayant le rôle ACCOUNTADMIN active l’exécution automatique inter-Cloud pour votre compte Snowflake. Pour plus d’informations, voir Collaborer avec des comptes situés dans des régions différentes.
Vous exécutez la commande provider.enable_laf_for_cleanroom pour activer l’exécution automatique inter-Cloud pour la salle blanche. Par exemple :
call samooha_by_snowflake_local_db.provider.enable_laf_for_cleanroom($cleanroom_name);
Après avoir activé l’exécution automatique inter-Cloud pour la salle blanche, vous pouvez ajouter des consommateurs à votre annonce comme d’habitude à l’aide de la commande provider.create_cleanroom_listing. L’annonce est automatiquement répliquée vers des cloud et des régions distantes, selon les besoins.
Liez l’ensemble de données et définissez la politique de jointure pour l’ensemble de données¶
Liez des tables Snowflake dans la salle blanche. Parcourez la liste des tables de votre compte Snowflake et saisissez les noms de table entièrement qualifiés (Database.Schema.Table) sous forme de tableau. La procédure rend automatiquement la table accessible à la salle blanche en créant une vue sécurisée de la table depuis l’intérieur de la salle blanche, évitant ainsi tout besoin de faire une copie de votre table.
call samooha_by_snowflake_local_db.provider.link_datasets($cleanroom_name, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']);
Note
Si cette étape ne fonctionne pas alors que votre table existe, il est probable que le rôle SAMOOHA_APP_ROLE n’ait pas encore reçu l’accès à cette table. Si c’est le cas, passez au rôle ACCOUNTADMIN, appelez la procédure ci-dessous sur la base de données, puis repassez au rôle suivant pour le reste du flux :
use role accountadmin;
call samooha_by_snowflake_local_db.provider.register_db('<DATABASE_NAME>');
use role samooha_app_role;
Si vous souhaitez voir les ensembles de données qui ont été ajoutés à la salle blanche, appelez la procédure suivante.
call samooha_by_snowflake_local_db.provider.view_provider_datasets($cleanroom_name);
Pour déterminer les colonnes à utiliser comme politique de jointures, vous pouvez examiner votre ensemble de données pour déterminer les colonnes PII. Pour voir les 10 premières lignes, exécutez la requête suivante :
select * from SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS limit 10;
Indiquez quelles colonnes le consommateur est autorisé à joindre lors de l’exécution de modèles dans la salle blanche. Cette procédure doit être appelée sur les colonnes d’identité comme l’adresse e-mail. La politique de jointure est de type « remplacement uniquement », donc si la fonction est appelée à nouveau, la politique de jointure précédemment définie est entièrement remplacée par la nouvelle.
call samooha_by_snowflake_local_db.provider.set_join_policy($cleanroom_name, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HEM']);
Si vous souhaitez voir la politique de jointure qui a été ajoutée à la salle blanche, appelez la procédure suivante.
call samooha_by_snowflake_local_db.provider.view_join_policy($cleanroom_name);
Ajouter des modèles d’analyse à la salle blanche¶
Ajouter une liste de modèles prédéfinis à l’aide de leurs identificateurs de noms. Dans ce flux, vous allez ajouter un modèle prédéfini qui permet à un consommateur d’effectuer une analyse sur le chevauchement entre ses jeux de données et les ensembles de données du fournisseur de manière sécurisée et approuvée par le fournisseur sur des colonnes approuvées par le fournisseur.
Un détail crucial de ce modèle est qu’il implémente nativement les garanties de sécurité supplémentaires fournies par la confidentialité différentielle. Voir Confidentialité différentielle pour en savoir plus.
call samooha_by_snowflake_local_db.provider.add_templates($cleanroom_name, ['prod_overlap_analysis']);
Si vous souhaitez voir les modèles actuellement actifs dans la salle blanche, appelez la procédure suivante. Vous pouvez voir les modifications que vous devez apporter pour activer les garanties de confidentialité différentielle sur votre analyse. Un modèle similaire peut être incorporé dans tout modèle personnalisé que vous choisissez de rédiger.
Note
Notez que tous les modèles prédéfinis définis par le système sont chiffrés et ne sont pas visibles par défaut. Les modèles personnalisés que vous ajoutez sont toutefois visibles.
call samooha_by_snowflake_local_db.provider.view_added_templates($cleanroom_name);
Tout modèle ajouté à la salle blanche peut également être supprimé si nécessaire. Voir le Guide de référence du fournisseur API pour plus de détails.
Définir la politique des colonnes pour chaque table¶
Affichez les données liées pour voir les colonnes présentes dans la table. Pour voir les 10 premières lignes, appelez la procédure suivante.
select * from SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS limit 10;
Définissez les colonnes que le consommateur peut regrouper et agréger (par exemple SUM/AVG) et utiliser généralement dans une analyse pour chaque combinaison de tableau et de modèle. Cela offre une certaine souplesse, de sorte qu’une même table peut permettre des sélections de colonnes différentes en fonction du modèle sous-jacent. Cette fonction ne doit être appelée qu’après l’ajout du modèle.
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.
La politique de colonnes ne doit pas être utilisée pour les colonnes d’identité telles que l’adresse e-mail, HEM, RampID, car vous ne souhaitez pas que le consommateur puisse effectuer des groupes en fonction de ces colonnes. Dans l’environnement de production, le système déduit intelligemment les colonnes PII et bloque cette opération, mais cette fonction n’est pas disponible dans l’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 canal, le nombre de jours d’activité, etc.
call samooha_by_snowflake_local_db.provider.set_column_policy($cleanroom_name, [
'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',
'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:REGION_CODE']);
Si vous souhaitez voir la politique de colonnes qui a été ajoutée à la salle blanche, appelez la procédure suivante.
call samooha_by_snowflake_local_db.provider.view_column_policy($cleanroom_name);
Consommateur¶
Note
Les commandes suivantes doivent être exécutées dans une feuille de calcul Snowflake du compte du consommateur.
Mise en place de l’environnement¶
Exécutez les commandes suivantes pour configurer l’environnement Snowflake avant d’utiliser les APIs du développeur pour travailler avec une Snowflake Data Clean Room. Si vous n’avez pas le rôle SAMOOHA_APP_ROLE, contactez votre administrateur de compte.
use role samooha_app_role;
use warehouse app_wh;
Installer la salle blanche¶
Une fois qu’un partage de salle blanche a été installé, la liste des salles blanches disponibles peut être vue à l’aide de la commande ci-dessous.
call samooha_by_snowflake_local_db.consumer.view_cleanrooms();
Attribuez un nom à la salle blanche que le fournisseur vous a partagée.
set cleanroom_name = 'Overlap Analysis Demo Clean room';
La commande suivante installe la salle blanche sur le compte du consommateur avec le fournisseur associé et la salle blanche sélectionnée. Saisissez le localisateur de compte (et non le nom) Snowflake du fournisseur.
L’exécution de cette procédure peut prendre un peu plus de temps, généralement une demi-minute environ.
call samooha_by_snowflake_local_db.consumer.install_cleanroom($cleanroom_name, '<PROVIDER_ACCOUNT_LOCATOR>');
Une fois la salle blanche installée, le fournisseur doit terminer la mise en place 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);
Lier l’ensemble de données¶
Vous pouvez désormais relier certains de vos ensembles de données à 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, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']);
Note
Si cette étape ne fonctionne pas alors que votre table existe, il est probable que le rôle SAMOOHA_APP_ROLE n’ait pas encore reçu l’accès à cette table. Si c’est le cas, passez au rôle ACCOUNTADMIN, appelez la procédure ci-dessous sur la base de données, puis repassez au rôle suivant pour le reste du flux :
use role accountadmin;
call samooha_by_snowflake_local_db.consumer.register_db('<DATABASE_NAME>');
use role samooha_app_role;
Pour effectuer l’analyse, vous devez transmettre la table des consommateurs. 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);
Effectuer l’analyse¶
Maintenant que la salle blanche est installée, vous pouvez exécuter le modèle d’analyse donné à la salle blanche par le fournisseur à l’aide d’une commande « run_analysis ». Vous pouvez voir comment chaque champ est déterminé dans les sections ci-dessous.
Note
Avant d’effectuer l’analyse, vous pouvez modifier la taille de l’entrepôt ou utiliser une nouvelle taille d’entrepôt plus grande si vos tables sont volumineuses.
-- Example run analysis procedure with single provider dataset
call samooha_by_snowflake_local_db.consumer.run_analysis(
$cleanroom_name, -- cleanroom
'prod_overlap_analysis', -- template name
['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'], -- your tables
['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'], -- the provider table we want to carry out analysis on
object_construct( -- The keyword arguments needed for the SQL Jinja template
'dimensions', ['p.REGION_CODE'], -- Group by column
'measure_type', ['AVG'], -- Aggregate function you want to perform like COUNT, AVG, etc.
'measure_column', ['p.DAYS_ACTIVE'], -- Columns you want to perform aggregate function on
'where_clause', 'p.HEM=c.HEM' -- A boolean filter
-- $$ is used to pass string literal
)
);
Pour chacune des colonnes auxquelles il est fait référence dans le filtrage « where_clause » de l’ensemble de données ou dans les dimensions ou measure_columns, vous pouvez utiliser p. pour faire référence aux champs des tables de fournisseurs et c. pour faire référence aux champs des tables de consommateurs. Utilisez p2, p3, etc., pour plusieurs tables de fournisseurs et c2, c3, etc., pour plusieurs tables de consommateurs.
Comment déterminer les entrées de run_analysis ?¶
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
Premièrement, vous pouvez voir les modèles d’analyse pris en charge en appelant la procédure suivante.
call samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name);
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 les opérations suivantes.
Note
Notez que tous les modèles prédéfinis définis par le système sont chiffrés et ne sont pas visibles par défaut. Les modèles personnalisés que vous ajoutez sont toutefois visibles.
call samooha_by_snowflake_local_db.consumer.view_template_definition($cleanroom_name, 'prod_overlap_analysis');
Celui-ci peut souvent contenir un grand nombre de paramètres Jinja SQL différents. La fonctionnalité suivante analyse le modèle Jinja SQL et extrait les arguments qui doivent être spécifiés dans run_analysis dans une liste.
Note
Notez que tous les modèles prédéfinis définis par le système sont chiffrés et que cette fonction n’obtiendra donc pas les arguments de ces modèles. Vous pourrez toutefois récupérer les paramètres de vos modèles personnalisés.
call samooha_by_snowflake_local_db.consumer.get_arguments_from_template($cleanroom_name, 'prod_overlap_analysis');
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, appelez la procédure 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 en raison des propriétés de sécurité de la salle blanche.
call samooha_by_snowflake_local_db.consumer.view_provider_datasets($cleanroom_name);
Vous pouvez également voir les tables que vous avez liées à la salle blanche en utilisant l’appel suivant :
call samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name);
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 voulez voir la politique de colonnes qui a été ajoutée à la salle blanche par le fournisseur, appelez la procédure suivante.
call samooha_by_snowflake_local_db.consumer.view_provider_column_policy($cleanroom_name);
Budgets de confidentialité et epsilon
Si vous obtenez une erreur à la suite de la dernière procédure d’exécution, c’est peut-être parce qu’il n’y a plus de budget pour l’epsilon élevé que vous avez choisi. Vous pouvez vérifier le budget restant pour la protection de la confidentialité en suivant la procédure ci-dessous.
call samooha_by_snowflake_local_db.consumer.view_remaining_privacy_budget($cleanroom_name);
Le paramètre epsilon que vous spécifiez est une entrée du mécanisme de confidentialité différentielle fonctionnant à l’intérieur de la salle blanche. Consultez la section Confidentialité différentielle pour en savoir plus sur le fonctionnement de la confidentialité différentielle. Plus la valeur d’epsilon que vous indiquez est élevée, plus vous consommez une part importante du budget de confidentialité limité (réinitialisé quotidiennement), mais plus le résultat est précis, car moins de bruit est ajouté aux données agrégées.
Erreurs courantes
Si vous obtenez l’erreur Not approved : unauthorized columns used à la suite de l’analyse de l’exécution, vous voudrez peut-être voir la politique de jointure et la politique de colonnes définies par le fournisseur à nouveau.
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);
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 ci-dessous. Il se réinitialise tous les jours, sinon le fournisseur de la salle blanche peut le réinitialiser s’il le souhaite.
call samooha_by_snowflake_local_db.consumer.view_remaining_privacy_budget($cleanroom_name);
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);