Otimização de custo¶
Este tópico discute maneiras de otimizar o Snowflake para reduzir custos e maximizar seus gastos.
Insights de custos: Encontrando oportunidades de economia¶
O Snowflake fornece insights de custos que identificam oportunidades para otimizar o Snowflake para custos dentro de uma conta específica. Esses insights são calculados e atualizados semanalmente.
Cada insight indica quantos créditos ou TBs poderiam ser salvos otimizando o Snowflake.
Nota
Você deve receber a função ACCOUNTADMIN para visualizar os insights de custos.
Para acessar o bloco Cost Insights:
Faça login no Snowsight.
Mude para a função ACCOUNTADMIN.
No menu de navegação, selecione Admin » Cost Management.
Selecione a guia Account Overview.
Encontre o bloco Cost insights.
Cada um dos insights a seguir inclui sugestões sobre como otimizar seus gastos.
Insight: Caminhos de otimização de pesquisa raramente usados
Insight: Tabelas maiores de 100GB das quais os dados são gravados, mas não lidos
- Insight: Tabelas raramente usadas com clustering automático
Este insight identifica tabelas com agrupamento automático consultadas menos de 100 vezes por semana por esta conta.
Habilitar o clustering automático para uma tabela pode melhorar significativamente o desempenho das consultas nessa tabela. No entanto, conforme a tabela muda, o Snowflake deve usar recursos de computação sem servidor para mantê-lo em um estado bem clusterizado. Se o número de consultas executadas na tabela for mínimo, o custo incorrido pode não justificar as melhorias de desempenho.
Recomendação: considere desabilitar o agrupamento automático nessas tabelas. Antes de desativar o clustering automático, determine se a tabela existe apenas para fins de recuperação de desastres ou para uso por outras contas Snowflake por meio do compartilhamento de dados, o que pode explicar por que ela não é acessada com frequência.
Por exemplo, para desabilitar o clustering automático para uma tabela nomeada
t1, execute o seguinte comando:ALTER TABLE t1 SUSPEND RECLUSTER;
- Insight: Exibições materializadas raramente usadas
Este insight identifica exibições materializadas que são consultadas menos de 10 vezes por semana por esta conta.
Criar uma exibição materializada pode melhorar significativamente o desempenho de determinados padrões de consulta. No entanto, exibições materializadas geram custos adicionais de armazenamento, bem como custos de computação sem servidor associados à manutenção da exibição materializada atualizada com novos dados. Se o número de consultas executadas na exibição materializada for mínimo, o custo incorrido pode não justificar as melhorias de desempenho.
Recomendação: considere remover ou suspender as atualizações nas exibições materializadas. Antes de descartar uma exibição materializada, determine se a tabela existe apenas para fins de recuperação de desastres ou para uso por outras contas Snowflake por meio do compartilhamento de dados, o que pode explicar por que ela não é acessada com frequência.
Por exemplo, para excluir uma exibição materializada nomeada
mv1, execute o seguinte comando:DROP MATERIALIZED VIEW mv1;
- Insight: Caminhos de otimização de pesquisa raramente usados
Esse insight identifica caminhos de acesso de otimização de pesquisa, que são usados menos de 10 vezes por semana por esta conta.
A otimização de pesquisa usa caminhos de acesso de pesquisa para melhorar o desempenho de certos tipos de consultas analíticas e de pesquisa pontual. Adicionar otimização de pesquisa a uma tabela pode melhorar significativamente o desempenho dessas consultas. No entanto, a otimização de pesquisa gera custos adicionais de armazenamento, bem como custos de computação sem servidor associados à manutenção desse armazenamento atualizado. Se o número de consultas que usam o caminho de acesso de pesquisa criado pela otimização de pesquisa for mínimo, o custo incorrido pode não justificar as melhorias de desempenho.
Recomendação: Considere remover a otimização de pesquisa da tabela. Antes de remover a otimização de pesquisa, determine se a tabela existe apenas para fins de recuperação de desastres ou para uso por outras contas Snowflake por meio do compartilhamento de dados, o que pode explicar por que ela não é acessada com frequência.
Por exemplo, para remover completamente a otimização de pesquisa de uma tabela nomeada
t1, execute o seguinte comando:ALTER TABLE t1 DROP SEARCH OPTIMIZATION;
- Insight: Tabelas grandes que nunca são consultadas
Este insight identifica tabelas grandes que não foram consultadas na última semana por esta conta.
Recomendação: considere excluir tabelas não utilizadas, o que pode reduzir os custos de armazenamento sem afetar nenhuma carga de trabalho. Antes de remover as tabelas, determine se elas existem apenas para fins de recuperação de desastres ou para uso por outras contas Snowflake por meio do compartilhamento de dados, o que pode explicar por que elas não são acessadas com frequência.
Por exemplo, para excluir um nome de tabela
t1, execute o seguinte comando:DROP TABLE t1;
- Insight: Tabelas maiores de 100GB das quais os dados são gravados, mas não lidos
Este insight identifica tabelas onde os dados são gravados, mas nunca lidos por esta conta.
Recomendação: pode ser um desperdício armazenar dados e ingerir novos dados no Snowflake se os dados nunca forem lidos. Considere excluir essas tabelas para economizar em custos de armazenamento ou pare de gravar novos dados para economizar em créditos consumidos pela ingestão. Antes de remover as tabelas, determine se elas existem apenas para fins de recuperação de desastres ou para uso por outras contas Snowflake por meio do compartilhamento de dados, o que pode explicar por que elas não estão sendo lidas.
Por exemplo, para excluir um nome de tabela
t1, execute o seguinte comando:DROP TABLE t1;
- Insight: Tabelas permanentes de curta duração
Este insight identifica tabelas com mais de 100 GB que foram excluídas dentro de 24 horas após sua criação.
Recomendação: se os dados precisarem ser mantidos por um curto período, considere usar uma tabela temporária ou tabela transitória para tabelas futuras. Usar uma tabela temporária ou tabela transitória pode ajudar você a diminuir Custos de Fail-safe e Time Travel.
Por exemplo, para criar uma nova tabela transitória
t1, execute o seguinte comando:CREATE TRANSIENT TABLE t1;
Otimização dos serviços de nuvem para custos¶
Se você achar que seu uso de serviços de nuvem é maior do que o esperado, verifique se o uso do Snowflake segue algum dos padrões a seguir. Cada padrão inclui uma recomendação que pode ajudar você a reduzir custos associados aos serviços de nuvem.
Padrão: consultas bloqueadas devido a bloqueios de transação
Padrão: comandos SHOW de alta frequência (por aplicativos de dados e ferramentas de terceiros)
Padrão: inserções de linha única e esquemas fragmentados (por aplicativos de dados)
- Padrão: consultas bloqueadas devido a bloqueios de transação
Os comandos de atualização e mesclagem colocam um bloqueio de transação em uma tabela, o que impede que outros comandos sejam executados nessa tabela até que o bloqueio seja liberado. As consultas consomem créditos de serviços de nuvem enquanto aguardam a liberação de um bloqueio. Quanto mais tempo as consultas permanecem na camada de serviços de nuvem aguardando o bloqueio, mais créditos elas consomem.
Recomendação: os bloqueios de transação geralmente ocorrem quando os usuários executam comandos simultâneos de atualização/mesclagem em uma única tabela, especialmente quando cada comando atualiza apenas algumas linhas. Você pode minimizar esses bloqueios usando um comando em lote em vez de atualizações únicas. Nesta estratégia, você faz o seguinte:
Use uma instrução em lote INSERT para carregar novos dados em uma tabela temporária. Evite usar uma inserção de linha única. Mesmo as chamadas de API que carregam novos dados continuamente devem ser projetadas de forma que enviem inserções em lote em vez de inserções de linha única.
Use a tabela temporária para atualizar/mesclar a tabela de destino.
Se a origem enviar novos dados continuamente ao longo do dia, considere usar uma tarefa para atualizar a tabela de destino periodicamente.
- Padrão: comandos de cópia com baixa seletividade
A execução de comandos de cópia envolve listar arquivos do Amazon Simple Storage Service (S3). Como a listagem de arquivos usa apenas computação de serviços de nuvem, a execução de comandos de cópia com baixa seletividade pode resultar em alto uso de serviços de nuvem.
Recomendação: considere alterar a estrutura do seu bucket S3 para incluir algum tipo de prefixo de data, para listar apenas os arquivos de destino necessários.
- Padrão: operações DDL de alta frequência e clonagem
As operações de linguagem de definição de dados (DDL), especialmente a clonagem, são operações inteiramente de metadados, o que significa que usam apenas computação de serviços de nuvem. A criação ou eliminação frequente de grandes esquemas ou tabelas, ou a clonagem de bancos de dados para backup, podem resultar no uso significativo de serviços de nuvem.
Recomendação: a clonagem usa apenas uma fração dos recursos necessários para fazer cópias profundas, portanto você deve continuar a clonar. Revise seus padrões de clonagem para garantir que eles sejam tão granulares quanto possível e não sejam executados com muita frequência. Por exemplo, talvez você queira clonar apenas tabelas individuais em vez de um esquema inteiro.
- Padrão: consultas simples e de alta frequência
O consumo de serviços de nuvem por uma única consulta simples é insignificante, mas a execução de consultas como
SELECT 1,SELECT sequence1.NEXTVALouSELECT CURRENT_SESSION()com uma frequência extremamente alta (dezenas de milhares por dia) pode resultar em um uso significativo de serviços de nuvem.Recomendação: revise a frequência de consulta e determine se ela está definida adequadamente para seu caso de uso. Se você observar uma alta frequência de consultas
SELECT CURRENT_SESSION()originadas de ferramentas de parceiros que usam o driver JDBC, confirme se o parceiro atualizou o código para usar o métodogetSessionId()na interface SnowflakeConnection. Isso aproveita o cache e reduz o uso de serviços de nuvem.
- Padrão: consultas INFORMATION_SCHEMA de alta frequência
As consultas em Snowflake Information Schema consomem apenas recursos de serviços de nuvem. O consumo de serviços de nuvem por uma única consulta em exibições INFORMATION_SCHEMA pode ser insignificante, mas a execução dessas consultas com frequência extremamente alta (dezenas de milhares por dia) pode resultar em uso significativo de serviços de nuvem.
Recomendação: revise a frequência de consulta e determine se ela está definida adequadamente para seu caso de uso. Como alternativa, você pode consultar uma exibição no esquema ACCOUNT_USAGE em vez de uma exibição INFORMATION_SCHEMA. A consulta do esquema ACCOUNT_USAGE usa um warehouse virtual em vez de serviços de nuvem.
- Padrão: comandos SHOW de alta frequência (por aplicativos de dados e ferramentas de terceiros)
Os comandos SHOW são operações inteiramente de metadados, o que significa que consomem apenas recursos de serviços de nuvem. Esse padrão normalmente ocorre quando você cria um aplicativo baseado no Snowflake que executa comandos SHOW em alta frequência. Esses comandos também podem ser iniciados por ferramentas de terceiros.
Recomendação: revise a frequência de consulta e determine se ela está definida adequadamente para seu caso de uso. No caso de ferramentas de parceiros, entre em contato com seu parceiro para saber se ele tem planos de ajustar seu uso.
- Padrão: inserções de linha única e esquemas fragmentados (por aplicativos de dados)
Snowflake não é um sistema OLTP, portanto, inserções de linha única não são ideais e podem consumir recursos significativos de serviços de nuvem.
Criar um aplicativo de dados que defina um esquema por cliente pode resultar em diversas cargas de dados em um determinado período, o que pode resultar em alto consumo de serviços de nuvem.
Esse padrão também resulta em muito mais metadados que o Snowflake precisa manter, e as operações de metadados consomem recursos de serviços de nuvem. Cada operação de metadados consome recursos mínimos individualmente, mas o consumo pode ser significativo em conjunto.
Recomendação: em geral, faça carregamentos em lote ou em massa em vez de inserções de linha única.
Usar um esquema compartilhado é significativamente mais eficiente, o que economiza custos. Provavelmente você desejará agrupar todas as tabelas em
customer_IDe usar exibições seguras.
- Padrão: consultas SQL complexas
As consultas podem consumir computação significativa dos serviços de nuvem se incluírem muitas junções/produtos cartesianos, usarem o operador IN com listas grandes ou forem consultas muito grandes. Todos esses tipos de consultas têm tempos de compilação elevados.
Recomendação: revise suas dúvidas para confirmar se elas estão fazendo o que você pretende que façam. Snowflake oferece suporte a essas consultas e cobrará apenas pelos recursos consumidos.