Spark结构化流式蓝色/绿色部署

Question

我们希望能够部署我们的Spark作业，以便在部署期间处理数据时没有任何停机时间（目前大约有2-3分钟的窗口）。在我看来，最简单的方法是模拟“蓝/绿部署”理念，即启动新版本的Spark工作，让它热身，然后关闭旧工作。但是，结构化的流媒体＆amp;检查点，我们不能这样做，因为新的Spark作业看到最新的检查点文件已经存在（来自旧的工作）。我在下面附上了一个示例错误。有没有人对潜在的解决方法有任何想法？

我考虑过将现有的检查点目录复制到另一个检查点目录以获取新创建的作业 - 虽然这应该可以作为一种解决方法（某些数据可能会被重新处理，但我们的数据库应该重复删除），这似乎超级hacky和我的东西我宁愿不追求。

Caused by: org.apache.hadoop.fs.FileAlreadyExistsException: rename destination /user/checkpoint/job/offsets/3472939 already exists
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.validateOverwrite(FSDirRenameOp.java:520)
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.unprotectedRenameTo(FSDirRenameOp.java:364)
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.renameTo(FSDirRenameOp.java:282)
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.renameToInt(FSDirRenameOp.java:247)
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3677)
    at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename2(NameNodeRpcServer.java:914)
    at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename2(ClientNamenodeProtocolServerSideTranslatorPB.java:587)
    at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
    at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
    at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049)
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:422)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1698)
    at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2045)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
    at org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
    at org.apache.hadoop.hdfs.DFSClient.rename(DFSClient.java:1991)
    at org.apache.hadoop.fs.Hdfs.renameInternal(Hdfs.java:335)
    at org.apache.hadoop.fs.AbstractFileSystem.rename(AbstractFileSystem.java:678)
    at org.apache.hadoop.fs.FileContext.rename(FileContext.java:958)
    at org.apache.spark.sql.execution.streaming.HDFSMetadataLog$FileContextManager.rename(HDFSMetadataLog.scala:356)
    at org.apache.spark.sql.execution.streaming.HDFSMetadataLog.org$apache$spark$sql$execution$streaming$HDFSMetadataLog$$writeBatch(HDFSMetadataLog.scala:160)
    ... 20 more
Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.fs.FileAlreadyExistsException): rename destination /user/checkpoint/job/offsets/3472939 already exists

Answer 1

这是可能的，但它会给您的应用程序增加一些复杂性。启动流通常很快，因此可以假设，延迟是由静态对象和依赖关系的初始化引起的。在这种情况下，您只需要SparkContext / SparkSession，并且没有流式依赖关系，因此可以将此过程描述为：

• 启动新的Spark应用程序。
• 初始化面向批处理的对象。
• 将消息传递给上一个应用程序以降级。
• 等待确认。
• 启动流。

在非常高的层面上，幸福的道路可以被视为：

由于它是非常通用的模式，它可以以不同的方式实现，具体取决于语言和基础结构：

• 轻量级消息传递队列，如ØMQ。
• 通过分布式文件系统传递消息。
• 将应用程序放置在交互式上下文（Apache Toree，Apache Livy）中，并使用外部客户端进行编排。