Introdução às tarefas

Uma tarefa pode executar qualquer um dos seguintes tipos de código SQL:

  • Instrução SQL única

  • Chamada de um procedimento armazenado

  • Lógica de procedimentos usando Script Snowflake

As tarefas podem ser combinadas com fluxos de tabela para fluxos de trabalho ELT contínuos a fim de processar linhas de tabela recentemente alteradas. Os fluxos garantem uma semântica exatamente uma vez para dados novos ou alterados em uma tabela.

As tarefas também podem ser usadas independentemente para gerar relatórios periódicos, inserindo ou mesclando linhas em uma tabela de relatório ou para realizar outros trabalhos periódicos.

Neste tópico:

Recursos de computação

As tarefas exigem recursos de computação para executar código SQL. Qualquer um dos modelos de computação a seguir pode ser escolhido para tarefas individuais:

  • Gerenciado pelo Snowflake (ou seja, um modelo de computação sem servidor)

  • Gerenciado pelo usuário (ou seja, warehouse virtual)

Tarefas sem servidor

O modelo de computação sem servidor para tarefas permite que você conte com recursos de computação gerenciados pelo Snowflake em vez de warehouses virtuais gerenciados pelo usuário. Os recursos de computação são automaticamente redimensionados pelo Snowflake, conforme necessário para cada carga de trabalho. O Snowflake determina o tamanho ideal dos recursos de computação para uma determinada execução com base em uma análise dinâmica de estatísticas para as execuções mais recentes da mesma tarefa. O tamanho máximo para uma execução de tarefa sem servidor é equivalente a um warehouse XXLARGE. Múltiplos carregamentos de trabalho em sua conta possuem um conjunto comum de recursos de computação.

A opção de habilitar o modelo de computação sem servidor deve ser especificada ao criar uma tarefa. A sintaxe CREATE TASK é quase idêntica às tarefas que dependem de warehouses virtuais gerenciados pelo usuário. Omita o parâmetro WAREHOUSE para permitir que o Snowflake gerencie os recursos de computação para a tarefa. Note que a função que executa o comando CREATE TASK deve ter o privilégio global EXECUTE MANAGED TASK. Para obter mais informações sobre os requisitos de controle de acesso para tarefas, consulte Segurança de tarefas.

O faturamento da execução de tarefas sem servidor difere um pouco do modelo padrão de consumo de crédito para tarefas que dependem de warehouses para recursos de computação. Para obter mais informações, consulte Custos da tarefa.

Nota

As tarefas sem servidor não podem chamar os seguintes tipos de objetos e funções:

  • UDFs (funções definidas pelo usuário) que contêm código Java ou Python.

  • Procedimentos armazenados gravados em Scala (usando Snowpark), ou que chamam UDFs que contêm código Java ou Python.

Tarefas gerenciadas pelo usuário

Se preferir, você pode gerenciar os recursos de computação para tarefas individuais especificando um warehouse virtual existente ao criar a tarefa. Esta opção requer que você escolha um warehouse de tamanho adequado para as ações SQL que são executadas pela tarefa.

Escolha do tamanho de um warehouse

Se você optar por utilizar os warehouses existentes para fornecer os recursos de computação para tarefas individuais, recomendamos seguir as práticas recomendadas descritas em Considerações sobre warehouses. Sugerimos que você analise o tempo médio de execução de uma única tarefa ou DAG de tarefas usando um warehouse específico com base no tamanho e clustering do warehouse, bem como se o warehouse é ou não compartilhado por múltiplos processos ou se é dedicado à execução desta única tarefa (ou DAG).

Consulte a TASK_HISTORY exibição Account Usage (no banco de dados compartilhado SNOWFLAKE). A diferença média entre os tempos agendados e completados para uma tarefa é o tempo médio de execução esperado para a tarefa, incluindo qualquer período em que a tarefa esteve enfileirada. Uma tarefa é enfileirada quando outros processos estão utilizando todos os recursos de computação do warehouse.

A menos que as instruções SQL definidas para as tarefas possam ser otimizadas (seja regravando as instruções ou usando procedimentos armazenados), então este seria o tempo médio esperado de execução da tarefa (ou DAG). Escolha o tamanho certo para o warehouse com base em sua análise para garantir que a tarefa (ou DAG) termine de ser executada dentro desse período.

O diagrama a seguir mostra um período de 1 minuto no qual uma única tarefa ficou em fila por 20 segundos e depois foi executada por 40 segundos.

Example task batch window

O diagrama a seguir mostra um DAG que requer 5 minutos, em média, para ser completado em cada execução. O diagrama mostra o período para a conclusão de 2 execuções do DAG. Esse período é calculado a partir do momento em que a tarefa raiz está agendada para começar até que a última tarefa filha no DAG tenha terminado de ser executada. Neste exemplo, o DAG é compartilhado com outras operações simultâneas que fazem fila enquanto cada uma das 3 tarefas do DAG está em execução. Estas operações simultâneas consomem todos os recursos disponíveis quando cada tarefa no DAG termina e antes que a próxima tarefa comece a ser executada. Como resultado, o período para cada tarefa inclui algum tempo de fila de espera enquanto aguarda que outras operações terminem e liberem os recursos de computação.

Note que mesmo que este DAG fosse executado em um warehouse dedicado, um breve atraso seria esperado após uma tarefa predecessora terminar e qualquer tarefa filha ser executada; entretanto, nenhum enfileiramento de recursos compartilhados com outras operações ocorreria. O tamanho do warehouse que você escolher deve ser grande o suficiente para acomodar várias tarefas filhas que são acionadas simultaneamente pelas tarefas predecessoras.

Example DAG batch window

Recomendações para a escolha de um modelo de cálculo

A tabela a seguir descreve vários fatores que podem ajudar você a decidir quando usar tarefas sem servidor versus tarefas gerenciadas pelo usuário:

Categoria

Tarefas sem servidor

Tarefas gerenciadas pelo usuário

Notas

Número, duração e previsibilidade de cargas de trabalho de tarefas simultâneas

Recomendado quando não é possível utilizar totalmente um warehouse porque poucas tarefas são executadas simultaneamente ou são executadas rapidamente (em menos de 1 minutos).

Como o tamanho dos recursos de computação escolhidos é baseado no histórico de execuções anteriores, tarefas com execuções relativamente estáveis são boas candidatas para tarefas sem servidor.

Recomendado quando você pode utilizar plenamente um único warehouse programando várias tarefas simultâneas para aproveitar os recursos de computação disponíveis.

Também recomendado para cargas com picos ou imprevisíveis nos recursos de computação. Warehouses multicluster com suspensão automática e retomada automática habilitadas podem ajudar a reduzir seu consumo de crédito.

Para tarefas sem servidor, o Snowflake faz o faturamento sua conta com base no uso real dos recursos de computação.

De outra forma, o faturamento dos warehouses gerenciados pelo usuário é baseado no tamanho do warehouse, com um mínimo de 60 segundos cada vez que o warehouse é retomado, independentemente dos recursos de computação utilizados.

Intervalo programado

Recomendado quando o cumprimento do intervalo programado é altamente importante.

Se uma execução de uma tarefa autônoma ou DAG programado exceder quase todo esse intervalo, o Snowflake aumenta o tamanho dos recursos de computação (até um máximo do equivalente a um warehouse 2X-Large).

Recomendado quando o cumprimento do intervalo programado é menos importante.

Intervalo programado refere-se ao intervalo de tempo entre as sucessivas execuções programadas de uma tarefa autônoma ou tarefa raiz em um DAG.

Note que o aumento dos recursos de computação reduz o tempo de execução de alguns, mas não todos, códigos SQL e pode não ser suficiente para garantir que uma execução de tarefa seja concluída dentro da janela do lote.

Observe que o tamanho máximo para uma execução de tarefa sem servidor é equivalente a um warehouse XXLARGE. Se a carga de trabalho de uma tarefa exigir um warehouse maior, crie uma tarefa gerenciada pelo usuário que faça referência a um warehouse do tamanho exigido.

Agendamento de tarefas

Uma tarefa autônoma ou a tarefa raiz em um DAG geralmente é executada de acordo com um cronograma. Você pode definir o cronograma ao criar uma tarefa (usando CREATE TASK) ou mais tarde (usando ALTER TASK).

O Snowflake garante que apenas uma instância de uma tarefa com um cronograma (ou seja, uma tarefa autônoma ou a tarefa raiz em um DAG) seja executada em um determinado momento. Se uma tarefa ainda estiver em execução quando o próximo período de execução agendado ocorrer, esse tempo agendado é ignorado.

O Snowflake redimensiona automaticamente os recursos de computação para tarefas sem servidor. Para tarefas que dependem de um warehouse para fornecer recursos de computação, escolha um tamanho de warehouse apropriado para uma determinada tarefa completar sua carga de trabalho dentro do cronograma definido. Para obter mais informações, consulte Escolha do tamanho de um warehouse (neste tópico).

Agendamento de tarefas e horário de verão

A expressão cron em uma definição de tarefa suporta a especificação de um fuso horário. Uma tarefa agendada é executada de acordo com a expressão cron especificada na hora local para um determinado fuso horário. Deve-se tomar cuidado especial com relação ao agendamento de tarefas para os fusos horários que reconhecem o horário de verão. As tarefas agendadas durante horários específicos em dias em que ocorre a transição do horário padrão para o horário de verão (ou o inverso) podem ter comportamentos inesperados.

Por exemplo:

  • Durante a mudança do horário de verão para o horário padrão que ocorre no outono do hemisfério norte, uma tarefa programada para começar à 1h no fuso horário de América/Los_Angeles (isto é, 0 1 * * * America/Los_Angeles) seria executada duas vezes: uma vez à 1h e depois novamente quando 1h59min59s muda para 1h00min00s hora local. Ou seja, há dois momentos em que a hora local é 1h.

  • Durante a mudança do horário padrão para o horário de verão que ocorre na primavera do hemisfério norte, uma tarefa programada para começar às 2h no fuso horário de América/Los_Angeles (isto é, 0 2 * * * America/Los_Angeles) não seria executada porque a hora local muda de 1h59min59s muda para 3h00min00s. Isto é, não há nenhum momento durante aquele dia em que a hora local é 2h.

Para evitar execuções de tarefa inesperadas devido ao horário de verão, use uma destas opções:

  • Não agende tarefas para um horário específico entre 1h e 3h (diariamente ou em dias da semana, incluindo domingo), ou

  • Ajuste manualmente a expressão cron para tarefas agendadas durante essas horas duas vezes por ano para compensar a mudança de horário devido ao horário de verão ou

  • Utilize um formato de horário que não aplique o horário de verão, tal como UTC.

DAG de tarefas

Um Gráfico acíclico dirigido (DAG) é uma série de tarefas composta de uma única tarefa raiz e tarefas adicionais, organizadas por suas dependências. DAGs fluem em uma única direção, o que significa que uma tarefa mais adiante na série não pode provocar a execução de uma tarefa anterior (ou seja, um loop). Cada tarefa (exceto a tarefa raiz) pode ter múltiplas tarefas predecessoras (dependências); da mesma forma, cada tarefa pode ter múltiplas tarefas subsequentes (filhas) que dependem dela. Uma tarefa só é executada depois de todas as tarefas anteriores terem sido concluídas com sucesso.

A tarefa raiz deve ter um cronograma definido que inicie uma execução do DAG. Cada uma das outras tarefas tem pelo menos um predecessor definido para vincular as tarefas no DAG. Uma tarefa filha só é executada depois de todas as tarefas predecessoras terem sido concluídas com sucesso.

Você pode especificar as tarefas predecessoras ao criar uma nova tarefa (usando CREATE TASK … AFTER) ou posterior (usando ALTER TASK … ADD AFTER). O DAG é limitado a um máximo de 1.000 tarefas no total (incluindo a tarefa raiz). Uma única tarefa pode ter um máximo de 100 tarefas predecessoras e 100 tarefas filhas.

No exemplo básico a seguir, a tarefa raiz faz as Tarefas B e C serem executadas simultaneamente. A tarefa D é executada quando ambas as tarefas B e C são completadas.

Basic DAG example

O exemplo prático a seguir mostra como um DAG pode ser usado para atualizar tabelas de dimensões em um banco de dados de vendas antes de agregar dados factuais:

Sales database DAG example

Um outro exemplo mostra a tarefa final em um DAG chamando uma função externa para acionar um serviço de mensagens remotas para enviar uma notificação de que todas as tarefas anteriores foram executadas com sucesso até a conclusão.

Cloud messaging notification DAG example

Propriedade de tarefas

Todas as tarefas em um DAG devem ter o mesmo proprietário (ou seja, uma única função deve ter o privilégio OWNERSHIP sobre todas as tarefas) e ser armazenadas no mesmo banco de dados e esquema.

A transferência de propriedade de uma tarefa corta a dependência entre essa tarefa e qualquer tarefa predecessora e filha. Para obter mais informações, consulte Vínculo cortado entre tarefas predecessoras e filhas (neste tópico).

Quando a propriedade de todas as tarefas em um DAG é transferida de uma vez, através de uma das seguintes atividades, as relações entre todas as tarefas no DAG são mantidas:

  • O atual proprietário de todas as tarefas que compõem o DAG é descartado (usando DROP ROLE). A propriedade dos objetos da função descartada é transferida para a função que executa o comando DROP ROLE.

  • A propriedade de todas as tarefas que compõem o DAG é explicitamente transferida para outra função (por exemplo, executando GRANT OWNERSHIP em todas as tarefas de um esquema).

Sobreposição de execuções do DAG

Por padrão, o Snowflake assegura que apenas uma instância de um determinado DAG seja autorizada a funcionar de cada vez. A próxima execução de uma tarefa raiz só é programada depois que todas as tarefas no DAG tiverem terminado. Isto significa que se o tempo acumulado necessário para executar todas as tarefas no DAG exceder o tempo explicitamente programado determinado na definição da tarefa raiz, pelo menos uma execução do DAG é ignorada. O comportamento é controlado pelo parâmetro ALLOW_OVERLAPPING_EXECUTION na tarefa raiz; o valor padrão é FALSE. A definição do valor do parâmetro como TRUE permite que execuções do DAG se sobreponham.

Além disso, uma tarefa filha começa sua execução somente depois que todas as tarefas predecessoras da tarefa filha tenham completado com sucesso suas próprias execuções. Uma tarefa que executa operações SQL demoradas atrasa o início de qualquer tarefa filha que identifique a tarefa como predecessora.

No exemplo a seguir, uma execução do DAG está programada para começar quando uma execução anterior ainda não foi concluída. O período de sobreposição, ou simultaneidade, é identificado em vermelho. O diagrama também identifica o intervalo de tempo em que cada tarefa é enfileirada antes de ser executada no warehouse administrado pelo usuário. Observe que se forem utilizados recursos de computação gerenciados pelo Snowflake, não há período de enfileiramento:

Overlapping DAG runs

Execuções sobrepostas podem ser toleradas (ou mesmo desejáveis) quando operações SQL de leitura/gravação com execuções sobrepostas de um DAG não produzem dados incorretos ou duplicados. Entretanto, para outros DAGs, os proprietários das tarefas (ou seja, a função com o privilégio OWNERSHIP em todas as tarefas no DAG) devem definir um cronograma apropriado na tarefa raiz e escolher um tamanho de warehouse apropriado (ou usar recursos de computação gerenciados pelo Snowflake) para garantir que uma instância do DAG termine a conclusão antes que a tarefa raiz seja agendada.

Para alinhar melhor um DAG com o cronograma definido na tarefa raiz:

  1. Se possível, aumente o tempo de agendamento entre as execuções da tarefa raiz.

  2. Considere modificar tarefas de computação pesada para usar recursos de computação gerenciados pelo Snowflake. Se a tarefa depender de recursos de computação gerenciados pelo usuário, aumente o tamanho do warehouse que executa instruções SQL grandes ou complexas ou procedimentos armazenados no DAG.

  3. Analise as instruções SQL ou procedimentos armazenados executados por cada tarefa. Determine se o código pode ser reescrito para aproveitar o processamento paralelo.

Se nenhuma das soluções acima ajudar, considere se é necessário permitir execuções simultâneas do DAG definindo ALLOW_OVERLAPPING_EXECUTION = TRUE na tarefa raiz. Este parâmetro pode ser definido ao criar uma tarefa (usando CREATE TASK) ou mais tarde (usando ALTER TASK).

Visualização de tarefas dependentes em um DAG

Para ver as tarefas filhas diretas para uma tarefa raiz ou todas as tarefas em um DAG:

SQL

Consulte a função de tabela TASK_DEPENDENTS (no Snowflake Information Schema). Para recuperar todas as tarefas em um DAG, insira a tarefa raiz ao chamar a função. Se você inserir uma tarefa filha, a função retorna os filhos (e os filhos desses filhos, etc.) da tarefa especificada.

Execuções do DAG com tarefas filhas suspensas

Quando a tarefa raiz é suspensa, você pode retomar ou suspender qualquer tarefa filha usando ALTER TASK … RESUME | SUSPEND. A retomada de qualquer tarefa filha suspensa não é necessária antes que você retome a tarefa raiz.

Quando um DAG é executado com uma ou mais tarefas filhas suspensas, a execução ignora essas tarefas. Uma tarefa filha com múltiplos predecessores é executada desde que pelo menos um dos predecessores esteja em um estado de retomada, e todos os predecessores retomados sejam executados com sucesso até a conclusão.

Retomada de tarefas suspensas em um DAG

Para retomar recursivamente todas as tarefas em um DAG, consulte a função SYSTEM$TASK_DEPENDENTS_ENABLE em vez de retomar cada tarefa individualmente (usando ALTER TASK … RESUME).

Tarefa finalizadora

Uma tarefa finalizadora trata do lançamento e limpeza de recursos que um DAG usa. A tarefa finalizadora terá execução garantida se o DAG for executado e garantirá a limpeza adequada dos recursos e a conclusão das etapas necessárias em todos os cenários. Por exemplo, se uma execução de DAG usar tabelas intermediárias para rastrear dados para processamento e falhar antes que as linhas da tabela sejam consumidas, a próxima execução encontrará linhas duplicadas e reprocessará os dados, resultando em tempo de execução mais longo ou desperdício de recursos de computação. A tarefa finalizadora pode resolver esse problema descartando as linhas ou truncando a tabela conforme necessário.

