Référence d’un modèle de salle blanche personnalisé

À propos des modèles de clean rooms

Clean room templates are written in JinjaSQL. JinjaSQL is an extension to the Jinja templating language that generates a SQL query as output. This allows templates to use logic statements and run-time variable resolution to let the user specify table names, table columns, and custom values used in the query at run time.

Snowflake provides some pre-designed templates for common use cases. However, most users prefer to create custom query templates for their clean rooms. Custom templates are created using the clean rooms API, but can be run either in code or using the clean rooms UI.

Il existe deux types généraux de modèles :

  • Analysis templates, which evaluate to a SELECT statement (or a set of SELECT operations) that show results to the template runner.

  • Activation templates, which are used to activate results to a Snowflake account or a third-party, rather than showing results in the immediate environment. An activation template is very similar to an analysis template with a few extra requirements.

    In the clean rooms UI, an analysis template can be associated with an activation template to enable the caller to run an analysis, see results, and then activate data to themselves or a third party. The activation template does not need to resolve to the same query as the associated analysis template.

Création et exécution d’un modèle personnalisé

In a clean room with default settings, the provider adds a template to a clean room and the consumer runs the template, as described in the custom template usage documentation.

Un exemple rapide

Voici un exemple simple de SQL qui joint une table de fournisseurs et une table de consommateurs par courriel et affiche le nombre de chevauchements par ville :

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

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

Notes sur le modèle :

  • Les valeurs contenues dans {{ double bracket pairs }} sont des variables personnalisées. group_by_col les valeurs de my_table, source_table, consumer_join_col, provider_join_col et group_by_col sont toutes des variables personnalisées renseignées par l’appelant.

  • source_table et my_table sont des variables de type tableau de chaînes définies par Snowflake et renseignées par l’appelant. Les membres du tableau sont les noms pleinement qualifiés des tables de fournisseurs et de consommateurs liées à la clean room. L’appelant spécifie les tables à inclure dans chaque tableau.

  • 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 est nécessaire pour tous les noms de colonnes et de tables, car les variables dans {{ double brackets }} évaluent des chaînes littérales, qui ne sont pas des identificateurs valides.

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

Tous ces points seront examinés en détail ultérieurement.

Voici comment un consommateur pourrait exécuter ce modèle dans le code. Notez que les noms de colonnes sont qualifiés par les alias de table déclarés dans le modèle.

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

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.

Développement d’un modèle personnalisé

Les modèles de salle blanche sont des modèles JinjaSQL. Pour créer un modèle, vous devez connaître les rubriques suivantes :

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.

Exemple :

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

Le modèle rendu ressemble à ceci :

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;

Essayez d’exécuter l’instruction SQL ci-dessus dans votre environnement pour voir si cela fonctionne et permet d’obtenir les résultats attendus.

Testez ensuite votre modèle sans clause 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']
));
Copy

Modèle renvoyé :

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
  ;

Ajoutez les filtres de la politique au modèle, et ajoutez le modèle à votre salle blanche :

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 %};
    $$,
);
Copy

Protection des données

Les modèles ne peuvent accéder qu’aux ensembles de données liés à la clean room par le fournisseur et le consommateur.

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.

Syntaxe des modèles personnalisés

Snowflake Data Clean Rooms prend en charge la version 3 du site JinjaSQL, avec quelques extensions comme indiqué.

Cette section comprend les rubriques suivantes :

Règles de dénomination des modèles

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.

Exemples de noms valides :

  • my_template

  • activation_template_1

Exemple de noms non valides :

  • my template - Espaces non autorisés

  • My_Template - Seuls les modèles en minuscules sont autorisés

Variables de modèles

Les appelants d’un modèle peuvent transmettre des valeurs aux variables du modèle. La syntaxe JinjaSQL permet la liaison de variables pour n’importe quel nom de variable dans {{ double_brackets }}, mais Snowflake réserve quelques noms de variables que vous ne devez pas remplacer, comme décrit ci-dessous.

Prudence

Toutes les variables, qu’elles soient définies par Snowflake ou personnalisées, sont renseignées par l’utilisateur et doivent être traitées avec la prudence qui s’impose. Les modèles de Snowflake Data Clean Rooms doivent se résoudre en une seule instruction SELECT, mais vous devez toujours vous rappeler que toutes les variables sont transmises par l’appelant.

Variables définies par Snowflake

Tous les modèles de clean room ont accès aux variables globales suivantes, définies par Snowflake, mais transmises par l’appelant :

