Colunas¶

Existem três tabelas nesta seção:

• A primeira tabela fornece um exemplo de cada valor de coluna.

• A segunda tabela define as colunas na exibição ACCESS_HISTORY.

• A terceira tabela define os campos na matriz JSON para as colunas BASE_OBJECTS_ACCESSED, DIRECT_OBJECTS_ACCESSED e OBJECTS_MODIFIED.

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]

[
  {
    "objectDomain": "STRING",
    "objectId":  NUMBER,
    "objectName": "STRING",
    "columns": [
      {
        "columnId": "NUMBER",
        "columnName": "STRING",
        "baseSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ],
        "directSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ]
      }
    ]
  },
  ...
]

{
  "objectDomain": STRING,
  "objectName": STRING,
  "objectId": NUMBER,
  "operationType": STRING,
  "properties": ARRAY
}

[
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "SSN",
        "policies": [
          {
              "policyName": "governance.policies.ssn_mask",
              "policyId": 68811,
              "policyKind": "MASKING_POLICY"
          }
        ]
      }
    ],
    "objectDomain": "VIEW",
    "objectId": 66564,
    "objectName": "GOVERNANCE.VIEWS.V1",
    "policies": [
      {
        "policyName": "governance.policies.rap1",
        "policyId": 68813,
        "policyKind": "ROW_ACCESS_POLICY"
      }
    ]
  }
]

Os campos na matriz JSON para as colunas DIRECT_OBJECTS_ACCESSED, BASE_OBJECTS_ACCESSED, OBJECTS_MODIFIED e POLICIES_REFERENCED estão descritos abaixo.

Os campos para a coluna OBJECT_MODIFIED_BY_DDL são descritos abaixo.

Para o campo properties:

• Atômica: um valor por propriedade (por exemplo, um comment tem um único valor de cadeia de caracteres, a propriedade enabled é um booleano e tem um valor).

• Composta: a propriedade tem múltiplos valores (por exemplo allowed_values para uma tag, política de mascaramento).

As propriedades compostas são registradas em uma matriz JSON. Por exemplo, se uma tabela contiver uma única coluna chamada EMAIL, a coluna será registrada da seguinte forma:

columns: {
  "email": {
    objectId: {
      "value": 1
    },
    "subOperationType": "ADD"
  }
}

O valor subOperationType pode ser um dos seguintes:

• ADD especifica a adição de uma propriedade composta (por exemplo, adicionar uma coluna, definir valores permitidos).

• DROP especifica a remoção de uma propriedade composta.

• ALTER especifica a modificação de uma propriedade composta.

O objectId especifica o identificador para a coluna ou objeto, exceto para valores de tag permitidos que não possuem um identificador.

Notas de uso¶

Notas gerais

• A visualização exibe dados a partir de 22 de fevereiro de 2021.

• A latência da visualização pode ser de até 180 minutos (3 horas).

• Para aumentar o desempenho, filtre as consultas na coluna QUERY_START_TIME e escolha períodos mais curtos. Para amostras de consulta, consulte Consulta da exibição ACCESS_HISTORY.

• Visualizações seguras. O registro contém a tabela base subjacente (ou seja BASE_OBJECTS_ACCESSED) para gerar a visualização. Exemplos incluem consultas em outras visualizações do Account Usage e consultas em tabelas base para operações de extração, transformação e carga (ou seja, ETL).

• Registros na exibição QUERY_HISTORY do Account Usage nem sempre são gravados na exibição ACCESS_HISTORY. A estrutura da instrução SQL determina se o Snowflake registra uma entrada na exibição ACCESS_HISTORY.

• Especificar a cláusula USING ao consultar esta exibição pode fazer com que colunas não referenciadas sejam registradas no campo DIRECT_OBJECTS_ACCESSED. Como alternativa, substitua a cláusula USING por uma cláusula JOIN ... ON .... Para obter mais detalhes, consulte:

  • JOIN e USING (no tópico de referência JOIN)

  • Rastreamento da movimentação de dados em estágios confidenciais (no exemplo de consulta ao histórico de acesso)

Leia as notas de consulta

Esta exibição oferece suporte a consultas de leitura do seguinte tipo:

• SELECT incluindo CREATE TABLE … AS SELECT (como CTAS).

  • O Snowflake registra a subconsulta SELECT em uma operação CTAS.

• CREATE TABLE … CLONE

  • O Snowflake registra a tabela de origem em uma operação CLONE.

• COPY INTO … TABLE

  • O Snowflake registra esta consulta somente quando a tabela é especificada como a fonte em uma cláusula FROM.

• Operações DML que leem dados (por exemplo, contém uma subconsulta SELECT, especifica certas colunas em WHERE ou JOIN): INSERT … SELECT, UPDATE, DELETE e MERGE.

• UDFs e UDFs tabulares de SQL (UDTFs) se as tabelas estiverem incluídas nas consultas dentro das funções. Isso é registrado no campo BASE_OBJECTS_ACCESSED.

  Para obter mais detalhes sobre UDFs, consulte as notas UDF (neste tópico).

