我正在尝试使用spark-submit
执行Spark程序(特别是GATK Spark工具,所以命令不是spark-submit
,但类似的东西):这个程序接受一个唯一的输入,所以我我正在尝试编写一些Java代码以接受更多输入。
特别是我试图通过JavaRDD的pipe函数为每个输入执行spark-submit
:
JavaRDD<String> bashExec = ubams.map(ubam -> par1 + "|" + par2)
.pipe("/path/script.sh");
其中par1
和par2
是将传递给 script.sh 的参数,它将处理(按“|”拆分)并使用它们执行某些操作类似于spark-submit
。
现在,我不期望与单个输入的执行相比获得加速,因为我正在调用其他Spark函数,而只是在不同节点上分配更多输入的工作负载并且具有线性执行时间到数字投入。
例如,GATK Spark工具持续大约108分钟,只有一个输入,我的代码我希望有两个相似的输入,它会持续类似于216分钟。
我注意到代码“有效”,或者说我在终端上获得了通常的输出。但至少在15个小时内,任务尚未完成,而且仍在执行中。
所以我问这种方法(用管道函数执行spark-submit
)是愚蠢的还是可能还有其他错误?
我希望能够清楚地解释我的问题。
P.S。我在Azure上使用了一个带有28GB内存和4个执行线程的VM。
答案 0 :(得分:1)
是否可能
是的,这在技术上是可行的。有点谨慎,甚至可以在工作线程中创建一个新的SparkContext
,但
是否明智
没有。你应该从不做这样的事情。 Spark首先禁止嵌套并行化是有充分理由的。任务中发生的任何事情都是黑盒子,因此在DAG计算和资源分配期间无法计算。在最糟糕的情况下,作业将与主作业等待任务完成以及等待主作业释放所需资源的任务一起死锁。
如何解决此问题。问题相当粗略,所以很难给你一个精确的建议,但你可以: