Ce document présente les connecteurs Kafka Connect dansGoogle Cloud. Découvrez quand utiliser chaque type de connecteur pour gérer et intégrer vos flux de données.
Ces connecteurs utilisent le framework Kafka Connect pour intégrer Apache Kafka à d'autres applications. Ils ingèrent et répliquent les données entre vos clusters et applications Kafka. Voici les types de connecteurs disponibles :
Connecteurs MirrorMaker 2.0
Connecteur source
Connecteur de point de contrôle
Connecteur de pulsation
Connecteur de récepteur BigQuery
Connecteur de récepteur Cloud Storage
Connecteur source Pub/Sub
Connecteur de récepteur Pub/Sub
Les connecteurs MirrorMaker 2.0 sont spécifiquement conçus pour la réplication de données et la reprise après sinistre entre les clusters Kafka. Ils facilitent la mise en miroir des données d'un cluster Kafka vers un autre, ce qui permet d'assurer une haute disponibilité et une tolérance aux pannes.
Les connecteurs MirrorMaker 2.0 peuvent établir des connexions entre des clusters Managed Service pour Apache Kafka et d'autres clusters Managed Service pour Apache Kafka ou des clusters Kafka autogérés.
Les autres connecteurs de récepteur et de source servent à intégrer Kafka à différents servicesGoogle Cloud . Ces connecteurs permettent de transférer des données entre les clusters Managed Service for Apache Kafka et les services Google Cloud , tels que BigQuery, Cloud Storage ou Pub/Sub.
Avant de commencer
Avant d'explorer et de créer des connecteurs, assurez-vous de bien comprendre les points suivants et de remplir les conditions préalables suivantes :
Connaissances pratiques de Kafka Connect et des clusters Connect. Vous devez créer un cluster Connect avant de pouvoir déployer des connecteurs.
Pour les connecteurs de récepteur et de source, vous devez comprendre les tables BigQuery, les buckets Cloud Storage ou les sujets et abonnements Pub/Sub, selon le type de connecteurs que vous configurez.
Vous devez être familiarisé avec les fichiers de configuration YAML ou JSON, car les connecteurs sont configurés à l'aide de ces formats.
Quand utiliser MirrorMaker 2.0 ?
Utilisez les connecteurs MirrorMaker 2.0 dans les scénarios suivants :
Migrer des données : déplacez votre charge de travail Kafka vers un nouveau cluster Managed Service pour Apache Kafka.
Récupérer les données en cas de sinistre : créez un cluster de sauvegarde pour assurer la continuité de l'activité en cas de défaillance.
Agrégation des données : consolidez les données de plusieurs clusters Kafka dans un cluster Managed Service pour Apache Kafka central à des fins d'analyse.
Fonctionnalités clés de MirrorMaker 2.0
- Réplique tous les composants nécessaires, y compris les thèmes, les données, les configurations, les groupes de consommateurs avec des décalages et les LCA.
- Maintient le même schéma de partitionnement dans le cluster cible, ce qui simplifie la transition pour les applications.
- Détecte et réplique automatiquement les nouveaux thèmes et partitions, ce qui minimise la configuration manuelle.
- Fournit des métriques essentielles, comme la latence de réplication de bout en bout, qui vous permettent de suivre l'état et les performances du processus de réplication.
- Il garantit un fonctionnement fiable, même avec des volumes de données élevés, et peut être mis à l'échelle horizontalement pour gérer des charges de travail croissantes.
- Utilise des thèmes internes pour la synchronisation des décalages, les points de contrôle et les pulsations. Ces thèmes ont des facteurs de réplication configurables, tels que
offset.syncs.topic.replication.factor, pour assurer une haute disponibilité et une tolérance aux pannes.
Utiliser le connecteur source MirrorMaker 2.0
Le connecteur source MirrorMaker 2.0 réplique les sujets et les données d'un cluster Kafka (la source) vers un autre cluster Kafka (la cible).
| Source | Cible |
|---|---|
| Cluster Managed Service pour Apache Kafka | Cluster Managed Service pour Apache Kafka |
| Cluster Managed Service pour Apache Kafka | Cluster Kafka externe ou autogéré |
| Cluster Kafka externe ou autogéré | Cluster Managed Service pour Apache Kafka |
Le connecteur source MirrorMaker 2.0 est compatible avec les scénarios de migration suivants :
Répliquer ou migrer des données d'un cluster Kafka externe ou autogéré vers un cluster Managed Service pour Apache Kafka
Répliquez ou migrez des données d'un cluster Managed Service pour Apache Kafka vers un cluster Kafka externe ou autogéré.
Répliquez les données Kafka dans plusieurs régions pour répondre aux exigences de reprise après sinistre et de haute disponibilité.
Utiliser le connecteur de point de contrôle MirrorMaker 2.0
L'utilisation du connecteur de point de contrôle MirrorMaker 2.0 est facultative. Il copie les décalages de consommateur, qui indiquent le dernier message consommé avec succès. Ce processus garantit que les consommateurs du cluster cible peuvent reprendre le traitement au même point que le cluster source.
Ce connecteur n'est pas nécessaire au fonctionnement du connecteur source MirrorMaker 2.0. Ce connecteur n'est nécessaire que si vous devez synchroniser l'état ConsumerGroup pour minimiser les temps d'arrêt lors du passage du cluster source au cluster cible. Si vous n'avez besoin que d'une copie de vos données sources, ce connecteur n'est pas nécessaire.
Utilisez le connecteur de point de contrôle MirrorMaker 2.0 pour les cas d'utilisation suivants :
Reprise après sinistre pour maintenir un état consommateur cohérent entre les clusters et permettre un basculement fluide.
Préservez la progression des consommateurs dans les scénarios où cela est essentiel.
Utiliser le connecteur de pulsation MirrorMaker 2.0
Le connecteur de pulsation MirrorMaker 2.0 est un composant facultatif qui génère des messages de pulsation périodiques sur le cluster Kafka source. Le connecteur écrit ces messages dans un sujet dédié, généralement nommé heartbeats.
Vous pouvez configurer un connecteur source MirrorMaker 2.0 pour répliquer le sujet heartbeats dans le cluster cible. En observant ce sujet répliqué sur le cluster cible, vous pouvez surveiller l'état et les performances de votre flux de réplication de sujets. Cela permet de vérifier la connexion et le flux de données entre les clusters, même lorsqu'aucune autre donnée n'est produite ni répliquée.
Le déploiement du connecteur Heartbeat seul ne permet pas de surveiller automatiquement l'état de la réplication. Pour l'utiliser à des fins de surveillance, vous devez répliquer le sujet heartbeats, puis observer sa présence et sa ponctualité sur le cluster cible, ou utiliser des outils de surveillance qui consomment ces pulsations.
Le connecteur Heartbeat n'est pas nécessaire au fonctionnement du connecteur source MirrorMaker 2.0. Utilisez le connecteur de pulsation MirrorMaker 2.0 pour les cas d'utilisation suivants :
Surveillez l'état et le statut de la réplication MirrorMaker 2.
Configurez des alertes dans Cloud Monitoring à l'aide des signaux de présence générés et des métriques disponibles pour être averti lorsque la réplication ou le signal de présence s'arrêtent.
Utiliser les connecteurs Sink
Les connecteurs de récepteur exportent les données des sujets Kafka vers d'autres systèmes.
Utiliser le connecteur de récepteur BigQuery
Le connecteur de récepteur BigQuery diffuse les données des sujets Kafka vers des tables BigQuery.
Utilisez le connecteur de récepteur BigQuery pour les cas d'utilisation suivants :
L'entreposage de données, pour charger des données de flux continu dans BigQuery à des fins d'analyse et de création de rapports.
Remplir les tables BigQuery qui alimentent les tableaux de bord en temps réel.
Utiliser le connecteur de récepteur Cloud Storage
Le connecteur de récepteur Cloud Storage diffuse les données des sujets Kafka vers des buckets Cloud Storage.
Utilisez le connecteur Cloud Storage Sink pour les cas d'utilisation suivants :
Ingestion de lacs de données, pour stocker les données Kafka dans un lac de données à des fins d'archivage à long terme et de traitement par lot.
Archiver des données pour répondre aux exigences réglementaires.
Utiliser le connecteur de récepteur Pub/Sub
Le connecteur de récepteur Pub/Sub diffuse les messages des sujets Kafka vers un sujet Pub/Sub.
Utilisez le connecteur de récepteur Pub/Sub pour les cas d'utilisation suivants :
Intégration de services permettant d'envoyer des données de Kafka vers d'autres services ou applications qui consomment des données à partir de Pub/Sub. Google Cloud
Déclencher des notifications ou des actions en temps réel en fonction des données traitées.
Utiliser les connecteurs Source
Les connecteurs sources importent des données provenant d'autres systèmes dans des sujets Kafka.
Utiliser le connecteur source Pub/Sub
Le connecteur source Pub/Sub diffuse les messages d'un abonnement Pub/Sub vers un sujet Kafka.
Utilisez le connecteur source Pub/Sub pour les cas d'utilisation suivants :
Ingestion de données en temps réel, importation de données depuis des services cloud ou d'autres applications, et publication dans Pub/Sub dans Kafka pour le traitement des flux.
Architectures basées sur les événements, déclenchant le traitement basé sur Kafka en fonction des événements publiés sur Pub/Sub.
Règle de redémarrage des tâches
Vous pouvez définir la règle de redémarrage des tâches d'un connecteur, qui détermine le comportement en cas d'échec. Les connecteurs sont compatibles avec les règles suivantes :
Ne jamais redémarrer Le connecteur ne relance pas les tâches ayant échoué. Il s'agit du comportement par défaut. Cela est utile pour le débogage ou dans les situations où une intervention manuelle est requise après une erreur.
Redémarrez avec un intervalle exponentiel entre les tentatives. Le connecteur redémarre une tâche ayant échoué après un délai (appelé période de rétrogradation). Le délai augmente de manière exponentielle à chaque nouvel échec. Cette stratégie est recommandée pour la plupart des charges de travail de production.
Si vous utilisez la stratégie d'intervalle exponentiel entre les tentatives, définissez également des valeurs pour l'intervalle minimal et maximal. L'intervalle minimal entre les tentatives doit être supérieur à 60 secondes, et l'intervalle maximal doit être inférieur à 7 200 secondes.
Transformations et prédicats
Kafka Connect est compatible avec les transformations et les prédicats Kafka par défaut.
Vous spécifiez la configuration dans la configuration de votre connecteur. Par exemple, pour configurer un connecteur de récepteur afin d'ignorer les messages contenant une clé d'en-tête DoNotProcess, vous devez ajouter la configuration suivante à votre connecteur :
transforms=dropMessage
transforms.dropMessage.type=org.apache.kafka.connect.transforms.Filter
transforms.dropMessage.predicate=hasKey
predicates=hasKey
predicates.hasKey.type=org.apache.kafka.connect.transforms.predicates.HasHeaderKey
predicates.hasKey.name=DoNotProcess
Cette configuration effectue les opérations suivantes :
Configure un prédicat nommé
hasKeyde typeorg.apache.kafka.connect.transforms.predicates.HasHeaderKey. Ce prédicat correspond à tous les messages contenant un en-tête avec la cléDoNotProcess.Configure une transformation nommée
dropMessagede typeorg.apache.kafka.connect.transforms.Filter. Cette transformation supprime tous les messages qui correspondent au prédicat configuré.Associe la transformation au prédicat
hasKey. Cela permet de s'assurer que seuls les messages contenant la clé d'en-têteDoNotProcesssont supprimés par la transformation.
Pour en savoir plus, consultez la documentation Kafka sur les transformations et les prédicats.
Étape suivante
Créer un connecteur MirrorMaker 2.0
Créez un connecteur de récepteur BigQuery.
Créez un connecteur source Pub/Sub.
Créer un connecteur de récepteur Pub/Sub