CN117716336A - 数据处理方法、装置、设备及介质 - Google Patents

Abstract

本发明涉及一种数据处理方法、装置、设备及介质。本发明通过在获取到目标节点上所显示的节点在程序代码中对应的操作对象的属性数据之后，将所获取到的属性数据关联到对应的节点上，从而使得在对目标节点上的节点进行拖拽操作时，可以直接基于拖拽操作对应的操作数据，来对节点所关联的属性数据进行修改，而无需进行操作对象的查找，使得通过简单的操作过程，即可实现对节点的拖拽显示，以使节点基于修改后的属性数据，显示在拖拽操作结束的位置。

Description

数据处理方法、装置、设备及介质 技术领域

本发明涉及计算机技术领域，尤其涉及一种数据处理方法、装置、设备及介质。

背景技术

第五版超文本标记语言(Hyper Text Markup Language 5.0，HTML5)作为构建网页(Web)内容的一种语言描述方式，已经在应用开发过程中得到了广泛的应用。

相关技术中，如果要在基于HTML5开发得到的应用中实现对某一个组件的拖拽，需要相关技术人员在开发时编写大量复杂的代码，从而导致开发效率较低，因此，亟需一种方法，以更加在基于HTML5开发得到的应用中更加简单地实现对某一个组件的拖拽功能。

发明内容

本发明提供一种数据处理方法、装置、设备及介质，以解决相关技术中的不足。

根据本发明实施例的第一方面，提供一种数据处理方法，该方法包括：

获取目标界面上所显示的节点对应的操作对象的属性数据，操作对象为在目标界面对应的程序代码中所定义的对象；

将所获取到的属性数据关联到对应的节点上；

响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改，以使节点基于修改后的属性数据，显示在拖拽操作结束的位置。

在一些实施例中，响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改，包括：

响应于对目标界面上的节点的拖拽操作，通过属性获取指令，基于拖拽操作对 应的操作数据，获取待修改的属性数据；

通过属性设置指令，确定待修改的属性数据对应的操作对象；

基于待修改的属性数据，对所确定出的操作对象对应的属性数据进行修改。

在一些实施例中，属性数据包括节点的位置数据；

响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改，包括：

响应于对目标界面上的节点的拖拽操作，基于拖拽操作结束的位置所对应的位置数据，对节点所关联的属性数据中的位置数据进行修改。

在一些实施例中，位置数据包括节点所处物理池对应的服务器标识以及节点在服务器中的索引值。

在一些实施例中，该方法还包括：

在节点满足设定条件的情况下，响应于对目标界面上的节点的拖拽操作，为节点生成临时变量；

通过临时变量，对节点修改前的属性数据进行存储。

在一些实施例中，属性数据还包括节点的样式数据，样式数据用于指示节点的显示样式；

该方法还包括：

响应于对目标界面上的节点的拖拽操作，将临时变量中所存储的属性数据所包括的样式数据修改为第一样式数据，将节点所关联的属性数据所包括的样式数据修改为第二样式数据。

在一些实施例中，属性数据还包括行为数据，行为数据用于指示节点在被拖拽时是否需要显示提示信息；

该方法还包括：

响应于对目标界面上的节点的拖拽操作，获取被拖拽的节点所关联的属性数据；

在属性数据所包括的行为数据指示节点在被拖拽时是否需要显示提示信息的情况下，显示提示信息，提示信息用于基于本次拖拽操作进行提示。

在一些实施例中，操作对象为文档对象模型DOM对象，属性获取指令为getAtttribute指令，属性设置指令为setAtttribute指令。

根据本发明实施例的第二方面，提供一种数据处理装置，该装置包括：

获取单元，用于获取目标界面上所显示的节点对应的操作对象的属性数据，操作对象为在目标界面对应的程序代码中所定义的对象；

关联单元，用于将所获取到的属性数据关联到对应的节点上；

修改单元，用于响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改，以使节点基于修改后的属性数据，显示在拖拽操作结束的位置。

在一些实施例中，修改单元，在用于响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改时，用于：

响应于对目标界面上的节点的拖拽操作，通过属性获取指令，基于拖拽操作对应的操作数据，获取待修改的属性数据；

通过属性设置指令，确定待修改的属性数据对应的操作对象；

基于待修改的属性数据，对所确定出的操作对象对应的属性数据进行修改。

在一些实施例中，属性数据包括节点的位置数据；

修改单元，在用于响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改时，用于：

响应于对目标界面上的节点的拖拽操作，基于拖拽操作结束的位置所对应的位置数据，对节点所关联的属性数据中的位置数据进行修改。

在一些实施例中，位置数据包括节点所处物理池对应的服务器标识以及节点在服务器中的索引值。

在一些实施例中，该装置还包括：

生成单元，用于在节点满足设定条件的情况下，响应于对目标界面上的节点的拖拽操作，为节点生成临时变量；

存储单元，用于通过临时变量，对节点修改前的属性数据进行存储。

在一些实施例中，属性数据还包括节点的样式数据，样式数据用于指示节点的 显示样式；

修改单元，还用于响应于对目标界面上的节点的拖拽操作，将临时变量中所存储的属性数据所包括的样式数据修改为第一样式数据，将节点所关联的属性数据所包括的样式数据修改为第二样式数据。

在一些实施例中，属性数据还包括行为数据，行为数据用于指示节点在被拖拽时是否需要显示提示信息；

获取单元，还用于响应于对目标界面上的节点的拖拽操作，获取被拖拽的节点所关联的属性数据；

该装置还包括：

显示单元，用于在属性数据所包括的行为数据指示节点在被拖拽时是否需要显示提示信息的情况下，显示提示信息，提示信息用于基于本次拖拽操作进行提示。

在一些实施例中，操作对象为文档对象模型DOM对象，属性获取指令为getAtttribute指令，属性设置指令为setAtttribute指令。

根据本发明实施例的第三方面，提供一种计算设备，该计算设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，该处理器执行该计算机程序时实现上述第一方面以及第一方面的任一个实施例所提供的数据处理方法所执行的操作。

根据本发明实施例的第四方面，提供一种计算机可读存储介质，该计算机可读存储介质上存储有程序，该程序被处理器执行时，实现上述第一方面以及第一方面的任一个实施例所提供的数据处理方法所执行的操作。

根据本发明实施例的第五方面，提供一种计算机程序产品，该计算机程序产品包括计算机程序，计算机程序被处理器执行时，实现上述第一方面以及第一方面的任一个实施例所提供的数据处理方法所执行的操作。

本发明通过在获取到目标节点上所显示的节点在程序代码中对应的操作对象的属性数据之后，将所获取到的属性数据关联到对应的节点上，从而使得在对目标节点上的节点进行拖拽操作时，可以直接基于拖拽操作对应的操作数据，来对节点所关联的属性数据进行修改，而无需进行操作对象的查找，使得通过简单的操作过程，即可实现对节点的拖拽显示，以使节点基于修改后的属性数据，显示在拖拽操作结束的 位置。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据本发明实施例示出的一种数据处理方法的流程图。

图2是根据本发明实施例示出的一种拖拽功能的原理示意图。

图3是根据本发明实施例示出的一种修改样式数据的原理示意图。

图4是根据本发明实施例示出的一种部署界面的界面示意图。

图5是根据本发明实施例示出的一种增加物理池界面的界面示意图。

图6是根据本发明实施例示出的一种部署界面的界面示意图。

图7是根据本发明实施例示出的一种推荐部署过程的流程图。

图8是根据本发明实施例示出的一种部署界面的界面示意图。

图9是根据本发明实施例示出的一种节点分配过程的示意图。

图10是根据本发明实施例示出的多种大数据组件在进行不同操作时需要修改的配置文件示意图。

图11是根据本发明实施例示出的一种部署数据示意图。

图12是根据本发明实施例示出的一种部署数据示意图。

图13是根据本发明实施例示出的一种恢复出厂设置过程的流程示意图。

图14是根据本发明实施例示出的一种redis.conf配置文件的示意图。

图15是根据本发明实施例示出的一种Redis集群的搭建过程的示意图。

图16是根据本发明实施例示出的一种模块交互过程的流程图。

图17是根据本发明实施例示出的另一种模块交互过程的流程图。

图18是根据本发明实施例示出的另一种模块交互过程的流程图。

图19是本发明根据一示例性实施例示出的一种计算设备的结构示意图。

图20是本发明根据一示例性实施例示出的一种计算设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

本发明提供了一种数据处理方法，以便可以通过本发明所提供的方法，设计一种便捷操作的拖拽组件，方便开发者对拖拽过程进行更精准的控制，获取更全面简约的数据信息，避免过多冗余代码的产生，简化开发工作，提高代码质量与代码可读性。

参见图1，图1是根据本发明实施例示出的一种数据处理方法的流程图，如图1所示，该方法包括：

步骤101、获取目标界面上所显示的节点对应的操作对象的属性数据，操作对象为在目标界面对应的程序代码中所定义的对象。

其中，目标界面可以为多种类型的界面，例如，目标界面可以为大数据集群的部署界面。以目标界面为大数据集群的部署界面为例，目标界面上所显示的节点可以为大数据组件所包括的节点。

例如，大数据组件可以包括分布式文件系统(Hadoop Distributed File System，HDFS)组件、资源协调者(Yet Another Resource Negotiator，YARN)组件、分布式应用程式协调服务(Zookeeper)组件、数据库工具(Clickhouse)组件、数据仓库工具(Hive)组件、安全管理(Knox)组件、监控工具(如Prometheus、Grafana)组件等，此外，大数据集群还可以包括其他类型的组件，本发明对具体的组件类型不加以限定。

其中，HDFS组件包括NameNode(nn)节点、DataNode(dn)节点和SecondaryNameNode(sn)节点，YARN组件包括ResourceManager(rm)节点和NodeManager(nm)节点，Hive组件包括Hive(hv)节点，Clickhouse组件包括Clickhouse (ch)节点。

可选地，操作对象可以为文档对象模型(Document Object Model，DOM)对象。属性数据可以包括节点的位置数据、样式数据等，此外，属性数据还可以包括其他类型的数据，本发明对属性数据所包括的具体内容不加以限定。

步骤102、将所获取到的属性数据关联到对应的节点上。

步骤103、响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改，以使节点基于修改后的属性数据，显示在拖拽操作结束的位置。

通过在获取到目标节点上所显示的节点在程序代码中对应的操作对象的属性数据之后，将所获取到的属性数据关联到对应的节点上，从而使得在对目标节点上的节点进行拖拽操作时，可以直接基于拖拽操作对应的操作数据，来对节点所关联的属性数据进行修改，而无需进行操作对象的查找，使得通过简单的操作过程，即可实现对节点的拖拽显示，以使节点基于修改后的属性数据，显示在拖拽操作结束的位置。

在介绍了本发明的基本实现过程之后，下面对本发明的各个可选实施例进行介绍。

在一些实施例中，对于步骤101，在获取目标界面上所显示的节点对应的操作对象的属性数据时，可以基于目标界面上所显示的节点所处的位置，确定该节点对应的是哪个操作对象，从而获取该操作对象的属性数据。

对于步骤102，在将所获取到的属性数据关联到对应的节点上时，可以将所获取到的属性数据作为一种标记信息，标记到相应的节点上，同时，也将节点标识作为一种标记信息，标记到相应的属性数据上，从而实现属性数据和节点的关联。可选地，还可以采用其他方式实现属性数据和节点的关联，本发明对具体采用哪种方式不加以限定。

通过上述过程，即可实现属性数据和节点的双向绑定，以便后续可以直接基于对节点的操作来对属性数据进行修改，而无需通过修改操作对象实现。

在一些实施例中，属性数据可以包括位置数据，因而对于步骤103，在响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改时，可以响应于对目标界面上的节点的拖拽操作，基于拖拽操作结束的位置所对应的位置数据，对节点所关联的属性数据中的位置数据进行修改。

可选地，属性数据还可以包括其他类型的数据，本发明对属性数据的具体类型不加以限定。然而，无论属性数据是何种类型的数据，均可以通过如下过程实现步骤103：

步骤1031、响应于对目标界面上的节点的拖拽操作，通过属性获取指令，基于拖拽操作对应的操作数据，获取待修改的属性数据。

步骤1032、通过属性设置指令，确定待修改的属性数据对应的操作对象。

步骤1033、基于待修改的属性数据，对所确定出的操作对象对应的属性数据进行修改。

其中，属性获取指令可以为getAtttribute指令，属性设置指令可以为setAtttribute指令。

参见图2，图2是根据本发明实施例示出的一种拖拽功能的原理示意图，如图2所示，以操作对象为DOM对象为例，通过关联属性数据和界面中所显示的节点，从而使得在检测到对节点的拖拽操作后，可以直接基于拖拽操作同步修改属性数据，而在拖拽组件内部，可以基于被操作的节点确定对应的DOM对象，从而再对DOM对象进行修改。

需要说明的是，对于HTML5页面，原生的拖拽功能，需要通过拖拽事件获取到所拖拽的节点对应的操作对象，再通过操作对象对应的属性数据查找到业务所需的逻辑，如获取到DOM对象赋值给变量item，通过item.getAttribute指令获取DOM对象的属性数据，再通过item.setAttribute指令对属性数据进行修改，才能实现按照拖拽操作显示节点。

而本发明通过预先关联属性数据和节点，从而可以在节点被拖拽时直接对属性数据进行修改，而将查找操作对象和修改操作对象的过程封装到拖拽组件内部，从而使得用户仅需关注对数据的修改即可，从而使得在实际代码实现时仅需将待修改的属性数据赋值给i，通过i.isDeploy指令即可实现属性数据的修改，在这里看似只简化了一个单词，但是在实际开发中，对于HTML5页面原生的拖拽功能，大量的属性数据写在代码里，来对操作对象进行操作显得十分复杂，且易读性差，而操作数据可以使代码一目了然，只关注数据的改动，而无需关注操作对象的修改。

需要说明的是，上述过程是以直接对节点进行移动拖拽为例来进行说明的，也即是，在节点被拖拽后，即从节点被拖拽前所处的服务器中删除所显示的节点，而仅 在被拖拽后所处的服务器中显示该节点，以达到一种移动拖拽的效果为例来进行说明的，在更多可能的实现方式中，还可以被拖拽前节点所处的服务器中、以及被拖拽后节点所处的服务器中均显示该节点，以达到一种复制拖拽的效果。

则，在一些实施例中，在节点满足设定条件的情况下，可以响应于对目标界面上的节点的拖拽操作，为节点生成临时变量，通过临时变量，对节点修改前的属性数据进行存储。

例如，通过临时变量，可以对节点被拖拽前的位置数据进行存储。其中，位置数据可以为节点所处物理池对应的服务器标识以及节点在服务器中的索引值。

需要说明的是，通过上述过程，即可使得被拖拽前节点所处的服务器中、以及被拖拽后节点所处的服务器中均显示该节点，而为了便于用户区分，还可以将这两个节点显示为不同的样式。

在一些实施例中，属性数据还可以包括样式数据，样式数据用于指示节点的显示样式，如节点的边框样式(实线或虚线)、节点的颜色等。

在一种可能的实现方式中，响应于对目标界面上的节点的拖拽操作，将临时变量中所存储的属性数据所包括的样式数据修改为第一样式数据，将节点所关联的属性数据所包括的样式数据修改为第二样式数据，从而使得被拖拽前的节点以及基于节点的拖拽操作复制出来的节点可以被显示为不同的样式，便于用户区分。

参见图3，图3是根据本发明实施例示出的一种修改样式数据的原理示意图，如图3所示，以操作对象为DOM对象为例，通过预先将样式数据作为属性数据，与界面中所显示的节点进行关联，从而使得在检测到对节点的拖拽操作后，可以直接基于对节点的样式数据进行修改，而在拖拽组件内部，可以基于被操作的节点确定对应的DOM对象，从而再对DOM对象的样式数据进行修改。

在更多可能的实现方式中，属性数据还可以包括行为数据，行为数据用于指示节点在被拖拽时是否需要显示提示信息。

因此，可以响应于对目标界面上的节点的拖拽操作，获取被拖拽的节点所关联的属性数据；在属性数据所包括的行为数据指示节点在被拖拽时是否需要显示提示信息的情况下，显示提示信息，提示信息用于基于本次拖拽操作进行提示。其中，提示信息可以为弹框提示，消息提醒等。

通过为节点关联属性数据的方式，可以更好地控制操作过程，例如，只需判断 标记属性数据中的某些值，就可以在拖拽过程中触发其他行为，如弹框提示，消息提醒等，无需多次获取节点，简化操作逻辑。

此外，通过本发明所提供的方法，可以支持不同服务器中多种节点的拖拽，从而可以提高拖拽过程的灵活性。

上述过程主要是有关本发明对于拖拽功能的优化内容的介绍，通过本发明所提供的拖拽功能，即可通过在界面上的拖拽操作实现大数据集群的部署，以便后续可以通过大数据集群提供数据处理功能。

下面，分别对部署大数据集群以及通过大数据集群提供数据处理功能的过程进行介绍。

首先，对部署大数据集群的过程进行介绍。

在基于上述拖拽功能实现大数据集群的部署时，可以包括如下步骤：

步骤一、显示部署界面。

步骤二、响应于在部署界面的节点创建操作，在部署界面的临时资源池区域显示待部署节点，节点为大数据组件所包括的、用于提供数据管理功能的服务。

其中，临时资源池相当于一个虚拟池，临时资源池是为了方便用户的拖拽操作所设置的，临时资源池中所存储的节点并非真正等待进行部署的节点。通过将根据节点创建操作所生成的待部署节点显示在临时资源池对应的界面区域(也即是临时资源池区域)中，以便后续将节点拖拽到部署资源池对应的界面区域(也即是部署资源池区域)中，以便基于部署资源池中的节点部署方式来进行部署。

步骤三、响应于对临时资源池区域中的待部署节点的拖拽操作，在部署界面的部署资源池区域中的物理池中显示待部署节点。

其中，部署资源池中所显示的节点是真正要进行部署的节点，部署资源池中包括至少一个物理池，每个物理池都是一个实际的机器，通过部署资源池可以将不同机器的资源整合使用，相关技术人员可以根据实际需求来进行容器的部署。

步骤四、响应于在部署界面中的开始部署操作，按照待部署节点所处的物理池，在物理池对应的服务器上创建待部署节点对应的容器，容器用于提供大数据集群服务。

通过提供一个部署界面，以通过部署界面来提供大数据集群部署功能。相关技术人员通过在部署界面中对节点的拖拽操作以及对组件的触发操作，后台即可响应于 在部署界面中相应操作，自动完成容器的部署，以通过容器提供大数据集群服务。通过上述部署过程可以大大简化相关技术人员的操作，从而可以降低大数据集群的部署成本、提高部署效率。

在介绍了大数据集群部署过程的基本实现过程之后，下面介绍各个可选实施例。

在一些实施例中，为保证大数据集群部署过程的顺利进行，可以预先进行一些准备工作。可选地，可以预先准备至少一台服务器，用于部署大数据集群，且保证服务器间通信畅通。例如，可以预先准备n台服务器，n可以为大于等于的正整数，为便于说明，可以将这n台服务器记为S1、S2、…、Sn。

可选地，可以在这至少一台服务器中任选一台服务作为初始服务器，以便在初始服务器上预先部署所需的网络环境，以通过所部署的网络环境，来实现大数据集群的搭建。

在一种可能的实现方式中，在初始服务器上预先部署所需的网络环境的过程可以包括如下步骤：

步骤一、在初始服务器上安装目标运行环境，并在初始服务器上配置目标运行环境对应的接口。

其中，目标运行环境可以为应用引擎容器(Docker)环境，目标运行环境对应的接口可以为Docker应用程序接口(Application Programming Interface，API)。

例如，可以以服务器S1作为初始服务器，从而可以在服务器S1上安装Docker环境，并且在服务器S1上配置Docker API，以便后续可以通过Docker API支持对其他服务器上的Docker引擎的操作(例如，支持以RESTful方式来操作Docker引擎)。

步骤二、在初始服务器上创建目标运行环境对应的Overlay网络，并在初始服务器上初始化集群环境。

例如，可以在作为初始服务器的服务器S1上创建Docker环境的Overlay网络，并在初始服务器上进行Docker Swarm集群环境的初始化。

通过在初始服务器上创建目标运行环境对应的Overlay网络，使得后续大数据集群中所包括的组成部分之间可以通过Overlay网络来进行通信，以满足大叔级集群内部的通信需求。而通过在初始服务器上初始化集群环境，以提供大数据集群的搭建 基础，以便后续可以基于初始服务器来实现大数据集群的搭建。

步骤三、在初始服务器上创建大数据组件基础镜像，大数据组件基础镜像用于为容器提供构建基础。

其中，Overlay网络是使用网络虚拟化在物理基础设施之上建立连接的逻辑网络。相对于Overlay网络的概念，大数据集群中还包括UnderLay网络，Underlay网络是负责传递数据包的物理网络，由交换机和路由器等设备组成，借助以太网协议、路由协议和VLAN协议等驱动。相比于UnderLay网络，Overlay实现了控制平面与转发平面的分离，以满足容器的跨主机通信需求。

通过OverLay技术，可以在对物理网络不做任何改造的情况下，通过隧道技术在现有的物理网络上创建了一个或多个逻辑网络，有效解决物理数据中心存在的诸多问题，实现了数据中心的自动化和智能化。

例如，可在初始服务器上创建大数据组件基础Docker镜像，以便通过大数据组件基础Docker镜像，来提供大数据集群服务容器的启动功能。

需要说明的是，为了便于后续的容器化部署，可以将各种大数据组件所需的环境和软件预先打包成Docker镜像磁带归档(Tape Archive，Tar)包，并且预先将打包好的Docker镜像Tar包上传到初始服务器中，以便初始服务器可以通过对Docker镜像Tar包进行安装，以实现大数据组件基础镜像的创建。

其中，大数据集群可以包括多种类型的组件，例如，可以包括分布式文件系统(Hadoop Distributed File System，HDFS)组件、资源协调者(Yet Another Resource Negotiator，YARN)组件、分布式应用程式协调服务(Zookeeper)组件、数据库工具(Clickhouse)组件、数据仓库工具(Hive)组件、安全管理(Knox)组件、监控工具(如Prometheus、Grafana)组件等，此外，大数据集群还可以包括其他类型的组件，本发明对具体的组件类型不加以限定。

可选地，不同类型的大数据组件所需的环境和软件可以被打包到一个Docker镜像Tar包中，或者，可以将不同类型的大数据组件所需的环境和软件打包成不同的Docker镜像Tar包，例如，将HDFS组件、YARN组件和Zookeeper组件打包成一个Docker镜像Tar包，将Clickhouse组件、Hive组件、Knox组件、监控工具组件分别打包成一个Docker镜像Tar包，本发明对具体采用哪种方式不加以限定。

相应地，由于不同类型的大数据组件可以被一起打包成一个Docker镜像Tar 包，还可以被分开打包成多个Docker镜像Tar包，因而，在初始服务器上创建大数据组件基础镜像时，可以对包括多种类型的大数据组件所需的环境和软件的Docker镜像Tar包进行安装，以创建一个完整的大数据组件基础镜像，来满足多种类型的服务容器的启动需求，或者，可以对多个Docker镜像Tar包分别进行安装，以得到多个大数据组件基础镜像，以便通过各个大数据组件基础镜像，分别满足对应类型的服务容器的启动需求。

另外，需要说明的是，除了上述涉及到的大数据组件，开发人员还可以根据需求开发其他大数据组件对应的Docker镜像Tar包，并通过在初始服务器上上传并安装Docker镜像Tar包的方式热扩展增加支持的组件。

步骤四、在初始服务器上生成目标密钥文件。

可选地，可以采用对称加密算法或非对称加密算法来实现密钥的生成，此外，还可以采用其他算法来实现密钥的生成，本发明对此不加以限定。

其中，目标密钥可以为安全外壳协议(Secure Shell，SSH)公私钥。

通过生成目标密钥文件，以便后续可以在大数据集群中添加了新的服务器或创建了新的容器时，可以与新添加的服务器或新创建的容器共享目标密钥文件，使得后续大数据集群的服务器与服务器之间、或者服务器与容器之间均可以通过目标密钥实现免密通信。

通过上述过程即可完成构建大数据集群所需的基础网络环境的构建，从而使得后续可以基于已构建的基础网络环境，来将其他服务器添加至大数据集群中，以构建包括多个服务器的大数据集群。而且，还可以基于已构建的基础网络环境，在大数据集群中进行容器部署，以实现通过所部署的容器来为用户提供服务。

需要说明的是，上述过程仅介绍了对大数据集群的初始服务器的处理过程，在更多可能的实现方式中，相关技术人员还可以根据自己的实际需求，在大数据集群中添加服务器，以搭建包括多个服务器的大数据集群。

在一些实施例中，可以在部署界面中设置新增物理池控件，从而可以通过新增物理池控件，来将某个服务器加入大数据集群。例如，可以将新增物理池控件设置在部署资源池区域。参见图4，图4是根据本发明实施例示出的一种部署界面的界面示意图，如图4所示，该部署界面被划分为节点创建区域、临时资源池区域和部署资源池区域，其中，部署资源池区域中所设置的“增加物理池”按钮即为新增物理池控件， 通过“增加物理池”按钮，即可实现将服务器加入大数据集群。

通过在部署界面中设置新增物理池控件，以便用户可以根据实际的技术需求，来实现在大数据集群中增加服务器，以使所创建的大数据集群可以满足技术需求，进而保证后续数据处理过程的顺利进行。

