Snowflake High Performance connector for Kafka¶

Avantages¶

Le Snowflake High Performance connector for Kafka exploite l’architecture Snowpipe Streaming hautes performances de Snowflake, qui est conçue pour les organisations modernes, à forte intensité de données, qui exigent des informations en quasi temps réel. Cette architecture nouvelle génération améliore considérablement le débit, l’efficacité et la flexibilité pour l’ingestion en temps réel dans Snowflake.

L’architecture hautes performances offre plusieurs avantages clés :

• Débit supérieur et latence : conçue pour prendre en charge des vitesses d’ingestion pouvant atteindre 10 GB/s par table avec ingestion de bout en bout pour interroger des latences de 5 à 10 secondes, permettant des analyses en temps quasi réel.

• Facturation simplifiée : fournit une facturation transparente basée sur le débit, ce qui rend les coûts plus prévisibles et plus faciles à comprendre.

• Performances améliorées : utilise un cœur client basé sur Rust qui offre de meilleures performances côté client et une utilisation moindre des ressources par rapport aux implémentations précédentes.

• Transformations en cours : Prend en charge le nettoyage et la transformation des données lors de l’ingestion à l’aide de la syntaxe de la commande COPY dans l’objet PIPE, vous permettant de transformer les données avant qu’elles n’atteignent la table cible.

• Validation des schémas côté serveur : déplace la validation des schémas du côté client vers le côté serveur via l’objet PIPE, garantissant la qualité des données et réduisant la complexité du client.

• Capacité de pré-clustering : peut regrouper les données lors de l’ingestion lorsque la table cible possède des clés de clustering définies, ce qui améliore les performances des requêtes sans nécessiter de maintenance après l’ingestion.

Le connecteur utilise les objets Snowflake PIPE comme composant central de la gestion de l’ingestion. L’objet PIPE agit en tant que point d’entrée et couche de définition pour toutes les données en continu, définissant comment les données sont traitées, transformées et validées avant d’être validées dans la table cible. Pour plus d’informations sur la manière dont le connecteur fonctionne avec les tables et les canaux, voir Comment le connecteur fonctionne-t-il avec les tables et les canaux ?.

Sélection d’une version de connecteur¶

Le connecteur Kafka fonctionne dans un cluster Kafka Connect. Il lit les données des sujets Kafka et écrit dans des tables Snowflake.

Snowflake fournit deux versions du connecteur. Les deux versions du connecteur offrent la même fonctionnalité de base pour le flux de données de Kafka vers Snowflake.

• Version Confluent du connecteur

  Le connecteur Snowflake Connector haute performance pour Kafka n’est pas encore disponible sur Confluent Cloud. Si vous utilisez Confluent Cloud, vous devez installer le connecteur manuellement en tant que connecteur de plugin personnalisé.

  La version Confluent est conçue pour une installation facile via Confluent Hub ou Confluent Control Center et comprend des optimisations pour l’environnement Confluent Platform.

  Choisissez cette version si vous utilisez Confluent Platform ou Confluent Cloud.

  Veuillez contacter l’assistance de Snowflake pour obtenir et installer la version Confluent du connecteur.

  Pour plus d’informations sur Kafka Connect, voir : https://docs.confluent.io/current/connect/.

• open source software (OSS) Apache Kafka package https://mvnrepository.com/artifact/com.snowflake/snowflake-kafka-connector/ - Version Apache Kafka OSS du connecteur.

  La version Apache est distribuée en tant que fichier JAR standard et nécessite une installation manuelle dans votre cluster Apache Kafka Connect. Choisissez cette version si vous exécutez Apache Kafka.

  Pour plus d’informations sur Apache Kafka, voir : https://kafka.apache.org/.

Limitations¶

Le Snowflake High Performance connector for Kafka a les limitations suivantes :

Création de table :

les tables de destination doivent être créées manuellement avant de démarrer le connecteur. Le connecteur ne crée pas de tables automatiquement.

Migration à partir de la version 3.x et antérieure

Vous pouvez migrer manuellement vos pipelines existants de la version 3.x ou antérieure vers le nouveau connecteur. Assurez-vous que vos pipelines existants ne dépendent pas de fonctions qui ne sont pas encore disponibles avec le nouveau connecteur.

Stabilité de la configuration

Les noms des paramètres de configuration sont susceptibles d’être modifiés pendant la phase d’avant première privée. Tous les paramètres de configuration que vous utilisez peuvent être renommés ou restructurés avant l’avant-première publique. Snowflake fournira des conseils de migration lorsque les noms des paramètres changeront.

Limitations du connecteur Kafka¶

Migration des pipelines existants à partir de la version 3.x et inférieure

Le connecteur ne prend pas en charge la migration des pipelines existants à partir de la version 3.x et des versions inférieures. Vous devez migrer manuellement les pipelines existants vers le nouveau connecteur.

