Recomendamos encarecidamente usar compresión en sus topics de Kafka. La compresión puede suponer un ahorro significativo en los costes de transferencia de datos, prácticamente sin afectar al rendimiento.
Para obtener más información sobre la compresión de mensajes en Kafka, le recomendamos empezar por esta guía.
DEFAULT no se admite.- De forma predeterminada, los mensajes individuales están limitados a 16 MB (sin comprimir) cuando se usa el tamaño de réplica más pequeño (XS), y a 32 MB (sin comprimir) con réplicas de mayor tamaño. Los mensajes que superen este límite se rechazarán con un error. Si necesita mensajes más grandes, póngase en contacto con el soporte técnico.
ClickPipes para Kafka garantiza la entrega al menos una vez de forma predeterminada y realiza el seguimiento del progreso de la ingestión mediante los offsets del grupo de consumidores de Kafka. También admite opcionalmente semántica de exactamente una vez, en la que cada registro de Kafka se inserta en ClickHouse exactamente una vez, incluso tras reinicios de pods, reequilibrios de consumidores y errores de inserción.
Para garantizar la entrega exactamente una vez, ClickPipes registra el progreso de cada partición en su almacén de estado interno mediante dos valores:
- Marca de agua — el offset hasta el que se confirma que todos los registros de la partición se han insertado en ClickHouse. Al reiniciarse, ClickPipes descarta cualquier registro que esté en esa marca o por debajo de ella, por lo que los datos ya insertados nunca se vuelven a enviar.
- Rangos pendientes — los rangos de offsets de los bloques de inserción enviados a ClickHouse pero aún no confirmados. Tras un error, ClickPipes reproduce exactamente esos rangos.
Cada bloque de inserción abarca un rango contiguo de offsets e incluye un token de deduplicación determinista con el formato topic:partition:firstOffset-lastOffset. Durante la reproducción, ClickPipes vuelve a generar el mismo rango de offsets y, por tanto, el mismo token, de modo que ClickHouse rechaza el duplicado. Como el token depende únicamente del rango de offsets, una reproducción se deduplica incluso cuando el bloque reconstruido no es idéntico byte a byte.
Ventana de deduplicaciónLa deduplicación de tokens está limitada por replicated_deduplication_window de la tabla de destino (los 10.000 bloques de inserción más recientes de forma predeterminada) y replicated_deduplication_window_seconds (una hora de forma predeterminada). Las canalizaciones de alto rendimiento pueden agotar rápidamente la ventana basada en el número de bloques, por lo que recomendamos verificar y, si es necesario, aumentar ambos ajustes en la tabla de destino para cubrir el mayor retraso de reproducción previsto. Los datos reproducidos después de que su token haya salido de la ventana pueden volver a insertarse, por lo que en ese caso no se garantiza la entrega exactamente una vez. SASL/SCRAM-SHA-256 y SASL/SCRAM-SHA-512. Según la fuente de streaming (Redpanda, MSK, etc.), se habilitarán todos o solo algunos de estos mecanismos de autenticación en función de la compatibilidad. Si sus requisitos de autenticación son distintos, háganos llegar sus comentarios.
Tamaño de fetch de Warpstream
max.fetch_bytes para limitar el tamaño de los datos procesados en un único nodo de ClickPipes en un momento dado. En algunas circunstancias,
Warpstream no respeta esta configuración, lo que puede provocar fallos inesperados en los pipes. Recomendamos encarecidamente establecer la configuración específica de Warpstream kafkaMaxFetchPartitionBytesUncompressedOverride
en 8 MB (o menos) al configurar su agente de WarpStream para evitar fallos en ClickPipes.
ClickPipes admite los siguientes métodos de autenticación de AWS MSK
Al usar la autenticación de IAM para conectarse a un bróker de MSK, el rol de IAM debe tener los permisos necesarios.
A continuación, se muestra un ejemplo de la política de IAM necesaria para las API de Apache Kafka para MSK:
Configurar una relación de confianza
El acceso basado en roles solo funciona para las instancias de ClickHouse Cloud desplegadas en AWS.
Certificados personalizados
- El tamaño del lote ha alcanzado el máximo (100,000 filas o 28MB por 1GB de memoria del pod de Kubernetes)
- El lote ha permanecido abierto durante el tiempo máximo permitido (5 segundos)
La latencia (definida como el tiempo transcurrido entre que se produce el mensaje de Kafka y que el mensaje está disponible en ClickHouse) depende de varios factores (por ejemplo, la latencia del bróker, la latencia de red y el tamaño/formato del mensaje). El procesamiento por lotes descrito en la sección anterior también influye en la latencia. Recomendamos siempre probar su caso de uso concreto con cargas típicas para determinar la latencia esperada.
ClickPipes no ofrece ninguna garantía con respecto a la latencia. Si tiene requisitos específicos de baja latencia, contáctenos.
ClickPipes for Kafka está diseñado para escalar horizontal y verticalmente. De forma predeterminada, creamos un grupo de consumidores con un solo consumidor. Esto se puede configurar durante la creación del ClickPipe o en cualquier otro momento en Settings -> Advanced Settings -> Scaling.
ClickPipes ofrece alta disponibilidad mediante una arquitectura distribuida entre zonas de disponibilidad.
Esto requiere escalar a al menos dos consumidores.
La tolerancia a fallos está garantizada por diseño, independientemente del número de consumidores en ejecución.
Si un consumidor o su infraestructura subyacente falla,
el ClickPipe reiniciará automáticamente el consumidor y continuará procesando mensajes.
A continuación se muestran algunos benchmarks informales de ClickPipes for Kafka que pueden servir para hacerse una idea general del rendimiento de referencia. Es importante tener en cuenta que hay muchos factores que pueden afectar al rendimiento, como el tamaño de los mensajes, los tipos de datos y el formato de los datos. Los resultados pueden variar, y lo que mostramos aquí no garantiza el rendimiento real.
Detalles del benchmark:
- Usamos servicios de producción de ClickHouse Cloud con recursos suficientes para garantizar que el throughput no estuviera limitado por el procesamiento de inserción del lado de ClickHouse.
- El servicio de ClickHouse Cloud, el cluster de Kafka (Confluent Cloud) y el ClickPipe se ejecutaban en la misma región (
us-east-2).
- El ClickPipe se configuró con una sola réplica de tamaño L (4 GiB de RAM y 1 vCPU).
- Los datos de muestra incluían datos anidados con una combinación de tipos de datos
UUID, String e Int. Otros tipos de datos, como Float, Decimal y DateTime, pueden ofrecer un rendimiento inferior.
- No hubo diferencias apreciables de rendimiento al usar datos comprimidos y sin comprimir.
