Spark結構化流式藍色/綠色部署

Question

我們希望能夠部署我們的Spark作業，以便在部署期間處理數據時沒有任何停機時間（目前大約有2-3分鍾的窗口）。 在我看來，最簡單的方法是模擬“藍/綠部署”理念，即啟動新版本的Spark工作，讓它熱身，然后關閉舊工作。 但是，使用結構化流和檢查點，我們無法做到這一點，因為新的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）中，並使用外部客戶端進行編排。