我开始做amp-camp 5 练习。我尝试了以下两种情况：

情景#1

情景#2

两种方案的 Spark shell 应用程序 UI 中显示的总时间不同。
场景 #1 耗时 0.5 秒，而场景 #2 仅耗时 0.2 秒

在场景 #1 中，检查点命令什么都不做，它既不是转换也不是动作。意思是，一旦 RDD 在某个动作之后具体化，就继续保存到磁盘。我在这里错过了什么吗？

问题：

1. 我知道场景 #1 需要更多时间，因为 RDD 是检查点（写入磁盘）。有没有办法从总时间中知道检查点所用的时间？
   Spark shell 应用程序 UI 显示以下内容 - 调度程序延迟、任务反序列化时间、GC 时间、结果序列化时间、获取结果时间。但是，没有显示检查点的故障。

2. 有没有办法访问上述指标，例如调度程序延迟、GC 时间并以编程方式保存它们？我想为 RDD 上调用的每个操作记录上述一些指标。

3. 如何以编程方式访问以下信息：

   • RDD 的大小，当在检查点上持久化到磁盘时？
   • 目前内存中有多少百分比的 RDD？
   • 计算 RDD 所需的总时间？

如果您需要更多信息，请告诉我。

伙计们，

当尝试从提供了验证框架的检查点模型恢复 R 中的 h2o 深度学习时，我遇到了一些问题。它说“验证数据集必须与检查点模型相同”，我相信我确实有相同的验证数据集。如果我将validation_frame 留空，则检查点模型可以正常工作。我在下面附上我的代码：

然后我关闭了 h2o，退出 R 并在 R 中重新启动 h2o 以恢复训练，其中 h2o 错误：

晚上好，

我想问一个我不确定可以做到的问题。我有一个用 Simple HTML DOM 制作的抓取程序。

该程序从各种网站中提取数据。

所以我的问题是：

如果程序失败，是否可以使程序自动化以自动重启？

而我更进一步......

我将从特定点重新启动程序，例如：

如果程序无法处理 2，我想从检查点重新开始工作。

如果不可能，请告诉我并删除问题。没问题。

非常感谢。

计算科学中的典型情况是有一个连续运行几天/几周/几个月的程序。由于硬件/操作系统故障是不可避免的，因此通常使用检查点，即不时保存程序的状态。如果发生故障，则从最新的检查点重新启动。

实现检查点的pythonic方法是什么？

例如，可以直接转储函数的变量。

或者，我正在考虑将此类函数转换为一个类（见下文）。函数的参数将成为构造函数的参数。构成算法状态的中间数据将成为类属性。pickle模块将有助于（反）序列化。

我正在从这个版本的源代码构建 docker：
https ://github.com/boucher/docker/tree/cr-combined

克隆代码后：

光盘码头工人

然后将生成的文件@./bundles/../docker 复制到 usr/bin 目录后重新打开终端并再次启动 docker 引擎。它表明我使用的是我自己构建的版本，但是这个版本应该有两个主要的 docker 命令，这些命令不会出现在我构建的一个 1-检查点 2-恢复中

你能帮我告诉我哪里出错了吗

我正在尝试运行 h2o.deeplearning 两次，在 2 个火车组上使用检查点参数（使用相同的参数，除了不同的时期）。我收到以下错误：

错误：'训练数据的列必须与检查点模型的列相同

即使两个集合都有相同的列。下面附上相关代码：

谢谢，伊莱。

