【问题标题】:In spark structured streaming, is there a way to sleep the read operation during maintenance window for the database在火花结构化流中,有没有办法在数据库维护窗口期间休眠读取操作
【发布时间】:2020-08-07 17:53:54
【问题描述】:

我正在开发一个 Spark 结构化流作业,该作业从 Kafka 主题读取并写入 Jdbc 数据库。

数据库应该有一个维护窗口,我正试图找出一种在不中止工作的情况下处理该案例的方法。

我的代码:

// read data from kafka and transform into required DF.
val transformDF = spark
  .readStream
  .format("kafka")
  .option("kafka.bootstrap.servers", config.kafkaBootstrapServers)
  .option("startingOffsets", "latest")
  .option("subscribePattern", config.topics)
  .load()
  .transform(toRaw)

//write
val query = transformDF
  .writeStream
  .option("checkpointLocation", config.checkpointLocation)
  .foreachBatch { (batchDF: DataFrame, batchId: Long) =>
   batchDF.write
  .format("jdbc")
  .option("url", config.url)
  .option("user", config.username)
  .option("password", config.password)
  .option(JDBCOptions.JDBC_TABLE_NAME, tableName.get)
  .option("stringtype", "unspecified")
  .mode(SaveMode.Append)
  .save()
    })
  }.outputMode(OutputMode.Append()).start()

try {
  query.awaitTermination()
} catch {

  case e: Exception => logger.error("Error", e)
}

现在,如果 DB 不可用,代码将进入异常块并中止。我想避免这种情况,相反,我希望停止进一步阅读消息。我试图避免重新提交作业的手动过程。

这可能吗?

火花:2.4.5

【问题讨论】:

  • 在这种情况下,我建议尝试提供背压的 Akka Kafka(Alpakka)。这意味着当流的内部缓冲区因接收器不可用而已满时,它可以停止从代理中提取消息的过程。您也可以检查 DStream 的背压控制。
  • @EmiCareOfCell44 Akka Kafka 不适合我们。
  • 有趣的是,Spark 官方文档中没有解决这个问题。此外,DEV OPP 的事情意味着优雅的终止。然后重新开始。
  • 你试过ForeachWriter接口吗?您可以在其中实现自己的重试机制。
  • @mike 如果数据库在处理期间在那里脱机怎么办?在目标上至少需要幂等的东西?除非我错了

标签: scala apache-spark apache-spark-sql spark-streaming spark-structured-streaming


【解决方案1】:

不,没有可靠的方法。顺便说一句,不也是一个答案。

检查异常的逻辑通常是通过在驱动程序上运行的 try/catch 实现的,就像您编写的代码一样。这是公认的范式,也是合乎逻辑的。但是这种做法是驱动程序产生的错误。

由于 Executor 级别的意外情况已经由 Spark 框架本身为结构化流处理进行标准处理,如果错误是不可恢复的,那么应用程序/作业在向驱动程序发出错误信号后就会崩溃,除非您在各种 foreachXXX 结构中编写 try / catch 代码。也就是说,尚不清楚微批次是否可以在这种方法中恢复,因为微批次的某些部分很可能会丢失。不过很难测试。

鉴于 Spark 提供了一些您无法挂钩的标准功能,为什么可以在程序源代码中插入循环/try/catch?同样,广播变量也是一个问题——尽管他们说有些人有这方面的技术。但这不符合框架的精神。

所以,很好的问题,我想知道(ed)关于这个(过去)。

【讨论】:

    猜你喜欢
    • 2021-04-02
    • 2019-09-20
    • 1970-01-01
    • 2021-11-14
    • 2013-03-01
    • 2021-09-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多