在一种可能的实现方式中，可以通过如下过程实现物理池的新增，从而实现将某个服务器加入大数据集群：

步骤一、响应于对新增物理池控件的触发操作，显示增加物理池界面，增加物理池界面包括标识获取控件和密码获取控件。

参见图5，图5是根据本发明实施例示出的一种增加物理池界面的界面示意图，在新增物理池控件被触发后，即可在可视化界面上显示如图5所示的增加物理池界面，其中，文字提示为“IP”的输入框即为标识获取控件，文字提示为“密码”的输入框即为密码获取控件。

步骤二、通过标识获取控件获取待增加的物理池对应的服务器标识，通过密码获取控件获取待验证密码。

在一种可能的实现方式中，相关技术人员可以在标识获取控件中输入待加入大数据集群的服务器的服务器标识，在密码获取控件中输入预先设定好的密码，以便计算设备可以通过标识获取控件获取到待增加的物理池对应的服务器标识，通过密码获取控件获取到待验证密码。

可选地，在通过标识获取控件获取到待增加的物理池对应的服务器标识，通过密码获取控件获取到待验证密码之后，即可对待验证密码进行验证。

步骤三、在待验证密码验证通过的情况下，在部署资源池区域显示待增加的物理池。

通过设置标识获取控件，以便用户可以自行在标识获取控件中输入要加入大数据集群的服务器的服务器标识，以满足用户的定制化需求，而通过设置密码获取控件，以便用户可以在密码获取界面中输入待验证密码，以基于待验证密码对用户身份进行验证，以确定用户是否有权进行将服务器加入大数据集群的过程，从而保证大数据集群部署过程的安全性。

在一种可能的实现方式中，可以通过如下过程实现物理池的新增：

在待验证密码验证通过的情况下，在待验证密码验证通过的情况下，生成第二请求报文，从而将第二请求报文存储至第二消息队列中，进而从第二消息队列中获取第二请求报文，基于第二请求报文，向待增加的物理池对应的服务器发送安装文件，以便服务器可以在接收到安装文件的情况下对安装文件进行安装，以使服务器加入大数据集群。

其中，第二请求报文可以为JS对象简谱(Java Script Object Notation，JSON)格式的请求报文数据。可选地，第二请求报文还可以为其他类型的报文数据，本发明对此不加以限定。

以第二请求报文为JSON格式的请求报文数据为例，第二请求报文可以为如下形式的代码：

{

ip":"10.10.177.18",

"password":"root"

}

上述仅为一种示例性的第二请求报文，并不构成对第二请求报文的限定。

通过生成第二请求报文，以便计算设备可以基于第二请求报文实现相应的处理过程。

其中，安装文件可以包括各种类型的组件对应的Docker镜像Tar包以及红帽软件包管理器(Red-Hat Package Manager，RPM)安装包等，以便计算设备可以在接收到安装文件的情况下，通过安装RPM包实现预设脚本(包括第一预设脚本和第二预设脚本)的安装，其中，第一预设脚本用于实现环境安装功能，第二预设脚本用于实现集群加入功能，因而，计算设备可以通过第一预设脚本来对Docker镜像Tar包进行安装，以在待加入集群的服务器上实现环境安装，再在待加入集群的服务器上执行第二预设脚本，以使该服务器可以加入初始服务器的Docker Swarm集群。

可选地，计算设备可以关联有一个数据库，该数据库可以用于对大数据集群中的部署记录进行存储。例如，该数据库中可以包括第三部署表，第三部署表可以用于对增加物理池的操作进行记录。

在一些实施例中，在待验证密码验证通过的情况下，可以在第三部署表中生成服务器部署记录，服务器部署记录用于记录待增加的物理池对应的部署操作。

其中，可以在服务器部署记录中记录待增加的物理池对应的服务器的初始化状态，初始化状态至少包括待初初始化、初始化中、初始化错误和初始化完成，以便计算设备可以基于服务器部署记录中所记录的初始化状态，实现待增加的物理池在部署资源池区域的显示。

可选地，可以基于服务器部署记录中所记录的初始化状态，将待增加的物理池显示为不同的颜色。例如，在服务器部署记录中所记录的初始化状态为待初始化或初始化中时，可以将待增加的物理池显示为蓝色；在服务器部署记录中所记录的初始化状态为初始化完成时，可以将待增加的物理池显示为白色；服务器部署记录中所记录的初始化状态为初始化错误时，可以将待增加的物理池显示为红色，以便相关技术人员可以直观地观察到服务器的初始化状态。

例如，在待验证密钥刚刚验证通过，即使尚未开始在相应的服务器上进行文件安装，但部署资源池中已经显示有待增加的物理池，此时，该待增加的物理池对应的服务器在服务器部署记录中的初始化状态记录为待初始化，相应地，部署资源池区域所显示的待增加的物理池为蓝色。而在服务器上已经开始进行文件安装的情况下，该待增加的物理池对应的服务器在服务器部署记录中所记录的初始化状态为初始化中，此时，部署资源池区域所显示的待增加的物理池仍为蓝色。在服务器成功加入大数据集群的情况下，该待增加的物理池对应的服务器在服务器部署记录中所记录的初始化状态为初始化完成，相应地，部署资源池区域所显示的待增加的物理池为白色。另外，如果在初始化过程中出现任何问题导致服务器未成功加入大数据集群，则该待增加的物理池对应的服务器在服务器部署记录中所记录的初始化状态为初始化错误，相应地，部署资源池区域所显示的待增加的物理池为红色。

需要说明的是，计算设备可以每隔预设时长查询一次服务器初始化状态，从而基于查询到的初始化状态对待增加的物理池的显示方式进行更新。其中，预设时长可以为10秒，可选地，预设时长还可以为其他时长，本发明对预设时长的具体取值不加以限定。

可选地，还可以在服务器部署记录中记录失败原因，以便相关技术人员可以进行问题排查，其中，失败原因可以为IP地址或密码错误、无法连接待增加的物理池对应的服务器等。另外，还可以在服务器部署记录中记录请求触发时间、待增加的物理池对应服务器的服务器标识、待增加的物理池对应的服务器成功加入大数据集群的时间等，本发明对服务器部署记录所包括的具体内容不加以限定。

通过在数据库中维护第三部署表，以便可以在第三部署表中记录大数据集群在服务器层面的变更，以便后续可以从第三部署表中查询到所需的操作记录，以更加全面地满足用户需求。

需要说明的是，在服务器初始化完成之后，该服务器即可与大数据集群中已有的服务器组成Docker Swarm集群。另外，在服务器初始化错误的情况下，服务器即无法成功加入大数据集群，此时，服务器部署记录中所记录的该服务器的初始化状态即为初始化错误，而且，服务器部署记录中还记录有失败原因，则计算设备在查询到初始化状态为初始化错误的情况下，即可获取服务器部署记录中所记录的失败原因，从而即可基于获取到的失败原因显示第一提示信息，以便可以通过第一提示信息指示服务器未成功加入大数据集群的原因，便于相关技术人员及时进行针对性处理。

上述过程是以生成第二请求报文后，即基于第二请求报文来进行待验证密码的校验为例来进行说明的。可选地，在生成第二请求报文后，可以将第二请求报文存储至第二消息队列中，以便后续可以从第二消息队列中获取第二请求报文，来执行基于第二请求报文，对待验证密码进行验证的过程。

通过采用消息队列来对请求报文进行存储，可以实现显示侧对用户请求的同步处理以及后台的异步处理，以保证用户可以在当前请求报文未被真正处理完成的情况下，用户可以继续通过部署界面进行操作，而不会影响后台的处理过程，以保证后续的用户请求可以得到及时的响应。

此外，通过消息队列对请求报文进行存储，可以保证请求报文处理出现问题的情况下，可以从消息队列中重新获取未被成功处理的请求报文进行重试，而无需用户重新在界面上手动进行操作，简化用户操作，从而可以提高用户体验。

另外，在一些实施例中，在待验证密码验证通过的情况下，可以向待增加的物理池对应的服务器发送目标密钥，以便通过目标密钥用于在后续通信过程中实现身份验证，无需登录即可保证通信过程的安全性。

需要说明的是，上述过程是以在大数据集群中添加一个服务器的过程为例来进行说明的，重复上述过程即可完成将多个服务器加入大数据集群，具体过程可以参见上述实施例，此处不再赘述。

参见图6，图6是根据本发明实施例示出的一种部署界面的界面示意图，如图6所示，相较于如图4所示的部署界面，大数据集群中已经在初始服务器(服务器标 识为10.10.177.19)的基础上增加了两个服务器，这两个服务器的服务器标识分别为10.10.177.18和10.10.177.20。

可选地，在部署资源池区域中对物理池进行显示时，还可以显示有物理池的相关信息，如物理池所对应的服务器的服务器标识、当前存储使用率、内存占用率和分配内存占用率等。

例如，对于部署资源池区域中所显示的任一物理池，可以在物理池的第二目标位置处显示物理池所对应的服务器的服务器标识，在物理池的第三目标位置处显示物理池所对应的服务器的当前存储使用率、内存占用率和分配内存占用率。

其中，第二目标位置可以为所显示的物理池的左上角，第三目标位置可以为所显示的物理池的右下角。仍以图6所示的部署界面为例，如图6所示的部署界面即在各个物理池的左上角显示有对应服务器的服务器标识，在各个物理池的右下角显示有对应服务器的当前存储使用率、内存占用率和分配内存占用率。可选地，第二目标位置和第三目标位置还可以为其他位置，本发明对此不加以限定。

通过在物理池中对相应服务器的相关状态信息进行显示，以便用户可以直观地看到各个物理池对应的服务器的一些状态数据，如当前存储使用率、内存占用率和分配内存占用率等，以使用户可以及时获知各个服务器的状态，便于用户基于各个服务器的状态来进行容器的创建。

可选地，可以实时获取各个服务器的状态数据，从而基于获取到的状态数据，来在物理池上对应的位置处显示各个服务器的状态。

通过基于实时获取到的状态数据实现服务器状态的显示，可以保证数据的实时性和有效性，从而使得用户通过所显示的内容获取到的服务器状态更加真实可靠。

通过上述过程即可完成大数据集群的硬件环境的搭建，以得到包括至少一台服务器的大数据集群，从而即可在这至少一台服务器上进行容器化部署，以使大数据集群可以为用户提供大数据处理功能。

在一些实施例中，部署界面包括节点创建区域，节点创建区域包括节点创建控件和至少一个大数据组件。

需要说明的是，虽然大数据组件可以包括HDFS组件、YARN组件、Clickhouse组件、Hive组件、Knox组件、监控工具组件等多种类型的组件，但有些组件是在配置初始服务器时就会默认配置好的，无需用户手动操作，因而，上述几种大数据组件 并非都会显示在节点创建区域中。一般情况下，节点创建区域所显示的组件可以包括HDFS组件、YARN组件、Clickhouse组件、Hive组件。

为便于理解，下面对各个组件适用的场景进行介绍。以大数据组件包括HDFS组件、YARN组件、Clickhouse组件和Hive组件为例，HDFS组件可以用于提供数据存储功能，也即是，若要为用户提供数据存储功能，则需要在大数据集群中部署HDFS组件的节点对应的容器，以便通过所部属的容器为用户提供数据的分布式存储服务，以满足用户的需求。

YARN组件可以用于提供数据分析功能，也即是，如要为用户提供数据分析功能，则需要在大数据集群中部署YARN组件的节点对应的容器，以便通过YARN组件的节点对应的容器，从HDFS组件的节点对应的容器中获取数据，并基于获取到的数据进行数据分析，以满足用户的数据分析需求。

Hive组件可以将HDFS组件的节点对应的容器中所存储的数据转换为一张可查询的数据表，以便可以基于数据表进行数据查询及处理等过程，以满足用户的数据处理需求。

需要说明的是，虽然YARN组件和Hive组件都可以为用户提供数据分析功能，但有所不同的是，如果要用YARN组件实现数据分析过程，则需要开发一系列代码，以在将数据处理任务提交到YARN组件中之后，通过所开发的代码来基于数据处理任务进行相应的数据处理过程，而如果要用Hive组件实现数据分析过程，仅需使用结构化查询语言(Structured Query Language，SQL)语句即可实现对数据处理任务的处理。

Clickhouse组件为一种列式存储数据库，可以用于满足用户对大量数据的存储需求，相较于常用的行式存储数据库，Clickhouse组件的读取速度更快，而且，Clickhouse组件可以对数据分区进行存储，用户可以根据自己的实际需求，仅获取某一个或某几个分区中的数据来进行处理，而无需获取数据库中的所有数据，从而可以降低计算设备的数据处理压力。

仍以如图6所示的部署界面为例，在如图6所示的部署界面中，所显示的大数据组件包括HDFS组件、YARN组件、Hive组件和Clickhouse组件，如图6所示的部署界面中的“应用”按钮即为节点创建控件。

在一些实施例中，在响应于在部署界面的节点创建操作，在部署界面的临时资源池区域显示待部署节点时，可以通过如下方式实现：

在任一大数据组件被选中的情况下，响应于对节点创建控件的触发操作，在临时资源池区域中显示被选中的大数据组件对应的待部署节点。

需要说明的是，不同的组件所包括的节点是不同的，下面对各个组件所包括的节点类型进行说明。

HDFS组件包括NameNode(nn)节点、DataNode(dn)节点和SecondaryNameNode(sn)节点，YARN组件包括ResourceManager(rm)节点和NodeManager(nm)节点，Hive组件包括Hive(hv)节点，Clickhouse组件包括Clickhouse(ch)节点。

基于上述组件与节点之间的关系，计算设备即可根据被选中的大数据组件，来在临时资源池区域显示相应的节点，作为待部署节点。

需要说明的是，由于大数据组件还可能有版本的区分，或者说，同一个大数据组件可能有多个可选的版本，因而，节点创建区域还可以设置有节点参数设置控件，节点参数设置控件可以用于设置待部署节点的版本。

基于此，在一些实施例中，在响应于对节点创建控件的触发操作，在临时资源池区域中显示被选中的大数据组件对应的待部署节点时，可以响应于对节点创建控件的触发操作，在临时资源池区域中显示通过节点参数设置控件所设置的版本对应的待部署节点。

例如，HDFS组件、YARN组件可以包括高可用(High Availability，HA)版本和非高可用版本。需要说明的是，HDFS组件和YARN组件的版本需要保持一致。

仍以如图6所示的部署界面为例，在被选中的组件为HDFS组件或YARN组件的情况下，标记文字为“节点参数”下“HA”对应的勾选框即为节点参数设置控件，在“HA”对应的勾选框被选中的情况下，即表示要部署的HDFS组件或YARN组件为HA版本，在“HA”对应的勾选框未被选中的情况下，即表示要部署的HDFS组件或YARN组件为非HA版本。另外，需要说明的是，由于Hive组件和Clickhouse组件无需区分HA版本和非HA版本，因此，在被选中的组件为Hive组件或Clickhouse组件的情况下，标记文字为“节点参数”下所显示的文字即会变为“无”，从而使得无需对Hive组件和Clickhouse组件的版本进行区分。

通过在部署界面中设置节点参数设置控件，以便用户可以根据实际技术需求，对大数据组件的版本进行选择，从而可以满足用户的定制化需求。

此外，在已经通过节点参数设置控件设置了版本的情况下，如果节点已经开始 部署，则无法对所设置的版本进行修改，而如果节点还未开始部署，则用户还可以对所设置的版本进行修改，相应地，在版本修改后临时资源池区域所显示的节点会被清空，以便用户重新进行节点的创建。

需要说明的是，在已选择大数据组件的情况下，每次触发节点创建控件时要添加的待部署节点的节点类型和节点数量都是预先设置好的。而一般情况下，HDFS组件、YARN组件、Hive组件和Clickhouse组件在大数据集群中的使用最为广泛，下面主要以HDFS组件、YARN组件、Hive组件和Clickhouse组件为例来进行说明。

其中，不同版本、不同组件的初始状态(也即是第一次点击节点创建控件的时候)下的节点类型和节点数量如下：

HA版本的HDFS组件的初始状态：1个nn节点、1个sn节点、4个dn节点；

非HA版本的HDFS组件的初始状态：3个nn节点、4个dn节点；

HA版本的YARN组件的初始状态：1个rm节点、1个nm节点；

非HA版本的YARN组件的初始状态：3个rm节点、1个nm节点；

Hive组件：1个hv节点；

Clickhouse组件：1个ch节点。

其中，nn节点是HDFS组件的核心节点，用于提供数据管控功能，而非HA版本的HDFS组件仅包括1个nn节点，一旦该节点发生故障，则会导致HDFS组件无法再提供相应的功能，然而，HA版本的HDFS组件包括3个nn节点，其中，1个nn节点处于激活(Active)状态，另外2个nn节点处于准备(Standby)状态，开始时可以由处于Active状态的nn节点进行工作，而一旦处于Active状态的nn节点出现故障，即可激活处于Standby状态的nn节点，以保证HDFS组件的正常工作，从而可以达到高可用的效果。

同理，rm节点是YARN组件的核心节点，用于提供数据管控功能，而非HA版本的YARN组件仅包括1个rm节点，一旦该节点发生故障，则会导致YARN组件无法再提供相应的功能，然而，HA版本的YARN组件包括3个rm节点，其中，1个rm节点处于Active状态，另外2个rm节点处于Standby状态，开始时可以由处于Active状态的rm节点进行工作，而一旦处于Active状态的rm节点出现故障，即可激活处于Standby状态的rm节点，以保证YARN组件的正常工作，从而可以达到高可用的效果。

另外，需要说明的是，对于HDFS组件的nn节点和sn节点、YARN组件的rm节点和nm节点、Hive组件的hv节点以及Clickhouse组件的ch节点，其在初始状态下的节点数量是基于Hadoop架构的技术需求确定，而对于HDFS组件的dn节点，其在初始状态下的节点数量是由于HDFS组件的默认副本数为3，为保证在各个副本上移动节点不会丢失数据，因此设置了4个dn节点。

需要说明的是，对于HDFS组件，用户可以根据实际技术需求增加dn节点的数量，但nn节点和sn节点的数量是无法增加的；对于YARN组件，用户可以根据实际技术需求增加nm节点的数量，但rm节点的数量是无法增加的；对于Hive组件和Clickhouse组件，其对应的节点(也即是hv节点和ch节点)的数量均是无法增加的。

为便于理解，下面以表格的形式对每次触发节点创建控件时要添加的待部署节点的节点类型和节点数量进行说明，参见如下表1：

表1

通过上表可以看出，在大数据组件为HA版本的HDFS组件的情况下，第一次点击节点创建控件时可以在临时资源池区域添加3个nn节点和4个dn节点，第二次点击节点创建控件时可以在临时资源池区域添加1个dn节点，以此类推，后续每次点击创建控件时均可以在临时资源池区域添加1个dn节点；在大数据组件为非HA版本的HDFS组件的情况下，第一次点击节点创建控件时可以在临时资源池区域添加1个nn节点、1个sn节点、4个dn节点，第二次点击节点创建控件时可以在临时资源池区域添加1个dn节点，以此类推，后续每次点击创建控件时均可以在临时资源池区域添加1个dn节点；在大数据组件为HA版本的YARN组件的情况下，第一次点击节点创建控件时可以在临时资源池区域添加3个rm节点和4个nm节点，第二次点击节 点创建控件时可以在临时资源池区域添加1个nm节点，以此类推，后续每次点击创建控件时均可以在临时资源池区域添加1个nm节点；在大数据组件为非HA版本的YARN组件的情况下，第一次点击节点创建控件时可以在临时资源池区域添加1个rm节点和1个nm节点，第二次点击节点创建控件时可以在临时资源池区域添加1个nm节点，以此类推，后续每次点击创建控件时均可以在临时资源池区域添加1个nm节点；在大数据组件为Hive组件的情况下，第一次点击节点创建控件时可以在临时资源池区域添加1个hv节点，后续再点击节点创建控件也无法再增加Hive组件对应的节点个数；在大数据组件为Clickhouse组件的情况下，第一次点击节点创建控件时可以在临时资源池区域添加1个ch节点，后续再点击节点创建控件也无法再增加Clickhouse组件对应的节点个数。

下面以几个示例性的节点创建过程为例，来对本发明的节点创建过程进行说明。

例如，仍以如图4所示的部署界面为例，在仅要部署非HA版本的HDFS组件对应的节点的情况下，在如图4所示的界面中选中HDFS组件，使得HDFS组件处于被选中状态，再点击“应用”按钮(也即是节点创建控件)，即可在临时资源池区域显示1个nn节点、1个sn节点和4个dn节点。

又例如，仍以如图4所示的部署界面为例，在要部署HDFS组件、YARN组件、Hive组件和Clickhouse组件对应的节点的情况下，在如图4所示的界面中先选中HDFS组件，使得HDFS组件处于被选中状态，再点击“应用”按钮(也即是节点创建控件)，即可在临时资源池区域显示1个nn节点、1个sn节点和4个dn节点；然后选中YARN组件，使得YARN组件处于被选中状态，再点击“应用”按钮，即可在临时资源池区域显示1个rm节点和1个nm节点；再选中Hive组件，使得Hive组件处于被选中状态，再点击“应用”按钮，即可在临时资源池区域显示1个hv节点；最后选中Clickhouse组件，使得Clickhouse组件处于被选中状态，再点击“应用”按钮，即可在临时资源池区域显示1个ch节点。

又例如，仍以如图4所示的部署界面为例，在仅要部署HA版本的HDFS组件对应的节点的情况下，在如图4所示的界面中选中HDFS组件，使得HDFS组件处于被选中状态，再勾选“HA”对应的勾选框，然后再点击“应用”按钮(也即是节点创建控件)，即可在临时资源池区域显示3个nn节点4个dn节点。

又例如，仍以如图4所示的部署界面为例，在要部署HA版本的HDFS组件、 HA版本的YARN组件、Hive组件和Clickhouse组件对应的节点的情况下，在如图4所示的界面中先选中HDFS组件，使得HDFS组件处于被选中状态，再勾选“HA”对应的勾选框，然后再点击“应用”按钮(也即是节点创建控件)，即可在临时资源池区域显示3个nn节点和4个dn节点；然后选中YARN组件，使得YARN组件处于被选中状态，再勾选“HA”对应的勾选框，然后再点击“应用”按钮，即可在临时资源池区域显示3个rm节点和1个nm节点；再选中Hive组件，使得Hive组件处于被选中状态，再点击“应用”按钮，即可在临时资源池区域显示1个hv节点；最后选中Clickhouse组件，使得Clickhouse组件处于被选中状态，再点击“应用”按钮，即可在临时资源池区域显示1个ch节点。

需要说明的是，在部署了各个大数据组件对应的节点后，即可基于各种类型的节点的预估占用内存，来确定各个服务器的内存占用情况。需求强调的是，如果将HDFS组件和YARN组件部署为HA版本，虽然前端部署界面并未展示出Zookeeper(简称zk)节点，但在实际的集群部署过程中zk节点是需要部署的，因而在确定预估占用内存时，需要增加3个zk节点的占用内存。

其中，各种类型的节点的预估占用内存可以参见如下表2：

表2

计算设备即可根据如表2中所示的数据以及用户所部署的各个节点的个数，实现预估占用内存的确定。

上述过程是以用户根据自己的实际需求选择所需的大数据组件，并根据自己的需求来进行节点的创建，在更多可能的实现方式中，本发明还可以提供配置推荐功能，当用户无法确定需要部署的大数据组件的类型和需要部署的节点个数时，可以通过本发明所提供的配置推荐功能，来获取推荐的较优配置方式，该配置方式也即包括部署的大数据组件的类型和需要部署的节点个数。

在一些实施例中，可以通过如下过程实现配置推荐过程：

步骤一、显示部署指示界面。

步骤二、通过部署指示界面获取待部署的大数据组件类型、组件版本和目标数据，目标数据用于指示数据处理需求所需的每秒存储数据条数。

其中，部署指示界面可以提供多个可部署的大数据组件选项、候选组件版本和一个数据获取控件。可选地，大数据组件选项可以被设置为勾选框，以便用户可以根据自己的实际需求勾选要部署的大数据组件，以便计算设备可以获取到待部署的大数据组件类型；候选组件版本的形式可以参见如上所述的节点参数设置控件，此处不再赘述；数据获取控件可以被提供为一个输入框，以便用户可以通过部署指示界面上所设置的数据获取控件，来输入指示数据处理需求所需的每秒存储数据条数的目标数据，从而使得计算设备可以通过部署指示界面获取到目标数据。

步骤三、基于待部署的大数据组件类型、组件版本、目标数据和预设参数，确定各种类型的待部署节点对应的推荐部署个数。

需要说明的是，基于待部署的大数据组件类型和组件版本，即可确定出nn节点、sn节点、rm节点、hv节点和ch节点的推荐部署数量。而对于dn节点和nm节点的推荐部署个数，可以通过如下方式确定：

为便于理解，先介绍一下预设参数的，预设参数可以为预先设置好的每秒存储数据条数阈值。基于此，在确定dn节点的推荐部署个数时，可以对目标数据和预设参数的大小进行比较，在目标数据小于等于预设参数的情况下，可以将dn节点的推荐部署个数确定为4；在目标数据大于预设参数的情况下，可以按照“dn节点的推荐部署个数＝目标数据/(预设参数/4)”的公式，来确定出dn节点的推荐部署个数。而在确定nm节点的推荐部署个数时，也可以基于目标数据和预设参数的大小比较结果，来进行nm节点的推荐部署个数的确定，在目标数据小于等于预设参数的情况下，可以将nm节点的推荐部署个数确定为1；而在目标数据大于预设参数的情况下，可以将dn节点的推荐部署个数的一半确定为nm节点的推荐部署个数。

此外，计算设备还可以基于各种类型的待部署节点的推荐部署个数，确定预估占用内存。在确定预估占用内存时，需求强调的是，如果将HDFS组件和YARN组件部署为HA版本，虽然前端部署界面并未展示出Zookeeper(简称zk)节点，但在实际的集群部署过程中zk节点是需要部署的，因而在确定预估占用内存时，需要增加3个zk节点的占用内存。

下面以部署HA版本的HDFS组件、HA版本的YARN组件、Hive组件、Clickhouse组件，目标数据为40w/s(每秒存储数据条数)，预设参数为20w/s为例，确定各种类型的节点的推荐部署个数以及预估占用内存：

其中，dn节点的推荐部署个数为40/(20/4)＝8，nm节点的推荐部署个数为4，为便于查看，下面以表格的形式介绍各种类型的节点的推荐部署个数，参见如下表3：

表3

需要说明的是，在确定出各种类型的待部署节点的推荐部署个数后，即可在部署指示界面中显示所确定出的推荐部署个数，以便用户进行查看。

可选地，还可以在部署指示界面中显示提示信息，提示信息可以用于提示推荐部署个数仅供参考，用户可以根据实际情况，来增加或减少待部署节点的个数。

另外，用户还可以根据实际情况，来将待部署节点部署到多个物理池中。此外，需要注意的是，如果待部署节点为HA版本，则可以通过可视化界面向用户建议至少设置3个物理池，以将3个nn或3个rm分别部署到不同的服务器上，以真正实现大数据集群的高可用。

另外，需要说明的是，HA版本的HDFS组件和YARN组件需要用到Zookeeper集群，因此，若用户选择的大数据组件是HA版本的HDFS组件或YARN组件，则计算设备会在部署HDFS组件或YARN组件对应节点的服务器上默认部署一个3节点的Zookeeper集群，因而，Zookeeper组件无需展示在前端的部署界面中，也可在需要的时候完成Zookeeper组件的部署。而在HA版本的HDFS组件和YARN组件、以及其他组件中，则无需部署Zookeeper组件。

此外，需要强调的是，不同大数据组件之间是有依赖关系的，因而，在进行节点的创建时，需要相关技术人员按照组件之间的依赖关系来进行大数据组件的选择，从而进行节点的创建。

例如，YARN组件对应节点的部署与使用需要基于HDFS组件，也即是，要先 部署HDFS组件对应的节点，再部署YARN组件对应的节点，如果在未部署HDFS组件的对应节点的情况下直接部署YARN组件对应的节点，前端页面会提示错误；Hive组件对应节点的部署与使用需要基于HDFS和YARN组件，也即是，要先部署HDFS组件和YARN组件对应的节点，再部署Hive组件对应的节点，如果在未部署HDFS和YARN组件的对应节点的情况下直接部署Hive组件对应的节点，前端页面会提示错误；Clickhouse组件对应节点是独立的节点，与其他组件对应的节点之间无依赖关系。

上述推荐部署过程的流程可以参见图7，图7是根据本发明实施例示出的一种推荐部署过程的流程图，如图7所示，可以通过部署指示界面获取待部署的大数据组件类型和组件版本，如果在待部署的大数据组件仅包括Clickhouse组件的情况下，即可直接确定出ch节点的推荐部署个数为1，从而即可确定出预估占用内存；而在待部署的大数据组件还包括除Clickhouse组件外的其他组件的情况下，可以通过部署指示界面获取目标数据，从而确定目标数据是否大于预设参数，在目标数据大于预设参数的情况下可以通过上述过程中所描述的公式来进行节点推荐部署个数的确定，而在目标数据小于等于预设参数的情况下，即可采用默认推荐节点个数作为推荐部署个数；进一步地，还需要根据组件版本确定要部署的节点是否包括HA版本的节点，在包括HA版本的节点的情况下，需要增加HA版本的相关节点(如zk节点)，从而再基于推荐部署个数以及增加的HA版本的相关节点来进行预估占用内存的确定，而在不需要增加HA版本的相关节点的情况下，直接基于推荐部署个数来进行预估占用内存的确定即可。

需要说明的是，无论是用户根据自己的需求自行创建待部署节点，还是根据计算设备推荐的节点个数来进行待部署节点的创建，在创建了待部署节点之后，待部署节点即可显示在临时资源池区域，用户可以将临时资源池区域的待部署节点拖拽到部署资源池区域的物理池中，以便计算设备可以响应于对临时资源池区域中的待部署节点的拖拽操作，在部署界面的部署资源池区域中的物理池中显示待部署节点。

其中，部署资源池区域可以包括至少一个物理池。在一些实施例中，在响应于对临时资源池区域中的待部署节点的拖拽操作，在部署界面的部署资源池区域中的物理池中显示待部署节点时，对于任一待部署节点，可以响应于对待部署节点的拖拽操作，将待部署节点显示在拖拽操作结束时所指示的物理池中。

通过为部署界面中所显示的节点提供拖拽功能，以便用户可以根据实际技术需 求，来将各个待部署节点拖拽到对应的物理池中，以满足用户的定制化需求。

可选地，部署界面还可以设置有自动分配控件，以便用户可以通过自动分配控件，来将临时资源池区域中的待部署控件自动分配到部署资源池区域内的各个物理池中。

参见图8，图8是根据本发明实施例示出的一种部署界面的界面示意图，如图8所示，图8中的“自动分配”按钮即为自动分配控件，临时资源池中已添加了HDFS组件对应的节点(也即是3个nn节点和4个dn节点)、YARN组件对应的节点(也即是3个rm节点和1个nm节点)、Hive组件对应的节点(也即是1个hv节点)和Clickhouse组件对应的节点(也即是1个ch节点)，通过触发“自动分配”按钮，即可将临时资源池中的这些节点自动分配到部署资源池的各个物理池中。

通过在部署界面中设置自动分配控件，使得用户无需手动拖拽即可将待部署节点分配到部署资源池的各个物理池中，从而可以简化用户操作，提高节点分配效率。

参见图9，图9是根据本发明实施例示出的一种节点分配过程的示意图，如图9所示，以临时资源池区域包括8个节点为例，可以通过自动分配或拖拽的方式，将这8个节点分配到3个物理池中，例如，将节点1、节点2和节点3分配到物理池1中，将节点4、节点5和节点6分配到物理池2中，将节点7和节点8分配到物理池3中，其中，一个物理池对应于大数据集群中的一个服务器。而每个节点在服务器上进行部署时，均会被部署为一个容器，因而，一个节点即为服务器中的一个容器。

此外，临时资源池区域中的待部署节点还支持拖拽删除功能，用户可以通过将临时资源池区域中的待部署节点拖拽到指定位置，从而实现对待部署节点的删除。仍以如图4所示的部署界面为例，界面左下角“拖动节点到此处删除”的位置即为指定位置。

需要强调的是，由于临时资源池区域中存放的都是临时节点，当离开页面或刷新页面时，页面会被重置，从而使得页面会清空临时资源池中的所有节点。

需要说明的是，在将临时资源池区域中的待部署节点均拖拽到部署资源池区域后，即可响应于在部署界面中的开始部署操作，按照待部署节点所处的物理池，在物理池对应的服务器上部署待部署节点对应的容器。

在一些实施例中，在响应于在部署界面中的开始部署操作，按照待部署节点所处的物理池，在物理池对应的服务器上部署待部署节点对应的容器时，可以包括如下 步骤：

步骤一、响应于开始部署操作，基于待部署节点所属的大数据组件的组件类型，确定目标插件。

其中，目标插件可以为开发人员根据统一开发规范开发的二进制包，开发人员可以在目标插件开发完成后，将目标插件上传至大数据集群的初始化服务器中，以便可以初始化服务器可以将目标插件存储至大数据集群中的设定位置处。其中，设定位置可以为初始服务器中的plugins文件目录下。

需要说明的是，不同类型的组件可以对应于不同的目标插件，但每个插件的开发过程都需要遵循插件开发规范，统一开发start方法用来启动服务、restart方法来重启服务、decommission方法来退役节点的功能。

步骤二、通过目标插件，启动位于物理池对应的服务器上的目标接口。

步骤三、通过目标接口，在物理池对应的服务器上部署待部署节点对应的容器。

在一种可能的实现方式中，上述步骤三可以通过如下过程实现：

步骤1、通过目标插件读取第一配置文件，以从第一配置文件中获取目标安装环境。

其中，第一配置文件可以为app.json配置文件，可选地，第一配置文件内可以包括镜像名、版本号、Docker网络名称、储存数据的MYSQL信息、RabbitMQ信息等。

在一种可能的实现方式中，可以基于第一配置文件所包括的Docker网络名称和镜像名，确定目标安装环境。其中，目标安装环境可以为HDFS组件对应的Docker网络环境、YARN组件对应的Docker网络环境、Hive组件对应的Docker网络环境、Clickhouse组件对应的Docker网络环境，等等。

步骤2、通过目标接口，对服务器的目标安装环境的配置文件进行修改，以在物理池对应的服务器上部署待部署节点对应的容器。

需要说明的是，不同的目标安装环境对应的配置文件不同，因而，在部署不同组件对应的容器时，需要修改的配置文件也不相同。部署HDFS组件对应的容器时需要修改core-site.xml和hdfs-site.xml这两个配置文件，部署YARN组件对应的容器时需要修改配置文件yarn-site.xml，部署Clickhouse组件对应的容器时需要修改 config.xml和users.xml这两个配置文件，同时，由于上述部署过程均是在大数据集群中进行操作，因而，还需要修改集群启动时需要修改的配置文件workers，等等，但是，需要强调的是，这些繁杂的部署过程都无需手动修改，程序可自动生成参数、自动完成配置文件的修改。

为便于查看，以图的形式来展示各个组件在进行不同操作时需要修改的配置文件，参见图10，图10展示出了多种大数据组件在进行不同操作时需要修改的配置文件。

通过上述插件化开发过程，可以实现插件热插拔和插件统一开发，降低集群搭建技术门槛。而且，对于开发人员来说，插件根据统一开发规范，拥有统一模板的方法、配置、功能，不仅可以增加可读性，还可以减少插件间的冲突问题；对于用户来说，插件被规范封装，用户无需理解后端插件的执行方式，即可操控插件，从而可以减少出现问题的隐患。

通过插件，即可将服务部署在容器中，实现大数据集群轻量化，解决资源浪费的问题，插件通过启动提前打好的镜像包，即可实现环境搭建，提高搭建效率。而且，使用Docker和插件，后期可以很方便地对服务进行移动，从而可以减少开发和维护成本。

完成配置文件的修改后，程序会自动完成拷贝、容器间统一配置、启动服务等操作，以完成容器的部署。例如，在修改完配置文件后，即可通过如下过程实现容器的部署。

步骤一、基于待部署节点以及待部署节点所处的物理池，生成第一请求报文，第一请求报文用于指示在物理池对应的服务器上部署待部署节点对应的容器。

在一种可能的实现方式中，可以基于待部署节点以及待部署节点所处的物理池生成JSON格式的请求报文数据，从而将所生成的JSON格式的请求报文数据作为第一请求报文，以便后续可以基于第一请求报文实现容器的部署。

需要说明的是，第一请求报文中可以携带n个待部署节点对应的信息，例如，可以携带每个待部署节点对应的待创建容器的容器名称(containerName)和容器类型(containerType)。

可选地，在生成第一请求报文后，可以将第一请求报文存储至第一消息队列中，以便后续可以从第一消息队列中获取第一请求报文，来执行基于第一请求报文和物理 池对应的服务器上的已部署容器以及已部署容器中的待删除容器，确定待部署节点对应的部署操作类型以及已部署容器中的待删除容器的步骤。

通过采用消息队列来对请求报文进行存储，可以实现显示侧对用户请求的同步处理以及后台的异步处理，以保证用户可以在当前请求报文未被真正处理完成的情况下，用户可以继续通过部署界面进行操作，而不会影响后台的处理过程，以保证后续的用户请求可以得到及时的响应。

在更多可能的实现方式中，在生成第一请求报文后，可以对第一请求报文的数据格式进行校验，和/或，按照预设部署规则，对第一请求报文所携带的部署数据进行校验，从而在校验通过的情况下，再将第一请求报文存储至第一消息队列中。

通过对第一请求报文进行校验，可以保证第一请求报文的合法性和有效性，从而可以保证处理过程的安全性。

步骤二、基于第一请求报文和物理池对应的服务器上的已部署容器，确定待部署节点对应的部署操作类型以及已部署容器中的待删除容器，部署操作类型包括新增节点、移动节点和不改变节点。

