Zeppelin：如何在 zeppelin 中重新启动 sparkContext

Posted 2023-03-23

【中文标题】Zeppelin：如何在 zeppelin 中重新启动 sparkContext

【英文标题】：Zeppelin: How to restart sparkContext in zeppelin

【发布时间】：2017-03-25 19:17:44

【问题描述】：

我正在使用 zeppelins spark 解释器的隔离模式，在这种模式下，它将为 spark 集群中的每个笔记本启动一个新工作。笔记本执行完成后，我想通过 zeppelin 终止工作。为此，我做了sc.stop 这停止了 sparkContext 并且作业也从 spark 集群停止。但是下次当我尝试运行笔记本时，它不会再次启动sparkContext。那么该怎么做呢？

【参考方案1】：

这有点反直觉，但您需要访问解释器菜单选项卡而不是直接停止 SparkContext：

转到解释器列表。

找到Spark解释器，点击右上角的restart：

【讨论】：

除了手动重启解释器就没有别的办法了吗？

当在EMR 上使用Zeppelin 为Spark 并从S3 加载外部fat-jar 时，我发现重新启动解释器一次是不够的。假设我从S3 加载了 fat-jar，它已经升级了。为了确保在interpreter 中加载new jar，我这样做：（1）​​编辑解释器dependencies 并删除现有的jar，保存更改（2）重新启动解释器（3）再次编辑 interpreter dependencies 并添加新的 jar（它可能具有与以前相同的路径） (4) 再次重新启动解释器

【参考方案2】：

您可以通过单击相关解释器左侧的重新启动图标（在本例中为 spark 解释器），在解释器绑定（右上角的齿轮）中重新启动笔记本的解释器。

【参考方案3】：

在使用 Zeppelin 和 Spark 时，我也偶然发现了同样的问题并进行了一些调查。一段时间后，我的第一个结论是：

停止 SparkContext 可以通过在段落中使用 sc.stop() 来完成 重启 SparkContext 只能使用 UI（菜单 -> 解释器 -> Spark 解释器 -> 点击restart 按钮）

但是，既然 UI 允许通过按下按钮重新启动 Spark 解释器，为什么不直接对 restart 按钮的 API 调用进行逆向工程！结果是，restarting Spark 解释器发送了以下 HTTP 请求：

PUT http://localhost:8080/api/interpreter/setting/restart/spark

幸运的是，Zeppelin 能够与多个口译员一起工作，其中一位也是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

【讨论】：

这对我在 EMR 上不起作用。通过 shell 解释器运行 curl 命令时，出现以下错误：curl: (7) Failed to connect to localhost port 8080: Connection refused

【参考方案4】：

我正在调查为什么 sc 在 yarn-client 中停止 spark 的问题。我发现这是火花本身的问题（火花版本> = 1.6）。在spark客户端模式下，AM通过RPC连接到Driver，有两个连接。它设置 NettyRpcEndPointRef 连接到服务器 'SparkDriver' 的驱动程序服务 'YarnSchedulerBackEnd'，另一个连接是 EndPoint 'YarnAM'。

在 AM 和 Driver 之间的这些 RPC 连接中，没有心跳。因此，AM 知道驱动程序是否连接的唯一方法是 EndPoint 'YarnAM' 中的 OnDisconnected 方法。通过 NettyRpcEndPointRef 的驱动程序和 AM 连接的断开消息将通过 RPCHandler 将“postToAll”发送到端点“YarnAM”。当它们之间的 TCP 连接断开，或者 keep alive 消息发现 tcp 不活动时（在 Linux 系统中可能需要 2 小时），它会标记应用程序成功。

所以当Driver Monitor Process发现yarn应用状态变为SUCCESS时，就会停止sc。

所以根本原因是，在Spark客户端中，没有重试连接到驱动程序来检查驱动程序是否处于活动状态，而是尽快标记yarn应用程序。也许Spark可以修改这个问题。