Práticas recomendadas do Snowpipe Streaming¶

Otimização de custo¶

Como prática recomendada, recomendamos chamar o API com menos clientes do Snowpipe Streaming que escrevem mais dados por segundo. Use um aplicativo Java ou Scala para agregar os dados de várias fontes, como dispositivos IoT ou sensores, e depois usar o Snowflake Ingest SDK para chamar a API para carregar dados em taxas de fluxo mais altas. O API agrega eficientemente os dados em várias tabelas de destino em uma conta.

Um único cliente Snowpipe Streaming pode abrir vários canais para enviar dados, mas o custo do cliente só é cobrado por cliente ativo. O número de canais não afeta o custo do cliente. Portanto, recomendamos o uso de vários canais por cliente para otimização de desempenho e custos.

Usando as mesmas tabelas tanto para a ingestão de lote quanto para a ingestão de streaming também pode resultar na redução dos custos de computação do Snowpipe Streaming devido às operações de migração de arquivos capturadas. Se o clustering automático também estiver ativado na mesma tabela em que o Snowpipe Streaming está sendo inserido, os custos de computação para migração de arquivos poderão ser reduzidos. A operação de clustering otimizará e migrará dados na mesma transação.

Recomendações de desempenho¶

Para um ótimo desempenho em implantações de alto rendimento, recomendamos as seguintes ações:

Se você estiver carregando várias linhas, usar insertRows será mais eficiente e econômico do que chamar insertRow várias vezes, pois há menos tempo gasto nos bloqueios.
- Mantenha o tamanho de cada lote de linhas passado para insertRows abaixo de 16 MB compactado.
- O tamanho ideal dos lotes de linha é entre 10 e 16 MB.
Passe os valores para as colunas TIME, DATE e todas as colunas TIMESTAMP como um dos tipos suportados do pacote java.time.
Ao criar um canal usando OpenChannelRequest.builder, defina o OnErrorOption como OnErrorOption.CONTINUE e verifique manualmente o valor de retorno de insertRows quanto a possíveis erros de ingestão. Esta abordagem atualmente leva a um melhor desempenho do que confiar em exceções lançadas quando OnErrorOption.ABORT é usado.
Ao definir o nível de log padrão para DEBUG, certifique-se de que os registradores a seguir continuem fazendo o registro de log em INFO: isso porque sua saída de DEBUG é muito detalhada, o que pode levar a uma degradação significativa do desempenho.
- net.snowflake.ingest.internal.apache.parquet
- org.apache.parquet
Os canais devem ter vida longa quando um cliente está inserindo dados ativamente e devem ser reutilizados porque as informações do token de offset são retidas. Não feche os canais após inserir dados porque os dados dentro dos canais são automaticamente liberados com base no tempo configurado em MAX_CLIENT_LAG.

Recomendações de latência¶

Com o SDK do Snowflake Ingest versão 2.0.4 e posterior, você pode usar MAX_CLIENT_LAG para configurar a latência de liberação de dados. Por padrão, o Snowpipe Streaming libera dados a cada 1 segundo. A configuração MAX_CLIENT_LAG permite que você substitua isso e defina a latência de liberação desejada de 1 segundo a 10 minutos.

Para cenários de baixo rendimento, onde não há muitos dados sendo gerados, você pode enviar apenas 1 linha ou 1 KB de dados a cada segundo. Isso pode resultar em um tempo maior de compilação de consulta, em que muitas partições pequenas devem ser resolvidas para retornar os resultados da consulta, especialmente quando a consulta é acionada antes do processo de migração compactar as partições. Definir um MAX_CLIENT_LAG maior permite que o Snowpipe Streaming armazene em buffer as linhas inseridas pelo período configurado e crie partições de melhor tamanho. Isso ajuda significativamente no desempenho da consulta e na migração.

Portanto, defina o maior MAX_CLIENT_LAG que sua latência de destino permitir. Por exemplo, se você tiver uma tarefa executada a cada 1 minuto para fundir ou transformar seus dados transmitidos, seria ideal definir MAX_CLIENT_LAG para 50 ou 55 segundos.