gpt4 book ai didi

apache-spark - Kinesis Spark Streaming Receiver的检查点如何工作

转载 作者:行者123 更新时间:2023-12-04 08:54:56 27 4
gpt4 key购买 nike

我们正在使用连接到AWS Kinesis流的Spark Streaming来(每分钟)汇总接收到的指标并将指标写入influxdb,以使其可用于实时仪表板。

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

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

The Kinesis receiver creates an input DStream using the Kinesis Client Library (KCL) provided by Amazon under the Amazon Software License (ASL). The KCL builds on top of the Apache 2.0 licensed AWS Java SDK and provides load-balancing, fault-tolerance, checkpointing through the concepts of Workers, Checkpoints, and Shard Leases.



我们可以定义运动学的检查点间隔,但是据我所知,这只是用来标记直到消耗了度量的流的哪一点为止。因此,我们仍然需要使用Spark Streaming中的检查点功能,对吗?

当我们每分钟汇总一次数据时,批处理间隔为60秒,但在这60秒内,我们不断从流中接收数据。

这是我的问题:
  • 当我执行JavaStreamingContext.stop(...)(以部署作业的新版本)时,接收器将停止并且检查点将在最后更新吗?
  • Spark 流检查点何时发生?每次执行工作后?前?
  • 假设我们两个检查点都在工作,那么在出现故障的情况下如何保证一致性?似乎每次发生流检查点时,都需要同时检查运动点,否则我们可以再次结束读取相同的数据。我们该如何处理呢?
  • 如果基础服务(在本例中为influxdb)关闭,我该怎么办?实现重试机制?如果是这样,它需要在一段时间后停止重试,否则我们将耗尽内存。

  • 提前致谢!

    最佳答案

    由于检查点解决方案是一个非常复杂的组件,并且每个子问题在SO中都可能需要一个单独的问题,因此不能百分百地确定这将是您问题的完整答案。不过,也许这会为该过程提供一些线索:

  • 检查点可以在DStream级别上工作,因此这意味着您可以在管道的不同阶段执行检查点。这可能是Spark通过接收方生成的块创建第一个RDD的时候,也可以是转换后的RDD,您可以在计算指标后的下一个阶段使用它。因此,当您调用stop(如果您优雅地停止它)时,将在接收方停止在管道
  • 中选择的点后,处理最后一个RDD的检查点状态
  • 检查点由名为JobGenerator的Spark组件触发。在运行作业之前,它将生成将计算RDD的DStream。在这一步上,如果配置了检查点,则该DStream的每个RDD都会另外创建检查点元数据,并且RDD将标记为需要检查点的元数据。然后,SparkContext将运行生成的作业,最后将调用doCheckpoint方法,该方法会将检查点数据持久保存到配置的位置。 JobGenerator将为此创建一个单独的作业,因此您期望实际的作业完成与检查点持久性之间存在一些延迟
  • 每次Spark将运行您的应用程序时,它将从您的检查点数据创建流上下文。所以可以说,如果您的指标处于状态7,例如在停止Kenesis接收器后最后一次Spark关闭时,那么当您的流上下文恢复时,它将再次处于状态7,并且只有下一个批次是根据新的Kenesis数据生成的将其置于状态8
  • 很好,这取决于您如何设计产品。可能只有在依赖项成功处理了数据之后才进行检查点设置(原因是,我建议您应用重试机制以避免短期连接问题)。但是,那是很少的信息,无法为您提供关于
  • 的完整答案

    关于apache-spark - Kinesis Spark Streaming Receiver的检查点如何工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35925580/

    27 4 0