A tarefa finalizadora funciona como qualquer outra tarefa em um DAG, com as seguintes diferenças:

  • Uma tarefa finalizadora está sempre associada a uma tarefa raiz. Cada tarefa raiz pode ter apenas uma tarefa finalizadora, e uma tarefa finalizadora só pode ser associada a uma tarefa raiz.

  • Uma tarefa finalizadora é agendada somente quando nenhuma outra tarefa está em execução ou na fila na execução do DAG atual e pelo menos uma tarefa no gráfico iniciou a execução. Se um gráfico for ignorado (por exemplo, a tarefa raiz for ignorada), a tarefa finalizadora não será executada. Se ALLOW_OVERLAPPING_EXECUTION for verdadeiro, a tarefa finalizadora se comportará como as outras tarefas e ainda será agendada mesmo se houver outras execuções de DAG em andamento.

  • Uma tarefa finalizadora não pode ter tarefas secundárias. Qualquer comando que tente transformar a tarefa finalizadora em uma predecessora falhará. A criação de uma tarefa finalizadora deve incluir a palavra-chave FINALIZE, que é incompatível com as palavras-chave SCHEDULE e AFTER.

Para criar uma tarefa finalizadora, crie uma tarefa usando a palavra-chave FINALIZE e defina um relacionamento com a tarefa raiz:

CREATE TASK <TASK_NAME> ...
... FINALIZE = <ROOT_TASK_NAME>
Copy

Para obter mais informações, consulte CREATE TASK.

Nota

Em Snowsight, uma tarefa finalizadora é exibida como uma tarefa separada com seu próprio histórico de execução e detalhes de configuração. Uma exibição do gráfico de tarefas não mostra a tarefa finalizadora ou o relacionamento entre a tarefa raiz e a tarefa finalizadora.

Controle de versão de execuções

Quando uma tarefa autônoma ou a tarefa raiz em um DAG é retomada (ou executada manualmente usando EXECUTE TASK), uma versão inicial da tarefa é definida. Se a tarefa for uma tarefa raiz, então uma versão de todo o DAG, incluindo todas as propriedades para todas as tarefas no DAG, é definida. A tarefa autônoma ou DAG é executada utilizando esta versão. Após uma tarefa ser suspensa e modificada, uma nova versão é definida quando a tarefa autônoma ou raiz é retomada ou executada manualmente.

Para modificar ou recriar qualquer tarefa em um DAG, a tarefa raiz deve primeiro ser suspensa (usando ALTER TASK … SUSPEND). Quando a tarefa raiz é suspensa, todas as futuras execuções programadas da tarefa raiz são canceladas; entretanto, se alguma tarefa estiver sendo executada (ou seja, as tarefas estão em um estado EXECUTING), estas tarefas e quaisquer tarefas descendentes continuam a ser executadas usando a versão atual.

Nota

Se a definição de um procedimento armazenado chamado por uma tarefa mudar enquanto o DAG estiver sendo executado, a nova programação poderá ser executada quando o procedimento armazenado for chamado pela tarefa na execução atual.

Por exemplo, suponha que a tarefa raiz em um DAG esteja suspensa, mas uma execução programada desta tarefa já tenha começado. O proprietário de todas as tarefas no DAG modifica o código SQL chamado por uma tarefa filha enquanto a tarefa raiz ainda está em execução. A tarefa filha executa o código SQL em sua definição usando a versão do DAG que era atual quando a tarefa raiz iniciou sua execução. Quando a tarefa raiz é retomada ou é executada manualmente, uma nova versão do DAG é definida. Esta nova versão inclui as modificações da tarefa filha.

Para recuperar o histórico das versões de tarefas, consulte TASK_VERSIONS Exibição do Account Usage (no banco de dados SNOWFLAKE compartilhado).

Definição de parâmetros de sessão para tarefas

Você pode definir parâmetros para a sessão em que uma tarefa é executada. Para isso, modifique uma tarefa existente e defina os valores dos parâmetros desejados (usando ALTER TASKSET session_parameter = value[, session_parameter = value ... ]).

Uma tarefa oferece suporte a todos os parâmetros da sessão. Para a lista completa, consulte Parâmetros.

Note que uma tarefa não suporta parâmetros de conta ou de usuário.

Suspensão automática das tarefas após uma execução falhada

Opcionalmente, suspende as tarefas automaticamente após um número especificado de execuções consecutivas que falham ou ficam sem tempo. Este recurso pode reduzir custos suspendendo tarefas que consomem créditos do Snowflake, mas que não são executadas até a conclusão. Execuções de tarefas falhadas incluem execuções nas quais o código SQL no corpo da tarefa produz um erro do usuário ou atinge o tempo limite. Execuções de tarefas que são puladas, canceladas ou que falham devido a um erro do sistema são consideradas indeterminadas e não são incluídas na contagem de execuções de tarefas falhadas.

Defina o parâmetro SUSPEND_TASK_AFTER_NUM_FAILURES = num em uma tarefa autônoma ou na tarefa raiz em um DAG. Quando o parâmetro é definido como um valor maior que 0, o seguinte comportamento se aplica a execuções da tarefa autônoma ou do DAG:

  • Tarefas autônomas são automaticamente suspensas após o número especificado de execuções consecutivas de tarefas falhar ou atingir o tempo limite.

  • A tarefa raiz é automaticamente suspensa após a execução de qualquer tarefa única em um DAG falhar ou atingir o tempo limite pelo número especificado de vezes, em execuções consecutivas.

O parâmetro pode ser definido ao criar uma tarefa (usando CREATE TASK) ou mais tarde (usando ALTER TASK). A configuração se aplica a tarefas que dependem de recursos computacionais gerenciados pelo Snowflake (ou seja, modelo computacional sem servidor) ou recursos computacionais gerenciados pelo usuário (ou seja, um warehouse virtual).

O parâmetro SUSPEND_TASK_AFTER_NUM_FAILURES também pode ser definido no nível de conta, banco de dados ou esquema. A configuração se aplica a todas as tarefas autônomas ou raiz contidas no objeto modificado. Observe que a definição explícita do parâmetro em um nível mais baixo (ou seja, mais granular) sobrepõe-se ao valor do parâmetro definido em um nível mais alto.

Execução manual de tarefas

O comando EXECUTE TASK aciona manualmente uma única execução de uma tarefa agendada (seja uma tarefa autônoma ou a tarefa raiz em um DAG) independentemente do agendamento definido para a tarefa. Uma execução bem-sucedida de uma tarefa raiz aciona uma execução em cascata de tarefas filhas no DAG quando a tarefa anterior é concluída, como se a tarefa raiz tivesse sido executada em seu cronograma definido.

Este comando SQL é útil para testar tarefas autônomas novas ou modificadas e DAGs antes de habilitá-los a executar o código SQL na produção.

Chame este comando SQL diretamente em scripts ou em procedimentos armazenados. Além disso, este comando suporta a integração de tarefas em pipelines de dados externos. Qualquer serviço de terceiros que possa autenticar em sua conta Snowflake e autorizar ações SQL pode executar o comando EXECUTE TASK para executar tarefas.

Visualização do histórico de tarefas para sua conta

Você pode visualizar o histórico de tarefas de sua conta usando SQL ou Snowsight. Para ver o histórico de tarefas em Snowsight, consulte Visualização do histórico de tarefas na Snowsight.

As seguintes funções (ou funções com os privilégios especificados) podem usar SQL para visualizar o histórico de tarefas dentro de um intervalo de datas especificado:

  • Administrador de conta (ou seja, usuários com a função ACCOUNTADMIN).

  • Proprietário da tarefa (ou seja, função que tem o privilégio OWNERSHIP sobre uma tarefa).

  • Qualquer função que tenha o privilégio global MONITOR EXECUTION.

Para ver o histórico de execução de uma única tarefa:

SQL

Consulte a função de tabela TASK_HISTORY (no Snowflake Information Schema).

Para ver os detalhes de uma execução do DAG que está agendada ou em execução:

SQL

Consulte a função de tabela CURRENT_TASK_GRAPHS (no Snowflake Information Schema).

Para ver o histórico de execuções do DAG que foram executadas com sucesso, falharam ou foram canceladas nos últimos 60 minutos:

SQL

Consulte a função de tabela COMPLETE_TASK_GRAPHS (no Snowflake Information Schema).

Consulte a exibição Exibição COMPLETE_TASK_GRAPHS (no Account Usage).

Custos da tarefa

Os custos associados à execução de uma tarefa para executar código SQL diferem dependendo da fonte dos recursos de computação para a tarefa:

Warehouse gerenciado pelo usuário

O Snowflake fatura sua conta por uso de crédito baseado no uso do warehouse enquanto uma tarefa está em execução, semelhante ao uso do warehouse para executar as mesmas instruções SQL em um cliente ou na interface da Web do Snowflake. O faturamento de crédito por segundo e a suspensão automática do warehouse lhe dão a flexibilidade de começar com tamanhos de warehouse maiores e depois ajustar o tamanho para corresponder às cargas de trabalho de suas tarefas.

