Aller au contenu principal
Dernière mise à jour le

FAQ du connecteur Kafka

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.

Cette page contient des réponses aux questions fréquemment posées concernant le connecteur d'ingestion Kafka géré dans Databricks Lakeflow Connect.

FAQ générale sur les connecteurs gérés​

Consultez la FAQ sur les connecteurs gérés pour obtenir les questions fréquemment posées qui s'appliquent à tous les connecteurs gérés Lakeflow Connect. Les éléments suivants sont spécifiques au connecteur Kafka.

FAQ spécifiques au connecteur​

Pourquoi est-ce que je reçois un TimeoutException lors de la connexion à Kafka ?​

Parmi les causes courantes, citons :

  • Connectivité réseau : le compute Serverless ne peut pas atteindre les brokers Kafka. Vérifiez les règles de pare-feu, les groupes de sécurité et les configurations de Virtual Private Cloud (VPC).
  • **Serveurs d'amorçage incorrects** : Vérifiez que le hostname et le port du serveur d'amorçage dans votre connexion sont corrects.
  • Résolution DNS : assurez-vous que les hostnames du broker Kafka peuvent être résolus depuis le réseau Databricks.
  • Problèmes SSL/TLS : si vous utilisez SSL, vérifiez que les certificats sont correctement configurés.

Pour les configurations de Private Link ou d'appairage Virtual Private Cloud (VPC), assurez-vous que les bonnes routes réseau sont en place. Consultez Authentification pour plus de détails sur la configuration de l'authentification.

Est-il possible de lire à partir de plusieurs sujets Kafka dans un seul pipeline ?​

Oui. Vous pouvez vous abonner à plusieurs rubriques dans la même définition de table de pipeline en utilisant l'une des méthodes suivantes :

  • topics : Fournissez une liste de noms de sujet, par exemple topics: [topic1, topic2].
  • topic_pattern : Utilisez une expression régulière Java pour faire correspondre les noms de sujets, par exemple topic_pattern: "topic-.*". topic_pattern est mutuellement exclusif avec topics.

Les deux champs sont définis sous connector_options.kafka_options. Consultez la référence du connecteur Kafka pour la référence complète des options.

Pourquoi mon Stream ne retourne aucun enregistrement même si des données existent dans le sujet ?​

Parmi les causes courantes, citons :

  • Paramètre starting_offset incorrect : la valeur default est latest, qui ne lit que les nouvelles données arrivant après le start du Stream. Définissez starting_offset sur earliest pour lire les données existantes.
  • Nom de sujet incorrect : vérifiez que vous vous abonnez au bon sujet. Les noms de sujets Kafka sont sensibles à la casse.
  • Problèmes d'authentification : votre Stream peut s'être connecté avec succès, mais ne dispose pas de l'autorisation de lire le sujet. Vérifiez vos ACL Kafka.

Comment acheminer les enregistrements d'un sujet vers plusieurs tables ?​

Utilisez la distribution (en Private Preview). Fanout achemine chaque enregistrement d'une source Kafka unique vers l'une des nombreuses tables de destination, en fonction d'une clé de routage par enregistrement. Vous le configurez avec fanout_options sur un objet de schéma. Fanout nomme chaque table de destination {destination_catalog}.{destination_schema}.{key_value}, où la valeur de la clé provient de l'expression SQL fanout_by. Étant donné que cette valeur est insérée dans le nom de la table tel quel, sans guillemets ni nettoyage, il doit s'agir d'un identificateur de table non cité valide. Les valeurs contenant des espaces, des points ou d'autres caractères qui ne sont pas valides dans un identifiant sans guillemets échouent l'écriture. Voir Acheminer les enregistrements vers plusieurs tables (fanout).

Quels formats de message sont pris en charge pour le fanout ?​

Seul JSON est actuellement pris en charge. Consulter les limites de fanout.

Comment puis-je surveiller le décalage entre mon stream et les derniers offsets Kafka ?​

Consultez Afficher les métriques de streaming. L'interface utilisateur des métriques de streaming affiche le décalage d'offset par partition, ce qui indique le retard du pipeline par rapport aux derniers offsets disponibles dans la rubrique.

Que se passe-t-il si des enregistrements sont supprimés de Kafka avant que le pipeline ne les lise ?​

Si le pipeline prend du retard et que Kafka supprime des enregistrements avant leur lecture (en raison des paramètres de rétention de la rubrique), le pipeline ignore automatiquement les décalages manquants et continue à partir du prochain décalage disponible.

Ce comportement est intentionnel. L'arrêt du pipeline sur une lacune de rétention entraînerait un retard supplémentaire du pipeline en attendant une intervention, augmentant la quantité totale de données manquées. En continuant au-delà de la lacune, le pipeline reprend la lecture de nouveaux enregistrements aussi rapidement que possible.

Si votre cas d'utilisation exige de garantir que chaque enregistrement est traité, assurez-vous que la période de rétention de votre sujet Kafka est suffisamment longue pour tenir compte de toute interruption ou latence prévue du pipeline.

Sur cette page