在一种可能的实现方式中，可以对第一请求报文所携带的待部署节点对应的待创建容器，与服务器上的已部署容器进行比较，以确定哪些待部署节点是需要增加的节点(即需要在服务器中为其创建对应的容器)、哪些待部署节点是需要移动的节点(即需要将其对应的容器从一个服务器移动到另一个服务器中)、哪些待部署节点是无需改变的节点，并且，可以确定出哪些已部署容器是需要删除的容器(即需要在服务器中删除对应的已部署容器)。

下面以几个具体示例为例，来对步骤二所描述的过程进行介绍。为便于理解，首先对不同containerType对应的容器类型进行介绍：

containerType＝1→NameNode；

containerType＝1→DataNode；

containerType＝3→ResourceManager；

containerType＝4→NodeManager；

containerType＝5→Secondary NameNode；

containerType＝6→Clickhouse；

containerType＝7→Hive；

containerType＝8→Zookeeper；

containerType＝11→HANameNode；

containerType＝12→HADataNode；

containerType＝13→HAResourceManager；

containerType＝14→HANodeManager。

结合上述内容，接下来对几个示例分别进行介绍：

示例一中，共两个服务器(服务器标识分别为10.10.86.214和10.10.86.215)，其中，每个服务器下需要部署的容器可以参见图11，图11是根据本发明实施例示出的一种部署数据示意图，如图11所示，服务器10.10.86.214下共有3个需要部署的容器，其中，containerType为1、5两个容器的containerName为空，表示NameNode、SecondaryNameNode两个节点对应的容器为需要进行部署的新容器，从而可以确定NameNode、SecondaryNameNode两个节点的部署操作类型为新增节点；containerType为6的containerName不为空，表示ClickHouse节点对应的容器之前被部署过；而服务器10.10.86.215下共有4个需要部署的容器，containerType均为2，表示需要部署4个DataNode节点对应的新容器。

当示例一的部署操作完成后，会获取到如示例二所示的部署结果数据，而通过比较示例一和示例二的部署结果，即可确定示例二中containerType为6的容器，在本次部署中未出现，可以判断出本次部署时该组件已被删除。

示例三中，共两个服务器(服务器标识分别为10.10.86.214和10.10.86.215)，其中，每个服务器下需要部署的容器可以参见图12，图12是根据本发明实施例示出的一种部署数据示意图，如图12所示，服务器10.10.86.214下containerType为1、5两个容器之前部署过，本次部署的IP地址未改变，表示NameNode、SecondaryNameNode两个节点对应的容器本次无需重新进行部署，从而可以确定NameNode、SecondaryNameNode两个节点的部署操作类型为未改变节点；containerType为2容器之前部署过，本次部署的IP地址由10.10.86.215变更为10.10.86.214，说明部署容器由服务器10.10.86.214移动到服务器10.10.86.215，从而可以确定DataNode节点的部署操作类型为移动节点；containerType为7的容器的containerName为空，表示Hive节点对应的容器为需要进行部署的新容器，从而可以确定Hive节点的部署操作类型为 新增节点；而服务器10.10.86.215下共有3个需要部署的容器，containerType均为2，且本次部署的IP地址未改变，表示4个DataNode节点的部署操作类型均为未改变节点。

当示例三的部署操作完成后，即可获取到如示例四所示的部署结果数据。

步骤三、按照待部署节点对应的部署操作类型以及已部署容器中的待删除容器，在物理池对应的服务器上进行容器部署。

在一种可能的实现方式中，在部署操作类型为新增节点的情况下，调用待部署节点的节点类型对应的组件插件，在物理池对应的服务器上创建待部署节点对应的容器。

其中，节点类型与组件插件之间的对应关系都是预先设置好的，基于待部署节点的节点类型，即可找到对应的组件插件，从而可以通过对应的组件插件来进行容器的创建。

在另一种可能的实现方式中，在部署操作类型为移动节点的情况下，从已部署待部署节点对应容器的服务器上删除待部署节点对应的已部署容器，在物理池对应的服务器中创建待部署节点对应的容器，并将已部署容器中的数据拷贝至所创建的容器中。

需要说明的是，由于各个容器中的数据均会被持久化到诸如硬盘的存储设备中，因而，在将已部署容器中的数据拷贝至所创建的容器中时，可以从硬盘中获取已部署容器中的数据，从而将获取到的数据存储至所创建的容器中，以实现数据的拷贝。

在另一种可能的实现方式中，在部署操作类型为不改变节点的情况下，无需在物理池对应的服务器上进行操作。

在另一种可能的实现方式中，在已部署容器中存在待删除容器的情况下，从物理池对应的服务器上删除待删除容器。

可选地，计算设备所关联的数据库中还可以包括第一部署表和第二部署表，第一部署表可以用于对每次容器部署过程进行记录，第二部署表可以用于对每次容器部署过程的具体部署内容进行记录。

也即是，在一些实施例中，在基于第一请求报文和物理池对应的服务器上的已部署容器，确定待部署节点对应的部署操作类型以及已部署容器中的待删除容器之后， 本发明所提供的大数据集群部署方法还可以包括下述过程：

响应于第一请求报文，在第一部署表中生成操作记录，操作记录用于记录本次部署操作；

响应于第一请求报文，在第二部署表中生成待部署节点对应的容器部署记录，容器部署记录用于记录待部署节点对应的部署操作。

其中，可以在操作记录中记录本次操作的部署状态，在容器部署记录中记录待部署节点对应的容器的部署状态。可选地，部署状态可以包括部署中、部署完成和部署错误等。计算设备可以基于各个容器的部署情况，对容器部署记录中的部署状态进行更新，进而在每个容器均已部署完成的情况下，将操作记录中的部署状态更新为部署完成。

可选地，可以基于容器部署记录中所记录的部署状态，将部署资源池中的各个节点显示为不同的颜色，便于用户查看。其中，未部署状态的节点可以被显示为灰色，已部署状态的节点可以被显示为绿色)、部署错误状态的节点可以被显示为红色。

需要说明的是，计算设备可以每隔预设时长查询一次容器的部署状态，从而基于查询到的部署状态对部署资源池中各个节点的显示方式进行更新。其中，预设时长可以为10秒，可选地，预设时长还可以为其他时长，本发明对预设时长的具体取值不加以限定。

此外，还可以在容器部署记录中记录失败原因，以便相关技术人员可以进行问题排查。

上述实施例中主要介绍了增加物理池以及在物理池中部署节点对应的容器的过程，可选地，部署资源池区域还可以设置有删除物理池控件、置顶物理池控件等，以便为用户提供更加多样化的功能。

在部署资源池区域包括删除物理池控件的情况下，相关技术人员可以通过删除物理池控件来进行物理池的删除。

在一种可能的实现方式中，一个物理池对应于一个删除物理池控件，相关技术人员可以触发任一物理池对应的删除物理池控件，计算设备即可响应于对任一删除物理池控件的触发操作，不再在部署资源池区域显示被触发的删除物理池控件对应的物理池。

仍以图4所示的部署界面为例，如图4所示的部署界面的部署资源池区域中所显示的每个物理池的右上角都设置有一个“×”按钮，该按钮即为删除物理池控件，用户即可通过触发任一“×”按钮，来实现对对应物理池的删除。

通过在部署界面设置删除物理池控件，以便用户可以根据自己的实际需求实现对任一物理池的删除，以将该物理池对应的服务器从大数据集群中剔除，从而可以满足用户的技术需求，而且，操作简便，用户仅需一个简单的控件触发操作即可完成对大数据集群的修改，大大提高了操作效率。

需要说明的是，在对物理池进行删除时，需要将当前部署节点中待删除的物理池中所显示的节点移除，保证该物理池在部署界面中显示为空时，才可以通过删除物理池控件来对物理池进行删除。另外，需要注意的是，正在初始化中的物理池无法删除。

另外，需要说明的是，在对物理池进行删除时，计算设备可以响应于对任一删除物理池控件的触发操作，从删除物理池控件对应的物理池所对应的服务器中删除已部署的容器。

在任一删除物理池控件被触发的情况下，计算设备可以通过第二部署表查询被触发的删除物理池控件对应的服务器中所包括的已部署容器，从而调用Docker API，从相应的服务器总删除已部署容器的接口，以完成已部署容器删除。

而在部署资源池区域包括指定物理池控件的情况下，相关技术人员可以通过置顶物理池控件来改变物理池在部署资源池中的显示位置。

在一种可能的实现方式中，一个物理池对应于一个置顶物理池控件，相关技术人员可以触发任一物理池对应的置顶物理池控件，计算设备即可响应于对任一置顶物理池控件的触发操作，将置顶物理池控件对应的物理池显示在部署资源池区域中的第一目标位置处。其中，第一目标位置可以为部署资源池区域最左侧的位置。

仍以如图6所示的部署界面为例，如图6所示的部署界面的部署资源池区域中所显示的每个物理池的右上角都设置有一个“↑”按钮，该按钮即为置顶除物理池控件，用户即可通过触发任一“↑”按钮，来实现对对应物理池的显示位置的改变。

需要说明的是，当部署资源池中物理池添加到一定数量时，查找物理池时会出现一定困难，本发明通过增加置顶物理池功能，通过触发任一物理池对应的置顶物理池控件，该物理池就会被移动到部署资源池的最左侧的位置，也即是，部署资源池的 第一位，其余物理池顺序右移，从而使得用户可以更加方便地对移动到第一位的物理池中的节点进行操作，从而可以提高用户体验。

另外，本发明还可以在部署界面中提供恢复设置控件，以便在使用大数据平台的用户在遇到一些问题想要将大数据平台恢复到初始状态重新进行部署时，可以通过恢复设置控件，来将大数据平台恢复到初始状态。

在一种可能的实现方式中，计算设备可以响应于对恢复设置控件的触发操作，生成第三请求报文，第三请求报文用于请求删除已部署的服务器和容器；基于第三请求报文，从已部署的服务器中删除已部署的多个容器，执行第三预设脚本文件以使已部署的服务器脱离大数据集群。

可选地，在生成第三请求报文后，可以对第三请求报文的数据格式进行校验，从而在校验通过的情况下，再对第三请求报文进行处理，以保证第三请求报文的合法性和有效性，从而可以保证处理过程的安全性。

其中，在从已部署的服务器中删除已部署的多个容器，以及执行第三预设脚本文件以使已部署的服务器脱离大数据集群时，可以通过第二部署表查询大数据集群中的所有已部署容器，从而依次遍历容器列表，通过已部署的服务器IP、容器名称调用Docker API，来删除容器接口，完成所有已部署容器的删除；并且，通过第一部署表，查询到大数据集群所包括的所有服务器，依次遍历服务器列表，执行离开Docker Swarm集群脚本，完成所有服务器脱离集群的操作。

可选地，由于恢复出厂设置的操作是不可逆的，因而，在检测到对恢复设置控件的触发操作后，计算设备可以多次显示提示信息，来向用户确认是否确定要恢复出厂设置，从而在接收到确定要恢复出厂设置的指示后，再进行第三报文数据的生成。其中，提示信息可以为文案等多种类型。

上述恢复设置控件被触发后的处理逻辑可以参见图13，图13是根据本发明实施例示出的一种恢复出厂设置过程的流程示意图，如图13所示，在用户触发恢复出厂设置过程之后，可以通过多次文案提示来确认用户是否确定要执行恢复出厂设置的操作，在用户确定后，计算设备后端(也即是服务端)即可基于接收到的请求报文进行校验，从而在校验通过的情况下，通过遍历所有服务器实现所有容器的删除，再让所有服务器脱离大数据集群，此外，删除大数据集群中的所有存储数据，以使大数据集群恢复到初始状态，相应地，部署界面也会恢复到系统初始状态。

上述实施例主要是围绕大数据集群中常用的几种大数据组件来进行说明的，在更多可能的实现方式中，本发明还可以支持其他类型的容器的部署。

例如，本发明所提供的方法，还可以支持诸如分布式日志系统(Kafka)组件和远程字典服务(Remote Dictionary Server，Redis)组件的容器部署过程。下面，以Redis组件为例，给出Redis集群的部署方案。

其中，Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。单个Redis组件存在不稳定性，当Redis服务宕机就会导致服务不可用，并且，单个Redis组件的读写能力有限，使用Redis集群可以强化Redis的读写能力，并且当一台服务器宕机，其他服务器还能正常工作，不影响使用。

因而，开发人员可以预先准备用于部署Redis集群的基础镜像文件，并开发、部署Redis插件，以便可以通过本发明所提供的方法，实现Redis集群的部署。

