Ofertas de dados¶

Uma oferta de dados é um conjunto de uma ou mais exibições, chamadas conjuntos de dados, compartilhadas com executores de análise específicos em uma colaboração. Você pode compartilhar dados com executores de análise para os quais você está definido como provedor de dados na especificação da colaboração.

Uma oferta de dados é uma exibição ativa dos dados de origem, não um instantâneo dos dados no momento em que a oferta de dados é registrada. Todas as políticas do Snowflake aplicadas aos dados de origem ficam ativas na oferta de dados.

Quando você registra uma oferta de dados, o Snowflake cria uma exibição para cada fonte de dados listada na especificação da oferta de dados. A exibição inclui apenas as colunas listadas na especificação da oferta de dados. Certas colunas, dependendo da respectiva categoria, estão sujeitas à renomeação neste estágio.

Além disso, ao vincular uma oferta de dados a uma colaboração, o Snowflake cria uma cópia da exibição registrada e limita o acesso a ela aos executores de análise especificados de acordo com a especificação da colaboração.

Importante

Se você mover, renomear ou alterar as permissões de acesso das tabelas subjacentes, a oferta de dados se tornará inutilizável por meio dos links que já foram registrados.

Se você usar o Snowflake Standard Edition, não será possível compartilhar dados por meio de uma sala limpa de dados com aplicação de políticas. Portanto, não é possível compartilhar dados com outras partes ou aproveitar as políticas de sala limpa de dados especificadas nas ofertas, mesmo para usuários em sua própria conta. No entanto, você pode acessar ofertas de dados de outros colaboradores ou usar os próprios dados como uma oferta de dados local sem políticas.

Requisitos da oferta de dados:

Você deve ter o privilégio REFERENCE_USAGE com GRANT OPTION nos dados que deseja compartilhar. Caso contrário, você receberá um erro de «concessão de uso de referência ausente» ao tentar registrar, ingressar na colaboração ou vincular os dados.
```
GRANT REFERENCE_USAGE ON DATABASE my_database TO ROLE my_role WITH GRANT OPTION;
```
Você deve ter a função de colaboração de provedor de dados em uma colaboração.
Atualmente, somente a função da conta que criou ou ingressou na colaboração pode vincular ou desvincular dados de uma colaboração.

Continue lendo para saber como registrar e vincular uma oferta de dados a uma colaboração:

Registrar uma oferta de dados¶

Crie uma especificação da oferta de dados para seus dados. Especifique os seguintes detalhes sobre a oferta de dados:
- O objeto de origem para cada conjunto de dados na oferta de dados.
- Quais colunas incluir em cada conjunto de dados.
- O tipo (junção ou outro) de cada coluna, que é usado para preencher as políticas de sala limpa. Em alguns casos, você também especificará o formato das colunas individuais.
- Qualquer política de proteção de dados do Snowflake para aplicar às colunas em sua oferta de dados.
- Como os usuários podem acessar os dados: somente por modelo ou também por consulta SQL de forma livre.
Registre a oferta de dados chamando REGISTER_DATA_OFFERING, que retorna um ID da oferta de dados.

Esta etapa torna a oferta de dados disponível para ser vinculada a qualquer colaboração por qualquer função em sua conta que tenha acesso de leitura ao registro. Você pode usar o mesmo ID para compartilhar uma oferta de dados com várias colaborações.

Vincular uma oferta de dados¶

O processo de vinculação depende se a colaboração foi criada:

Se a colaboração ainda não foi criada, o provedor de dados pode fornecer o ID da oferta de dados ao proprietário da colaboração para incluir na especificação da colaboração. Quando uma oferta de dados é incluída na especificação da colaboração, o ID fica visível na especificação para revisão pelo provedor de dados antes de ingressar na colaboração.
Se a colaboração foi criada, o provedor de dados ingressa na colaboração e chama LINK_DATA_OFFERING com o ID da oferta de dados, o nome da colaboração e com quem os dados podem ser compartilhados. Pode haver um pequeno atraso para uma oferta de dados ficar disponível para uso depois de ser vinculada. Chame VIEW_UPDATE_REQUESTS se quiser garantir que a solicitação de vinculação da oferta de dados tenha sido concluída com sucesso. Após a vinculação bem-sucedida, a oferta de dados estará visível e pronta para uso ao chamar VIEW_DATA_OFFERINGS.

Ao vincular dados, você especifica quais executores de análise podem acessá-los.

