Snowflake Data Clean Rooms : modèles sécurisés basés sur Python¶

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 = 'Custom Secure Python UDF 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 environ 45 secondes.

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 s’exécute 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 :

1. 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.

2. 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);
   

   Copy

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']);

use role accountadmin;
call samooha_by_snowflake_local_db.provider.register_db('<DATABASE_NAME>');
use role samooha_app_role;

Vous pouvez voir les ensembles de données liés à la salle blanche en suivant 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, utilisez 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);

Chargez de manière confidentielle du code Python personnalisé en tant qu’UDFs dans la salle blanche¶

Cette section vous montre comment charger les fonctions Python suivantes dans la salle blanche.

• assign_group -> une UDF qui va ligne par ligne et assigne un ID de groupe.

• group_agg -> une UDF qui regroupe par ID et agrège un aspect des données.

L’API suivante vous permet de définir vos fonctions Python directement en tant que fonctions en ligne dans la salle blanche. Vous pouvez également charger Python à partir de fichiers en zone de préparation que vous avez chargés dans la zone de préparation de la salle blanche. Voir le Guide de référence de l’API pour un exemple.

Le code suivant définit et charge l’UDF assign_group qui va ligne par ligne et attribue un ID de groupe :

call samooha_by_snowflake_local_db.provider.load_python_into_cleanroom(
    $cleanroom_name, 
    'assign_group',                      -- Name of the UDF
    ['data variant', 'index integer'],   -- Arguments of the UDF, specified as (variable name, variable type)
    ['numpy', 'pandas'],                 -- Packages UDF will use
    'integer',                           -- Return type of UDF
    'main',                              -- Handler
    $$
import numpy as np
import pandas as pd

def main(data, index):
    df = pd.DataFrame(data) # Just as an example of what we could do
    np.random.seed(0)
    
    # First let's combine the data row and the additional index into a string
    data.append(index)
    data_string = ",".join(str(d) for d in data)

    # Hash it 
    encoded_data_string = data_string.encode()
    hashed_string = hash(encoded_data_string)

    # Return the hashed string
    return hashed_string
    $$
);

Le code suivant définit et charge l’UDF group_agg qui regroupe par ID et agrège un aspect des données :

call samooha_by_snowflake_local_db.provider.load_python_into_cleanroom(
    $cleanroom_name, 
    'group_agg',              -- Name of the UDF
    ['data variant'],         -- Arguments of the UDF, specified as (variable name, variable type)
    ['pandas'],               -- Packages UDF will use
    'integer',                -- Return type of UDF
    'main',                   -- Handler
    $$
import pandas as pd

def main(s):
    s = pd.Series(s)
    return (s == 'SILVER').sum()
    $$
);

-- See the versions available inside the clean room
show versions in application package samooha_cleanroom_Custom_Secure_Python_UDF_Demo_clean_room;

-- Once the security scan is approved, update the release directive to the latest version
call samooha_by_snowflake_local_db.provider.set_default_release_directive($cleanroom_name, 'V1_0', '2');

Charger du code Python à partir de fichiers Python dans une zone de préparation¶

Au lieu de procéder à une définition, vous pouvez charger Python à partir de fichiers .py dans une zone de préparation. Pour ce faire, vous devez charger votre code dans la zone de préparation de code de salle blanche. Il est important de noter que seuls les fichiers se trouvant dans la zone de préparation de la salle blanche peuvent être utilisés dans la salle blanche, de sorte que vos fichiers ne peuvent pas se trouver ailleurs. Les fichiers doivent être dans la zone de préparation suivante :

ls @samooha_cleanroom_Custom_Secure_Python_UDF_Demo_clean_room.app.code;

Afin de définir les UDFs assign_group et group_agg de cette manière, vous pouvez charger les scripts suivants dans la zone de préparation de salle blanche :

Créez un fichier dans votre répertoire personnel appelé ~/assign_group.py et collez-y le code suivant :

import numpy as np
import pandas as pd


def main(data, index):
    _ = pd.DataFrame(data)  # Just as an example of what we could do
    np.random.seed(0)

    # First let's combine the data row and the additional index into a string
    data.append(index)
    data_string = ",".join(str(d) for d in data)

    # Hash it
    encoded_data_string = data_string.encode()
    hashed_string = hash(encoded_data_string)

    # Return the hashed string
    return hashed_string

Vous devez maintenant charger le code dans la zone de préparation. Pour ce faire, procédez à son ajout dans le dossier contenant la version des fichiers de l’application de salle blanche actuellement publiée. Pour obtenir le dossier nécessaire, vous pouvez suivre la procédure suivante :

call samooha_by_snowflake_local_db.provider.get_stage_for_python_files($cleanroom_name);

Cela vous donne la zone de préparation vers laquelle charger ce fichier. Vous pouvez charger ce fichier dans la zone de préparation en utilisant la commande suivante à partir de snowsql :

