Snowflake Data Clean Room:多提供商 Clean Room¶
本主题提供了对来自多个提供商的 Clean Room 集群运行分析的示例。该示例演示了查询如何跨 Clean Room 访问数据,同时为每个 Clean Room 提供安全保障。此外,还演示了使用者如何定义用于运行分析的模板,这是多提供商 Clean Room 的常见用例。
在多提供商分析中,每个 Clean Room 的数据都以完全安全的方式使用。Snowflake Data Clean Room 确保遵守每项 Clean Room 安全策略,同时还证明所有根据数据运行的 SQL 与每个 Clean Room 参与者的期望相符。
在许多情况下,执行多提供商分析的使用者希望能够定义分析模板,而不是使用提供商定义的模板。这使得使用者能够控制分析来自多方的数据时如何获得见解。有关使用者定义的模板的更多信息,请参阅使用开发者 API 添加使用者定义的模板。
备注
不允许在跨区域共享的 Clean Room 中进行多提供商 Clean Room 分析。
多提供商分析示例包括以下步骤:
提供商:
a.创建两个 Clean Room,模拟两个不同的提供商。
b.与同一使用者共享 Clean Room。
使用者:
a.安装两个提供商 Clean Room。
b.发送请求以将使用者定义的模板添加到 Clean Room。
提供商:
a.批准使用者添加使用者定义的模板的请求。
b.为使用者定义的模板设置列策略。
使用者:
a.提出多提供商分析请求。
提供商:
a.启用 Clean Room 以进行多提供商分析。
b.批准使用者的多提供商分析请求。
使用者
a.在整个 Clean Room 集群中执行分析。
先决条件¶
您需要有两个独立的 Snowflake 账户才能完成此示例。使用第一个账户执行提供商的命令,然后切换到第二个账户执行使用者的命令。
使用者:安装 Clean Room¶
使用使用者账户中的 Snowflake 工作表执行本节中的命令。
作为使用者,您可以共享多个 Clean Room。在对所有 Clean Room 运行多提供商分析之前,您需要将每个 Clean Room 安装到您的账户中,并关联您要用于分析的数据集。
设置环境¶
在使用 Developer APIs 之前,您需要承担 SAMOOHA_APP_ROLE 角色,并指定用来执行 APIs 的仓库。如果您没有 SAMOOHA_APP_ROLE 角色,请联系账户管理员。
执行以下命令以设置您的环境:
USE ROLE samooha_app_role;
USE WAREHOUSE app_wh;
安装 Clean Room¶
安装 Clean Room 前,为提供商与您共享的每个 Clean Room 命名。
set cleanroom_name_1 = 'Samooha Cleanroom Multiprovider Clean Room 1';
set cleanroom_name_2 = 'Samooha Cleanroom Multiprovider Clean Room 2';
以下命令将在使用者账户中安装 Clean Room:
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>');
安装了 Clean Room 后,提供商必须在启用前完成提供商端的 Clean Room 设置。您可以通过以下函数查看 Clean Room 的状态。启用 Clean Room 后,您应该能够运行下面的“运行分析”命令。启用 Clean Room 通常需要大约 1 分钟。
CALL samooha_by_snowflake_local_db.consumer.is_enabled($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.consumer.is_enabled($cleanroom_name_2);
安装 Clean Room 共享后,可以使用以下命令查看可用的 Clean Room 列表。
CALL samooha_by_snowflake_local_db.consumer.view_cleanrooms();
关联数据集¶
将数据集链接到 Clean Room,使用提供商的数据进行安全计算。
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']);
备注
如果即使表存在此步骤也不起作用,则包含该表的数据库可能未注册。要注册数据库,请作为具有 ACCOUNTADMIN 角色的用户执行以下命令。
USE ROLE accountadmin;
CALL samooha_by_snowflake_local_db.provider.register_db('<DATABASE_NAME>');
USE ROLE samooha_app_role;
如果要查看您已添加到 Clean Room 的数据集,请调用以下过程。
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);
使用者:发送请求以将使用者定义的模板添加到 Clean Room。¶
运行多提供商分析的使用者通常最了解如何从来自多方的数据中提取价值。使用者可以向 Clean Room 提供商发送请求,将使用者定义的模板纳入 Clean Room 中,以便使用者可以用它来运行分析。有关将使用者定义的模板添加到 Clean Room 的更多信息,请参阅添加使用者定义的模板。
备注
多提供商 Clean Room 分析的工作原理是,将来自其他 Clean Room 以及当前 Clean Room 的所有表放入模板中的 source_tables
实参。然而,在安全验证和请求批准期间,每个 Clean Room 也只会收到与其相关的表。因此,模板应该按照一般方式编写,而不要假设特定数量的 source_table
实参,这样便可扩展到一个或多个 source_table
输入。这可以使用 Jinja for 循环来实现。
对于此示例,使用者发送以下请求。每个请求都包含定义模板的 Jinja 代码。
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 %}
$$);
提供商:批准使用者添加模板的请求¶
提供商必须批准使用者的请求,将使用者定义的模板纳入 Clean Room。
提供商使用 provider.list_template_requests
命令列出请求,包括获取新请求的 UUID。然后,提供商通过执行 provider.approve_template_request
命令批准请求。有关此过程的更多信息,请参阅添加使用者定义的模板。
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>);
对每个表设置列策略¶
对于每个表和模板组合,设置使用者可以在分析中使用的列,例如可以分组或汇总的列。这提供了灵活性,使同一个表可以根据基础模板允许不同的列选择。等到添加模板之后,再在表上设置列策略。
请注意,列策略是 仅替换,因此如果再次调用函数,新的列策略会完全替换之前设置的列策略。
不应将列策略用于 email、HEM 或 RampID 等身份列,因为您不希望使用者能够按这些列进行分组。在生产环境中,Snowflake 会推理 PII 列并阻止此操作,但在沙盒环境中无法进行此推理。它应该只用于您希望使用者能够汇总和分组的列,例如状态、年龄段、地区代码或活动天数。
要使“column_policy”和“join_policy”对使用者分析请求执行检查,在 SQL Jinja 模板中,所有列名 MUST 称为 dimensions 或 measure_columns。确保使用这些标签来引用自定义 SQL Jinja 模板中要检查的列。
要设置模板/表组合的列策略,请执行以下命令:
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']);
使用者:提出多提供商 Clean Room 分析请求¶
下一步是针对您安装的 Clean Room 提出多提供商分析请求。这组 Clean Room 被称为 Clean Room 集群。此过程会向每个提供商写入请求,询问是否可以批准和执行此多提供商分析。提供商使用自动或手动流程,异步处理这些请求。如果采用自动审批流程,请求处理大约需要 2 分钟,并且如果每个 Clean Room 都获得批准(在检查请求是否符合 Clean Room 的安全政策后),则可以执行该流程。
多提供商 Clean Room 请求流程要求在 source_table 数组实参下指定提供商表。该表需要以其所在的 Clean Room 名称开头。整体格式为 <CLEANROOM_NAME>.<DB>.<SCHEMA>.<TABLE>。可以在 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'
)
);
此 API 首先根据每个 Clean Room 的安全策略验证请求,然后向每个 Clean Room 的提供商提出多提供商分析请求。如果这些检查失败,此 API 将就其遇到的错误返回错误消息。
如何确定 prepare_multiprovider_flow 的输入¶
要运行分析,需要向 run_analysis 函数传递一些参数。本节将向您展示如何确定要传入的参数。
模板名称
首先,您可以通过执行以下命令来查看支持的分析模板:
CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name);
在使用模板运行分析之前,您需要知道要指定哪些实参以及需要哪些类型。对于自定义模板,您可以执行以下命令:
CALL samooha_by_snowflake_local_db.consumer.view_template_definition($cleanroom_name, 'prod_custom_template');
这将返回大量不同的 SQL Jinja 参数。要解析 SQL Jinja 模板,并将需要在 run_analysis 中指定的实参提取到列表中,请执行以下命令。
CALL samooha_by_snowflake_local_db.consumer.get_arguments_from_template($cleanroom_name, 'prod_custom_template');
数据集名称
如果要查看提供商已添加到 Clean Room 的数据集名称,请执行以下命令。请注意,您无法查看提供商添加到 Clean Room 的数据集中的数据。
CALL samooha_by_snowflake_local_db.consumer.view_provider_datasets($cleanroom_name);
您还可以执行以下命令,查看已关联到 Clean Room 的表:
CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name);
维度和度量列
在运行分析时,您可能希望对某些列进行筛选、分组和汇总。如果要查看提供商已添加到 Clean Room 的列策略,请执行以下命令:
CALL samooha_by_snowflake_local_db.consumer.view_provider_column_policy($cleanroom_name);
常见错误
如果运行分析的结果是出现 Not approved: unauthorized columns used 错误,请尝试查看提供商设置的联接策略和列策略。
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);
也有可能您已经耗尽了隐私预算,这样一来系统会阻止您执行更多查询。您可以使用以下命令查看剩余的隐私预算。预算会每天重置;或者,Clean Room 提供商也可以手动重置。
CALL samooha_by_snowflake_local_db.consumer.view_remaining_privacy_budget($cleanroom_name);
您可以通过以下 API 检查 Clean Room 是否启用了差分隐私:
CALL samooha_by_snowflake_local_db.consumer.is_dp_enabled($cleanroom_name);
提供商:启用多提供商分析并批准请求¶
您现在即将切换回提供商账户,以便为使用者启用多提供商分析并处理提出的请求。
启用 Clean Room 以进行多提供商分析¶
除非您为此目的启用 Clean Room,否则使用者无法成功执行多提供商分析。在为使用者启用 Clean Room 时,您还可以指定哪些 Clean Room 可以包含在多提供商分析中。除非您明确批准其他提供商的 Clean Room,否则使用者不能执行涉及您的 Clean Room 和其他提供商的 Clean Room 的多提供商分析。
为了允许使用者使用来自任何其他提供商的 Clean Room 运行多提供商分析,请在执行以下命令时指定一个空列表。
备注
这只能针对 已经 安装了 Clean Room 的使用者调用。
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)]);
批准多提供商分析请求¶
在每个 Clean Room 启用多提供商分析后,可以使用以下 API 查看针对 Clean Room 提出的所有多提供商分析请求:
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>');
请求审批可以通过以下两种方式进行:
自动使用监听传入请求并在需要时触发的任务。
由用户手动明确处理传入的多提供商分析请求。
默认情况下,审批为手动进行,任务由 enable_multiprovider_computation
API 以暂停状态创建。这需要用户手动处理传入的请求。可以通过执行以下命令来完成:
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>');
备注
此 API 可以通过指定 view_multiprovider_requests
API 输出中的特定的请求 ID,在请求 ID 层面运行,或者以“-1”传入 REQUEST_ID 来处理所有传入请求。
此过程 不会批准 传入的请求,而是会将请求传递到处理逻辑中,根据请求的时长以及请求的协作者是否在您在 enable_multiprovider_computation
中设置的批准协作者列表中等因素来验证是否可以批准。
处理完后,请求将写入 samooha_cleanroom_${UUID}.admin.request_log_multiprovider
表。您可以通过以下查询查看请求列表以及请求是否已获批准:
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;
之前未获批准的请求也可以替换为 APPROVE=True
,或通过使用以下查询,设置 APPROVE=False
来移除访问权限。有关 <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>;
如果自动审批流程优先于手动审批,则需要通过执行以下命令来恢复多提供商分析任务:
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>');
相反,如果当前启动了自动审批流程,则可以通过执行以下命令将其关闭:
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>');
安全注意事项:管理多提供商分析请求¶
多提供商分析通过将已批准查询的哈希值添加到行访问策略来实现。行访问策略通常在 samooha_cleanroom_${UUID}.shared_schema
架构下创建,行访问策略的定义为:
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
);
行访问策略的工作原理是,查找您账户上 Clean Room 特定使用者的 samooha_cleanroom_${UUID}.admin.request_log_multiprovider
表中的已批准请求,并检查其账户中运行的当前查询的哈希值是否与已批准的查询相匹配。
对于多提供商流程,对数据的所有安全访问均需通过本表所列的批准进行控制 (samooha_cleanroom_${UUID}.admin.request_log_multiprovider
)。您必须主动管理,确保只有您希望访问数据的查询能获准运行。
简单查询可用于批准或取消批准(即移除批准)先前处理的请求。例如,您可以执行以下查询:
-- 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>;
从行访问策略中可以看出,数据访问权限取决于 query_hash
。但是,query_hash
还取决于随机选择哪个 Clean Room 来执行查询,因此系统会将 <CONDITIONS> 传递到上述查询,从而确定哪些撤销访问/批准的请求需要遵循以下最佳实践:
如果手动批准请求,请尝试通过筛选以下内容尽可能具体地描述请求:
request_id
和/或cleanroom_names
、requester_account
和template_name
。如果撤销之前查询的批准情况,则撤销所有
query_hash
匹配的请求,并 撤销给定requester_account
、template_name
和cleanroom_names
的所有请求(请参阅以下示例)。如果新请求未获批准,则不会更改之前请求的批准情况。如果您希望撤销之前的查询访问权限,则需要使用
samooha_cleanroom_${UUID}.admin.request_log_multiprovider
表中的 APPROVED=False 来标记相应的请求。如果您通过再次运行
enable_multiprovider_computation
来更改允许的协作者集,则默认情况下,不会撤销之前的请求。您需要通过设置samooha_cleanroom_${UUID}.admin.request_log_multiprovider
表中的 APPROVED=False,撤销对之前协作的访问权限,进而管理批准情况。
如何彻底撤销特定协作提出请求的能力的示例。假设有一个协作正在您要撤销的 requester_account=ABC123
上运行。您可以执行以下查询:
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];
撤销该 Clean Room 协作中的查询哈希和该模板的访问权限。
以下是一些示例查询,您可用于查看每个 请求者账户
提出了多少个查询:
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>';
使用者 - 执行请求¶
prepare_multiprovider_flow API 提出的请求获得批准后,可以在 Clean Room 集群中使用以下 API 来执行。此执行通过随机选择一个 Clean Room 来执行流程,并且只要两个 Clean Room 都批准了请求,就允许进行多提供商分析。
CALL samooha_by_snowflake_local_db.consumer.execute_multiprovider_flow([$cleanroom_name_1, $cleanroom_name_2]);
还需要注意,一旦 prepare_multiprovider_flow 过程之后请求得到批准,就可以根据需要多次调用 execute_multiprovider_flow,而无需再次调用 prepare_multiprovider_flow。但是,为了运行不同的分析或跨不同的 Clean Room 集群的单个分析,需要再次调用 prepare_multiprovider_flow。
实用函数¶
将互操作性请求写入每个提供商后,批准就会采用请求特定的客户模板的形式,这些模板会添加到 Clean Room 并在分析期间执行。这样一来,就设置好了所需的基础设施。您可以通过执行以下命令,查看请求的审批流程实时添加的这些模板。
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);