Gerenciamento do Snowpipe

Este tópico descreve as tarefas administrativas associadas ao gerenciamento do Snowpipe.

Neste tópico:

Eliminação de arquivos preparados depois que o Snowpipe carrega os dados

Os objetos de canal não oferecem suporte à opção de cópia PURGE. O Snowpipe não pode excluir arquivos preparados automaticamente quando os dados são carregados com sucesso em tabelas.

Para remover arquivos preparados de que você não precisa mais, recomendamos executar periodicamente o comando REMOVE para excluir os arquivos.

Alternativamente, configure qualquer recurso de gerenciamento do ciclo de vida fornecido por seu provedor de serviços de armazenamento em nuvem.

Carregamento de dados históricos

Nota

As informações nesta seção dizem respeito a carregamentos automatizados de dados usando notificações de eventos. Chamadas para a API REST Snowpipe podem carregar dados históricos sem a necessidade de etapas adicionais.

Uma instrução ALTER PIPE … REFRESH copia um conjunto de arquivos de dados preparados nos 7 dias anteriores para a fila de ingestão do Snowpipe para carregamento na tabela de destino. Se você quiser carregar dados de arquivos preparados anteriormente, recomendamos as seguintes etapas:

  1. Carregue os dados históricos na tabela de destino executando uma instrução COPY INTO <tabela>.

  2. Configure carregamentos automáticos de dados usando o Snowpipe com notificações de eventos. Os arquivos que foram preparados recentemente acionarão notificações de eventos para ingestão na tabela de destino. Como os arquivos de dados históricos não acionam notificações de eventos, eles não são carregados duas vezes.

    Para instruções, consulte:

    Amazon S3

    Automação do Snowpipe para Amazon S3

    Google Cloud Storage

    Automação do Snowpipe para Google Cloud Storage

    Microsoft Azure

    Automação do Snowpipe para o armazenamento de blobs Microsoft Azure

  3. Execute uma instrução ALTER PIPE … REFRESH para enfileirar arquivos preparados entre as etapas 1 e 2. A instrução verifica o histórico de carregamento da tabela de destino e do canal para garantir que os mesmos arquivos não sejam carregados duas vezes.

Recriação de canais

Recriar um canal (usando uma instrução CREATE OR REPLACE PIPE) é necessário para modificar a maioria das propriedades do canal.

Esta seção descreve considerações e práticas recomendadas a seguir ao recriar canais.

Recriação de canais para carregamentos automatizados de dados

Ao recriar um canal que automatiza os carregamentos de dados usando notificações de eventos, recomendamos que você complete as seguintes etapas:

  1. Pause o canal (usando ALTER PIPE … SET PIPE_EXECUTION_PAUSED = verdadeiro).

  2. Consulte a função SYSTEM$PIPE_STATUS e verifique se o estado de execução do canal é PAUSED.

  3. Recrie o canal (usando CREATE OR REPLACE PIPE).

  4. Pause o canal novamente.

  5. Revise as etapas de configuração de seu serviço de mensagens em nuvem para garantir que as configurações ainda sejam precisas:

  6. Retome o canal (usando ALTER PIPE … SET PIPE_EXECUTION_PAUSED = falso).

  7. Consulte novamente a função SYSTEM$PIPE_STATUS e verifique se o estado de execução do canal é RUNNING.

Histórico de carregamento

O histórico de carregamento para operações do Snowpipe é armazenado nos metadados do objeto de canal. Quando um canal é recriado, o histórico de carregamento é descartado. Em geral, esta condição só afeta os usuários se eles executarem posteriormente uma instrução ALTER PIPE … REFRESH no canal. Isso pode carregar dados duplicados de arquivos preparados no local de armazenamento para o canal se os dados já tiverem sido carregados com sucesso e os arquivos não forem excluídos posteriormente.

Alteração dos parâmetros de nuvem do estágio referenciado

Os parâmetros de nuvem de um estágio externo incluem o seguinte:

  • URL

  • STORAGE_INTEGRATION

  • ENCRYPTION

Após o Snowpipe ter sido configurado com sucesso, se você precisar modificar qualquer um dos parâmetros de nuvem do estágio referenciado, recomendamos que você complete as seguintes etapas:

  1. Pause o canal (usando ALTER PIPE … SET PIPE_EXECUTION_PAUSED = verdadeiro). Aguarde que todos os arquivos atualmente enfileirados sejam carregados na tabela de destino.

  2. Modifique os parâmetros de estágio conforme necessário (usando ALTER STAGE).

  3. Retome o canal (usando ALTER PIPE ... SET PIPE_EXECUTION_PAUSED = false).

Como os canais não são transacionais, essas etapas garantem que o Snowpipe enfileire os arquivos usando os valores de parâmetro de estágio mais recentes.

Aviso

Modificar o parâmetro URL de um estágio pode fazer com que qualquer canal que aproveite as mensagens em nuvem para acionar carregamentos de dados (ou seja, em que AUTO_INGEST = TRUE) pare de funcionar.

