CN113204353B - 一种大数据平台组件部署方法及装置 - Google Patents

Abstract

本公开提供了一种大数据平台组件部署方法及装置，用于提高大数据平台的高可用性和组件性能。本公开通过将大数据平台服务划分为管理服务和非管理服务，在部署有容器编排引擎集群和高可用性组件的管理服务节点部署管理服务，在非管理服务节点即数据节点部署非管理服务节点，使管理节点和数据节点解耦，减少资源抢夺，能够提高大数据平台组件性能，最小化管理节点的故障，保证大数据平台稳定运行。

Description

一种大数据平台组件部署方法及装置

技术领域

本公开涉及大数据和云计算技术领域，尤其涉及一种大数据平台组件部署方法及装置。

背景技术

Apache Ambari是一种基于Web的用于创建、管理、监视Hadoop的集群的管理工具，简称为大数据管理平台。Ambari已支持大多数Hadoop组件，包括分布式文件系统HDFS、MapReduce(大规模数据集的并行运算编程模型)、Hive(数据仓库框架)、Pig(大规模数据分析平台)、Hbase(分布式列数据库)、Zookeeper(分布式应用程序协调服务)、Sqoop(数据传输工具)和Hcatalog(数据表和存储管理服务)等。

以Ambari为代表的Hadoop大数据平台应用广泛，然而，随着数据量的增加和集群规模的扩大，以及业务的复杂程度不断提升，经常出现资源抢夺、网络震荡、断电等各种因素造成平台上的某些服务挂掉。为了解决单节点故障，对管理服务实现高可用(HighAvailable，HA)部署来保障服务的高可用性，但是大部分HA机制依赖于Zookeeper的实现。通常一个平台内只有一个Zookeeper集群，Zookeeper通常作为协调者角色存在，很多服务(例如HBase、Solr、Kafka)会频繁的访问Zookeeper集群，其压力很大，一旦Zookeeper出现故障会导致所有被依赖的服务出现故障。

随着容器云管理平台K8s的出现，人们开始把Hadoop大数据服务移动到容器内运行，但是容器是通过Cgroup虚拟出来的，相比于物理机，其多出来很多调用层级，因此其性能大大缩减。再者大数据服务通常需要海量的存储，单纯使用容器，很难满足业内需求。

发明内容

有鉴于此，本公开提供一种大数据平台组件部署方法及装置，用于提高大数据平台的高可用性和组件性能。

图1为本公开提供的大数据平台组件部署方法的步骤流程示意图，该方法包括：

步骤101.在多个管理服务节点部署容器编排引擎集群，并为所述容器编排引擎集群部署高可用组件；

所述容器编排引擎用于管理云平台中多个主机上的容器化的应用，例如可以为Kubernetes简称K8s。

所述高可用组件用于提供高可用性、负载均衡的组件，例如可以为HAProxy。

步骤102.将大数据平台组件的管理服务安装包部署在所述由多个管理服务节点组成的容器编排引擎集群中；所述管理服务安装包中仅包括所述大数据平台组件中只参与任务的分发和调度的管理服务的安装包；

所述大数据平台组件包括HDFS、Yarn、HBase、Zookeeper、Kafka、Solr等组件中的一种或多种。

步骤103.将大数据平台组件的非管理服务安装包部署在一个或多个非管理节点；所述非管理服务安装包中仅包括只参与任务的计算和数据的存储的非管理服务的安装包。

本公开将大数据平台组件的服务安装包(或称为镜像)划分为管理服务安装包和非管理服务安装包；所述管理服务安装包中仅包括大数据平台组件中只参与任务的分发和调度的管理服务的安装包，所述非管理服务安装包中仅包括只参与任务的计算和数据的存储的非管理服务的安装包。所述管理服务以容器方式运行在所述K8s集群的Pod中。所述非管理服务部署在由物理机承载的所述一个或多个非管理服务节点中。

进一步地，所述管理服务安装包中包括大数据管理平台组件的管理服务的安装包，所述非管理服务安装包中还包括大数据管理平台组件的非管理服务的安装包，所述方法还包括：