source_table:

Un tableau de chaînes de caractères indexé à partir de zéro, listant les tables et vues liées au fournisseur dans la clean room, utilisables par le modèle. Les noms de tables sont entièrement qualifiés, par exemple : my_db.my_sch.provider_customers

Exemple : SELECT col1 FROM IDENTIFIER({{ source_table[0] }}) AS p;

my_table:

Tableau (string) basé sur zéro des tables et vues consommateurs de la clean room qui peuvent être utilisées par le modèle. Les noms de tables sont entièrement qualifiés, par exemple : my_db.my_sch.consumer_customers

Exemple : SELECT col1 FROM IDENTIFIER({{ my_table[0] }}) AS c;

privacy:

A set of privacy-related values associated with users and templates. See the list of available child fields. These values can be set explicitly for the user, but you might want to set default values in the template. Access the child fields directly in your template, such as privacy.threshold.

Exemple : Voici un exemple de modèle qui utilise threshold_value pour imposer une taille de groupe minimale dans une clause d’agrégation.

SELECT
  IFF(a.overlap > ( {{ privacy.threshold_value | default(2)  | sqlsafe }} ),
                    a.overlap,1 ) AS overlap,
  c.total_count AS total_count
  ...
Copy
measure_column:

dimensions:

where_clause:

Legacy clean room global variables. They are no longer recommended for use, but are still defined and appear in some legacy templates and documentation, so you should not alias tables or columns using either of these names to avoid naming collisions.

Si votre modèle utilise measure_column ou dimensions, la politique de colonne est vérifiée par rapport à toutes les colonnes transmises dans ces variables.

Si votre modèle utilise une where_clause qui a une condition de jointure (par exemple, table1.column1 = table2.column2), la politique de jointure est vérifiée par rapport à toutes les colonnes qui y sont nommées ; sinon, la politique de colonnes est vérifiée par rapport à toutes les colonnes qui y sont nommées.

Variables personnalisées

Les créateurs de modèles peuvent inclure des variables arbitraires dans un modèle qui peuvent être renseignées par l’appelant. Ces variables peuvent avoir n’importe quel nom arbitraire conforme Jinja, à l’exception des variables définies par Snowflake ou des noms d’alias de table. Si vous souhaitez que votre modèle soit utilisable dans l’UI des salles blanches, vous devez également fournir un formulaire d’UI pour les utilisateurs de l’UI des salles blanches. Vous devez fournir une bonne documentation pour les variables obligatoires et facultatives aux utilisateurs de l’API.

Les variables personnalisées sont accessibles par votre modèle, comme indiqué ici pour la variable personnalisée max_income:

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

Les utilisateurs peuvent transmettre des variables à un modèle de deux manières différentes :

  • Dans l’UI des salles blanches, en sélectionnant ou en fournissant des valeurs via un formulaire UI créé par le développeur du modèle. Ce formulaire d’UI contient des éléments de formulaire dans lesquels l’utilisateur peut fournir des valeurs pour votre modèle. Le nom de chaque élément de formulaire est le nom d’une variable. Le modèle utilise simplement le nom de l’élément de formulaire pour accéder à la valeur. Créez le formulaire UI en utilisant provider.add_ui_form_customizations.

  • Dans le code, un consommateur appelle consumer.run_analysis et transmet les noms des tables sous forme de tableaux d’arguments et les variables personnalisées sous forme de paires nom-valeur dans l’argument analysis_arguments.

Note

If you need to access user-provided values in any custom Python code uploaded to the clean room, you must explicitly pass variable values in to the code through Python function arguments; template variables are not directly accessible within the Python code using {{jinja variable binding syntax}}.

Résoudre correctement les variables

Les valeurs de chaîne passées dans le modèle se traduisent par une chaîne littérale dans le modèle final. Cela peut provoquer des erreurs d’analyse SQL ou des erreurs logiques si vous ne gérez pas les variables de liaison de manière appropriée :

  • SELECT {{ my_col }} FROM P; - This resolves to SELECT 'my_col' from P; which simply returns the string « my_col » - probably not what you want.

  • SELECT age FROM {{ my_table[0] }} AS P; - This resolves to SELECT age FROM 'somedb.somesch.my_table' AS P;, which causes a parsing error because a table must be an identifier, not a literal string.

  • SELECT age FROM IDENTIFIER({{ my_table[0] }}) AS P {{ where_clause }}; - Passing in « WHERE age < 50 » evaluates to SELECT age FROM mytable AS P 'WHERE age < 50';, which is a parsing error because of the literal string WHERE clause.

