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

Question

我们使用连接到AWS Kinesis流的Spark Streaming,以便聚合(每分钟)我们收到的指标,并将聚合写入Influxdb,以便将它们提供给实时仪表板.

一切都运行良好,但我们现在正在考虑如何管理系统的部署和最终故障的暂停.

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

Kinesis接收器使用Amazon在亚马逊软件许可(ASL)下提供的Kinesis客户端库(KCL)创建输入DStream.KCL构建于Apache 2.0许可的AWS Java SDK之上,并通过Workers,Checkpoints和Shard Leases的概念提供负载平衡,容错,检查点.

我们可以为kinesis定义检查点间隔,但据我所知,它仅用于标记直到我们消耗了指标的流的哪个点.所以,我们仍然需要使用火花流的检查点功能,对吧？

由于我们每分钟聚合数据,我们的批处理间隔为60秒,但在这60秒内,我们不断从流中接收数据.

这是我的问题:

• 当我执行JavaStreamingContext.stop(...)(为了部署新版本的作业)时,接收器将被停止并且检查点将在最后更新？
• 火花流检查点什么时候发生？每次执行工作后？之前？
• 假设我们两个检查点都工作,我们怎样才能保证失败时的一致性？似乎每次流式检查点发生时,它都需要同时检查点到kinesis,否则我们可以再次读取相同的数据.我们怎么办呢？
• 如果底层服务(在这种情况下为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

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