Kafka Streaming simultané?
J'ai quelques éléments de base Kafka Streaming qui lit les enregistrements d'un sujet, effectue un traitement et génère des enregistrements vers un autre sujet.
Comment Kafka streaming gère-t-il la concurrence? Tout est-il exécuté dans un seul thread? Je ne vois pas cela mentionné dans la documentation.
S'il s'agit d'un seul thread, j'aimerais que les options de traitement multi-thread pour gérer des volumes de données élevés.
Si elle est multi-thread, j'ai besoin de comprendre comment cela fonctionne et comment gérer les ressources, comme les connexions de base de données SQL doivent être partagées dans différents threads de traitement.
L'API de streaming intégrée de Kafka n'est-elle pas recommandée pour les scénarios à volume élevé par rapport à d'autres options (Spark, Akka, Samza, Storm, etc.)?
Comment Kafka streaming gère-t-il la concurrence? Tout est-il exécuté dans un seul thread? Je ne vois pas cela mentionné dans la documentation.
Ceci est documenté en détail sur http://docs.confluent.io/current/streams/architecture.html#parallelism-model . Je ne veux pas copier-coller ceci textuellement, mais je veux souligner que à mon humble avis l'élément clé à comprendre est celui des partitions (cf. Les partitions de sujet de Kafka, qui dans Kafka Streams est généralisé en "partitions de flux" car tous les flux de données en cours de traitement ne passeront pas par Kafka) car une partition est actuellement ce qui détermine le parallélisme des deux Kafka (côté courtier/serveur) et des applications de traitement de flux qui utilisent le Kafka API Streams (côté client).
S'il s'agit d'un seul thread, j'aimerais que les options de traitement multi-thread pour gérer des volumes de données élevés.
Le traitement d'une partition sera toujours effectué par un seul "thread" uniquement, ce qui garantit que vous ne rencontrez pas de problèmes de concurrence. Mais...
Si elle est multi-thread, j'ai besoin de comprendre comment cela fonctionne et comment gérer les ressources, comme les connexions de base de données SQL doivent être partagées dans différents threads de traitement.
... car Kafka permet à un sujet d'avoir plusieurs partitions, vous obtenez un traitement parallèle. Par exemple, si un sujet a 100 partitions, alors jusqu'à 100 tâches de flux (ou, quelque peu simplifiées à l'excès) : jusqu'à 100 machines différentes exécutant chacune une instance de votre application) peuvent traiter ce sujet en parallèle. Encore une fois, chaque tâche de flux obtiendrait un accès exclusif à 1 partition, qu'elle traiterait ensuite.
L'API de streaming intégrée de Kafka n'est-elle pas recommandée pour les scénarios à volume élevé par rapport à d'autres options (Spark, Akka, Samza, Storm, etc.)?
Le moteur de traitement de flux de Kafka est certainement recommandé et également utilisé dans la pratique pour les scénarios à volume élevé. Le travail sur le benchmarking comparatif est toujours en cours, mais dans de nombreux cas, une application basée sur Kafka Streams s'avère plus rapide. Voir Blog de l'ingénieur LINE: Application Kafka Streams pour la distribution interne des messages pour un article de LINE Corp, l'une des plus grandes plateformes sociales d'Asie (220 millions d'utilisateurs et plus), où ils décrivent comment ils utilisent Kafka et l'API Kafka Streams en production pour traiter des millions d'événements par seconde.
La configuration de kstreams num.stream.threads vous permet de remplacer le nombre de threads à partir de 1. Cependant, il peut être préférable d'exécuter simplement plusieurs instances de votre application de streaming, toutes exécutant le même consommateur groupe. De cette façon, vous pouvez faire tourner autant d'instances que nécessaire pour obtenir un partitionnement optimal.