Запустите внешнюю программу зажигания внутри программы scala.

Question

У меня есть огромная итеративная программа, которая имеет тенденцию расходиться во времени. Итерации занимают все больше и больше времени. Поэтому я думаю, что разложение проблемы в подпрограммах, которые будут работать независимо друг от друга, позволит spark и JVM лучше распределять память.

Первый вопрос : как вы думаете, действительно ли можно достичь некоторой производительности при использовании предложенного метода?

Второй вопрос : как?

Я попытался запустить команду spark-submit внутри scala программы, например:

import sys.process._
"cmd /C spark-submit --master local --class org.HelloWorld \\path\\helloworld.jar".!!

, которая отлично работает на Windows, но, очевидно, не в Linux. Я попытался адаптировать его для Unix системы, как это, но она не работает:

Seq("bash", "-c", "spark-submit --master local --class org.HelloWorld \\path\\helloworld.jar")!!

Выдает:

bash: spark-submit : command not found
Exception in thread "main" java.lang.RuntimeException: Nonzero exit value: 127
    at scala.sys.package$.error(package.scala:27)
    at scala.sys.process.ProcessBuilderImpl$AbstractBuilder.slurp(ProcessBuilderImpl.scala:132)
    at scala.sys.process.ProcessBuilderImpl$AbstractBuilder.$bang$bang(ProcessBuilderImpl.scala:102)

Хотя я могу успешно запустить его вручную на bash терминал .

Я также обнаружил, что он существует org.apache.spark.launcher.SparkLauncher. Но всякий раз, когда я пытаюсь создать такой объект: val spark = new SparkLauncher(), я получаю java.lang.ClassNotFoundException: org.apache.spark.launcher.SparkLauncher

У вас есть какие-либо решения или предложения? Спасибо.

Answer 1

Если вы можете запустить bash вручную от имени пользователя spark, вы, вероятно, сможете запустить интерпретатор bash из кода. Таким образом, вы можете создать файл bash с помощью приложения Spark, сохранить его и запустить bash, используя sys.process API. Однако вы также можете попытаться использовать полный путь к исполняемому файлу spark-submit, поскольку sys.process не знает, где на самом деле находится ваш исполняемый файл.