我正在使用隔离模式的zeppelins spark解释器,使用此模式,它将为spark集群中的每个笔记本启动一项新工作。笔记本执行完成后,我想通过zeppelin终止这项工作。为此我做了sc.stop
这停止了sparkContext,并且作业也从spark集群中停止。但是下次当我尝试运行笔记本时,它不会再次启动sparkContext
。那怎么办?
答案 0 :(得分:17)
答案 1 :(得分:1)
我调查了为什么sc停止在纱线客户端火花的问题。我发现这是火花本身的问题(Spark版本> = 1.6)。在spark客户端模式下,AM通过RPC连接连接到Driver,有两个连接。它设置NettyRpcEndPointRef连接到服务器'SparkDriver'的驱动程序'YarnSchedulerBackEnd',另一个连接是EndPoint'YarnAM'。
在AM和Driver之间的这些RPC连接中,没有心跳。因此,AM知道驱动程序是否连接的唯一方法是EndPoint'YarnAM'中的OnDisconnected方法。虽然NettyRpcEndPointRef驱动程序和AM连接的断开消息将通过RPCHandler“postToAll”到EndPoint'YarnAM'。当它们之间的TCP连接断开或者保持活动消息时发现tcp没有活着(可能在Linux系统中2小时),它会标记应用程序SUCCESS。
因此,当Driver Monitor Process发现纱线应用程序状态更改为SUCCESS时,它将停止sc。
因此,根本原因是,在Spark客户端中,没有重试连接到驱动程序以检查驱动程序是否存在,而只是尽可能快地标记纱线应用程序。也许Spark可以修改此问题。 / p>
答案 2 :(得分:1)
与Zeppelin和Spark合作时,我也偶然发现了相同的问题,并进行了一些调查。一段时间后,我的第一个结论是:
sc.stop()
来终止SparkContext restart
按钮)重新启动SparkContext 但是,由于UI允许通过按下按钮来重新启动Spark Interpreter,所以为什么不对restart
按钮的API调用进行反向工程!结果是,restarting
Spark解释器发送了以下HTTP请求:
PUT http://localhost:8080/api/interpreter/setting/restart/spark
幸运的是,齐柏林飞艇可以与多个口译员合作,其中之一也是shell
口译员。因此,我创建了两个段落:
第一段用于在需要时停止SparkContext:
%spark
// stop SparkContext
sc.stop()
第二段用于以编程方式重新启动SparkContext:
%sh
# restart SparkContext
curl -X PUT http://localhost:8080/api/interpreter/setting/restart/spark
在用两段停止并重新启动SparkContext之后,我运行另一段来检查重新启动是否有效...并且有效!因此,虽然这不是官方的解决方案,而更多的是解决方法,但它仍然是合法的,因为我们除了“按下”段落中的restart
按钮外,什么也不做!
Zeppelin版本:0.8.1
答案 3 :(得分:0)
您可以通过单击有问题的解释器左侧的重新启动图标(在本例中为火花解释器),在解释器绑定(右上角的齿轮)中重新启动笔记本的解释器>