CN110874271A - 一种海量建筑图斑特征快速计算方法及系统 - Google Patents
一种海量建筑图斑特征快速计算方法及系统 Download PDFInfo
- Publication number
- CN110874271A CN110874271A CN201911143063.1A CN201911143063A CN110874271A CN 110874271 A CN110874271 A CN 110874271A CN 201911143063 A CN201911143063 A CN 201911143063A CN 110874271 A CN110874271 A CN 110874271A
- Authority
- CN
- China
- Prior art keywords
- task
- data
- tasks
- building
- nodes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/29—Geographical information databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Remote Sensing (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本公开提供了一种海量建筑图斑特征快速计算方法及系统,根据集群节点数量和建筑数据及其他数据的数据量将总的计算任务分解为若干个任务,使集群中的每个处理器均能分配到任务;将各个任务按照规模降序排列加入队列,依次分发至集群中空闲的计算节点,直至所有任务分发完毕;各个计算节点接收任务后,将待计算的特征加入子任务队列,依次分配给节点上的空闲处理器进行并行处理,直至子任务分发完毕,执行分配的子任务,计算相应的建筑特征,并按照节点被分配的建筑数据ID的顺序输出建筑图斑特征计算结果到相应的文本文件;对各子任务的计算结果进行合并,得到最终的建筑图斑特征数据。
Description
技术领域
本公开属于海量地理信息数据快速计算领域,涉及一种海量建筑图斑特征快速计算方法及系统。
背景技术
本部分的陈述仅仅是提供了与本公开相关的背景技术信息,不必然构成在先技术。
随着信息科学的不断发展,GIS数据也逐渐呈现出海量化、实时化的特点,特别是近年来基础测绘数据、地理省情监测数据已经能够实现每年更新一次的频率,对于其中的爆炸式剧增的矢量数据的处理、分析、挖掘的需求越来越迫切,而地理计算、统计分析等工作对计算机的计算性能、计算效率等方面的要求越来越高。ArcGIS作为目前全球范围内应用性能最高的GIS平台,在地理计算、地统计分析、空间分析等方面集成了多种丰富算法,但是ArcGIS地理处理工具的执行过程采用串行排队的方式,不能充分利用高性能多核计算机的全部运算能力,而传统的串行算法已经不能满足日益增加的海量地理数据的处理需求,导致效率低下,特别对于测绘生产单位来说,直接影响工作进度。目前基于ArcGIS平台提高地理处理运算速度的也有一些研究,但是基本停留在对于硬件设备的改进,或是通过改进某个分析工具原有算法,或是通过Python语言的多进程技术相结合模式,仍然局限于单机处理模式。
为了对区域范围内建筑形态进行研究,进一步丰富山东省地理省情监测统计分析成果,需要对全省范围内约数千万建筑图斑数据上百个特征变量进行计算,传统串行排队计算方式显然不适用,现有的方法效率低,速度慢,严重影响计算进度。
发明内容
本公开为了解决上述问题,提出了一种海量建筑图斑特征快速计算方法及系统,本公开能够有效使用现有软硬件提高计算效率,且兼顾时间。
根据一些实施例,本公开采用如下技术方案:
一种海量建筑图斑特征快速计算方法,包括以下步骤:
根据集群节点数量和建筑数据及其他数据的数据量将总的计算任务分解为若干个任务,使集群中的每个处理器均能分配到任务;
将各个任务按照规模降序排列加入队列,依次分发至集群中空闲的计算节点,直至所有任务分发完毕;
各个计算节点接收任务后,将待计算的特征加入子任务队列,依次分配给节点上的空闲处理器进行并行处理,直至子任务分发完毕,执行分配的子任务,计算相应的建筑特征,并按照节点被分配的建筑数据ID的顺序输出建筑图斑特征计算结果到相应的文本文件;
对各子任务的计算结果进行合并,得到最终的建筑图斑特征数据。
作为可选择的实施方式,总的计算任务分解为若干个任务的具体过程包括:
根据总任务的物理线程数,确定初步分组数;
根据数据涉及的各级行政区划个数选择恰当的行政区划级别,使其在初步确定的分组数范围内;
根据任务分组,对对应的行政区划进行裁剪,生成对应的数据和指令。
作为进一步的限定,第一类任务采用单线程,分组数为1;第二类任务采用单机并行,分组数参考该机器的物理线程数的1到10倍,或采用集群并行,分组数参照节点个数的1到10倍;第三类任务采用集群多线程并行,分组数参照总物理线程数的10到100倍。
作为进一步的限定,分组过程中,需要兼顾的原则包括:
a.尽可能将邻近的建筑物划分到同一分组;
b.每组的数据数量在审范围内;
c.尽量通过行政区划边界进行划分分组。
作为可选择的实施方式,任务分发的具体过程包括:
创建任务队列,统计各个任务负责的建筑图斑个数,按照逆序排列,将它们加入任务队列;
监听各计算节点的状态,一旦空闲则从队列中提取任务发送过去,直到任务队列为空。
作为可选择的实施方式,建筑图斑特征计算的具体过程包括:
节点接收分配的任务,如果数据部分是数据查询指令,则执行查询提取数据到本地文件;
创建子任务队列,将各个特征属性的计算指令加入队列,将依赖于同一图层的指令排列在相邻位置;将由前后依赖关系的指令封装为一组加入队列,所有节点使用的初始队列保持一致;
每个处理器执行一个子任务,一旦执行完毕,将结果写入文本文件,文件名以属性名命名以确保互不相同,结果顺序与任务中的建筑图斑保持一致,然后该处理器从子任务队列中提取下一个或者下一组任务,直到所有子任务结束。
作为进一步的限定,在各处理器并行处理过程中,节点上每一个处理器复制基础数据,创建待分析的特征属性队列,采用与任务向各节点分发类似的方式,轮流将队列中的任务分配给空闲的处理器,最后连接所有的计算结果,就得到了该节点分配的这个任务的计算结果;
或,对于有前后依赖关系的属性,合并为一个任务加入队列;
每一个属性或属性组的结果直接写入一个文本文件,统一进行连接,再提交给主节点。
一种海量建筑图斑特征快速计算系统,包括:
任务分解模块,被配置为根据集群节点数量和建筑数据及其他数据的数据量将总的计算任务分解为若干个任务,使集群中的每个处理器均能分配到任务;
主节点,被配置为各个任务按照规模降序排列加入队列,依次分发至集群中空闲的计算节点,直至所有任务分发完毕;接收各子任务的计算结果并进行合并,得到最终的建筑图斑特征数据;
多个计算节点,被配置为接收主节点分发的任务,将待计算的特征加入子任务队列,依次分配给空闲处理器进行并行处理,直至子任务分发完毕,执行分配的子任务,计算相应的建筑特征,并按照节点被分配的建筑数据ID的顺序输出建筑图斑特征计算结果到相应的文本文件,并反馈至主节点。
一种计算机可读存储介质,其中存储有多条指令,所述指令适于由终端设备的处理器加载并执行所述的一种海量建筑图斑特征快速计算方法的步骤。
一种终端设备,包括处理器和计算机可读存储介质,处理器用于实现各指令;计算机可读存储介质用于存储多条指令,所述指令适于由处理器加载并执行所述的一种海量建筑图斑特征快速计算方法的步骤。
与现有技术相比,本公开的有益效果为:
本公开能够解决千万级海量图斑以及上百个特征变量在计算过程中串行排队计算时随着地理要素图斑的增加而效率低下甚者内存溢出崩盘问题,同时解决单个ArcGIS计算时图层锁定导致资源闲置等多个方面的问题,实现在工作局域网内数据分组分发和多用户并行计算。
本公开采用计算机集群+节点多线程的方式进行建筑特征计算。与传统方案相比,可处理的任务规模的制约因素不再是单机性能而是集群规模(主要由节点性能、数量决定),具备了更好的可伸缩性。
本公开优化了任务划分方案及并行处理框架以减少并行框架的资源消耗,同时利用空间数据和操作系统的特点在部分环节上取得超加速比;在处理典型的建筑图斑特征计算任务时可以得到接近于线性的加速比。
本公开节点内各子任务计算结果按照ID顺序进行存储,可以不经过连接(JOIN)以及数值解析(PARSE)操作,直接将原始的数据流合并;并且合并时采用二分法降低时间复杂度;同时并各节点的计算时,采用on-the-fly方式进行准实时追加合并,而不是最终一次性合并,减少耗时。
附图说明
构成本公开的一部分的说明书附图用来提供对本公开的进一步理解,本公开的示意性实施例及其说明用于解释本公开,并不构成对本公开的不当限定。
图1是本公开的流程示意图;
图2是任务规模与处理方式参考曲线图;
图3是数据分发步骤的流程图;
图4是在节点上进行建筑特征计算的流程图;
图5是节点上各子任务计算结果合并的流程图;
图6是节点上子任务计算结果格式与合并方式的示意图;
图7是各节点计算结果合并为最终结果的流程图。
具体实施方式:
下面结合附图与实施例对本公开作进一步说明。
应该指出,以下详细说明都是例示性的,旨在对本公开提供进一步的说明。除非另有指明,本文使用的所有技术和科学术语具有与本公开所属技术领域的普通技术人员通常理解的相同含义。
需要注意的是,这里所使用的术语仅是为了描述具体实施方式,而非意图限制根据本公开的示例性实施方式。如在这里所使用的,除非上下文另外明确指出,否则单数形式也意图包括复数形式,此外,还应当理解的是,当在本说明书中使用术语“包含”和/或“包括”时,其指明存在特征、步骤、操作、器件、组件和/或它们的组合。
一种基于ArcGIS的海量建筑图斑特征快速计算方法,主要关键点在于以下几个方面:
(1)在多处理器计算机集群上进行建筑图斑特征的并行计算,具体为:通过将任务在节点级别进行纵向分配(按照记录分解任务)、在节点内部各处理器上进行横向分配(按照属性分解任务)的方式来进行并行计算;
(2)在任务分组上,针对GIS数据及建筑图斑特征计算任务的特点,采用了基于空间位置的划分方式,将位置临近的数据划归同一组以提高查询及计算效率;
(3)根据集群总的逻辑CPU个数来选择合理的分组数量,提高处理器利用率并压缩任务同步耗时的期望;任务采用按照计算量的期望逆序分发的方式,进一步降低任务的同步时间;
(4)针对空间数据处理与分析操作IO访问较多这一特点,充分利用磁盘缓存来实现加速;
(5)节点内各子任务计算结果按照ID顺序进行存储,可以不经过连接(JOIN)以及数值解析(PARSE)操作,直接将原始的数据流合并;并且合并时采用二分法降低时间复杂度。
(6)合并各节点的计算时,采用on-the-fly方式进行准实时追加合并,而不是最终一次性合并,减少耗时。
具体的,如图1所示,包括以下步骤:
A总任务分解
根据集群节点数量和建筑数据及其他数据的数据量将总的计算任务分解为若干个任务,使集群中平均每个处理器能分配数个任务。每个任务负责计算一部分相邻的建筑图斑的特征,因此只需要用到位于这些建筑数据所处区域的数据。
B任务分发
由主节点将各个任务按照规模降序排列加入队列,依次分发至集群中空闲的计算节点,直至所有任务分发完毕。一个任务由两部分组成,一是计算建筑图斑特征的指令,二是实现计算所需的数据(是原始数据的一个较小的子集)。
C建筑图斑特征计算
各个计算节点接收任务后,将待计算的特征加入子任务队列,依次分配给节点上的空闲处理器进行并行处理,直至子任务分发完毕。子任务包含指令,但不包含数据,因为数据已经在当前计算节点上。如果特征计算需要执行图层编辑操作,则为每个处理器创建一个任务数据中该图层的副本。只读数据不创建副本。
各个处理器执行分配的子任务,计算相应的建筑特征,并按照节点被分配的建筑数据ID的顺序输出计算结果到文本文件。
D子任务结果回传
计算节点执行任务的过程中,一旦获得子任务的计算结果,就对其进行合并。在完成本节点上所有子任务结果合并后,将任务的计算结果回传给主节点。
当节点中处理器数量较多时,可以采用二分法进行合并以减少耗时。
E结果汇总
主节点一旦获得计算节点返回的结果,就对其进行合并。在所有任务完成、任务结果合并后,得到最终的建筑图斑特征数据。
需要说明,主节点也可以作为任务处理节点使用。一般建议选择性能较高的节点作为主节点。处理工具的部署、原始数据预处理、最终结果的使用等步骤不在本发明的核心步骤内,这里不进行讨论。
下面针对每一步进行详细的叙述:
首先是总任务分解步骤:
(1-1)根据总任务的规模大致确定分组数
小型任务采用单线程,分组数为1;中型任务采用单机并行,分组数参考该机器的物理线程数的1到10倍,也可以采用集群并行,分组数参照节点个数的1到10倍;大型任务采用集群多线程并行,分组数参照总物理线程数的10到100倍。
如图2所示,耗时坐标轴为单线程处理的理论耗时,实际上指代的是任务规模。处理方式坐标轴上,单线程指不分组单机单线程处理(一小部分操作GIS会自动优化为多线程);单机并行指的是使用所选计算机的全部物理线程;集群并行指集群每个节点上单线程运行;集群并行+即节点上也使用所有物理线程来处理数据,本方案默认采用这种方式。理论上最佳效费比为单线程执行,因为不会为环境启动、进程同步等花费额外的计算资源,但实际上由于分任务执行对于超过o(n)复杂度的任务能实现超线性加速比,并且更大的总体缓存容量也对提速有很大帮助,故实际上可能并不是最佳效费比。最短耗时则是充分利用并行机制进行加速,并不是简单的任务分组越多越好,需要根据任务大小、任务的重要性、可用资源总量选择合适的分组数。本方案在耗时天级以上的场景中更有优势。
(1-2)根据行政区划确定分组数
除了分组数为1的情况,都需要根据数据涉及的各级行政区划个数选择恰当的行政区划级别,使其在大致确定的分组数范围内,或者尽可能接近该范围。
(1-3)任务生成
根据任务分组,生成对应的数据和指令。对于各个任务指令都是一样的,但是数据要根据分组对应的行政区划进行裁剪。建筑数据仅使用分组对应的行政区划内的部分,其他用于关联的数据仅使用行政区划一个较小的邻域内的部分。
对于基于文件的数据,直接在主节点裁剪;基于数据库的数据则推送数据查询指令而非数据本身。
为了在多个计算节点上并行计算建筑物特征,首先需要对建筑物数据进行分组。进行分组时,要兼顾以下方面:
a.尽可能将邻近的建筑物划分到同一分组
进行周边特征计算时,需要对每一个建筑周边不同半径内的各类数据进行搜索操作,然后对结果的个数、长度、面积等测度进行汇总。这种搜索操作依赖于空间上的INTERSECT算子,属于IO密集型操作,对磁盘性能要求很高。想提高执行效率,就必须尽可能减轻磁盘IO负担。
在建筑数据、搜索目标图层不变的前提下,对任意两个建筑进行邻域搜索操作,不论二者是否相邻,理论上最执行的磁盘IO操作是相同的,并无差异。但实际上当前主流的操作系统(Linux、Windows以及Mac OS)都会尽可能利用剩余内存作为磁盘缓存,如果两个建筑相邻,则邻域搜索要访问的数据也会比较接近,直接从磁盘缓存中查找到的可能性远大于不相邻的情况。
表1列出了常见内、外存储器理论带宽、顺序访问速度、随机访问速度及读写延时的典型值(为便于对比进行了舍入)。在进行大量随机访问时,带宽通常都不能完全发挥,制约因素很大程度上变为IOPS性能和访问延时。因此,一旦磁盘缓存命中,其顺序读写速度视磁盘类型不同可达10到400倍;随机读写性能可以达到数倍至数千倍。在进行特征计算时,大部分磁盘IO集中在随机读取上,此时能否有效利用操作系统的磁盘缓存对任务耗时多少有决定性影响。
表1
由于内存容量通常远小于磁盘容量,而空间数据又比较大,一次性缓存所有数据(或者空间索引)是不现实的。为了有效利用缓存空间,尽可能搜索相邻建筑的周边数据是最合理的方式,这样每次访问的大部分数据都可以从缓存中读取而不是从磁盘中加载。因此,需要尽可能将相邻的建筑物划分至同一分组。
b.每组数据不宜过小
如果每组数据过小,则会增加环境启动及数据合并这些操作的耗时,进而导致总耗时增加。
进行并行处理时,所有任务最终要分配到某个粒度的计算单元上。称这样一种计算单元为最终计算单元:于该计算单元,任务进一步并行化处理的效率不高于串行处理。例如,对于计算密集型任务,最终计算单元为CPU的逻辑核心(对应于一个物理核心或者一个基于超线程技术的虚拟核心),此时已经可以充分发挥硬件的性能,不宜进一步并行,否则任务切换会浪费部分计算资源;对于IO密集型任务,最终计算单元为发挥最高IOPS的并发任务数中的一个任务,使用更多的任务数反而会降低总的IO数,导致计算耗时增加。
假定某最终计算单元上总共分配了n组数据,每组m条,各组数据串行处理(此时再并行并没有额外收益)。假设单条数据处理耗时为t,环境启动耗时为t0,则总耗时为:
T=Ttask+Tenv
Ttask=m·n·t
Tenv=n·t0
其中Ttask为数据处理耗时,Tenv为环境启动耗时。由于任务至少要分为1组,所以Tenv至少为t0。组数n越大,Tenv越大。由于GIS环境启动耗时通常较多,最终计算单元上的数据组数越多,则消耗在Tenv上的计算资源就越多,有效操作的比例也越低。因此Tenv部分的影响无法忽略,应尽可能控制分组数n。
c.每组数据不宜过大
如果每组数据处理耗能够相对准确的预测,则可以根据最终计算单元的效率来进行任务划分,为每个单元分配1组任务即可实现Tenv。不过,进行建筑特征计算时,耗时与很多因素有关,例如自身几何形状的复杂度、要检索的周边目标的密度及复杂度等,我们无法根据先验知识建立耗时预测模型,因此任务组数比较少(即任务粒度比较大时)会带来额外的不利因素。
较大的任务粒度会增加各节点耗时的波动性(如图所示),而并行处理最终要求所有节点进行同步,任务完成时间由最后完成任务的节点决定。如果不同节点完成任务的时间先后差异较大,则进行同步时可能需要更多的等待时间(此时不再是理想的并行处理状态),从而拖累整体进程。最坏的情况下,所有已完工的节点要等待最后一个节点完成刚刚启动的任务,因此理论上同步等待时间的上限是最大的任务在最慢的节点上的耗时(记作Tsync)。为了避免这种风险,需要适当的减小任务粒度。
综上所述,任务分组过少会导致Tsync的期望变大,过多又会导致Tenv过大,并且还有空间上以及关于最终计算单元个数的约束条件,选择折中的近似最优的数据分组方案是整个方案重要的基础组成部分。分组数的数量级应针对任务大小来决定:
a.大型任务
大型任务指运行耗时超过数天的空间计算任务。此时应利用集群多线程执行,任务分组数不低于可用的物理线程数的10倍,不超过物理线程数的100倍,单个任务(单线程)平均耗时的数量级(因为不可能准确估算)不宜低于10分钟。此时,由于每个物理线程平均分配10到100个任务,max(Tsync)的期望已经被控制到较小级别,Tenv占比也很低,可以兼顾效费比接近于最高和耗时最短这两个目标。只有在任务足够大时且采用了合理的分组方案时,才能做到这一点。
b.中型任务
中型任务指的是耗时数十分钟至数天的空间计算任务。此时应视任务量采用单机多线程至集群并行执行,任务分组数不低于集群节点数或单机物理线程数,不超过物理线程总数的10倍。在集群节点上可选择单线程或者多线程执行。此时提高速度的边际成本(即效费比的降低幅度)较高。
c.小型任务
小型任务指的是耗时数分钟至数十分钟的空间计算任务。对于本公开来说,小型任务属于例外情况。虽然采用大中型任务的分组方式充分利用集群资源进行计算仍有望取得一定的效果,但GIS数据处理环境启动时间通常为秒级或更高,此时总的有效操作比例(即效费比,单线程花费的计算资源/实际花费的计算资源)会明显下降,提高速度的边际成本很高。部分情况下并行处理甚至不能带来加速的作用。应视任务需求(即强调效费比还是追求时间最短)采用单线程执行或者单机多线程执行,任务分组数不超过可用的物理线程数。
分组最好是通过行政区划边界进行划分,例如区县/乡镇街道/村居委会。行政区划边界是社会发展过程中形成的一种较强的空间单元,同一行政区划内的建筑、人文社会资源等相似度通常较高聚类效应,对于建筑数据以及计算周边特征所使用的数据这样分组都有利于提高缓存效率。
数据裁剪的计算复杂度不高,但外部存储以及网络IO瓶颈会相对明显。因此分为直接裁剪和推送查询两种,推送查询可以进一步分为顺序执行和并行执行。
使用基于文件的数据时,由主节点采用单线程的方式直接推送数据,多线程可能会导致IO竞争致使总性能下降。使用小型数据库时,主节点只推送查询命令,各节点依次访问数据库,同样是为了避免IO竞争。使用大规模数据库时(例如基于小型机的Oracle数据库或者基于集群的数据库),主节点推送查询指令,各节点并行执行查询获取数据。
如图3所示,任务分发的具体过程包括:
(i)创建任务队列
创建任务队列(先进先出),统计各个任务负责的建筑图斑个数,按照逆序排列,将它们加入任务队列。
(ii)开始任务调度
监听各计算节点的状态,一旦空闲则从队列中提取任务发送过去,直到任务队列为空。
由于各组任务在不同节点上处理所需时间难以准确预估,预先将全套数据分发至各节点也可能带来较多的耗时。为了减轻其影响,可以先按照数据量降序的方式对各组数据排序,然后采用动态分配的方式依次分发。由于任务耗时大体上与建筑图斑数量成正比,先分发数据较多的分组,最后分发数据较少的分组可以起到削峰填谷的作用,节点越多效果越显著。
这种按照任务数据量逆序分发数据的方案是在合理的分组数上的进一步的优化。在同样的分组数下,这一方案能够进一步压低Tsync,提高并行处理的速度和效费比。
在实现中(见附图),任务数据排序后将加入队列,节点也将加入可用节点队列,依次将任务和可用节点从队列中取出进行分配。分配给节点的任务执行完毕后节点重新加入可用节点队列。所有任务执行完毕后,结束数据分发子流程。
建筑图斑特征计算的具体过程包括:
(a)任务接收
节点接收分配的任务,如果数据部分是数据查询指令,则执行查询提取数据到本地文件。
(b)子任务分发
创建子任务队列,将各个特征属性的计算指令加入队列。将依赖于同一图层的指令排列在相邻位置;将由前后依赖关系的指令封装为一组加入队列。所有节点使用的初始队列保持一致。
(c)子任务执行
每个逻辑处理器执行一个子任务。一旦执行完毕,将结果写入文本文件,文件名以属性名命名以确保互不相同。结果顺序与任务中的建筑图斑保持一致。然后从子任务队列中提取下一个或者下一组任务。
建筑图斑特征计算是整个处理过程中最耗时的部分。由于涉及上百个属性,即使每个节点每次只处理一个分组的数据,采用顺序计算的方式也需要很长时间。因此进行属性计算时也要采用并行的方式。
方案考虑了以下方面:
a.最佳线程数
由于周边搜索和特征计算属于偏重计算型的任务,数据缓存后外部存储IO更少,一个节点最佳空间分析线程数等于其物理线程数(即逻辑CPU数),通常是2的整数幂。因此,也需要采用轮询的方式分配任务,尽可能保证有且仅有与逻辑CPU数量相等的分析线程在执行。
b.并行的方式
向各个节点分发的数据是按照记录进行拆分的,这一步整体任务进行了纵向的拆分。对于其中一个节点,不再进一步进行纵向拆分,而是按照要计算的特征进行横向拆分。
采用横向拆分而非纵向拆分的主要原因是为了提高磁盘缓存命中率,磁盘缓存一旦命中就能够提供数倍到数千倍的访问性能,这在实际执行中很重要。由于总共要计算上百个特征属性值,涉及数十组相关数据,如果采用纵向拆分,则处理每一个记录时,都需要轮流访问全套相关数据,但是计算机内存远小于这些数据,缓存命中率会很低。如果采用横向拆分,然后再尽可能同时计算使用同一组数据的属性,缓存命中率会高得多。
需要说明,缓存命中率低不仅会降低IO性能,还会降低处理器的计算性能,因为访问外存、将数据映射到内存、切换虚拟内存页面这些操作都要占用一定数量的计算资源。对于建筑特征计算这种重量级任务,提高缓存命中率在实际执行时可以发挥巨大作用。
采用的并行算法如附图所示,首先给节点上每一个逻辑CPU复制一组必要的数据(什么样的数据需要复制将在后文说明)。然后创建待分析的特征属性队列,采用与任务向各节点分发类似的方式,轮流将队列中的任务分配给空闲的逻辑CPU。最后连接所有的计算结果,就得到了该节点分配的这个任务的计算结果。
队列中的元素一般是一个属性的计算任务,按照所使用的相关文件进行排列以提高缓存效率。对于有前后依赖关系的属性,可以合并为一个任务加入队列。
每一个属性(或属性组)的结果直接写入一个文本文件,最后统一进行连接,再提交给主节点。采用文本文件是为了提高连接效率,原因在后文说明。
c.文件副本策略
ArcGIS在修改一张表时,会锁定其写入权限;数据库可以提供记录级锁定,但仍然有访问冲突甚至死锁的可能。因此,对于需要写入操作才能执行的特征计算,需要创建数据的多个副本,可用副本数至多等于物理线程数,更多不仅浪费空间和时间,还会降低缓存的比例,进而影响速度。
对于只读数据,这里采用的并行算法已经尽可能提高了操作系统磁盘缓存的命中率,可以在很大程度上抵消IO请求过多带来的不利影响,因此只读数据不必创建副本。
属性值的计算结果直接写入不同的文本文件,互不冲突,也没有必要建立副本。
子任务结果回传的具体过程:
(1)结果连接
一旦有子任务完成,则检查是否可以合并,能合并就进行合并,如图5所示。如果数量较多,则使用二分法两两合并提高速度。
可以合并是指,合并完成中间结果或者最终结果中,属性顺序与初始的子任务队列中属性顺序完全一致,不跳过某个属性。
(2)结果回传
合并完当前任务的结果后,将其回传主节点。然后通知主节点当前节点已闲置,准备申请新的任务。
在数据库中,连接操作是时间复杂度很高的操作。不过这里的情况比较特殊,有较大的优化余地。由于节点上的任务是按照属性进行进一步分解,因此每组计算结果的记录条数和ID顺序是一致的,只需要将这些计算结果逐行拼接起来即可。既不用使用ArcGIS中的属性连接工具,也不必使用数据库中的索引和JOIN操作。使用最简单的文本文件就能满足要求,并且效率很高。
图6展示了计算结果的拼接过程。其中id为ID列表,每行一个,与输入的数据一致;a1和b1是计算得到的属性值,顺序也与id中的ID一致。创建id表后,其余各表就不必再包含id属性。将他们拼接起来时,输入文件只需要逐行顺序读取一次,输出文件只需要逐行写入一次,拼接时只需要追加分隔符,连解析字符串的数值都没有必要。
需要注意,为避免串行,属性值计算结果不允许跳行,使用NULL来表示空值,使用ERR表示出错。
如果节点的逻辑处理器数量较多(例如当前较先进的双路服务器有256个逻辑处理器),连接计算结果时也可以采用并行的方式。对于n个属性输出文件,可以分log2n轮进行两两连接。同依次连接相比,时间复杂度由O(n)降低至O(log(n)),空间复杂度则由O(n)增加到O(2n)。
为了避免最终结果合并需要对字段进行排序,这里额外加上了依次连接的约束,从而保证了表结构的一致性。排序需要对数值进行判读,消耗资源远高于直接顺序读取。存在部分子任务完成较慢造成待合并结果累积的可能,因此允许使用二分法进行合并,只要确保各组内部属性顺序与子任务队列一致(实际上所有节点使用的任务队列一样)即可。
计算结果汇总,如图7所示:
不同节点将计算结果回传至主节点后,对其进行合并就可以得到最终所需的结果。如果最终数据存储在文件中,则合并文件。如果采用数据库,则直接将所得的结果插入数据库中的结果表。
由于是记录上的合并,格式一致,合并操作耗时随总建筑数线性增长,复杂度较低(比数据分发还低,因为不需要表内检索)。并且,可以接收数据后即时开始合并,而不是等全部数据接收后才能开始合并。
单纯对于数据合并来说,最坏的情况是所有节点(假设有n个)同时回传最后一组计算结果,此时需要将n组结果追加到最终结果中。需要强调的是,相对于建筑特征提取,数据合并耗时极低,因此这对于建筑特征计算乃至整个任务来说反而是比较理想的情况,因为任务同时结束即Tsync=0。
需要强调的是,该步骤是否采用并行的方式对整体耗时影响相对较小,应当优先保证耗时最多的建筑特征计算步骤的效率。
上述实施例中,数据分组的具体过程还可以替换为:
针对并行计算建筑图斑特征这一任务,同时可以满足空间上邻近、分组数量与并行处理相适配的分组方法。这是判断是否属于本发明的数据分组部分的替代方案的完整条件,不满足该条件的话则不属于替代方案。
其他的自动化的分组方式包括且不仅限于:
不规则三角网(简称TIN,即Triangulated Irregular Network)
根据建筑或其他相关数据、衍生数据的某个或某些几何或非几何属性,作为参考属性值,生成不规则三角网,对空间数据进行划分。
泰森多边形(或voronoi图)
根据建筑或其他相关数据、衍生数据的几何属性,生成泰森多边形,对空间数据进行划分。
Delaunay三角剖分(或Delaunay图)
根据建筑或其他相关数据、衍生数据的几何属性,生成泰森多边形,对空间数据进行划分。
聚类
利用聚类的方法,对空间数据所属范围或者空间数据自身进行划分。
利用街区、片区等非国家标准行政区划空间分割
在国家标准行政区划之外,还有很多组织或个人根据不同的需求定制除了不同的空间分割方式。直接引用这些既有的分割方式对空间数据进行划分。
其他人工或半自动的分组方式包括:
人工绘制边界进行空间分割
手工绘制可用于分割数据的线或者面边界,对空间数据进行划分。
人工直接进行数据划分
利用GIS工具,直接查看空间数据的分布,手工进行选取和分组。
上述自动分组方式与人工相结合的方式
在人工分组的基础上进行自动划分,或者在自动划分的基础上进行人工划分。
而针对并行计算建筑图斑特征这一任务,使用已知性能在同一级别的节点组成的并行集群进行计算,按照任务大小降序排列进行分发属于最优方案。
建筑图斑特征并行计算过程中,可以采用物理CPU核心个数作为最佳线程数
目前大部分处理器(含嵌入式及移动处理器)并不支持超线程之类的技术(即利用少量额外的计算单元将一个物理CPU核心模拟为2到多个逻辑CPU),此时物理CPU个数与逻辑CPU个数是相等的。对于支持超线程技术的处理器,如果存储等性能瓶颈,多个逻辑CPU发挥出的总性能与单个物理CPU是相对接近的。
将没有前后依赖关系的属性分为一组子任务
本方案在节点上采用了横向的任务分解方式,除了有前后依赖的属性作为一个子任务外,其余都是每个属性作为一个子任务,只是为了追求缓存效率将使用同组数据的属性排列在任务队列中相邻的位置。实际上,只要同时满足有前后依赖关系的子任务完成次序正确、使用同组数据的子任务尽可能同时或接近于同时执行这两个条件,将部分没有前后依赖关系的待计算的建筑图斑特征属性放到一组子任务中也是可以的。
连接节点上各组子任务结果时使用其他分组方式
对于待连接的子任务结果数据较多时,本方案使用二分法。实际上采用三分法、四分法以及不等分的方法都是可以的,能够提升结果合并效率。
连接节点上各组子任务结果时使用on-the-fly方法
本方案节点上数据合并算法输入是在该节点上所有子任务的输出。实际实现中可以采用完成一个或一批子任务合并一次结果的on-the-fly的方法进行处理,并不需要等待所有子任务完成,也与二分法无冲突。
节点上各组子任务结果格式微调
为追求最高效率,本方案节点上各组子任务结果以不带ID的文本格式保存。性能接近的替代方案包括:
a.采用二进制或JSON、XML等文本格式保存;
b.使用带有ID的格式;
本方案强调的是各组子任务结果中ID顺序保持一致,其优化作用是避免连接操作。与具体的表结构或存储格式不直接相关。
综上,本公开采用计算机集群+节点多线程的方式进行建筑特征计算。与传统方案相比,可处理的任务规模的制约因素不再是单机性能而是集群规模(主要由节点性能、数量决定),具备了更好的可伸缩性。
对于建筑图斑特征计算任务来说,最大限制因素是计算方案的可伸缩性。与数值计算等领域不同,地理信息行业中尚无成熟的可用于所有常见数据处理与分析业务的分布式并行处理软件。业内最先进的ArcGIS系列软件大多数情况下是以单线程模式运行,部分可以利用单台计算机进行多线程处理,支持集群并行的只有极少数工具(不支持本发明针对的任务)。因此,任务规模越大,数据处理方案的可伸缩性与计算规模之间的矛盾就越显著。尤其是在数据有时效性约束的情况下,例如建筑数据必须定期更新,单机处理的传统方案处理大规模数据时计算完毕前已经大幅度失真,不具备事实上的可行性。并且,这是在假设单机能够处理的前提下。当建筑数量达到千万级时(典型的任务规模),ArcGIS现有工具已经无法处理图层连接和邻域搜索度量操作。其原因可能是数据量过大导致不得不频繁使用虚拟内存技术引起了磁盘IO竞争导致性能锐减,以及32位版软件自身内存访问限制等。使用本公开可以突破这种限制。
因此,对于建筑图斑特征计算来说,可伸缩性不仅关系到能够应对的任务规模或者处理的速度,还关系到任务本身的可行性。这方面的改进十分关键。
本公开在处理典型的建筑图斑特征计算任务时可以得到接近于线性的加速比。
在并行计算领域,线性加速比是理想的结果。根据阿姆达尔定律,采用n个子任务进行并行处理时,理论上加速比不高于n,串行操作比例越高,加速比越低。在任务规模恒定的前提下,达到最佳处理线程数之后,随着处理线程数的进一步增加,任务分发、通信、同步、结果汇总等具备一定串行执行特征的框架性操作在整个任务中占比逐渐提升,并行的边际效益会迅速下降,实际的加速比曲线会越来越偏离(低于)理想值(即线形加速比)。
不过,典型的建筑图斑特征计算场景的任务规模并不小。该问题可以抽象为:给定一个含有m条记录的建筑图层,与x个图层进行空间连接,对每栋建筑y种邻域内的对象进行测度,得到n种度量值。以国土测绘系统内的中等规模的地级市数据为例,保守估计m>100万,x>10,y>3,n>100。如果为省级数据分析,则m>1000万。如果为全国数据处理,则m>3亿。假设每个属性长度为4到8字节,仅计算结果大小就达到GB到TB数量级。而计算过程又涉及高计算复杂度、高IO访问量的周边搜索与特征度量操作,任务规模的下限就已经比较高。相对于普通计算机集群来说,任务规模远远大于节点数量,有利于减缓加速比的衰减。
本公开进一步优化了任务划分方案及并行处理框架以减少并行框架的资源消耗,同时利用空间数据和操作系统的特点在部分环节上取得超加速比,最终实现接近于线性的加速比。
本公开不仅考虑了处理的速度,还考虑了效费比。
并行处理是有代价的,任务分发、通信、同步、结果回传和合并都需要消耗额外的计算资源。目前集群一般通过虚拟化技术实现共享,因此在满足需求的前提下,应当节约计算资源以免影响其他计算任务的执行。即使是不考虑成本的独占集群,压缩额外的计算资源耗费也意味着减少任务耗时,这一点十分重要。
假设并行计算可以取得线性的加速比,且没有环境启动与销毁、任务同步、数据合并等并行处理带来的额外开销。这是一种理想化的状况,称其效费比为最高效费比。本公开中,采用了一系列优化方案(详见技术方案说明部分)减小额外开销的资源占用比,此外缓存的充分利用也有助于压缩IO所需要的计算资源与时间(同时意味着节约电力消耗、减少设备折旧),在大规模并行的前提下可以趋近最高的效费比。
本领域内的技术人员应明白,本公开的实施例可提供为方法、系统、或计算机程序产品。因此,本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本公开是参照根据本公开实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅为本公开的优选实施例而已,并不用于限制本公开,对于本领域的技术人员来说,本公开可以有各种更改和变化。凡在本公开的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本公开的保护范围之内。
上述虽然结合附图对本公开的具体实施方式进行了描述,但并非对本公开保护范围的限制,所属领域技术人员应该明白,在本公开的技术方案的基础上,本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本公开的保护范围以内。
Claims (10)
1.一种海量建筑图斑特征快速计算方法,其特征是:包括以下步骤:
根据集群节点数量和建筑数据及其他数据的数据量将总的计算任务分解为若干个任务,使集群中的每个处理器均能分配到任务;
将各个任务按照规模降序排列加入队列,依次分发至集群中空闲的计算节点,直至所有任务分发完毕;
各个计算节点接收任务后,将待计算的特征加入子任务队列,依次分配给节点上的空闲处理器进行并行处理,直至子任务分发完毕,执行分配的子任务,计算相应的建筑特征,并按照节点被分配的建筑数据ID的顺序输出建筑图斑特征计算结果到相应的文本文件;
对各子任务的计算结果进行合并,得到最终的建筑图斑特征数据。
2.如权利要求1所述的一种海量建筑图斑特征快速计算方法,其特征是:总的计算任务分解为若干个任务的具体过程包括:
根据总任务的物理线程数,确定初步分组数;
根据数据涉及的各级行政区划个数选择恰当的行政区划级别,使其在初步确定的分组数范围内;
根据任务分组,对对应的行政区划进行裁剪,生成对应的数据和指令。
3.如权利要求1所述的一种海量建筑图斑特征快速计算方法,其特征是:第一类任务采用单线程,分组数为1;第二类任务采用单机并行,分组数参考该机器的物理线程数的1到10倍,或采用集群并行,分组数参照节点个数的1到10倍;第三类任务采用集群多线程并行,分组数参照总物理线程数的10到100倍。
4.如权利要求1所述的一种海量建筑图斑特征快速计算方法,其特征是:分组过程中,需要兼顾的原则包括:
a.尽可能将邻近的建筑物划分到同一分组;
b.每组的数据数量在审范围内;
c.尽量通过行政区划边界进行划分分组。
5.如权利要求1所述的一种海量建筑图斑特征快速计算方法,其特征是:任务分发的具体过程包括:
创建任务队列,统计各个任务负责的建筑图斑个数,按照逆序排列,将它们加入任务队列;
监听各计算节点的状态,一旦空闲则从队列中提取任务发送过去,直到任务队列为空。
6.如权利要求1所述的一种海量建筑图斑特征快速计算方法,其特征是:建筑图斑特征计算的具体过程包括:
节点接收分配的任务,如果数据部分是数据查询指令,则执行查询提取数据到本地文件;
创建子任务队列,将各个特征属性的计算指令加入队列,将依赖于同一图层的指令排列在相邻位置;将由前后依赖关系的指令封装为一组加入队列,所有节点使用的初始队列保持一致;
每个处理器执行一个子任务,一旦执行完毕,将结果写入文本文件,文件名以属性名命名以确保互不相同,结果顺序与任务中的建筑图斑保持一致,然后该处理器从子任务队列中提取下一个或者下一组任务,直到所有子任务结束。
7.如权利要求6所述的一种海量建筑图斑特征快速计算方法,其特征是:在各处理器并行处理过程中,节点上每一个处理器复制基础数据,创建待分析的特征属性队列,采用与任务向各节点分发类似的方式,轮流将队列中的任务分配给空闲的处理器,最后连接所有的计算结果,就得到了该节点分配的这个任务的计算结果;
或,对于有前后依赖关系的属性,合并为一个任务加入队列;
每一个属性或属性组的结果直接写入一个文本文件,统一进行连接,再提交给主节点。
8.一种海量建筑图斑特征快速计算系统,其特征是:包括:
任务分解模块,被配置为根据集群节点数量和建筑数据及其他数据的数据量将总的计算任务分解为若干个任务,使集群中的每个处理器均能分配到任务;
主节点,被配置为各个任务按照规模降序排列加入队列,依次分发至集群中空闲的计算节点,直至所有任务分发完毕;接收各子任务的计算结果并进行合并,得到最终的建筑图斑特征数据;
多个计算节点,被配置为接收主节点分发的任务,将待计算的特征加入子任务队列,依次分配给空闲处理器进行并行处理,直至子任务分发完毕,执行分配的子任务,计算相应的建筑特征,并按照节点被分配的建筑数据ID的顺序输出建筑图斑特征计算结果到相应的文本文件,并反馈至主节点。
9.一种计算机可读存储介质,其特征是:其中存储有多条指令,所述指令适于由终端设备的处理器加载并执行权利要求1-7中任一项所述的一种海量建筑图斑特征快速计算方法的步骤。
10.一种终端设备,其特征是:包括处理器和计算机可读存储介质,处理器用于实现各指令;计算机可读存储介质用于存储多条指令,所述指令适于由处理器加载并执行权利要求1-7中任一项所述的一种海量建筑图斑特征快速计算方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911143063.1A CN110874271B (zh) | 2019-11-20 | 2019-11-20 | 一种海量建筑图斑特征快速计算方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911143063.1A CN110874271B (zh) | 2019-11-20 | 2019-11-20 | 一种海量建筑图斑特征快速计算方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110874271A true CN110874271A (zh) | 2020-03-10 |
CN110874271B CN110874271B (zh) | 2022-03-11 |
Family
ID=69717201
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911143063.1A Active CN110874271B (zh) | 2019-11-20 | 2019-11-20 | 一种海量建筑图斑特征快速计算方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110874271B (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111858821A (zh) * | 2020-07-27 | 2020-10-30 | 平安科技(深圳)有限公司 | 空间分析任务的处理方法、装置、计算机设备和存储介质 |
CN112363821A (zh) * | 2021-01-12 | 2021-02-12 | 湖南大学 | 一种计算资源调度方法、装置及计算机设备 |
CN112667159A (zh) * | 2020-12-25 | 2021-04-16 | 深圳创新科技术有限公司 | 一种基于纠删码的数据并行重构方法及系统 |
CN114021969A (zh) * | 2021-11-04 | 2022-02-08 | 中国安全生产科学研究院 | 一种涉农企业安全生产风险指数分析系统 |
WO2023241740A1 (zh) * | 2022-06-15 | 2023-12-21 | 顺丰科技有限公司 | 计算任务的执行方法及装置 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101226557A (zh) * | 2008-02-22 | 2008-07-23 | 中国科学院软件研究所 | 一种高效的关联主题模型数据处理方法及其系统 |
CN102541640A (zh) * | 2011-12-28 | 2012-07-04 | 厦门市美亚柏科信息股份有限公司 | 一种集群gpu资源调度系统和方法 |
US20130081053A1 (en) * | 2011-09-23 | 2013-03-28 | Elwha LLC, a limited liability company of the State of Delaware | Acquiring and transmitting tasks and subtasks to interface devices |
CN103955400A (zh) * | 2014-04-17 | 2014-07-30 | 国网宁夏电力公司 | 一种电力系统中并行计算的在线校核方法 |
CN104239144A (zh) * | 2014-09-22 | 2014-12-24 | 珠海许继芝电网自动化有限公司 | 一种多级分布式任务处理系统 |
CN107729138A (zh) * | 2017-09-14 | 2018-02-23 | 北京天耀宏图科技有限公司 | 一种高性能分布式矢量空间数据的分析方法和装置 |
CN109145051A (zh) * | 2018-07-03 | 2019-01-04 | 阿里巴巴集团控股有限公司 | 分布式数据库的数据汇总方法及装置和电子设备 |
CN110196773A (zh) * | 2019-04-24 | 2019-09-03 | 中国电力科学研究院有限公司 | 统一调度计算资源的多时间尺度安全校核系统及方法 |
-
2019
- 2019-11-20 CN CN201911143063.1A patent/CN110874271B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101226557A (zh) * | 2008-02-22 | 2008-07-23 | 中国科学院软件研究所 | 一种高效的关联主题模型数据处理方法及其系统 |
US20130081053A1 (en) * | 2011-09-23 | 2013-03-28 | Elwha LLC, a limited liability company of the State of Delaware | Acquiring and transmitting tasks and subtasks to interface devices |
CN102541640A (zh) * | 2011-12-28 | 2012-07-04 | 厦门市美亚柏科信息股份有限公司 | 一种集群gpu资源调度系统和方法 |
CN103955400A (zh) * | 2014-04-17 | 2014-07-30 | 国网宁夏电力公司 | 一种电力系统中并行计算的在线校核方法 |
CN104239144A (zh) * | 2014-09-22 | 2014-12-24 | 珠海许继芝电网自动化有限公司 | 一种多级分布式任务处理系统 |
CN107729138A (zh) * | 2017-09-14 | 2018-02-23 | 北京天耀宏图科技有限公司 | 一种高性能分布式矢量空间数据的分析方法和装置 |
CN109145051A (zh) * | 2018-07-03 | 2019-01-04 | 阿里巴巴集团控股有限公司 | 分布式数据库的数据汇总方法及装置和电子设备 |
CN110196773A (zh) * | 2019-04-24 | 2019-09-03 | 中国电力科学研究院有限公司 | 统一调度计算资源的多时间尺度安全校核系统及方法 |
Non-Patent Citations (2)
Title |
---|
HUI ZHAO 等: "Prediction-Based and Locality-Aware Task Scheduling for Parallelizing Video Transcoding Over Heterogeneous MapReduce Cluster", 《IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY 》 * |
王宇新 等: "一种基于两级DAG模型的MapReduce工作流异构调度算法", 《计算机工程与科学》 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111858821A (zh) * | 2020-07-27 | 2020-10-30 | 平安科技(深圳)有限公司 | 空间分析任务的处理方法、装置、计算机设备和存储介质 |
WO2021139488A1 (zh) * | 2020-07-27 | 2021-07-15 | 平安科技(深圳)有限公司 | 空间分析任务的处理方法、装置、计算机设备和存储介质 |
CN111858821B (zh) * | 2020-07-27 | 2024-03-29 | 平安科技(深圳)有限公司 | 空间分析任务的处理方法、装置、计算机设备和存储介质 |
CN112667159A (zh) * | 2020-12-25 | 2021-04-16 | 深圳创新科技术有限公司 | 一种基于纠删码的数据并行重构方法及系统 |
CN112363821A (zh) * | 2021-01-12 | 2021-02-12 | 湖南大学 | 一种计算资源调度方法、装置及计算机设备 |
CN114021969A (zh) * | 2021-11-04 | 2022-02-08 | 中国安全生产科学研究院 | 一种涉农企业安全生产风险指数分析系统 |
WO2023241740A1 (zh) * | 2022-06-15 | 2023-12-21 | 顺丰科技有限公司 | 计算任务的执行方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN110874271B (zh) | 2022-03-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110874271B (zh) | 一种海量建筑图斑特征快速计算方法及系统 | |
Khorasani et al. | Scalable simd-efficient graph processing on gpus | |
US9619430B2 (en) | Active non-volatile memory post-processing | |
CA2963088C (en) | Apparatus and method for scheduling distributed workflow tasks | |
WO2021254135A1 (zh) | 任务执行方法及存储设备 | |
CN105069149B (zh) | 一种面向结构化列式数据的分布式并行数据导入方法 | |
US9250979B2 (en) | Asynchronous grace-period primitives for user-space applications | |
US11487435B1 (en) | System and method for non-volatile memory-based optimized, versioned, log-structured metadata storage with efficient data retrieval | |
US9477710B2 (en) | Isolating resources and performance in a database management system | |
US9195599B2 (en) | Multi-level aggregation techniques for memory hierarchies | |
US11093459B2 (en) | Parallel and efficient technique for building and maintaining a main memory, CSR-based graph index in an RDBMS | |
CN107329982A (zh) | 一种基于分布式列式存储的大数据并行计算方法及系统 | |
CN106354729B (zh) | 一种图数据处理方法、装置和系统 | |
CN102231121B (zh) | 基于内存映射的大数据文件快速并行提取方法 | |
WO2012060889A1 (en) | Systems and methods for grouped request execution | |
Humbetov | Data-intensive computing with map-reduce and hadoop | |
CN104778077B (zh) | 基于随机和连续磁盘访问的高速核外图处理方法及系统 | |
US10073648B2 (en) | Repartitioning data in a distributed computing system | |
You et al. | Spatial join query processing in cloud: Analyzing design choices and performance comparisons | |
Wang et al. | Distributed storage and index of vector spatial data based on HBase | |
Lu et al. | TridentKV: A read-optimized LSM-tree based KV store via adaptive indexing and space-efficient partitioning | |
CN109918450A (zh) | 基于分析类场景下的分布式并行数据库及存储方法 | |
CN106406762A (zh) | 一种重复数据删除方法及装置 | |
CN108132834A (zh) | 多级共享高速缓冲存储器架构下的任务分配方法和系统 | |
Henzinger et al. | Scheduling large jobs by abstraction refinement |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |