Entwerfen benutzerdefinierter Vorlagen

Über Clean Room-Vorlagen

Clean Room-Vorlagen werden in `JinjaSQL<https://github.com/sripathikrishnan/jinjasql>`_ geschrieben. JinjaSQL ist eine Erweiterung der Jinja-Vorlagensprache. Eine JinjaSQL-Vorlage ergibt eine SQL-Anweisung bei der Ausführung in einem Clean Room. Die JinjaSQL-Vorlagensprache bietet logische Anweisungen und das Ersetzen von Laufzeitvariablen, sodass die Vorlage zur Laufzeit angepasst werden kann. So kann ein Benutzer beispielsweise Tabellen- und Spaltennamen angeben, wenn er die Vorlage ausführt, und die Vorlage kann sich anhand der übergebenen Werte selbst anpassen.

Es gibt zwei allgemeine Vorlagentypen:

  • Analysevorlagen, die eine SQL DQL-Anweisung (eine SELECT-Anweisung) ergeben, die Abfrageergebnisse sofort an die Vorlagenausführung zurückgibt.

  • Aktivierungsvorlagen, die verwendet werden, um Ergebnisse für ein Snowflake-Konto zu aktivieren, anstatt die Ergebnisse in der unmittelbaren Umgebung anzuzeigen. Eine Aktivierungsvorlage ist einer Analysevorlage sehr ähnlich, mit einigen zusätzlichen Anforderungen, und ergibt eine DDL-Anweisung (CREATE TABLE).

Erstellen, Freigeben und Ausführen von benutzerdefinierten Vorlagen

Jeder Teilnehmer kann mit bestimmten Analyseausführenden in einer Collaboration Vorlagen registrieren und freigeben.

Beginnen wir mit einer einfachen SQL-Abfrage und wie sie als Vorlage geschrieben werden würde.

1. Die JinjaSQL-Vorlage

Hier ist eine einfache SQL-Abfrage, die zwei Tabellen per E-Mail verknüpft und die Anzahl der Überschneidungen pro Stadt anzeigt:

SELECT COUNT(*), city FROM table_1
  INNER JOIN table_2
  ON table_1.hashed_email = table_2.hashed_email
  GROUP BY city;

So würde diese Abfrage als JinjaSQL-Vorlage aussehen, die es dem Aufrufer ermöglicht, die JOIN- undGROUPBY- Spalten sowie die verwendeten Tabellen zu wählen. Die Vorlage enthält einige Filter, die :ref:` Snowflake Data Clean Room-Richtlinien<label-dcr_collaborations_policies>` erzwingen.

SELECT COUNT(*), IDENTIFIER({{ group_by_col | column_policy }})
  FROM IDENTIFIER({{ source_table[0] }}) AS p1
  INNER JOIN IDENTIFIER({{ source_table[1] }}) AS p2
  ON IDENTIFIER({{ p1_join_col | join_policy }}) = IDENTIFIER({{ p2_join_col | join_policy }})
  GROUP BY IDENTIFIER({{ group_by_col | column_policy }});

Anmerkungen zur Vorlage:

  • Werte innerhalb von {{doppelten Klammerpaaren}} sind Variablen. Die Werte werden vom Aufrufer gefüllt.

  • group_by_col, source_table,``p1_join_col`` und p2_join_col sind alle Variablen, die vom Aufrufer gefüllt werden. Diese Variablen haben beliebige Namen, die vom Vorlagendesigner gewählt wurden.

  • source_table ist eine von Snowflake definierte Standardvariable. Diese Variable definiert die in der Abfrage zu verwendenden Ansichten. Diese Ansichten sind Datensätze innerhalb von Datenangeboten, die mit dem Clean Room verknüpft sind. Teilnehmer können verfügbare Datasets auflisten, indem sie VIEW_DATA_OFFERINGS aufrufen.

  • Ein Datenset muss den Alias Kleinbuchstaben```p` verwenden, wenn Sie die Richtlinien von Snowflake Data Clean Room dafür durchsetzen möchten. Wenn eine Vorlage mehrere Datensets verwendet, ist das erste p oder p1 und zusätzliche Datensets werden als p2 ,``p3`` usw. indiziert.

  • IDENTIFIER wird für alle Spalten- und Tabellennamen benötigt, da Variablen in {{ double brackets }} als Zeichenfolgenliterale ausgewertet werden, die keine gültigen Bezeichner sind.

  • JinjaSQL-Filter werden auf Spalten angewendet, um Snowflake Data Clean Room-Richtlinien für die Spalte durchzusetzen. Snowflake implementiert die kundenspezifischen Filter join_policy und column_policy, die überprüfen, ob eine Spalte den Verknüpfungs- bzw. Spaltenrichtlinien im Clean Room entspricht, und die Abfrage fehlschlagen lässt, wenn dies nicht der Fall ist. Ein Filter wird auf einen Spaltennamen als {{ column_name | filter_name }} angewendet.

All diese Punkte werden wir später im Detail besprechen.

2. Die Collaboration-Vorlage

Eine Vorlage wird zu einer Collaboration hinzugefügt, indem sie in eine YAML-Spezifikation eingebettet und registriert wird und dann verknüpft wird.

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.REGISTRY.REGISTER_TEMPLATE(
  $$
  api_version: 2.0.0
  spec_type: template
  name: my_test_template
  version: 2026_01_12_V1
  type: sql_analysis
  description: A test template
  methodology: Join on single column with a single group by value
  parameters:
  - name: source_tables
    description: Tables from both sides which can be listed in any order, aliased with p1 or p2
    required: true
  - name: p1_join_col
    description: Column to join on from first table specified under source_tables, aliased with p1
    required: true
  - name: p2_join_col
    description: Column to join on from second table specified under source_tables, , aliased with p2
    required: true
  - name: group_by_col
    description: Column which results should be grouped group aliased with respective table p1 or p2
    required: true

  template:
    SELECT COUNT(*), IDENTIFIER({{ group_by_col | column_policy }})
    FROM IDENTIFIER({{ source_table[0] }}) AS p1
    INNER JOIN IDENTIFIER({{ source_table[1] }}) AS p2
    ON IDENTIFIER({{ p1_join_col | join_policy }}) = IDENTIFIER({{ p2_join_col | join_policy }})
    GROUP BY IDENTIFIER({{ group_by_col | column_policy }});

$$);

Sie müssen anfordern, dass eine Vorlage für einen bestimmten Analyseausführenden freigegeben werden soll, der die Anfrage annehmen oder ablehnen kann. Außerdem müssen alle Datenanbieter für diesen Analyseausführenden die Anfrage zur Freigabe der Vorlage akzeptieren.

-- Request to share template with only Collaborator3.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.ADD_TEMPLATE_REQUEST(
  $collaboration_name,
  $template_id,
  ['Collaborator3']
);

3. Ausführen der Vorlage

So könnte ein Analyseausführender diese Vorlage im Code ausführen. Beachten Sie, wie Spaltennamen durch die in der Vorlage deklarierten Tabellenaliasse qualifiziert werden.

CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.RUN( $collaboration_name,
$$
api_version: 2.0.0
spec_type: analysis
name: example_run
description: Example run for template
template: $template_id

template_configuration:
  view_mappings:
    source_tables:
      - collaborator_1.data_offering_1.dataset_1
      - collaborator_2.data_offering_2.dataset_2
  arguments:
     p1_join_col: p1.hashed_email
     p2_join_col: p2.hashed_email
     group_by_col: p2.device_type

$$ );

Entwickeln einer benutzerdefinierten Vorlage

Clean Room-Vorlagen sind JinjaSQL-Vorlagen. Um eine -Vorlage zu erstellen, sollten Sie mit den folgenden Themen vertraut sein:

Sie können Cortex Code verwenden, um die SQL-Ausgabe Ihrer JinjaSQL-Vorlagen auf der Grundlage von Variableneingaben, die bereitgestellt werden sollen, zu validieren. Sehen Sie sich unten Beispiel-Eingabeaufforderungen an, die Sie in Cortex Code kopieren können, um die endgültigen SQL-Ausgaben zu erhalten, die Sie testen können:

Beispiel:

Resolve the following Jinja template into SQL based on the variables defined:

Jinja Template:
 SELECT IDENTIFIER({{ col1 | column_policy }}), IDENTIFIER({{ col2 | column_policy }})
  FROM IDENTIFIER({{ source_table[0] }}) AS p1
  JOIN IDENTIFIER({{ source_table[1] }}) AS p2
  ON  IDENTIFIER({{ p1_join_col | join_policy }}) = IDENTIFIER({{ p2_join_col | join_policy }})
  {% if where_phrase %} WHERE {{ where_phrase | sqlsafe }}{% endif %};

