CN110308984B - 一种用于处理地理分布式数据的跨集群计算系统 - Google Patents
一种用于处理地理分布式数据的跨集群计算系统 Download PDFInfo
- Publication number
- CN110308984B CN110308984B CN201910360062.6A CN201910360062A CN110308984B CN 110308984 B CN110308984 B CN 110308984B CN 201910360062 A CN201910360062 A CN 201910360062A CN 110308984 B CN110308984 B CN 110308984B
- Authority
- CN
- China
- Prior art keywords
- cluster
- data
- global
- master node
- task
- 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.)
- Active
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
- 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/5061—Partitioning or combining of resources
- G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
Abstract
一种用于处理地理分布式数据的跨集群计算的系统,包括有三层的集群管理框架,包括全局主节点‑‑集群主节点‑‑从节点,全局主节点负责管理所有的集群主节点,每个集群主节点则负责管理集群内部的从节点,使用应用提交客户端向全局主节点提交应用程序时,全局主节点会选择一个其管理的集群主节启动全局驱动器,所述全局驱动器启动成功后向全局主节点注册全局应用描述,全局主节点根据描述在各个集群主节点启动集群驱动器,集群驱动器启动成功后,向集群主节点注册集群应用描述,集群主节点再根据描述在各个内部从节点启动执行器,全部启动成功后,由全局驱动器开始任务分发和数据交换等来完成一个应用的执行。
Description
技术领域
本发明涉及一种跨集群计算方系统,尤其涉及用于处理地理分布式数据的跨集群计算系统。
背景技术
地理分布式数据是指那些由不同地理位置的集群所生成的数据,这一类型数据往往具有类似的格式,可以统一处理。地理分布式数据随集群提供的服务持续生成,无论是累积的历史数据量,还是新数据的生成速度都非常大。
地理分布式数据的产生通常有两个原因:1,许多组织在多个国家有业务,并在全球运营多个数据中心,如大型跨国公司为提供最佳的服务体验,往往在多个国家和区域就近部署服务集群。即使在一个国家,数据也可能分布在不同的系统和地点,如同一个国家的某个银行的多个支行;2,一个组织可能倾向于使用多个公有或私有云来增加可靠性,安全性和处理能力。
地理分布式数据的处理有多个场景。例如,一个生物信息学应用需要分析存储在不同实验室和国家的基因组数据来追踪流行疾病的源头,一个气候科学应用需要分析全球各个国家气象站存储的气象数据来模拟地理气候演变,一个服务器监视应用需要分析全球各个区域服务器的日志数据来提供运行状态报告。还有更多类似的应用案例,像传感器网络,股票交易,社交网络应用,分布式摄像机的视频流等。这一类处理应用有相同的特点:1,数据是地理分布的,且数据量巨大,移动会产生大量的广域网带宽成本;2,因为安全、隐私、区域政策、数据敏感等因素,限制原始数据跨国或跨区域的移动;3,大多数的分析任务(Task)都只需要很小的一部分原始数据来生成最后的输出。
现有技术对地理分布式数据的处理有三种方法:方法1,把分布在各个集群上的数据全部拉取到一个集群上,再使用成熟的大数据处理框架,如开源的大数据项目Hadoop、Spark来对所有的数据进行处理,然而在跨国家或跨区域移动原始数据往往是法律禁止的,即使这些数据允许移动,通过广域网汇总所有集群的数据会带来巨大的带宽成本,即使带宽成本在能承受的范围内,这些数据本身可能是动态持续快速产生的,则可能需要多次移动数据,用此种方法只适用于数据大小固定、数据量不大也不敏感的数据处理。
方法2,在每个集群上搭建大数据处理框架,针对具体的业务逻辑写一个应用,将这个应用发送到各个集群上去运行,再将数据处理的结果拉取到一个集群,再写另一个应用处理这些汇总的结果数据来得到最后的输出。此种方法的问题在于,当业务逻辑复杂时,可能需要编写多个应用,并配合额外的调度系统来调度执行这些应用。例如,要获取一个服务的用户总数,需要先在各个集群上统计此地区的用户数,再把这些数据汇总到一个集群再计算总和。用户总数就是一个全局量,每个全局量的获取都需要2个应用的执行。这个方案只适用于简单的业务逻辑编写。
方法3,通过把多个集群的计算节点在网络层通过隧道协议连通,将所有集群的所有计算节点连成一个整体,在这个整体上部署成熟的大数据框架,如分布式文件系统(HDFS),分布式计算框架(MapReduce、Spark),分布式资源调度系统(Yarn)等。然而多个集群并不能完全视为一个巨大的集群,集群内的网络为局域网,高速低延迟且各向同性,集群间的网络为广域网,低速高延迟且各向异性。当前成熟的大数据框架本身是为单集群设计的,并没有为这种特殊的网络性质做优化,在具体的数据处理中也不够高效。
发明内容
本发明提出一种用于处理地理分布式数据的跨集群计算系统,其具有有三层的集群管理框架:全局主节点(GlobalMaster)--集群主节点(SiteMaster)--从节点(Worker)。在这种三层架构中,全局主节点不再能“看见”集群的内部的从节点,它与集群主节点联合进行资源分配。
本发明有如下技术效果:一、不需要大规模地汇总原始数据,而是将任务(Task)分发到集群本地去处理数据,这样可以极大地减少跨集群的数据传输,进而减少带宽成本;二、不是基于应用而是基于任务来调度的,用户通过写一个应用程序来完成全部的业务逻辑,本身不需要配合额外的调度系统;三、能区分不同集群,并针对不同集群间带宽的不同高效地进行任务调度,来极大地减少整体任务的执行时间。整体上,通过新的框架屏蔽了多集群的物理环境,使用户可以像写单集群应用一样编写程序。
附图说明
图1为本发明的集群管理框架图。;
图2为本发明的带宽检测流程;
图3为本发明采用三层的任务分发结构;
图4为一实施例的多集群环境下的混洗过程;
图5为本发明的数据混洗流程;
图6为本发明RDD转换图切分为阶段的关系图;
图7为一实施例统计所有集群中的字母个数的流程图;
图8为本发明的内部聚合图;
图9为一实施例中调度算法的流程图;
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
本发明提出一种用于处理地理分布式数据的跨集群计算系统,其具有有三层的集群管理框架:全局主节点(GlobalMaster)--集群主节点(SiteMaster)--从节点(Worker)。全局主节点(GlobalMaster)负责管理所有的集群主节点(SiteMaster),而每个集群的主节点(SiteMaster)则负责管理集群内部的从节点(Worker)。当使用应用提交客户端向全局主节点(GlobalMaster)提交应用程序时,全局主节点(GlobalMaster)会从其管理的集群主节点(SiteMaster)选择一个来启动全局驱动器(GlobalDriver),选择标准是主节点的空闲CPU和内存容量满足应用要求。全局驱动器(GlobalDriver)启动成功后会向全局主节点(GlobalMaster)注册全局应用描述,后者根据描述在各个集群主节点(SiteMaster)启动集群驱动器(SiteDriver)。集群驱动器启动成功后,会向集群主节点(SiteMaster)注册集群应用描述,后者再根据描述在各个内部从节点(Worker)启动执行器(Executor)。全部启动成功后,由全局驱动器(GlobalDriver)开始任务分发和数据交换等来完成一个应用的执行。由上可见,在这种三层架构中,全局主节点(GlobalMaster)不再能“看见”集群的内部的从节点(Worker),整个集群被抽象为一个主节点(SiteMaster),其负责管理集群内部的操作。如图1所示为三层架构下的集群管理框架图。
高效的任务调度算法需要依赖对集群间带宽的实时测量。在带宽监测上,采用了带宽监测工具bwctl和nuttcp两个工具。
bwctl包装了iperf,traceroute,owamp和一些其他测量工具,联系远程系统和本地系统上的bwctld进程,并请求这些守护进程在所述进程之间执行特定的iperf测试。
Nuttcp是一个网络性能测量工具,通过将内存缓冲区从源系统跨越网络传输到目标系统来确定网络的吞吐量,或者传输指定时间间隔的数据,或者传输指定数量的字节。主要用于测量网络链路的带宽和延迟。
bwctl通过发送命令给各节点的bwctld进程,在参数中指定要测量的IP地址列表。bwctld收到测量请求后,向IP地址列表中所有的节点的bwctld进程发送测量指令。bwctld通过调用本地的nuttcp命令进行任意节点间的带宽和延迟测量,并将测量结果数据发送给发起测量的节点,流程如图2所示。
本发明在应用的执行过程中采用三层的任务(Task)分发结构,全局驱动器(GlobalDriver)--集群驱动器(SiteDriver)--执行器(Executor),流程如图3所示。
集群驱动器负责本集群的任务的分发、监控和结果收集。在具体的任务分发上,特别是第一步,新的框架采用新的分发机制,即一次性将合适的任务打包分发到集群驱动器,再由集群驱动器根据集群的资源空闲情况,将任务一个个分发给执行器(Executor)去执行。这种新的一次性任务分发机制可以避免在集群间产生大量的跨集群通信,进而减少在任务分发上消耗的时间。
标准Spark以宽依赖将RDD转换图切分为“阶段”(Stage)的有向无环图图(DAG),此处指以Stage为节点,以Stage间依赖为边,构成的有向无环图,所述RDD为Spark引入的数据抽象概念,表示弹性分布式数据集。Shuffle操作分为两个阶段,shuffle read和shufflewrite。所谓shuffle操作指集群中的某个节点从其余所有节点拉取部分数据的过程。每个“阶段”的任务(Task)都要以shuffle read为起始,中间进行聚合和计算,再以shufflewrite为结束。任务在shuffle read时,会直接从其余所有执行器(Executor)上拉取用于本次任务的分区数据,这就是在批计算中所谓的数据“混洗”(Shuffle)。数据“混洗”(Shuffle)依赖于执行器间的连接,即任意一个执行器跟其余所有执行器连接,执行器之间构成全连通网络。
从连通性角度看,多集群环境下,任意集群内部是全连通的,任意集群之间也是全连通的,但是,一个集群的内部节点与另一个集群的内部节点并不直接连通。跨集群的内部节点连通性是最大的问题,所有的计算任务(Task)都是在内部节点执行的,所有的计算数据都是存储在内部节点的。非全连通性导致计算任务(Task)无法直接分发,导致计算数据无法直接交换。
Spark的数据“混洗”(Shuffle)是通过执行器(Executor)中的块传输服务(BlockTransferService)模块完成的,它同时是客户端(Client)和(服务器(Server),即任意执行器可以向任意执行器请求数据传输。在多集群环境下,可以在集群驱动器(SiteDriver)中运行一个块传输服务模块,并通过此模块完成跨集群的数据代理传输,即从一个集群的内部节点传输到另一个集群的内部节点。如图4所示为一实施例的多集群环境下的混洗过程,集群1执行的任务(Task)要处理的分区为0和1,则可以通过集群驱动器向集群2的集群驱动器注册这一信息,则集群2将分区3、4、5数据对应的分片0、1进行数据合并后再传输给集群1。通过这种方式,在一次数据“混洗”(Shuffle)中,每个集群之间只会有一次数据传输。
考虑到任务(Task)在从全局驱动器(GlobalDriver)到集群驱动器(SiteDriver)分发时是打包分发的,每个集群知道自己需要执行的任务集(TaskSet)。根据数据的“混洗”(Shuffle)机制,任务(Task)分发决定了数据的移动,因此,每个集群可以将其余集群中属于自己要处理的那部分数据一次性拉取过来,而不是每个任务都拉取一次。
本发明采用的数据“混洗”(Shuffle)方法,所述数据“混洗”方法在集群内进行一次数据聚合重点是从分发的任务(Task)中抽象聚合函数,再在集群间进行数据“混洗”,以此来减少数据传输量。在进行集群间数据“混洗”传输前,先在集群内进行一次分区数据聚合。本发明的数据混洗流程如图5所示。
内部的数据聚合并不是简单地将不同分区的相同分片的数据拼接在一起,而是将所有数据应用某种聚合函数来得到结果。这个聚合操作需要启动一个任务(Task)来进行,且这个任务不同于在任务分发中分发到本集群的任务。为了保证计算结果的正确性,并不能简单地将分发的任务执行两次。
标准Spark的一个RDD表示一次计算转换,如简单的对每个元素加1,对每个元素执行过滤等,也有一些操作需要跨分区进行数据“混洗”(Shuffle),如reduceByKey。标准Spark将RDD转换图切分为“阶段”(Stage)的有向无环图(DAG)图,再以“阶段”的每个分区为任务(Task)进行执行。本发明中RDD转换图切分为阶段的关系如图6所示。
一个Stage由多个RDD构成,数据总是从第一个RDD(入口,左侧)“流向”最后一个RDD(出口,右侧)。“入口”RDD负责读取和聚合数据,“出口”RDD则负责将处理完的数据写入磁盘。一个Task是指一个分区的数据从一个Stage的“入口”“流向”“出口”,被这个Stage的所有RDD所表示的计算一个个处理。通常可以将“入口”RDD进行的数据读取和计算转换视为一个Task的reduce部分,而将之后所有RDD进行的计算转换视为map部分。在多集群环境下,集群内部进行的数据聚合应该只包含Task的reduce部分,而不包含map部分。如图7所示,每个集群的数据为字母(有重复)及其个数(单位千),任务是统计所有集群中的字母个数(单位个),最简单的方式就是每个集群统计一遍,再总的统计一遍,最后将个数乘以1000即可。此过程中,合并相同字母个数即为reduce,因为原始数据的个数单位为千,将原始个数乘以1000则为map。在对每个集群的数据聚合时,只能执行reduce部分,不能执行map部分,否则会导致对相同的数据执行两次map,得到错误结果。标准Spark的API在生成“入口”RDD时,要求传递给API的函数为幂等的,即执行多次函数不会影响最终结果。而图8则为本发明的内部聚合图。
标准Spark的任务(Task)可以视为由两个部分构成:reduce和map。而两层数据“混洗”(Shuffle)中间的数据聚合,执行的是任务的reduce部分,而不是map部分。reduce部分是幂等的,执行多次并不会改变结果,而map则不是。
任务的执行时间=数据传输时间+数据处理时间。要减少应用的执行时间,就要减少这两个时间消耗。
标准Spark主要部署在单个集群上,节点与节点间相互连通,共享一个局域网。局域网有着带宽高,延迟低,各向同性的特点。也因此,标准Spark的任务(Task)调度只考虑数据在各节点的分布,尽量将任务分发给数据量大的节点,这样在数据“混洗”(Shuffle)时从其余节点拉取的数据量就相对较小,在相同带宽下数据的传输时间就少,从而加快作业的执行。但在多集群环境下,集群间共享的是广域网,彼此间的带宽、延迟并不相同,数据的传输时间除了跟拉取的数据量有关,也跟传输数据的链路带宽有关。
标准Spark的每个应用的每个执行器(Executor)代表的资源是固定的,有着相同的CPU核心数和内存大小。任务的执行时间只跟其处理的数据量有关(严格说,也跟具体节点的CPU和内存规格有关)。但在多集群环境下,资源分配是每个集群独立进行的,一个应用在不同的集群上使用的计算资源(CPU/Mem)并不相同。则任务的执行时间除了跟数据量有关外,也跟能使用的计算资源有关。
新框架的任务调度要综合考虑数据分布、带宽分布和计算资源分布,其负责决定要在哪个云上执行哪些任务,每个任务对应处理一个分区。一实施例中,调度算法的输入和输出如图9所示。任务(Task)将在CloudA上执行,因此,将从CloudB上拉取一部分数据。从拉取数据到处理完数据的时间消耗为:
costAB=costtAB+costcAB
其中,costAB为总过程所花的时间,包含两部分:costtAB为数据从集群B到A的网络传输时间,costcAB数据在集群A上的处理时间。
数据在集群A的处理时间由数据大小dataSizeB和计算资源M(cpu,mem)来表示,M(cpu,mem)为计算数计算CPU核和内存容量资源的量化函数。
costAB为分布在集群B上的数据的传输和处理所消耗的时间,则当任务(Task)在集群A上执行时,分布在其余集群的全部数据的传输处理的总时间为
则来自除CloudA外的所有集群的总时间成本为:
来自不同集群的数据是并行拉取的,因此传输时间只取最大值。只有所有数据都拉取结束后,才能进行数据处理,因此处理时间为所有值的和。
对此任务(Task)计算出其在每个集群的时间成本,其中时间消耗最小的即为最佳的执行位置。
计算出所有任务(Task)的最佳执行集群,反过来,每个集群将要执行的任务(Task)子集就是确定的。根据这种划分,GlobalDriver就可以将一个“阶段”(Stage)的所有任务(Task)全部分发给所有集群。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (2)
1.一种用于处理地理分布式数据的跨集群计算的系统,其特征在于,其包括有三层的集群管理框架,包括全局主节点---集群主节点---从节点,全局主节点负责管理所有的集群主节点,每个集群主节点则负责管理集群内部的从节点,使用应用提交客户端向全局主节点提交应用程序时,全局主节点会选择一个其管理的集群主节点启动全局驱动器,所述全局驱动器启动成功后向全局主节点注册全局应用描述,全局主节点根据全局应用描述在各个集群主节点启动集群驱动器,集群驱动器启动成功后,向集群主节点注册集群应用描述,集群主节点再根据集群应用描述在各个从节点启动执行器,启动成功后,由全局驱动器开始任务分发和数据交换完成一个应用的执行;所述系统使用三层架构的任务分发机制,所述任务分发机制为一次性将任务打包分发到集群驱动器,再由集群驱动器根据集群的资源空闲情况,将任务逐个分发给执行器去执行;所述系统在进行集群间数据混洗操作前,先在集群内进行分区数据聚合,而不执行map部分,所述数据聚合方式为执行的是任务的reduce部分,所述集群间数据的混洗操作是指集群中的某个节点从其余集群的所有节点以及当前集群的其他节点拉取部分数据的过程。
2.如权利要求1所述的系统,其特征在于,所述系统使用任务调度算法,所述任务调度算法基于全局数据分布、带宽分布和计算资源分布决定在具体的集群执行任务;所述系统使用任务调度算法具体为,对于集群A、B、C…,任务在集群A上执行,从集群B上拉取数据,所述拉取数据到处理完数据的时间消耗如下:
costAB=costtAB+costcAB
costAB为分布在集群B上的数据从传输到处理整个过程所花的时间,包含两部分:costtAB为数据从集群B到A的网络传输时间,costcAB为数据在集群A上的处理时间;
bandwidthAB为集群B到A的带宽;
数据在集群A的处理时间由数据大小dataSizeB和计算资源M(cpu,mem)A来表示,M(cpu,mem)A为计算CPU核和内存容量资源的量化函数,costtAB当任务在集群A上执行时,分布在其余集群的全部数据的传输处理总时间为其中i为集群标识,可取B,C,…,
传输时间取其中的最大值,对此任务计算出其在每个集群的时间成本,其中时间消耗最小的即为最佳的执行位置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910360062.6A CN110308984B (zh) | 2019-04-30 | 2019-04-30 | 一种用于处理地理分布式数据的跨集群计算系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910360062.6A CN110308984B (zh) | 2019-04-30 | 2019-04-30 | 一种用于处理地理分布式数据的跨集群计算系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110308984A CN110308984A (zh) | 2019-10-08 |
CN110308984B true CN110308984B (zh) | 2022-01-07 |
Family
ID=68074871
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910360062.6A Active CN110308984B (zh) | 2019-04-30 | 2019-04-30 | 一种用于处理地理分布式数据的跨集群计算系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110308984B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111049898A (zh) * | 2019-12-10 | 2020-04-21 | 杭州东方通信软件技术有限公司 | 一种实现计算集群资源跨域架构的方法及系统 |
CN112311596B (zh) * | 2020-10-22 | 2023-05-12 | 深圳前海微众银行股份有限公司 | 数据管理方法、装置、设备及计算机存储介质 |
CN114443798B (zh) * | 2022-02-10 | 2024-07-05 | 数字广东网络建设有限公司 | 一种面向地理信息数据的分布式管理系统及方法 |
CN114969149B (zh) * | 2022-05-06 | 2024-04-30 | 北京偶数科技有限公司 | 数据资源的处理方法、装置以及存储介质 |
CN114791855B (zh) * | 2022-06-23 | 2022-09-16 | 中航金网(北京)电子商务有限公司 | 云平台下的任务调度方法、装置、介质、设备和程序产品 |
CN115242877B (zh) * | 2022-09-21 | 2023-01-24 | 之江实验室 | 面向多K8s集群的Spark协同计算、作业方法及装置 |
US11954525B1 (en) | 2022-09-21 | 2024-04-09 | Zhejiang Lab | Method and apparatus of executing collaborative job for spark faced to multiple K8s clusters |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101702721A (zh) * | 2009-10-26 | 2010-05-05 | 北京航空航天大学 | 一种多集群系统的可重组方法 |
CN102479099A (zh) * | 2010-11-22 | 2012-05-30 | 中兴通讯股份有限公司 | 虚拟机管理系统及其使用方法 |
CN109284336A (zh) * | 2018-09-18 | 2019-01-29 | 南京航空航天大学 | 一种地理分布式数据中心系统及其调度方法 |
-
2019
- 2019-04-30 CN CN201910360062.6A patent/CN110308984B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101702721A (zh) * | 2009-10-26 | 2010-05-05 | 北京航空航天大学 | 一种多集群系统的可重组方法 |
CN102479099A (zh) * | 2010-11-22 | 2012-05-30 | 中兴通讯股份有限公司 | 虚拟机管理系统及其使用方法 |
CN109284336A (zh) * | 2018-09-18 | 2019-01-29 | 南京航空航天大学 | 一种地理分布式数据中心系统及其调度方法 |
Also Published As
Publication number | Publication date |
---|---|
CN110308984A (zh) | 2019-10-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110308984B (zh) | 一种用于处理地理分布式数据的跨集群计算系统 | |
US10728091B2 (en) | Topology-aware provisioning of hardware accelerator resources in a distributed environment | |
Wang et al. | Maptask scheduling in mapreduce with data locality: Throughput and heavy-traffic optimality | |
Hu et al. | Flutter: Scheduling tasks closer to data across geo-distributed datacenters | |
CN110262901B (zh) | 一种数据处理方法及数据处理系统 | |
US20160350146A1 (en) | Optimized hadoop task scheduler in an optimally placed virtualized hadoop cluster using network cost optimizations | |
CN103176849B (zh) | 一种基于资源分类的虚拟机集群的部署方法 | |
US9367359B2 (en) | Optimized resource management for map/reduce computing | |
CN116360972A (zh) | 资源管理方法、装置及资源管理平台 | |
US8898422B2 (en) | Workload-aware distributed data processing apparatus and method for processing large data based on hardware acceleration | |
WO2018120171A1 (zh) | 一种用于存储过程的执行方法、设备以及系统 | |
Xie et al. | Pandas: robust locality-aware scheduling with stochastic delay optimality | |
CN107729138B (zh) | 一种高性能分布式矢量空间数据的分析方法和装置 | |
US20180341728A1 (en) | Distributable and Customizable Load-Balancing of Data-Associated Computation Via Partitions and Virtual Processes | |
CN109614227A (zh) | 任务资源调配方法、装置、电子设备及计算机可读介质 | |
US20210390405A1 (en) | Microservice-based training systems in heterogeneous graphic processor unit (gpu) cluster and operating method thereof | |
CN107204998B (zh) | 处理数据的方法和装置 | |
US20230136612A1 (en) | Optimizing concurrent execution using networked processing units | |
Liu et al. | Optimizing shuffle in wide-area data analytics | |
CN106502790A (zh) | 一种基于数据分布的任务分配优化方法 | |
CN105740249B (zh) | 一种大数据作业并行调度过程中的处理方法及其系统 | |
Slagter et al. | SmartJoin: a network-aware multiway join for MapReduce | |
CN117076133B (zh) | 云游戏平台异构资源分配方法、计算机装置及存储介质 | |
Mershad et al. | A study of the performance of a cloud datacenter server | |
Yang et al. | High-performance docker integration scheme based on OpenStack |
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 |