Nous recommandons vivement d’utiliser la compression pour vos topics Kafka. La compression peut permettre de réduire considérablement les coûts de transfert de données, pratiquement sans impact sur les performances.
Pour en savoir plus sur la compression des messages dans Kafka, nous vous recommandons de commencer par ce guide.
DEFAULT n’est pas pris en charge.- Par défaut, la taille des messages individuels est limitée à 16 Mo (non compressés) avec la plus petite taille de réplique (XS), et à 32 Mo (non compressés) avec des répliques plus grandes. Les messages qui dépassent cette limite seront rejetés avec une erreur. Si vous avez besoin de messages plus volumineux, veuillez contacter l’assistance.
ClickPipes for Kafka offre des garanties de livraison at-least-once (l’une des approches les plus courantes). N’hésitez pas à nous faire part de vos retours sur les garanties de livraison via ce formulaire de contact. Si vous avez besoin de garanties exactly-once, nous vous recommandons d’utiliser notre sink officiel clickhouse-kafka-connect.
Pour les sources de données utilisant le protocole Apache Kafka, ClickPipes prend en charge l’authentification SASL/PLAIN avec chiffrement TLS, ainsi que SASL/SCRAM-SHA-256 et SASL/SCRAM-SHA-512. Selon la source de streaming (Redpanda, MSK, etc.), tout ou partie de ces mécanismes d’authentification seront activés en fonction de la compatibilité. Si vos besoins en matière d’authentification sont différents, veuillez nous faire part de vos retours.
Taille de récupération de Warpstream
max.fetch_bytes pour limiter la taille des données traitées simultanément sur un seul nœud ClickPipes. Dans certaines circonstances,
Warpstream ne respecte pas ce paramètre, ce qui peut provoquer des défaillances inattendues des pipelines. Nous recommandons vivement de définir le paramètre spécifique à Warpstream kafkaMaxFetchPartitionBytesUncompressedOverride
sur 8 MB (ou moins) lors de la configuration de votre agent WarpStream afin d’éviter des défaillances de ClickPipes.
ClickPipes prend en charge les mécanismes d’authentification AWS MSK suivants
Lors de l’utilisation de l’authentification IAM pour se connecter à un broker MSK, le rôle IAM doit disposer des autorisations nécessaires.
Vous trouverez ci-dessous un exemple de la stratégie IAM requise pour les API Apache Kafka pour MSK :
Configuration d’une relation de confiance
L’accès basé sur les rôles fonctionne uniquement pour les instances ClickHouse Cloud déployées sur AWS.
Certificats personnalisés
- La taille du lot a atteint la taille maximale (100 000 lignes ou 28 MB par 1 GB de mémoire de pod)
- Le lot est resté ouvert pendant la durée maximale autorisée (5 secondes)
La latence (définie comme le temps écoulé entre la production d’un message Kafka et le moment où il devient disponible dans ClickHouse) dépend de plusieurs facteurs (par exemple, la latence du broker, la latence réseau, ainsi que la taille et le format du message). Le traitement par lots décrit dans la section ci-dessus a également un impact sur la latence. Nous recommandons toujours de tester votre cas d’utilisation avec des charges typiques afin de déterminer la latence attendue.
ClickPipes ne fournit aucune garantie en matière de latence. Si vous avez des exigences particulières en matière de faible latence, veuillez nous contacter.
ClickPipes for Kafka est conçu pour une mise à l’échelle horizontale et verticale. Par défaut, nous créons un groupe de consommateurs avec un seul consommateur. Ce paramètre peut être configuré lors de la création du ClickPipe, ou à tout moment dans Paramètres -> Paramètres avancés -> Mise à l’échelle.
ClickPipes assure une haute disponibilité grâce à une architecture distribuée sur plusieurs zones de disponibilité.
Cela nécessite de passer à au moins deux consommateurs.
Quel que soit le nombre de consommateurs actifs, la tolérance aux pannes est assurée par conception.
Si un consommateur ou l’infrastructure sous-jacente tombe en panne,
le ClickPipe redémarre automatiquement le consommateur et poursuit le traitement des messages.
Vous trouverez ci-dessous quelques benchmarks informels pour ClickPipes for Kafka, qui donnent un ordre d’idée général des performances de référence. Il est important de noter que de nombreux facteurs peuvent influer sur les performances, notamment la taille des messages, les types de données et le format des données. Les résultats peuvent varier, et ce que nous présentons ici ne garantit pas les performances réelles.
Détails des benchmarks :
- Nous avons utilisé des services ClickHouse Cloud de production disposant de suffisamment de ressources pour que le débit ne soit pas limité par le traitement des insertions côté ClickHouse.
- Le service ClickHouse Cloud, le cluster Kafka (Confluent Cloud) et le ClickPipe s’exécutaient tous dans la même région (
us-east-2).
- Le ClickPipe était configuré avec un seul réplica de taille L (4 Gio de RAM et 1 vCPU).
- Les données d’échantillon comprenaient des données imbriquées avec un mélange de types de données
UUID, String et Int. D’autres types de données, comme Float, Decimal et DateTime, peuvent être moins performants.
- Aucune différence notable de performances n’a été observée entre les données compressées et non compressées.