Recursos gerenciados pelo Snowflake (ou seja, modelo de computação sem servidor)

O Snowflake fatura sua conta com base no uso real dos recursos de computação; em contraste com os warehouses virtuais gerenciados pelo cliente, que consomem créditos quando ativos, e podem ficar ociosos ou ser utilizados em excesso. As taxas são calculadas com base no uso total dos recursos (incluindo o uso do serviço de nuvem) medido em uso de créditos de horas de computação.

O Snowflake analisa dinamicamente as tarefas executadas no histórico de tarefas para determinar o tamanho ideal dos recursos de computação, e suspende esses recursos de computação para economizar custos. O Snowflake gerencia a capacidade de carga, garantindo recursos de computação ideais para atender à demanda. Para recuperar os custos de gerenciamento dos recursos de computação fornecidos pelo Snowflake, aplicamos um multiplicador de 1,5x ao consumo de recursos. Observe, entretanto, que o modelo de computação sem servidor ainda pode reduzir os custos de computação de warehouses administrados pelo usuário; em alguns casos, significativamente.

Para saber quantos créditos são consumidos pelas tarefas, consulte a “Tabela de crédito de recursos sem servidor” na Tabela de consumo de serviço do Snowflake.

O faturamento é semelhante aos outros recursos do Snowflake, como o Clustering automático de tabelas, a Replicação e failover/failback e o Snowpipe.

Para recuperar o uso de créditos atual para uma tarefa específica, consulte a função de tabela SERVERLESS_TASK_HISTORY. Execute a seguinte instrução como o proprietário da tarefa (ou seja, a função que tem o privilégio OWNERSHIP sobre a tarefa):

SET num_credits = (SELECT SUM(credits_used)
  FROM TABLE(<database_name>.information_schema.serverless_task_history(
    date_range_start=>dateadd(D, -1, current_timestamp()),
    date_range_end=>dateadd(D, 1, current_timestamp()),
    task_name => '<task_name>')
    )
  );
Copy

Onde:

<nome_do_banco_de_dados>

Nome do banco de dados que contém a tarefa.

<nome_da_tarefa>

Nome da tarefa.

Para recuperar o uso de créditos atual para todas as tarefas sem servidor, consulte a exibição SERVERLESS_TASK_HISTORY. Execute a seguinte instrução como administrador de conta (ou seja, um usuário com a função ACCOUNTADMIN):

SELECT start_time,
  end_time,
  task_id,
  task_name,
  credits_used,
  schema_id,
  schema_name,
  database_id,
  database_name
FROM snowflake.account_usage.serverless_task_history
ORDER BY start_time, task_id;
Copy

Explicação do serviço do sistema

O Snowflake executa tarefas com os privilégios do proprietário da tarefa (ou seja, a função que tem o privilégio OWNERSHIP para a tarefa), mas as execuções de tarefa não estão associadas a um usuário. Ao invés disso, cada execução é realizada por um serviço de sistema. As tarefas são desacopladas de usuários específicos para evitar complicações que podem surgir quando os usuários são descartados, bloqueados devido a problemas de autenticação ou têm suas funções removidas.

As tarefas são executadas com os privilégios do proprietário da tarefa, seja ela programada ou executada manualmente por EXECUTE TASK por outra função com privilégio OPERATE.

Como as execuções de tarefas são desacopladas de um usuário, o histórico de consultas das execuções de tarefas está associado ao serviço do sistema. SYSTEM não é um usuário na conta; é um serviço em segundo plano. Como tal, não há credenciais de usuário para este serviço, e nenhum indivíduo (do Snowflake ou em sua conta) pode assumir sua identidade. A atividade para o serviço do sistema é limitada à sua conta. As mesmas proteções de criptografia e outros protocolos de segurança são incorporados a este serviço, assim como são aplicados para outras operações.

DDL de tarefas

Para apoiar a criação e o gerenciamento de tarefas, o Snowflake fornece o seguinte conjunto de comandos DDL especiais:

Além disso, os provedores podem visualizar, conceder ou revogar o acesso aos objetos de banco de dados necessários para ELT usando o seguinte DDL de controle de acesso padrão:

Funções de tarefa

Para apoiar a recuperação de informações sobre tarefas, o Snowflake fornece o seguinte conjunto de funções SQL:

Segurança de tarefas

Privilégios de controle de acesso

Criação de tarefas

A criação de tarefas requer uma função com um mínimo dos seguintes privilégios:

Objeto

Privilégio

Notas

Conta

EXECUTE MANAGED TASK

Necessário apenas para tarefas que dependem de recursos de computação gerenciados pelo Snowflake (modelo de computação sem servidor).

Banco de dados

USAGE

Esquema

USAGE, CREATE TASK

Warehouse

USAGE

Necessário apenas para tarefas que dependem de warehouses gerenciados pelo usuário para recursos de computação.

Como ser proprietário de tarefas

Depois que uma tarefa é criada, o proprietário da tarefa (ou seja, a função que tem o privilégio OWNERSHIP na tarefa) deve ter os seguintes privilégios:

Objeto

Privilégio

Notas

Conta

EXECUTE TASK

Requerido para executar quaisquer tarefas que a função possua. A revogação do privilégio EXECUTE TASK em uma função impede que todas as tarefas subsequentes sejam iniciadas sob essa função.

Conta

EXECUTE MANAGED TASK

Necessário apenas para tarefas que dependem de recursos de computação gerenciados pelo Snowflake.

Banco de dados

USAGE

Esquema

USAGE

Tarefa

OWNERSHIP

Warehouse

USAGE

Além disso, a função deve ter as permissões necessárias para executar a instrução SQL executada pela tarefa.

Retomada ou suspensão de tarefas

Além do proprietário da tarefa, uma função que tenha o privilégio OPERATE para a tarefa pode suspender ou retomar a tarefa. Esta função deve ter o privilégio USAGE para o banco de dados e o esquema que contêm a tarefa. Nenhum outro privilégio é necessário.

Quando uma tarefa é retomada, o Snowflake verifica se a função do proprietário da tarefa tem os privilégios listados em Como ser proprietário de tarefas (neste tópico).

Criação de uma função de administrador de tarefas

Para facilitar o uso, recomendamos a criação de uma função personalizada (por exemplo, taskadmin) e a atribuição do privilégio EXECUTE TASK a esta função. Qualquer função que possa conceder privilégios (por exemplo, SECURITYADMIN ou qualquer função com o privilégio MANAGE GRANTS) pode então conceder esta função personalizada a qualquer função de proprietário da tarefa para permitir a alteração de suas próprias tarefas. Para remover a capacidade de o proprietário executar a tarefa, é necessário apenas revogar esta função personalizada na função de proprietário da tarefa. Observe que se você optar por não criar esta função personalizada, um administrador de conta precisa revogar o privilégio EXECUTE TASK da função de proprietário da tarefa.

Por exemplo, crie um nome de função personalizado taskadmin e conceda a essa função o privilégio EXECUTE TASK. Atribua a função taskadmin a uma função de proprietário de tarefa chamada myrole:

USE ROLE securityadmin;

CREATE ROLE taskadmin;

-- set the active role to ACCOUNTADMIN before granting the account-level privileges to the new role
USE ROLE accountadmin;

GRANT EXECUTE TASK, EXECUTE MANAGED TASK ON ACCOUNT TO ROLE taskadmin;

-- set the active role to SECURITYADMIN to show that this role can grant a role to another role
USE ROLE securityadmin;

GRANT ROLE taskadmin TO ROLE myrole;
Copy

Para obter mais informações sobre a criação de funções personalizadas e hierarquias de funções, consulte Configuração do controle de acesso.

Descarte de uma função de proprietário de tarefa

Quando a função de proprietário de uma determinada tarefa (ou seja, a função com o privilégio OWNERSHIP para a tarefa) é excluída, a tarefa é recuperada pela função que descartou a função de proprietário. Isto assegura que a propriedade passe para uma função que esteja mais próxima da raiz da hierarquia de funções. Quando uma tarefa é recuperada, ela é automaticamente pausada, ou seja, todas as execuções atualmente em processamento são completadas, mas novas execuções não são agendadas até que a tarefa seja retomada explicitamente pelo novo proprietário. A razão para isto é impedir que um usuário com acesso a uma função específica deixe para trás tarefas que subitamente são executadas com permissões mais altas quando a função é removida.

Se a função sob a qual uma tarefa está sendo executada for descartada, a tarefa completa seu processamento sob a função descartada.

Fluxo de trabalho

Esta seção fornece uma visão geral de alto nível do fluxo de trabalho de configuração de tarefas.

  1. Complete os passos em Criação de uma função de administrador de tarefas (neste tópico) para criar uma função que possa ser usada para executar os comandos nos passos seguintes.

  2. Crie uma tarefa usando CREATE TASK. A tarefa está suspensa por padrão.

    Nota

    Verifique se a instrução SQL que você usará em uma tarefa é executada como esperado antes de criar a tarefa. As tarefas destinam-se a automatizar instruções SQL ou procedimentos armazenados que já tenham sido testados exaustivamente.

  3. Execute ALTER TASK … RESUME para permitir que a tarefa seja executada com base nos parâmetros especificados na definição da tarefa.