Variable Inputs:
source_table: SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS, SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS
col1: p1.status
col2: p1.age_band
p1_join_col: p1.hashed_email
p2_join_col: p2.hashed_email
where_phrase: p1.household_size > 2

Die gerenderte Vorlage sieht wie folgt aus:

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

Versuchen Sie, die obige SQL-Anweisung in Ihrer Umgebung auszuführen, um zu sehen, ob sie funktioniert und die erwarteten Ergebnisse liefert.

Dann testen Sie Ihre Vorlage ohne WHERE-Klausel:

Resolve the following Jinja template into SQL based on the variables defined:

Jinja Template:
 SELECT IDENTIFIER({{ col1 | column_policy }}), IDENTIFIER({{ col2 | column_policy }})
  FROM IDENTIFIER({{ source_table[0] }}) AS p1
  JOIN IDENTIFIER({{ source_table[1] }}) AS p2
  ON  IDENTIFIER({{ p1_join_col | join_policy }}) = IDENTIFIER({{ p2_join_col | join_policy }})
  {% if where_phrase %} WHERE {{ where_phrase | sqlsafe }}{% endif %};

Variable Inputs:
source_table: SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS, SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS
col1: p1.status
col2: p1.age_band
p1_join_col: p1.hashed_email
p2_join_col: p2.hashed_email

Gerenderte Vorlage:

SELECT IDENTIFIER('p1.status'), IDENTIFIER('p1.age_band')
FROM IDENTIFIER('SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS') AS p1
JOIN IDENTIFIER('SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS') AS p2
ON  IDENTIFIER('p1.hashed_email') = IDENTIFIER('p2.hashed_email');

Fügen Sie die Vorlage zu Ihrem Clean Room hinzu, und testen Sie mit einer Analyseausführungsspezifikation.

Datenschutz

Vorlagen können nur auf Datensets zugreifen, die von Teilnehmern mit dem Clean Room verknüpft wurden.

Teilnehmer legen Verknüpfungs-, Spalten- und Aktivierungsrichtlinien für ihre Datensets fest, um sicherzustellen, dass nur diese Spalten als Eingabe für eine Vorlagenvariable verwendet werden können.

Wichtig

Die Vorlage muss den entsprechenden JinjaSQL-Richtlinienfilter für eine Spalte enthalten, damit die Richtlinie angewendet wird.

Syntax einer benutzerdefinierten Vorlage

Snowflake Data Clean Rooms unterstützt V3 JinjaSQL, mit einigen Erweiterungen (wie angegeben).

Dieser Abschnitt enthält die folgenden Themen:

Regeln für die Benennung von Vorlagen

Beim Erstellen einer Vorlage dürfen Namen nur Buchstaben, Zahlen oder Unterstriche enthalten. Die Namen der Vorlagen werden im name-Feld der Spezifikation der Vorlage zugewiesen, wenn Sie die Vorlage registrieren.

Beispiel für gültige Namen:

  • my_template

  • activation_template_1

Beispiel für ungültige Namen:

  • my template - Leerzeichen nicht erlaubt

  • my_template! - Sonderzeichen nicht erlaubt

Vorlagenvariablen

Vorlagenaufrufer können Werte an Vorlagenvariablen übergeben. Die JinjaSQL-Syntax ermöglicht die Variablenbindung für jeden Variablennamen innerhalb von {{ double_brackets }}, aber Snowflake reserviert einige Variablennamen, die Sie nicht überschreiben sollten, wie unten beschrieben.

Vorsicht

Alle Variablen, ob von Snowflake definiert oder kundenspezifisch, werden vom Benutzenden befüllt und sollten mit der entsprechenden Vorsicht behandelt werden. Analysevorlagen müssen zu einer einzigen SELECT -Anweisung aufgelöst werden (Aktivierungsvorlagen werden zu einem Skriptblock aufgelöst). Denken Sie daran, dass alle Variablen vom Aufrufer übergeben werden.

Snowflake-definierte Variablen

Alle Clean Room-Vorlagen haben Zugriff auf die folgenden globalen Variablen, die von Snowflake definiert, aber vom Analyseausführenden übergeben werden:

source_table:

Ein nullbasiertes Zeichenfolgen-Array von Tabellen und Ansichten aus Datenangeboten, die über LINK_DATA_OFFERING mit der Collaboration verknüpft sind, die von der Vorlage verwendet werden kann.

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

my_table:

In einem Collaboration-Clean Room wird my_table nur von Benutzern der Snowflake Standard Edition verwendet. Für diese Benutzer gilt: my_table ist ein nullbasiertes Zeichenfolgen-Array von Datensets, die der Analyseausführende durch den Aufruf von LINK_LOCAL_DATA_OFFERING verknüpft hat.

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

Benutzerdefinierte Variablen

Vorlagenersteller können beliebige Variablen in eine Vorlage aufnehmen, die vom Analyseausführenden befüllt werden können. Diese Variablen, außer die von Snowflake definierten Variablen oder Tabellen-Aliasnamen, können einen beliebigen Jinja-kompatiblen Namen haben. Sie sollten im Parameterabschnitt der Vorlage Hinweise zu erforderlichen und optionalen Variablen geben.

Auf benutzerdefinierte Variablen kann von Ihrer Vorlage aus zugegriffen werden, wie hier für die benutzerdefinierte Variable max_income gezeigt:

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

Analyseausführende übergeben beim Aufruf von RUN Variablen wie in der Analyseausführungsspezifikation definiert.

Variablen richtig auflösen

In die Vorlage übergebene Zeichenfolgenwerte werden in der endgültigen Vorlage in ein Zeichenfolgenliteral aufgelöst. Dies kann zu SQL-Parsing- oder logischen Fehlern führen, wenn Sie gebundene Variablen nicht angemessen behandeln:

  • SELECT {{ my_col }} FROM p; wird zu SELECT 'my_col' from p; aufgelöst, sodass einfach die Zeichenfolge „my_col“ zurückgegeben wird, was wahrscheinlich nicht Ihr Ziel war.

  • SELECT age FROM {{ source_table[0] }} AS p; wird zu SELECT age FROM 'somedb.somesch.source_table' AS p; aufgelöst, was einen Parsing-Fehler verursacht, da eine Tabelle ein Bezeichner und keine literale Zeichenfolge sein muss.

  • Die Übergabe von SELECT age FROM IDENTIFIER({{ source_table[0] }}) AS p {{ where_clause }}; in „WHERE Alter < 50“ ergibt SELECT age FROM mytable AS p 'WHERE age < 50';, was aufgrund der WHERE-Klausel der literalen Zeichenfolge ein Parsing-Fehler ist.

Daher müssen Sie, wo es angebracht ist, Variablen auflösen. Hier erfahren Sie, wie Sie Variablen in Ihrer Vorlage richtig auflösen:

Auflösen von Tabellen- und Spaltennamen

Variablen, die Tabellen- oder Spaltennamen enthalten, müssen auf eine der beiden folgenden Arten in Bezeichner in Ihrer Vorlage umgewandelt werden:

  • IDENTIFIER: For example: SELECT IDENTIFIER({{ my_column }}) FROM p;

  • sqlsafe: Dieser JinjaSQL-Filter löst Bezeichnerzeichenfolgen in SQL-Text auf. Eine gleichwertige Anweisung zum vorherigen Punkt ist SELECT {{ my_column | sqlsafe }} FROM p;

Ihre spezielle Nutzung bestimmt, wann IDENTIFIER oder sqlsafe verwendet werden. Beispiel:p.{{ my_column | sqlsafe }} kann nicht einfach mit IDENTIFIER umgeschrieben werden.

Auflösen von dynamischem SQL

Wenn Sie eine Zeichenfolgenvariable haben, die als Literal-SQL verwendet werden soll, wie z. B. eine WHERE Klausel, verwenden Sie den sqlsafe-Filter in Ihrer Vorlage. Beispiel:

SELECT age FROM IDENTIFIER({{ source_table[0] }}) AS p WHERE {{ where_clause }};

Wenn ein Benutzer „Alter < 50“ an where_clause übergibt, würde die Abfrage in SELECT Alter FROM sometable AS p WHERE 'Alter < 50'; aufgelöst werden, was aufgrund der WHERE-Bedingung der literalen Zeichenfolge ungültige SQL ist. In diesem Fall sollten Sie den sqlsafe-Filter verwenden:

SELECT age FROM IDENTIFIER( {{ source_table[0] }} ) as p {{ where_clause | sqlsafe }};

Erforderliche Tabellen-Aliasse

