Écrivez une application Spark Steaming en Java ou Scala et soumettez-la à Spark pour l'exécuter sur un cluster YARN. À ce stade, si l'application Spark Streaming qui est déjà en cours d'exécution et FQCN sont inclus dans le fichier JAR soumis avec une nouvelle version de la même classe, vous aurez des problèmes.
Dans le cas de Spark Streaming, les processus qui composent le DAG sont sérialisés en tant qu'objets Lambda, transférés vers le nœud sur lequel le processus exécuteur s'exécute sur le réseau et exécutés. Le processus exécuteur désérialise l'objet Lambda sérialisé et tente de le restaurer en mémoire, mais il existe un conflit entre la version de classe de l'objet à désérialiser et la version de la classe chargée dans la mémoire du processus exécuteur. Quelquefois. Étant donné que la version est différente, InvalidClassException se produit en disant que la désérialisation n'est pas possible.
Il serait possible de concevoir juste pour éviter l'exception InvalidClassException, mais nous voulons que les nouvelles applications utilisent la nouvelle version de la classe, donc nous ne voulons pas que la classe chargée en mémoire soit utilisée.
C'est pourquoi je garde une trace des classes utilisées par chaque application, et en cas de conflit, j'arrête l'application en cours à l'avance et je la mets à niveau.
Mais ... c'est bien si c'est dans la classe que vous avez développée vous-même, mais c'est trop ennuyeux si cela se produit dans une classe qui est dans une dépendance.
Surtout si le cluster YARN est partagé par de nombreux utilisateurs ...