Introduction aux connecteurs Kafka

Pour le connecteur source, la configuration de référence est disponible à$CONFLUENT_HOME/etc/kafka/connect-file-source.properties:

Cette configuration a certaines propriétés communes à tous les connecteurs source:

Dans ce cas, nous avons également un attribut spécifique au connecteur:

Pour que cela fonctionne, créons un fichier de base avec du contenu:

Notez que le répertoire de travail est $ CONFLUENT_HOME.

Pour notre connecteur récepteur, nous utiliserons la configuration de référence à$CONFLUENT_HOME/etc/kafka/connect-file-sink.properties:

Logiquement, il contient exactement les mêmes paramètres,though this time connector.class specifies the sink connector implementation, and file is the location where the connector should write the content.

Enfin, nous devons configurer le travailleur Connect, qui intégrera nos deux connecteurs et effectuera le travail de lecture à partir du connecteur source et d’écriture sur le connecteur du récepteur.

Pour cela, nous pouvons utiliser$CONFLUENT_HOME/etc/kafka/connect-standalone.properties:

Notez queplugin.path peut contenir une liste de chemins, où les implémentations de connecteur sont disponibles

Comme nous utiliserons des connecteurs fournis avec Kafka, nous pouvons définirplugin.path sur$CONFLUENT_HOME/share/java. Sous Windows, il peut être nécessaire de fournir un chemin absolu ici.

Pour les autres paramètres, on peut laisser les valeurs par défaut:

Et la liste des paramètres est assez mature, alors consultez lesofficial documentation pour une liste complète.

Et avec cela, nous pouvons commencer notre première configuration de connecteur:

Tout d'abord, nous pouvons inspecter le contenu du sujet en utilisant la ligne de commande:

Comme nous pouvons le voir, le connecteur source a pris les données du fichiertest.txt, les a transformées en JSON et les a envoyées à Kafka:

Et, si nous regardons le dossier$CONFLUENT_HOME, nous pouvons voir qu'un fichiertest.sink.txt was créé ici:

Lorsque le connecteur récepteur extrait la valeur de l'attributpayload et l'écrit dans le fichier de destination, les données detest.sink.txt ont le contenu du fichiertest.txt d'origine.

Ajoutons maintenant plus de lignes àtest.txt.

Lorsque nous le faisons, nous voyons que le connecteur source détecte ces modifications automatiquement.

Nous devons simplement nous assurer d'insérer une nouvelle ligne à la fin, sinon le connecteur source ne prendra pas en compte la dernière ligne.

À ce stade, arrêtons le processus de connexion, car nous allons démarrer Connect dansdistributed mode en quelques lignes.

Une configuration de référence pour le mode distribué peut être trouvée dans $ CONFLUENT_HOME/etc/kafka/connect-distributed.properties.

Les paramètres sont généralement les mêmes que pour le mode autonome. Il n'y a que quelques différences:

Encore une fois, leofficial documentation fournit une liste avec tous les paramètres.

Nous pouvons démarrer Connect en mode distribué comme suit:

Désormais, par rapport à la commande de démarrage autonome, nous n'avons transmis aucune configuration de connecteur en tant qu'arguments. Au lieu de cela, nous devons créer les connecteurs à l'aide de l'API REST.

Pour configurer notre exemple précédent, nous devons envoyer deux requêtes POST àhttp://localhost:8083/connectors contenant les structures JSON suivantes.

Premièrement, nous devons créer le corps du connecteur source POST sous forme de fichier JSON. Ici, nous l'appelleronsconnect-file-source.json:

Notez à quel point cela ressemble assez au fichier de configuration de référence que nous avons utilisé la première fois.

Et puis nous postons:

Ensuite, nous ferons de même pour le connecteur récepteur, en appelant le fichierconnect-file-sink.json:

Et effectuez le POST comme avant:

Si nécessaire, nous pouvons vérifier que cette configuration fonctionne correctement:

Et, si nous regardons le dossier$CONFLUENT_HOME, nous pouvons voir qu'un fichiertest-distributed.sink.txt was créé ici:

Après avoir testé la configuration distribuée, faisons le ménage en supprimant les deux connecteurs:

Les transformations nous permettent d’apporter des modifications simples et légères à des messages individuels.

Kafka Connect prend en charge les transformations intégrées suivantes:

Une transformation est configurée à l'aide des paramètres suivants:

Pour tester certaines fonctionnalités de transformation, configurons les deux transformations suivantes:

Avant d'appliquer nos transformations, nous devons configurer Connect pour utiliser le JSON sans schéma, en modifiant lesconnect-distributed.properties:

Après cela, nous devons redémarrer Connect, toujours en mode distribué:

De nouveau, nous devons créer le corps du POST du connecteur source sous forme de fichier JSON. Ici, nous l'appelleronsconnect-file-source-transform.json.

Outre les paramètres déjà connus, nous ajoutons quelques lignes pour les deux transformations requises:

Après cela, effectuons le POST:

Écrivons quelques lignes dans nostest-transformation.txt:

Si nous inspectons maintenant la rubriqueconnect-transformation, nous devrions obtenir les lignes suivantes:

Les connecteurs pré-construits sont disponibles à partir de différentes sources:

La version d'entreprise de Confluent fournit un script pour l'installation de Connectors et d'autres composants à partir de Confluent Hub (le script n'est pas inclus dans la version Open Source). Si nous utilisons la version entreprise, nous pouvons installer un connecteur à l'aide de la commande suivante:

Si nous avons besoin d’un connecteur qui n’est pas disponible sur Confluent Hub ou si nous avons la version Open Source de Confluent, nous pouvons installer les connecteurs requis manuellement. Pour cela, nous devons télécharger et décompresser le connecteur, ainsi que déplacer les bibliothèques incluses dans le dossier spécifié commeplugin.path.

Pour chaque connecteur, l'archive doit contenir deux dossiers qui nous intéressent:

Nous devons déplacer le dossierlib vers$CONFLUENT_HOME/share/java, ou le chemin que nous avons spécifié commeplugin.path dansconnect-standalone.properties etconnect-distributed.properties. Ce faisant, il peut également être judicieux de renommer le dossier en quelque chose de significatif.

Nous pouvons utiliser les fichiers de configuration deetc soit en les référençant en démarrant en mode autonome, soit nous pouvons simplement récupérer les propriétés et créer un fichier JSON à partir d'elles.