Transformations de message unique (SMTs) :

La plupart des transformations de message unique (SMTs) sont pris en charge lors de l’utilisation de convertisseurs communautaires, à l’exception de regex.router qui n’est actuellement pas pris en charge.

Pour plus d’informations sur les SMTs, voir Référence de transformation de message Kafka Connect pour Confluent Cloud ou Confluent Platform.

Fonctionnalités non prises en charge¶

Les fonctionnalités suivantes ne sont pas prises en charge :

Évolution du schéma

L’évolution du schéma n’est pas prise en charge. Vous devez gérer les modifications de schéma manuellement. Pour plus d’informations, voir Évolution du schéma.

Tables Iceberg

L’ingestion dans les tables Iceberg n’est pas prise en charge.

Création automatique de tables

Le connecteur ne crée pas de tables automatiquement. Vous devez créer manuellement des tables avant de démarrer le connecteur.

Les enregistrements cassés ne sont pas envoyés à la file d’attente de lettres mortes (DLQ) par le connecteur

Si vous définissez errors.tolerance=all et errors.deadletterqueue.topic.name, seuls les enregistrements non convertis sont envoyés à la DLQ par le gestionnaire d’erreurs au niveau de Kafka Connect. Si l’enregistrement est transmis au connecteur et qu’il ne parvient pas à être ingéré dans Snowflake, il ne sera pas envoyé à la DLQ. Il s’agit d’une limitation existante de Snowpipe Streaming hautes performances. Le connecteur est incapable de détecter les enregistrements qui n’ont pas été ingérés dans Snowflake. Il peut uniquement détecter si une certaine quantité d’enregistrements n’a pas été ingérée. En raison de cela avec le paramètre errors.tolerance=all, le connecteur ne garantit que la livraison au plus une fois.

Les enregistrements interrompus qui n’ont pas pu être ingérés doivent être réessayés manuellement

Si vous définissez errors.tolerance=none, le connecteur fera échouer la tâche dès qu’il détectera que rows_error_count est supérieur à 0 dans le statut du canal. Pour réessayer les enregistrements interrompus, l’utilisateur doit les rechercher en consultant l’historique des canaux. Pour plus d’informations sur le dépannage des enregistrements interrompus et des erreurs d’ingestion, voir traitement des erreurs. Vous pouvez également utiliser la technique de recherche des écarts décrite dans la section Détecter les erreurs et y remédier à l’aide des décalages de métadonnées. Les informations de décalage Kafka nécessaires pour utiliser cette technique sont disponibles dans la colonne RECORD_METADATA.

Externaliser les secrets¶

Snowflake recommande fortement d’externaliser des secrets tels que la clé privée et de les stocker sous une forme chiffrée ou dans un service de gestion de clés tel que AWS Key Management Service (KMS), Microsoft Azure Key Vault, ou HashiCorp Vault. Pour ce faire, utilisez une implémentation ConfigProvider sur votre cluster Kafka Connect.

Pour plus d’informations, voir la description de ce service par Confluent.

Considérations relatives au cache pour les tests et le prototypage¶

Le connecteur met en cache les contrôles d’existence des tables et des canaux pour améliorer les performances lors des rééquilibrages des partitions. Cependant, lors des tests et du prototypage, ce comportement de mise en cache peut empêcher le connecteur de détecter immédiatement les tables ou les canaux créés manuellement.

Problème : lorsque vous créez manuellement une table ou un canal pendant que le connecteur est en cours d’exécution, le connecteur peut continuer à utiliser les résultats de la vérification de l’existence en cache (qui peuvent indiquer que l’objet n’existe pas) pendant 5 minutes par défaut. Cela peut conduire à des erreurs ou à des comportements inattendus pendant le test.

Recommandation pour les tests : pour éviter les problèmes liés au cache lors des tests et du prototypage, configurez les deux paramètres d’expiration du cache à leur valeur minimale de 1 milliseconde ou désactivez la mise en cache :

snowflake.cache.table.exists.expire.ms=1
snowflake.cache.pipe.exists.expire.ms=1

Cette configuration garantit que le connecteur effectue de nouveaux contrôles d’existence à chaque rééquilibrage de partition, ce qui vous permet de voir immédiatement les effets des tables et des canaux créés manuellement.

Changements importants dans la version d’avant première privée¶

Voir les notes de version des versions d’avant première privée pour une liste des changements importants.

• 4.0.0-rc1

• 4.0.0-rc2

• 4.0.0-rc3

• 4.0.0-rc4

Prochaines étapes¶

Consultez la rubrique Configurer des tâches pour le Snowflake High Performance connector for Kafka relative aux étapes de configuration du Snowflake High Performance connector for Kafka. . Consultez la rubrique comment fonctionne le connecteur pour plus d’informations sur la façon dont le connecteur fonctionne avec les tables et les canaux.