在一种可能的实现方式中，可以在部署界面显示Redis组件，用户可以选中Redis后触发节点创建控件，计算设备即可响应于用户对节点创建控件的触发操作，在临时资源池区域显示6个待部署的Redis节点，从而将Redis节点拖拽到部署资源池的至少一个物理池中，进而触发开始部署控件，计算设备即可响应于对开始部署控件的触发操作，生成JSON的请求报文数据，进而对所生成的请求报文数据的数据格式进行校验，并且校验待部署的Redis节点的个数是否为6(由于Redis组件的性质，必须满足待部署的Redis节点的个数为6时，才允许进行部署)，从而在校验通过的情况下，在相应的服务器上创建Redis容器，具体过程可参见上述实施例，此处不再赘述。

需要说明的是，可以根据配置文件模板，为每个Redis节点生成一个redis.conf配置文件。参见图14，图14是根据本发明实施例示出的一种redis.conf配置文件的示意图，如图14所示，6个Redis节点对应于6个redis.conf配置文件，这6个配置文件中{{.Port}}(也即是端口号)的取值范围为6379-6384。在Redis集群启动时，每个Redis节点会加载自己对应的配置文件。

另外，需要说明的是，集群部署完成后，可以通过服务器的IP地址以及上述任意一个配置文件中的端口号，即可完成Redis集群功能使用。

上述Redis集群的搭建过程可以参见图15，图15是根据本发明实施例示出的一种Redis集群的搭建过程的示意图，如图15所示，开发人员可以预先开发Redis插 件，也即是，构建Redis基础镜像，然后抽象出配置文件，从而进行插件功能的开发(包括读取参数项、创建配置文件、将配置文件拷贝到远程的目标机器、目标机器上启动容器等)，从而对插件进行编译、安装和加载，以便可以通过已加载的Redis插件来部署Redis容器。具体地，首先部署节点，从而将所部署的Redis节点拖动到部署资源池，然后触发开始部署操作，在满足部署规则的情况下，服务器按照部署逻辑进行处理，调用Redis插件传递参数，以实现Redis的搭建，否则，返回错误消息，以便重新进行Redis节点的部署。

图15所示的过程仅为流程性说明，具体实现过程可以参见上述各个实施例，此处不再赘述。

上述过程主要介绍了有关大数据集群搭建过程的一些内容，在构建了大数据集群并在大数据集群中部署了相应的容器后，即可通过所搭建的大数据集群为用户提供服务。其中，大数据集群的不同容器之间通过Overlay网络进行通信，以共同为用户提供服务。

下面，对基于大数据集群的数据处理过程进行说明，该过程可以包括如下步骤：

步骤一、获取数据处理请求。

步骤二、通过Overlay网络，向目标容器发送数据处理请求，目标容器用于基于数据处理请求实现数据处理过程，容器按照对部署界面中的待部署节点的拖拽操作在服务器上创建得到，容器用于提供大数据集群服务。

通过Overlay网络保证大数据集群中各个容器之间的通信，以便在获取到数据处理请求时，可以通过Overlay网络，向目标容器发送数据处理请求，以便目标容器基于数据处理请求实现数据处理过程，以满足用户的数据处理需求。

在一些实施例中，在通过Overlay网络，向目标容器发送数据处理请求时，可以基于数据处理请求，确定至少一个目标容器，从而通过Overlay网络，向至少一个目标容器发送数据处理请求。

需要说明的是，在目标容器的数量大于等于2的情况下，至少一个目标容器至少包括第一目标容器和第二目标容器。则在通过Overlay网络，向至少一个目标容器发送数据处理请求时，可以通过Overlay网络，向第一目标容器发送数据处理请求，第一目标容器用于通过Overlay网络与第二目标容器进行通信，以完成对数据处理请求的响应。

以通过Overlay网络实现第一目标容器和第二目标容器之间数据通信需求的过程为例，第一目标容器可以对待传输的数据进行封装得到第一数据报文，进而对第一数据报文再次进行封装，得到第二数据报文，其中，第一数据报文的目的IP地址为第二目标容器的IP地址，源IP地址为第一目标容器的IP地址，第二数据报文的目的IP地址为第二目标容器所处服务器的IP地址，源IP地址为第一目标容器所处服务器的IP地址，第一目标容器即可通过Overlay网络，将第二数据报文发送给第二目标容器，以便第二目标容器可以对第二数据报文的双层封装进行拆解，以得到真正需要处理的数据部分。

其中，数据处理请求可以为数据存储请求、数据获取请求或数据删除请求。可选地，数据处理请求还可以包括其他类型的请求，本发明对数据处理请求的具体类型不加以限定。

本发明的实施例还提出了一种大数据集群部署系统以及对应的数据处理系统，该系统可以包括至少可视化操作模块和架构服务模块。其中，可视化操作模块用于为使用者提供便捷的大数据集群部署操作界面，可添加、删除服务器，部署、移动、删除大数据组件所包括的节点，恢复集群出厂设置等；架构服务模块可以用于提供API接口服务、数据规则校验、组件部署逻辑处理、消息处理、插件调用、数据库持久化等功能。

可选地，该系统还可以包括消息模块、数据库模块、网络模块和大数据组件插件模块。其中，消息模块为基于RabbitMQ的消息队列，在被架构部署模块调用时完成消息生产、消费，在比较耗时的场景(如服务器初始化、各组件容器部署等)下使用提升用户体验，保证数据一致性、稳定性和可靠性；数据库模块使用MYSQL数据库，用于存储服务器状态、组件部署状态、组件部署与服务器间关系信息；网络模块，为基于docker的overlay网络，大数据服务容器启动时使用该网络，保证容器间跨服务器通信；大数据组件插件模块，用于对于每个大数据组件开发可插拔的启动插件，以服务器IP结合插件参数的方式启动插件，即可完成对指定组件容器在指定服务器上启动。

上述仅为对各个模块的功能的简要说明，下面对各个模块的功能仅详细介绍。

其中，可视化操作模块，用于显示部署界面；

可视化操作模块，还用于响应于在部署界面的节点创建操作，在部署界面的临 时资源池区域显示待部署节点，节点为大数据组件所包括的、用于提供数据管理功能的服务；

可视化操作模块，还用于响应于对临时资源池区域中的待部署节点的拖拽操作，在部署界面的部署资源池区域中的物理池中显示待部署节点；

架构服务模块，用于响应于在部署界面中的开始部署操作，按照待部署节点所处的物理池，在物理池对应的服务器上创建待部署节点对应的容器，容器用于提供大数据集群服务。

在一些实施例中，部署界面包括节点创建区域，节点创建区域包括节点创建控件和至少一个大数据组件；

可视化操作模块，在用于响应于在部署界面的节点创建操作，在部署界面的临时资源池区域显示待部署节点时，用于：

在任一大数据组件被选中的情况下，响应于对节点创建控件的触发操作，在临时资源池区域中显示被选中的大数据组件对应的待部署节点。

在一些实施例中，节点创建区域还包括节点参数设置控件，节点参数设置控件用于设置待部署节点的版本；

可视化操作模块，在用于响应于对节点创建控件的触发操作，在临时资源池区域中显示被选中的大数据组件对应的待部署节点时，用于：

响应于对节点创建控件的触发操作，在临时资源池区域中显示通过节点参数设置控件所设置的版本对应的待部署节点。

在一些实施例中，大数据组件至少包括HDFS组件、YARN组件、Hive组件和Clickhouse组件。

在一些实施例中，部署资源池区域包括至少一个物理池；

可视化操作模块，在用于响应于对临时资源池区域中的待部署节点的拖拽操作，在部署界面的部署资源池区域中的物理池中显示待部署节点时，用于：

对于任一待部署节点，响应于对待部署节点的拖拽操作，将待部署节点显示在拖拽操作结束时所指示的物理池中。

在一些实施例中，架构服务模块，在用于响应于在部署界面中的开始部署操作，按照待部署节点所处的物理池，在物理池对应的服务器上部署待部署节点对应的容器 时，用于：

响应于开始部署操作，基于待部署节点所属的大数据组件的组件类型，确定目标插件；

通过目标插件，启动位于物理池对应的服务器上的目标接口；

通过目标接口，在物理池对应的服务器上部署待部署节点对应的容器。

在一些实施例中，架构服务模块，在用于通过目标接口，在物理池对应的服务器上部署待部署节点对应的容器，包括：

通过目标插件读取第一配置文件，以从第一配置文件中获取目标安装环境；

通过目标接口，对服务器的目标安装环境的配置文件进行修改，以在物理池对应的服务器上部署待部署节点对应的容器。

在一些实施例中，目标插件为二进制包，目标插件存储在大数据集群中的设定位置处；

目标插件的获取过程包括：

获取被上传至大数据集群的初始服务器中的目标插件；

将目标插件存储在大数据集群中的设定位置处。

在一些实施例中，架构服务模块，在用于响应于在部署界面中的开始部署操作，按照待部署节点所处的物理池，在物理池对应的服务器上部署待部署节点对应的容器时，用于：

响应于开始部署操作，基于待部署节点以及待部署节点所处的物理池，生成第一请求报文，第一请求报文用于指示在物理池对应的服务器上部署待部署节点对应的容器；

基于第一请求报文和物理池对应的服务器上的已部署容器，确定待部署节点对应的部署操作类型以及已部署容器中的待删除容器，部署操作类型包括新增节点、移动节点和不改变节点；

按照待部署节点对应的部署操作类型以及已部署容器中的待删除容器，在物理池对应的服务器上进行容器部署。

在一些实施例中，架构服务模块，还用于将第一请求报文存储至第一消息队列 中；

该系统还包括：

消息模块，用于从第一消息队列中获取第一请求报文；

架构服务模块，还用于在消息模块获取到第一请求报文的情况下，执行基于第一请求报文和物理池对应的服务器上的已部署容器，确定待部署节点对应的部署操作类型以及已部署容器中的待删除容器的步骤。

在一些实施例中，架构服务模块，在用于按照待部署节点对应的部署操作类型以及已部署容器中的待删除容器，在物理池对应的服务器上进行容器部署时，用于：

在部署操作类型为新增节点的情况下，调用待部署节点的节点类型对应的组件插件，在物理池对应的服务器上创建待部署节点对应的容器；

在部署操作类型为移动节点的情况下，从已部署待部署节点对应容器的服务器上删除待部署节点对应的已部署容器，在物理池对应的服务器中创建待部署节点对应的容器，并将已部署容器中的数据拷贝至所创建的容器中；

在部署操作类型为不改变节点的情况下，无需在物理池对应的服务器上进行操作；

在已部署容器中存在待删除容器的情况下，从物理池对应的服务器上删除待删除容器。

在一些实施例中，架构服务模块，还用于对第一请求报文的数据格式进行校验；

架构服务模块，还用于按照预设部署规则，对第一请求报文所携带的部署数据进行校验。

在一些实施例中，系统还包括数据库模块；

数据库模块，用于响应于第一请求报文，在第一部署表中生成操作记录，操作记录用于记录本次部署操作；

数据库模块，还用于响应于第一请求报文，在第二部署表中生成待部署节点对应的容器部署记录，容器部署记录用于记录待部署节点对应的部署操作。

在一些实施例中，数据库模块，还用于在操作记录中记录本次操作的部署状态；

数据库模块，还用于在容器部署记录中记录待部署节点对应的容器的部署状 态；

其中，部署状态至少包括部署中、部署完成和部署错误；

在一些实施例中，待部署节点包括多种类型；

可视化操作模块，还用于显示部署指示界面；

可视化操作模块，还用于通过部署指示界面获取用户填写的目标数据，目标数据用于指示待部署的容器的每秒存储数据条数；

架构服务器模块，还用于基于目标数据和预设参数，确定各种类型的待部署节点对应的推荐部署数量。

在一些实施例中，部署资源池区域包括新增物理池控件；可视化操作模块，还用于：

响应于对新增物理池控件的触发操作，显示增加物理池界面，增加物理池界面包括标识获取控件和密码获取控件；

通过标识获取控件获取待增加的物理池对应的服务器标识，通过密码获取控件获取待验证密码；

在待验证密码验证通过的情况下，在部署资源池区域显示待增加的物理池。

在一些实施例中，架构服务模块，还用于在待验证密码验证通过的情况下，生成第二请求报文；

架构服务模块，还用于将第二请求报文存储至第二消息队列中；

该装置还包括：

消息模块，用于从第二消息队列中获取第二请求报文；

架构服务模块，还用于基于第二请求报文，向待增加的物理池对应的服务器发送安装文件，服务器用于在接收到安装文件的情况下对安装文件进行安装，以使服务器加入大数据集群。

在一些实施例中，可视化操作模块，还用于在待验证密码未验证通过或者服务器未成功加入大数据集群的情况下，显示第一提示信息，第一提示信息用于指示服务器未成功加入大数据集群的原因。

在一些实施例中，该系统还包括：

数据库模块，用于在待验证密码验证通过的情况下，在第三部署表中生成服务器部署记录，服务器部署记录用于记录待增加的物理池对应的部署操作。

