Snowflake Data Clean Rooms: Registre um modelo da API de desenvolvedor no aplicativo da web¶
Este tópico descreve como um provedor pode criar e compartilhar programaticamente uma sala limpa com um consumidor, ao mesmo tempo em que fornece uma interface de usuário que o consumidor pode usar para executar uma análise no aplicativo da Web. É semelhante ao [fluxo de aprendizado de máquina] (machine-learning), mas demonstra como fornecer ao consumidor uma interface de usuário para um fluxo de trabalho de aprendizado de máquina complexo. Após o provedor registrar a sala limpa no aplicativo da Web, o consumidor não precisa usar o Snowsight ou as APIs de desenvolvedor, permitindo que consumidores não técnicos utilizem uma sala limpa personalizada e complexa.
Um provedor pode registrar vários modelos personalizados para uma sala limpa, cada um dos quais aparecerá no aplicativo da web para o consumidor. O provedor simplesmente chama as APIs relacionadas diversas vezes.
Este fluxo inclui o seguinte:
Provedor:
a. Como adicionar um modelo personalizado executando uma análise de modelagem semelhante.
b. Como adicionar de forma segura modelos baseados em código Python de aprendizado de máquina aproveitando o XGBoost.
c. Chamada de UDFs de aprendizado de máquina dentro da sala limpa usando o modelo personalizado.
d. Cadastre a sala limpa no aplicativo da Web com um formulário de UI personalizado.
Consumidor:
a. Use o aplicativo da Web para instalar a sala limpa e executar análises nela.
Nota
A modelagem semelhante é um tipo de análise no qual um consumidor tenta encontrar clientes de “alto valor” a partir dos dados de um provedor, treinando um modelo estatístico em seus clientes de alto valor. Este modelo usa sinalizadores especificados pelo consumidor para indicar usuários de alto valor, como aqueles com gastos acima de um certo limite, no conjunto de dados do consumidor. O modelo treinado é então usado para inferir quais clientes nos dados do provedor podem ser potencialmente de “alto valor” para o consumidor.
Pré-requisitos¶
Você precisa de duas contas Snowflake separadas para concluir este fluxo. Use a primeira conta para executar os comandos do provedor e alterne para a segunda conta para executar os comandos do consumidor.
Provedor¶
Use uma planilha Snowflake na conta de provedor para executar os comandos nesta seção.
Configuração do ambiente¶
Antes de usar as APIs de desenvolvedor, você precisa assumir a função SAMOOHA_APP_ROLE e especificar o warehouse usado para executar as APIs. Se você não tem a função SAMOOHA_APP_ROLE, entre em contato com o administrador da sua conta.
Execute os seguintes comandos para configurar seu ambiente:
USE ROLE samooha_app_role;
USE WAREHOUSE app_wh;
Crie a sala limpa¶
Antes de criar uma sala limpa, você precisa especificar um nome alfanumérico para ela. O nome não pode conter caracteres especiais, exceto espaços e sublinhados. Certifique-se de que o nome da sala limpa não duplique uma sala limpa existente.
Para especificar o nome da sala limpa, execute o seguinte comando:
SET cleanroom_name = 'UI Registration ML Clean room';
Agora você está pronto para executar o comando provider.cleanroom_init e criar a sala limpa. O segundo argumento define a distribuição da sala limpa. Para este exemplo, você definirá isso como INTERNAL para ignorar a verificação de segurança automatizada que ocorre antes que a sala limpa possa ser liberada aos colaboradores. As contas do provedor e do consumidor devem estar na mesma organização para usar o método de distribuição INTERNAL. Para salas limpas distribuídas para uma conta em uma organização diferente, você deve usar uma distribuição EXTERNAL.
Para criar a sala limpa, execute o seguinte comando:
CALL samooha_by_snowflake_local_db.provider.cleanroom_init($cleanroom_name, 'INTERNAL');
Após criar uma sala limpa, você deve definir sua diretiva de liberação antes que ela possa ser compartilhada com um colaborador.
Nota
Quando você define a distribuição de uma sala limpa para EXTERNAL, você deve aguardar a conclusão da verificação de segurança antes de definir a diretiva de lançamento. Você pode visualizar o status da verificação de segurança executando:
CALL samooha_by_snowflake_local_db.provider.view_cleanroom_scan_status($cleanroom_name);
Você pode continuar executando comandos durante a verificação de segurança, desde que defina a diretiva de lançamento antes de tentar executar o comando provider.create_cleanroom_listing.
Para definir a diretiva de lançamento para a sala limpa, execute o seguinte comando:
CALL samooha_by_snowflake_local_db.provider.set_default_release_directive($cleanroom_name, 'V1_0', '0');
Compartilhamento entre regiões¶
Para compartilhar uma sala limpa com um cliente Snowflake cuja conta está em uma região diferente da sua conta, você deve habilitar o Preenchimento automático entre nuvens. Para obter mais informações sobre os custos adicionais associados à colaboração com consumidores em outras regiões, consulte Custos de preenchimento automático entre nuvens.
Ao usar as APIs de desenvolvedor, o processo para habilitar o compartilhamento entre regiões ocorre em duas etapas.
Um administrador Snowflake com a função ACCOUNTADMIN habilita o preenchimento automático entre nuvens para sua conta Snowflake. Para obter instruções, consulte Colaboração com contas em diferentes regiões.
Execute o comando provider.enable_laf_for_cleanroom para habilitar o preenchimento automático entre nuvens para a sala limpa. Por exemplo:
CALL samooha_by_snowflake_local_db.provider.enable_laf_for_cleanroom($cleanroom_name);
Após habilitar o preenchimento automático entre nuvens para a sala limpa, você pode adicionar consumidores à sua listagem normalmente usando o comando provider.create_cleanroom_listing. A listagem é replicada automaticamente para nuvens e regiões remotas, conforme necessário.
Vincule o conjunto de dados e defina a política de junção para o conjunto de dados¶
Vincule as tabelas do Snowflake à sala limpa, navegue pela lista de tabelas em sua conta Snowflake e insira os nomes de tabela totalmente qualificados (Database.Schema.Table) como uma matriz. O procedimento torna a tabela automaticamente acessível à sala limpa, criando uma exibição segura da tabela de dentro da sala limpa, evitando assim a necessidade de fazer uma cópia da tabela.
CALL samooha_by_snowflake_local_db.provider.link_datasets($cleanroom_name, ['samooha_provider_sample_database.lookalike_modeling.customers']);
Nota
Se esta etapa não funcionar mesmo que sua tabela exista, é provável que a função SAMOOHA_APP_ROLE ainda não tenha recebido acesso a ela. Se esse for o caso, mude para a função ACCOUNTADMIN, chame o procedimento abaixo no banco de dados e reverta para o restante do fluxo:
USE ROLE accountadmin;
CALL samooha_by_snowflake_local_db.provider.register_db('<DATABASE_NAME>');
USE ROLE samooha_app_role;
Você pode visualizar os nomes dos conjuntos de dados vinculados à sala limpa chamando o procedimento a seguir.
CALL samooha_by_snowflake_local_db.provider.view_provider_datasets($cleanroom_name);
Você pode ver os conjuntos de dados vinculados à sala limpa usando o seguinte procedimento:
SELECT * FROM <PROVIDER_TABLE> LIMIT 10;
Especifique em quais colunas o consumidor tem permissão para unir ao executar modelos na sala limpa. Este procedimento deve ser chamado em colunas de identidade como e-mail. A política de junção é “somente substituição”, portanto, se a função for chamada novamente, a política de junção definida anteriormente será completamente substituída pela nova.
CALL samooha_by_snowflake_local_db.provider.set_join_policy($cleanroom_name, ['samooha_provider_sample_database.lookalike_modeling.customers:hashed_email']);
Se quiser visualizar todas as colunas para escolher as colunas de política de junção, chame o procedimento a seguir.
CALL samooha_by_snowflake_local_db.provider.view_join_policy($cleanroom_name);
Como adicionar código Python confidencial de aprendizado de máquina à sala limpa¶
Carregue algumas funções Python para a sala limpa para o trabalho de ML semelhante. Todas as funções Python instaladas na sala limpa permanecem completamente confidenciais. Elas não podem ser vistas pelo consumidor.
A API a seguir permite definir suas funções Python diretamente como funções em linha na sala limpa. Como alternativa, você pode carregar o código Python a partir de arquivos preparados que você enviou para o estágio da sala limpa. Consulte o Guia de referência da API para um exemplo.
Nota
Observe que esta implementação é limitada pela restrição do tamanho total do Snowflake na quantidade de dados que podem ser agregados por ARRAY_AGG (ou seja 16MB). Uma implementação que aproveita modelos de processamento em lote e streaming, que podem ser dimensionados para conjuntos de dados de tamanho arbitrário usando processamento em lote, está disponível mediante solicitação.
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"])
}
$$);
Agora instale uma função de pontuação na sala limpa:
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)
$$);
Nota
Carregar o código Python na sala limpa cria um novo patch para a sala limpa. Se a distribuição de sua sala limpa estiver definida como EXTERNAL, você precisa aguardar a conclusão da verificação de segurança e, em seguida, atualizar a diretiva de liberação padrão usando:
-- See the versions available inside the cleanroom
SHOW VERSIONS IN APPLICATION PACKAGE samooha_cleanroom_UI_Registration_ML_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');
Como adicionar um modelo de modelagem semelhante personalizado¶
Para adicionar um modelo de análise personalizado à sala limpa, você precisa de um espaço reservado para nomes de tabelas no lado do provedor e do consumidor, juntamente com colunas de junção do lado do provedor. Nos modelos SQL Jinja, esses espaços reservados devem ser sempre:
source_table: uma matriz de nomes de tabela do provedor
my_table: uma matriz de nomes de tabela do consumidor
Os nomes de tabela podem ser tornados dinâmicos por meio do uso dessas variáveis, mas também podem ser embutidos em código no modelo, se desejado, usando o nome da exibição vinculada à sala limpa. Os nomes das colunas podem ser embutidos em código no modelo, se desejado, ou definidos dinamicamente por meio de parâmetros. Se eles forem definidos por meio de parâmetros, lembre-se de que você precisa chamar os parâmetros dimensions ou measure_column, que precisam ser matrizes para que sejam verificados em relação à política de coluna. Você adiciona estes como parâmetros SQL Jinja no modelo que serão passados posteriormente pelo consumidor durante a consulta. As políticas de junção garantem que o consumidor não possa ingressar em colunas não autorizadas.
Alternativamente, qualquer argumento em um modelo SQL Jinja personalizado pode ser verificado quanto à conformidade com as políticas de junção e coluna usando os seguintes filtros:
join_policy: verifica se um valor de cadeia de caracteres ou cláusula de filtro está em conformidade com a política de junção
column_policy: verifica se um valor de cadeia de caracteres ou cláusula de filtro está em conformidade com a política de coluna
join_and_column_policy: verifica se as colunas usadas para uma junção em uma cláusula de filtro estão em conformidade com a política de junção e se as colunas usadas como um filtro estão em conformidade com a política de coluna
Por exemplo, na cláusula {{ provider_id | sqlsafe | join_policy }}, uma entrada de p.HEM será analisada para verificar se p.HEM está na política de junção. Nota: Use o filtro sqlsafe com cautela, pois ele permite que os colaboradores coloquem SQL puro no modelo.
Nota
Todas as tabelas de provedores/consumidores devem ser referenciadas usando esses argumentos, pois o nome da exibição segura realmente vinculada à sala limpa será diferente do nome da tabela. Os aliases de tabela de provedores DEVEM ser obrigatoriamente p (ou p1), p2, p3, p4 etc., e os aliases da tabela do consumidor devem ser c (ou c1), c2, c3 etc. Isso é necessário para aplicar políticas de segurança na sala limpa.
Observe que esta função substitui qualquer modelo existente com o mesmo nome. Se quiser atualizar qualquer modelo existente, basta chamar esta função novamente com o modelo atualizado.
Um conjunto de recursos é selecionado do conjunto de dados do provedor e um conjunto de rótulos é selecionado do conjunto de dados do consumidor, juntamente com um sinalizador de “alto valor” (chamado label_value). Essas duas tabelas são então unidas internamente por e-mail e passadas ao algoritmo de treinamento de floresta aleatória. Por fim, a saída da etapa de treinamento do modelo é passada para uma função de inferência, que usa o modelo treinado para “inferir” quais clientes do provedor que NOT estão nos conjuntos de dados do consumidor poderiam ser de “alto valor”. A contagem desses indivíduos é então retornada, juntamente com o erro do modelo.
O limite para determinar a pontuação além da qual um cliente é “provavelmente de alto valor” é definido manualmente no modelo como 0,5. Isso pode ser facilmente alterado ao adicionar o modelo à sala limpa.
CALL samooha_by_snowflake_local_db.provider.add_custom_sql_template($cleanroom_name, 'prod_custom_lookalike_template',
$$
WITH
features AS (
SELECT
identifier({{ provider_join_col | join_policy }}) AS joincol,
array_construct({{ dimensions[0] | sqlsafe }} {% for feat in dimensions[1:] %} , {{ feat | sqlsafe }} {% endfor %}) AS features
FROM
identifier({{ source_table[0] }}) AS p
),
labels AS (
SELECT
c.{{ consumer_join_col | sqlsafe }} AS joincol,
c.{{ filter_column | default('SALES_DLR') | sqlsafe }} {{ operator | default('>=') | sqlsafe }} {{ filter_value | default(2000) | sqlsafe }} 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_function | default('lookalike_train') | sqlsafe }}(array_agg(f.features), array_agg(l.label_value)) AS train_out
FROM features f, labels l
WHERE f.joincol = l.joincol
)
),
inference_output AS (
SELECT
MOD(seq4(), 100) AS batch,
cleanroom.{{ lookalike_score_function | default('lookalike_score') | sqlsafe }}(
array_agg(distinct t.model),
array_agg(identifier({{ provider_join_col | join_policy }})),
array_agg(array_construct( identifier({{ dimensions[0] }}) {% for feat in dimensions[1:] %} , identifier({{ feat }}) {% endfor %}) )
) AS scores
FROM trained_model t, identifier({{ source_table[0] }}) p
WHERE identifier({{ provider_join_col | join_policy }}) NOT IN (SELECT c.{{ consumer_join_col | sqlsafe }} FROM identifier({{ my_table[0] }}) c)
GROUP BY batch
),
processed_output AS (
SELECT value:email::string as id, value:score::float AS score FROM (select scores from inference_output), lateral flatten(input => parse_json(scores))
), train_results AS (
SELECT {{ num_boosting_rounds | sqlsafe }} AS num_boosting_rounds, {{ trim_extremes | sqlsafe }} AS trim_extremes, p.audience_size AS audience_size, t.error AS error FROM (SELECT count(distinct id) AS audience_size FROM processed_output WHERE score > 0.5) p, trained_model t
), seed_size AS (
select count(*) AS seed_audience_size FROM features f, labels l WHERE f.joincol = l.joincol
)
SELECT s.seed_audience_size, t.audience_size AS num_lookalikes_found, t.error FROM train_results t, seed_size s
$$);
Nota
Você pode adicionar sensibilidade de privacidade diferencial à chamada de procedimento samooha_by_snowflake_local_db.provider.add_custom_sql_template acima como o último parâmetro. Se você não a adicionar, o padrão será 1.
Se quiser visualizar os modelos atualmente ativos na sala limpa, chame o procedimento a seguir. Você pode fazer modificações para habilitar garantias de privacidade diferencial em sua análise. Um padrão semelhante pode ser incorporado em qualquer modelo personalizado que você escolher escrever.
CALL samooha_by_snowflake_local_db.provider.view_added_templates($cleanroom_name);
Definição da política de coluna em cada tabela¶
Visualize os dados vinculados para ver as colunas presentes na tabela. Para exibir as 10 primeiras linhas, chame o procedimento a seguir.
SELECT * FROM <PROVIDER_TABLE> LIMIT 10;
Defina as colunas nas quais deseja agrupar, agregar (por exemplo SUM/AVG) e geralmente usa em uma análise para cada combinação de tabela e modelo. Isso proporciona flexibilidade para que a mesma tabela possa permitir diferentes seleções de coluna dependendo do modelo subjacente. Isso deve ser chamado somente após adicionar o modelo.
Observe que a política de coluna é somente substituição, portanto, se a função for chamada novamente, a política de coluna definida anteriormente será completamente substituída pela nova.
A política de coluna não deve ser usada em colunas de identidade como e-mail, HEM, RampID etc., já que você não quer que o consumidor seja capaz de agrupar por essas colunas. No ambiente de produção, o sistema irá inferir de forma inteligente as colunas PII e bloquear esta operação, mas esse recurso não está disponível no ambiente sandbox. Ele só deve ser usado em colunas que você deseja que o consumidor possa agregar e agrupar, como Status, Faixa etária, Código de região, Dias ativos etc.
Observe que para que “column_policy” e “join_policy” realizem verificações nas solicitações de análise do consumidor, todos os nomes de colunas DEVEM ser referidos como dimensions ou measure_columns no modelo SQL Jinja. Certifique-se de usar essas tags para se referir às colunas que deseja verificar nos modelos de SQL Jinja personalizados.
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'
]);
Se você quiser visualizar a política de coluna adicionada à sala limpa, chame o procedimento a seguir.
CALL samooha_by_snowflake_local_db.provider.view_column_policy($cleanroom_name);
Registre a sala limpa com o aplicativo da Web¶
Agora que a sala limpa foi compartilhada com o consumidor, você pode registrar o modelo personalizado para que ele fique disponível para o consumidor no aplicativo da Web. Isso significa que o consumidor pode executar análises personalizadas, incluindo aquelas apoiadas por código complexo de aprendizado de máquina, por meio de uma interface de usuário sem a necessidade de usar as APIs de desenvolvedor.
Registrar uma sala limpa para que o consumidor possa acessá-la no aplicativo da Web é um processo de três etapas. Você precisa fazer o seguinte:
Chame o comando provider.add_ui_form_customizations para definir como o modelo aparece no aplicativo da Web.
Chame o comando provider.register_cleanroom_in_ui para registrar o modelo.
Entre na Web como o provedor.
Criação de interface do usuário para o modelo¶
O comando provider.add_ui_form_customizations define como o modelo na sala limpa aparece no aplicativo da Web. Para uma descrição completa das personalizações que você pode usar para projetar a interface do usuário, consulte a seção Métodos de registro de UI de sala limpa da referência de API do provedor.
Nota
Você pode opcionalmente usar a personalização warehouse_hints
para controlar que tipo de warehouse a conta do consumidor usará para executar análises. Por exemplo, para a maioria dos casos de uso de aprendizado de máquina, a Snowflake recomenda especificar um warehouse otimizado para o Snowpark. Para valores válidos para warehouse_size
, consulte CREATE WAREHOUSE.
Para este exemplo, execute o comando provider.add_ui_form_customizations com as seguintes personalizações:
CALL samooha_by_snowflake_local_db.provider.add_ui_form_customizations(
$cleanroom_name,
'prod_custom_lookalike_template',
{
'display_name': 'Custom Lookalike Template',
'description': 'Use our customized ML techniques to find lookalike audiences.',
'methodology': 'Specify your own seed audience, while matching against our users. Then customize the lookalike model across number of boosting rounds and removing outliers.',
'warehouse_hints': {
'warehouse_size': 'medium',
'snowpark_optimized': TRUE
}
},
{
'num_boosting_rounds': {
'display_name': 'Number of Boosting Rounds',
'type': 'integer',
'default': 10,
'order': 7,
'description': 'How many rounds of boosting should the model do?',
'size': 'M',
'group': 'Training & Inference Configuration'
},
'trim_extremes': {
'display_name': 'Trim Extremes',
'type': 'boolean',
'default': False,
'order': 8,
'description': 'Remove outliers by default?',
'size': 'M',
'group': 'Training & Inference Configuration'
},
'lookalike_train_function': {
'display_name': 'Training Function',
'choices': ['lookalike_train'],
'type': 'dropdown',
'order': 9,
'description': 'Which function do you want to use for training?',
'size': 'M',
'group': 'Training & Inference Configuration'
},
'lookalike_score_function': {
'display_name': 'Scoring Function',
'choices': ['lookalike_score'],
'type': 'dropdown',
'order': 10,
'description': 'Which function do you want to use for scoring?',
'size': 'M',
'group': 'Training & Inference Configuration'
},
'provider_join_col': {
'display_name': 'Provider Join Column',
'choices': ['p.HASHED_EMAIL'],
'type': 'dropdown',
'order': 4,
'description': 'Select the provider column to join users on.',
'infoMessage': 'We recommend using HASHED_EMAIL.',
'size': 'M',
'group': 'Enable Provider Features'
},
'consumer_join_col': {
'display_name': 'Consumer Join Column',
'description': 'Specify column in your table that matches the providers (i.e. HASHED_EMAIL).',
'size': 'M',
'default': 'HASHED_EMAIL',
'infoMessage': 'We recommend using HASHED_EMAIL.',
'order': 5,
'group': 'Enable Provider Features'
},
'dimensions': {
'display_name': 'Feature Selection',
'choices': ['p.STATUS', 'p.AGE', 'p.REGION_CODE', 'p.DAYS_ACTIVE'],
'type': 'multiselect',
'order': 6,
'description': 'What features do you want to train on?',
'infoMessage': 'We recommend selecting all features for maximum signal.',
'size': 'M',
'group': 'Enable Provider Features'
},
'filter_column': {
'display_name': 'Filter Column',
'type': 'any',
'order': 1,
'description': 'Specify column in your table to filter for high value users (i.e. SALES_DLR)',
'size': 'S',
'default': 'SALES_DLR',
'infoMessage': 'We recommend you input SALES_DLR over here.',
'group': 'Seed Audience Selection'
},
'operator': {
'display_name': 'Operator',
'choices': ['>=', '=', '<='],
'type': 'dropdown',
'order': 2,
'description': 'What is the operator your want to use for the filter?',
'size': 'S',
'group': 'Seed Audience Selection'
},
'filter_value': {
'display_name': 'Filter Value',
'order': 3,
'description': 'What value do you want to filter to?',
'default': 2000,
'size': 'S',
'group': 'Seed Audience Selection'
}
}, {
'measure_columns': ['seed_audience_size', 'audience_size', 'num_lookalikes_found', 'error'],
'default_output_type': 'BAR'
});
Registro do modelo¶
Após definir a aparência do modelo no aplicativo da Web, execute o comando provider.register_cleanroom_in_ui para registrar o modelo para que ele fique disponível no ambiente de sala limpa do consumidor.
O comando provider.register_cleanroom_in_ui aceita os seguintes argumentos:
Nome da sala limpa.
Nome do modelo.
Conta de consumidor com quem a sala limpa está sendo compartilhada.
Endereço de e-mail de um usuário de aplicativo da Web no ambiente de sala limpa do consumidor. A Snowflake usa o endereço de e-mail para fins de verificação.
Nota
O comando provider.register_cleanroom_in_ui, diferentemente dos comandos provider.add_consumers e provider.create_cleanroom_listing, precisa do identificador completo da conta do consumidor, especificado no formato LOCATOR.REGION.CLOUD
. Para obter mais informações sobre como encontrar esse identificador de conta, consulte Como usar um localizador de conta como um identificador.
Alguns exemplos incluem:
ABC01234.us-west-2.aws
XYZ01234.us-east-1.aws
MNO01234.west-us-2.azure
Para registrar o modelo prod_custom_lookalike_template
que você criou neste exemplo, execute o seguinte comando:
CALL samooha_by_snowflake_local_db.provider.register_cleanroom_in_ui($cleanroom_name, 'prod_custom_lookalike_template', '<CONSUMER_ACCOUNT_IDENTIFIER>', '<CONSUMER_USER_EMAIL>');
Para revisar solicitações de registro anteriores, execute o seguinte comando:
CALL samooha_by_snowflake_local_db.provider.view_ui_registration_request_log();
Faça login no aplicativo da Web.¶
Após executar o comando provider.register_cleanroom_in_ui, o provedor precisa fazer login no aplicativo da Web para concluir o processo de registro. Até que você faça login no aplicativo da Web como provedor, a solicitação permanecerá no estado “PENDING”. Para fazer login no aplicativo da Web, consulte Snowflake Data Clean Room: aplicativo da Web.
Métodos auxiliares¶
Vários localizadores de contas de consumidores podem ser passados para a função provider.add_consumers como uma cadeia de caracteres separada por vírgulas ou como chamadas separadas para provider.add_consumers.
Se quiser visualizar os consumidores adicionados a esta sala limpa, chame o procedimento a seguir.
CALL samooha_by_snowflake_local_db.provider.view_consumers($cleanroom_name);
Se quiser visualizar as salas limpas criadas recentemente, use o seguinte procedimento.
CALL samooha_by_snowflake_local_db.provider.view_cleanrooms();
Se quiser obter mais informações sobre a sala limpa que criou, use o procedimento a seguir.
CALL samooha_by_snowflake_local_db.provider.describe_cleanroom($cleanroom_name);
Qualquer sala limpa criada também pode ser excluída. O comando a seguir descarta a sala limpa completamente, de modo que qualquer consumidor que antes tivesse acesso à sala não poderá mais usá-la. Se uma sala limpa com o mesmo nome for desejada no futuro, ela deverá ser reinicializada usando o fluxo acima.
CALL samooha_by_snowflake_local_db.provider.drop_cleanroom($cleanroom_name);
Fluxo do consumidor¶
A sala limpa que você acabou de criar como provedor agora está disponível no aplicativo da Web no ambiente de sala limpa do consumidor.
Nota
Você pode continuar modificando o formulário de UI na conta do provedor e, em seguida, ver as alterações no ambiente de sala limpa do consumidor em tempo real.
Acesse a conta do consumidor no aplicativo da Web¶
Para entrar na sala limpa como consumidor:
Entre no aplicativo da Web da Snowflake Data Clean Room. Para obter mais detalhes, consulte Snowflake Data Clean Room: aplicativo da Web.
Insira seu endereço de e-mail e selecione Continuar.
Insira sua senha.
Selecione a conta Snowflake associada à conta do consumidor.
Instalação da sala limpa¶
Na página Salas limpas, encontre o bloco que corresponde à sala limpa que você acabou de criar e selecione Instalar. O bloco pode ter a seguinte aparência:
Execute uma análise¶
Para executar uma análise na sala limpa:
Na página Análises e consultas, selecione Nova análise e consulta.
Selecione o bloco que corresponde ao modelo personalizado semelhante que você criou e selecione Avançar.
Selecione a sala limpa e depois Avançar.
Preencha o formulário personalizado que você criou para a sala limpa.