Auf der obersten Ebene Ihrer Abfrage müssen alle``source_table``-Datensets den Alias p verwenden, und alle my_table-Datensets müssen den Alias c verwenden, damit Snowflake Verknüpfungs- und Spaltenrichtlinien in der Abfrage korrekt überprüfen kann. Jede Spalte, die anhand von Verknüpfungs- oder Spaltenrichtlinien verifiziert werden soll, muss mit dem Tabellenalias kleines p oder c qualifiziert sein.

Wenn Sie in Ihrer Abfrage mehrere source_table- oder my_table-Datensets verwenden, fügen Sie jedem Tabellenalias nach der ersten ein numerisches, fortlaufendes 1-basiertes Suffix hinzu. Also: p oder p1, p2, p3 usw. für die ersten, zweiten und dritten source_table-Datensets und c oder``c1``, c2, c3 usw. für die ersten, zweiten und dritten my_table-Datensets. Der p- oder c-Index sollte ohne Lücken sequenziell sein (d. h. nutzen Sie die Aliasnamen p1, p2 und p3, nicht p1, p2 und p4).

Beispiel

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

Kundenspezifische Clean Room-Filter

Snowflake unterstützt alle Standard-Jinja-Filter und die meisten der Standard-JinjaSQL-Filter sowie einige Erweiterungen:

join_policy:

Erfolgreich, wenn die Spalte in der Verknüpfungsrichtlinie des Dateneigentümers enthalten ist; schlägt andernfalls fehl. Siehe Anwenden von Datenschutzrichtlinien auf Datenangebote.

column_policy:

Erfolgreich, wenn die Spalte in der Spaltenrichtlinie des Dateneigentümers enthalten ist; schlägt andernfalls fehl. Siehe Anwenden von Datenschutzrichtlinien auf Datenangebote.

activation_policy:

Erfolgreich, wenn die Spalte in der Aktivierungsrichtlinie des Dateneigentümers enthalten ist; schlägt andernfalls fehl. Siehe Anwenden von Datenschutzrichtlinien auf Datenangebote.

join_and_column_policy:

Erfolgreich, wenn die Spalte in der Verknüpfungs- oder Spaltenrichtlinie des Dateneigentümers enthalten ist; schlägt andernfalls fehl. Siehe Anwenden von Datenschutzrichtlinien auf Datenangebote.

identifier:

Dieser JinjaSQL-Filter wird von Snowflake-Vorlagen nicht unterstützt.

Tipp

JinjaSQL-Anweisungen werden von links nach rechts ausgewertet:

  • {{ my_col | column_policy }} Richtig

  • {{ my_col | sqlsafe | column_policy }} Richtig

  • {{ column_policy | my_col }} Falsch

  • {{ my_col | column_policy | sqlsafe }} Falsch: column_policy wird mit dem my_col-Wert als Zeichenfolge abgeglichen, was ein Fehler ist.

Clean Room-Richtlinien durchsetzen

Clean Rooms überprüfen nicht automatisch Clean Room-Richtlinien für die Spalten, die in einer Vorlage verwendet werden. Wenn Sie eine Richtlinie für eine Spalte erzwingen möchten:

  • Sie müssen den entsprechenden Richtlinienfilter auf diese Spalte in der Vorlage anwenden. Beispiel:

FROM IDENTIFIER({{ source_table[0] }}) AS p1
JOIN IDENTIFIER({{ source_table[1] }}) AS p2
  ON IDENTIFIER({{ p1_join_col | join_policy }}) = IDENTIFIER({{ p2_join_col | join_policy }})

Richtlinien werden nur für Spalten von Tabellen geprüft, auf die in einer source_table-Variable verwiesen wird, und die sich auf innerhalb des Clean Room freigegebene Ansichten beziehen. Richtlinien werden nicht mit Spalten von Tabellen geprüft, auf die in einer my_table-Variable verwiesen wird, bei denen es sich um lokale Tabellen handelt, die nicht innerhalb des Clean Room gemeinsam genutzt werden.

Beachten Sie beim Testen von Richtlinien, dass Spaltennamen nicht mehrdeutig sein dürfen. Wenn Sie also Spalten mit demselben Namen in zwei Tabellen haben, müssen Sie den Spaltennamen qualifizieren, um die Richtlinie für diese Spalte testen zu können.

Hinweise zum Zugriff und Best Practices

Eine Vorlage wird immer im Kontext der Clean Room-Anwendungsrolle ausgeführt. Ein Teilnehmer hat keinen direkten Zugriff auf Daten im Clean Room, die nur auf Vorlagen beschränkt sind. Der gesamte Zugriff erfolgt über die nativen Anwendungsrollen und die Ausgaben der Vorlagen.