通过容器编排引擎启动所述大数据管理平台组件的管理服务后，通过所述大数据管理平台组件的管理服务添加所述一个或多个非管理服务节点，然后执行所述将大数据平台组件的非管理服务安装包部署在一个或多个非管理节点的步骤。

进一步地，所述大数据平台组件的管理服务运行于容器当中，为实现所述管理服务的配置的动态更新，采用配置信息与服务程序分离的机制实现配置信息的注入；为实现所述大数据平台组件的管理服务持续服务能力，所述容器编排引擎集群通过控制机制使预定数量的承载所述大数据平台组件的管理服务的容器进程持续运行。

本公开一实施例采用ConfigMap功能来实现所述管理服务的配置的动态更新，为每一个管理服务配置一个configMap.yaml文件。所述容器编排引擎集群所使用的控制机制为ReplicationController机制。

进一步地，当所述大数据平台组件的管理服务为有状态服务时，通过标签将所述管理服务标记为对外提供服务的角色。

进一步地，当所述大数据平台组件依赖分布式应用协调服务组件时，所述方法还包括：

在所述由多个管理服务节点组成的容器编排引擎集群中为所述大数据平台组件部署分布式应用协调服务组件集群，并将创建的分布式应用协调服务组件集群的服务域名和网络访问地址及端口动态加载到所述大数据平台组件的管理服务和非管理服务的配置里。

图2为本公开一实施例提供的一种大数据平台组件部署装置结构示意图，该装置200中的各功能模块可以采用软件、硬件或软硬件相结合的方式实现。当多个硬件设备共同实施本公开的技术方案时，由于各硬件设备之间相互协作的目的是共同实现本发明目的，一方的动作和处理结果确定了另一方的动作执行的时机及可能获得的结果，因此，可视为各执行主体之间具有相互协作关系，各执行主体之间具有相互指挥和控制关系。该大数据平台组件部署装置200包括：

多个管理服务节点210、一个或多个非管理服务节点220和高可用组件230；

所述多个管理服务节点210部署有容器编排引擎集群，所述高可用组件230为所述容器编排引擎集群中的管理服务提供高可用性；

所述多个管理服务节点210中部署有所述大数据平台组件的管理服务；所述管理服务为所述大数据平台组件中只参与任务的分发和调度的服务；

所述一个或多个非管理服务节点220中部署有所述大数据平台组件的非管理服务；所述非管理服务为所述大数据平台组件中只参与任务的计算和数据的存储的服务。

进一步地，所述多个管理服务节点210中还部署有大数据管理平台组件的管理服务，所述一个或多个非管理节点220中还部署有所述大数据管理平台组件的非管理服务；

所述容器编排引擎启动所述大数据管理平台组件的管理服务后，所述大数据管理平台组件的管理服务添加所述一个或多个非管理服务节点220，将所述大数据平台组件的非管理服务部署到所述一个或多个非管理节点220。

进一步地，所述大数据平台组件的管理服务运行于容器当中，所述大数据平台组件的管理服务采用配置信息与服务程序分离的机制实现配置信息的注入；

所述容器编排引擎集群通过控制机制使预定数量的承载所述大数据平台组件的管理服务的容器进程持续运行。

进一步地，所述多个管理服务节点210中还部署有所述大数据平台组件所依赖的分布式应用协调服务组件集群，所述分布式应用协调服务组件集群的服务域名和网络访问地址及端口通过动态加载机制加载到所述大数据平台组件的管理服务和非管理服务的配置里。

进一步地，所述容器编排引擎集群为K8s，所述高可用组件为HAProxy，所述大数据平台组件包括HDFS、Yarn、HBase、Zookeeper、Kafka、Solr组件中的一种或多种；大数据管理平台组件为Ambari；所述分布式应用协调服务组件为Zookeeper；

所述Ambari的管理服务为Ambari-Server，非管理服务为Ambari-Agent；

所述HDFS的管理服务为NameNode，非管理服务为DataNode；

所述Yarn的管理服务为ResourceManager，非管理服务为NodeManager；

所述HBase的管理服务为HMaster，非管理服务为HRegionServer；

所述Kafka和Solr的服务为非管理服务。

