Schreiben Sie eine Spark Steaming-Anwendung in Java oder Scala und senden Sie sie an einen YARN-Cluster. Wenn zu diesem Zeitpunkt die bereits ausgeführte Spark-Streaming-Anwendung und FQCN mit einer neuen Version derselben Klasse in der übermittelten JAR-Datei enthalten sind, treten Probleme auf.
Im Fall von Spark Streaming werden die Prozesse, aus denen die DAG besteht, als Lambda-Objekte serialisiert, an den Knoten übertragen, auf dem der Executor-Prozess über das Netzwerk ausgeführt wird, und ausgeführt. Der Executor-Prozess desrialisiert das serialisierte Lambda-Objekt und versucht, es im Speicher wiederherzustellen. Die Version der Klasse des dort zu deserialisierenden Objekts widerspricht jedoch der Version der Klasse, die in den Speicher des Executor-Prozesses geladen wurde. Manchmal. Da die Version unterschiedlich ist, tritt eine InvalidClassException auf, die besagt, dass eine Deserialisierung nicht möglich ist.
Es wäre möglich, nur zu entwickeln, um die InvalidClassException zu vermeiden, aber wir möchten, dass neue Anwendungen die neue Version der Klasse verwenden, damit die speichergeladene Klasse nicht verwendet wird.
Aus diesem Grund verfolge ich die von jeder Anwendung verwendeten Klassen und stoppe im laufenden Fall die laufende Anwendung im Voraus und aktualisiere sie.
Aber ... das ist in Ordnung, wenn es in der Klasse ist, die Sie selbst entwickelt haben, aber es ist zu ärgerlich, wenn es in einer Klasse passiert, die in Abhängigkeit ist.
Besonders wenn der YARN-Cluster von vielen Benutzern gemeinsam genutzt wird ...