Les ClickPipes Kinesis peuvent être déployés et gérés manuellement via l’UI ClickPipes, ainsi que de manière programmatique à l’aide d’OpenAPI et de Terraform.
Vous vous êtes familiarisé avec l’introduction à ClickPipes et avez configuré des identifiants IAM ou un rôle IAM. Suivez le guide d’accès basé sur les rôles pour Kinesis pour savoir comment configurer un rôle compatible avec ClickHouse Cloud.
Création de votre premier ClickPipe
- Accédez à la SQL Console de votre service ClickHouse Cloud.
- Sélectionnez le bouton
Data Sources dans le menu de gauche, puis cliquez sur “Set up a ClickPipe”
- Sélectionnez votre source de données.
- Remplissez le formulaire en indiquant un nom pour votre ClickPipe, une description (facultative), votre rôle IAM ou vos identifiants, ainsi que les autres informations de connexion.
- Sélectionnez le Kinesis Stream et l’offset de départ. L’UI affichera un exemple de document provenant de la source sélectionnée (Kafka topic, etc.). Vous pouvez également activer Enhanced Fan-out pour les Kinesis streams afin d’améliorer les performances et la stabilité de votre ClickPipe (plus d’informations sur Enhanced Fan-out sont disponibles ici)
- À l’étape suivante, vous pouvez choisir d’ingérer les données dans une nouvelle table ClickHouse ou de réutiliser une table existante. Suivez les instructions à l’écran pour modifier le nom de la table, le schéma et les paramètres. Vous pouvez voir un aperçu en temps réel de vos modifications dans l’exemple de table affiché en haut.
Vous pouvez également personnaliser les paramètres avancés à l’aide des contrôles fournis
- Vous pouvez aussi choisir d’ingérer vos données dans une table ClickHouse existante. Dans ce cas, l’UI vous permettra de mapper les champs de la source aux champs ClickHouse dans la table de destination sélectionnée.
- Enfin, vous pouvez configurer les permissions de l’utilisateur interne ClickPipes.
Permissions : ClickPipes créera un utilisateur dédié pour écrire des données dans une table de destination. Vous pouvez sélectionner un rôle pour cet utilisateur interne à l’aide d’un rôle personnalisé ou de l’un des rôles prédéfinis :
Full access : accès complet au cluster. Cela peut être utile si vous utilisez une vue matérialisée ou un Dictionary avec la table de destination.
Only destination table : avec les permissions INSERT sur la seule table de destination.
- En cliquant sur “Complete Setup”, le système enregistrera votre ClickPipe et vous pourrez le voir dans le tableau récapitulatif.
Le tableau récapitulatif fournit des contrôles pour afficher des données d’exemple provenant de la source ou de la table de destination dans ClickHouse
Ainsi que des contrôles pour supprimer le ClickPipe et afficher un récapitulatif de la tâche d’ingestion.
- Félicitations ! Vous avez configuré avec succès votre premier ClickPipe. S’il s’agit d’un ClickPipe de streaming, il s’exécutera en continu et ingérera des données en temps réel depuis votre source de données distante. Sinon, il ingérera le batch, puis se terminera.
Les formats pris en charge sont :
ClickPipes for Kinesis détecte automatiquement les enregistrements compressés et les décompresse. Contrairement à Kafka, où la bibliothèque cliente gère la décompression de manière transparente, Kinesis transmet des octets bruts — ClickPipes s’en charge pour vous, sans aucune configuration.
Les codecs de compression suivants sont pris en charge :
- gzip
- zstd
- lz4
- snappy (format encapsulé en trames)
La compression est détectée automatiquement à l’aide des octets magiques de chaque enregistrement. Si aucune signature de compression connue n’est trouvée, l’enregistrement est traité comme non compressé. Le type de compression détecté apparaît également lors de l’inférence de schéma, afin que l’aperçu de l’échantillon de données dans l’UI affiche correctement les données décompressées.
La détection automatique est fiable pour les formats textuels comme JSON et CSV, car les caractères ASCII imprimables n’entrent jamais en conflit avec les octets magiques de compression.
Types de données pris en charge
Prise en charge des types standard
- Types numériques de base - [U]Int8/16/32/64, Float32/64 et BFloat16
- Types d’entiers de grande taille - [U]Int128/256
- Types Decimal
- Boolean
- String
- FixedString
- Date, Date32
- DateTime, DateTime64 (fuseaux horaires UTC uniquement)
- Enum8/Enum16
- UUID
- IPv4
- IPv6
- tous les types LowCardinality de ClickHouse
- Map avec des clés et des valeurs utilisant l’un des types ci-dessus (y compris les Nullable)
- Tuple et Array avec des éléments utilisant l’un des types ci-dessus (y compris les Nullable, profondeur d’un seul niveau uniquement)
- types SimpleAggregateFunction (pour les destinations AggregatingMergeTree ou SummingMergeTree)
Prise en charge des types Variant
Variant(String, Int64, DateTime)) pour n’importe quel champ JSON
du flux de données source. En raison de la façon dont ClickPipes détermine le sous-type de variant approprié, un seul type entier ou DateTime
peut être utilisé dans la définition de Variant. Par exemple, Variant(Int64, UInt32) n’est pas pris en charge.
Prise en charge du type JSON
Colonnes virtuelles Kinesis
Add Column.
Le champ _raw_message peut être utilisé lorsque seul l’enregistrement JSON Kinesis complet est nécessaire (par exemple, en utilisant les fonctions ClickHouse JsonExtract* pour alimenter une vue matérialisée en aval). Pour ce type de pipes, la suppression de toutes les colonnes « non virtuelles » peut améliorer les performances de ClickPipes.
- DEFAULT n’est pas pris en charge.
- La taille des messages individuels est limitée par défaut à 16MB (non compressés) avec la plus petite taille de réplique (XS), et à 32MB (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 insère les données dans ClickHouse par lots. Cela permet d’éviter de créer trop de parts dans la base de données, ce qui peut entraîner des problèmes de performances dans le cluster.
Les lots sont insérés dès que l’un des critères suivants est atteint :
- La taille du lot a atteint la taille maximale (100 000 lignes ou 32 Mo par 1 Go de mémoire de réplique)
- Le lot est resté ouvert pendant la durée maximale (5 secondes)
La latence (définie comme le temps écoulé entre l’envoi du message Kinesis vers le flux et le moment où le message devient disponible dans ClickHouse) dépendra de plusieurs facteurs (par ex. la latence de Kinesis, la latence réseau, ainsi que la taille/le format du message). Le traitement par lots décrit dans la section précédente aura également un impact sur la latence. Nous recommandons toujours de tester votre cas d’usage afin de comprendre la latence à laquelle vous pouvez vous attendre.
Si vous avez des exigences spécifiques en matière de faible latence, veuillez nous contacter.
Nous recommandons vivement de limiter le nombre de shards actifs simultanément afin de l’adapter à vos besoins en débit. Pour un flux Kinesis « On Demand », AWS attribue automatiquement un nombre de shards correspondant en fonction du débit,
mais pour les flux « Provisioned », provisionner trop de shards peut entraîner de la latence, comme décrit ci-dessous, ainsi qu’une hausse des coûts, car la tarification Kinesis pour ces flux est calculée « par shard ».
Si votre application productrice écrit en continu sur un grand nombre de shards actifs, cela peut entraîner de la latence si votre pipeline n’est pas dimensionné de façon suffisante pour les traiter efficacement. En fonction des limites de débit de Kinesis,
ClickPipes attribue un nombre précis de « workers » par réplique pour lire les données des shards. Par exemple, dans la plus petite taille, une réplique ClickPipes dispose de 4 de ces threads de travail. Si le producteur écrit
sur plus de 4 shards en même temps, les données des shards « supplémentaires » ne seront pas traitées tant qu’un thread de travail ne sera pas disponible. En particulier, si le pipeline utilise « enhanced fanout », chaque thread de travail s’abonne à un
seul shard pendant 5 minutes et ne peut lire aucun autre shard pendant cette période. Cela peut provoquer des « pics » de latence par tranches de 5 minutes.
ClickPipes for Kinesis est conçu pour une mise à l’échelle à la fois horizontale et verticale. Par défaut, nous créons un groupe de consommateurs avec un seul consommateur. Cela peut être configuré lors de la création du ClickPipe, ou ultérieurement dans Paramètres -> Paramètres avancés -> Mise à l’échelle.
ClickPipes offre une haute disponibilité grâce à une architecture répartie sur plusieurs zones de disponibilité.
Cela nécessite de passer à au moins deux consommateurs.
Quel que soit le nombre de consommateurs en cours d’exécution, la tolérance aux pannes est garantie 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.
Pour accéder aux flux Amazon Kinesis, vous pouvez utiliser des identifiants IAM ou un rôle IAM. Pour en savoir plus sur la configuration d’un rôle IAM, vous pouvez consulter ce guide, qui explique comment configurer un rôle compatible avec ClickHouse Cloud 