本公开通过将大数据平台服务划分为管理服务和非管理服务，在部署有容器编排引擎集群和高可用性组件的管理服务节点部署管理服务，在非管理服务节点即数据节点部署非管理服务节点，使管理节点和数据节点解耦，减少资源抢夺，能够提高大数据平台组件性能，最小化管理节点的故障，保证大数据平台稳定运行。

附图说明

为了更加清楚地说明本公开实施例或者现有技术中的技术方案，下面将对本公开实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本公开实施例的这些附图获得其他的附图。

图1为本公开提供的大数据平台组件部署方法的步骤流程示意图；

图2为本公开一实施例提供的一种大数据平台组件部署装置结构示意图；

图3为本公开一实施例提供的大数据平台组件服务拆分部署规划示意图；

图4为本公开一实施例提供的不依赖Zookeeper集群的非管理服务在物理机上的集群部署示例；

图5为本公开一实施例提供的依赖Zookeeper集群的大数据平台组件的部署示例；

图6为本公开一实施例提供的实现大数据平台组件部署方法的电子设备结构示意图。

具体实施方式

在本公开实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本公开实施例。本公开实施例中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。本公开中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

Ambari大数据管理平台所管理的关键组件服务通常有HDFS、Yarn、HBase、Zookeeper、Kafka和Solr等，由于服务硬件资源及服务依赖关系等方面的问题，经常出现组件的管理进程挂掉，以至于整个组件服务全部处于瘫痪状态。

本公开一实施例通过HAProxy机制对Kubernetes(简称K8s)的Master服务实现HA，从而保证了K8s的稳定性，然后再通过K8s的副本控制Replica control机制对服务的副本进行控制，当包含服务的容器所在的Pod挂掉时自动重启，使Pod一直处于指定的个数，通过利用上述机制，把大数据平台组件的关键服务部署到Pod里，从而保障组件的高可用性。以Ambari所管理的关键组件服务HDFS为例，HDFS由NameNode和DataNode组成，可以把更为关键的管理服务NameNode提前打成镜像，然后放到K8s部署的Pod里去运行，把DataNode放到Ambari大数据管理平台去管理。

通常在Ambari部署的一个集群内所有组件共用一个Zookeeper集群。但在实际业务环境中，需要大量访问Zookeeper集群时，总是会出现连接数不够导致业务无法正常使用的问题。为了充分保障使用Zookeeper集群的服务的正常使用，本公开的改进思路之一是将Zookeeper放进Pod，由于Zookeeper占用内存较少，可以在依赖Zookeeper的组件(HBase、Solr、Kafka)部署的时候，动态通知K8s去创建一个属于自己的Zookeeper集群，从而保障使用Zookeeper集群的服务不会因为连接数不够影响业务。

为实现本公开的发明目的，本公开需要对Ambari及其所管理的大数据平台组件的服务包进行定制操作，将组件服务拆分为管理服务和非管理服务。

本公开将一个组件中只参与任务的分发和调度，不参与任务的执行的服务命名为管理服务；将只参与任务的计算和数据的存储，不参与任务分发和调度的服务命名为非管理服务。

本公开将大数据平台的管理服务提前打成镜像包，放到docker的镜像库里，再对剩下的非管理服务进行包定制，以方便其在物理机部署。其中，Docker是Kubernetes创建或部署的最小/最简单的基本单位Pod中的最常见的运行时runtime，Pod也可支持其他容器runtimes。

由于Ambari所管理的大数据平台服务较多，本公开主要针对HDFS、Yarn、HBase、Zookeeper、Kafka和Solr进行举例说明，其它服务可参照本公开提供的技术方案处理，本公开不做赘述。

本公开技术方案主要包含三方面的改进，分别为：Ambar i大数据管理平台及大数据相关组件服务包的拆分、管理服务的部署策略、非管理服务的部署策略。部署的整体流程主要包括如下几个步骤：

(1).使用多台物理机搭建k8s高可用集群。

(2).拆分Ambari及其所管理的大数据平台的组件服务，制作管理服务镜像，并将管理服务镜像上传到Docker镜像库。

管理服务镜像只包括大数据平台各个组件的管理服务，如NameNode、HMaster、ResourceManager等。

(3).在通过K8s搭建的集群内启动Ambari-Server服务。

