Snowflake Data Clean Rooms : Machine Learning

Cette rubrique décrit les flux de fournisseurs et de consommateurs nécessaires pour mettre en place de manière programmatique une salle blanche, la partager avec un consommateur et y exécuter des analyses par le biais d’algorithmes de machine learning avancés. Les flux de fournisseurs chargent dans la salle blanche un code Python sécurisé mettant en œuvre un algorithme de machine learning XGBoost basé sur une forêt d’arbres décisionnels. Cette information est totalement confidentielle et n’est visible que par le fournisseur. Le consommateur ne peut pas voir le code Python de machine learning chargé dans la salle blanche.

Ce flux couvre les éléments suivants :

  1. Fournisseur :

    a. Ajoutez un modèle personnalisé exécutant une analyse de modélisation Lookalike.

    b. Ajoutez en toute sécurité des modèles basés sur du code python de machine learning en tirant parti de XGBoost.

    c. Appelez des UDFs de machine learning à l’intérieur de la salle blanche à l’aide du modèle personnalisé.

  2. Consommateur :

    a. Exécutez le modèle personnalisé qui utilise les fonctions ML définies par le fournisseur.

La Modélisation Lookalike est un type d’analyse dans lequel un consommateur tente de trouver des clients « high value » à partir des données d’un fournisseur en entraînant un modèle statistique sur leurs clients à forte valeur (high value). Ce modèle utilise des indicateurs spécifiés par les consommateurs pour indiquer les utilisateurs à forte valeur (high value), tels que ceux dont les dépenses dépassent un certain seuil, dans l’ensemble de données du consommateur. Le modèle entraîné est ensuite utilisé pour déduire quels clients dans les données du fournisseur pourraient potentiellement être de type « high value » pour le consommateur.

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

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 = 'Machine Learning Demo Clean room';
Copy

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, ce processus échouera.

L’exécution de cette procédure peut prendre un peu plus de temps, généralement une demi-minute environ.

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

Pour voir le statut de l’analyse de sécurité, utilisez :

call samooha_by_snowflake_local_db.provider.view_cleanroom_scan_status($cleanroom_name);
Copy

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 et revenir ici avant l’étape provider.create_cleanroom_listing pendant que l’analyse s’exécute.

Pour définir la directive de version, appelez :

call samooha_by_snowflake_local_db.provider.set_default_release_directive($cleanroom_name, 'V1_0', '0');
Copy

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.

Ajouter du code Python confidentiel de machine learning à la salle blanche

Cette section vous montre comment charger quelques fonctions python dans la salle blanche pour des tâches de ML Lookalike. Toutes les fonctions python installées dans la salle blanche restent totalement confidentielles. Le consommateur ne peut pas les voir.

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.

Note

Notez que cette mise en œuvre est limitée par la contrainte de taille totale de Snowflake sur la quantité de données qui peuvent être agrégées par ARRAY_AGG (c’est-à-dire 16MB). Une mise en œuvre tirant parti de la mise en lots et des modèles de flux qui peut s’étendre à des ensembles de données de taille arbitraire grâce à la mise en lots est disponible sur demande.

