大数据平台租户管理系统、方法、存储介质及电子设备与流程

1.本发明涉及大数据平台技术领域，具体涉及一种大数据平台租户管理系统、方法、存储介质及电子设备。


背景技术：

2.随着大数据平台技术的发展，大数据服务越来越多的应用于各个行业的数据分析、数据规律研究等各种场景中。例如大数据平台提供的mapreduce服务(mrs)是兼容开源、租户完全可控的企业级海杜普(hadoop)大数据集群云服务，通过mrs可以实现海量数据分析的场景，比如，在研究某个城市天气变化规律的场景中，可以通过大数据平台的mrs服务在很短的时间内完成某个城市近一年或多年的天气变化趋势分析，其中大数据平台用于分析天气变化趋势的基础数据可能来源于一些天气服务应用程序(application，app)或浏览器页面等；在分析客户购物喜好的场景中，可以通过大数据平台的mrs服务快速分析出客户的搜索偏好来分析客户的购物喜好，以实现更精准的商品推送达成更高的商品销售成交率。其中，用于分析客户购物喜好的基础数据可能来源于一些购物app或浏览器页面等。
3.大数据平台提供数据服务的示意性场景如图1所示，大数据平台100可以包括大数据平台租户管理系统110和大数据平台数据服务系统120。大数据平台租户管理系统110用于对用户在大数据平台100上开通的租户进行管理，包括管理租户的基本信息(包括租户的系统名称、id等信息)、租户资源配置，以及对租户资源进行监控和对空置的资源进行回收等，如图1所示，大数据平台租户管理系统110上管理的租户1-n与用户之间可以是一对一或多对一的对应关系，每个租户n有唯一的系统名称及id；大数据平台数据服务系统120则通过数据采集、数据存储、数据分析、数据建模以及数据展示等方式通过租户向对应的用户提供用户所需的各种数据服务。大数据平台的用户可以是个人(例如科研人员、针对特定需求的软件开发人员等)，也可以是单位(例如科研单位、政务单位等)，还可以是各种互联网行业的各开发商(例如智能设备开发商、app开发商等)。不同用户对大数据平台的使用需求类型不同、服务资源需求量也有所不同，有些用户仅需要在大数据平台上开通一个租户即可满足其使用需求，而有些用户使用需求多、服务资源需求量大，则需要开通多个租户来满足其使用需求。由于每个租户的资源容量有限，当现有租户的资源使用量达到或超过该租户的资源总容量时，则需要创建新租户来响应用户的服务请求。


技术实现要素：