PUT file://~/assign_group.py @samooha_cleanroom_Custom_Secure_Python_UDF_Demo_clean_room.app.code/V1_0P1/test_folder overwrite=True auto_compress=False;

Enfin, vous pouvez charger Python dans la salle blanche à l’aide de la commande suivante :

call samooha_by_snowflake_local_db.provider.load_python_into_cleanroom(
    $cleanroom_name,
    'assign_group',                      // Name of the UDF
    ['data variant', 'index integer'],   // Arguments of the UDF, specified as (variable name, variable type)
    ['numpy', 'pandas'],                 // Packages UDF will use
    ['/test_folder/assign_group.py'],                // Name of Python file to import, relative to stage folder uploaded to
    'integer',                           // Return type of UDF
    'assign_group.main'                  // Handler - now scoped to file
);

De la même manière, vous pouvez créer un fichier appelé ~/group_agg.py avec le code suivant :

import pandas as pd


def main(s):
    s = pd.Series(s)
    return (s == "SILVER").sum()

Le dossier dans lequel il doit être chargé aura changé depuis que le dernier appel à load_python_into_cleanroom a ajouté un correctif à la salle blanche. Le nouveau dossier peut être obtenu en exécutant à nouveau la commande suivante :

call samooha_by_snowflake_local_db.provider.get_stage_for_python_files($cleanroom_name);

Le fichier peut ensuite être chargé dans le dossier approprié :

PUT file://~/group_agg.py @samooha_cleanroom_Custom_Secure_Python_UDF_Demo_clean_room.app.code/V1_0P2 overwrite=True auto_compress=False;

Une fois chargé, l’UDF Python peut être créée à partir de ce fichier à l’aide de la commande suivante :

call samooha_by_snowflake_local_db.provider.load_python_into_cleanroom(
    $cleanroom_name,
    'group_agg',                         // Name of the UDF
    ['data variant'],                    // Arguments of the UDF, specified as (variable name, variable type)
    ['pandas'],                          // Packages UDF will use
    ['/group_agg.py'],                   // Name of Python file to import, relative to stage folder uploaded to
    'integer',                           // Return type of UDF
    'group_agg.main'                     // Handler - now scoped to file
);

Ajouter un modèle personnalisé à l’aide des UDFs¶

Pour ajouter un modèle d’analyse personnalisé à la salle blanche, vous avez besoin d’un espace réservé pour les noms des tables, tant du côté du fournisseur que du côté du consommateur, ainsi que des colonnes de jointure du côté du fournisseur. Dans les modèles SQL Jinja, ces espaces réservés doivent toujours être :

• source_table : un tableau de noms de tables du fournisseur

• my_table : un tableau de noms de tables du consommateur

Les noms des tables peuvent être rendus dynamiques par l’utilisation de ces variables, mais ils peuvent également être codés en dur dans le modèle si vous le souhaitez, en utilisant le nom de la vue liée à la salle blanche. Les noms des colonnes peuvent être codés en dur dans le modèle, si vous le souhaitez, ou définis dynamiquement par le biais de paramètres. S’ils sont définis par des paramètres, rappelez-vous que vous devez appeler les paramètres dimensions ou measure_column, qui doivent être des tableaux, pour qu’ils soient vérifiés par rapport à la politique de colonne. Vous les ajoutez en tant que paramètres SQL Jinja dans le modèle, qui seront transmis ultérieurement par le consommateur lors de la requête. Les politiques de jointure garantissent que le consommateur ne peut pas effectuer de jointure sur des colonnes autres que celles qui sont autorisées.

Il est également possible de vérifier la conformité de tout argument d’un modèle SQL Jinja personnalisé avec les politiques de jointure et de colonne à l’aide des filtres suivants :

• join_policy : vérifie si une valeur de chaîne ou une clause de filtre est conforme à la politique de jointure

• politique_de_colonne : vérifie si une valeur de chaîne ou une clause de filtrage est conforme à la politique de colonne

• join_and_column_policy : vérifie que les colonnes utilisées pour une jointure dans une clause de filtrage sont conformes à la politique de jointure et que les colonnes utilisées comme filtre sont conformes à la politique de colonne.

Par exemple, dans la clause {{ provider_id | sqlsafe | join_policy }}, une entrée p.HEM sera analysée pour vérifier si p.HEM figure dans la politique de jointure. Remarque : n’utilisez le filtre sqlsafe qu’avec précaution, car il permet aux collaborateurs d’introduire du code SQL pur dans le modèle.

Notez que cette fonction remplace tout modèle existant portant le même nom. Si vous souhaitez mettre à jour un modèle existant, il vous suffit de rappeler cette fonction avec le modèle mis à jour.

Ce modèle enrichit d’abord les données du fournisseur avec un hachage d’une série de colonnes de la table du fournisseur. Ces données enrichies sont ensuite intégrées à l’ensemble de données du consommateur sur l’e-mail, avec une clause de filtrage facultative. Enfin, l’UDF Python group_agg est utilisée pour calculer une agrégation en fonction des colonnes hachées de la première UDF.

call samooha_by_snowflake_local_db.provider.add_custom_sql_template(
    $cleanroom_name, 
    'prod_custom_udf_template', 
    $$
with enriched_provider_data as (
    select 
        cleanroom.assign_group(array_construct(identifier({{ filter_column | column_policy }}), identifier({{ dimensions[0] | column_policy }})), identifier({{ measure_column[0] | column_policy }})) as groupid,
        {{ filter_column | sqlsafe }},
        hem
    from identifier({{ source_table[0] }}) p
), filtered_data as (
    select 
        groupid,
        identifier({{ filter_column | column_policy }})
    from enriched_provider_data p
    inner join identifier({{ my_table[0] }}) c
    on p.hem = c.hem
    {% if where_clause %}
    where {{ where_clause | sqlsafe }}
    {% endif %}
)
select groupid, cleanroom.group_agg(array_agg({{ filter_column | sqlsafe }})) as count from filtered_data p
group by groupid;
    $$
);

Si vous voulez voir les modèles qui sont actuellement actifs dans la salle blanche, appelez la procédure suivante.

call samooha_by_snowflake_local_db.provider.view_added_templates($cleanroom_name);

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, agréger (par exemple SUM/AVG) et généralement utiliser dans une analyse pour chaque combinaison de table 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 code de région, le nombre de jours d’activité, etc.

Notez que 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.

call samooha_by_snowflake_local_db.provider.set_column_policy($cleanroom_name, [
    'prod_custom_udf_template:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS', 
    'prod_custom_udf_template:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:REGION_CODE',
    'prod_custom_udf_template:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:AGE_BAND',
    'prod_custom_udf_template:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:DAYS_ACTIVE']);

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);

Partager avec un consommateur¶

Enfin, ajoutez un consommateur de données à la salle blanche en ajoutant son localisateur de compte Snowflake et ses noms de compte, comme indiqué ci-dessous. Le nom du compte Snowflake doit être de la forme suivante : <ORGANIZATION>.<ACCOUNT_NAME>.

show versions in application package samooha_cleanroom_Custom_Secure_Python_UDF_Demo_clean_room;

call samooha_by_snowflake_local_db.provider.add_consumers($cleanroom_name, '<CONSMUMER_ACCOUNT_LOCATOR>');

Plusieurs localisateurs de comptes de consommateurs peuvent être transmis à la fonction provider.add_consumers sous la forme d’une chaîne séparée par des virgules ou sous la forme d’appels distincts à provider.add_consumers.

Si vous souhaitez voir les consommateurs qui ont été ajoutés à cette salle blanche, appelez la procédure suivante.

call samooha_by_snowflake_local_db.provider.view_consumers($cleanroom_name);

Afficher les salles blanches qui ont été récemment créées en suivant la procédure suivante :

call samooha_by_snowflake_local_db.provider.view_cleanrooms();

Afficher plus en détail la salle blanche récemment créée via la procédure suivante.

call samooha_by_snowflake_local_db.provider.describe_cleanroom($cleanroom_name);

Toute salle blanche créée peut également être supprimée. La commande suivante supprime entièrement la salle blanche, de sorte que les consommateurs qui avaient auparavant accès à la salle blanche ne pourront plus l’utiliser. Si une salle blanche portant le même nom est souhaitée à l’avenir, elle doit être réinitialisée à l’aide du flux ci-dessus.

call samooha_by_snowflake_local_db.provider.drop_cleanroom($cleanroom_name);

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 = 'Custom Secure Python UDF 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.

Cette procédure dure environ 45 secondes.

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¶

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, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']);

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.

Le nombre d’ensembles de données transmissibles est limité par le modèle que le fournisseur a mis en œuvre. Certains modèles requièrent un nombre spécifique de tables. Le créateur du modèle peut mettre en œuvre les exigences qu’il souhaite prendre en charge.

call samooha_by_snowflake_local_db.consumer.run_analysis(
  $cleanroom_name,               -- cleanroom
  'prod_custom_udf_template',    -- template name

  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'],    -- consumer tables

  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'],     -- provider tables

  object_construct(    -- Rest of the custom arguments needed for the template
    'filter_column', 'p.status',            -- One of the SQL Jinja arguments, the column the UDF filters on

    'dimensions', ['p.DAYS_ACTIVE'],
    
    'measure_column', ['p.AGE_BAND'],

    'where_clause', 'c.status = $$GOLD$$'   -- A boolean filter applied to the data
  )
);

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 montrera 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.

call samooha_by_snowflake_local_db.consumer.view_template_definition($cleanroom_name, 'prod_custom_udf_template');

Celui-ci peut souvent contenir un grand nombre de paramètres Jinja SQL différents. La fonctionnalité suivante analyse le modèle SQL Jinja et extrait les arguments qui doivent être spécifiés dans run_analysis dans une liste pratique.

call samooha_by_snowflake_local_db.consumer.get_arguments_from_template($cleanroom_name, 'prod_custom_udf_template');

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);

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 colonne 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);