Zepto otimiza ingestão em larga escala no ClickHouse com Kafka Connect personalizado
Aprofundamento CEVIU
Aprofundamento
A Zepto não só aumentou o throughput em 45% no ClickHouse com um Kafka Connect personalizado, ela resolveu um gargalo operacional crítico: a ingestão de bilhões de eventos por dia para o Lucid, seu motor interno de análise de produtos. O problema não era o Kafka nem o ClickHouse isoladamente, mas a combinação de restrições do Confluent Cloud (infraestrutura gerenciada sem acesso a ajustes de baixo nível no broker e no conector) com as limitações do conector open-source original, que não suportava buffering inteligente nem controle fino de GC. A solução foi reescrever componentes-chave do conector para inserir lógica de buffer nativa, evitar pausas de coleta de lixo e implementar batching adaptativo baseado em tamanho *e* tempo, não mais apenas em contagem fixa de registros.
Isso coloca a Zepto dentro de uma tendência clara entre empresas de alta escala: abandonar conectores genéricos em favor de versões especializadas quando o custo operacional da latência ou da instabilidade supera o esforço de manutenção. Diferente da Grab, que unificou ingestão com Flink para reduzir tempo de integração, ou da Datadog, que migrou de Postgres para otimizar latência de queries, a Zepto atacou o ponto exato onde os dados entram no sistema analítico, e fez isso sem trocar o stack, apenas aprimorando o elo fraco. O fato de ter contribuído com duas correções upstream mostra que a otimização não foi um fork isolado, mas uma melhoria que beneficia toda a comunidade.
O que mudou
Na cobertura anterior do CEVIU sobre ingestão em larga escala, destacamos soluções baseadas em Flink (Grab), substituição de bancos transacionais (Datadog) ou escalonamento de consumidores (Cloudflare). A Zepto é a primeira no nosso histórico a reescrever diretamente o Kafka Connect para ClickHouse, não como um wrapper ou serviço paralelo (como o da Tinybird), mas como uma modificação profunda do conector open-source. Antes, o ecossistema dependia de configurações superficiais (como bufferCount e bufferFlushTime, introduzidas em maio de 2026) ou de serviços externos. Agora, a Zepto demonstrou que, para throughput sustentado acima de 10 MB/s com picos até 20 MB/s, é necessário controle granular sobre ciclo de vida do buffer, serialização Avro e timing de flush, algo que nenhum conector padrão oferecia até então.
Por que isso importa
ClickHouse é usado pela Zepto para relatórios em tempo real críticos, não para armazenamento histórico, mas para decisões operacionais de produto, como ajuste de estoque dinâmico e recomendação de ofertas. Um gargalo na ingestão significa insights atrasados, métricas desatualizadas e, consequentemente, perda de receita. Ao resolver isso com engenharia de baixo nível no conector, a Zepto garantiu que o Lucid processe milhões de eventos por minuto com consistência, mesmo enquanto sua base de usuários transacionais cresce para 47,97 milhões e os pedidos diários ultrapassam 1,75 milhão. Isso também afeta diretamente sua IPO: investidores avaliam infraestrutura de dados como indicador de maturidade operacional, especialmente em empresas de quick-commerce, onde velocidade de decisão = velocidade de execução.
Linha do tempo
Yelp atualiza 1.000 nós Cassandra 3.11 → 4.1 com zero downtime
Pinterest reestrutura dados de sequência do usuário com configuration-as-code
Grab lança plataforma unificada de ingestão com Apache Flink
Cloudflare escala Security Insights para 120 varreduras por segundo
Zepto otimiza ingestão no ClickHouse com Kafka Connect personalizado
Perguntas frequentes
Por que a Zepto não usou o conector gerenciado da Confluent Cloud para ClickHouse?
O conector da Confluent Cloud, embora autoescalável, não permite ajustes de baixo nível no buffer, no flush ou na serialização. Para a Zepto, isso gerava pausas de Garbage Collection e throughput instável, inaceitável para um motor analítico que alimenta decisões em tempo real.
Qual é a diferença entre o conector personalizado da Zepto e o novo suporte a 'bufferCount' lançado em maio de 2026?
A atualização de maio adicionou opções de configuração, mas mantém a lógica de buffer no nível do worker do Kafka Connect. A Zepto reescreveu o próprio sink para controlar o buffer *dentro do conector*, com flushing adaptativo e tratamento otimizado de Avro, algo que configurações não resolvem.
Como essa otimização se relaciona com a arquitetura lakehouse da Zepto (Delta Lake + Databricks + ClickHouse)?
O ClickHouse é o único componente da stack projetado para baixa latência em consultas ad hoc. Os dados chegam lá via Kafka Connect após processamento em Flink (para enriquecimento) e CDC via Debezium. Se esse último elo falha, o resto da cadeia fica cego para o que acontece *agora*, não só ontem ou na última janela de lote.
As contribuições upstream da Zepto já foram aceitas?
Sim. Duas correções foram enviadas ao repositório oficial do ClickHouse Kafka Connect em 17 de junho de 2026 e já estão integradas na versão 2.3.0 do conector, conforme confirmado no changelog do GitHub e no blog da Zepto.
Fontes
- blog.zepto.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 22 de junho de 2026
- Editoria
- CEVIU Dados
