数据处理方法、装置、设备、介质及程序产品与流程

1.本技术涉及计算机应用领域，具体涉及一种数据处理方法、装置、设备、介质及程序产品。


背景技术：

1.随着大数据及深度学习技术的不断发展，通过深度学习的方法利用大量标记或非标记数据对模型进行对应的学习训练，最终得到较为精准的认知模型。经过训练的深度学习模型能揭示大数据里所承载的复杂且丰富的信息，并对未来或未知事件做更精准的预测。
2.但是，对模型的训练需要消耗大量的计算资源，在分布式系统中，每个计算节点承载着各自的运算任务，这些任务执行时会碰到调用数据库中的预存数据。在大规模的计算节点集群中，当并发大量的计算节点向数据库申请调用数据时，就会给数据库造成极大的带宽压力和数据传输压力，严重时会造成信息阻塞，无法及时完成模型的训练任务。
3.因此，如何对数据库的数据调用请求进行数据分流成为了亟待解决的技术问题。


技术实现要素：

4.本技术提供了一种数据处理方法、装置、设备、介质及程序产品，以解决如何对数据库的数据调用请求进行数据分流的技术问题。
5.第一方面，本技术提供了一种数据处理方法，包括：
6.获取数据请求，所述数据请求用于为计算节点集群中至少一个第一计算节点申请调用目标数据，所述目标数据由多个数据单元组成；
7.根据所述数据请求确定各个所述数据单元的调用地址，所述调用地址包括：第一地址，和/或第二地址，所述第一地址为所述计算节点集群中至少一个第二计算节点的地址，所述第二地址为存储节点集群中至少一个目标存储节点中数据库中的存储地址；
8.根据所述调用地址调用所有所述数据单元，并将所有所述数据单元组合成所述目标数据。
9.在一种可能的设计中，当该方法应用于计算节点集群或存储节点集群中的管理节点上时，所述获取数据请求，包括：
10.通过所述计算节点集群中的管理节点接收至少一个所述第一计算节点发送的所述数据请求；
11.对应的，所述根据所述数据请求确定各个所述数据单元的调用地址，包括：
12.通过所述管理节点向至少一个所述目标存储节点发送所述数据请求，以使所述目标存储节点根据所述目标数据确定所述调用地址；
13.通过所述管理节点接收所述目标存储节点反馈的所述调用地址；
14.对应的，所述根据所述调用地址调用所有所述数据单元，并将所有所述数据单元组合成所述目标数据，包括：
15.通过所述管理节点，根据所述调用地址，将所有所述数据单元组合成所述目标数据，并将所述目标数据发送给所述第一计算节点。
16.在一种可能的设计中，当该方法应用于计算节点集群中的计算节点上时，所述获取数据请求，包括：
17.在所述第一计算节点中响应于预设任务的触发指令，确定所述数据请求，所述数据请求用于使所述第一计算节点调用所述目标数据来执行所述预设任务；
18.对应的，所述根据所述数据请求确定各个所述数据单元的调用地址，包括：
19.通过所述第一计算节点，根据所述目标数据以及预设分割方式，向所述计算节点集群中至少一个其它计算节点发送第二数据请求，所述第二数据请求用于从各个所述数据节点中获取到所述数据单元；
20.接收各个所述其它计算节点返回的应答结果，并根据所述应答结果判断是否接收到了全部的所述数据单元；
21.若是，则将全部的所述数据单元组合成所述目标数据；
22.若否，则向至少一个所述目标存储单元发送第三数据请求，所述第三数据请求用于从所述目标存储单元中获取到剩余的所述数据单元。
23.在一种可能的设计中，在所述向至少一个所述目标存储节点发送所述数据请求之前，还包括：
24.获取所述存储节点集群中各个存储节点的工作状态信息；
25.根据所述工作状态信息，在各个所述存储节点中筛选出满足预设要求的至少一个所述目标存储节点。
26.在一种可能的设计中，当该方法应用于存储节点集群中的存储节点上时，所述获取数据请求，包括：
27.通过所述目标存储节点接收所述数据请求；
28.对应的，根据所述数据请求确定各个所述数据单元的调用地址，包括：
29.通过所述目标存储节点，根据所述数据请求中的所述目标数据，确定各个所述数据单元；
30.通过所述目标存储节点，在所述计算节点集群的各个计算节点中，确定部分或全部所述数据单元所对应的所述第一地址；
31.若所述第二计算节点中没有包含所有的所述数据单元，在数据库中确定剩余的所述数据单元对应的所述第二地址。
32.在一种可能的设计中，所述目标数据包括docker镜像，所述docker镜像用于在宿主机上完成对目标虚拟环境的搭建，所述目标虚拟环境与预设用户相对应。
33.在一种可能的设计中，所述存储节点集群中包括多个存储节点，每个所述存储节点中包括：docker registry组件以及接口组件，所述docker registry组件中的registry镜像库中存储有各种类型的所述docker镜像。
34.可选的，所述接口组件包括基于nginx服务平台的url统一资源定位接口。
35.在一种可能的设计中，所述接口组件的功能包括：缓存所述docker镜像，以及对用户的身份信息进行认证。
36.第二方面，本技术提供一种数据处理装置，包括：
37.获取模块，用于获取数据请求，所述数据请求用于为计算节点集群中至少一个第一计算节点申请调用目标数据，所述目标数据由多个数据单元组成；
38.处理模块，用于根据所述数据请求确定各个所述数据单元的调用地址，所述调用地址包括：第一地址，和/或第二地址，所述第一地址为所述计算节点集群中至少一个第二计算节点的地址，所述第二地址为存储节点集群中至少一个目标存储节点中数据库中的存储地址；
39.处理模块，还用于根据所述调用地址调用所有所述数据单元，并将所有所述数据单元组合成所述目标数据。
40.在一种可能的设计中，当该装置设置在计算节点集群或存储节点集群中的管理节点上时，所述获取模块，用于通过所述计算节点集群中的管理节点接收至少一个所述第一计算节点发送的所述数据请求；
41.所述处理模块，用于：
42.通过所述管理节点向至少一个所述目标存储节点发送所述数据请求，以使所述目标存储节点根据所述目标数据确定所述调用地址；通过所述管理节点接收所述目标存储节点反馈的所述调用地址；
43.所述处理模块，还用于通过所述管理节点，根据所述调用地址，将所有所述数据单元组合成所述目标数据，并将所述目标数据发送给所述第一计算节点。
44.在一种可能的设计中，当该装置设置在计算节点集群中的计算节点上时，所述获取模块，用于在所述第一计算节点中响应于预设任务的触发指令，确定所述数据请求，所述数据请求用于使所述第一计算节点调用所述目标数据来执行所述预设任务；
45.所述处理模块，用于通过所述第一计算节点，根据所述目标数据以及预设分割方式，向所述计算节点集群中至少一个其它计算节点发送第二数据请求，所述第二数据请求用于从各个所述数据节点中获取到所述数据单元；
46.所述获取模块，用于接收各个所述其它计算节点返回的应答结果；
47.所述处理模块，用于根据所述应答结果判断是否接收到了全部的所述数据单元；若是，则将全部的所述数据单元组合成所述目标数据；若否，则向至少一个所述目标存储单元发送第三数据请求，所述第三数据请求用于从所述目标存储单元中获取到剩余的所述数据单元。
48.在一种可能的设计中，所述获取模块，还用于获取所述存储节点集群中各个存储节点的工作状态信息；
49.所述处理模块，还用于根据所述工作状态信息，在各个所述存储节点中筛选出满足预设要求的至少一个所述目标存储节点。
50.在一种可能的设计中，所述工作状态信息包括：工作负载以及可用状态。
51.在一种可能的设计中，当该装置设置在存储节点集群中的存储节点上时，所述获取模块，用于通过所述目标存储节点接收所述数据请求；
52.所述处理模块，用于通过所述目标存储节点，根据所述数据请求中的所述目标数据，确定各个所述数据单元；通过所述目标存储节点，在所述计算节点集群的各个计算节点中，确定部分或全部所述数据单元所对应的所述第一地址；若所述第二计算节点中没有包含所有的所述数据单元，在数据库中确定剩余的所述数据单元对应的所述第二地址。
53.在一种可能的设计中，所述目标数据包括docker镜像，所述docker镜像用于在宿主机上完成对目标虚拟环境的搭建，所述目标虚拟环境与预设用户相对应。
54.在一种可能的设计中，所述存储节点集群中包括多个存储节点，每个所述存储节点中包括：docker registry组件以及接口组件，所述docker registry组件中的registry镜像库中存储有各种类型的所述docker镜像。
55.可选的，所述接口组件包括基于nginx服务平台的url统一资源定位接口。
56.在一种可能的设计中，所述接口组件的功能包括：缓存所述docker镜像，以及对用户的身份信息进行认证。
57.第三方面，本技术提供一种集群系统，包括：基于预设应用容器引擎的计算节点集群以及存储节点集群；其中，
58.所述计算节点集群中包括多个计算节点以及至少一个管理节点，所述计算节点用于执行预设任务，所述管理节点用于处理所述计算节点集群与所述存储节点集群间的数据交互；
59.所述存储节点集群中包括多个存储节点，每个所述存储节点中包括：镜像库组件以及接口组件，所述镜像库组件中的镜像库中存储有各种类型的镜像文件，所述接口组件包括：基于预设服务平台的统一资源定位接口，所述接口组件被配置为：缓存所述镜像文件，以及对用户的身份信息进行认证；
60.所述集群系统用于实现权利要求1
‑
5中任意一项所述的数据处理方法。
61.可选的，所述预设应用容器引擎包括：docker应用容器引擎，所述镜像文件包括：docker镜像，所述镜像库组件包括：docker registry组件。
62.在一种可能的设计中，所述预设任务，包括：对深度学习模型的逻辑演算任务。
63.在一种可能的设计中，所述接口组件包括：基于nginx服务平台的url统一资源定位接口。
64.在一种可能的设计中，所述存储节点集群中还包括至少一个存储管理节点。
65.第四方面，本技术提供一种电子设备，包括：
66.处理器；以及，
67.存储器，用于存储所述处理器的可执行指令；
68.其中，所述处理器配置为经由执行所述可执行指令，执行第一方面所提供的任意一种可能的数据处理方法。
69.第五方面，本技术提供一种空调，包括：显示元件、储能元件以及第三方面所提供的任意一种可能的电子设备。
70.第六方面，本技术还提供一种存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序用于执行第一方面所提供的任意一种可能的数据处理方法。
71.第七方面，本技术还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所提供的任意一种可能的数据处理方法。
72.本技术提供了一种数据处理方法、装置、设备、介质及程序产品，通过获取为计算节点集群中至少一个第一计算节点申请调用目标数据而发起的数据请求，其中，目标数据由多个数据单元组成，然后根据数据请求，在计算节点集群和存储节点集群中分别找到对应的各个数据单元的调用地址，再根据该调用地址获取到所有的数据单元，从而组合得到
目标数据。解决了如何对数据库的数据调用请求进行数据分流的技术问题。达到了将目标数据打散到多个位置来获取，而不是仅靠存储节点集群中的数据库来传输，减轻了大规模集群并发数据调用时数据库数据传输压力的技术效果。
附图说明
73.为了更清楚地说明本技术或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
74.图1为本技术提供的一种集群系统的结构示意图；
75.图2为本技术实施例提供的第一种数据处理方法的流程示意图；
76.图3为本技术实施例提供的第二种数据处理方法的流程示意图；
77.图4为本技术实施例提供的第三种数据处理方法的流程示意图；
78.图5为本技术实施例提供的第四种数据处理方法的流程示意图；
79.图6为本技术提供的一种数据处理装置的结构示意图；
80.图7为本技术提供的一种电子设备的结构示意图。
具体实施方式
81.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，包括但不限于对多个实施例的组合，都属于本技术保护的范围。
82.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
83.下面先对本技术所涉及到的专业名词进行定义解释：
84.docker，是一种开源的应用容器引擎，让开发者可以将应用以及依赖(即应用的运行环境)打包到一个可移植的容器中，然后发布到任何流行的linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。需要注意的是，docker本身并不是容器，而是创建容器的工具。
85.容器概念的出现，使得建立在不同平台或者说是依赖的运行环境不同的各种类型或不同版本的应用程序可以同时运行在同一个操作系统中而不会产生冲突。如果将操作系统比作大海，那么容器就是海上的船只，而镜像就是船只上的集装箱。容器就是各种应用和操作系统间的媒介。
86.docker技术的三大核心概念，分别是：镜像(image)、容器(container)、仓库(repository)。
87.docker镜像可以理解为开发好的某个应用及其依赖的复制品。
88.docker仓库就是用来存储docker镜像的数据库。
89.docker容器就是用来承载着多个docker镜像，使得相互间互相隔离，无法互通的应用可以在同一个操作系统上正常运行。
90.而在docker应用容器引擎中，负责对docker镜像进行管理的，是docker registry服务，其作用类似于仓库管理员。
91.docker registry服务中有三个角色，分别是index、registry和registry client。
92.index负责并维护有关用户帐户、镜像的校验以及公共命名空间的信息。它使用以下组件维护这些信息：web ui、元数据存储、认证服务、符号化。
93.registry是镜像和图表的仓库。然而，它没有一个本地数据库，也不提供用户的身份认证，由s3、云文件和本地文件系统提供数据库支持。此外，通过index auth service的token方式进行身份认证。registries可以有不同的类型，例如：
94.(1)sponsor registry：第三方的registry镜像仓库，供客户和docker社区使用。
95.(2)mirror registry：第三方的registry镜像仓库，只让客户使用。
96.(3)vendor registry：由发布docker镜像的供应商提供的registry镜像仓库。
97.(4)private registry：通过设有防火墙和额外的安全层的私有实体提供的registry镜像仓库。
98.registry client：docker充当registry客户端来负责维护推送和拉取的任务，以及客户端的授权。
99.现有技术中，当用户要获取并下载镜像时，docker registry服务的工作流程如下：
100.首先，用户发送请求到index来下载镜像；
101.然后index发出响应，返回三个相关部分信息：该镜像所处的registry、该镜像包括所有层的校验，以及以授权为目标意愿的token。
102.需要注意：当请求header里有x
‑
docker
‑
token时才会返回token。而私人仓库需要基本的身份验证，对于公有仓库这一点不是强制性的。
103.接下来，用户通过响应后返回的token和registry沟通，registry全权负责镜像，它用来存储基本的镜像和继承的层；
104.然后，registry现在要与index证实该token是被授权的；
105.最后，index会发送“true”或者“false”标识给registry镜像仓库，由此判定是否允许用户下载所需要的镜像。
106.而上述用户端获取镜像的过程，当其应用在大规模集群系统中时，就会出现问题，因为大规模集群系统中的各个计算节点就相当于各个用户端，在多个计算节点同时向registry镜像仓库请求获取镜像时，就会造成registry镜像仓库的带宽需求和数据传输压力的迅速增长。
107.下面介绍本技术的发明构思：
108.目前，在大规模的集群系统中，一般都是通过docker方式部署镜像，在计算节点集群中的各个计算节点通过请求registry镜像仓库所在的存储节点拉取对应的镜像。在大规模并发场景下，大大增加了存储节点带宽和数据传输压力。
109.虽然可以通过部署多个具备完整registry镜像仓库的存储节点来缓解单个存储节点的带宽和数据传输压力，但是由于成本的限制，不可能无限制地增加存储节点，那么如何对registry镜像库的数据调用请求进行数据分流成为了亟待解决的技术问题。
110.而本技术发明人发现，对于一个大规模的集群系统来说，多个计算节点所申请的有可能是相同的镜像，或者是具有相同组成单元或者说是相同数据单元的镜像，如多个应用都是基于java平台环境，那么多个镜像中的java平台环境的数据单元就是相同的。因此，可以将已经获取到镜像或具有相同数据单元的计算节点作为数据源来进行调用。这样就使得，原本只有有限的几个具备完整registry镜像仓库的存储节点作为数据源的情况，变成了能够充分利用大规模的集群系统中各个计算节点的资源作为动态数据源。目标数据的调用就不会都拥堵到registry镜像仓库的存储节点上，从而解决了数据调用请求的数据分流问题。
111.下面结合几个实施例，对本技术所提供的数据处理方法的具体步骤进行详细介绍。
112.图1为本技术提供的一种集群系统的结构示意图。如图1所示，该集群系统100包括：计算节点集群110以及存储节点集群120。该计算节点集群110以及存储节点集群120都是基于docker应用容器引擎的基础上设置的。
113.其中，计算节点集群110中包括：多个计算节111以及至少一个管理节点112，计算节点111用于执行预设任务，包括对深度学习模型的逻辑演算任务；
114.管理节点112用于处理计算节点集群110与存储节点集群120间的数据交互；
115.存储节点集群120中包括：多个存储节121和/或至少一个管理节点(图中未示出)，每个存储节点121中包括：docker registry组件1211以及接口组件1212。docker registry组件1211中的registry镜像库中存储有各种类型的docker镜像。接口组件1212包括：基于nginx服务平台的url统一资源定位接口，该接口组件1212被配置为：缓存所述docker镜像，以及对用户的身份信息进行认证。
116.需要说明的是，针对于缓存docker镜像，原生的dokcer registry镜像库是基于文件系统的，并发能力差，为了减轻对后端存储的负载压力，需要增加缓存策略。本技术利用nginx来实现url(uniform resource locator,统一资源定位)接口数据的缓存，为了避免cache缓存过大，可以配置缓存失效时间，只缓存最近的预设时间内读取的热点数据。通过配置缓存策略，大大提升了并发下载同一镜像的性能。
117.还需要说明的是，本技术所提供的数据处理方法可以应用在，图1所示的集群系统的计算节点集群110或存储节点集群120的管理节点上，也可以应用在计算节点111或存储节点121上。
118.下面先通过图2所示的实施例对本技术所提供的数据处理方法进行总体介绍，然后再通过图3、图4和图5所示的实施例对应用在不同节点上时的具体实现方式进行介绍。
119.图2为本技术实施例提供的第一种数据处理方法的流程示意图。如图2所示，该数据处理方法的具体步骤，包括：
120.s201、获取数据请求。
121.在本步骤中，数据请求用于为计算节点集群中至少一个第一计算节点申请调用目标数据，该目标数据由多个数据单元组成。
122.需要说明的是，数据单元可以根据预设分割形式进行分割，也可以根据目标数据原有的文件组织形式进行分割。例如，一个大型文档在进行传输时，会分为多个数据包，每个数据包的数据大小都有限定要求，比如，每个数据包为4m大小，那么就可以将此数据包作为数据单元进行管理。
123.在本实施例中，目标数据包括各种类型的docker镜像。
124.还需要说明的是，数据请求是计算节点为完成或执行预设任务，如深度学习算法的逻辑演算任务，而需要申请调用docker镜像。
125.具体的，计算节点集群中的至少一个计算节在执行预设任务时触发了数据请求，该计算节点直接将此数据请求进行拦截；
126.或者，
127.计算节点集群或存储节点集群中的管理节点，如super node超级节点，拦截计算节点发起的数据请求；
128.又或者是，存储节点集群中的存储节点接收到计算节点发起的数据请求。
129.具体的情况可以参考下面的其它实施例。
130.s202、根据数据请求确定各个数据单元的调用地址。
131.在本步骤中，调用地址包括：第一地址，和/或第二地址，第一地址为计算节点集群中至少一个第二计算节点的地址，第二地址为存储节点集群中至少一个目标存储节点中数据库中的存储地址。
132.具体的，从数据请求中提取到目标数据的标识，如docker镜像的编号，然后根据预设分割方式，或者该docker镜像的组织形式，确定组成该docker镜像的各个数据单元的标识。
133.然后，先根据各个数据单元的标识，从计算节点集群中遍历各个计算节点，查看在计算节点中是否存储有对应的数据单元。若存在，则此计算节点就是第二计算节点，其存储对应数据单元的地址如ip地址，就是第一地址。
134.若通过遍历各个计算节点，查找到了所有的数据单元，那么将各个第一地址返回给发起数据请求的第一计算节点。
135.若遍历完了所有处于可用状态的计算节点，仍然没有把所有的数据单元全部找到，那么就把没有找到的数据单元的标识发送给数据库，如registry镜像库，registry镜像库将这些没有在计算节点中找到的数据单元的存储地址即第二地址发送给第一计算节点。
136.s203、根据调用地址调用所有数据单元，并将所有数据单元组合成目标数据。
137.在本步骤中，从各个数据单元对应的调用地址上调用数据单元，由于各个数据单元可以来源于计算节点集群的多个第二计算节点，这样就使得原本数据库需要传输整个目标数据，变成了只需要传输部分数据单元，实现了对数据库的数据调用的分流。甚至，所有的数据单元都能够从第二计算节点中得到，那么数据库的数据传输压力就更小了。
138.在得到了所有的数据单元后，只需要根据预设分割方式，或者是各个数据单元间的数据连接标识，将其组合成目标数据，即可实现第一计算节点对目标数据的调用。
139.本实施例提供的数据处理方法，通过获取为计算节点集群中至少一个第一计算节点申请调用目标数据而发起的数据请求，其中，目标数据由多个数据单元组成，然后根据数据请求，在计算节点集群和存储节点集群中分别找到对应的各个数据单元的调用地址，再根据该调用地址获取到所有的数据单元，从而组合得到目标数据。解决了如何对数据库的数据调用请求进行数据分流的技术问题。达到了将目标数据打散到多个位置来获取，而不是仅靠存储节点集群中的数据库来传输，减轻了大规模集群并发数据调用时数据库数据传输压力的技术效果。
140.当本技术所提供的数据处理方法应用于计算节点集群或存储节点集群中的管理节点上时，其具体的实现步骤如图3所示。
141.图3为本技术实施例提供的第二种数据处理方法的流程示意图。如图3所示，该数据处理方法的具体步骤包括：
142.s301、通过计算节点集群中的管理节点接收至少一个第一计算节点发送的数据请求。
143.在本步骤中，计算节点集群中的至少一个第一计算节点在执行预设任务时，触发了对至少一个目标数据的调用需求，从而使得第一计算节点发出数据请求，以获取到目标数据。
144.计算节点向管理节点发送该数据请求，或者是计算节点原本是要向数据库所在的存储节点发送该数据请求，但在本实施例中，由管理节点截获了该数据请求。
145.s302、通过管理节点向至少一个目标存储节点发送数据请求，以使目标存储节点根据目标数据确定调用地址。
146.在本步骤中，存储节点集群中存在多个包含完整数据库数据的存储节点，管理节点负责计算节点集群与存储节点集群的数据交互。
147.具体的，管理节点向处于可用状态的，且负载率低于预设负载阈值的至少一个存储节点即目标存储节点发送连接请求，
148.然后，管理节点可以与第一个反馈该连接请求的目标存储节点建立数据连接，如http连接，并通过http协议向该目标存储节点发送数据请求。
149.可选的，管理节点也可以将目标数据按预设分割方式进行分割，以确定多个数据单元。然后管理节点与多个目标存储节点建立数据连接，然后通过数据连接，向多个目标存储节点分别申请调用对应的数据单元。
150.在一种可能的设计中，在向至少一个目标存储节点发送数据请求之前，还包括：
151.是获取所述存储节点集群中各个存储节点的工作状态信息；
152.根据所述工作状态信息，在各个所述存储节点中筛选出满足预设要求的至少一个所述目标存储节点。
153.工作状态信息包括：工作负载以及可用状态。
154.具体的，如图1所示，第一计算节点上的docker daemon服务器解析docker registry镜像库对应的域名地址时，先从各个含有docker registry镜像库的存储节点中筛选出处于可用状态的存储节点；然后获其工作负载，如按照预设负载计算模型得到各个存储节点的负载值；然后对各个负载值进行由低到高的排序，选取排在前n位的存储节点作为目标存储节点，或者选取负载值低于预设负载阈值的存储节点作为目标存储节点。
155.可选的，选取负载值最低的存储节点作为目标存储节点。
156.接下来，通过dns(domain name system，域名系统)解析到目标存储节点所对应的域名地址。
157.s303、通过管理节点接收目标存储节点反馈的调用地址。
158.在本步骤中，目标存储节点通过遍历计算节点集群中的各个计算节点，判断其中是否包含了目标数据所对应的部分或者全部的数据单元，并将存储有对应的数据单元的第二计算节点的第一地址反馈给管理节点。
159.如果计算节点集群的计算节点中没有包含所有的数据单元，那么目标存储节点就将剩余的数据单元在数据库中的存储地址即第二地址反馈给管理节点。
160.这样就实现了对数据库的数据分流，降低了数据库的带宽和数据传输压力。
161.在本实施例中，目标数据包括docker镜像，通过p2p模式，将docker镜像分割为预设大小(如4m)的镜像分块(即数据单元)，将对docker镜像的数据请求进行重定向，使得只有小部分的数据调用请求会真正到达镜像仓库(即目标存储节点上的数据库)拉取镜像分块，大部分请求会从计算节点集群内的其他计算节点上获取镜像分块。
162.s304、通过管理节点，根据调用地址，将所有数据单元组合成目标数据。
163.s305、将目标数据发送给第一计算节点。
164.本实施例提供的数据处理方法，通过获取为计算节点集群中至少一个第一计算节点申请调用目标数据而发起的数据请求，其中，目标数据由多个数据单元组成，然后根据数据请求，在计算节点集群和存储节点集群中分别找到对应的各个数据单元的调用地址，再根据该调用地址获取到所有的数据单元，从而组合得到目标数据。解决了如何对数据库的数据调用请求进行数据分流的技术问题。达到了将目标数据打散到多个位置来获取，而不是仅靠存储节点集群中的数据库来传输，减轻了大规模集群并发数据调用时数据库数据传输压力的技术效果。
165.当本技术所提供的数据处理方法应用于当该方法应用于计算节点集群中的计算节点上时，其具体的实现步骤如图4所示。
166.图4为本技术实施例提供的第三种数据处理方法的流程示意图。如图4所示，该数据处理方法的具体步骤包括：
167.s401、在第一计算节点中响应于预设任务的触发指令，确定数据请求。
168.在本步骤中，数据请求用于使第一计算节点调用目标数据来执行预设任务。
169.在本实施例中，目标数据包括docker镜像。在第一计算节点执行预设任务，如深度学习模型的逻辑演算任务，或者是虚拟环境的创建任务时，由于任务需求，需要使用到对应的docker镜像。
170.现有技术中，是第一计算节点直接向docker registry镜像库所在的存储节点拉取对应的docker镜像。从而在大量并发docker镜像拉取时，引起docker registry镜像库的带宽堵塞，制约了计算节点完成预设任务。
171.在本实施例中，计算节点触发了该docker镜像调用需求后，确定数据请求，但是不直接向存储节点发送拉取请求。
172.s402、通过第一计算节点，根据目标数据以及预设分割方式，向计算节点集群中至少一个其它计算节点发送第二数据请求。
173.在本步骤中，第二数据请求用于从各个数据节点中获取到数据单元，s401中的数据请求中的目标数据可以按预设分割方式分割为多个数据单元。
174.预设分割方式包括：与数据传输协议对应的数据包分割方式。
175.具体的，第一计算节点通过遍历计算节点集群中的其它计算节点，判断其中是否包含了目标数据所对应的部分或者全部的数据单元，若是则获取存储有对应的数据单元的第二计算节点的第一地址。
176.s403、接收各个其它计算节点返回的应答结果，并根据应答结果判断是否接收到了全部的数据单元。
177.在本步骤中，若能够从其它的计算节点向第一计算节点中获取到目标数据所对应的全部数据单元，则执行步骤s404，否则执行步骤s405。
178.s404、将全部的数据单元组合成目标数据。
179.s405、向至少一个目标存储单元发送第三数据请求。
180.在本步骤中，第三数据请求用于从目标存储单元中获取到剩余的数据单元。
181.在一种可能的设计中，在向至少一个目标存储节点发送第三数据请求之前，还包括：
182.是获取存储节点集群中各个存储节点的工作状态信息；
183.根据工作状态信息，在各个存储节点中筛选出满足预设要求的至少一个目标存储节点。
184.工作状态信息包括：工作负载以及可用状态。
185.具体的，如图1所示，第一计算节点上的docker daemon服务器解析docker registry镜像库对应的域名地址时，先从各个含有docker registry镜像库的存储节点中筛选出处于可用状态的存储节点；然后获其工作负载，如按照预设负载计算模型得到各个存储节点的负载值；然后对各个负载值进行由低到高的排序，选取排在前n位的存储节点作为目标存储节点，或者选取负载值低于预设负载阈值的存储节点作为目标存储节点。
186.可选的，选取负载值最低的存储节点作为目标存储节点。
187.接下来，通过dns(domain name system，域名系统)解析到目标存储节点所对应的域名地址。
188.s406、将所有数据单元组合成目标数据。
189.本实施例提供的数据处理方法，通过获取为计算节点集群中至少一个第一计算节点申请调用目标数据而发起的数据请求，其中，目标数据由多个数据单元组成，然后根据数据请求，在计算节点集群和存储节点集群中分别找到对应的各个数据单元的调用地址，再根据该调用地址获取到所有的数据单元，从而组合得到目标数据。解决了如何对数据库的数据调用请求进行数据分流的技术问题。达到了将目标数据打散到多个位置来获取，而不是仅靠存储节点集群中的数据库来传输，减轻了大规模集群并发数据调用时数据库数据传输压力的技术效果。
190.当本技术所提供的数据处理方法应用于当该方法应用于存储节点集群中的存储节点上时，其具体的实现步骤如图5所示。
191.图5为本技术实施例提供的第四种数据处理方法的流程示意图。如图5所示，该数据处理方法的具体步骤包括：
192.s501、通过目标存储节点接收数据请求。
193.在本步骤中，数据请求用于使第一计算节点调用目标数据来执行预设任务。
194.在本实施例中，目标数据包括docker镜像。在第一计算节点执行预设任务，如深度学习模型的逻辑演算任务，或者是虚拟环境的创建任务时，由于任务需求，需要使用到对应的docker镜像。
195.目标存储节点接收到第一计算节点所发送的数据请求。
196.s502、通过目标存储节点，根据数据请求中的目标数据，确定各个数据单元。
197.在本步骤中，目标存储节点通过对目标数据进行解析，如通过预设分割方式，或者是目标数据的文档组成形式，确定能够组成完整目标数据的各个数据单元。
198.s503、通过目标存储节点，在计算节点集群的各个计算节点中，确定部分或全部数据单元所对应的第一地址。
199.在本步骤中，目标存储节点通过遍历计算节点集群中的各个计算节点，判断其中是否包含了目标数据所对应的部分或者全部的数据单元，若是则获取存储有对应的数据单元的第二计算节点的第一地址。所述第一地址为所述数据单元在所述第二计算节点中的存储地址。
200.s504、若第二计算节点中没有包含所有的数据单元，在数据库中确定剩余的数据单元对应的第二地址。
201.s505、将第一地址和第二地址发送给第一计算节点，以使第一计算节点调用各个数据单元组合成目标数据。
202.本实施例提供的数据处理方法，通过获取为计算节点集群中至少一个第一计算节点申请调用目标数据而发起的数据请求，其中，目标数据由多个数据单元组成，然后根据数据请求，在计算节点集群和存储节点集群中分别找到对应的各个数据单元的调用地址，再根据该调用地址获取到所有的数据单元，从而组合得到目标数据。解决了如何对数据库的数据调用请求进行数据分流的技术问题。达到了将目标数据打散到多个位置来获取，而不是仅靠存储节点集群中的数据库来传输，减轻了大规模集群并发数据调用时数据库数据传输压力的技术效果。
203.对于上述图2
‑
图5中任一实施例来说，在一种可能的设计中，所述目标数据包括docker镜像，所述docker镜像用于在宿主机上完成对目标虚拟环境的搭建，所述目标虚拟环境与预设用户相对应。
204.在一种可能的设计中，所述存储节点集群中包括多个存储节点，每个所述存储节点中包括：docker registry组件以及接口组件，所述docker registry组件中的registry镜像库中存储有各种类型的所述docker镜像。
205.可选的，所述接口组件包括基于nginx服务平台的url统一资源定位接口。
206.在一种可能的设计中，所述接口组件的功能包括：缓存所述docker镜像，以及对用户的身份信息进行认证。
207.在上述任一实施例中，本技术对于各个计算节点的身份信息的认证方式，包括：
208.采用docker registry官方提供的basic auth的base 64位编码方式进行用户认证，然后使用openrestry扩展nginx的方式对不同的url(uniform resource locator,统一资源定位)路由进行鉴权。通过容器编排工具将容器以linux中真实用户的uid用户身份标
识和gid组别身份标识，进行容器中对应的用户创建操作，容器编排工具需要以linux中的root权限进行docker启动操作，并且启动时将该用户的家目录和root用户的私钥进行挂载，其中用户的家目录是为用户提供该用户所需的文件，挂载root用户的私钥是为了容器间调度和ssh无密码访问。
209.此用户认证方式还可支持容器固化后的用户认证，通过容器编排工具启动时对当前用户的uid用户身份标识和gid组别身份标识进行记录，下次访问时会清除上次的用户记录创建新的用户uid用户身份标识和gid组别身份标识，从而保证一个容器中只有一个用户，不会发生用户uid用户身份标识或者gid组别身份标识冲突问题，从而解决了单个容器中只有一个用户的问题，并且此用户是有sudo权限的用户，相当于对该容器有root所有权，从而实现了用户权限的隔离。
210.图6为本技术提供的一种数据处理装置的结构示意图。该数据处理装置可以通过软件、硬件或者两者的结合实现。
211.如图6所示，本实施例提供的数据处理装置600，包括：
212.获取模块601，用于获取数据请求，数据请求用于为计算节点集群中至少一个第一计算节点申请调用目标数据，目标数据由多个数据单元组成；
213.处理模块602，用于根据数据请求确定各个数据单元的调用地址，调用地址包括：第一地址，和/或第二地址，第一地址为计算节点集群中至少一个第二计算节点的地址，第二地址为存储节点集群中至少一个目标存储节点中数据库中的存储地址；
214.处理模块602，还用于根据调用地址调用所有数据单元，并将所有数据单元组合成目标数据。
215.在一种可能的设计中，当该装置设置在计算节点集群或存储节点集群中的管理节点上时，获取模块601，用于通过计算节点集群中的管理节点接收至少一个第一计算节点发送的数据请求；
216.处理模块602，用于：
217.通过管理节点向至少一个目标存储节点发送数据请求，以使目标存储节点根据目标数据确定调用地址；通过管理节点接收目标存储节点反馈的调用地址；
218.处理模块602，还用于通过管理节点，根据调用地址，将所有数据单元组合成目标数据，并将目标数据发送给第一计算节点。
219.在一种可能的设计中，当该装置设置在计算节点集群中的计算节点上时，获取模块601，用于在第一计算节点中响应于预设任务的触发指令，确定数据请求，数据请求用于使第一计算节点调用目标数据来执行预设任务；
220.处理模块602，用于通过第一计算节点，根据目标数据以及预设分割方式，向计算节点集群中至少一个其它计算节点发送第二数据请求，第二数据请求用于从各个数据节点中获取到数据单元；
221.获取模块601，用于接收各个其它计算节点返回的应答结果；
222.处理模块602，用于根据应答结果判断是否接收到了全部的数据单元；若是，则将全部的数据单元组合成目标数据；若否，则向至少一个目标存储单元发送第三数据请求，第三数据请求用于从目标存储单元中获取到剩余的数据单元。
223.在一种可能的设计中，获取模块601，还用于获取存储节点集群中各个存储节点的
工作状态信息；
224.处理模块602，还用于根据工作状态信息，在各个存储节点中筛选出满足预设要求的至少一个目标存储节点。
225.在一种可能的设计中，工作状态信息包括：工作负载以及可用状态。
226.在一种可能的设计中，当该装置设置在存储节点集群中的存储节点上时，获取模块601，用于通过目标存储节点接收数据请求；
227.处理模块602，用于通过目标存储节点，根据数据请求中的目标数据，确定各个数据单元；通过目标存储节点，在计算节点集群的各个计算节点中，确定部分或全部数据单元所对应的第一地址；若第二计算节点中没有包含所有的数据单元，在数据库中确定剩余的数据单元对应的第二地址。
228.在一种可能的设计中，目标数据包括docker镜像，docker镜像用于在宿主机上完成对目标虚拟环境的搭建，目标虚拟环境与预设用户相对应。
229.在一种可能的设计中，存储节点集群中包括多个存储节点，每个存储节点中包括：docker registry组件以及接口组件，docker registry组件中的registry镜像库中存储有各种类型的docker镜像。
230.可选的，接口组件包括基于nginx服务平台的url统一资源定位接口。
231.在一种可能的设计中，接口组件的功能包括：缓存docker镜像，以及对用户的身份信息进行认证。
232.值得说明的是，图6所示实施例提供的数据处理装置，可以执行上述任一方法实施例中所提供的方法，其具体实现原理、技术特征、专业名词解释以及技术效果类似，在此不再赘述。
233.图7为本技术提供的一种电子设备的结构示意图。如图7所示，该电子设备700可以包括：至少一个处理器701和存储器702。图7示出的是以一个处理器为例的电子设备。
234.存储器702，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。
235.存储器702可能包含高速ram存储器，也可能还包括非易失性存储器(non
‑
volatile memory)，例如至少一个磁盘存储器。
236.处理器701用于执行存储器702存储的计算机执行指令，以实现以上各方法实施例所述的方法。
237.其中，处理器701可能是一个中央处理器(central processing unit，简称为cpu)，或者是特定集成电路(application specific integrated circuit，简称为asic)，或者是被配置成实施本技术实施例的一个或多个集成电路。
238.可选地，存储器702既可以是独立的，也可以跟处理器701集成在一起。当所述存储器702是独立于处理器701之外的器件时，所述电子设备700，还可以包括：
239.总线703，用于连接所述处理器701以及所述存储器702。总线可以是工业标准体系结构(industry standard architecture，简称为isa)总线、外部设备互连(peripheral component，pci)总线或扩展工业标准体系结构(extended industry standard architecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。
240.可选的，在具体实现上，如果存储器702和处理器701集成在一块芯片上实现，则存储器702和处理器701可以通过内部接口完成通信。
241.本技术还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：u盘、移动硬盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述各实施例中的方法。
242.本技术还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各实施例中的方法。
243.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。