Um provedor de dados pode remover ofertas de dados de uma colaboração ou de colaboradores específicos chamando UNLINK_DATA_OFFERING.

Para ver as ofertas de dados registradas em sua conta, chame VIEW_REGISTERED_DATA_OFFERINGS.

Dica

As ofertas de dados não estarão visíveis em uma colaboração até que o usuário que a registrou ingresse na colaboração.

Consulte Execute uma análise para saber como executar uma análise.

Renomeação da coluna de origem¶

Os nomes das colunas em uma oferta de dados podem ser renomeados antes de serem expostos ao executor de análise. A renomeação depende dos valores category e column_type que definem a coluna na especificação da oferta de dados, conforme descrito nesta tabela:


`category` de coluna	Novo nome da coluna
`join_standard`	Valor `column_type`
`timestamp`	`timestamp`
`join_custom`, `passthrough` ou `event_type`	É usado o nome original da coluna.

Por exemplo, se o nome da coluna na tabela de origem é user_email_address, a forma como essa coluna é exposta a um executor de análise depende de como ela foi definida na especificação da oferta de dados:


Especificação da oferta de dados	Como a coluna é referenciada
... schema_and_template_policies: user_email_address: category: join_standard column_type: hashed_email_sha256	`column_type` é usado para as colunas `join_standard`: SELECT HASHED_EMAIL_SHA256 FROM source_table[0];

Aplicando políticas de proteção de dados às ofertas de dados¶

Os dados compartilhados em uma sala limpa são protegidos de várias maneiras:

Os dados registrados no ambiente de sala limpa são criados como uma exibição segura que omite todas as colunas que não estão listadas na especificação da oferta de dados.
A exibição segura é compartilhada apenas com os usuários e modelos específicos indicados na especificação da colaboração.
Você pode adicionar políticas do Snowflake aos seus dados para gerenciar melhor como eles são usados.
Políticas de modelo do Data Clean Room também são aplicadas com base na classificação de coluna da oferta de dados.

Há duas maneiras de aplicar uma política de proteção de dados do Snowflake, como uma política de junção ou agregação, aos seus dados compartilhados:

Aplicar a política aos dados de origem. As políticas aplicadas aos dados de origem são executadas nos conjuntos de dados expostos em uma colaboração. Comunique a política a seus colaboradores.
Aplicar a política à oferta de dados quando usada em consultas de forma livre. Se você permitir consultas de forma livre em suas ofertas de dados, poderá especificar políticas a serem aplicadas a essas consultas na especificação da oferta de dados. Essas políticas são aplicadas às políticas existentes do Snowflake em suas tabelas de origem.

Aplicar a política do Snowflake aos dados de origem¶

As políticas do Snowflake aplicadas aos dados de origem também se aplicam à exibição da oferta de dados na colaboração.

Se você aplicar políticas do Snowflake aos dados de origem, informe seus colaboradores sobre elas, para que eles não tentem executar, sem saber, uma consulta que faça junção em uma coluna que não pode ser unida ou que não atenda aos requisitos de agregação. Mencione as políticas do Snowflake no campo description da oferta de dados.

Importante

Ao registrar uma oferta de dados que tem políticas de dados do Snowflake, você deve usar uma função que não esteja sujeita a essas políticas ou suspender temporariamente a política até que os dados sejam registrados.

Isso deve ser feito porque o Snowflake Data Clean Rooms executa uma consulta de validação na tabela de origem como parte do processo de registro. Se a consulta de teste não retornar resultados significativos, o registro falhará. Algumas políticas de dados do Snowflake podem provocar falha no teste. Por exemplo, uma tabela pode ter uma política de agregação, e a consulta de validação não retornará linhas suficientes para atender ao requisito de tamanho mínimo de grupo da política de agregação.

Aplicar a política do Snowflake à oferta de dados (somente para uso da consulta de forma livre)¶

Você pode aplicar as políticas do Snowflake aos seus dados compartilhados quando eles forem acessados por meio de consultas de forma livre, sem aplicá-las aos dados de origem. Essas políticas são aplicadas além das políticas do Snowflake que são aplicadas diretamente à tabela de origem.

Para adicionar políticas SQL de forma livre aos seus dados:

Crie uma política de um tipo compatível com o Collaboration Data Clean Rooms.
Adicione as seguintes informações à especificação da oferta de dados:
- Defina allowed_analyses: template_and_freeform_sql.
- Adicione uma seção freeform_sql_policies à entrada do conjunto de dados.
- Adicione as seções de tipo de política apropriadas em freeform_sql_policies, listando as políticas do Snowflake que você criou e a quais colunas de colaboração elas são aplicadas. Os tipos de política compatíveis são:
  - aggregation_policy: uma única política de agregação com chaves de entidade opcionais.
  - projection_policies: uma matriz de políticas de projeção, cada uma com vinculações de coluna.
  - join_policy: uma única política de junção com vinculações de coluna opcionais.
  - masking_policies: uma matriz de políticas de mascaramento, cada uma com vinculações de coluna.
  - row_access_policy: uma única política de acesso a linhas com vinculações de colunas opcionais.
A função que registra a oferta de dados deve ter o privilégio USAGE nas políticas.

Os colaboradores veem os tipos de política aplicados aos seus dados quando chamam COLLABORATION.VIEW_DATA_OFFERINGS.

Você pode reutilizar uma política em várias colunas de várias tabelas.

Exemplo:

CREATE OR REPLACE AGGREGATION POLICY my_db.public.my_agg_policy AS ()
  RETURNS AGGREGATION_CONSTRAINT ->
    AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5);

# Tell data clean rooms to set your aggregation policy on the hashed_email column of
# the data offering
api_version: 2.0.0
spec_type: data_offering
version: 1
name: my_favorite_dataset
datasets:
  - alias: test_freeform_restricted_agg
    data_object_fqn: samooha_provider_sample_database.audience_overlap.customers
    allowed_analyses: template_and_freeform_sql
    object_class: custom
    freeform_sql_policies:
      aggregation_policy:
        name: my_db.public.my_agg_policy
        entity_keys:
          - hashed_email
...

Políticas de modelo do Snowflake Data Clean Room¶

O Snowflake Data Clean Rooms também oferecem suporte ao próprio sistema de políticas, além do sistema de políticas do Snowflake. Cada provedor de dados em uma colaboração pode definir as seguintes políticas na oferta de dados:

Uma política de junção que especifica em quais colunas é possível unir.
Uma política de coluna que especifica quais colunas podem ser projetadas.
Uma política de ativação que especifica quais colunas podem ser ativadas.

Um provedor de dados pode definir essas políticas na especificação da oferta de dados:

Se a category da coluna é join_standard ou join_custom, a coluna é adicionada à política de junção da sala limpa.
Se a category da coluna é definida como qualquer outro valor, a coluna é adicionada à política de coluna da sala limpa.
Se o valor activation_allowed da coluna é definido como TRUE, ele também é adicionado à política de ativação da sala limpa.

As políticas são aplicadas quando um modelo tem o filtro de verificação de política apropriado. Esses filtros são: join_policy, column_policy, activation_policy, join_and_column_policy. No momento da execução do modelo, esses filtros validam que as colunas referenciadas são permitidas pela política correspondente definida na especificação da oferta de dados. Haverá falha no modelo se um filtro for aplicado a uma coluna que não faça parte da política especificada.

Por exemplo, ambos col1 e col2 devem fazer parte das políticas de junção do provedor de dados (category: join_standard ou category: join_custom), ou o seguinte trecho de modelo vai gerar um erro:

SELECT *
FROM T1
JOIN T2
ON {{ t1_col | sqlsafe | join_policy }} = {{ t2_col | sqlsafe | join_policy }}

Organizando ofertas de dados com caminhos de nomenclatura¶

Você pode usar caminhos de nomenclatura para agrupar ofertas de dados conceitualmente. Isso é particularmente eficaz porque cada oferta de dados representa uma ou mais tabelas ou exibições. As tabelas individuais são acessadas usando a sintaxe collaborator alias.data offering ID.dataset alias, em que o ID da oferta de dados é uma combinação dos valores de nome e versão fornecidos pelo usuário, e o alias é uma única tabela na oferta.

Considere o nome, a versão e o alias como um sistema de escopo ao registrar suas ofertas de dados, o que permite que você organize seus dados por oferta e alias. Por exemplo, você pode registrar a seguinte oferta de dados de vendas, em que cada tabela é específica a um estado dos US:

api_version: 2.0.0
spec_type: data_offering
version: v0
name: examplecorp_sales_by_state
datasets:
 - alias: AL
   data_object_fqn: mydb.mysch.al_data
 - alias: NY
   data_object_fqn: mydb.mysch.ny_data
 - alias: CA
   data_object_fqn: mydb.mysch.ca_data

O executor de análise faz referência a essas tabelas como user_alias.offering_id.AL, user_alias.offering_id.NY e user_alias.offering_id.CA.