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.
Par défaut, ClickPipes for Kafka garantit une livraison au moins une fois et suit la progression de l’ingestion à l’aide des offsets du groupe de consommateurs Kafka. Il prend également en charge, en option, la sémantique exactement une fois, dans laquelle chaque enregistrement Kafka est inséré dans ClickHouse exactement une fois, même en cas de redémarrage de pods, de rééquilibrage des consommateurs ou d’échec d’insertion.
Pour assurer une livraison exactement une fois, ClickPipes enregistre la progression de chaque partition dans son magasin d’état interne à l’aide de deux valeurs :
- Marque de hautes eaux — l’offset jusqu’auquel chaque enregistrement de la partition est confirmé comme ayant été inséré dans ClickHouse. Au redémarrage, ClickPipes ignore tout enregistrement dont l’offset est inférieur ou égal à cette marque, afin que les données déjà insérées ne soient jamais renvoyées.
- Plages en attente — les plages d’offsets des blocs d’insertion envoyés à ClickHouse mais pas encore confirmés. Après un échec, ClickPipes rejoue exactement ces plages.
Chaque bloc d’insertion couvre une plage contiguë d’offsets et porte un jeton de déduplication déterministe de la forme topic:partition:firstOffset-lastOffset. Lors d’une relecture, ClickPipes reproduit la même plage d’offsets et donc le même jeton, de sorte que ClickHouse rejette le doublon. Comme le jeton dépend uniquement de la plage d’offsets, une relecture est dédupliquée même lorsque le bloc reconstruit n’est pas identique octet pour octet.
Fenêtre de déduplicationLa déduplication par jeton est limitée par replicated_deduplication_window de la table cible (les 10 000 blocs d’insertion les plus récents par défaut) et par replicated_deduplication_window_seconds (une heure par défaut). Les pipelines à haut débit peuvent rapidement parcourir toute la fenêtre basée sur le nombre de blocs ; nous recommandons donc de vérifier et, si nécessaire, d’augmenter ces deux paramètres de la table cible afin de couvrir votre délai maximal de relecture. Les données rejouées après que leur jeton a quitté la fenêtre peuvent être insérées de nouveau ; la livraison exactement une fois n’est donc pas garantie dans ce cas. 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.