call samooha_by_snowflake_local_db.provider.load_python_into_cleanroom(
    $cleanroom_name, 
    'lookalike_train',
    ['input_data variant', 'labels variant'],
    ['pandas', 'numpy', 'xgboost'],
    'variant',
    'train',
    $$
import numpy as np
import pandas as pd
import xgboost
from sklearn import preprocessing
import sys
import os
import pickle
import codecs
import threading


class TrainXGBoostClassifier(object):
    def __init__(self):
        self.model = None
        self._params = {
            "objective": "binary:logistic",
            "max_depth": 3,
            "nthread": 1,
            "eval_metric": "auc",
        }
        self.num_boosting_rounds = 10

    def get_params(self):
        if self.model is not None and "updater" not in self._params:
            self._params.update(
                {"process_type": "update", "updater": "refresh", "refresh_leaf": True}
            )
        return self._params

    def train(self, X, y):
        """
        Train the model in a threadsafe way
        """
        # pick only the categorical attributes
        categorical = X.select_dtypes(include=[object])

        # fit a one-hot-encoder to convert categorical features to binary features (required by XGBoost)
        ohe = preprocessing.OneHotEncoder()
        categorical_ohe = ohe.fit_transform(categorical)
        self.ohe = ohe

        # get the rest of the features and add them to the binary features
        non_categorical = X.select_dtypes(exclude=[object])
        train_x = np.concatenate((categorical_ohe.toarray(), non_categorical.to_numpy()), axis=1)

        xg_train = xgboost.DMatrix(train_x, label=y)

        params = self.get_params()
        params["eval_metric"] = "auc"
        evallist = [(xg_train, "train")]
        evals_result = {}

        self.model = xgboost.train(
            params, xg_train, self.num_boosting_rounds, evallist, evals_result=evals_result
        )

        self.evals_result = evals_result

    def __dump_model(self, model):
        """
        Save down the model as a json string to load up for scoring/inference
        """
        pickle_jar = codecs.encode(pickle.dumps([model, self.ohe]), "base64").decode()
        return pickle_jar

    def dump_model(self):
        """
        Save down the model as a json string to load up for scoring/inference
        """
        if self.model is not None:
            return self.__dump_model(self.model)
        else:
            raise ValueError("Model needs to be trained first")


def train(d1, l1):

    # get take training features and put them in a pandas dataframe
    X = pd.DataFrame(d1)

    # get the labels into a Numpy array
    y = np.array(l1)

    trainer = TrainXGBoostClassifier()
    trainer.train(X, y)

    # return training stats, accuracy, and the pickled model and pickled one-hot-encoder
    return {
        "total_rows": len(d1),
        "total_bytes_in": sys.getsizeof(d1),
        "model": trainer.dump_model(),
        "iteration": trainer.num_boosting_rounds,
        "auc": np.max(trainer.evals_result["train"]["auc"]),
        "error": 1 - np.max(trainer.evals_result["train"]["auc"])
    }    
    $$
);
Copy

Installons maintenant une fonction de notation dans la salle blanche

call samooha_by_snowflake_local_db.provider.load_python_into_cleanroom(
    $cleanroom_name, 
    'lookalike_score',
    ['pickle_jar variant', 'emails variant', 'features variant'],
    ['pandas', 'numpy', 'xgboost', 'scikit-learn'],
    'string',
    'score',
    $$
import numpy as np
import pandas as pd
import xgboost as xgb
import pickle
import codecs
import json


def score(model, emails, features):
    # load model
    model = model[0] if not isinstance(model, str) else model
    model = pickle.loads(codecs.decode(model.encode(), "base64"))

    # retrieve the XGBoost trainer from the pickle jar
    bst = model[0]

    # retrieve the fitted one-hot-encoder from the pickle jar
    ohe2 = model[1]

    # create pandas dataframe from the inference features
    Y = pd.DataFrame(features)

    # select the categorical attributes and one-hot-encode them
    Y1 = Y.select_dtypes(include=[object])
    Y2 = ohe2.transform(Y1)

    # select the non-categorical attributes
    Y3 = Y.select_dtypes(exclude=[object])

    # join the results of the one-hot encoding to the rest of the attributes
    Y_pred = np.concatenate((Y2.toarray(), Y3.to_numpy()), axis=1)

    # inference
    dscore = xgb.DMatrix(Y_pred)
    pred = bst.predict(dscore)

    retval = list(zip(np.array(emails), list(map(str, pred))))
    retval = [{"email": r[0], "score": r[1]} for r in retval]
    return json.dumps(retval)  
    $$
);
Copy

Note

Le chargement de Python dans la salle blanche crée un nouveau correctif pour la salle blanche. Si la distribution de votre salle blanche est définie sur EXTERNAL, vous devez attendre la fin de l’analyse de sécurité, puis mettre à jour la directive de version par défaut à l’aide de :

