Aller au contenu principal

Limitations 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 répertorie les limitations et les considérations relatives à l'ingestion de données depuis Apache Kafka à l'aide de Databricks Lakeflow Connect.

Données prises en charge

Le connecteur Kafka ingère des données d'un ou de plusieurs sujets Kafka. Vous spécifiez les sujets à ingérer à l'aide de l'option de connecteur topics ou topic_pattern. Tout sujet accessible via la connexion Kafka peut être ingéré.

Limitations spécifiques au connecteur

  • Colonnes de métadonnées non disponibles : Seules les colonnes clé et valeur sont écrites dans la table de destination. Les colonnes de métadonnées Kafka — y compris topic, partition, offset, timestamp, timestampType et headers — ne sont pas disponibles dans la table de destination en version Bêta.
  • Tables en ajout uniquement : Les tables de destination sont en ajout uniquement. Les upserts et les suppressions ne sont pas pris en charge.
  • **Un cluster par pipeline** : chaque pipeline utilise une connexion Unity Catalog unique (un cluster Kafka). Pour ingérer à partir de plusieurs clusters Kafka, créez des pipelines distincts.
  • Compute Serverless uniquement : Le connecteur Kafka géré s'exécute exclusivement sur un compute serverless. Les pipelines de compute classiques ne sont pas pris en charge.
  • Pas de création de pipeline basée sur l’interface utilisateur : la création de pipeline via l’interface utilisateur Databricks n’est pas prise en charge en version Beta. Utilisez les Declarative Automation Bundles ou un Notebook Databricks.
  • Aucune sélection ni désélection de colonne : la sélection ou la désélection de colonnes spécifiques n'est pas prise en charge en version Beta.
  • Aucun filtrage de ligne : le filtrage au niveau des lignes n'est pas pris en charge.
  • Pas de SCD de type 2 : Étant donné que les tables de destination sont uniquement en ajout, le suivi de l'historique SCD de type 2 n'est pas pris en charge.
  • Pas d'évolution des schémas pour les colonnes renommées : les renommages de colonnes ne sont pas suivis. Une colonne renommée dans la source est traitée comme une nouvelle colonne dans la destination.
  • Pas d'orchestration via Databricks Workflows : Le pipeline fonctionne en continu. La planification basée sur les Workflows n'est pas prise en charge.

Limitations du fanout

info

Aperçu

Cette fonctionnalité est en préversion privée. Pour l'essayer, veuillez contacter votre interlocuteur Databricks.

Les limitations suivantes s'appliquent lorsque vous acheminez des enregistrements vers plusieurs tables à l'aide du fanout. Consultez Acheminer des enregistrements vers plusieurs tables (fanout) pour configurer le fanout.

  • Configurez fanout_options sur un objet de schéma, et non sur un objet de table. Ne définissez pas source_catalog ou source_schema sur l'objet de schéma fanout.
  • Chaque enregistrement est acheminé vers une seule table de destination, déterminée par sa valeur fanout_by. La diffusion d'un seul enregistrement vers plusieurs tables n'est pas prise en charge.
  • Le fanout nécessite un pipeline continu (continuous: true). Les pipelines Déclenchés (à exécution unique) ne sont pas pris en charge.
  • Vous pouvez appliquer au maximum une transformation à chaque route, et elle doit utiliser format: JSON. Les transformations AVRO et PROTOBUF ne sont pas prises en charge pour la diffusion.
  • L'expression fanout_by doit se résoudre en STRING, référencer au moins une colonne d'entrée et être déterministe. Les fonctions définies par l'utilisateur (UDF) ne sont pas prises en charge. La clé de routage ne doit pas être nulle.
  • La valeur résolue fanout_by est utilisée telle quelle comme segment de nom de table de destination, sans guillemets ni désinfection, elle doit donc être un identifiant de table non entre guillemets valide. Les valeurs contenant des espaces, des points ou d'autres caractères non valides dans un identifiant non entre guillemets échouent à l'écriture, tout comme une valeur entièrement numérique (par exemple, 123). Un chiffre initial est autorisé lorsque la valeur contient également une lettre ou un trait de soulignement, tel que 2024_events.
  • fanout_by est évaluée par rapport à l'enregistrement source brut (avec les colonnes Kafka key et value). La colonne value est binaire, veuillez donc la convertir en chaîne de caractères avant d'extraire un champ (par exemple, cast(value as string):event_type::string). Une transformation fanout_options s'exécute après le routage ; elle ne peut donc pas produire une colonne à laquelle fanout_by fait référence.