Custos para o Snowpipe Streaming Classic¶
Com o modelo de computação sem servidor do Snowpipe Streaming, os usuários podem transmitir qualquer volume de dados sem gerenciar um warehouse virtual. Em vez disso, o Snowflake fornece e gerencia os recursos de computação, aumentando ou diminuindo automaticamente a capacidade com base na carga do Snowpipe Streaming.
Para o Snowpipe Streaming Classic, as contas são cobradas com base no tempo por segundo que a computação sem servidor e a ingestão de streaming do cliente ativo usam. Fique atento ao seguinte:
A migração de arquivos ocorre de forma assíncrona a partir da ingestão de streaming.
A migração de arquivos pode ser antecipada por clustering ou outras operações DML.
A migração de arquivos pode nem sempre ocorrer e, portanto, os custos de computação podem ser reduzidos.
Para tabelas Apache Iceberg™ gerenciadas pelo Snowflake, a migração de arquivos funciona de forma semelhante à manutenção de tabelas Iceberg para criar novos arquivos Parquet compactados, se necessário.
Para obter mais informações, consulte “Tabela de crédito de recursos sem servidor” na Tabela de consumo de serviços do Snowflake.
Estimativa das taxas do Snowpipe Streaming¶
Dado o número de fatores que podem diferenciar os carregamentos do Snowpipe Streaming, é muito difícil para a Snowflake fornecer custos de amostra. O tamanho dos registros, número de registros, tipos de dados etc. podem afetar o consumo de recursos de computação para a migração de arquivos. Os encargos dos clientes são ditados apenas pelo número de clientes que estão ativamente escrevendo dados ao Snowflake por segundo.
Sugerimos que você experimente executando uma carga de ingestão de streaming típica para estimar os encargos futuros. Para ver um exemplo de experimento de ingestão de streaming com custos estimados, consulte esta postagem do blog.
Faturamento e armazenamento de arquivos temporários¶
Embora a API Snowpipe Streaming seja projetada para gravar linhas diretamente nas tabelas do Snowflake sem exigir que os usuários preparem os arquivos explicitamente, no Snowpipe Streaming Classic, os processos internos do Snowflake usam uma área de preparação interna transparente para o buffer temporário de dados. O Snowpipe Streaming com SDK de arquitetura clássica gera e carrega arquivos intermediários para essa área de preparação interna antes de serem transformados no formato de arquivo nativo do Snowflake.
O Snowflake cobra pelo armazenamento consumido por esses arquivos temporários na área de preparação interna. Esse custo de armazenamento é separado do custo de computação sem servidor do Snowpipe Streaming e aparece no «custo de armazenamento» geral na sua fatura do Snowflake.
O período de retenção desses arquivos temporários na área de preparação interna está diretamente associado ao tempo de retenção de dados da tabela de destino (ou à retenção em nível de conta, se nenhuma retenção de tabela específica estiver definida). O Snowflake exclui automaticamente esses arquivos quando eles ultrapassam a janela de Time Travel definida. Normalmente, essa exclusão ocorre dentro de um dia após os dados saírem do período de retenção. Os usuários não têm acesso direto ou visibilidade desses arquivos de área de preparação interna.
Clonagem de tabelas com o Snowpipe Streaming¶
Quando os usuários clonam uma tabela que está recebendo dados ativamente pelo Snowpipe Streaming com arquitetura clássica, podem observar custos de armazenamento mais altos. Esse custo extra não se deve à duplicação dos arquivos de dados subjacentes. O Snowflake realiza clonagem de cópia zero. Isso ocorre porque os dados em trânsito (dados que foram processados pelo Snowpipe Streaming com SDK de arquitetura clássica e estão temporariamente armazenados na área de preparação interna, mas ainda não totalmente comprometidos com a tabela de destino) exigem uma migração de arquivo tanto para a tabela original quanto para o clone. Esse processamento duplo de arquivos temporários aumenta o consumo de migração de arquivos e leva a um maior uso de armazenamento. Esse custo extra normalmente é muito pequeno, refletindo um máximo de cerca de cinco minutos de arquivos temporários, mas pode ser maior com uma taxa de transferência muito alta se o sistema estiver enfrentando atrasos nessas migrações. Essa duplicação contribui para o aumento do consumo de armazenamento.
Em contraste, o Snowpipe Streaming com uma arquitetura de alto desempenho oferece clonagem de cópia zero real para tabelas que recebem ativamente dados de streaming. Com a arquitetura de alto desempenho, as operações de clonagem se comportam como clones de tabela Snowflake padrão. Isso significa que apenas novos dados gravados após a operação de clonagem consomem armazenamento extra. Os dados em trânsito no momento da clonagem não estão sujeitos a essa migração dupla. Como resultado, você se beneficia de uma clonagem econômica para tabelas de streaming.
Visualização do histórico de carregamento de dados para sua conta¶
Os administradores de conta (usuários com a função ACCOUNTADMIN) ou usuários com uma função com o privilégio global MONITOR USAGE podem usar comandos SQL para visualizar os créditos faturados em sua conta Snowflake dentro de um intervalo de datas especificado. Você pode usar as seguintes exibições para consultar o histórico dos dados migrados para as tabelas Snowflake, o tempo gasto para carregar dados nas tabelas Snowflake usando o Snowpipe Streaming e os créditos consumidos.
Para visualizar os custos totais do Snowpipe Streaming, incluindo os custos de computação e do cliente, consulte o histórico de medição quando SERVICE_TYPE estiver definido como SNOWPIPE_STREAMING.
Para obter mais informações sobre como consultar os custos totais do Snowpipe Streaming, consulte um exemplo SQL.
Para ver os detalhamentos da ingestão de clientes e da computação de migração, é possível consultar as seguintes exibições: