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 oOnErrorOption
comoOnErrorOption.CONTINUE
e verifique manualmente o valor de retorno deinsertRows
quanto a possíveis erros de ingestão. Esta abordagem atualmente leva a um melhor desempenho do que confiar em exceções lançadas quandoOnErrorOption.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 chamarinsertRow
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