Práticas recomendadas para o Snowpipe Streaming Classic¶

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á inserindo, os custos de computação para a migração de arquivos poderão ser reduzidos. A operação de clustering otimiza e migra os 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 é mais eficiente e econômico do que chamar insertRow várias vezes, porque menos tempo é gasto com 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.
Quando você criar um canal usando OpenChannelRequest.builder, defina 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 registro padrão como DEBUG, certifique-se de que os seguintes registradores continuem registrando em INFO: a 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 a inserção de dados, pois os dados dentro dos canais são automaticamente descarregados com base no tempo configurado em MAX_CLIENT_LAG.

Recomendações de latência¶

Quando você usa o Snowpipe Streaming, a latência se refere à rapidez com que os dados gravados em um canal ficam disponíveis para consulta no Snowflake. O Snowpipe Streaming libera automaticamente os dados dentro dos canais a cada um segundo, o que significa que você não precisa fechar explicitamente um canal para que os dados sejam liberados.

Configurando a latência com MAX_CLIENT_LAG. Com o Snowflake Ingest SDK versões 2.0.4 e posteriores, você pode ajustar a latência de descarga de dados usando a opção MAX_CLIENT_LAG:

Tabelas padrão do Snowflake (não Iceberg): o padrão de MAX_CLIENT_LAG é 1 segundo. Você pode substituir isso para definir a latência de esvaziamento desejada de 1 segundo até um máximo de 10 minutos.
Tabelas Iceberg gerenciadas pelo Snowflake: compatível com o Snowflake Ingest SDK versões 3.0.0 e posteriores, o padrão de MAX_CLIENT_LAG é de 30 segundos. Esse padrão ajuda a garantir que sejam criados arquivos Parquet otimizados, o que é benéfico para o desempenho da consulta. Embora seja possível definir um valor mais baixo, isso geralmente não é recomendado, a menos que o rendimento seja excepcionalmente alto.

Recomendações de latência para um desempenho ideal. A configuração eficaz de MAX_CLIENT_LAG pode afetar significativamente o desempenho da consulta e o processo de migração interna (em que o Snowflake compacta pequenas partições).

Em cenários de baixa taxa de transferência, em que você pode estar enviando apenas uma pequena quantidade de dados (por exemplo, 1 linha ou 1 KB) a cada segundo, as descargas frequentes podem levar a várias partições pequenas. Isso pode aumentar o tempo de compilação da consulta, pois o Snowflake precisa resolver muitas partições minúsculas, especialmente se as consultas forem executadas antes que o processo de migração possa compactá-las.

Portanto, você deve definir MAX_CLIENT_LAG o mais alto que seus requisitos de latência de destino permitirem. O armazenamento em buffer das linhas inseridas por um período mais longo permite que o Snowpipe Streaming crie partições de melhor tamanho, o que melhora o desempenho da consulta e reduz a sobrecarga de migração. Por exemplo, se você tiver uma tarefa que é executada a cada minuto para mesclar ou transformar os dados transmitidos, um MAX_CLIENT_LAG ideal pode ter entre 50 e 55 segundos. Isso garante que os dados sejam descarregados em partes maiores logo antes da execução do processo downstream.

Conector Kafka para Snowpipe Streaming. É importante observar que o conector Kafka para Snowpipe Streaming tem seu próprio buffer interno. Quando o tempo de descarga do buffer do Kafka é atingido, os dados são enviados ao Snowflake com a latência padrão de um segundo por meio do Snowpipe Streaming. Para obter mais informações, consulte a configuração de buffer.flush.time