Transferência da propriedade do canal

Complete as seguintes etapas para transferir a propriedade de um canal:

  1. Ajuste o parâmetro PIPE_EXECUTION_PAUSED para TRUE.

    Esse parâmetro permite pausar ou retomar um canal. O parâmetro é suportado nos seguintes níveis:

    • Conta

    • Esquema

    • Canal

    No nível do canal, o proprietário do objeto (ou uma função pai em uma hierarquia de funções) pode definir o parâmetro para pausar ou retomar um canal individual.

    Um administrador de conta (usuário com a função ACCOUNTADMIN) pode definir esse parâmetro no nível da conta para pausar ou retomar todos os canais da conta. Da mesma forma, um usuário com o privilégio MODIFY sobre o esquema pode pausar ou retomar os canais no nível do esquema. Observe que esse controle de domínio maior só afeta canais para os quais o parâmetro ainda não foi definido em um nível inferior; por exemplo, pelo proprietário no nível do objeto.

  2. Transfira a propriedade do canal usando GRANT OWNERSHIP.

  3. Force a retomada do canal (usando SYSTEM$PIPE_FORCE_RESUME).

    Esta etapa permite ao novo proprietário avaliar o status do canal e determinar quantos arquivos de dados estão esperando para serem carregados usando SYSTEM$PIPE_STATUS. Recomendamos verificar se apenas os arquivos aprovados para carregamento na tabela de destino estão enfileirados.

Modificação da instrução COPY em uma definição de canal

Complete as seguintes etapas para modificar a instrução COPY em uma definição de canal; por exemplo, quando as colunas são adicionadas à tabela de destino.

Para executar os comandos nesta seção, a função atual do usuário deve ter o privilégio OWNERSHIP sobre o canal.

  1. Pause o canal (usando ALTER PIPE … SET PIPE_EXECUTION_PAUSED = verdadeiro).

  2. Consulte a função SYSTEM$PIPE_STATUS e verifique se o estado de execução do canal é PAUSED e a contagem do arquivo pendente é 0.

  3. Recrie o canal para mudar a instrução COPY na definição. Escolha uma das seguintes opções:

  4. Pause o canal novamente.

  5. Revise as etapas de configuração de seu serviço de mensagens em nuvem para garantir que as configurações ainda sejam precisas:

  6. Retome o canal (usando ALTER PIPE … SET PIPE_EXECUTION_PAUSED = falso).

  7. Consulte novamente a função SYSTEM$PIPE_STATUS e verifique se o estado de execução do canal é RUNNING.

Nota

Os metadados de carregamento de arquivo estão associados ao objeto de canal e não à tabela. Recriar o canal remove o histórico de arquivos carregados. Certifique-se de que os arquivos já carregados pelo Snowpipe não sejam reenviados acidentalmente ao canal e carregados novamente na tabela de destino. Para visualizar o histórico de consultas de uma tabela, consulte a função COPY_HISTORY.

Retomada de um canal desatualizado

Nota

Esta seção diz respeito apenas a objetos de canal que aproveitam as mensagens em nuvem para acionar carregamentos de dados (ou seja, onde AUTO_INGEST = TRUE na definição do canal).

Quando um canal é pausado, as mensagens de eventos recebidas para o canal entram em um período de retenção limitado. O período é de 14 dias por padrão. Se um canal for pausado por mais de 14 dias, ele é considerado desatualizado.

Para retomar um canal desatualizado, uma função qualificada deve chamar a função SYSTEM$PIPE_FORCE_RESUME e inserir o argumento STALENESS_CHECK_OVERRIDE. Este argumento indica um entendimento de que a função está retomando um canal desatualizado.

Por exemplo, retomar o canal stalepipe1 desatualizado no banco de dados e esquema mydb.myschema:

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1','staleness_check_override');
Copy

Enquanto o canal desatualizado foi pausado, se a propriedade do canal foi transferida para outra função, então a retomada do canal requer o argumento adicional OWNERSHIP_TRANSFER_CHECK_OVERRIDE. Por exemplo, retomar o canal stalepipe2 desatualizado no banco de dados e esquema mydb.myschema que foi transferido para uma nova função:

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1','staleness_check_override, ownership_transfer_check_override');
Copy

Como uma notificação de evento recebida enquanto um canal é pausado chega ao final do período de retenção limitado, o Snowflake programa que ele seja descartado dos metadados internos. Se o canal for retomado mais tarde, o Snowpipe processa essas notificações mais antigas com base no melhor esforço. A Snowflake não pode garantir que elas sejam processadas.

Por exemplo, se um canal for retomado 15 dias após ter sido pausado, Snowpipe geralmente ignora qualquer notificação de evento recebida no primeiro dia em que o canal foi pausado (ou seja, que agora tem mais de 14 dias). Se o canal for retomado 16 dias após ter sido pausado, Snowpipe geralmente ignora qualquer notificação de evento recebida no primeiro e segundo dias após a pausa do canal. E assim por diante.