Par conséquent, le cas échéant, vous devez résoudre les variables. Voici comment résoudre correctement les variables dans votre modèle :

Resolving table and column names

Les variables qui spécifient des noms de tables ou de colonnes doivent être converties en identificateurs dans votre modèle de l’une des deux manières suivantes :

  • IDENTIFIER: Par exemple : SELECT IDENTIFIER({{ my_column }}) FROM P ;

  • sqlsafe: Ce filtre JinjaSQL résout les chaînes d’identificateurs en texte SQL. Une instruction équivalente au point précédent est SELECT {{ my_column | sqlsafe }} FROM P ;

Votre utilisation particulière dicte quand utiliser IDENTIFIER ou sqlsafe. Par exemple, c.{{ my_column | sqlsafe }} ne peut pas être facilement réécrit en utilisant IDENTIFIER.

Resolving dynamic SQL

Lorsque vous avez une variable chaîne qui doit être utilisée comme littéral SQL, telle qu’une clause WHERE, utilisez le filtre sqlsafe dans votre modèle. Par exemple :

SELECT age FROM IDENTIFIER({{ my_table[0] }}) AS C WHERE {{ where_clause }};
Copy

Si un utilisateur introduit « age < 50 » dans where_clause, la requête aboutira à SELECT age FROM sometable AS C WHERE 'age < 50';, qui n’est pas valide SQL en raison de la condition relative à la chaîne littérale WHERE. Dans ce casse-tête, vous devez utiliser le filtre sqlsafe:

SELECT age FROM IDENTIFIER( {{ my_table[0] }} ) as c {{ where_clause | sqlsafe }};
Copy

Alias de table requis

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

Exemple

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

Custom clean room template filters

Snowflake prend en charge tous les filtres standard Jinja et la plupart des filtres JinjaSQL standard, ainsi que quelques extensions :

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

  • column_policy : Réussit si la colonne figure dans la politique de colonne du propriétaire des données ; échoue dans le cas contraire.

  • activation_policy : Réussit si la colonne se trouve dans la politique d’activation du propriétaire des données ; échoue dans le cas contraire.

  • join_and_column_policy : Réussit si la colonne figure dans la politique de jointure ou de colonne du propriétaire des données ; échoue dans le cas contraire.

  • Le filtre identifier JinjaSQL n’est pas supporté par les modèles Snowflake.

Astuce

L’évaluation des expressions JinjaSQL s’effectue de gauche à droite :

  • {{ my_col | column_policy }} Correct

  • {{ my_col | sqlsafe | column_policy }} Correct

  • {{ column_policy | my_col }} Incorrect

  • {{ my_col | column_policy | sqlsafe }} Incorrect : column_policy sera vérifié par rapport à la valeur de my_col en tant que chaîne, ce qui est une erreur.

Appliquer les politiques des clean rooms

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

Les politiques ne sont vérifiées qu’en fonction des colonnes appartenant à d’autres collaborateurs. Les politiques ne sont pas vérifiées pour vos propres données.

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.

Exécution de code Python personnalisé

Les modèles peuvent exécuter le code Python téléchargé dans la clean room. Le modèle peut appeler une fonction Python qui accepte les valeurs d’une ligne de données et renvoie des valeurs à utiliser ou à projeter dans la requête.

  • Lorsqu’un fournisseur télécharge du code Python personnalisé dans une salle blanche, le modèle appelle des fonctions Python avec la syntaxe cleanroom.function_name. Plus de détails ici.

  • Lorsqu’un consommateur télécharge du code Python personnalisé dans une salle blanche, le modèle appelle la fonction avec la valeur function_name de base transmise à consumer.generate_python_request_template (non limité à cleanroom comme l’est le code du fournisseur). Plus de détails ici.

Exemple de code fournisseur :

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

Remarques relatives à la sécurité

A clean room template is not executed with the identity of the current user.

L’utilisateur n’a pas d’accès direct aux données de la clean room ; tout l’accès se fait par l’application native via les résultats du modèle.

Appliquez un filtre de politiques chaque fois qu’une colonne est utilisée dans votre modèle pour garantir que vos politiques, et les politiques de tous les collaborateurs, sont respectées.

Entourez les variables fournies par l’utilisateur de IDENTIFIER() lorsque cela est possible pour renforcer vos modèles contre les attaques par injection de SQL.

Modèles d’activation

