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 2 MB (sem compactação) ao usar o menor tamanho de réplica (XS), e a 8 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 do Kafka oferece semântica de entrega at-least-once (uma das abordagens mais usadas). Gostaríamos muito de receber seu feedback sobre a semântica de entrega no formulário de contato. Se você precisar de semântica exactly-once, recomendamos usar nosso sink oficial clickhouse-kafka-connect.
Para fontes de dados do protocolo Apache Kafka, o ClickPipes oferece suporte à autenticação SASL/PLAIN com criptografia TLS, bem como a 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.