In Spark Streaming it is possible (and mandatory if you're going to use stateful operations) to set the StreamingContext to perform checkpoints into a reliable data storage (S3, HDFS, ...) of (AND):

• Metadata
• DStream lineage

As described here, to set the output data storage you need to call yourSparkStreamingCtx.checkpoint(datastoreURL)

On the other hand, it is possible to set lineage checkpoint intervals for each DataStream by just calling checkpoint(timeInterval) at them. In fact, it is recommended to set lineage checkpoint interval between 5 and 10 times the DataStream's sliding interval:

dstream.checkpoint(checkpointInterval). Typically, a checkpoint interval of 5 - 10 sliding intervals of a DStream is a good setting to try.

My question is:

When the streaming context has been set to perform checkpointing and no ds.checkpoint(interval) is called, is lineage checkpointing enabled for all data streams with a default checkpointInterval equal to batchInterval? Or is, on the contrary, only metadata checkpointing what is enabled?

文档说任何与 Hadoop API 兼容的文件系统（如 HDFS 、 S3 ）都可以用作检查点目录。

我的问题是，除了 HDFS 和 S3 之外，使用 Kafka 和 Cassandra 的 spark 流应用程序还有哪些实用的替代方案。

谢谢

描述

我们在 Scala 中有一个 Spark Streaming 1.5.2 应用程序，它从 Kinesis Stream 读取 JSON 事件，进行一些转换/聚合并将结果写入不同的 S3 前缀。当前批处理间隔为 60 秒。我们每秒有 3000-7000 个事件。我们使用检查点来保护我们免于丢失聚合。

它已经运行了一段时间，从异常甚至集群重启中恢复。我们最近重新编译了 Spark Streaming 1.6.0 的代码，只更改了build.sbt文件中的库依赖项。在 Spark 1.6.0 集群中运行代码几个小时后，我们注意到以下内容：

1. “输入速率”和“处理时间”波动性在 1.6.0 中大幅增加（见下面的截图）。
2. 每隔几个小时，在写入记录时会抛出一个“异常：BlockAdditionEvent ... 到 WriteAheadLog。java.util.concurrent.TimeoutException: Futures timeouts after [5000 milliseconds]” 异常（参见下面的完整堆栈跟踪）与特定批次（分钟）下降到 0 个事件/秒一致。

在做了一些挖掘之后，我认为第二个问题看起来与这个Pull Request有关。PR 的最初目标：“当使用 S3 作为 WAL 的目录时，写入时间太长。当多个接收器向 ReceiverTracker 发送 AddBlock 事件时，驱动程序很容易出现瓶颈。此 PR 在 ReceivedBlockTracker 中添加事件批处理，以便接收者不会被驱动程序阻塞太久。”</p>

我们在 Spark 1.5.2 的 S3 中进行检查点，没有性能/可靠性问题。我们已经在 S3 和本地 NAS 中测试了 Spark 1.6.0 中的检查点，在这两种情况下我们都收到了这个异常。看起来当检查点一个批次的时间超过 5 秒时，就会出现这个异常，我们已经检查过该批次的事件是否永远丢失。

问题

• Spark Streaming 1.6.0 中的“输入速率”和“处理时间”波动是否会增加？是否有任何已知的改进方法？

• 除了这两个之外，您知道任何解决方法吗？：

  1) 保证 checkpointing sink 写入所有文件的时间少于 5 秒。根据我的经验，你不能保证使用 S3，即使是小批量。对于本地 NAS，这取决于谁负责基础设施（云提供商很难）。

  2) 增加 spark.streaming.driver.writeAheadLog.batchingTimeout 属性值。

• 您是否期望在所描述的场景中丢失任何事件？我认为如果批量检查点失败，则不会增加分片/接收器序列号，并且会在稍后重试。

Spark 1.5.2 统计 - 截图

Spark 1.6.0 统计 - 截图

全栈跟踪

源代码提取

我正在从 HDFS 检查点（例如，ConstantInputDSTream）恢复一个流，但我不断得到SparkException: <X> has not been initialized.

从检查点恢复时我需要做一些具体的事情吗？

我可以看到它想要DStream.zeroTime设置，但是当流恢复时zeroTime是null. 由于它是私有成员 IDK，它可能无法恢复。我可以看到StreamingContext恢复的流所引用的确实具有zeroTime.

initialize是一个私有方法并且被调用StreamingContext.graph.start而不是被调用StreamingContext.graph.restart，大概是因为它期望zeroTime被持久化。

有人有一个从检查点恢复并具有非空值的 Stream 示例zeroTime吗？