Referência de modelo de sala limpa personalizado¶

Um exemplo rápido¶

Aqui está um exemplo simples de SQL que une uma tabela de provedor e uma tabela de consumidor por e-mail e mostra a contagem de sobreposições por cidade:

SELECT COUNT(*), city FROM consumer_table
  INNER consumer_table
  ON consumer_table.hashed_email = provider_table.hashed_email
  GROUP BY city;

Here is how that query would look as a JinjaSQL template that allows the caller to choose the JOIN and GROUP BY columns, as well as the tables used:

SELECT COUNT(*), IDENTIFIER({{ group_by_col | column_policy }})
  FROM IDENTIFIER({{ my_table[0] }}) AS c
  INNER JOIN IDENTIFIER({{ source_table[0] }}) AS p
  ON IDENTIFIER({{ consumer_join_col | join_policy }}) = IDENTIFIER({{ provider_join_col | join_policy }})
  GROUP BY IDENTIFIER({{ group_by_col | column_policy }});

Observações sobre o modelo:

• Os valores em {{ double bracket pairs }} são variáveis personalizadas. group_by_col, my_table, source_table, consumer_join_col, provider_join_col e group_by_col são variáveis personalizadas preenchidas pelo chamador.

• source_table e my_table são variáveis de matriz de cadeia de caracteres definidas pelo Snowflake e preenchidas pelo chamador. Os membros da matriz são nomes totalmente qualificados de tabelas de provedores e consumidores vinculadas à clean room. O chamador especifica quais tabelas devem ser incluídas em cada matriz.

• Provider tables must be aliased as lowercase p and consumer tables as lowercase c in a template. If you have multiple tables, you can index them as p1, p2, c1, c2, and so on.

• IDENTIFIER é necessário para todos os nomes de colunas e tabelas, pois as variáveis em {{ double brackets }} são avaliadas como literais de cadeia de caracteres, que não são identificadores válidos.

• JinjaSQL filters can be applied to variables to enforce any join or column policies set by either side. Snowflake implements custom filters join_policy and column_policy, which verify whether a column complies with join or column policies in the clean room respectively, and fail the query if it does not. A filter is applied to a column name as {{ column_name | filter_name }}.

Todos esses pontos serão discutidos em detalhes posteriormente.

Veja como um consumidor pode executar esse modelo no código. Observe como os nomes de colunas são qualificados pelos aliases de tabela declarados no modelo.

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.CONSUMER.RUN_ANALYSIS(
  $cleanroom_name,
  $template_name,
  ['my_db.my_sch.consumer_table],       -- Populates the my_table variable
  ['my_db.my_sch.provider_table'],      -- Populates the source_table variable
  OBJECT_CONSTRUCT(                     -- Populates custom named variables
    'consumer_join_col','c.age_band',
    'provider_join_col','p.age_band',
    'group_by_col','p.device_type'
  )
);

To be able to use this template in the clean rooms UI, the provider must create a custom UI form for the template. The UI form has named form elements that correspond to template variable names, and the values provided in the form are passed into the template.

Desenvolvimento de um modelo personalizado¶

Os modelos de sala limpa são modelos JinjaSQL. Para criar um modelo, você deve estar familiarizado com os seguintes tópicos:

• Jinja templating basics

• The JinjaSQL extension to Jinja.

Use the consumer.get_jinja_sql procedure to test the validity of your template, then run the rendered template to see that it produces the results that you expect. Note that this procedure doesn’t support clean room filter extensions, such as join_policy, so you must test your template without those filters, and add them later.

Exemplo:

-- Template to test
SELECT {{ col1 | sqlsafe }}, {{ col2 | sqlsafe }}
  FROM IDENTIFIER({{ source_table[0] }}) AS p
  JOIN IDENTIFIER({{ my_table[0] }}) AS c
  ON {{ provider_join_col | sqlsafe }} = {{ consumer_join_col | sqlsafe}}
  {% if where_phrase %} WHERE {{ where_phrase | sqlsafe}}{% endif %};

-- Render the template.
USE WAREHOUSE app_wh;
USE ROLE SAMOOHA_APP_ROLE;

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.CONSUMER.GET_SQL_JINJA(
$$
SELECT {{ col1 | sqlsafe }}, {{ col2 | sqlsafe }}
  FROM IDENTIFIER({{ source_table[0] }}) AS p
  JOIN IDENTIFIER({{ my_table[0] }}) AS c
  ON IDENTIFIER({{ provider_join_col }}) = IDENTIFIER({{ consumer_join_col }})
  {% if where_phrase %} WHERE {{ where_phrase | sqlsafe }}{% endif %};
  $$,
  object_construct(
'col1', 'c.status',
'col2', 'c.age_band',
'where_phrase', 'p.household_size > 2',
'consumer_join_col', 'c.age_band',
'provider_join_col', 'p.age_band',
'source_table', ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'],
'my_table', ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']
));

O modelo renderizado tem esta aparência:

SELECT c.status, c.age_band
  FROM IDENTIFIER('SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS') AS p
  JOIN IDENTIFIER('SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS') AS c
  ON p.age_band = c.age_band
  WHERE p.household_size > 2;

Tente executar a instrução SQL acima em seu ambiente para ver se ela funciona e retorna os resultados esperados.

Em seguida, teste seu modelo sem uma cláusula WHERE:

-- Render the template without a WHERE clause
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.CONSUMER.GET_SQL_JINJA(
$$
SELECT {{ col1 | sqlsafe }}, {{ col2 | sqlsafe }}
  FROM IDENTIFIER({{ source_table[0] }}) AS p
  JOIN IDENTIFIER({{ my_table[0] }}) AS c
  ON {{ provider_join_col | sqlsafe }} = {{ consumer_join_col | sqlsafe}}
  {% if where_phrase %} WHERE {{ where_phrase | sqlsafe }}{% endif %};
  $$,
  object_construct(
'col1', 'c.status',
'col2', 'c.age_band',
'consumer_join_col', 'c.age_band',
'provider_join_col', 'p.age_band',
'source_table', ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'],
'my_table', ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']
));

Modelo renderizado:

SELECT c.status, c.age_band
  FROM IDENTIFIER('SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS') AS p
  JOIN IDENTIFIER('SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS') AS c
  ON p.age_band = c.age_band
  ;

Adicione os filtros de política ao modelo e o modelo à sua sala limpa:

CALL samooha_by_snowflake_local_db.provider.add_custom_sql_template(
    $cleanroom_name,
    'simple_template',
    $$
    SELECT {{ col1 | sqlsafe | column_policy }}, {{ col2 | sqlsafe | column_policy }}
      FROM IDENTIFIER({{ source_table[0] }}) AS p
      JOIN IDENTIFIER({{ my_table[0] }}) AS c
      ON {{ provider_join_col | sqlsafe | join_policy }} = {{ consumer_join_col | sqlsafe | join_policy }}
      {% if where_phrase %} WHERE {{ where_phrase | sqlsafe }}{% endif %};
    $$,
);

Proteção de dados¶

Os modelos podem acessar apenas conjuntos de dados vinculados à clean room pelo provedor e pelo consumidor.

Both the provider and consumer can set join, column, and activation policies on their data to protect which columns can be joined on, projected, or activated; however, the template must include the appropriate JinjaSQL policy filter on a column for the policy to be applied.

Regras de nomeação de modelos¶

When creating a template, names must be all lowercase letters, numbers, spaces, or underscores. Activation templates (except for consumer-run provider activation) must have a name beginning with activation_. Template names are assigned when you call provider.add_custom_sql_template or consumer.create_template_request.

Exemplo de nomes válidos:

• my_template

• activation_template_1

Exemplo de nomes inválidos:

• my template – Espaços não permitidos

• My_Template – Somente modelos em letras minúsculas são permitidos

Variáveis de modelo¶

Os chamadores de modelo podem passar valores para variáveis de modelo. A sintaxe JinjaSQL permite a vinculação de variáveis para qualquer nome de variável em {{ double_brackets }}, mas o Snowflake reserva alguns nomes de variável que você não deve substituir, conforme descrito abaixo.

SELECT income FROM my_db.my_sch.customers WHERE income < {{ max_income }};

Aliases de tabela necessários¶

At the top level of your query, all tables or subqueries must be aliased as either p (for provider-tables) or c (for consumer tables) in order for Snowflake to validate join and column policies correctly in the query. Any column that must be verified against join or column policies must be qualified with the lowercase p or c table alias. (Specifying p or c tells the back end whether to validate a column against the provider or the consumer policy respectively.)

If you use multiple provider or consumer tables in your query, add a numeric, sequential 1-based suffix to each table alias after the first. So: p, p1, p2, and so on for the first, second, and third provider tables, and c, c1, c2, and so on for the first, second, and third consumer tables. The p or c index should be sequential without gaps (that is, create the aliases p, p1, and p2, not p, p2, and p4).

Exemplo

SELECT p.col1 FROM IDENTIFIER({{ source_table[0] }}) AS P
UNION
SELECT p1.col1 FROM IDENTIFIER({{ source_table[1] }}) AS P1;

Custom clean room template filters¶

O Snowflake é compatível com todos os filtros Jinja padrão e com a maioria dos filtros padrão JinjaSQL, além de algumas extensões:

• join_policy: Succeeds if the column is in the join policy of the data owner; fails otherwise.

• column_policy: com sucesso se a coluna estiver na política de coluna do proprietário dos dados; caso contrário, com falha.

• activation_policy: com sucesso se a coluna estiver na política de ativação do proprietário dos dados; caso contrário, com falha.

• join_and_column_policy: com sucesso se a coluna estiver na política de junção ou de coluna do proprietário dos dados; caso contrário, com falha.

• O filtro JinjaSQL identifier não é compatível com os modelos Snowflake.

Aplicação de políticas de clean room¶

Clean rooms do not automatically check clean room policies against columns used in a template. If you want to enforce a policy against a column:

• You must apply the appropriate policy filter to that column in the template. For example:

JOIN IDENTIFIER({{ source_table[0] }}) AS p
  ON IDENTIFIER({{ c_join_col | join_policy }}) = IDENTIFIER({{ p_join_col | join_policy }})

• Você deve definir o alias da tabela como p ou c em letras minúsculas. Consulte Aliases de tabela necessários.

As políticas são verificadas somente em relação às colunas de propriedade de outros colaboradores. Elas não são verificadas em seus próprios dados.

Note that column names cannot be ambiguous when testing policies. So if you have columns with the same name in two tables, you must qualify the column name in order to test the policy against that column.

Execução de código Python personalizado¶

Os modelos podem executar o código Python carregado na clean room. O modelo pode chamar uma função Python que aceita valores de uma linha de dados e retorna valores para serem usados ou projetados na consulta.

• Quando o provedor carrega um código Python personalizado em uma sala limpa, o modelo chama funções Python com a sintaxe cleanroom.function_name. Mais detalhes aqui.

• Quando o consumidor carrega um código Python personalizado em uma sala limpa, o modelo chama a função com o valor básico function_name passado para consumer.generate_python_request_template (sem escopo definido para cleanroom como acontece no código do provedor). Mais detalhes aqui.

Exemplo de código de provedor:

-- Provider uploads a Python function that takes two numbers and returns the sum.
CALL samooha_by_snowflake_local_db.provider.load_python_into_cleanroom(
  $cleanroom_name,
  'simple_addition',                        -- Function name to use in the template
  ['someval integer', 'added_val integer'], -- Arguments
  [],                                       -- No packages needed
  'integer',                                -- Return type
  'main',                                   -- Handler for function name
  $$

def main(input, added_val):
  return input + int(added_val)
    $$
);

-- Template passes value from each row to the function, along with a
-- caller-supplied argument named 'increment'
CALL samooha_by_snowflake_local_db.provider.add_custom_sql_template(
    $cleanroom_name,
    'simple_python_example',
$$
    SELECT val, cleanroom.simple_addition(val, {{ increment | sqlsafe }})
    FROM VALUES (5),(8),(12),(39) AS P(val);
$$
);