Snowflake Data Clean Rooms: salas limpas de múltiplos provedores¶

Este tópico fornece um exemplo de execução de uma análise em um cluster de salas limpas de vários provedores. Ele demonstra como uma consulta pode acessar dados em salas limpas, mantendo as garantias de segurança de cada sala limpa. Ele também demonstra como o consumidor pode definir o modelo usado para executar a análise, o que é um caso de uso comum para salas limpas de vários provedores.

Em uma análise de vários provedores, os dados de cada sala limpa são usados de maneira completamente segura. As Snowflake Data Clean Rooms garantem conformidade com cada política de segurança de sala limpa individual, ao mesmo tempo em que assegura que todo código SQL executado nos dados seja exatamente o que cada participante da sala limpa espera.

Em muitos casos, o consumidor que executa uma análise de vários provedores deseja poder definir o modelo para a análise em vez de usar um modelo definido pelos provedores. Isso permite que os consumidores controlem como obtêm insights ao analisar dados de diversas partes. Para obter mais informações sobre modelos definidos pelo consumidor, consulte Uso da API do desenvolvedor para adicionar modelos definidos pelo consumidor.

Nota

Análises de vários provedores de salas limpas não são permitidas em salas limpas compartilhadas entre regiões.

O exemplo de análise de vários provedores inclui as seguintes etapas:

Provedor:

a. Crie duas salas limpas, que simulem dois provedores diferentes.

b. Compartilhe as salas limpas com o mesmo consumidor.
Consumidor:

a. Instale salas limpas de ambos provedores.

b. Envie solicitações para adicionar um modelo definido pelo consumidor às salas limpas.
Provedor:

a. Aprove as solicitações do consumidor para adicionar um modelo definido pelo consumidor.

b. Defina políticas de coluna para o modelo definido pelo consumidor.
Consumidor:

a. Faça a solicitação de análise multiprovedor.
Provedor:

a. Habilite as salas limpas para análise de vários provedores.

b. Aprove as solicitações de análise de vários provedores do consumidor.
Consumidor

a. Execute a análise no cluster da sala limpa.

Pré-requisitos¶

Você precisa de duas contas Snowflake separadas para concluir este exemplo. Use a primeira conta para executar os comandos do provedor e alterne para a segunda conta para executar os comandos do consumidor.

Consumidor: instalação de salas limpas¶

Use uma planilha Snowflake na conta do consumidor para executar os comandos nesta seção.

Como consumidor, você pode ter várias salas limpas compartilhadas com você. Antes de executar uma análise de vários provedores em todos eles, você precisa instalar cada um em sua conta e vincular os conjuntos de dados que pretende usar para análises.

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;

Copy

Instalação de salas limpas¶

Antes de instalar as salas limpas, atribua um nome para cada sala limpa que o provedor tenha compartilhado com você.

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

Copy

Os comandos a seguir instalam as salas limpas na conta do consumidor:

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

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

Copy

Após a instalação da sala limpa, o provedor precisa terminar de configurá-la do seu lado antes que ela seja habilitada para uso. A função abaixo permite que você verifique o status da sala limpa. Depois que ela for habilitada, você poderá executar o comando Run Analysis abaixo. Normalmente, leva cerca de 1 minuto para que a sala limpa seja habilitada.

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

Copy

Após a instalação de um compartilhamento de sala limpa, a lista de salas limpas disponíveis pode ser visualizada usando o comando abaixo.

CALL samooha_by_snowflake_local_db.consumer.view_cleanrooms();

Copy

Vincule o conjunto de dados¶

Vincule conjuntos de dados à sala limpa para realizar cálculos seguros com os dados do provedor.

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

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

Copy

Nota

Se esta etapa não funcionar mesmo que sua tabela exista, o banco de dados com a tabela pode não estar registrado. Para registrar o banco de dados, execute os seguintes comandos como um usuário com a função ACCOUNTADMIN.

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

Copy

Se quiser visualizar os conjuntos de dados que adicionou à sala limpa, chame o procedimento a seguir.

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

Copy

Consumidor: envio de solicitação para adicionar modelo definido pelo consumidor para limpar salas¶

O consumidor que executa uma análise de vários provedores geralmente está na melhor posição para saber como extrair valor dos dados de várias partes. Um consumidor pode enviar uma solicitação aos provedores de salas limpas para incluir um modelo definido pelo consumidor na sala limpa para que o consumidor possa usá-lo para executar análises. Para obter mais informações sobre como adicionar modelos definidos pelo consumidor a uma sala limpa, consulte Adição de modelos definidos pelo consumidor.

Nota

As análises em salas limpas com vários provedores funcionam renderizando todas as tabelas de outras salas limpas, bem como da sala limpa atual, no argumento source_tables do modelo. No entanto, durante as validações de segurança e aprovação de solicitação, cada sala limpa também recebe apenas as tabelas relevantes a ela. Portanto, o modelo deve ser escrito genericamente, sem assumir um número específico de argumentos source_table, o que permite que ele seja dimensionado para uma ou mais entradas source_table. Você pode usar um for-loop Jinja para implementar isso.

Neste exemplo, o consumidor envia as seguintes solicitações. Cada solicitação inclui o código Jinja que define o modelo.

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

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

Copy

Provedor: aprovação de solicitação do consumidor para adicionar modelo¶

O provedor deve aprovar as solicitações do consumidor para incluir um modelo definido pelo consumidor nas salas limpas.

O provedor usa o comando provedor provider.list_template_requests para listar as solicitações, incluindo a obtenção do UUID da nova solicitação. O provedor então aprova as solicitações executando o comando provider.approve_template_request. Para obter mais informações sobre esse processo, consulte Adição de modelos definidos pelo consumidor.

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


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

Copy

Definição da política de coluna em cada tabela¶

Para cada combinação de tabela e modelo, defina as colunas que o consumidor pode usar em uma análise, por exemplo, as colunas nas quais ele pode agrupar ou agregar. Isso proporciona flexibilidade para que a mesma tabela possa permitir diferentes seleções de coluna dependendo do modelo subjacente. Aguarde até adicionar um modelo para definir a política de coluna em uma tabela.

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.

As políticas de coluna não devem ser usadas em colunas de identidade como e-mail, HEM ou RampID porque você não quer que o consumidor consiga agrupar por essas colunas. No ambiente de produção, o Snowflake infere colunas PII e bloqueia esta operação, mas esta inferência não está disponível em um ambiente sandbox. Ele só deve ser usado em colunas que você deseja que o consumidor possa agregar e agrupar, por exemplo, Status, Faixa etária, Código de região ou Dias ativos.

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.

Para definir a política de coluna para uma combinação de modelo/tabela, execute os seguintes comandos:

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

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

Copy

Consumidor: solicitação de análise de sala limpa de vários provedores¶

O próximo passo é solicitar uma análise de vários provedores em todo o conjunto de salas limpas que você instalou. Este conjunto de salas limpas é conhecido como cluster de salas limpas. Este processo escreve solicitações para cada provedor perguntando se essa análise de vários provedores pode ser aprovada e executada. Essas solicitações são processadas de forma assíncrona pelo provedor usando um fluxo automatizado ou manual. Se um fluxo de aprovação automatizado for usado, o processamento da solicitação será feito em cerca de 2 minutos e, se a aprovação for dada por cada sala limpa (após verificar a solicitação quanto à conformidade com as políticas de segurança da sala limpa), o fluxo poderá ser executado.

O fluxo de solicitação de sala limpa de vários provedores exige que as tabelas de provedores sejam especificadas no argumento de matriz source_table. As tabelas precisam começar com o nome da sala limpa na qual elas existem. A forma geral é <CLEANROOM_NAME>.<DB>.<SCHEMA>.<TABLE>. Tabelas de consumidores podem ser fornecidas sob o argumento de matriz my_table.

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

Copy

Essa API primeiro verifica a solicitação com as políticas de segurança de cada sala limpa antes de enviar a solicitação de análise de vários provedores ao provedor de cada sala limpa. Se essas verificações falharem, essa API retornará a mensagem de erro encontrada.

Como determinar as entradas para prepare_multiprovider_flow¶

Para executar a análise, você precisa passar alguns parâmetros à função run_analysis. Esta seção mostra como determinar quais parâmetros passar.

Nomes dos modelos

Primeiro, você pode ver os modelos de análise compatíveis executando o seguinte comando:

CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name);

Copy

Antes de executar uma análise com um modelo, você precisa saber quais argumentos especificar e quais tipos são esperados. Para modelos personalizados, você pode executar o seguinte comando:

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

Copy

Isso retorna um grande número de diferentes parâmetros SQL Jinja. Para analisar o modelo SQL Jinja e extrair os argumentos que precisam ser especificados em run_analysis em uma lista, execute o seguinte comando.

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

Copy

Nomes dos conjuntos de dados

Se quiser visualizar os nomes dos conjuntos de dados adicionados à sala limpa pelo provedor, execute o seguinte comando. Observe que você não pode visualizar os dados presentes nos conjuntos de dados adicionados à sala limpa pelo provedor.

CALL samooha_by_snowflake_local_db.consumer.view_provider_datasets($cleanroom_name);

Copy

Você também pode ver as tabelas vinculadas à sala limpa executando o seguinte comando:

CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name);

Copy

Colunas de dimensão e medida

Ao executar a análise, você pode querer filtrar, agrupar e agregar em determinadas colunas. Se quiser visualizar a política de coluna adicionada à sala limpa pelo provedor, execute o seguinte comando:

CALL samooha_by_snowflake_local_db.consumer.view_provider_column_policy($cleanroom_name);

Copy

Erros comuns

Se estiver recebendo o erro Não aprovado: colunas não autorizadas em uso como resultado da análise de execução, tente visualizar a política de junção e a política de coluna definidas pelo provedor.

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

Também é possível que você tenha esgotado seu orçamento de privacidade, o que o impedirá de executar mais consultas. Seu orçamento de privacidade restante pode ser visualizado usando o seguinte comando. O orçamento é redefinido diariamente, ou o provedor de sala limpa pode redefini-lo manualmente.

CALL samooha_by_snowflake_local_db.consumer.view_remaining_privacy_budget($cleanroom_name);

Copy

Você pode verificar se a privacidade diferencial foi habilitada para sua sala limpa usando a seguinte API:

CALL samooha_by_snowflake_local_db.consumer.is_dp_enabled($cleanroom_name);

Copy

Provedor: Habilitação de análise de vários provedores e aprovação de solicitações¶

Agora você está retornando para a conta do provedor para habilitar a análise de vários provedores para o consumidor e processar as solicitações geradas.

Habilitação de salas limpas para análise de vários provedores¶

Um consumidor não pode executar com sucesso uma análise de vários provedores até que você habilite a sala limpa para essa finalidade. Ao habilitar a sala limpa para o consumidor, você também especifica quais salas limpas podem ser inclusas na análise de vários provedores. O consumidor não pode executar uma análise de vários provedores que envolva sua sala limpa e a sala limpa de outro provedor, a menos que você aprove expressamente a sala limpa do outro provedor.

Para permitir que um consumidor execute uma análise de vários provedores usando uma sala limpa de qualquer outro provedor, especifique uma lista vazia ao executar os comandos a seguir.

Nota

Isso só pode ser exigido de consumidores que já instalaram a sala limpa.

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

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

Copy

Aprovação de solicitações de análise de vários provedores¶

Após a análise de vários provedores ter sido habilitada em cada sala limpa, todas as solicitações de análise de vários provedores feitas em relação às salas limpas podem ser visualizadas usando a seguinte API:

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

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

Copy

A aprovação de solicitação pode ocorrer de duas maneiras:

Usando automaticamente uma tarefa que escuta solicitações recebidas e aciona quando necessário.
Manualmente por um usuário processando explicitamente solicitações de análise de vários provedores recebidas.

Por padrão, as aprovações são manuais e a tarefa é criada em um estado suspenso pela API enable_multiprovider_computation. Isso exige que o usuário processe manualmente as solicitações recebidas. Isso pode ser feito executando os seguintes comandos:

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

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

Copy

Nota

Essa API pode ser feita para operar ao nível do ID de solicitação especificando um ID de solicitação da saída da API view_multiprovider_requests, ou REQUEST_ID pode ser passado como “-1” para processar todas as solicitações recebidas.

Este processo não aprova solicitações recebidas, mas as passa por uma lógica de processamento para verificar se podem ser aprovadas com base em fatores como idade da solicitação e se os colaboradores solicitados estão em sua lista de colaboradores aprovados que você definiu durante enable_multiprovider_computation.

Uma vez que a solicitação tenha sido processada, ela é gravada na tabela samooha_cleanroom_${UUID}.admin.request_log_multiprovider. Você pode ver a lista de solicitações e se elas foram aprovadas ou não por meio de consultas como as seguintes:

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

Copy

Solicitações anteriores que não foram aprovadas também podem ser substituídas por APPROVE=True, ou, inversamente, o acesso pode ser removido configurando APPROVE=False usando as seguintes consultas. Consulte a seção Considerações de segurança abaixo para obter mais detalhes sobre <CONDITIONS>.

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

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

Copy

Se o fluxo de aprovação automatizado for preferido às aprovações manuais, as tarefas de análise de vários provedores precisarão ser retomadas executando os seguintes comandos:

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

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

Copy

Por outro lado, se o fluxo de aprovação automatizado estiver ativado no momento, ele poderá ser desativado executando os seguintes comandos:

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

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

Copy

Considerações de segurança: Gerenciamento de solicitações de análise de vários provedores¶

As análises multiprovedor funcionam adicionando o hash de uma consulta aprovada a uma política de acesso a linhas. A política de acesso a linhas geralmente é criada no esquema samooha_cleanroom_${UUID}.shared_schema, e a definição da política de acesso a linhas é:

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

Copy

A política de acesso a linhas funciona localizando solicitações aprovadas na tabela samooha_cleanroom_${UUID}.admin.request_log_multiprovider em sua conta para o consumidor específico de sala limpa e verificando se o hash da consulta atual em execução na conta corresponde à consulta aprovada.