Un modèle peut également être utilisé pour enregistrer les résultats de la requête dans une table située à l’extérieur de la clean room ; il s’agit de l’activation. Actuellement, les seules formes d’activation supportées pour les modèles personnalisés sont l’activation du fournisseur et l’activation du consommateur (stockage des résultats sur le compte Snowflake du fournisseur ou du consommateur, respectivement). Découvrez comment mettre en œuvre l’activation.

Un modèle d’activation est un modèle d’analyse auquel s’ajoutent les exigences suivantes :

  • Les modèles d’activation sont des instructions JinjaSQL qui évaluent un bloc de script SQL, contrairement aux modèles d’analyse, qui peuvent être de simples instructions SELECT.

  • Les modèles d’activation créent une table dans la salle blanche pour stocker les résultats, et renvoient le nom de la table (ou un fragment du nom) à l’appelant du modèle.

  • Le bloc de script doit se terminer par une instruction RETURN qui renvoie le nom de la table générée, sans le préfixe cleanroom. ou cleanroom.activation_data_.

  • Le nom du modèle, le nom de la table interne créée par le modèle et le nom de la table renvoyée par le modèle suivent ces modèles :

Activation type

Template name prefix

Préfixe de nom de table

Returned table name

Consommateur exécuté par le consommateur

activation_

cleanroom.activation_data_*

Nom de table sans préfixe

Fournisseur exécuté par le consommateur

Aucun préfixe requis

cleanroom.activation_data_*

Nom de table sans préfixe

Fournisseur exécuté par le fournisseur

activation_

cleanroom.temp_result_data est le nom complet de la table.

temp_result_data

  • Toute colonne activée doit être listée dans la politique d’activation du fournisseur ou du consommateur qui a lié les données, et le filtre activation_policy doit lui être appliqué. Notez qu’une colonne peut être à la fois une colonne d’activation et une colonne de jointure.

  • Si le modèle doit être exécuté à partir de l’UI des salles blanches , vous devriez fournir un formulaire Web qui comprend les champs activation_template_name et enabled_activations. Les modèles à utiliser dans l’UI doivent disposer à la fois d’un modèle d’analyse et d’un modèle d’activation associé.

  • Toutes les colonnes calculées doivent être explicitement aliasées, plutôt que d’avoir des noms déduits, parce qu’une table est générée. C’est-à-dire :

    SELECT COUNT(*), p.status from T AS P; FAILS, because the COUNT column name is inferred.

    SELECT COUNT(*) AS COUNT_OF_ITEMS, p.status from T AS P; SUCCEEDS, because it explicitly aliases the COUNT column.

Voici deux échantillons de modèles d’activation de base. L’une concerne l’activation du serveur géré par le fournisseur, l’autre les autres types d’activation. Elles se distinguent par les deux lignes surlignées, qui contiennent le nom de la table de résultats.

La table doit être nommée cleanroom.temp_result_data :

BEGIN
  CREATE OR REPLACE TABLE cleanroom.temp_result_data AS
    SELECT COUNT(c.status) AS ITEM_COUNT, c.status, c.age_band
      FROM IDENTIFIER({{ my_table[0] }}) AS c
    JOIN IDENTIFIER({{ source_table[0] }}) AS p
      ON {{ c_join_col | sqlsafe | activation_policy }} = {{ p_join_col | sqlsafe | activation_policy }}
    GROUP BY c.status, c.age_band
    ORDER BY c.age_band;
  RETURN 'temp_result_data';
END;
Copy

Prochaines étapes

Une fois que vous aurez maîtrisé le système de création de modèles, lisez les détails relatifs à la mise en place d’une clean room avec votre type de modèle :

  • Les modèles du fournisseur sont des modèles rédigés par le fournisseur. Il s’agit du cas d’utilisation par défaut.

  • Les modèles du consommateur sont des modèles créés par le consommateur. Dans certains cas, un créateur de salle blanche souhaite permettre au consommateur de créer, de télécharger et d’exécuter ses propres modèles dans la salle blanche.

  • Les modèles d’activation créent une table de résultats après une exécution réussie. En fonction du modèle d’activation, la table des résultats peut être soit enregistrée sur le compte du fournisseur ou du consommateur en dehors de la clean room, soit envoyée à un fournisseur d’activation tiers répertorié dans le hub d’activation.

  • Les modèles enchaînés vous permettent d’enchaîner plusieurs modèles où la sortie de chaque modèle est utilisée par le modèle suivant dans la chaîne.

Plus d’informations