Als Best Practice sollten Sie Folgendes für Vorlagen befolgen, die Sie erstellen oder in einem Clean Room verwenden:

  • Stellen Sie sicher, dass jedes Mal, wenn eine Spaltenvariable in einer Vorlage verwendet wird, ein Richtlinienfilter angewendet wird, damit die Richtlinien der Teilnehmer beachtet werden.

  • Schließen Sie vom Benutzer bereitgestellte Variablen wenn möglich mit IDENTIFIER() ein, um Ihre Vorlagen gegen SQL-Einschleusungsangriffe auszurüsten.

Aktivierungsvorlagen

Eine Vorlage kann auch verwendet werden, um Abfrageergebnisse in einer Tabelle außerhalb des Clean Room zu speichern. Dies wird Aktivierung genannt. Eine Aktivierungsvorlage ist eine Analysevorlage mit den folgenden zusätzlichen Anforderungen:

  • Aktivierungsvorlagen sind JinjaSQL-Anweisungen, die einen SQL-Skriptblock ergeben, im Gegensatz zu Analysevorlagen, die einfache SELECT-Anweisungen sein können.

  • Aktivierungsvorlagen müssen eine interne Tabelle im Clean Room erstellen, um die Ergebnisse zu speichern. Die von der Vorlage generierte Tabelle muss das Präfix cleanroom.activation_data_ haben, zum Beispiel: cleanroom.activation_data_my_results

  • Alle Spalten in der internen Ergebnistabelle sollten den Wert activation_allowed: TRUE in ihrer Datenangebotsspezifikation haben.

  • Der Skriptblock sollte mit einer RETURN-Anweisung enden, die den Namen der generierten Tabelle ohne das cleanroom.activation_data_-Präfix zurückgibt, zum Beispiel: RETURN 'my_results'.

  • Für die Vorlage selbst gibt es keine Anforderungen an die Benennung.

Hier finden Sie ein Beispiel für eine Aktivierungsvorlagen-Spezifikation:

api_version: 2.0.0
spec_type: template
name: my_activation_template
version: v0
type: sql_activation
description: Activation template that creates segment data
template: |
  BEGIN
      CREATE OR REPLACE TABLE cleanroom.activation_data_analysis_results AS
      SELECT
          {{ group_by_column | sqlsafe }} AS bucket_label,
          {{ activation_column | sqlsafe | activation_policy }} AS activation_label,
          COUNT(DISTINCT {{ join_column | sqlsafe }}) AS overlap_count
      FROM IDENTIFIER({{ source_table[0] }}) AS p
      GROUP BY {{ group_by_column | sqlsafe }},
               {{ activation_column | sqlsafe }};
      RETURN 'analysis_results';
  END;
parameters:
  - name: join_column
    description: Join column name
    required: true
    default: "p.IP_ADDRESS"
  - name: group_by_column
    description: Group by column name
    required: true
    default: "p.CAMPAIGN_NAME"
  - name: activation_column
    description: Activation column name
    required: true
    default: "p.DEVICE_TYPE"

Erfahren Sie, wie Sie die Aktivierung in einer Collaboration implementieren: Aktivieren von Abfrageergebnissen.

Nächste Schritte

Nachdem Sie das Vorlagensystem gemeistert haben, lesen Sie sich die Einzelheiten zur Implementierung eines Clean Room mit Ihrem Vorlagentyp durch:

  • Aktivierungsvorlagen erstellen eine Ergebnistabelle nach einer erfolgreichen Ausführung und werden außerhalb des Clean Room freigegeben. Je nach Spezifikation für die Collaboration kann die Ergebnistabelle für den Analyseausführenden oder andere Teilnehmer freigegeben werden.

  • Code-Bundles werden verwendet, um benutzerdefinierte Python-UDFs und -UDTFs in eine Collaboration hochzuladen. Vorlagen in der Zusammenarbeit können diese Funktionen ausführen, um komplexe Datenaktionen durchzuführen.

  • Interne Tabellen werden verwendet, um Zwischenergebnisse oder persistente Ergebnisse zu speichern, die nachgelagert zur Unterstützung von mehrstufigen Arbeitsabläufen verwendet werden können. Auf diese Tabellen können Vorlagen oder benutzerdefinierten Code innerhalb des Clean Room zugreifen.

Weitere Informationen