-- See the versions available inside the cleanroom
show versions in application package samooha_cleanroom_Machine_Learning_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');
Copy

Ajouter un modèle de modélisation Lookalike personnalisé

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.

Note

Il faut faire référence à toutes les tables fournisseur/consommateur en utilisant ces arguments, car le nom de la vue sécurisée effectivement liée à la salle blanche sera différent du nom de la table. Il est essentiel que les alias de table de fournisseurs doivent être p (ou p1), p2, p3, p4, etc., et que les alias de table de consommateurs doivent être c (ou c1), c2, c3, etc. Cela est nécessaire pour appliquer les politiques de sécurité dans la salle blanche.

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.

Un ensemble de fonctions est sélectionné dans l’ensemble de données du fournisseur et un ensemble d’étiquettes est sélectionné dans l’ensemble de données du consommateur, ainsi qu’un indicateur « high value » (appelé valeur_étiquette). Ces deux tables sont ensuite jointes sur l’e-mail et transmises à l’algorithme d’entraînement de la forêt d’arbres décisionnels. Enfin, le résultat de l’étape d’entraînement des modèles est transmis à une fonction d’inférence, qui utilise le modèle entraîné pour « déduire » lesquels des clients fournisseurs qui ne sont pas dans les ensembles de données consommateurs pourraient être de type « high value ». Le nombre de ces personnes est alors retourné, ainsi que l’erreur de modèle.

Le seuil permettant de déterminer le score au-delà duquel un client est « likely high value » est fixé manuellement dans le modèle à 0,5. Ceci peut être facilement modifié lors de l’ajout du modèle à la salle blanche.

call samooha_by_snowflake_local_db.provider.add_custom_sql_template(
    $cleanroom_name, 
    'prod_custom_lookalike_template', 
    $$
WITH
features AS (
    SELECT
        p.hashed_email,
        array_construct(identifier({{ dimensions[0] | column_policy }}) {% for feat in dimensions[1:] %} , identifier({{ feat | column_policy }}) {% endfor %}) as features
    FROM
        identifier({{ source_table[0] }}) as p
),
labels AS (
    SELECT
        c.hashed_email,
        {{ filter_clause | sqlsafe | column_policy }} as label_value
    FROM
        identifier({{ my_table[0] }}) as c
),
trained_model AS (
    SELECT
        train_out:model::varchar as model,
        train_out:error::float as error
    FROM (
      SELECT
        cleanroom.lookalike_train(array_agg(f.features), array_agg(l.label_value)) as train_out
      FROM features f, labels l
      WHERE f.hashed_email = l.hashed_email
    )
),
inference_output AS (
    SELECT
        MOD(seq4(), 100) as batch,
        cleanroom.lookalike_score(
            array_agg(distinct t.model), 
            array_agg(p.hashed_email), 
            array_agg(array_construct( identifier({{ dimensions[0] | column_policy }}) {% for feat in dimensions[1:] %} , identifier({{ feat | column_policy }}) {% endfor %}) )
        ) as scores
    FROM trained_model t, identifier({{ source_table[0] }}) p
    WHERE p.hashed_email NOT IN (SELECT c.hashed_email FROM identifier({{ my_table[0] }}) c)
    GROUP BY batch
),
processed_output AS (
    SELECT value:email::string as email, value:score::float as score FROM (select scores from inference_output), lateral flatten(input => parse_json(scores))
)
SELECT p.audience_size, t.error from (SELECT count(distinct email) as audience_size FROM processed_output WHERE score > 0.5) p, trained_model t;
    $$
);  
Copy

Note

Vous pouvez ajouter la sensibilité à la confidentialité différentielle à l’appel de procédure samooha_by_snowflake_local_db.provider.add_custom_sql_template ci-dessus en tant que dernier paramètre (si vous ne l’ajoutez pas, la valeur par défaut sera 1)

Si vous voulez voir les modèles qui sont actuellement actifs dans la salle blanche, appelez la procédure suivante. Vous pouvez apporter les modifications nécessaires 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.