Todo acesso de segurança aos seus dados para fluxos de vários provedores é controlado por meio das aprovações observadas nesta tabela (samooha_cleanroom_${UUID}.admin.request_log_multiprovider). Você deve gerenciá-lo proativamente para garantir que somente as consultas que você deseja que tenham acesso aos seus dados possam ser executadas.

Consultas simples podem ser usadas para aprovar ou desaprovar (ou seja, remover as aprovações de) solicitações processadas anteriormente. Por exemplo, você pode executar as seguintes consultas:

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

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

Copy

Conforme visto na política de acesso a linhas, o acesso aos dados é concedido dependendo de query_hash. No entanto, o query_hash também pode depender de qual sala limpa é selecionada aleatoriamente para executar a consulta, então o <CONDITIONS> passado na consulta acima para determinar quais solicitações revogar/aprovar acesso precisam seguir estas práticas recomendadas:

Se aprovar manualmente uma solicitação, tente ser o mais específico possível sobre a solicitação, filtrando por request_id e/ou cleanroom_names, requester_account e template_name.
Se revogar uma aprovação anterior para uma consulta, revogue todas as solicitações correspondentes com query_hash, e também revogue todas as solicitações para os requester_account, template_name e cleanroom_names (consulte o exemplo abaixo).
Se uma nova solicitação não for aprovada, isso não altera a aprovação de solicitações anteriores. Se você deseja revogar o acesso à consulta anterior, você precisa marcar as solicitações correspondentes com APPROVED=False na tabela samooha_cleanroom_${UUID}.admin.request_log_multiprovider.
Se você alterar o conjunto de colaboradores permitidos executando enable_multiprovider_computation novamente, as solicitações anteriores não são revogadas por padrão. Você precisa gerenciar aprovações revogando o acesso a colaborações anteriores definindo APPROVED=False na tabela samooha_cleanroom_${UUID}.admin.request_log_multiprovider.

Um exemplo de como revogar completamente a capacidade de uma colaboração específica de fazer solicitações. Suponha que houvesse uma colaboração em andamento requester_account=ABC123 que você queria revogar. Você pode executar as seguintes consultas:

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

Copy

O acesso tanto para o hash da consulta quanto para esse modelo nessa colaboração de sala limpa é revogado.

Aqui estão alguns exemplos de consultas que permitem que você veja quantas consultas foram feitas por cada conta de solicitante:

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

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

Copy

Consumidor – Executar solicitação¶

Uma vez que a solicitação gerada pela API prepare_multiprovider_flow tenha sido aprovada, ela pode ser executada usando a seguinte API em todo o cluster de salas limpas. Essa execução acontece quando uma sala limpa é selecionada aleatoriamente para executar o fluxo e, desde que ambas as salas limpas tenham aprovado a solicitação, a análise de vários provedores pode prosseguir.

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

Copy

Observe também que, depois que uma solicitação for aprovada após o procedimento prepare_multiprovider_flow, o execute_multiprovider_flow poderá ser chamado quantas vezes forem necessárias sem precisar chamar prepare_multiprovider_flow novamente. Entretanto, para executar uma análise diferente ou em um cluster de sala limpa diferente, o prepare_multiprovider_flow precisa ser chamado novamente.

Funções úteis¶

Depois que as solicitações de interoperabilidade são gravadas para cada provedor, a aprovação assume a forma de modelos de clientes específicos da solicitação que são adicionados à sala limpa e executados durante a análise. Eles configuram a infraestrutura necessária. Você pode visualizar esses modelos sendo adicionados em tempo real pelo processo de aprovação da solicitação executando os seguintes comandos.

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

Copy

Snowflake Data Clean Rooms: salas limpas de múltiplos provedores¶

Pré-requisitos¶

Provedor: Crie e compartilhe uma sala limpa¶

Configuração do ambiente¶

Crie a sala limpa¶

Vincule o conjunto de dados¶

Defina a política de junção para o conjunto de dados¶

Compartilhamento com um consumidor¶

Consumidor: instalação de salas limpas¶

Configuração do ambiente¶

Instalação de salas limpas¶

Vincule o conjunto de dados¶

Consumidor: envio de solicitação para adicionar modelo definido pelo consumidor para limpar salas¶

Provedor: aprovação de solicitação do consumidor para adicionar modelo¶

Definição da política de coluna em cada tabela¶

Consumidor: solicitação de análise de sala limpa de vários provedores¶

Como determinar as entradas para prepare_multiprovider_flow¶

Provedor: Habilitação de análise de vários provedores e aprovação de solicitações¶

Habilitação de salas limpas para análise de vários provedores¶

Aprovação de solicitações de análise de vários provedores¶

Considerações de segurança: Gerenciamento de solicitações de análise de vários provedores¶

Consumidor – Executar solicitação¶

Funções úteis¶