4.本技术实施例提供了一种大数据平台租户管理系统及方法，通过自动检测并监控租户的资源使用情况，判断是否满足新建租户条件；在租户的资源使用情况满足新建租户条件时，系统自动向用户发出告警通知并自动触发新建租户流程的开始，自动创建新租户并为新租户自动部署所需服务部件，以及自动向公有云申请创建云服务实例；新租户准备就绪后，系统自动启用新租户响应新的app接入请求，实现对租户的资源监控、预警以及新建租户流程的自动化管理，大大提高了管理效率，节约人工成本，并且预警性强，能够有效
避免租户资源使用量超限带来的诸多问题，提高了大数据平台用户的使用体验。
5.第一方面，本技术实施例提供了一种大数据平台租户管理系统，所述系统包括：综合管理子系统，用于在检测到所述大数据平台上用户的租户资源使用情况满足新建租户条件的情况下，向告警子系统发送告警信息；告警子系统，用于在接收到所述告警信息后获取所述用户创建新租户所需的第一资源；自动部署工具，用于在获取到的所述第一资源上为所述用户创建的新租户部署服务部件。
6.例如，综合管理子系统的租户管理模块用于管理租户以及自动检测租户的资源使用情况，综合管理子系统的配置管理模块用于配置租户资源的容量阈值或使用率阈值并据此监控租户的资源使用情况是否满足新建租户条件。新建租户条件满足时，综合管理子系统的配置管理模块便向告警子系统发送告警信息。告警子系统的告警接入模块用于将上述告警信息接收至告警子系统中，告警子系统中的资源申请模块用于获取创建新租户所需的虚拟机资源(例如，第一资源是虚拟机资源)。
7.在上述第一方面的一种可能的实现中，在所述租户的资源使用量大于或等于容量阈值的情况下，所述用户的租户资源使用情况满足新建租户条件；或者在所述租户的资源使用率大于或等于使用率阈值的情况下，所述用户的租户资源使用情况满足新建租户条件，其中，所述租户的资源使用率为所述租户的资源使用量与所述租户的资源总容量之间的比值。
8.例如，如果综合管理子系统的配置管理模块设置的是容量阈值，则相应地在租户的资源使用量大于或等于容量阈值的情况下，向告警子系统发送告警信息；如果综合管理子系统的配置管理模块设置的是使用率阈值，则相应地在租户的资源使用率大于或等于使用率阈值的情况下，向告警子系统发送告警信息。
9.在上述第一方面的一种可能的实现中，所述告警子系统通过以下方式获取所述第一资源：在所述大数据平台上所述用户的空置资源少于所述第一资源的情况下，所述告警子系统向所述大数据平台外部发送资源获取请求，其中，所述资源获取请求用于请求获取第二资源，所述第二资源根据所述第一资源与所述空置资源之间的差异确定；在所述大数据平台上所述用户的空置资源多于或等于所述第一资源的情况下，所述告警子系统获取所述空置资源作为所述第一资源。
10.例如，空置资源为空置虚拟机资源，告警子系统中的资源申请模块可以在大数据平台上的资源池里查询空置虚拟机资源情况，如果资源池里的空置虚拟机资源不足以供新租户使用，则调用外部虚拟机资源库的资源申请api申请虚拟机新资源(例如，第二资源是虚拟机新资源)作为补充。如果资源池里的空置虚拟机资源充足，则资源申请模块可以向综合管理子系统发送资源充足的反馈信息。这种资源获取方式利于提高大数据平台的资源使用效率。
11.在上述第一方面的一种可能的实现中，所述自动部署工具通过以下方式在获取到的所述第一资源上为所述用户创建的新租户部署服务部件：从所述第一资源中筛选所述服务部件所需的第三资源；在获取的所述第三资源上为所述服务部件创建服务器集群及服务器集群拓扑结构；在创建的所述集群上安装所述服务部件所需的软件；启动所述软件并完成所述软件的初始参数的配置。
12.例如，自动部署工具的自动拉取脚本从大数据平台上的软件仓里获取服务部件的
服务软件包，该服务软件包中包括相应服务部件的过滤器(filter)、集群拓扑结构要求描述文本、软件二进制文件以及自动化脚本。自动部署工具的自动组建集群模块能够解析上述服务软件包，并利用该服务软件包中的filter从第一资源(例如是为新租户准备的虚拟机资源)中筛选相应服务部件所需的虚拟机资源(即第三资源)；自动组建集群模块在筛选得到的第三资源上为上述服务部件创建服务器集群及服务器集群拓扑结构，自动部署工具的自动安装流程控制模块可以用于控制上述自动化脚本的运行，在上述创建的集群上安装该服务软件包中的软件，软件安装完成后再启动已安装的软件。
13.在上述第一方面的一种可能的实现中，所述自动部署工具在获取到的所述第一资源上为所述用户创建的新租户部署服务部件的方式还包括：在所述服务部件之间存在依赖关系的情况下，基于所述依赖关系构建所述服务部件之间的树状依赖关系，并且，所述自动部署工具按照所述树状依赖关系，自所述树状依赖关系的根部依次向上串行安装各所述服务部件所需的软件，以及在各所述服务部件所需的软件完成安装后，按照所述树状依赖关系，自所述树状依赖关系的根部依次向上串行启动各所述服务部件的软件；在所述服务部件之间不存在依赖关系的情况下，所述自动部署工具按照并行方式安装各所述服务部件所需的软件，并在各所述服务部件所需的软件完成安装后，按照并行方式启动各所述服务部件的软件。
14.例如，树状依赖关系中，被依赖的服务部件更靠近树状依赖关系的根部。自动部署工具在部署服务部件时，被依赖的服务部件的软件先进行安装，再按照树状依赖关系的根部向上依次安装其他服务部件的软件。当所有服务部件的软件全部安装完成后，自动部署工具先启动运行被依赖的服务部件的软件，再按照树状依赖关系的根部向上依次启动运行其他服务部件的软件。
15.在上述第一方面的一种可能的实现中，在检测到所述大数据平台上用户的租户资源使用情况满足新建租户条件的情况下，所述综合管理子系统还用于生成所述新租户的识别信息，其中，所述识别信息至少包括所述新租户在所述大数据平台中的系统名称或所述新租户的身份识别号；并且，在所述服务部件部署完成的情况下，所述综合管理子系统向所述服务部件发送所述新租户的识别信息，激活所述服务部件；并且，在所述服务部件完成激活的情况下，所述综合管理子系统向公有云发送实例申请请求，所述实例申请请求用于申请在所述公有云中为所述新租户创建云服务实例。
16.例如，综合管理子系统中的租户管理模块在新建租户流程开始时自动生成新租户的系统名称，或者自动生成新租户的身份识别号(identity document，id)，也可以同时生成新租户的系统名称和id，以将新租户与现有的其他租户加以区分识别。当自动部署工具将服务部件部署完成后，可以向综合管理子系统反馈服务部件的访问地址(url地址)，综合管理子系统中的租户管理模块根据服务部件的访问地址发送新租户的识别信息，以激活服务部件。服务部件接收到新租户的识别信息后按照新租户的识别信息为新租户响应服务请求做准备，例如为新租户响应app接入请求做准备。
17.在上述第一方面的一种可能的实现中，所述租户所需的资源包括虚拟机资源、物理机资源、容器资源中的至少一种，所述租户所需的资源包括所述第一资源。
18.例如，上述第一资源、空置资源、第二资源以及第三资源都是虚拟机资源。
19.第二方面，本技术实施例提供了一种大数据平台租户资源管理方法，所述方法包
括：检测到所述大数据平台上用户的租户资源使用情况满足新建租户条件的条件下，发送告警信息；其中，所述告警信息能够触发获取所述用户创建新租户所需的第一资源；在获取到的所述第一资源上为所述用户创建的新租户部署服务部件。
20.在上述第二方面的一种可能的实现中，上述方法还包括：在所述租户的资源使用量大于或等于预设的容量阈值的情况下，所述用户的租户资源使用情况满足新建租户条件；或者在所述租户的资源使用率大于或等于使用率阈值的情况下，所述用户的租户资源使用情况满足新建租户条件，其中，所述租户的资源使用率为所述租户的资源使用量与所述租户的资源总容量之间的比值。
21.在上述第二方面的一种可能的实现中，上述方法还包括：通过以下方式获取所述用户创建新租户所需的第一资源：在所述大数据平台上所述用户的空置资源少于所述第一资源的情况下，向所述大数据平台外部发送资源获取请求，其中，所述资源获取请求用于请求获取第二资源，所述第二资源根据所述第一资源与所述空置资源之间的差异确定；在所述大数据平台上所述用户的空置资源多于或等于所述第一资源的情况下，获取所述空置资源作为所述第一资源。
22.在上述第二方面的一种可能的实现中，所述在获取到的所述第一资源上为所述用户创建的新租户部署服务部件包括：从所述第一资源中筛选所述服务部件所需的第三资源；在获取的所述第三资源上为所述服务部件创建服务器集群及服务器集群拓扑结构；在创建的所述集群上安装所述服务部件所需的软件；启动所述软件并完成所述软件的初始参数的配置。
23.在上述第二方面的一种可能的实现中，所述在获取到的所述第一资源上为所述用户创建的新租户部署服务部件还包括：在所述服务部件之间存在依赖关系的情况下，基于所述依赖关系构建所述服务部件之间的树状依赖关系，并且，按照所述树状依赖关系，自所述树状依赖关系的根部依次向上串行安装各所述服务部件所需的软件，以及在各所述服务部件所需的软件完成安装后，按照所述树状依赖关系，自所述树状依赖关系的根部依次向上串行启动各所述服务部件的软件；在所述服务部件之间不存在依赖关系的情况下，按照并行方式安装各所述服务部件所需的软件，并在各所述服务部件所需的软件完成安装后，按照并行方式启动各所述服务部件的软件。
24.在上述第二方面的一种可能的实现中，上述方法还包括：所述告警信息能够触发所述大数据平台生成所述新租户的识别信息，所述识别信息至少包括所述新租户在所述大数据平台中的系统名称或所述新租户的身份识别号；并且，在所述服务部件部署完成的情况下，向所述服务部件发送所述新租户的识别信息，激活所述服务部件；并且，在所述服务部件完成激活的情况下，所述大数据平台向公有云发送实例申请请求，所述实例申请请求用于申请在所述公有云中为所述新租户创建云服务实例。
25.在上述第二方面的一种可能的实现中，上述方法还包括：所述租户所需的资源包括虚拟机资源、物理机资源、容器资源中的至少一种，所述租户所需的资源包括所述第一资源。
26.第三方面，本技术实施例提供了一种一种大数据平台租户管理方法，该方法包括：在所述大数据平台上用户的租户资源使用情况满足新建租户条件的条件下，接收到告警信息；根据获取的所述告警信息获取所述用户创建新租户所需的第一资源；其中，所述第一资
源上能够部署所述租户的服务部件。
27.例如，告警子系统在接收到综合管理子系统发来的告警信息后，获取所述用户创建新租户所需的虚拟机资源(例如，第一资源是虚拟机资源)。
28.在上述第三方面的一种可能的实现中，上述方法还包括：在所述租户的资源使用量大于或等于预设的容量阈值的情况下，所述用户的租户资源使用情况满足新建租户条件；或者在所述租户的资源使用率大于或等于使用率阈值的情况下，所述用户的租户资源使用情况满足新建租户条件，其中，资源使用率为所述租户的资源使用量与所述租户的资源总容量之间的比值。
29.在上述第三方面的一种可能的实现中，上述方法还包括通过以下方式获取所述用户创建新租户所需的第一资源：在所述大数据平台上所述用户的空置资源少于所述第一资源的情况下，向所述大数据平台外部发送资源获取请求，其中，所述资源获取请求用于请求获取第二资源，所述第二资源根据所述第一资源与所述空置资源之间的差异确定；在所述大数据平台上所述用户的空置资源多于或等于所述第一资源的情况下，获取所述空置资源作为所述第一资源。
30.在上述第三方面的一种可能的实现中，所述租户所需的资源包括虚拟机资源、物理机资源、容器资源中的至少一种，所述租户所需的资源包括所述第一资源。
31.第四方面，本技术实施例提供了一种大数据平台租户资源管理方法，该方法包括：获取调用指令；响应于所述调用指令，在第一资源上为所述大数据平台的用户创建的新租户部署服务部件。
32.例如，自动部署工具获取到综合管理子系统的调用指令后，响应该调用指令在准备好的虚拟机资源上为新租户部署服务部件。
33.在上述第四方面的一种可能的实现中，所述在获取到的所述第一资源上为所述用户创建的新租户部署服务部件包括：从所述第一资源中筛选所述服务部件所需的第三资源；在获取的所述第三资源上为所述服务部件创建服务器集群及服务器集群拓扑结构；在创建的所述集群上安装所述服务部件所需的软件；启动所述软件并完成所述软件的初始参数的配置。
34.在上述第四方面的一种可能的实现中，所述在获取到的所述第一资源上为所述用户创建的新租户部署服务部件还包括：在所述服务部件之间存在依赖关系的情况下，基于所述依赖关系构建所述服务部件之间的树状依赖关系，并且，按照所述树状依赖关系，自所述树状依赖关系的根部依次向上串行安装各所述服务部件所需的软件，以及在各所述服务部件所需的软件完成安装后，按照所述树状依赖关系，自所述树状依赖关系的根部依次向上串行启动各所述服务部件的软件；在所述服务部件之间不存在依赖关系的情况下，按照并行方式安装各所述服务部件所需的软件，并在各所述服务部件所需的软件完成安装后，按照并行方式启动各所述服务部件的软件。
35.第五方面，本技术实施例提供了一种计算机可读存储介质，所述存储介质上存储有指令，所述指令在计算机上执行时使所述计算机执上述大数据平台租户管理方法。
36.第六方面，本技术实施例提供了一种电子设备，包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个程序，当所述一个或者多个程序被所述一个或多个处理器执行时，使得所述电子设备执行上述大数据平台租户管理方法。
37.第七方面，本技术实施例提供了一种装置，该装置包含在电子设备中，该装置具有实现上述方面及上述方面的可能实现方式中电子设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或子系统。例如，综合管理子系统(如具有该子系统功能的处理器)，自动部署工具(如具有该工具功能的控制器)等。例如，综合管理子系统用于管理租户、配置容量阈值、自动检测并监控租户的资源使用量，在租户的资源使用量大于容量阈值时发出告警信息、以及在新建租户流程开始时生成新租户的识别信息，还用于向公有云为新租户申请云服务实例等；自动部署工具用于获取服务软件包、为新租户部署服务部件等。
附图说明
38.图1所示为大数据平台提供数据服务的场景示意图。
39.图2所示为本技术实施例的大数据平台租户管理系统及方法的应用场景示意图。
40.图3所示为本技术实施例的大数据平台租户管理系统的结构示意图。
41.图4所示为本技术实施例的大数据平台租户管理方法的流程示意图。
42.图5所示为本技术实施例的大数据平台租户管理系统110的运维界面示意图。
43.图6示出了本技术实施例的一种计算机的系统框图。
具体实施方式
44.如上所述，大数据平台100包括大数据平台租户管理系统110和大数据平台数据服务系统120。在用户开通的现有租户剩余可用资源不足的情况下，需要开通新租户扩展资源以满足用户需求。本技术的实施例公开了一种大数据平台租户管理方法，该方法基于大数据平台租户管理系统110，能够自动对现有租户的资源使用量进行监控，并在现有租户剩余可用资源不足的情况下，自动为用户开通新租户拓展资源以满足用户需求。
45.为使本技术的目的、技术方案和优点更加清楚，下面通过结合附图和实施方案，对本技术实施例的技术方案做进一步地详细描述。
46.为避免概念混淆，在本技术实施例中，对大数据平台100的用户以下简称为用户，对具体的app用户以下简称为客户，在此予以区别说明。例如，对于购物app，开发该购物app的应用开发商可以是用户，下载该购物app进行购物的使用者则是客户。
47.在图1所示的大数据平台提供数据服务的示意性场景中，大数据平台数据服务系统120中数据采集的方式可以有多种，包括但不限于日志采集、以及数据源数据同步等方式，在此不做限制。以采集app日志数据为例，可以通过开发专用统计软件开发工具包(software development kit，sdk)用于app的日志数据采集。也就是说，当app成功接入大数据平台100后，app运行过程中产生的各类日志数据可以源源不断推入大数据平台100。一般来说，app运行过程中的相关数据都具有较强的业务特征、自定义要求也比较高，因此除应用环境等一些基本数据以外，更多的是“按事件”的角度来采集app数据，比如登陆事件、业务操作事件等。大数据平台数据服务系统120中数据存储是将数据采集过程采集到的各种数据进行存储，以用于进一步的数据分析、数据建模以及数据展示。用户根据其需求或对数据的使用目的，通过用户界面上的某个租户向大数据平台100发出数据请求，大数据平台数据服务系统120则基于已存储的海量数据进行数据分析、建模或展示等过程得到符合该
数据请求的结果反馈给用户。例如，基于租户接入的某个购物app相关数据进行大数据服务，大数据平台100可以基于客户搜索商品而产生的日志数据分析该客户的购物喜好，还可以综合客户注册信息中的年龄、性别等信息分析客户的购物喜好与年龄、性别之间的关系等。可以理解，大数据平台数据服务系统120向用户展示数据服务结果的形式可以由用户自行设定，在此不做限制。
48.如上所述，在本技术实施例中，大数据平台100上的租户由大数据平台租户管理系统110进行管理。
49.图2示出了本技术实施例的一种大数据平台租户管理系统110的应用场景示意图。如图2所示，在大数据平台租户管理系统110中，用户111有租户1111，用户112有租户1121-1122，用户113有租户1131-1133。可以理解，在另一些实施例中，每个用户还可以有其他数量的租户，每个用户根据自己的需求可以在大数据平台100上申请一个或多个租户，在此不做限制。
50.可以理解，上述租户之间资源相互隔离，租户通过其服务部件以及云服务实例响应用户的各类请求。租户的资源主要用于响应用户的各类请求，为了便于理解，下面以租户的资源响应app的接入请求为例详细介绍本技术的技术方案，其中，app的资源使用量可以量化为租户接入app的数量。
51.可以理解，由于租户资源有限，因此每个租户能够响应的app接入请求数量亦有限，app接入请求被响应后该app即成功接入租户。当某个用户的现有租户响应的app接入请求即将到达数量上限时，该用户需要创建新租户来响应新的app接入请求。值得注意的是，当新租户的资源准备就绪时，该用户则启用新租户响应新的app接入请求，同时停止使用上述现有租户响应新的app接入请求，该现有租户接入的app数量为截至新租户资源准备就绪时已接入的app数量。
52.如图2所示，假定每个租户可以响应500个app接入请求。在用户的现有租户资源充足的情况下，新的app接入请求会由现有租户响应。例如，用户111有300个app需要接入租户，则这300个app的接入请求均由租户1111响应，并且租户1111还剩余有满足响应200个app接入请求的资源。在用户的现有租户资源不足的情况下，用户则需要多个租户来响应app的接入请求，例如用户112共有两个租户1121和1122，当有800个app需要接入租户时，用户112要在其租户1121接入第500个app之前完成新建租户流程得到准备就绪的新租户1122，在租户1122准备就绪的同时启用租户1122响应新的app接入请求，同时租户1121停止响应新的app接入请求。如果在租户1121已响应第499个app的接入请求时，租户1122新建完成并准备就绪，则从此时开始，租户1121停止响应新的app接入请求，而由租户1122继续响应第500个app及之后其他新app的接入请求。
53.以此类推，用户113共有三个租户1131-1133，当有1110个app需要接入租户时，用户113要在租户1131接入第500个app之前完成新建租户流程得到准备就绪的新租户1132来继续响应新app的接入请求；比如在租户1131已响应第501个app的接入请求时，租户1132新建完成并准备就绪，则从此时开始，租户1132继续响应第502个app的接入请求，同时租户1131停止响应新app的接入请求；随着租户1132接入app的数量不断增加，用户113要在租户1132接入第1002个app之前完成新建租户流程得到准备就绪的新租户1133来继续响应新app的接入请求。比如在租户1132已响应第1000个app的接入请求时，租户1133新建完成并
准备就绪，则从此时开始，租户1133继续响应第1001个app的接入请求，同时租户1132停止响应新app的接入请求。而如果用户的app接入需求超过用户已有租户的app接入承载量，则需要为用户申请新的租户。例如，用户113如果共有2000个app需要接入租户，则需要为用户113申请新的能够接入500个app的租户。
54.可以理解，租户接入app的数量在很大程度上也取决于每个app需要占用的资源量大小，例如有些app的客户量非常大，其接入某个租户后相应占用的资源量也会很大(这类app可以称之为大型app，例如微信)；而有些app的客户量小，其接入某个租户后相应占用的资源量也小(这类app可以称之为一般app或小型app，例如)，比如社交app中微信app所需资源量可能是其他社交app所需资源量的10倍左右。如果租户响应了某个大型app(例如微信)的接入请求，则可能该租户能够响应的app接入请求的数量就会减少。
55.目前对租户资源使用量的监控及新建租户流程主要依赖于人工。例如，通过大数据平台的运维界面人工监控各租户的资源使用量情况，当某租户的资源使用量接近或超过资源总容量时，人工操作运维界面向用户界面发送告警通知，同时人工监控该租户实时响应的请求接入量并不断催促用户尽快申请创建新租户。当用户申请开通新租户时，新建租户流程依赖于用户提交新租户开通申请、大数据平台100确认申请后再由人工提交各类资源申请、填写信息、确认授权等，一步步完成新租户开通流程，导致新租户的开通持续时间较长。如果在此过程中，现有租户的数据量出现突发性的暴涨(例如用户此时有一批app接入请求需要租户响应而引起数据量暴涨的情况)，则很可能会导致新租户开通完成之前，现有租户资源过载导致其运行效率降低甚至服务器崩溃的情况，而导致用户使用体验很差。
56.为解决上述技术问题，本技术提供了一种能够自动检测并监控租户资源使用情况以及自动完成新建租户流程的大数据平台租户管理系统及方法，通过自动检测并监控租户的资源使用情况，判断是否满足新建租户条件；在租户的资源使用情况满足新建租户条件时，系统自动向用户发出告警通知并自动触发新建租户流程的开始，自动创建新租户并为新租户自动部署所需服务部件，以及自动向公有云申请创建云服务实例；新租户准备就绪后，系统自动启用新租户响应新的app接入请求，实现对租户的资源监控、预警以及新建租户流程的自动化管理，大大提高了管理效率，节约人工成本，并且预警性强，能够有效避免租户资源使用量超限带来的诸多问题。
57.具体地，下面结合附图和具体实施方式来详细介绍本技术的大数据平台租户管理系统及方法。
58.图3示出了本技术实施例的大数据平台租户管理系统110的示意性系统结构框图。如图3所示，大数据平台租户管理系统110可以包括综合管理子系统101、告警子系统102、资源池103、自动部署工具104和软件仓105。其中，综合管理子系统101可以包括租户管理模块1011、配置管理模块1012和资源元数据管理模块1013，告警子系统102可以包括告警接入模块1021、告警发送模块1022和资源申请模块1023，资源池103可以包括资源导入接口1031、虚拟机资源管理模块1032和资源调用接口1033，自动部署工具104可以包括自动拉取脚本1041、自动组建集群模块1042和自动安装流程控制模块1043。各模块的功能将在下文进行详细的描述。
59.可以理解的是，本发明实施例示意的结构并不构成对大数据平台租户管理系统110的具体限定。在另一些实施例中，大数据平台租户管理系统110可以包括比图示更多或
更少的模块或系统结构，或者拆分某些模块或系统结构，或者不同的模块或系统结构布置等。图示的结构可以是软件模块、也可以是硬件或软件与硬件的组合实现。
60.其中，大数据平台租户管理系统110中每个系统结构或模块上的各种接口以及大数据平台租户管理系统110向公有云300申请云服务实例所调用的接口，可以是具有唯一识别信息的应用程序接口(application program interface，api)，同样是具有唯一识别信息的api。在大数据平台租户管理系统110中可以通过各种接口实现资源申请、资源导入、资源调用以及工具的调用和信息的传递等。上述接口也可以是其他类型具有唯一识别信息的接口、软件或脚本等，在此不做限制。
61.在上述大数据平台租户管理系统110中，各系统结构的功能参考以下描述，但下述功能描述亦不构成对各系统结构的具体限定，各系统结构可以具有更多的功能及相应的功能模块，在此不做限制。
62.综合管理子系统101
63.综合管理子系统101用于管理租户、配置容量阈值、自动检测并监控租户的资源使用量，以及管理大数据平台100上各租户的资源元数据，还用于为任意租户向公有云300申请创建云服务实例。其中，租户的资源包括服务部件集群(即上述服务部件)、在公有云上的云服务实例、以及运行服务部件所依赖的中央处理器(central processing unit，cpu)、内存等硬件资源(主要由虚拟机提供)，当租户的这些资源全部准备就绪(即硬件资源充足、服务部件及云服务实例等运行可用)时，租户才能够处理用户的各类请求。例如租户可以响应用户发出的app接入请求，app接入请求由租户的服务部件或云服务实例响应，app成功接入后会向大数据平台不断推送app运行过程中产生的各种数据，这些数据可以作为大数据平台数据服务系统120中数据采集的基础数据来源。上述所说的服务部件以及云服务实例，提供的是一台虚拟的计算环境，包含但不限于cpu、内存、操作系统、带宽、磁盘等基础的计算组件。上述资源元数据包括但不限于cpu、内存等资源的实时使用状态数据。
64.具体地，在一些实施例中，综合管理子系统101基于以下模块实现上述功能：
65.租户管理模块1011，用于管理租户以及自动检测租户的资源使用量。具体地，租户管理模块1011对租户的管理包括：对现有租户的识别信息、资源配置信息以及资源使用量进行一一对应的登记或记录，并自动检测租户的资源使用量等；租户管理模块1011对租户的管理还包括在满足创建新租户条件的情况下，通过执行预设算法而自动触发新建租户流程。新建租户流程开始后，新租户的系统名称以及id等信息会自动产生，并记录在租户管理模块1011内，作为新租户的唯一识别信息的组成部分。
66.配置管理模块1012，用于配置租户资源的容量阈值或使用率阈值，并监控租户的资源使用量是否超过该容量阈值，或者租户的资源使用率是否超过该使用率阈值。容量阈值或使用率阈值可以设置一个，也可以设置多个，在此不做限制。具体地，以设置一个容量阈值为例，配置管理模块1012可以从租户管理模块1011获取租户的资源使用量，并将获取的资源使用量与该租户的容量阈值相比较，当租户的资源使用量超过容量阈值时，配置管理模块1012向告警子系统102和租户管理模块1011发出告警信息，告警子系统102收到该告警信息后向用户发出告警通知并触发资源自动申请流程，租户管理模块1011收到该告警信息后自动触发新建租户流程。其中，租户管理模块1011接收到告警信息时表明新建租户条件已满足。
67.此外，在另一些实施例中，配置管理模块1012还可以设置多个容量阈值，例如，配置管理模块1012由低至高依次设置第一阈值、第二阈值、第三阈值，其中，第一阈值与第二阈值的差值大于第二阈值与第三阈值的差值，当租户的资源使用量超过第一阈值或第二阈值或第三阈值时，配置管理模块1012都会向告警子系统102和租户管理模块1011发出告警信息，这种告警机制下，可以设置告警子系统102仅在租户的资源使用量超过第三阈值时，触发资源自动申请流程，当租户的资源使用量超过第一阈值或第二阈值时，告警子系统102仅向用户发出告警通知。这种告警机制可以理解为阶段告警机制。
68.资源元数据管理模块1013，用于记录大数据平台100上对应于各租户的资源元数据的使用状态等以及对各租户的资源进行管理。资源元数据的使用状态包括但不限于cpu运行状态相关参数、内存占用状态相关参数等，资源元数据的使用状态用于供大数据平台100上对应于各租户的服务部件查询，还用于作为处理对cpu、内存等资源调用请求的依据，以实现对租户资源的管理。例如，当某个租户的某个服务部件需要使用某个资源(比如需要使用cpu进行计算或需要使用某个内存空间存储数据)时，但该资源当前不可用(比如已经没有cpu可分配)或资源不足(比如当前内存占用过大等)时，资源元数据管理模块1013则会拒绝该服务部件发来的调用请求，并向租户管理模块1011发送信息提示该租户的资源不足，租户管理模块1011收到该信息提示后可以管理该租户暂停响应上述服务部件支持的服务请求，待该服务部件需要使用的资源可用时再接入相应服务请求。资源元数据管理模块1013上设置有上调用接口，供其他系统(例如告警子系统102)调用。
69.告警子系统102
70.告警子系统102用于接收综合管理子系统101的配置管理模块1012发来的告警信息，告警子系统102接收告警信息之后向用户发出告警通知并触发资源自动申请流程，其中，资源自动申请流程是上述租户管理模块1011触发的新建租户流程中的一部分，资源自动申请流程可以为新租户准备资源，包括但不限于虚拟机资源、物理机资源以及容器资源等，在本实施例中，以新租户所需资源为虚拟机资源为例介绍本技术技术方案。具体地，在一些实施例中，告警子系统102基于以下模块实现上述功能：
71.告警接入模块1021，用于接收配置管理模块1012发来的告警信息，并将该告警信息发送给告警子系统的其他模块。
72.告警发送模块1022，用于接收告警接入模块1021发来的告警信息，并生成告警通知发送给用户，在另一些实施例中，告警发送模块1022还可以将告警通知发送至大数据平台100的运维界面，提醒大数据平台100的运维人员关注被告警的租户资源使用情况。
73.资源申请模块1023，用于接收告警接入模块1021发来的告警信息，资源申请模块1023收到该告警信息后，首先查询资源池103内的空置虚拟机资源情况，例如相关用户的空置虚拟机数量多少及空置虚拟机的配置参数等信息。当资源池103内的空置虚拟机资源不足以满足新租户的资源需求(例如空置虚拟机数量不够或者空置虚拟机的配置不符合新租户所需资源的配置要求)时，资源申请模块1023则自动调用外部虚拟机资源库的资源申请api申请虚拟机新资源作为补充。如果资源池103内的空置资源充足，则资源申请模块1023可以向综合管理子系统101发送资源充足的反馈信息。资源申请模块1023通过上述方式申请虚拟机新资源，能够有效避免大数据平台100内的空置虚拟机资源的浪费，提高大数据平台100内的资源使用率。
74.外部虚拟机资源库的管理系统响应该资源申请api的调用，返回虚拟机新资源的元数据，该虚拟机新资源的元数据包括但不限于互联网协议地址(internet protocol address，ip地址)、cpu、内存等信息。资源申请模块1023接收到资源申请api返回的虚拟机新资源元数据则表明虚拟机新资源申请成功，资源申请模块1023将接收到的虚拟机新资源的元数据发送给资源池103。
75.资源池103
76.资源池103用于管理大数据平台100内虚拟机资源的元数据，包括接收资源申请模块1023发来的虚拟机新资源的元数据。资源池103将接收到的虚拟机新资源元数据进行登记，将其归入上述大数据平台100的虚拟机资源的元数据中一并管理。其中，虚拟机资源的元数据包括但不限于虚拟机的属主信息(即该空置虚拟机或虚拟机新资源属于哪个用户)、使用或空置的状态信息、虚拟机的ip地址、cpu以及内存容量等。具体地，在一些实施例中，资源池103基于以下模块实现其功能：
77.资源导入接口1031，对外接受告警子系统102中资源申请模块1023的调用，对内与虚拟机资源管理模块1032连接以将资源申请模块1023发来的虚拟机新资源元数据传输至虚拟机资源管理模块1032中。
78.虚拟机资源管理模块1032，是资源池103的核心管理模块，用于实现资源池对大数据平台100内全部可用虚拟机资源的有效管理。大数据平台100内全部可用虚拟机资源包括大数据平台100内已有的虚拟机资源以及新申请获得的虚拟机新资源。虚拟机资源管理模块1032有序登记大数据平台100内全部可用虚拟机资源的元数据，包括但不限于登记每台虚拟机的属主信息、使用或空置的状态信息、虚拟机的ip地址、cpu以及内存容量等。虚拟机资源管理模块1032对虚拟机新资源的元数据完成登记后，即向告警子系统102发送资源确收信息，表明已成功接收虚拟机新资源。
79.资源调用接口1033，用于供自动部署工具104调用。自动部署工具104调用资源调用接口1033后，可以从虚拟机资源管理模块1032中获取部署服务部件所需要的虚拟机资源元数据。
80.当大数据平台100内的某台虚拟机资源元数据被获取使用后，虚拟机资源管理模块1032便将该虚拟机资源元数据中的空置状态信息更改为使用状态信息，以作标识。
81.同样地，当大数据平台100内的某台虚拟机资源不再使用时，虚拟机资源管理模块1032便将该虚拟机资源元数据中的使用状态信息更改为空置状态信息，以作标识。
82.自动部署工具104
83.自动部署工具104用于获取软件仓105中的服务软件包，并按照服务软件包中的资源过滤器(filter)描述以及自动化脚本等获取虚拟机资源、安装服务部件对应的软件并启动以完成部署服务部件。具体地，自动部署工具104基于以下模块实现其功能：
84.自动拉取脚本1041，用于从软件仓105中获取服务软件包，该服务软件包应与服务部件一一对应。该服务软件包中包括相应服务部件的filter、集群拓扑结构要求描述文本、软件二进制文件以及自动化脚本，其中，自动化脚本包括自动化安装脚本、自动化启动脚本、自动化卸载脚本、自动化升级脚本等等(还有环境检查脚本之类的)，用于完成流程中涉及到的安装、启动、卸载、升级等操作的需要。
85.自动组建集群模块1042，用于对自动拉取脚本1041获取的服务软件包进行解析，
并调用资源池103的资源调用接口1033从资源池103获取符合filter要求的虚拟机资源，以及在获取的虚拟机上自动创建集群拓扑结构。其中，从资源池103获取虚拟机资源时通过上述服务软件包中的filter过滤以得到符合要求的虚拟机。自动组建集群模块1042通过在获取的每台虚拟机上安装代理工具(agent，agent是与自动部署工具(server)相应的远程工具)，之后自动部署工具104便可以通过agent将服务软件包中的软件二进制文件、自动化脚本等复制到相应的虚拟机资源上进行软件的自动化安装和启动。
86.自动组建集群模块1042可以根据服务软件包中描述的集群拓扑结构要求，在获取的虚拟机资源上创建符合上述要求的集群拓扑结构。其中，集群拓扑结构表征的是在虚拟机上创建的集群中各节点(即服务器)之间的连接关系，在该集群拓扑结构的服务器可以运行自动化脚本，进行软件的自动化安装及启动。
87.自动组件集群模块1042还可以计算评估各服务部件所需资源之间的联系，在各服务部件所需资源允许同一虚拟机资源提供的情况下(下称资源合设)，自动组件集群模块1042将多个服务部件的集群拓扑结构创建在同一虚拟机上。资源合设能够最大限度的利用硬件资源，以免造成资源浪费。
88.自动安装流程控制模块1043，用于对服务软件包中软件二进制文件的安装运行过程及软件安装后的启动过程进行管理控制。自动安装流程控制模块1043通过上述agent运行自动化脚本，根据脚本中的软件安装及启动规则进行软件的自动化安装及自动化启动。自动化脚本设定的软件安装及启动规则包括以下两种情况：
89.(1)各服务部件之间存在依赖关系的情况下，基于该依赖关系可以生成的各服务部件之间树状依赖关系，自动化安装脚本中的安装规则基于该树状依赖关系设置。自动安装流程控制模块1043则根据该安装规则，控制自动化安装脚本按照上述树状依赖关系的根部依次向上串行安装各服务部件的软件，每个软件对应于一个服务部件。
90.相应地，自动化启动脚本中的启动规则也应是基于上述树状依赖关系设置。自动安装流程控制模块1043根据该启动规则，控制自动化启动脚本按照上述树状依赖关系的根部依次向上串行启动已安装完成的各服务部件的软件。
91.(2)各服务部件之间不存在依赖关系的情况下，自动化安装脚本中的安装规则设置为并行安装各服务部件的软件。自动安装流程控制模块1043根据该安装规则控制自动化安装脚本并行安装各服务部件的软件。
92.相应地，自动化启动脚本中启动规则也设置为并行启动各服务部件的软件。自动安装流程控制模块1043根据该启动规则控制自动化启动脚本并行启动各服务部件的软件。
93.软件仓105
94.软件仓105用于存储上述服务软件包，该服务软件包与需要部署的服务部件一一对应。大数据平台100的服务软件包发布后，自动上传到软件仓105内，以供自动部署工具104获取进行相关服务部件对应的服务软件包。服务软件包一般是压缩文件包，其中包括的文件及用途已在上述自动部署工具104的相关描述中进行说明，在此不再赘述。
95.大数据平台租户管理系统110通过上述综合管理子系统101、告警子系统102资源池103、自动部署工具104以及软件仓105，实现对租户的资源监控、预警以及新建租户流程的自动化管理，使得大数据平台100能够对用户提供资源监控、创建新租户等一揽子服务，利于提高用户使用大数据平台100的服务满意度。
96.下面在图3的基础上结合图4详细描述本技术的一种大数据平台租户管理方法的具体流程。
97.图4示出了本技术的一种大数据平台租户管理方法的流程示意图。如图4所示，该方法包括以下步骤：
98.s1：大数据平台租户管理系统110(下称系统110)自动检测现有租户的资源使用量。具体地，如上所述，系统110中的综合管理子系统101对大数据平台100上的现有租户资源使用量进行自动检测，
99.例如，图5示出了本技术实施例的大数据平台租户管理系统110的运维界面示意图。如图5所示，系统110的运维界面现有租户的系统名称为test(图5所示的租户名称为系统名称，系统名称在创建时自动生成)、自定义名称为test(自定义名称可以自行设定)、租户id为p5、服务部件集群为cluster1。作为示例，租户test的资源总容量可以用该租户能够响应的app接入请求数量来表征，例如租户test能够响应500个app的接入请求。系统110对租户test已响应的app接入请求的数量进行自动检测，例如检测到该租户当前已响应350个app接入请求，完成第350个app的接入，则该租户的资源使用量已达到资源总容量的70％。系统110中可以合理设置自动检测的间隔时长，例如，每隔5分钟进行一次自动检测。每次自动检测的间隔时长也可以设置为更长或者更短，在此不做限制。
100.s2：系统110判断现有租户的资源使用情况是否满足新建租户条件。如果现有租户的资源使用情况满足新建租户条件，则进行步骤s3；如果现有租户的资源使用情况不满足新建租户条件，则进行步骤s1。
101.具体地，现有租户的资源使用情况是否满足新建租户条件可以基于两种方式判断：
102.(1)通过设置容量阈值，比较现有租户的资源使用量与容量阈值，现有租户的资源使用量大于或等于容量阈值时，现有租户的资源使用情况满足新建租户条件；否则，则不满足。
103.(2)通过设置使用率阈值，比较现有租户的资源使用率与使用率阈值，现有租户的资源使用率大于或等于使用率阈值时，现有租户的资源使用情况满足新建租户条件；否则，则不满足。其中现有租户的资源使用率为租户的资源使用量与租户的资源总容量之间的比值。
104.如上所述，系统110中的综合管理子系统101可以设置容量阈值对租户的资源使用情况进行监控，也可以是设置使用率阈值对资源使用量设定的阈值，在此不做限制。
105.例如，如图5所示，租户test能够响应的app接入请求数量上限是500个，可以对资源使用量与资源总容量之间比值设定容量阈值，比如容量阈值设定为90％；也可以对资源使用量设置容量阈值，比如容量阈值设置为450个app接入请求。
106.可以理解，容量阈值的设置方式可以是多种的，例如，用户可以通过大数据平台100上的用户界面对自己所拥有的租户设置容量阈值，大数据平台100的运维人员也可以在取得用户授权的情况下通过运维界面对每个用户名下的租户设置容量阈值，在此不做限制。可以理解，用户界面和运维界面分别是系统110向用户和运维人员展示的界面，通过上述方式可以设置系统110上每个租户的容量阈值。
107.s3：系统110判断现有租户资源使用量超过容量阈值的情况下，对外发出告警通
知，同时触发新建租户流程开始，并为新租户准备虚拟机资源。新建租户流程被触发，新租户的系统名称会自动生成，在另一些实施例中，新租户的id等识别信息也可以自动生成。
108.具体地，系统110中的综合管理子系统101监控现有租户资源使用量的过程中判断现有租户的资源使用量超过容量阈值时，向系统110中的告警子系统102发出告警信息，同时综合管理子系统101内部触发新建租户流程开始。告警子系统102接收该告警信息后，对外发出告警通知，包括但不限于对通过系统110的用户界面向用户发出告警通知、以及通过系统110的运维界面向运维人员发出告警通知。综合管理子系统101内自动触发新建租户流程开始，新租户的系统名称及id信息等会自动生成。
109.系统110工作的过程中，资源池103可以定期向告警子系统102发送池内相关用户的空置虚拟机资源的数量及配置信息，告警子系统102也可以通过调用资源池103的接口查询资源池103内相关用户的空置虚拟机资源的数量及配置信息。基于资源池103内相关用户的空置虚拟机资源的数量和配置信息，告警子系统102在发出告警通知的同时自动触发算法计算相关用户需要补充的虚拟机新资源数量及虚拟机的配置要求，进而调用外部虚拟机资源库的资源申请api申请虚拟机新资源。
110.可以理解，一般地，用户在系统110上完成首次创建租户后，创建新租户时会按照该用户已创建或首次创建的租户资源配置要求为新租户配置虚拟机资源以及部署服务部件，因此告警子系统102可以基于用户已创建或首次创建的租户配置计算虚拟机新资源的数量。用户也可以通过用户界面设置新租户的默认资源配置及服务部件配置等，在此不做限制。
111.告警子系统102收到外部虚拟机资源库反馈的虚拟机新资源元数据后，调用资源池103的资源导入接口1031向资源池103发送虚拟机新资源的元数据。资源池103成功接收虚拟机新资源元数据后，向告警子系统102发送资源确收信息。
112.其中，虚拟机资源或虚拟机新资源的元数据参考上述图3中有关描述，在此不再赘述。资源池103通过资源导入接口1031和资源调用接口供系统110中的其他结构调用，能够提高调用效率、节省网络资源。
113.例如，如图5所示，正常情况下该租户test可以响应500个app的接入请求，当该租户test响应了第450个app的接入请求时，该租户test相应的资源使用量即判断为已达到资源总容量的90％(即容量阈值)，这时综合管理子系统101向告警子系统102发送告警信息，同时综合管理子系统101内部自动触发新建租户流程，准备创建新租户。综合管理子系统101自动生成新租户的系统名称test-new，以及新租户的id，例如，新租户的id为p6，并将新租户的系统名称和id记录在综合管理子系统101的租户管理模块1011内。由于此时新租户test-new的服务部件集群未创建，因此新租户test-new的服务部件集群的识别信息显示为空白，如图5所示。
114.新租户test-new需要的虚拟机资源配置参照租户test的虚拟机资源配置。告警子系统102可以基于租户test配置的虚拟机资源计算新租户test-new需要的虚拟机数量及虚拟机上的cpu、内存等配置要求。作为示例，例如，新租户test-new需要4台虚拟机，每台虚拟机的基础配置是16个cpu，32gb内存，500gb硬盘空间等。告警子系统102计算下来可能还需要调用资源申请api申请2台符合上述基础配置要求的虚拟机，则外部虚拟机资源库会响应资源申请api上的调用返回2台符合上述基础配置要求的虚拟机的ip地址、主机名、cpu、内
存、标签等元数据发送给告警子系统102，告警子系统102收到这2台虚拟机的元数据后调用资源池103的资源导入接口1031，将这2台虚拟机的元数据发送给资源池103登记保存。
115.s4：系统110中的告警子系统102发送虚拟机新资源的元数据给综合管理子系统101。具体地，告警子系统102收到资源池103发来的资源确收信息后，将虚拟机新资源的元数据发送给综合管理子系统101的资源元数据管理模块1013保存，以供后续各服务部件执行任务时调用查询。
116.可以理解，综合管理子系统101收到虚拟机新资源的元数据时表明为新租户部署服务部件的虚拟机资源已就位，继续进行下述步骤s5。上述告警子系统102收到资源池103发来的资源确收信息后，通过将虚拟机新资源的元数据发送给综合管理子系统101，以确认虚拟机资源已就位这一信息的过程，能够保障系统110内信息流的准确性，从而确保了系统110内各系统或模块结构响应准确的信息而精准触发下一步的自动化流程，使得系统110能够按照既定的工作流够稳定有序的进行。
117.可以理解，如果资源池103内相关用户的空置虚拟机资源的数量及配置信息能够满足该用户创建的新租户需求，则告警子系统102直接向综合管理子系统101发送资源充足的反馈信息，而不需要再调用资源申请api申请虚拟机新资源。
118.s5：系统110内的综合管理子系统101收到虚拟机新资源的元数据时自动调用自动部署工具104为新租户部署所需的服务部件。
119.具体地，自动部署工具104通过自动拉取脚本1041获取与新租户部署的服务部件相对应的服务软件包。自动部署工具104通过自动组建集群模块1042解析获得的服务软件包，并调用资源池103的资源调用接口1033从资源池103获取符合配置要求的虚拟机资源，自动组建集群模块1042进一步根据服务软件包中描述的集群拓扑结构要求在虚拟机上创建集群拓扑结构。自动部署工具104通过自动安装流程控制模块1043控制服务软件包中的自动化安装脚本运行以安装软件，软件安装成功后自动安装流程控制模块1043再通过控制自动化启动脚本运行来启动软件，软件启动运行后服务部件即部署完成。自动部署工具104具体部署服务部件的过程参考上述图3及相关描述，在此不再赘述。
120.可以理解，如果资源池103内相关用户的空置虚拟机资源的数量及配置信息能够满足该用户创建的新租户需求，则综合管理子系统101也可以在收到告警子系统102发来的资源充足反馈信息后，调用自动调用部署工具104为新租户部署所需的服务部件。
121.可以理解，新租户需要多个服务部件以响应不同的用户服务请求，例如，有的服务部件提供的是任务调度服务，用于响应用户的调度请求，比如调度一个任务用于计算近半年某地的天气数据。有的服务部件提供的是监听进程服务，用于响应用户的监听进程请求，例如用户请求展示某购物app上的客户活跃数据来观察该购物app上客户当前时刻的活跃度。
122.可以理解，由于部署每个服务部件需要的资源大小不同，为了达到资源利用率的最大化，在各服务部件之间不存资源冲突的情况下，可以通过资源合设的方式在同一虚拟机上部署多个服务部件，例如，可以在两台虚拟机上部署三个服务部件，或在四台虚拟机上部署3个服务部件，也可以在3台虚拟机上部署5个服务部件，在此不做限制。
123.服务部件部署成功后，自动部署工具104向综合管理子系统101发送服务部件部署成功的通知信息和这些服务部件的访问地址(url地址)等。在另一些实施例中，自动部署工
具104也可以发送已部署服务部件的其他识别调用信息给综合管理子系统101，在此不做限制。
124.例如，上述新租户test-new需要3个服务部件a、b、c，则自动部署工具104会分别获取这3个服务部件对应的服务软件包，自动部署工具104获取服务软件包的方式可以是逐个获取，也可以是一次性完成3个服务软件包的获取，在此不做限制。每个服务软件包中都有相应服务部件的filter，用于过滤虚拟机资源以得到符合相应服务部件需求的虚拟机资源。例如，服务部件a的指定要使用5个cpu，服务部件b指定的标签是service＝b，服务部件c指定要使用6个cpu和32g内存，并且服务部件a-c之间存在依赖关系，例如依赖关系是：服务部件c依赖于服务部件b，服务部件b依赖于服务部件a。自动部署工具104就会通过服务部件a的filter先选择满足5个cpu的虚拟机创建服务部件a的集群及集群拓扑结构，进行服务部件a的软件安装；服务部件a的软件安装完成后，再通过服务部件b的filter选择满足service＝b的虚拟机，创建服务部件b的集群及集群拓扑结构，进行服务部件b的软件安装；服务部件b的软件安装完成后，再通过服务部件c的filter选择满足6个cpu和32g内存的虚拟机，创建服务部件c的集群及集群拓扑结构，进行服务部件c的软件安装。服务部件a-c的软件全部安装完成后，先启动服务部件a的软件，再依次启动服务部件b和服务部件c的软件，完成服务部件a-c的部署。
125.服务部件a-c部署成功后，自动部署工具104将服务部件a-c的url地址发送给综合管理子系统101。
126.s6：系统110的综合管理子系统101接收自动部署工具104发来的已部署服务部件的url地址后，发送新租户的识别信息给已部署服务部件。
127.综合管理子系统101根据服务部件的url地址访问该服务部件，向其发送新租户的识别信息，激活该服务部件。新租户的识别信息包括新租户的系统名称、id信息等，还可以包括一些附加信息，在此不做限制。服务部件接收新租户的识别信息后，完成激活并为新租户响应用户的服务请求做准备，之后新租户通过服务部件响应用户的服务请求。
128.例如，综合管理子系统101将新租户test-new的系统名称test-new、id信息p6等分别发送给上述部署完成的服务部件a-c。
129.s7：系统110的综合管理子系统101自动发送需要各服务部件分别执行的任务信息给各服务部件。向服务部件发送任务信息包括以下两种情形：
130.(1)各服务部件之间存在依赖关系的情况下，综合管理子系统101中的租户管理模块1011上会构建描述该依赖关系的树状依赖关系，并按照该树状依赖关系先向位于根部的服务部件发送依赖任务信息，让该服务部件先执行该依赖任务；该依赖任务成功执行后，再依次向根部以上的服务部件串行发送依赖于上述依赖任务的任务信息并执行。这种情况下，串行下发任务及执行任务的方式可以保证服务部件执行任务的准确性。
131.(2)各服务部件之间不存在依赖关系的情况下，综合管理子系统101会将任务信息并行发送给各服务部件，各服务部件收到任务信息后并行执行任务。这种情况下，并行下发任务及执行任务的方式可以提高服务部件执行任务的效率。
132.例如，上述服务部件a-c之间的依赖关系为服务部件c依赖于服务部件b，服务部件b依赖于服务部件a，则综合管理子系统101中构建的树状依赖关系中服务部件a位于根部，因此，综合管理子系统101先发送服务部件a的任务信息给服务部件a执行；服务部件a执行
任务成功后，综合管理子系统101再发送服务部件b的任务信息给服务部件b执行；服务部件b执行任务成功后，综合管理子系统101再发送服务部件c的任务信息给服务部件c执行。
133.s8：系统110的综合管理子系统101调用公有云300服务接口为新租户申请创建云服务实例。公有云300响应上述云服务接口的调用，将创建完成的云服务实例的访问地址给综合管理子系统101中的新租户。
134.公有云300创建的上述云服务实例与步骤s7中执行相应任务信息后的各服务部件共同作为用户服务请求的响应部件。
135.可以理解，服务部件完成激活时说明新租户的服务部件已经准备就绪，此时再申请云服务实例能够有效避免新租户创建失败时申请了云服务实例的情况，由于申请云服务实例需要支付费用，因此也就避免了相应的费用损失。其中，新建租户流程中任意环节失败都可能导致新租户申请失败，例如，服务部件安装后不能启动运行而导致最终新租户的服务部件部署失败的情况。服务部件完成激活后申请云服务实例的过程中需要支付的费用可以通过与用户事先签订的预授权协议从用户的账户中划扣，也可以通过其他支付实现方式，在此不再赘述。
136.例如，新租户test-new需要使用公有云300的mapreduce服务，那么就需要在公有云300上创建该服务相应的云服务实例。创建完成后公有云300向系统110中的综合管理子系统101反馈云服务实例的id或访问地址等信息，供新租户test-new需要进行mapreduce任务提交的时候调用。
137.s9：新租户的各项资源就绪，系统110自动启用新租户响应新的app接入请求。
138.新租户的各项资源就绪包括但不限于上述服务部件和云服务实例运行就绪，这时，上述步骤s1中的现有租户停止响应新的app接入请求，系统110自动启用新租户响应新的app接入请求。这时现有租户可能已接入499个app，则该租户继续接收已接入的499个app推送过来的数据存储到用户指定的位置；如果现有租户可能已接入501个app，则该租户继续接收已接入的501个app推送过来的数据存储到用户指定的位置。新的app接入请求自动由新租户响应。
139.可以理解，以上步骤s1-s9不构成对本技术的大数据平台租户管理方法流程的具体限定，在另一些实施例中，上述步骤s1-s9可以描述为更少或者更多的步骤，在此不做限制。如图3所示，上述步骤s1-s9可以图3所示的大数据平台租户管理系统的基础上，图3中示出了上述步骤s1-s9中的部分内容以便于理解本技术的技术方案，图3所示的步骤s1-s9参考上述图4及相关各步骤的详细描述，在此不再赘述。
140.可以理解，上述大数据平台租户管理系统110可以在运行在多台计算机组建的服务器集群上，系统110中的综合管理子系统101、告警子系统102、资源池103、自动部署工具104以及软件仓105等结构，可以分别运行在不同的服务器集群上，或者其中任意两个或三个结构运行在相同的服务器集群上，在此不做限制。
141.图6示出了本技术实施例的一种计算机的系统框图。在一个实施例中，系统600可以包括一个或多个处理器604，与处理器604中的至少一个连接的系统控制逻辑608，与系统控制逻辑608连接的系统内存612，与系统控制逻辑608连接的非易失性存储器(non-volatile memory，nvm)616，以及与系统控制逻辑608连接的网络接口620。
142.在一些实施例中，处理器604可以包括一个或多个单核或多核处理器。在一些实施
例中，处理器604可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在系统600采用增强型基站(evolved node b，enb)或ran(radio access network，无线接入网)控制器的实施例中，处理器604可以被配置为执行各种符合的实施例，例如，如图2-5所示的实施例。
143.在一些实施例中，系统控制逻辑608可以包括任意合适的接口控制器，以向处理器604中的至少一个与系统控制逻辑608通信的任意合适的设备或组件提供任意合适的接口。
144.在一些实施例中，系统控制逻辑608可以包括一个或多个存储器控制器，以提供连接到系统内存612的接口。系统内存612可以用于加载以及存储数据和/或指令。在一些实施例中系统600的内存612可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(dynamic random access memory，dram)。
145.nvm/存储器616可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，nvm/存储器616可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如hdd(hard disk drive，硬盘驱动器)，cd(compact disc，光盘)驱动器，dvd(digital versatile disc，数字通用光盘)驱动器中的至少一个。
146.nvm616可以包括安装系统600的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口620通过网络访问nvm616。
147.特别地，系统内存612和nvm616可以分别包括：指令624的暂时副本和永久副本。指令624可以包括：由处理器604中的至少一个执行时导致系统600实施如图3-4所示的方法的指令。在一些实施例中，指令624、硬件、固件和/或其软件组件可另外地/替代地置于系统控制逻辑608，网络接口620和/或处理器604中。
148.网络接口620可以包括收发器，用于为系统600提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口620可以集成于系统600的其他组件。例如，网络接口620可以集成于处理器604的，系统内存612，nvm616，和具有指令的固件设备(未示出)中的至少一种，当处理器604中的至少一个执行所述指令时，系统600实现如图2-5所示的方法。
149.网络接口620可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口620可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。
150.在一个实施例中，处理器604中的至少一个可以与用于系统控制逻辑608的一个或多个控制器的逻辑封装在一起，以形成系统封装(system in package，sip)。在一个实施例中，处理器604中的至少一个可以与用于系统控制逻辑608的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(system-on-chip，soc)。
151.系统600可以进一步包括：输入/输出(i/o)设备632。i/o设备632可以包括用户界面，使得用户能够与系统600进行交互；外围组件接口的设计使得外围组件也能够与系统600交互。在一些实施例中，系统600还包括传感器，用于确定与系统600相关的环境条件和位置信息的至少一种。
152.在一些实施例中，用户界面可包括但不限于显示器(例如，液晶显示器，触摸屏显示器等)和键盘。
153.在一些实施例中，外围组件接口可以包括但不限于非易失性存储器端口、音频插孔和电源接口。
154.在一些实施例中，传感器可包括但不限于陀螺仪传感器，加速度计，近程传感器，环境光线传感器和定位单元。定位单元还可以是网络接口620的一部分或与网络接口620交互，以与定位网络的组件(例如，全球定位系统(global positioning system，gps)卫星)进行通信。
155.在说明书对“一个实施例”或“实施例”的引用意指结合实施例所描述的具体特征、结构或特性被包括在根据本技术公开的至少一个范例实施方案或技术中。说明书中的各个地方的短语“在一个实施例中”的出现不一定全部指代同一个实施例。
156.本技术公开的技术方案还涉及用于执行文本中的操作装置。该装置可以专门处于所要求的目的而构造或者其可以包括被存储在计算机中的计算机程序选择性地激活或者重新配置的通用计算机。这样的计算机程序可以被存储在计算机可读介质中，诸如，但不限于任何类型的盘，包括软盘、光盘、cd-rom、磁光盘、只读存储器(rom)、随机存取存储器(ram)、eprom、eeprom、磁或光卡、专用集成电路(asic)或者适于存储电子指令的任何类型的介质，并且每个可以被耦合到计算机系统总线。
157.本文所提出的系统、流程步骤和虚拟机等不涉及任何具体计算机或其他装置。各种通用系统也可以与根据本文中的教导的程序一起使用，或者构造更多专用系统以执行一个或多个方法步骤可以证明是方便的。在以下描述中讨论了用于各种这些系统的结构。另外，可以使用足以实现本技术公开的技术和实施方案的任何具体编程语言。各种编程语言可以被用于实施本公开，如本文所讨论的。
158.另外，在本说明书所使用的语言已经主要被选择用于可读性和指导性的目的并且可能未被选择为描绘或限制所公开的主题。因此，本技术公开旨在说明而非限制本文所讨论的概念的范围。