web-dev-qa-db-fra.com

Spark: traitement de plusieurs kafka rubrique en parallèle

J'utilise spark 1.5.2. Je dois exécuter spark job de streaming avec kafka comme source de streaming. J'ai besoin de lire à partir de plusieurs sujets dans kafka et traiter chaque sujet différemment.

  1. Est-ce une bonne idée de faire cela dans le même travail? Si oui, dois-je créer un seul flux avec plusieurs partitions ou un flux différent pour chaque sujet?
  2. J'utilise kafka Steam direct. Pour autant que je sache, spark lance des récepteurs de longue durée pour chaque partition. J'ai un cluster relativement petit, 6 nœuds avec 4 cœurs chacun. Si j'ai beaucoup de sujets et de partitions dans chaque sujet, l'efficacité serait-elle affectée car la plupart des exécuteurs sont occupés par des récepteurs de longue durée? Veuillez me corriger si ma compréhension est fausse ici
20
nish

J'ai fait les observations suivantes, au cas où cela serait utile pour quelqu'un:

  1. Dans kafka flux direct, les récepteurs ne sont pas exécutés en tant que tâches de longue durée. Au début de chaque inerval de lot, les données sont d'abord lues à partir de kafka dans les exécuteurs) Une fois lue, la partie traitement prend le relais.
  2. Si nous créons un seul flux avec plusieurs sujets, les sujets sont lus les uns après les autres. De plus, le filtrage du flux de données pour appliquer une logique de traitement différente ajouterait une autre étape au travail
  3. La création de plusieurs flux aiderait de deux manières: 1. Vous n'avez pas besoin d'appliquer l'opération de filtrage pour traiter différents sujets différemment. 2. Vous pouvez lire plusieurs flux en parallèle (par opposition à un par un en cas de flux unique). Pour ce faire, il existe un paramètre de configuration non documenté spark.streaming.concurrentJobs*. J'ai donc décidé de créer plusieurs flux.

    sparkConf.set("spark.streaming.concurrentJobs", "4");
    
19
nish

Je pense que la bonne solution dépend de votre cas d'utilisation.

Si votre logique de traitement est la même pour les données de tous les sujets, alors sans aucun doute, c'est une meilleure approche.

Si la logique de traitement est différente, je suppose que vous obtenez un seul RDD de tous les sujets et vous devez créer un pairedrdd pour chaque logique de traitement et le gérer séparément. Le problème est que cela crée une sorte de regroupement au traitement et la vitesse de traitement globale sera déterminée par le sujet qui a besoin du plus de temps pour être traité. Les sujets contenant moins de données doivent donc attendre que les données de tous les sujets soient traitées. Un avantage est que si ce sont des données de série temporelle, le traitement se poursuit ensemble, ce qui pourrait être une bonne chose.

Un autre avantage de l'exécution de travaux indépendants est que vous obtenez un meilleur contrôle et pouvez ajuster votre partage de ressources. Par exemple: les tâches qui traitent un sujet à haut débit peuvent se voir allouer un CPU/mémoire plus élevé.

6
Atul Soman