Recomendamos fortemente o uso de compressão nos seus tópicos do Kafka. A compressão pode gerar uma economia significativa nos custos de transferência de dados, com praticamente nenhum impacto no desempenho.
Para saber mais sobre compressão de mensagens no Kafka, recomendamos começar por este guia.
DEFAULT não é suportado.- As mensagens individuais são limitadas, por padrão, a 16 MB (sem compactação) ao usar o menor tamanho de réplica (XS), e a 32 MB (sem compactação) com réplicas maiores. As mensagens que excederem esse limite serão rejeitadas com erro. Se precisar de mensagens maiores, entre em contato com o suporte.
O ClickPipes para Kafka garante entrega pelo menos uma vez por padrão, acompanhando o progresso da ingestão por meio dos offsets do grupo de consumidores do Kafka. Ele também oferece suporte opcional à semântica de exatamente uma vez, em que cada registro do Kafka é inserido no ClickHouse exatamente uma vez, mesmo em caso de reinicializações de pods, rebalanceamentos de consumidores e falhas de inserção.
Para garantir a entrega exatamente uma vez, o ClickPipes registra o progresso de cada partição em seu armazenamento de estado interno usando dois valores:
- Marca d’água — o offset até o qual a inserção de todos os registros da partição no ClickHouse está confirmada. Ao reiniciar, o ClickPipes descarta qualquer registro nesse marco ou abaixo dele, para que dados já inseridos nunca sejam enviados novamente.
- Intervalos pendentes — os intervalos de offsets dos blocos de inserção enviados ao ClickHouse, mas ainda não confirmados. Após uma falha, o ClickPipes reproduz exatamente esses intervalos.
Cada bloco de inserção abrange um intervalo contíguo de offsets e inclui um token de desduplicação determinístico no formato topic:partition:firstOffset-lastOffset. Na reprodução, o ClickPipes recria o mesmo intervalo de offsets e, portanto, o mesmo token, fazendo com que o ClickHouse rejeite a duplicata. Como o token depende apenas do intervalo de offsets, uma reprodução é desduplicada mesmo quando o bloco recriado não é idêntico byte a byte.
Janela de desduplicaçãoA desduplicação por token é limitada pela replicated_deduplication_window da tabela de destino (os 10.000 blocos de inserção mais recentes por padrão) e por replicated_deduplication_window_seconds (uma hora por padrão). Pipes de alta vazão podem consumir rapidamente a janela de contagem de blocos, portanto, recomendamos verificar e, se necessário, aumentar ambas as configurações na tabela de destino para cobrir o maior atraso de reprodução possível. Dados reproduzidos após o token sair da janela podem ser inseridos novamente; nesse caso, a garantia de exatamente uma vez não se aplica. SASL/SCRAM-SHA-256 e SASL/SCRAM-SHA-512. Dependendo da fonte de streaming (Redpanda, MSK etc.), todos ou apenas alguns desses mecanismos de autenticação serão habilitados, conforme a compatibilidade. Se suas necessidades de autenticação forem diferentes, envie seu feedback.
Tamanho de fetch do Warpstream
max.fetch_bytes para limitar o volume de dados processados por um único nó do ClickPipes em um dado momento. Em algumas situações,
o Warpstream não respeita essa configuração, o que pode causar falhas inesperadas nos pipes. Recomendamos fortemente definir a configuração específica do Warpstream kafkaMaxFetchPartitionBytesUncompressedOverride
como 8MB (ou menos) ao configurar seu agent do WarpStream para evitar falhas no ClickPipes.
O ClickPipes oferece suporte aos seguintes tipos de autenticação do AWS MSK:
Ao usar a autenticação do IAM para se conectar a um broker do MSK, a role do IAM deve ter as permissões necessárias.
Abaixo está um exemplo da política de IAM necessária para as APIs do Apache Kafka no MSK:
Configurando uma relação de confiança
O acesso baseado em função só funciona para instâncias do ClickHouse Cloud implantadas na AWS.
Certificados personalizados
- O tamanho do lote atingiu o máximo (100.000 linhas ou 28 MB por 1 GB de memória do pod do Kubernetes)
- O lote permaneceu aberto pelo tempo máximo (5 segundos)
A latência (definida como o tempo entre a produção da mensagem no Kafka e sua disponibilização no ClickHouse) dependerá de vários fatores (por exemplo, latência do broker, latência da rede e tamanho/formato da mensagem). O processamento em lotes descrito na seção acima também afetará a latência. Recomendamos sempre testar seu caso de uso específico com cargas típicas para determinar a latência esperada.
O ClickPipes não oferece garantias em relação à latência. Se você tiver requisitos específicos de baixa latência, entre em contato conosco.
O ClickPipes do Kafka foi projetado para escalar horizontal e verticalmente. Por padrão, criamos um grupo de consumidores com um consumidor. Isso pode ser configurado durante a criação do ClickPipe ou a qualquer momento em Configurações -> Configurações avançadas -> Escalonamento.
O ClickPipes oferece alta disponibilidade com uma arquitetura distribuída entre zonas de disponibilidade.
Isso exige o escalonamento para pelo menos dois consumidores.
Independentemente do número de consumidores em execução, a tolerância a falhas é nativa.
Se um consumidor ou a infraestrutura subjacente falhar,
o ClickPipe reiniciará automaticamente o consumidor e continuará processando mensagens.
Abaixo estão alguns benchmarks informais do ClickPipes do Kafka que podem ser usados para ter uma ideia geral do desempenho de referência. É importante saber que muitos fatores podem afetar o desempenho, incluindo o tamanho das mensagens, os tipos de dados e o formato dos dados. Os resultados podem variar, e o que mostramos aqui não garante o desempenho real.
Detalhes do benchmark:
- Usamos serviços de produção do ClickHouse Cloud com recursos suficientes para garantir que a vazão não fosse limitada pelo processamento de insert no ClickHouse.
- O serviço do ClickHouse Cloud, o cluster Kafka (Confluent Cloud) e o ClickPipe estavam todos em execução na mesma região (
us-east-2).
- O ClickPipe foi configurado com uma única réplica de tamanho L (4 GiB de RAM e 1 vCPU).
- Os dados de exemplo incluíam dados aninhados com uma combinação de tipos de dados
UUID, String e Int. Outros tipos de dados, como Float, Decimal e DateTime, podem ter desempenho inferior.
- Não houve diferença perceptível de desempenho entre o uso de dados compactados e não compactados.