(4).通过Ambari-Server添加多台非管理服务节点即数据节点，用于非管理服务的部署。

(5).根据管理服务部署策略在K8s集群内部署管理服务。

(6).根据非管理服务部署策略在数据节点部署服务。

第一部分：Ambar i大数据管理平台及大数据相关组件服务包的拆分

图3为本公开一实施例提供的大数据平台组件服务拆分部署规划示意图，其中横向是集群节点，纵向为物理机，部署管理服务的物理机称为管理服务节点，部署非管理服务的物理机称为非管理服务节点，非管理服务节点可根据业务需要动态扩充。

Kubernetes即K8s是一个容器编排引擎，用于管理云平台中多个主机上的容器化的应用。本公开一实施例采用多台管理服务节点通过HAProxy搭建K8s容器云管理平台实现高可用集群，通过K8s将管理服务调度分配到多台管理服务节点的任一节点上。k8s可利用其StateFule机制保证承载管理服务的容器失败时进行调度，在将管理服务调度到一个管理服务节点失败时可将管理服务调度到其它管理服务节点运行。

Ambari本身包括Ambari-Server和Ambari-Agent。将Ambari-Server作为管理服务部署到管理服务节点，将Ambari-Agent作为非管理服务部署到非管理服务节点。

Ambari大数据管理平台所管理的大数据平台组件服务包通常默认包括HDFS、Yarn、HBase、Zookeeper、Kafak和Solr等组件。需要把这些组件拆分开，将这些组件中的管理服务通过K8s部署到由多台管理服务节点构成的高可用集群上以实现高可用性HA，非管理服务部署到非管理服务节点上，以加快数据的计算和存储性能。

通过对上述Hadoop组件进行分析，根据管理服务和非管理服务的定义，可对Ambari所管理端额大数据平台组件服务做如下的划分：

HDFS采用主从(Master/Slave)结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组成的。其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作；集群中的DataNode管理存储的数据。将NameNode作为管理服务部署到管理服务节点上，将DataNode作为非管理服务部署到非管理服务节点上。

Yarn包括ResourceManager和NodeManager，ResourceManager控制整个Yarn集群并管理应用程序向基础计算资源的分配。ResourceManager将各个资源部分(计算、内存、带宽等)安排给基础NodeManager。NodeManager管理一个Yarn集群中的每个节点。NodeManager提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。本公开将ResourceManager作为管理服务部署到管理服务节点，将NodeManager作为非管理服务部署到非管理服务节点。

HBase包括HMaster和HRegionServer，HMaster主要负责Table和Region的管理工作。HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。本公开将HMaster作为管理服务部署到管理服务节点，将HRegionServer作为非管理服务部署到非管理服务节点。

Zookeeper是分布式应用程序协调服务，Kafka、HBase、HDFS等组件的服务都依赖Zookeeper，如果Zookeeper出现故障，则依赖Zookeeper的组件服务也会出现故障，属于协调员角色，是重要组件，因此本公开将Zookeeper作为管理服务部署在管理服务节点上。由于在多台管理服务节点上通过K8s结合HAProxy搭建了高可用集群，因此将Zookeeper部署到管理服务节点的K8s的Pod里，即使Zookeeper服务失败，K8s也可将其重新调度执行，直到恢复正常状态，从而保障依赖Zookeeper的服务不会因为Zookeeper故障而产生故障。

Kafka和Solr的服务属于对等节点，每个服务节点都可以做主服务节点也可以做从服务节点，不存在一个节点挂了就影响服务的情况，因此本公开将此类组件的服务作为非管理服务部署在非管理服务节点上。

K8s通过服务包镜像来生产容器，容器里面部署管理服务。非管理服务部署在非管理节点，由于将非管理服务直接部署在物理机上可获得更好的性能，因此可非管理节点可采用物理机直接部署非管理服务。

以图3的示例为参考，可使用多台部署K8s的管理服务节点结合HAProxy实现大数据平台组件中的管理服务的高可用性，保障重要的管理服务的高可用性。对于大数据平台组件中的非管理服务，可依据实际业务情况，按需部署到物理机上。

第二部分，管理服务的部署策略

由于Ambari-Server、NameNode、ResourceManager、HMaster和ZooKeeper等管理服务属于是有状态服务，且K8s的pod的IP地址是动态的，所以只能通过Kind＝Service机制进行创建。Kind＝Service属于K8s提供服务的一个标签定义，定义有这个标签的是可对外提供服务的角色。管理服务通过配置yaml文件来部署，通过K8s命令启动。

管理服务的部署除了创建容器镜像外，还要解决管理服务的配置动态更新问题，本公开采用ConfigMap功能来实现将管理服务的配置信息与管理服务程序分离的目的，通过ConfigMap功能可实现通过环境变量或者外接挂载文件的方式进行配置注入。针对每一个管理服务分别经过如下流程编写对应服务的yaml文件。

步骤A01：配置configMap.yaml文件(简称configMap文件)。

每个管理服务可以对应多个配置文件，每一个配置文件对应一个configMap.yaml文件，便于与对应Pod内的管理服务的关联。

Configmap.yaml文件用于配置pod启动时需要依赖的配置参数。通过configmap文件便于修改已传递给pod内的服务的配置参数，不用重新制作镜像，方便管理参数。

步骤A02：定义Service.yaml文件(简称Service文件)。

每个管理服务对应一个Service.yaml文件，在容器内部服务使用targetport，外部主机无法直接访问容器内部端口，所以容器pod需要将容器内部端口targetport映射到主机nodeport才能被外部主机访问，因此需要定义管理服务的nodePort和targetPort的映射关系，用于管理节点上Pod内的管理服务与非管理节点上的服务进行通信。

步骤A03：定义ReplicationController.yaml文件(简称RC文件)。

该步骤用于实现K8s中始终存在一个NameNode的pod，每一个pod都要有对应的存储，以实现数据的持久化保存。注意此时要关联“步骤A01”中的ConfigMap.yaml文件，当ConfigMap有变化时该RC对应的pod里面的服务能够加载使用最新值。

RC文件属于K8s的控制器，用于保持K8s内的pod个数。如Zookeeper需要部署3个节点，即3个Pod，3个Pod共用一套yaml文件，则在RC文件内配置数量为3，K8s会保障3个pod同时运行。

由于容器不具备保存数据功能，Pod重启后数据会丢失，所以需要把管理服务需要持久化的数据持久化到主机某个路径下。如Namenode是管理服务，其需要记录DataNode元数据以管理DataNode；Zookeeper是应用协调服务的，其存储的元数据也需要持久化到主机某个路径下。

步骤A04：当通过Ambari的用户接口界面改变配置时，Ambari-server要告知K8s去更新“步骤A01”的configmap中，进而更新对应管理服务内的参数值。

Ambari-server通知K8s配置变更的方法可以为：Ambari-server启动一个守护脚本进行监控configmap文件的变化，当发现有变更时，守护脚本进程就修改对应的configmap文件。然后K8s重启对应的Pod内服务去加载新的configmap文件。

第三部分，非管理服务的部署策略

在物理机部署的DataNode、NodeManager、HRegionServer、Kafka和Solr等非管理服务。其中DataNode、NodeManager不依赖Zookeeper，HRegionServer、Kafka和Solr需要依赖Zookeeper。因此可分为两类讨论：

图4示例了不依赖Zookeeper集群的非管理服务在物理机上的集群部署示例。

以下是对不依赖Zookeeper的非管理服务的部署过程的描述，需要说明的是，因为非管理服务依赖于对应的管理服务，因此需要首先在管理节点的K8s集群上部署对应的管理服务后再通过Ambari部署与管理服务对应的非管理服务。

步骤B01：在多台管理服务节点上部署K8s组成集群并部署HAProxy；

例如，HDFS、Yarn、Ambari这些组件都不依赖于Zookeeper，在部署这些组件的非管理服务之前，需要先在管理服务节点上部署K8s集群+HAProxy环境，然后先在K8s集群中部署这些组件的管理服务，最后再通过Ambari部署这些组件的非管理服务。

步骤B02：根据管理服务部署策略编制相应的yaml文件，并在K8s集群内启动Pod运行相应的管理服务。

步骤B03：通过Ambari的用户接口UI界面在非管理节点即数据节点部署与管理服务相对应的非管理服务。

例如，对于Hadoop大数据平台的核心组件HDFS来说，首先需要在管理服务节点上部署NameNode，部署完后在K8s集群内启动NameNode服务，最后通过Ambari的用户接口UI界面按需在非管理节点上部署并启动DataNode服务。

图5示例了依赖Zookeeper集群的大数据平台组件的部署示例。依赖Zookeeper集群的大数据平台组件可能包括管理服务，也可能不包括管理服务，例如Kafka组件不包括本公开定义的管理服务，HBase组件既包括本公开定义的管理服务也包括本公开定义的非管理服务。此类依赖Zookeeper的非管理服务在部署时，需要向K8s通信，告知k8s创建一个Zookeeper服务集群给自己。等k8s创建完成后，K8s会把所创建的Zookeeper集群的服务域名及对应的IP：NodePort动态加载到这些组件的管理服务和非管理服务的配置里面。

依赖Zookeeper的大数据平台组件的非管理服务的部署过程描述如下：

步骤C01：在多台管理服务节点上部署K8s组成集群并部署HAProxy；

如前所述，在部署依赖Zookeeper的组件的非管理服务之前，需要首先在管理服务节点上部署K8s集群+HAProxy环境，然后先在K8s集群中部署Ambari的管理服务，如果这些依赖Zookeeper的组件有管理服务，也需要现在管理节点部署对应的管理服务，最后再通过Ambari部署这些组件的非管理服务。

步骤C02：根据管理服务部署策略编制相应的yaml文件，并在k8s集群内启动Pod运行相应的管理服务。

步骤C03：在K8s集群内部署依赖Zookeeper的组件所依赖的Zookeeper集群，并将创建的Zookeeper集群的服务域名及对应的IP：NodePort动态加载到这些组件的管理服务和非管理服务的配置里面。

例如，在部署HBase组件的时候，在部署HBase的管理服务之前，或在部署HBase的非管理服务之之前，或HBase的所有服务都部署完毕之后，再部署HBase所依赖的Zookeeper集群，在Zookeeper集群部署成功后，通过动态加载机制将Zookeeper集群的服务域名、网络访问地址及端口加载到HBase的管理服务和非管理服务的配置里，本公开不限定Zookeeper集群的部署时机。

步骤C04：通过Ambari用户接口UI界面在非管理服务节点即数据节点部署非管理服务。

图6为本公开一实施例提供的一种电子设备结构示意图，该设备600包括：诸如中央处理单元(CPU)的处理器610、通信总线620、通信接口640以及存储介质630。其中，处理器610与存储介质630可以通过通信总线620相互通信。存储介质630内存储有计算机程序，当该计算机程序被处理器610执行时用于实现本公开提供的方法的步骤或运行本公开所述的管理服务或非管理服务以及分布式应用协调组件的服务程序。

其中，存储介质可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。另外，存储介质还可以是至少一个位于远离前述处理器的存储装置。处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable GateArray，FPGA)或其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

应当认识到，本公开的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术，包括配置有计算机程序的非暂时性存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。此外，可按任何合适的顺序来执行本公开描述的过程的操作，除非本公开另外指示或以其他方式明显地与上下文矛盾。本公开描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本公开的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本公开所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本公开所述的方法和技术编程时，本公开还包括计算机本身。

以上所述仅为本公开的实施例而已，并不用于限制本公开。对于本领域技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (8)

1.一种大数据平台组件部署方法，其特征在于，所述方法包括：

在多个管理服务节点部署容器编排引擎集群，并为所述容器编排引擎集群部署高可用组件；

将大数据平台组件的管理服务安装包部署在由多个管理服务节点组成的容器编排引擎集群中；所述管理服务安装包中仅包括所述大数据平台组件中只参与任务的分发和调度的管理服务的安装包；

将大数据平台组件的非管理服务安装包部署在一个或多个非管理节点；所述非管理服务安装包中仅包括只参与任务的计算和数据的存储的非管理服务的安装包；

所述大数据平台组件的管理服务运行于容器当中，为实现所述管理服务的配置的动态更新，采用配置信息与服务程序分离的机制实现配置信息的注入；为实现所述大数据平台组件的管理服务持续服务能力，所述容器编排引擎集群通过控制机制使预定数量的承载所述大数据平台组件的管理服务的容器进程持续运行。

2.根据权利要求1所述的方法，其特征在于，所述管理服务安装包中还包括大数据管理平台组件的管理服务的安装包，所述非管理服务安装包中还包括大数据管理平台组件的非管理服务的安装包，所述方法还包括：

通过容器编排引擎启动所述大数据管理平台组件的管理服务后，通过所述大数据管理平台组件的管理服务添加所述一个或多个非管理服务节点，然后执行所述将大数据平台组件的非管理服务安装包部署在一个或多个非管理节点的步骤。

3.根据权利要求2所述的方法，其特征在于，当所述大数据平台组件依赖分布式应用协调服务组件时，所述方法还包括：

在所述由多个管理服务节点组成的容器编排引擎集群中为所述大数据平台组件部署分布式应用协调服务组件集群，并将创建的分布式应用协调服务组件集群的服务域名和网络访问地址及端口动态加载到所述大数据平台组件的管理服务和非管理服务的配置里。

4.根据权利要求3所述的方法，其特征在于，

所述容器编排引擎集群为K8s，所述高可用组件为HAProxy，所述大数据平台组件包括HDFS、Yarn、HBase、Zookeeper、Kafka、Solr组件中的一种或多种；大数据管理平台组件为Ambari；所述分布式应用协调服务组件为Zookeeper；

所述Ambari的管理服务为Ambari-Server，非管理服务为Ambari-Agent；

所述HDFS的管理服务为NameNode，非管理服务为DataNode；

所述Yarn的管理服务为ResourceManager，非管理服务为NodeManager；

所述HBase的管理服务为HMaster，非管理服务为HRegionServer；

所述Kafka和Solr的服务为非管理服务。

5.一种大数据平台组件部署装置，其特征在于，所述装置包括：多个管理服务节点、一个或多个非管理服务节点和高可用组件；

所述多个管理服务节点部署有容器编排引擎集群，所述高可用组件为所述容器编排引擎集群中的管理服务提供高可用性；

所述多个管理服务节点中部署有所述大数据平台组件的管理服务；所述管理服务为所述大数据平台组件中只参与任务的分发和调度的服务；

所述一个或多个非管理服务节点中部署有所述大数据平台组件的非管理服务；所述非管理服务为所述大数据平台组件中只参与任务的计算和数据的存储的服务；

所述大数据平台组件的管理服务运行于容器当中，所述大数据平台组件的管理服务采用配置信息与服务程序分离的机制实现配置信息的注入；

所述容器编排引擎集群通过控制机制使预定数量的承载所述大数据平台组件的管理服务的容器进程持续运行。

6.根据权利要求5所述的装置，其特征在于，

所述多个管理服务节点中还部署有大数据管理平台组件的管理服务，所述一个或多个非管理节点中还部署有所述大数据管理平台组件的非管理服务；

所述容器编排引擎启动所述大数据管理平台组件的管理服务后，所述大数据管理平台组件的管理服务添加所述一个或多个非管理服务节点，将所述大数据平台组件的非管理服务部署到所述一个或多个非管理节点。

7.根据权利要求6所述的装置，其特征在于，

所述多个管理服务节点中还部署有所述大数据平台组件所依赖的分布式应用协调服务组件集群，所述分布式应用协调服务组件集群的服务域名和网络访问地址及端口通过动态加载机制加载到所述大数据平台组件的管理服务和非管理服务的配置里。

8.根据权利要求7所述的装置，其特征在于，

所述容器编排引擎集群为K8s，所述高可用组件为HAProxy，所述大数据平台组件包括HDFS、Yarn、HBase、Zookeeper、Kafka、Solr组件中的一种或多种；大数据管理平台组件为Ambari；所述分布式应用协调服务组件为Zookeeper；

所述Ambari的管理服务为Ambari-Server，非管理服务为Ambari-Agent；

所述HDFS的管理服务为NameNode，非管理服务为DataNode；

所述Yarn的管理服务为ResourceManager，非管理服务为NodeManager；

所述HBase的管理服务为HMaster，非管理服务为HRegionServer；

所述Kafka和Solr的服务为非管理服务。

Images