在一些实施例中，数据库模块，还用于在服务器部署记录中记录待增加的物理池对应的服务器的初始化状态，初始化状态至少包括待初初始化、初始化中、初始化错误和初始化完成。

在一些实施例中，部署资源池区域包括删除物理池控件，一个物理池对应于一个删除物理池控件；

可视化操作模块，还用于响应于对任一删除物理池控件的触发操作，不再在部署资源池区域显示删除物理池控件对应的物理池。

在一些实施例中，架构服务模块，还用于响应于对任一删除物理池控件的触发操作，从删除物理池控件对应的物理池所对应的服务器中删除已部署的容器。

在一些实施例中，部署资源池区域包括置顶物理池控件，一个物理池对应于一个置顶物理池控件；

可视化操作模块，还用于响应于对任一置顶物理池控件的触发操作，将置顶物理池控件对应的物理池显示在部署资源池区域中的第一目标位置处。

在一些实施例中，可视化操作模块，还用于对于部署资源池区域中所显示的任一物理池，在物理池的第二目标位置处显示物理池所对应的服务器的服务器标识，在物理池的第三目标位置处显示物理池所对应的服务器的当前存储使用率、内存占用率和分配内存占用率。

在一些实施例中，部署界面还包括恢复设置控件；

架构服务模块，还用于响应于对恢复设置控件的触发操作，生成第三请求报文，第三请求报文用于请求删除已部署的服务器和容器；

架构服务模块，还用于基于第三请求报文，从已部署的服务器中删除已部署的多个容器，执行第三预设脚本文件以使已部署的服务器脱离大数据集群。

在一些实施例中，大数据集群包括至少一个服务器，至少一个服务器中存在一个初始服务器，架构服务模块，还用于：

在初始服务器上安装目标运行环境，并在初始服务器上配置目标运行环境对应的接口；

在初始服务器上创建目标运行环境对应的Overlay网络，并在初始服务器上初始化集群环境；

在初始服务器上创建大数据组件基础镜像，大数据组件基础镜像用于为容器提供构建基础；

在初始服务器上生成目标密钥文件。

在一些实施例中，系统还包括网络模块，用于保证容器间的跨服务器通信。

在一些实施例中，网络模块，用于在获取到数据处理请求后，通过Overlay网络，向目标容器发送数据处理请求，目标容器用于基于数据处理请求实现数据处理过程，容器按照对部署界面中的待部署节点的拖拽操作在服务器上创建得到，容器用于提供大数据集群服务。

在一些实施例中，网络模块，在用于通过Overlay网络，向目标容器发送数据处理请求时，用于：

基于数据处理请求，确定至少一个目标容器；

通过Overlay网络，向至少一个目标容器发送数据处理请求。

在一些实施例中，在目标容器的数量大于等于2的情况下，至少一个目标容器至少包括第一目标容器和第二目标容器；

网络模块，在用于通过Overlay网络，向至少一个目标容器发送数据处理请求时，用于：

通过Overlay网络，向第一目标容器发送数据处理请求，第一目标容器用于通过Overlay网络与第二目标容器进行通信，以完成对数据处理请求的响应。

在一些实施例中，数据处理请求为数据存储请求、数据获取请求或数据删除请求。

在一些实施例中，系统还包括大数据组件插件模块，大数据组件插件模块用于实现容器在服务器上的启动。

对于系统实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的系统实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个物料模块上。 可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

下面以几个实际的处理过程为例，来对本发明所提供的系统进行进一步说明。

例如，参见图16，图16是根据本发明实施例示出的一种模块交互过程的流程图，图16以增加物理池时各个模块之间的交互过程为例，如图16所示，可视化操作模块用于将服务器添加至大数据集群以及每10秒轮循查询服务器的初始化状态，在通过可视化操作模块将服务器添加至大数据集群时，可以通过可视化操作模块生成JSON格式的请求报文，从而向架构服务模块发送请求报文，架构服务模块在接收到请求报文的情况下，通过SSH连接测试，远程登录服务器，并在登录成功时，向消息模块中的消息队列发送消息，且向数据库模块中插入一条服务器初始化中的记录，此外，架构服务模块还可以对消息模块进行消息监听，以从消息模块的消息队列中获取消息，并基于获取到的消息来在服务器上进行环境安装、加入Docker Swarm集群等操作，并且，可以更新数据库模块中所记录的服务器初始化状态。

又例如，参见图17，图17是根据本发明实施例示出的另一种模块交互过程的流程图，图17以部署容器时各个模块之间的交互过程为例，如图17所示，可视化操作模块用于部署大数据组件对应的容器以及每10秒轮循查询容器部署状态，在通过可视化操作模块部署大数据组件对应的容器时，可以通过可视化操作模块生成JSON格式的请求报文，从而向架构服务模块发送请求报文，架构服务模块在接收到请求报文的情况下，基于部署规则对请求报文进行校验，并在校验成功的情况下，确定部署方式(也即是节点部署操作类型)，并向消息模块中的消息队列发送消息，且在数据库模块中增加第一部署表(也即是图17中所示的部署表)和第二部署表(也即是图17中所示的部署表细表)记录，此外，架构服务模块还可以对消息模块进行消息监听，以从消息模块的消息队列中获取消息，并基于获取到的消息来在服务器上进行插件启动，并且，可以更新数据库模块中所记录的部署状态等。

例如，参见图18，图18是根据本发明实施例示出的另一种模块交互过程的流程图，图18以恢复出厂设置时各个模块之间的交互过程为例，如图18所示，可视化操作模块用于重置大数据集群，在有重置大数据集群的需求时，可视化操作模块可以根据数据库模块中所记录的内容，查询已部署容器列表以删除所有已部署容器，还可以查询服务器列表以使所有服务脱离大数据集群，以完成大数据集群的重置。

上述仅为三种示例性说明，并不构成对本发明的限定。

本发明的实施例还提出了一种数据处理装置，参见图19，图19是根据本发明实施例示出的一种数据处理装置的框图，该装置包括：

获取单元1901，用于获取目标界面上所显示的节点对应的操作对象的属性数据,操作对象为在目标界面对应的程序代码中所定义的对象；

关联单元1902，用于将所获取到的属性数据关联到对应的节点上；

修改单元1903，用于响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改，以使节点基于修改后的属性数据，显示在拖拽操作结束的位置。

在一些实施例中，修改单元1903，在用于响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改时，用于：

响应于对目标界面上的节点的拖拽操作，通过属性获取指令，基于拖拽操作对应的操作数据，获取待修改的属性数据；

通过属性设置指令，确定待修改的属性数据对应的操作对象；

基于待修改的属性数据，对所确定出的操作对象对应的属性数据进行修改。

在一些实施例中，属性数据包括节点的位置数据；

修改单元1903，在用于响应于对目标界面上的节点的拖拽操作，基于拖拽操作对应的操作数据，对节点所关联的属性数据进行修改时，用于：

响应于对目标界面上的节点的拖拽操作，基于拖拽操作结束的位置所对应的位置数据，对节点所关联的属性数据中的位置数据进行修改。

在一些实施例中，位置数据包括节点所处物理池对应的服务器标识以及节点在服务器中的索引值。

在一些实施例中，该装置还包括：

生成单元，用于在节点满足设定条件的情况下，响应于对目标界面上的节点的拖拽操作，为节点生成临时变量；

存储单元，用于通过临时变量，对节点修改前的属性数据进行存储。

在一些实施例中，属性数据还包括节点的样式数据，样式数据用于指示节点的显示样式；

修改单元1903，还用于响应于对目标界面上的节点的拖拽操作，将临时变量中所存储的属性数据所包括的样式数据修改为第一样式数据，将节点所关联的属性数据所包括的样式数据修改为第二样式数据。

在一些实施例中，属性数据还包括行为数据，行为数据用于指示节点在被拖拽时是否需要显示提示信息；

获取单元1901，还用于响应于对目标界面上的节点的拖拽操作，获取被拖拽的节点所关联的属性数据；

该装置还包括：

显示单元，用于在属性数据所包括的行为数据指示节点在被拖拽时是否需要显示提示信息的情况下，显示提示信息，提示信息用于基于本次拖拽操作进行提示。

在一些实施例中，操作对象为文档对象模型DOM对象，属性获取指令为getAtttribute指令，属性设置指令为setAtttribute指令。

本发明还提供了一种计算设备，参见图20，图20是本发明根据一示例性实施例示出的一种计算设备的结构示意图。如图20所示，计算设备包括处理器2010、存储器2020和网络接口2030，存储器2020用于存储可在处理器2010上运行的计算机指令，处理器2010用于在执行计算机指令时实现本发明任一实施例所提供的数据处理方法，网络接口2030用于实现输入输出功能。在更多可能的实现方式中，计算设备还可以包括其他硬件，本发明对此不做限定。

本发明还提供了一种计算机可读存储介质，计算机可读存储介质可以是多种形式，比如，在不同的例子中，计算机可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、DVD等)，或者类似的存储介质，或者它们的组合。特殊的，计算机可读介质还可以是纸张或者其他合适的能够打印程序的介质。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现本发明任一实施例所提供的数据处理方法。

本发明还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现本发明任一实施例所提供的数据处理方法。

在本发明中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。术语“多个”指两个或两个以上，除非另有明确的限定。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (11)

1. 一种数据处理方法，其特征在于，所述方法包括：

   获取目标界面上所显示的节点对应的操作对象的属性数据，所述操作对象为在所述目标界面对应的程序代码中所定义的对象；

   将所获取到的属性数据关联到对应的节点上；

   响应于对所述目标界面上的节点的拖拽操作，基于所述拖拽操作对应的操作数据，对所述节点所关联的属性数据进行修改，以使所述节点基于修改后的属性数据，显示在拖拽操作结束的位置。
2. 根据权利要求1所述的方法，其特征在于，所述响应于对所述目标界面上的节点的拖拽操作，基于所述拖拽操作对应的操作数据，对所述节点所关联的属性数据进行修改，包括：

   响应于对所述目标界面上的节点的拖拽操作，通过属性获取指令，基于所述拖拽操作对应的操作数据，获取待修改的属性数据；

   通过属性设置指令，确定待修改的属性数据对应的操作对象；

   基于待修改的属性数据，对所确定出的操作对象对应的属性数据进行修改。
3. 根据权利要求1所述的方法，其特征在于，所述属性数据包括所述节点的位置数据；

   所述响应于对所述目标界面上的节点的拖拽操作，基于所述拖拽操作对应的操作数据，对所述节点所关联的属性数据进行修改，包括：

   响应于对所述目标界面上的节点的拖拽操作，基于所述拖拽操作结束的位置所对应的位置数据，对所述节点所关联的属性数据中的位置数据进行修改。
4. 根据权利要求3所述的方法，其特征在于，所述位置数据包括所述节点所处物理池对应的服务器标识以及所述节点在所述服务器中的索引值。
5. 根据权利要求1所述的方法，其特征在于，所述方法还包括：

   在所述节点满足设定条件的情况下，响应于对所述目标界面上的节点的拖拽操作，为所述节点生成临时变量；

   通过所述临时变量，对所述节点修改前的属性数据进行存储。
6. 根据权利要求5所述的方法，其特征在于，所述属性数据还包括所述节点的样式数据，所述样式数据用于指示所述节点的显示样式；

   所述方法还包括：

   响应于对所述目标界面上的节点的拖拽操作，将所述临时变量中所存储的属性数据所包括的样式数据修改为第一样式数据，将所述节点所关联的属性数据所包括的样式数据修改为第二样式数据。
7. 根据权利要求1所述的方法，其特征在于，所述属性数据还包括行为数据，所述行为数据用于指示所述节点在被拖拽时是否需要显示提示信息；

   所述方法还包括：

   响应于对所述目标界面上的节点的拖拽操作，获取被拖拽的节点所关联的属性数据；

   在所述属性数据所包括的行为数据指示所述节点在被拖拽时是否需要显示提示信息的情况下，显示提示信息，所述提示信息用于基于本次拖拽操作进行提示。
8. 根据权利要求1至7中任一项所述的方法，其特征在于，所述操作对象为文档对象模型DOM对象，所述属性获取指令为getAtttribute指令，所述属性设置指令为setAtttribute指令。
9. 一种数据处理装置，其特征在于，所述装置包括：

   获取单元，用于获取目标界面上所显示的节点对应的操作对象的属性数据；

   关联单元，用于将所获取到的属性数据添加到对应的节点上；

   修改单元，用于响应于对所述目标界面上的节点的拖拽操作，基于所述拖拽操作对应的操作数据，对所述节点所关联的属性数据进行修改，以使所述节点基于修改后的属性数据，显示在拖拽操作结束的位置。
10. 一种计算设备，其特征在于，所述计算设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如权利要求1至8中任一项所述的数据处理方法所执行的操作。
11. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有 程序，所述程序被处理器执行时，实现如权利要求1至8中任一项所述的数据处理方法所执行的操作。