call samooha_by_snowflake_local_db.provider.view_added_templates($cleanroom_name);
Copy

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_provider_sample_database.lookalike_modeling.customers limit 10;
Copy

Définissez les colonnes sur lesquelles vous souhaitez effectuer des regroupements, des agrégations (par exemple SUM/AVG) et, d’une manière générale, utiliser 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 différentes sélections de colonnes 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_lookalike_template:samooha_provider_sample_database.lookalike_modeling.customers:status', 
    'prod_custom_lookalike_template:samooha_provider_sample_database.lookalike_modeling.customers:age', 
    'prod_custom_lookalike_template:samooha_provider_sample_database.lookalike_modeling.customers:region_code', 
    'prod_custom_lookalike_template:samooha_provider_sample_database.lookalike_modeling.customers:days_active', 
    'prod_custom_lookalike_template:samooha_provider_sample_database.lookalike_modeling.customers:income_bracket', 
    'prod_custom_lookalike_template:samooha_provider_sample_database.lookalike_modeling.customers:household_size', 
    'prod_custom_lookalike_template:samooha_provider_sample_database.lookalike_modeling.customers:gender'
]);
Copy

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

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

Note

Afin d’appeler les procédures suivantes, assurez-vous d’avoir préalablement défini la directive de version à l’aide de provider.set_default_release_directive. Vous pouvez consulter la dernière version disponible et les correctifs en utilisant :

show versions in application package samooha_cleanroom_Machine_Learning_Demo_clean_room;
Copy
call samooha_by_snowflake_local_db.provider.add_consumers($cleanroom_name, '<CONSUMER_ACCOUNT_LOCATOR>', '<CONSUMER_ACCOUNT_NAME>');
call samooha_By_snowflake_local_db.provider.create_cleanroom_listing($cleanroom_name, '<CONSUMER_ACCOUNT_NAME>');
Copy

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

Si vous souhaitez voir les salles blanches qui ont été créées récemment, utilisez la procédure suivante.

call samooha_by_snowflake_local_db.provider.view_cleanrooms();
Copy

Si vous souhaitez obtenir plus d’informations sur la salle blanche que vous avez créée, suivez la procédure suivante.

call samooha_by_snowflake_local_db.provider.describe_cleanroom($cleanroom_name);
Copy

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

Note

Le flux de fournisseurs est maintenant terminé. Passez au compte du consommateur pour poursuivre le flux de consommateurs.

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

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

Attribuez un nom à la salle blanche que le fournisseur vous a partagée.

set cleanroom_name = 'Machine Learning Demo Clean room';
Copy

La commande suivante installe la salle blanche sur le compte du consommateur avec le fournisseur associé et la salle blanche sélectionnée.

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

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

Effectuer l’analyse

Maintenant que la salle blanche est installée, vous pouvez exécuter le modèle d’analyse ajouté à la salle blanche par le fournisseur à l’aide de la commande « run_analysis ». Vous pouvez voir comment chaque champ est déterminé dans la section ci-dessous.

Les utilisateurs « high value » sont identifiés par filter_clause dans la requête ci-dessous. Si c.SALES_DLR représente le montant des ventes par utilisateur, un filtre valide pourrait ressembler à c.HIGH_VALUE > 4000.

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.

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

    ['samooha_consumer_sample_database.lookalike_modeling.customers'],                -- consumer tables

    ['samooha_provider_sample_database.lookalike_modeling.customers'],                -- provider tables

    object_construct(                    -- Rest of the custom arguments needed for the template
        'dimensions', ['p.STATUS', 'p.AGE', 'p.REGION_CODE', 'p.DAYS_ACTIVE', 'p.INCOME_BRACKET'], -- Features used in training

        'filter_clause', 'c.SALES_DLR > 2000' -- Consumer flag for which customers are considered high value
    )
);
Copy

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);
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 les opérations suivantes.

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

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.

call samooha_by_snowflake_local_db.consumer.get_arguments_from_template($cleanroom_name, 'prod_custom_lookalike_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, 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);
Copy

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

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