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.

Quando você usa as mesmas tabelas para ingestão em lote e streaming, também pode reduzir os custos de computação do Snowpipe Streaming devido às operações de migração de arquivos antecipadas.

O Snowpipe Streaming gerencia e cobra todos os custos de computação da migração de arquivos para tabelas com Clustering automático ativado, onde o Snowpipe Streaming está inserindo dados. Esse processo otimiza e migra dados dentro da mesma transação, incorporando os custos anteriormente associados ao Clustering automático.

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

Práticas recomendadas de entrega exatamente um¶

Conseguir uma entrega exatamente única pode ser um desafio, e a adesão aos seguintes princípios em seu código personalizado é fundamental:

Para garantir a recuperação adequada de exceções, falhas ou travamentos, você deve sempre reabrir o canal e reiniciar a ingestão usando o último token de offset confirmado.

Embora seu aplicativo possa manter seu próprio offset, é fundamental usar o último token de offset confirmado fornecido pelo Snowflake como a fonte da verdade e redefinir seu próprio offset de acordo.

A única instância em que seu próprio offset deve ser tratado como a fonte da verdade é quando o token de offset do Snowflake é definido ou redefinido como NULL. Um token de offset NULL geralmente significa uma das seguintes opções:

Esse é um novo canal, portanto, nenhum token de offset foi definido.

A tabela de destino foi descartada e recriada, portanto, o canal é considerado novo.

Não houve nenhuma atividade de ingestão no canal por 30 dias, então o canal foi limpo automaticamente e as informações do token offset foram perdidas.

Se necessário, você pode limpar periodicamente os dados de origem que já foram confirmados com base no último token offset confirmado e avançar seu próprio offset.

Se o esquema da tabela for modificado quando os canais do Snowpipe Streaming estiverem ativos, o canal deverá ser reaberto. O conector Snowflake Kafka lida com esse cenário automaticamente, mas se você usar o Snowflake Ingest SDK diretamente, precisará reabrir o canal.

Para obter mais informações sobre como o conector Kafka com o Snowpipe Streaming consegue uma entrega exata, consulte Semântica exatamente um.