Gravação de notas de operação

Esta exibição oferece suporte às operações de gravação do seguinte tipo:

• GET <estágio_interno>

• PUT <estágio_interno>

• DELETE

• TRUNCATE

• INSERT

  • INSERT INTO … FROM SELECT *

  • INSERT INTO TABLE … VALUES ()

• MERGE INTO … FROM SELECT *

• UPDATE

  • UPDATE TABLE … FROM SELECT * FROM …

  • UPDATE TABLE … WHERE …

• Instruções de carregamento de dados:

  • COPY INTO TABLE FROM internalStage

  • COPY INTO TABLE FROM externalStage

  • COPY INTO TABLE FROM externalLocation

• Instruções de descarregamento de dados:

  • COPY INTO internalStage FROM TABLE

  • COPY INTO externalStage FROM TABLE

  • COPY INTO externalLocation FROM TABLE

• CREATE:

  • CREATE DATABASE … CLONE

  • CREATE SCHEMA … CLONE

  • CREATE TABLE … CLONE

  • CREATE TABLE … AS SELECT

• Para operações de escrita que chamam a função CASE para determinar as colunas a serem acessadas, como uma instrução CTAS com a função CASE na consulta SELECT, todas as colunas referenciadas em cada ramo CASE são registradas na coluna BASE_OBJECTS_ACCESSED, na coluna DIRECT_OBJECTS_ACCESSED, ou em ambas as colunas dependendo de como a instrução CTAS é escrita.

Notas de compartilhamento de dados

Se uma conta do provedor de Data Sharing compartilhar objetos com contas do consumidor de Data Sharing por um compartilhamento:

• Contas do provedor: As consultas e logs dos objetos compartilhados executados na conta do provedor não ficam visíveis para as contas de consumidor de Data Sharing.

• Contas de consumidor: As consultas de compartilhamento de dados executadas na conta do consumidor são registradas e ficam visíveis somente para a conta de consumidor, e não para a conta de provedor de Data Sharing.

  Por exemplo, se o provedor compartilha uma tabela e uma exibição construída a partir da tabela para a conta do consumidor, e há uma consulta sobre a exibição compartilhada, o Snowflake registra o acesso à exibição compartilhada na coluna BASE_OBJECTS_ACCESSED. Esse registro, que inclui os valores columnName e objectName, permite que o consumidor saiba qual objeto foi acessado em sua conta e também protege o provedor porque a tabela subjacente (através dos valores objectId e columnId) não é revelada ao consumidor.

• Para linhagem de colunas:

  Se um provedor de Data Sharing disponibilizar uma exibição para o consumidor de Data Sharing, as colunas de origem da exibição não ficarão visíveis para o consumidor porque as colunas são originadas do provedor de Data Sharing.

  Se o consumidor do Data Sharing mover os dados da exibição compartilhada para uma tabela, Snowflake não registra as colunas de exibição como baseSources para a tabela recém-criada.

• Para compartilhar UDFs e UDTFs:

  • Na conta do consumidor, a exibição ACCESS_HISTORY local registra a UDF/UDTF que foi compartilhada pelo provedor quando a UDF/UDTF compartilhada é invocada pelo consumidor.

  • Na conta do provedor, a exibição ACCESS_HISTORY local registra o uso do provedor de uma UDF/UDTF compartilhada. Os usuários na conta do consumidor não podem ver como a conta do provedor utiliza a UDF/UDTF compartilhada.

• Para rastreamento de referências de políticas:

  A coluna POLICIES_REFERENCED contém políticas que são locais para a conta que consulta os dados.

  Se um provedor compartilhar uma tabela protegida por política e um consumidor acessar essa tabela, o consumidor não poderá ver a política que o provedor definiu na tabela ou suas colunas.

  Se um consumidor criar uma exibição (v1) do objeto compartilhado, definir uma política para a exibição (v1) ou suas colunas, e um usuário na conta do consumidor acessar a exibição protegida (v1) ou outra exibição (v2) criada a partir da exibição protegida (v1), a exibição ACCESS_HISTORY na conta do consumidor terá a política que protege a exibição (v1) e suas colunas. O provedor não pode ver o registro que corresponde a v1.

Notas de mascaramento baseado em tags

Se um usuário acessar uma tabela ou exibição protegida por uma política de mascaramento baseada em tags, a coluna POLICIES_REFERENCED terá a política de mascaramento aplicada pela tag quando o Snowflake aplica a política de mascaramento na coluna protegida.

A exibição ACCESS_HISTORY não registra nenhuma informação da tag.

UDFs e procedimentos armazenados

Estas notas se aplicam às funções externas, UDFs e UDTFs para todas as linguagens, inclusive quando estas funções têm a propriedade SECURE, e procedimentos armazenados com direitos de proprietário e direitos de chamador:

Detalhes da coluna:

• A coluna DIRECT_OBJECTS_ACCESSED registra a menção explícita destas funções e procedimentos em uma consulta.

  O Snowflake não registra UDFs aninhadas (ou seja, uma UDF mencionada na definição de outra UDF) nesta coluna.

