-`kafka_group_name`– A group of Kafka consumers. Reading margins are tracked for each group separately. If you don’t want messages to be duplicated in the cluster, use the same group name everywhere.
-`kafka_format`– Message format. Uses the same notation as the SQL `FORMAT` la fonction, tels que `JSONEachRow`. Pour plus d’informations, voir le [Format](../../../interfaces/formats.md) section.
-`kafka_schema`– Parameter that must be used if the format requires a schema definition. For example, [Cap’n Proto](https://capnproto.org/) nécessite le chemin d’accès du fichier de schéma et le nom de la racine `schema.capnp:Message` objet.
-`kafka_num_consumers`– The number of consumers per table. Default: `1`. Spécifiez plus de consommateurs si le débit d’un consommateur est insuffisant. Le nombre total de consommateurs ne doit pas dépasser le nombre de partitions dans la rubrique, car un seul consommateur peut être affecté par partition.
-`kafka_skip_broken_messages`– Kafka message parser tolerance to schema-incompatible messages per block. Default: `0`. Si `kafka_skip_broken_messages = N` puis le moteur saute *N* Messages Kafka qui ne peuvent pas être analysés (un message est égal à une ligne de données).
Les messages livrés sont suivis automatiquement, de sorte que chaque message d’un groupe n’est compté qu’une seule fois. Si vous souhaitez obtenir les données deux fois, créez une copie de la table avec un autre nom de groupe.
Les groupes sont flexibles et synchronisés sur le cluster. Par exemple, si vous avez 10 thèmes et 5 copies d’une table dans un cluster, chaque copie obtient 2 sujets. Si le nombre de copies change, les rubriques sont redistribuées automatiquement entre les copies. En savoir plus à ce sujet à http://kafka.apache.org/intro.
`SELECT` n’est pas particulièrement utile pour la lecture de messages (sauf pour le débogage), car chaque message ne peut être lu qu’une seule fois. Il est plus pratique de créer des threads en temps réel à l’aide de vues matérialisées. Pour ce faire:
Lorsque l’`MATERIALIZED VIEW` rejoint le moteur, il commence à collecter des données en arrière-plan. Cela vous permet de recevoir continuellement des messages de Kafka et de les convertir au format requis en utilisant `SELECT`.
Une table kafka peut avoir autant de vues matérialisées que vous le souhaitez, elles ne lisent pas directement les données de la table kafka, mais reçoivent de nouveaux enregistrements( en blocs), de cette façon vous pouvez écrire sur plusieurs tables avec différents niveaux de détail (avec regroupement - agrégation et sans).
Pour améliorer les performances, les messages reçus sont regroupées en blocs de la taille de [max\_insert\_block\_size](../../../operations/server-configuration-parameters/settings.md#settings-max_insert_block_size). Si le bloc n’a pas été formé à l’intérieur [stream\_flush\_interval\_ms](../../../operations/server-configuration-parameters/settings.md) millisecondes, les données seront vidées dans le tableau, indépendamment de l’intégralité du bloc.
Si vous souhaitez modifier la table cible en utilisant `ALTER`, nous vous recommandons de désactiver la vue matériel pour éviter les divergences entre la table cible et les données de la vue.
Similaire à GraphiteMergeTree, le moteur Kafka prend en charge la configuration étendue à l’aide du fichier de configuration ClickHouse. Il y a deux clés de configuration que vous pouvez utiliser: global (`kafka`) et des rubriques (`kafka_*`). La configuration globale est appliquée en premier, puis la configuration au niveau de la rubrique est appliquée (si elle existe).
Pour obtenir une liste des options de configuration possibles, consultez [librdkafka référence de configuration](https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md). Utilisez le trait de soulignement (`_`) au lieu d’un point dans la configuration ClickHouse. Exemple, `check.crcs=true` sera `<check_crcs>true</check_crcs>`.