Kinesis spark 流接收器的检查点如何工作

Question

我们使用连接到 AWS Kinesis 流的 Spark Streaming 来聚合（每分钟）我们接收的指标并将聚合写入 influxdb 以使它们可用于实时仪表板。

一切正常，但我们现在正在考虑如何管理部署暂停和系统最终故障。

文档说 Kinesis 集成库已经为故障、检查点等做好了准备，但我想澄清一下检查点是如何在那里工作的。

Kinesis 接收器使用 Amazon 根据 Amazon 软件许可 (ASL) 提供的 Kinesis Client Library (KCL) 创建输入 DStream。 KCL 构建在 Apache 2.0 许可的 AWS Java 开发工具包之上，并通过工人、检查点和分片租赁的概念提供负载平衡、容错和检查点。

我们可以定义 kinesis 的检查点间隔，但据我了解，这仅用于标记我们消耗了指标的流的哪个点。所以，我们仍然需要使用 Spark Streaming 中的检查点功能，对吧？

当我们每分钟聚合数据时，我们的批处理间隔为 60 秒，但在这 60 秒内，我们不断地从流中接收数据。

这是我的问题：

• 当我执行 JavaStreamingContext.stop(...) 时（为了部署新版本的作业），接收器将停止并在最后更新检查点？
• 火花流检查点何时发生？每次执行作业后？以前？
• 假设我们的两个检查点都在工作，我们如何保证发生故障时的一致性？似乎每次流式检查点发生时，它都需要同时对运动进行检查点，否则我们可以结束再次读取相同的数据。我们该如何处理？
• 如果底层服务（在本例中为 influxdb）宕机了，我该怎么办？实施重试机制？如果是这样，它需要在一段时间后停止重试，否则我们将耗尽内存。

提前致谢！

Answer 1

不能百分百确定这将是您问题的完整答案，因为检查点解决方案是非常复杂的组件，并且每个子问题都可能需要一个单独的问题。不过，也许这会给这个过程一些线索：

• 检查点在 DStream 级别上工作，这意味着您可以在管道的不同阶段执行检查点。这可能是 Spark 从接收器生成的块创建您的第一个 RDD 的时间点，也可能是您转换后的 RDD，您可以在计算指标后在稍后阶段获得它。因此，当您调用 stop 时（如果您优雅地停止它），您将获得检查点的状态以及在您的接收器在您在管道中选择的点停止后处理的最后一个 RDD

• 检查点由名为 JobGenerator 的 Spark 组件触发。在运行作业之前，它将生成将计算 RDD 的 DStream。在该步骤中，如果您配置了检查点，则该 DStream 的每个 RDD 都将另外创建检查点元数据，并且 RDD 将被标记为需要检查点的RDD。然后 SparkContext 将运行生成的作业，最后它将调用 doCheckpoint 方法，该方法将检查点数据保存到配置的位置。 JobGenerator 将为此创建一个单独的作业，因此您预计实际作业完成和检查点持久性之间会有一些延迟

• Spark 每次运行您的应用程序时，都会根据您的检查点数据创建流式上下文。因此，假设您的指标处于状态 7，例如在您的 Kenesis 接收器停止后关闭的最后一个 Spark，那么当您的流式上下文将被恢复时，它将再次处于状态 7，并且仅从新的 kenesis 数据生成下一批将其置于状态 8

• 好吧，这取决于您将如何构建您的产品。可能只有在您的依赖项成功处理您的数据后才进行检查点（因为我建议应用重试机制以避免短期连接问题）。但信息太少，无法为您提供完整的答案