Compreensão dos custos das tabelas dinâmicas¶
Este tópico fornece uma visão geral dos custos de computação e armazenamento associados a tabelas dinâmicas. Para obter informações gerais sobre os custos do Snowflake, consulte Compreensão do custo total.
Custos computacionais¶
Há dois custos de computação associados a tabelas dinâmicas: warehouses virtuais e computação de serviços de nuvem.
As tabelas dinâmicas exigem pelo menos um warehouse virtual para fazer atualizações. Você pode atribuir um segundo warehouse se quiser separar os custos de computação de operações diferentes. Para obter mais informações, consulte Entender o uso do warehouse para tabelas dinâmicas.
As atualizações de tabelas dinâmicas consomem créditos de computação, e a frequência é determinada pela meta de atraso configurada: valores de meta de atraso mais baixos acionam atualizações mais frequentes e, portanto, geram custos de computação mais altos.
As tabelas dinâmicas também requerem computação de serviços de nuvem para identificar alterações em objetos base subjacentes e determinar se o warehouse virtual deve ser executado. Se a computação de serviços de nuvem não detectar alterações, nenhum crédito de computação do warehouse será consumido porque não há novos dados para atualizar. Se houver mudanças, mesmo que a consulta de tabela dinâmica as filtre, o warehouse virtual consumirá créditos porque a tabela dinâmica é atualizada para avaliar se essas mudanças se aplicam.
Se os warehouses virtuais associados forem suspensos e a computação de serviços de nuvem não detectar alterações nas tabelas base, os warehouses permanecerão suspensos e as tabelas dinâmicas não consumirão nenhum crédito. Quando a computação de serviços de nuvem identifica alterações nas tabelas base, o warehouse apropriado é retomado automaticamente. Se as alterações oferecerem suporte à atualização incremental, a tabela dinâmica será atualizada usando o parâmetro WAREHOUSE. Se a reinicialização for necessária (por exemplo, devido a uma alteração no esquema da tabela base), a tabela dinâmica usará INITIALIZATION_WAREHOUSE para realizar uma reinicialização completa. Para obter informações sobre como as tabelas dinâmicas são suspensas automaticamente, consulte Suspensão dinâmica automática da tabela.
Verificação do seu consumo de créditos de warehouse virtual¶
Para verificar se as atualizações da tabela dinâmica consumiram créditos do warehouse virtual, use a guia Refresh History no Snowsight:
No menu de navegação, selecione Transformation » Dynamic tables.
Selecione a tabela dinâmica e, depois, a guia Refresh History.
Marque caixa de seleção Warehouse used only para visualizar as atualizações que usaram o warehouse para atualização.
Dica
Para entender melhor os custos relacionados aos seus pipelines de tabelas dinâmicas, a Snowflake recomenda que você teste as tabelas dinâmicas usando warehouses dedicados. Dessa forma, você pode isolar o consumo de warehouse virtual atribuído às tabelas dinâmicas e mover suas tabelas dinâmicas para um warehouse compartilhado depois de estabelecer uma linha de base de custo.
Para obter mais informações, consulte Entender o uso do warehouse para tabelas dinâmicas.
Calcular o custo de restrições de imutabilidade¶
Se você usar a restrição IMMUTABLE WHERE, o Snowflake recalculará apenas as linhas que não correspondem à condição de imutabilidade, o que ajuda a reduzir os custos de reinicialização. Isso pode ser útil em situações em que a reinicialização pode ocorrer, como nos seguintes cenários:
Recriação de tabelas ou exibições a montante.
Alterações nas políticas de governança de dados a montante.
Failover para uma região secundária em um grupo de failover.
Usar a restrição IMMUTABLE WHERE pode ajudar você a reduzir o custo de atualização incremental e completa porque a restrição ignora alterações e dados que correspondem ao respectivo predicado.
Adicionar restrições de imutabilidade a uma tabela dinâmica não aciona computação extra, mas removê-las sim porque causa a reinicialização na próxima atualização. Modificar o predicado em uma restrição IMMUTABLE WHERE pode acionar a reinicialização, dependendo se o Snowflake consegue determinar se as linhas retornadas com a condição original ainda são retornadas com a nova condição.
Por exemplo, as seguintes modificações não acionam a reinicialização:
De
(ts < CURRENT_TIMESTAMP() - INTERVAL '2 days')para(ts < CURRENT_TIMESTAMP() - INTERVAL '1 days')De
(year <= 2023)para(year <= 2024)
As seguintes modificações acionam a reinicialização:
De
(ts < '2025-01-02')para(ts < '2025-01-01')De
(year < 2024)para(month < 10)
Custo de armazenamento¶
Tabelas dinâmicas requerem armazenamento para depositar os resultados materializados. De maneira semelhante às tabelas comuns, você pode incorrer em custos adicionais de armazenamento para os recursos Time Travel, de armazenamento fail-safe e de clonagem.
As tabelas dinâmicas Apache Iceberg™ não geram custos de armazenamento do Snowflake. Para obter mais informações, consulte Faturamento.
Esta seção discute as seguintes considerações de armazenamento para tabelas dinâmicas:
Para obter informações detalhadas sobre como esse armazenamento incorre em custos, consulte Explicação do custo de armazenamento e Considerações sobre armazenamento de dados.
Custos de Time Travel e fail-safe¶
O Snowflake Time Travel permite que você acesse e consulte o histórico de versões de tabelas dinâmicas em pontos específicos no tempo, o que pode ajudar a obter insights sobre tendências históricas, alterações e anomalias com base em seus dados.
As atualizações frequentes podem aumentar o acúmulo de dados do Time Travel, o que aumenta o uso total de armazenamento. Para obter mais informações, consulte Compreensão e uso do Time Travel.
Os recursos fail-safe ajudam a proteger suas tabelas dinâmicas contra perda ou corrupção de dados. Com base no período de fail-safe configurado, cobranças adicionais de armazenamento podem ser aplicadas.
Replicação de tabelas dinâmicas¶
As tabelas dinâmicas oferecem suporte à replicação entre contas e regiões, permitindo que você copie dados de um banco de dados primário para um banco de dados secundário para recuperação de desastres ou compartilhamento de dados. Isso pode servir como uma estratégia de preparação de failover para recuperação de desastres ou como um meio de compartilhar dados entre implantações para fins somente leitura. O uso de replicação com tabelas dinâmicas está sujeito a custos de replicação. Para obter mais informações, consulte Replicação e tabelas dinâmicas.
Tabelas dinâmicas suspensas¶
As tabelas dinâmicas suspensas não geram custos adicionais além das taxas de armazenamento padrão e não consomem recursos de computação. Se você tiver tarefas de manutenção em andamento ou trabalhos agendados que interajam com uma tabela suspensa, suas tabelas dinâmicas poderão consumir recursos de computação.
Tabelas dinâmicas transitórias¶
Snowflake oferece suporte a tabelas dinâmicas transitórias, semelhantes às tabelas regulares, que persistem até serem explicitamente removidas e estão disponíveis para todos os usuários com os privilégios adequados, sem um período fail-safe. As tabelas dinâmicas transitórias são mais adequadas para dados transitórios que não precisam do mesmo nível de proteção e recuperação oferecido pelas tabelas permanentes. O uso delas ajuda você a economizar com armazenamento fail-safe.
Armazenamento adicional para operações de atualização incremental¶
Para operações de atualização incremental, as tabelas dinâmicas mantêm uma coluna de metadados interna adicional para identificar cada linha dentro da tabela. Os identificadores de linha internos consomem uma quantidade constante de armazenamento por linha e aumentam o custo de armazenamento de forma linear ao número de linhas na tabela, seja qual for o número de colunas.
Para tabelas com poucas colunas, o aumento no armazenamento em comparação com uma tabela CTAS equivalente pode ser significativo, ou até mesmo dominante. Em tabelas dinâmicas mais amplas, esse efeito é menos pronunciado.
Custo do cronograma de atualização¶
O cronograma no qual uma tabela dinâmica é atualizada, seja completo ou incremental, tem um efeito em seu custo total. Esta seção apresenta os fatores que você deve considerar na hora de decidir sobre um cronograma de atualização, supondo que não haja atualização vazia:
Nota
As atualizações são relativamente baratas se as fontes não tiverem mudado. Para obter mais informações, consulte Custos computacionais (neste tópico).
Cronograma de atualização completo¶
O custo de uma atualização completa normalmente depende de quantos dados sua tabela dinâmica verifica e com que frequência ela é atualizada. Para diminuir os custos, você pode atualizar as tabelas dinâmicas somente quando necessário; por exemplo, suspenda as tabelas dinâmicas fora do horário comercial. Para um controle de tempo preciso, defina a meta de atraso downstream de uma tarefa para automatizar os cronogramas personalizados.
Cronograma de atualização incremental¶
O custo da atualização incremental costuma ser proporcional ao volume de alterações nos objetos de origem, mais alguma sobrecarga fixa.
Se a sobrecarga for baixa, você pode definir uma frequência de atualização alta sem muitas desvantagens. Isso significa que você pode atualizar com frequência para obter melhores resultados. Por exemplo, uma simples tabela dinâmica SELECT ... FROM ... WHERE processa apenas as linhas alteradas entre as atualizações, o que tem uma sobrecarga mínima, e a tabela dinâmica pode ser executada com frequência a um baixo custo adicional.
Se a sobrecarga for alta, você deverá encontrar um ponto de equilíbrio entre o consumo de crédito da alta frequência de atualização e os benefícios comerciais da atualização. Por exemplo, em uma tabela dinâmica com uma junção, você deve unir as alterações em uma tabela às da outra tabela. Não importa se o conjunto de alterações é muito pequeno, essa junção geralmente envolve um custo mínimo de execução. Se essa sobrecarga for significativa, ela poderá ser acumulada à medida que a frequência de atualização aumenta.