本发明实施方式涉及用于3D重建的分布式计算系统以及3D重建方法。
背景技术：
：：随着无人飞行技术的出现，使建筑物数据收集变易。飞行一天可收集数T字节(TeraBytes)的数据。大规模三维(3D)重建，例如城市3D重建，需要大量的计算资源，在典型的消费级别机器上需要运行数周至数个月。并且，当前的3D重建程序是用C++编写的巨大工程，只能在单机上运行，不适用于目前流行的分布式架构，例如，Hadoop(Hadoop是一个由Apache基金会所开发的分布式系统基础架构)和Spark(Spark是UCBerkeleyAMPlab(加州大学伯克利分校的AMP实验室)所开源的类HadoopMapReduce的通用并行框架)。因为现有流行的架构要求开发者用他们的语言和API(ApplicationProgrammingInterface，应用编程接口)重写应用程序，这样成本太高了。因此，无人飞行技术使建筑物数据收集更加容易，但对目前3D重建程序的可扩展性和有效性提出了挑战。技术实现要素：鉴于现有技术面临的上述挑战，本发明的发明人提供了一种用于3D重建的分布式计算系统以及3D重建方法。根据本发明的一种实施方式，所述用于3D重建的分布式计算系统包括分布式文件系统和由多个机器组成的集群，其中，多个机器中的一者被选举为主控机而其余机器为工作机。其中，多个工作机共享所述分布式文件系统，并且所述分布式文件系统与可移植操作系统接口标准兼容；所述主控机将接收到的3D重建工程的多个作业调度到所述多个工作机，所述多个工作机运行接收到的作业以完成3D重建。可选地，所述分布式文件系统为Gluster系统。Gluster是一个集群的文件系统，支持PB(PetaByte)级的数据量。Gluster系统通过RDMA(远程直接数据存取)和TCP/IP(传输控制协议/因特网互联协议)方式将分布到不同服务器上的存储空间汇集成一个大的网络并行文件系统根据本发明的另一种实施方式，所述分布式计算系统还包括分布式键值存储系统，所述分布式键值存储系统存储所述主控机的键值和状态。优选地，所述分布式键值存储系统为etcd。etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于ZooKeeper和Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个来自Stanford的新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性，在Raft中，任何一个节点都可能成为领导(Leader)或主控机(master)。因此，多个机器中的一者被选举为主控机可以包括：所述多个机器将各自的ID放到所述分布式键值存储系统的主控机键上，但只有一个机器可将ID成功放到所述主控机键上；所述多个机器从所述分布式键值存储系统获取主控机ID；所述多个机器中的自身ID与获得的主控机ID相同的机器作为所述主控机，其余机器为所述工作机。在本发明实施方式中，当所述主控机故障时，选举出新的主控机，并从所述分布式键值存储系统恢复出原主控机的状态。由此提高系统的容错性。在本发明实施方式中，所述工作机成对地运行，并且复制彼此的数据。这样，在一个工作机崩溃的情形下，可使用其配对的工作机的数据继续运行作业。由此进一步提高系统的容错性。在本发明的各种实施方式中，所述作业的属性包括作业类型、任务数量和限制条件。所述作业之间具有逻辑相依性、IO(输入输出)相依性。这样，所述主控机根据作业之间的逻辑相依性、IO相依性将所述多个作业调度到所述多个工作机上运行。例如，将具有IO相依性的作业安排在同一工作机上运行。在本发明的各种实施方式中，所述主控机通过HTTP协议(超文本传输协议)与外部通信。这样，用户可以通过网页界面(WebUI)监控所述分布式计算系统中的集群状态和工作状态。在一种实施方式中，所述主控机接收所述用户通过HTTP协议以JSON格式发送的作业。JSON(JavaScriptObjectNotation)是一种轻量级的数据交换格式，其基于ECMAScript的一个子集。在本发明的各种实施方式中，所述主控机与所述多个工作机通过远程过程调用RPC进行通信。并且，可为所述主控机和工作机各自的用于RPC的编码器和解码器设置时间限制。在本发明的各种实施方式中，所述工作机使用一组容器来运行接收的作业的任务。例如，所述容器可以是Docker容器。并且，所述任务在所述Docker容器的内部运行，并且与主操作系统隔离。如果容器内运行的任务用完其要求的资源，则停止该任务，而不会影响主操作系统。在本发明的进一步实施方式中，可通过将所述容器作为Docker镜像的方式输出应用，以便通过所述Docker镜像在其他操作系统上运行所述应用。由此，为了处理应用，不再要求用户手动安装全部依赖库(dependencylibraries)。在本发明的各种实施方式中，所述主控机基于作业的优先级和约束因素调度所述作业。所述约束因素可以包括作业约束和任务约束。并且，所述主控机使用LATE(LongestApproximateTimetoEnd，最长运行时间估计)算法处理优先级比其他任务低的任务。可选地，所述主控机使用LATE算法处理优先级比其他任务低的任务包括：每当存在空闲资源时，所述主控机推测运行任务，并将推测出的优先级比其他任务低的任务复制到另一工作机上运行。由此，可以加速运行时间。在本发明的另外的实施方式中，本发明还提出了一种3D重建方法，所述方法可以包括：将3D重建工程分解成多个作业，将分解的作业发送至根据本文各种实施方式所述的分布式计算系统，所述分布式计算系统运行所述作业以完成3D重建。采用分布式计算系统，无需修改源代码就可以很容易地将现有的单机3D重建程序移植到集群中。这样，3D重建工程可以分成多个小的作业。分布式计算系统管理这些作业的相依性(即依赖关系)，并将其调度到合适的机器上，推测掉队的作业，并重新开始失败的作业。此外，分布式计算系统是一种集群资源管理系统，它将多个机器连接在一起，从这些(物理的或虚拟的)机器抽离CPU(中央处理器)、GPU(图形处理器)、存储器、以及其他计算资源，从而构建容错的、灵活的分布式系统，并使该分布式系统有效地运行。分布式计算系统还提供了用于监控集群状态和作业状态的WebUI，这样，用户可以直接通过网页添加、删除、重启作业。通过产业应用，其结果表明分布式计算系统可以成功地加速3D重建工程，有效地适应了当前无人飞行技术在建筑物数据收集的应用。附图说明图1是根据本发明实施方式的用于3D重建的分布式计算系统的框图；图2是根据本发明另一实施方式的用于3D重建的分布式计算系统的框图；图3示出了根据本发明实施方式从多个机器确定主控机的处理流程；图4示出了使用根据本发明实施方式所述的分布式计算系统进行3D重建的处理流程；图5示出了根据本发明另一实施方式的用于3D重建的分布式计算系统的框图；图6示出了根据本发明实施方式的主控机选举过程；图7示出了在根据本发明实施方式所述的分布式计算系统中主控机和工作机之间的远程过程调用(RPC)过程；图8示出了在根据本发明实施方式所述的分布式计算系统中运行任务的容器；图9示出了在根据本发明实施方式所述的分布式计算系统中作业状态的变化；图10示出了在根据本发明实施方式所述的分布式计算系统中不进行工程调度的情况；图11示出了在根据本发明实施方式所述的分布式计算系统中的一种示例性工程调度。具体实施方式为了便于理解本发明技术方案的各个方面、特征以及优点，下面结合附图对本发明进行具体描述。应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。下面参考方法、系统、设备、装置和编程以及计算机程序产品的示例框图来描述本发明。应当理解的是，示例框图中的每一个框及其组合可通过编程指令来实现，所述编程指令包括计算机程序指令。这些计算机程序指令可被装载至计算机或其他可编程数据处理装置，这样在计算机或其他可编程数据处理装置上执行的指令产生用于实现框图或流程图中指定的功能的指令。这些计算机程序指令还可存储在计算机可读存储器中，可指示计算机或其他可编程数据处理装置以特定方式运行，这样，存储在计算机可读存储器中的指令产生包括实现框图或流程图中指定的功能的指令的制造品。计算机程序指令还可装载至计算机或其他可编程数据处理装置，以产生一系列在所述计算机或其他可编程装置中执行以产生计算机执行程序的操作步骤，这样，在所述计算机或其他可编程装置上执行的指令提供实现在框图或流程图中指定的功能的步骤。编程指令还可存储于电子线路中和/或通过电子线路实施以实现本发明的各个功能、步骤。用于3D重建的分布式计算系统【实施例1】图1示出了根据本发明实施方式的用于3D重建的分布式计算系统。在本实施方式中，所述用于3D重建的分布式计算系统可以包括分布式文件系统100和由多个机器组成的集群，其中，多个机器中的一者被选举为主控机200而其余机器为工作机300。其中，多个工作机300共享所述分布式文件系统100，并且，所述分布式文件系统100与可移植操作系统接口标准兼容，这样，已有单机3D重建程序，例如C++程序，可以利用其自己的标准文件API读、写文件，就像使用本地磁盘一样。所述主控机200接收用户提交的3D重建工程(project)，所述3D重建工程由多个作业(jobs)组成，每个作业由多个任务(tasks)组成。所述主控机200将接收到的3D重建工程的多个作业调度到所述多个工作机300，所述多个工作机300运行接收到的作业以完成3D重建。可选地，所述分布式文件系统为Gluster系统。Gluster是一个集群的文件系统，支持PB级的数据量。Gluster系统通过RDMA和TCP/IP方式将分布到不同服务器上的存储空间汇集成一个大的网络并行文件系统。采用本发明实施方式的分布式计算系统，无需修改源代码就可以很容易地将现有的单机3D重建程序移植到集群中。这样，有效地提高了3D重建程序的可扩展性和有效性。【实施例2】图2示出了根据本发明另一实施方式的用于3D重建的分布式计算系统。在本发明实施方式中，所述分布式计算系统除了包括分布式文件系统100、主控机200、多个工作机300之外，还包括分布式键值存储系统400。其中，所述主控机200、多个工作机300属于由多个机器构成的集群，多个机器竞选主控机，而其余机器为工作机。在本发明的可选实施方式中，如图3所示，在S300，所述多个机器将各自的ID(身份标识)放到所述分布式键值存储系统的主控机键上，但只有一个机器可将ID成功放到所述主控机键上；在S320，所述多个机器从所述分布式键值存储系统获取主控机ID；S330，各个机器判断自身ID是否与主控机ID相同；若是，则在S351，所述多个机器中的自身ID与获得的主控机ID相同的机器作为所述主控机200，否则，在S352，其余机器为所述工作机300。因此，所述分布式键值存储系统400可用于存储所述主控机200的键值和状态。在本发明的可选实施方式中，所述分布式键值存储系统400可以为etcd。etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于ZooKeeper和Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个来自Stanford的新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性，在Raft中，任何一个节点都可能成为领导(Leader)或主控机(master)。在本发明各种实施方式中，当所述主控机故障时，选举出新的主控机，并从所述分布式键值存储系统400恢复出原主控机的状态。由此提高系统的容错性(faulttolerance)。在本发明进一步的实施方式中，所述工作机还可以成对地运行，并且复制彼此的数据。这样，在一个工作机崩溃的情形下，可使用其配对的工作机的数据继续运行作业。由此进一步提高系统的容错性。【实施例3】在本发明的可选实施方式中，所述用于3D重建的分布式计算系统可具有上述实施例1或实施例2所述的功能、结构、特征。此外，进一步地，所述作业的属性可包括作业类型、任务数量和限制条件。所述作业之间具有逻辑相依性、IO相依性。这样，所述主控机200根据作业之间的逻辑相依性、IO相依性将所述多个作业调度到所述多个工作机300上运行。例如，将具有IO相依性的作业安排在同一工作机上运行。由此，提高数据本地化特性(datalocality)。【实施例4】在本发明的可选实施方式中，所述用于3D重建的分布式计算系统可具有上述实施例1或实施例2或实施例3所述的功能、结构、特征。此外，进一步地，所述主控机200通过HTTP协议与外部通信。这样，用户可以通过WebUI监控所述分布式计算系统中的集群状态和工作状态。可选地，所述主控机200接收所述用户通过HTTP协议以JSON格式发送的作业。JSON是一种轻量级的数据交换格式，其基于ECMAScript的一个子集。根据本发明实施方式，相比于其他分布式计算架构，所述用于3D重建的分布式计算系统可接受任何编程语言的程序写入，只要产生的JSON文件符合RestfulAPI规范。其中，Restful是一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。【实施例5】在本发明的可选实施方式中，所述用于3D重建的分布式计算系统可具有上述实施例1、2、3或4所述的功能、结构、特征。此外，进一步地，在本发明的选择性实施方式中，所述主控机200与所述多个工作机300可以通过RPC进行通信。当主控机200和工作机300之间有太多业务流时，网络将变得不稳定。在这种情况下，必须关闭连接，否则会发生丢包并且RPC将挂起。为了解决这个问题，在本发明实施方式中，不会设置RPC的时间限制(deadline)，因为作业完成时间不可预期，而是为编码器和解码器设置期限，因为消息编码和解码时间可表示网络的状态。因此，本发明的可选实施方式为所述主控机和工作机各自的用于RPC的编码器和解码器设置时间限制。【实施例6】在本发明的可选实施方式中，所述用于3D重建的分布式计算系统可具有上述实施例1至5任意一个所述的功能、结构、特征。此外，进一步地，在本发明的可选实施方式中，所述工作机300使用一组容器(container)来运行接收的作业的任务。例如，所述容器可以是Docker容器。并且，所述任务在所述Docker容器的内部运行，并且与主操作系统隔离。如果容器内运行的任务用完其要求的资源，则停止该任务，而不会影响主操作系统。此外，在本发明的进一步实施方式中，可通过将所述容器作为Docker镜像的方式输出应用，以便通过所述Docker镜像在其他操作系统(例如，windows、Linux、MacOS)上运行所述应用。由此，为了处理应用，不再要求用户手动安装全部依赖库(dependencylibraries)。【实施例7】在本发明的可选实施方式中，所述用于3D重建的分布式计算系统可具有上述实施例1至6任意一个所述的功能、结构、特征。此外，进一步地，在本发明的可选实施方式中，所述主控机200基于作业的优先级和约束因素调度所述作业。所述约束因素可以包括作业约束和任务约束。并且，所述主控机使用LATE算法处理优先级比其他任务低的任务。可选地，所述主控机使用LATE算法处理优先级比其他任务低的任务包括：每当存在空闲资源时，所述主控机推测运行任务，并将推测出的优先级比其他任务低的任务复制到另一工作机上运行。由此，可以加速运行时间。3D重建方法图4示出了根据本发明实施方式的3D重建方法的流程。在本发明实施方式中，所述3D重建方法可以包括：将3D重建工程分解成多个作业(S400)，将分解的作业发送至根据本文各种实施方式所述的分布式计算系统(S420)，所述分布式计算系统运行所述作业以完成3D重建(S440)。应当理解，在此所述的3D重建工程可以是现有单机3D重建程序，也可以是本领域技术人员根据需要重新编程的3D重建程序。根据以上各种实施方式，无需修改源代码就可以很容易地将现有的单机3D重建程序移植到集群中。这样，3D重建工程可以分成多个小的作业。本发明实施方式的分布式计算系统管理这些作业的相依性(即依赖关系)，并将其调度到合适的机器上，推测掉队的作业，并重新开始失败的作业。此外本发明实施方式的分布式计算系统将机器连接在一起，从这些(物理的或虚拟的)机器抽离CPU、GPU、存储器、以及其他计算资源，从而构建容错的、灵活的分布式系统，并使该分布式系统有效地运行。并且，本发明实施方式还提供了用于监控集群状态和作业状态的WebUI，这样，用户可以直接通过网页添加、删除、重启作业。应用面对目前无人飞行技术的应用给3D重建程序提出的挑战，本发明的发明人基于上述各种不同实施方式的教导，开发了一种用于大规模3D重建的分布式计算架构，称之为ZRPC。采用ZRPC，无需修改源代码就可以将现有的单机3D重建程序移植到集群中。这样，可将3D重建工程分成分成多个步骤，每个步骤可以视为一个作业，作业由要求不同数量的机器的任务组成。ZRPC管理这些作业的依赖关系，将其调度到合适的机器上，并推测或预测掉队的作业，重新开始失败的作业。此外，ZRPC是一种集群资源管理系统，它将机器连接在一起，从这些物理的或虚拟的机器抽离CPU、GPU、存储器、以及其他计算资源，从而构建容错的、灵活的分布式系统，并使该分布式系统有效地运行。ZRPC提供了用于监控集群状态和作业状态的WebUI，这样，用户可以直接通过网页添加、删除、重启作业。将ZRPC产业应用，结果表明ZRPC可以成功地加速3D重建工程。下面从各个方面介绍本发明的发明人提出的ZRPC。1.总体说明1.1目的需要一种满足下述要求的分布式系统：1.该系统应该能够将C++程序包作为一个作业，而无需改变其源代码。换句话说，分布式系统对用户是透明的。这相对于现有流行的架构(例如，HadoopMapReduce和Spark)来说是一个很大的优点。现有流行的架构要求开发者用它们的语言和API重写应用程序。2.使用集群(cluster)机可以显著减少3D重建工程的完成时间。为了实现这一点，可以共享集群源，并可以适当地调度(schedule)作业。总的IO吞吐量、网络带宽、CPU以及GPGPU(GeneralPurposeGPU，通用计算图形处理器)计算能力应当与机器数量的增加成线性增加。3.分布式文件系统应当与可移植操作系统接口(PortableOperatingSystemInterface，POSIX)标准兼容，这样，C++程序可以利用其自己的标准文件API读、写文件，就像使用本地磁盘一样。如果没有POSIX兼容性，用户必须改变C++程序源代码，这就与要求1相违背。4.集群应该满足常见的分布式系统要求：可扩展性和可靠性。可扩展性意味着该集群具有扩大以处理更多任务的潜能。随着工程的数量和大小增加，用户应该能够动态增加机器，并且不会影响集群中运行的当前作业。可靠性意味着系统是容错能力。故障在集群中是常见的。有三种故障：作业故障、机器故障、以及网络故障。全部故障应当被处理以最小化对工程运行的影响。1.2解决方案鉴于上述，本发明的发明人开发了ZRPC，其在作为单个系统的集群机上运行作业以加速3D重建。ZRPC是用于在集群的多个主机(hosts)之间管理资源和调度作业的分布式系统，提供作业部署、调度、更新、维护和扩展的机制。ZRPC具有三个优势：(1)提供了隐藏资源管理和故障处理的细节的简单抽象，这样，用户可集中于应用开发；(2)作业运行具有高可靠性、有效性和数据安全；(3)并行运行任务，以显著减少作业运行时间。图5示出了ZRPC的架构。其由4个部分组成，分别为：称为主控机的逻辑集中控制器、一组运行任务的工作机、基于Raft一致性算法的持久存储调用ETCD、以及由工作机共享的分布式文件系统(其存储了所有任务输出)。工作机实际上是ZRPC进程(process)，ZRPC进程控制一组运行任务的容器。ZRPC使用远程过程调用(RemoteProcedureCall，RPC)进行内部通信，并且使用HTTPRestfulAPI进行外部通信。用户可通过Web浏览器和pythonAPI运行作业并监控机器。本发明实施例利用Gluster作为基础分布式系统，其适于存储大量小文件，并具有较小的文件存取延迟。以下对它们进行具体讨论。2.集群管理2.1机器发现ZRPC依赖于etcd，一种基于Raft的分布式一致性键值存储技术，用于分享配置和服务发现。Raft是一致性算法，其在容错性和性能方面与Paxos相当，区别在于它被分解成相对于独立的多个子问题，并且，对实际系统所需的所有主要部分清楚地寻址(address)。机器注册信息包括逻辑CPU核心的数目、GPGPU的可用性、以及分布式文件系统信息。这些信息可经常更新，以用作任务运行的约束条件。2.2集群领导选举建立集群的进程由3个步骤组成。第一，建立小etcd集群。只要至少一半的机器可用，所述etcd集群就可保持数据可靠和安全。第二，设置所有机器并将它们注册到etcd上。每个机器开始处于选举状态。在选举状态下，每个机器试图选举自己作为主控机，并将它们的ID放到etcd的主控机键上。然而，只有一个机器可成功放到主控机键上。第三，所有机器从etcd集群请求主控机ID。如果响应的ID等于自身的ID，则该机器进入主控机状态，否则该机器进入工作机状态。选举的主控机应当心跳检测(heartbeat)etcd以维持其主控机角色。一旦主控机值过期，所有机器重新进入选举状态。2.3容错性ZRPC中的主控机不可复制，但其数据可以复制。主控机将其状态快照复制(snapshot)进etcd。当主控机崩溃时，集群将选举新主控机并从集群恢复原主控机的状态。如图6所示，在作业运行期间，工作机可加入和离开。为了可靠性，ZRPC中工作机是成对的，并且复制彼此的数据。在一个工作机宕机的情形下，可使用与其配对的对等体的数据继续运行作业。然而，如果一对中的两个工作机同时宕机，作业将进入故障状态，并要求管理员手动修复这个问题。第二种情形是个严重的问题，因此，需要最小化它的出现几率。假设采用具有N个节点的集群，具有N/2对，每个节点崩溃的概率为P，并且管理员每隔T时间单位检查集群，这样，在T时间单位一个节点崩溃的概率为PT，因此，在整个集群中发生第二种情形的概率P为：P＝N/2(PT)2例如，现有集群具有10个节点，典型的平均机器崩溃频率为每3个月一次，系统管理员每8小时检查集群。这样，可以得到在一天中一对工作机崩溃的概率为p＝0.0000685871，意味着每隔14580天才出现一次。2.4部署在实际应用中，一个易用的安装工具是非常重要的。在本实施方式中，基于Ansible架构来构造自动部署工具。Ansible是一种IT自动工具。其可以配置系统、部署软件以及安排更先进的IT任务，例如，连续部署或零停机滚动更新。该工具能够将本实施方式的程序，包括ZRPC、Gluster、etcd以及3D重建程序，自动地安装到新集群中或新机器中。[cluster]cent01Name＝cent01IP＝192.168.226.140cent02Name＝cent02IP＝192.168.226.141cent03Name＝cent02IP＝192.168.226.142cent04Name＝cent02IP＝192.168.226.143cent05Name＝cent02IP＝192.168.226.144[cluster:vars]ClusterName＝demoEtcdEndpoints＝["http://192.168.226.140:2379","http://192.168.226.141:2379","http://192.168.226.142:2379"]以上是5节点集群配置示例，其中，cent01、cent02和cent03组成etcd集群，用于存储和同步集群信息。用户只需要指定每个机器的角色和IP以及“EtcdEndpoints”(etcd集群的联系点)。3.作业和任务3.1用户管理用户必须采用系统管理员的账户才能使用ZRPC系统。有了该账户，用户可以提交作业、上传输入文件、以及下载分布式文件系统的结果文件。监控web页面可显示用户的作业状态。3.2作业类型作业的属性包括作业类型、任务数量和限制条件(constrains)。限制条件可以CPU数量、是否依赖GPU、以及机器性能。作业类型可以是单个(Single)、多个(Multiple)、批量(Batch)和服务(Service)。针对这些作业类型，ZRPC具有对应的策略。Single：“Single”类型的作业只包含一个命令和一个输入文件。ZRPC将其随机安排到工作机。Batch：“Batch”类型的作业包含命令列表。每个命令具有其自身的输入文件，并且不依赖于其他命令。ZRPC将每个命令作为一个任务，并平等地安排它们。Multiple：“Multiple”类型的作业只具有一个命令，但具有输入文件列表。ZRPC将考虑数据本地化和工作机性能，将该列表智能地分成多个小列表。然后，每个小列表为每个任务的输入。Service：Service是预定义的作业模板。其用于处理如下安全性问题：普通用户在ZRPC上可运行任何作业，包括那些有害的作业。管理员在ZRPC上注册Service，普通用户可通过所需的参数调用它。Service具有程序文件夹，其包含可执行文件和相依文件(dependentfiles)。用户可以通过ZRPC的web接口更新这些文件。作业之间有两种相依性，逻辑相依性和IO相依性。如果作业A逻辑依赖于作业B，那么作业A应当安排在作业B之后，因为B将向A传送一些信息。如果作业AIO依赖于作业B，那么作业A应当安排在作业B之后，它们的任务应当安排在同一个机器上，因为作业A将读取作业B的输出。将它们的任务安排在同一个机器上将提高数据本地化特性。3.3RestfulAPI用户可通过HTTP协议以JSON格式向ZRPC服务器发送作业。ZRPC服务器提供RestfulAPI。表述性状态传递(RepresentationStateTransfer，REST)是源自数个基于网络的架构风格的混合风格。意味着客户端与服务器之间的通信是无状态的。通过向ZRPC服务器发送作业，客户端可以获得作业ID。随后，可使用该作业ID查询作业状态或停止(kill)该作业。例如，如果用户作业想要在ZRPC上运行批量作业，将下述JSON字符串发送至http://serverIP/cmd/batch:{"Name":"testjob","Type":"batch","Threads":2,"GPU":True,"User":"jobs","FileDepend":JobID,"BatchArgs":[......]}“Name”是作业的描述。“Threads”表示作业中每个任务逻辑CPU核心的数量。“GPU”为布尔标志(booleanflag)，告知系统：作业是否要求运行GPU。“serverIP”可以是集群中任何机器的IP地址，因为ZRPC为多代理的。多代理意味着，如果非主控工作机接收到作业请求，则它将该请求重定向至主控机，这样，用户不需要知道当前主控机是哪个。“FileDepend”用于指定IO相依性作业。如果该作业IO依赖于另一个作业，则调度程序(scheduler)将尝试将它们安排在同一个机器上。当接收到作业请求时，服务器将首先解析该请求以看其是否符合作业规范，随后向用户响应作业ID以供后续使用。相比于其他分布式计算架构，ZRPC接受任何编程语言的程序写入，只要产生的JSON文件符合RestfulAPI规范。3.4远程过程调用主控机通过远程过程调用(RPC)向工作机发送作业。RPC将过程调用的常见程序设计抽象扩展到分布式环境，允许主控机调用工作机中的过程(procedure)，如同本地调用那样。例如，当主控机调用工作机的“DoJob”方法，通过网络向工作机实际发送参数。当工作机完成该任务时，向主控机返回结果图7示出了在本实施方式的系统上RPC的执行过程。ZRPC通过TCP协议以gob格式(编码器和解码器之间交换的二进制值)传输值。与主控机和客户端的HTTP协议相比，TCP更快并且冗余更少。相比于JSON，Gob格式节省更多的空间。因为主控机与工作机之间的业务流(trafficflow)远多于主控机与客户端之间的业务流，所以必须更加关注性能。此外，当主控机和工作机之间有太多业务流时，网络将变得不稳定。在这种情况下，必须关闭连接，否则会发生丢包并且RPC将挂起。为了解决这个问题，在本发明实施方式中，不设置RPC的时间限制(deadline)，因为作业完成时间不可预期，而是为gob编码器和解码器设置期限，因为消息编码和解码时间表示网络的状态。3.5容器虚拟机是大多数云计算平台使用的传统隔离方法。然而，现代的调度程序在基于LinuxCgroup的资源容器内运行任务。Cgroups是controlgroups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程组(processgroups)所使用的物理资源(如：CPU、内存、IO等等)的机制。相比于虚拟机，容器更轻，占用更少的系统资源，并且要求更少的启动时间。如图8所示，在每一个ZRPC工作机节点，ZRPCD进程接收主控机的任务并启动一串运行任务的容器。下面讨论ZRPC系统使用Docker(一种流行的容器实现，Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化)的三个优势。3.5.1资源隔离用户可有意或无意使用比其所要求的还多的计算资源运行作业。例如，如果程序造成内存泄露(memoryleak)，它将消耗全部内存资源并且最终使全部其他作业不能运行。更糟糕的是，实验表明写得不好的程序甚至可使整个机器崩溃。因此，需要资源隔离机制以限制作业最大的资源使用量。一旦接收到任务消息，ZRPCD将启动具有声明的资源限制的容器，这样，任务在其内部运行，与主操作系统隔离。如果容器内运行的任务用完其要求的所有资源，则停止该任务，而不会影响主操作系统。此外，当容器内运行进程时，其建立的各子进程也在容器内运行，这样，可容易地控制整个进程组。3.5.2一致的运行时环境机器的硬件具有异质性，软件也是。随着时间的过去，新机器加入集群，旧机器退出，操作系统内核版本和安装的软件可能会改变。更糟的是，在开发者机器上正常运行的应用可能在集群中失败。容器解决了这种问题，因为它确保集群和开发者机器的运行时环境一致。所有Docker容器是根据一个配置文件建立。一旦配置文件变化，所有容器将及时重建。3.5.3便于移植便于移植意味着应用可自由地迁移到其他操作系统。采用Docker，可以通过将容器作为Docker镜像(Dockerimage)输出应用。该镜像可在所有主流平台上运行，包括Linux、Windows、MacOS。因此，为了处理应用，不再要求用户手动安装全部依赖库(dependencylibraries)。图9示出了作业状态转移过程。如图9所示，等待创建作业；请求工作机，通过工作机运行作业；运行完成，则成功；运行时错误，则失败；还可以停止作业；运行过程中连接错误或系统错误，则返回等待新的创建作业。3.6调度ZRPC使用简单且快速的中央式调度器(monolithicscheduler)。在本发明实施方式中，在调度作业时考虑两个因素，即优先级和约束因素。收到的作业将基于其优先级被放进对应的作业队列。ZRPC支持的两种约束因素为作业约束(per-jobconstraint)和任务约束(per-taskconstraint)。作业约束是对所有任务而言的，例如，要求所有任务使用GPU运行。任务约束是对单个任务而言的，例如，数据本地化约束使具有输入数据的机器运行。ZRPC具有全局(global)作业优先级队列，用于调度作业，并且，对于每一个作业，其具有自己的任务调度器或调度程序。通过作业优先级队列调度器，ZRPC可对工程作业进行细粒度控制。如前所述，重建工程包含相继运行的4个步骤(作业)。图10和图11例证了ZRPC如何调度两个工程以减小平均工程完成时间。假设工程A在时刻0到达，并且工程B在时刻2到达。图10示出了没有调度的情况，A的时间跨度为0～7，B的时间跨度为2～14，这样，平均完成时间为9.5。在图11中，因为工程A比B先到达，A的所有作业的优先级比B的作业的优先级高，调度器将首先运行A的作业，然后只要有空闲的节点就运行B的作业。因此，A的时间跨度为0～7，B的时间跨度为2～10，平均完成时间为7.5。落后者(straggler)是比其他任务运行优先级低的任务，并且，因为作业只在其最后的任务完成时完成，落后者会延迟作业完成。ZRPC调度器使用LATE算法处理落后者。LATE是LongestApproximateTimetoEnd(最长运行时间估计)的简写，其通常预测性地执行认为将来最后才完成的任务。每当存在空闲资源预算，调度器就推测运行任务并且将识别出的落后任务克隆到另一机器(在这种情况下是快节点)上。较早完成的任务的结果被挑选出来作为校正结果。考虑到ZRPC在10节点集群中运行10个任务组成的1个作业的情况，调度器为每一个节点分配1个任务。假设一个任务的正常完成时间为Ttask，则在时刻Ttask，9个任务完成并且1个任务落后。因为现在有空闲的资源，调度器将该落后的任务克隆到另一工作机上。因此，作业完成时间将为2Ttask，意味着作业完成时间在最坏情况下延迟了100％。3.7故障处理运行任务时可能遇到数种错误。ZRPC适当地处理它们以确保作业容错性。1.拨号错误(DialingError)。这种错误通常在主控机未能连接远程工作机时发生。此时，任务信息未能发送给工作机，这样，ZRPC只需要设置工作机状态为死机，并重新安排该任务。2.Gluster错误(GlusterError)。工作机将检查任务首要具备的运行环境，例如，分布式文件系统Gluster。当其发现文件系统工作不正常时，其向主控机返回该错误。在这种情况下，任务实际上没有开始，ZRPC只需要重新调度该任务。3.运行时错误(RuntimeError)。其意味着任务运行并且由于错误而退出。ZRPC根据返回的代码判断任务是否成功运行，如果返回的代码不为0，则产生了运行时错误。这是任务的问题，因此ZRPC另外尝试两次，并且如果全都失败了，整个作业失败。4.失去连接错误(ConnectionLostError)。这是最麻烦的错误。其意味着作业已经发送并且在工作机上成功运行，但是主控机失去了与工作机的连接。因此，工作机上的任务状态为未确定。如果ZRPC在另一工作机上重新发起任务，则存在两个相同的进程写同一个文件，由此损坏该文件系统。然而，如果ZRPC不重新运行它，则整个作业被阻碍。本发明实施方式通过设置恢复期来处理这种错误。一方面，在恢复期期间，主控机尝试重新连接丢失的主控机并恢复该作业。另一方面，用户可以决定是否在另一机器上运行作业或维修当前机器。如果在恢复期两个方法都失败了，作业将重新调度到其他机器上。如果过了一段时间，机器恢复并且连接恢复，主控机要求该工作机停止，以避免重复。4.结论由于当前无人驾驶的流行，用于3D重建的数据集大规模增长。本发明的发明人认识到有必要对该领域引进分布式计算架构以解决大规模问题。尽管Hadoop是最广泛使用的大数据处理生态系统，但它不适合于本情况，因为它对应用程序的源代码有太多限制。因此，本发明的发明人建立了ZRPC，一种功能分布式计算系统，用于生产使用。ZRPC成功地解耦了计算架构与硬件资源，并在集群中为用户提供了简单的API以运行其程序。其不仅研发了并发性以提高性能，还允许用户组织集群机器来实现特定目标。这在已有代码几乎不能移植到“新”架构(例如MapReduce、Spark等)的情况下特别有用。ZRPC通过简单的JSONAPI将独立程序传送到分布式计算应用中。尽管产生了重复检查点，但是其实现了数据的可靠性。鲁棒的故障检测器和处理器使集群中作业安全地运行。ZRPC对于小工程和大工程都能减少工程完成时间，提高集群利用率。ZRPC还可适当地扩展，无需中断当前作业。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对
背景技术：
：做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。本领技术人员应当理解，以上所公开的仅为本发明的实施方式而已，当然不能以此来限定本发明之权利范围，依本发明实施方式所作的等同变化，仍属本发明权利要求所涵盖的范围。当前第1页1 2 3 当前第1页1 2 3