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:

  • 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.

  • Mantenha o tamanho de cada lote de linhas passado para insertRows abaixo de 16 MB.

  • 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.

  • 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