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 2 MB (sin comprimir) cuando se usa el tamaño de réplica más pequeño (XS), y a 8 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 for Kafka proporciona semántica de entrega at-least-once (uno de los enfoques más utilizados). Nos gustaría conocer tus comentarios sobre la semántica de entrega a través de nuestro formulario de contacto. Si necesitas semántica exactly-once, te recomendamos usar nuestro sink oficial clickhouse-kafka-connect.
Para las fuentes de datos del protocolo Apache Kafka, ClickPipes admite autenticación SASL/PLAIN con cifrado TLS, así como 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:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect"
],
"Resource": [
"arn:aws:kafka:us-west-2:12345678912:cluster/clickpipes-testing-brokers/b194d5ae-5013-4b5b-ad27-3ca9f56299c9-10"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-west-2:12345678912:topic/clickpipes-testing-brokers/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:12345678912:group/clickpipes-testing-brokers/*"
]
}
]
}
Configurar una relación de confianza
El acceso basado en roles solo funciona para las instancias de ClickHouse Cloud desplegadas en AWS.
{
"Version": "2012-10-17",
"Statement": [
...
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::12345678912:role/CH-S3-your-clickhouse-cloud-role"
},
"Action": "sts:AssumeRole"
}
]
}
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.
| Tamaño de la réplica | Tamaño del mensaje | Formato de los datos | Rendimiento |
|---|
| Grande (L) | 1.6kb | JSON | 63mb/s |
| Grande (L) | 1.6kb | Avro | 99mb/s |