• A coluna BASE_OBJECTS_ACCESSED registra funções externas, funções compartilhadas, UDFs não SQL, e procedimentos armazenados que são chamados em uma consulta.

• A coluna OBJECTS_MODIFIED registra:

  • A UDF/UDTF quando o resultado da chamada da função copia o resultado para outra coluna.

  • A UDF, UDTF e uma função externa podem ser registradas nas matrizes para baseSources e directSources, dependendo de como a consulta é escrita.

Sem suporte

Esta visualização não registra os acessos dos seguintes tipos:

• Funções de tabela fornecidas pelo Snowflake ou outras exibições Account Usage.

• RESULT_SCAN para obter resultados prévios.

• Sequências, incluindo a geração de novos valores.

• Visualizações intermediárias acessadas entre a tabela base e o objeto direto.

  Por exemplo, considere uma consulta em View_A com a seguinte estrutura de objetos: View_A » View_B » View_C » Base_Table.

  A exibição ACCESS_HISTORY registra a consulta na Exibição_A e na Tabela_base, não na Exibição_B e Exibição_C.

• As operações para atualizar fluxos.

• Movimento de dados resultante da replicação.

Notas de uso: Linhagem de colunas¶

Estas notas adicionais dizem respeito à linhagem de colunas:

Operações com suporte

Detalhes da linhagem de colunas para as seguintes operações SQL:

• CREATE TABLE … AS SELECT (ou seja CTAS)

• CREATE TABLE … CLONE

• INSERT … SELECT …

• MERGE

• UPDATE, duas variações possíveis, por exemplo:

  • Autoatualização:

    update mydb.s1.t1 set col_1 = col_1 + 1;
    

    Copy

  • Atualização de duas tabelas:

    update mydb.s1.t1 from mydb.s2.t2 set t1.col1 = t2.col1;
    

    Copy

Condições de consulta

• Perfil/plano de consulta

  O plano de consulta que o Snowflake escreve determina se a exibição ACCESS_HISTORY contém a linhagem de colunas. Se uma coluna precisar ser avaliada como parte do plano de consulta, Snowflake contém a coluna na exibição ACCESS_HISTORY, mesmo se o resultado final do plano de consulta for que a coluna não está incluída no resultado final.

  Por exemplo, considere a seguinte instrução INSERT com uma cláusula WHERE para um determinado valor de coluna:

  insert into a(c1)
  select c2
  from b
  where c3 > 1;
  

  Copy

  Mesmo que a cláusula WHERE avalie como FALSE, Snowflake registra a coluna c2 como uma coluna de origem para a coluna c1. A coluna c3 não está listada como coluna de origem para baseSources ou directSources.

• Colunas mascaradas:

  • A coluna mascarada é sempre listada no campo directSources.

  • O registro no campo baseSources depende da definição da política. Por exemplo:

    • Se as condições da política de mascaramento utilizarem uma função CASE, então todas as colunas referenciadas em cada uma das ramificações CASE são registradas no campo baseSources.

    • Se as condições da política de mascaramento especificarem apenas um valor constante (por exemplo, *****), então o campo baseSources estará vazio.

• UDFs:

  • Ao passar uma coluna como argumento para um UDF e escrever o resultado para outra coluna, a coluna que é passada como argumento é registrada no campo directSources. Por exemplo:

    insert into A(col1) select f(col2) from B;
    

    Copy

    Neste exemplo, Snowflake registra col2 no campo directSources porque a coluna é um argumento para o UDF chamado f.

  • O registro no campo baseSources depende da definição do UDF.

Exibição de colunas

As colunas de exibição não são consideradas colunas de origem e não são listadas no campo baseSources quando dados de uma coluna de exibição são copiados para uma coluna de tabela. As colunas de exibição neste caso estão listadas no campo directSources.

Subconsulta EXISTS

As colunas que são referenciadas na cláusula de subconsulta EXISTS não são consideradas como colunas de origem.

Notas de uso: coluna OBJECT_MODIFIED_BY_DDL¶

• Cláusulas IF [ NOT ] EXISTS.

  A coluna OBJECT_MODIFIED_BY_DDL só registra CREATE ou REPLACE ao criar ou modificar um objeto.

• O Snowflake oferece suporte aos seguintes domínios de objeto.

  • Tabela e tabela externa.

  • Exibição e exibição materializada

  • Esquema

  • Banco de dados.

A coluna registra essas alterações com base nas seguintes operações SQL. As operações DROP e UNDROP se aplicam a tabelas e exibições, não a colunas.

CREATE OR REPLACE

ALTER ... { SET | UNSET }

ALTER ... ADD ROW ACCESS POLICY

ALTER ... DROP ROW ACCESS POLICY

ALTER ... DROP ALL ROW ACCESS POLICIES

DROP | UNDROP

A tabela a seguir resume a relação entre operações DDL, domínios suportados e as propriedades dos registros do Snowflake.