基于预计算OLAP模型的多租户服务方法及装置与流程

本申请涉及计算机、数据分析领域，具体而言，涉及一种基于预计算olap模型的多租户服务方法及装置。

背景技术：

通过搭建预计算olap系统的多维分析平台，可以让多个用户在同一个平台上进行建模开发，从而加速多维分析。

发明人发现，在现有预计算olap模型的多租户部署方案中，需要配置每个租户对应的服务实例，一旦租户很多，就需要启动对应个数的服务实例，需要占用的资源很多，从而造成资源浪费。进一步，每次在部署租户时需要初始化和配置实例，增加了工作负担。

针对相关技术中资源利用率较为低下的问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请的主要目的在于提供一种基于预计算olap模型的多租户服务方法及装置，以解决资源利用率较为低下的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种基于预计算olap模型的多租户服务方法，根据包括至少一个服务实例的资源组，对多个租户提供服务。

根据本申请的基于预计算olap模型的多租户服务方法，包括：将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，以使租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。

进一步地，所述预计算olap模型包括：建模系统、预计算系统和查询系统，所述建模系统，用于进行模型开发和数据立方体设计；所述预计算系统，用于根据所述模型对数据仓库中的数据进行预聚合并保存预计算数据立方体结果；所述查询系统，用于对预计算数据立方体结果进行查询。

进一步地，租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限包括：第一租户在执行获取有权限的数据的操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。

进一步地，租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限包括：第二租户在执行构建操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。

进一步地，租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限包括：第三租户在执行查询操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。

进一步地，所述预计算olap模型中的每个子系统中按照不同角色配置不同的资源组，每个所述资源组中部署至少一个服务实例，所述资源组被配置为开发模式、构建模式或者查询模式的角色模式。

进一步地，将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定之后还包括：根据预设租户优先级路由到对应的所述资源组中，并按照不同优先级请求返回实例服务结果，以使所述资源组中的服务实例可以支持不同预设租户优先级的租户进行使用。

进一步地，将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定之后还包括：根据不同服务请求路由到对应的所述资源组中，并按照不同服务请求返回实例服务结果，以使所述资源组中的服务实例可以支持不同服务请求的租户进行使用。

进一步地，将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定之后还包括：根据单个资源组与多个租户的映射关系路由到对应的所述资源组中，并按照单个资源组与多个租户的映射关系返回实例服务结果，以使所述资源组中的服务实例可以支持单个资源组与多个租户的映射关系的租户进行使用。

为了实现上述目的，根据本申请的另一方面，提供了一种基于预计算olap模型的多租户服务装置，根据包括至少一个服务实例的资源组，对多个租户提供服务。

根据本申请的基于预计算olap模型的多租户服务装置包括：资源组服务模块，用于将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，以使租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。

在本申请实施例中基于预计算olap模型的多租户服务方法及装置，采用根据包括至少一个服务实例的资源组，对多个租户提供服务的方式，通过将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，达到了使租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限的目的，从而实现了确保数据隔离，且服务实例的个数不会随着租户的增加而增加的技术效果，进而解决了资源利用率较为低下的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据相关技术的多租户集群拓扑示意图；

图2是根据相关技术的服务实例和集群的交互示意图；

图3是根据本申请实施例的服务实例与hadoop用户解绑示意图；

图4是根据本申请实施例的基于预计算olap系统的多租户集群拓扑示意图；

图5是根据本申请实施例的配置资源组中的角色模式示意图；

图6是根据本申请实施例的预计算olap系统解耦示意图；

图7是根据本申请实施例的查询资源组支持不同优先级的使用场景示意图；

图8是根据本申请实施例的基于预计算olap模型的多租户服务装置结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

如图3所示，本申请中的基于预计算olap模型的多租户服务方法，根据包括至少一个服务实例的资源组，对多个租户提供服务，将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，以使租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。在确保数据隔离的同时，服务实例的个数不会随着租户的增加而增加。

具体地，为了提高资源利用率，单个服务实例可以支持不同租户的使用。在管理租户时，会绑定对应hadoop集群的用户，而服务实例在运行时绑定的是hadoop超级用户。

在租户每次去执行开发、构建或者查询时，服务实例都会只能访问该用户所对应hadoop用户的数据权限从而确保数据隔离，且服务实例的个数不会随着租户的增加而增加。

对于现有的多租户服务方法中，如图2所示，每个olap的服务实例在部署时需要配置该实例所服务的租户，同时需要配置hadoop集群的kerberos用户，在启动初始化后，该服务实例所执行的操作，包括获取有权限的数据，执行cube构建和cube查询操作，都会使用该kerberos用户。同时，由于每个租户的实例所使用的hadoop用户都不相同，而每个kerberos用户所具有的权限都不相同，这样则实现了租户之间的数据隔离。

如图3所示，本申请实施例中的方法，通过将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，可以使得每个子系统以资源组形式服务多租户场景，并且每个资源组可独立升缩、线性扩容，提高了整个集群的资源利用率。同时，在使用时控制租户能使用到的数据资源，完成隔离数据，在构建时设置资源队列，控制资源隔离。

从以上的描述中，可以看出，本申请实现了如下技术效果：

在本申请实施例中基于预计算olap模型的多租户服务方法及装置，采用根据包括至少一个服务实例的资源组，对多个租户提供服务的方式，通过将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，达到了使租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限的目的，从而实现了确保数据隔离，且服务实例的个数不会随着租户的增加而增加的技术效果，进而解决了资源利用率较为低下的技术问题。

根据本申请实施例，作为本实施例中的优选，如图4所示，所述预计算olap模型包括：建模系统、预计算系统和查询系统，所述建模系统，用于进行模型开发和数据立方体设计；所述预计算系统，用于根据所述模型对数据仓库中的数据进行预聚合并保存预计算数据立方体结果；所述查询系统，用于对预计算数据立方体结果进行查询。

具体地，在本申请的实施例中提供了解耦的预计算olap系统，子系统包括至少三个，其具体为：建模系统100、预计算系统200、查询系统300，在所述建模子系统、预计算子系统、查询子系统间相互并不不共享任何数据和元数据，只通过文件交换的形式沟通。从而达到在超大型企业中跨网络部署的目的，即子系统间可以网络隔离，只保留文件上传下载通道，最大化安全隔离性和部署灵活性。

作为本实施例中的优选，所述子系统包括：建模系统100、预计算系统200和查询系统300，所述建模系统100，用于进行模型开发和数据立方体设计；所述预计算系统200，用于根据所述模型对数据仓库中的数据进行预聚合并保存预计算数据立方体结果；所述查询系统300，用于对预计算数据立方体结果进行查询。优选地，三个所述子系统之间通过解耦隔离时，不共享每个所述子系统中的数据和元数据。

根据本申请实施例，作为本实施例中的优选，如图3所示，租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限包括：第一租户在执行获取有权限的数据的操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。由于将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，在第一租户执行相关获取有权限的数据的操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。

需要注意的是，所述有权限的数据按照租户的预设优先级确定，在本申请的实施例中并不进行限定。

根据本申请实施例，作为本实施例中的优选，如图3所示，租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限包括：第二租户在执行构建操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。由于将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，在第一租户执行构建操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。所述构建操作是指通过所述建模系统，进行模型开发和数据立方体设计。

需要注意的是，所述构建操作按照租户的分析需求确定，在本申请的实施例中并不进行限定。

根据本申请实施例，作为本实施例中的优选，如图3所示，租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限包括：第三租户在执行查询操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。由于将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，在第一租户执行查询操作所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限。所述查询操作是指通过所述查询系统，对预计算数据立方体结果进行查询。

需要注意的是，所述查询操作按照租户的使用场景确定，在本申请的实施例中并不进行限定。

根据本申请实施例，作为本实施例中的优选，如图5所示，所述预计算olap模型中的每个子系统中按照不同角色配置不同的资源组，每个所述资源组中部署至少一个服务实例，所述资源组被配置为开发模式、构建模式或者查询模式的角色模式。

具体地，通过重构资源组，并且以资源组形式服务多个租户，以资源组形式服务多个租户，从而在所述服务实例的部署方式与所述租户的个数不会有相关联性。区别于，现有基于预计算olap系统的多租户架构，如图1所示，服务实例和租户是完全绑定的形式。如果在租户增多的情况下，服务实例需要部署非常多的实例。所以为了提高资源利用率，在本申请实施例中每个所述子系统中按照不同角色配置不同的所述资源组，从而资源组中包括至少的一个服务实例可以支持不同租户的使用。

根据本申请实施例，作为本实施例中的优选，如图3所示，将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定之后还包括：根据预设租户优先级路由到对应的所述资源组中，并按照不同优先级请求返回实例服务结果，以使所述资源组中的服务实例可以支持不同预设租户优先级的租户进行使用。

具体地，如图7所示，本申请实施例中的预计算olap系统作为一个能支持多租户使用的多维分析平台，在租户之间的在查询时一般会有优先级的区分，对于每个查询的资源组，允许按照需求配置所述服务实例的个数。负载均衡模块会根据查询用户所设定的优先级自动路由到不同的查询资源组中，满足不同优先级的查询请求。

需要注意的是，由于允许按照需求配置所述服务实例的个数，且在资源组中包括至少一个实例服务，故，所述资源组中的服务实例可以支持不同预设租户优先级的租户进行使用。在本申请中并不对于具体的实例服务数量或者类型进行，只要能够满足预设优先级查询请求的条件即可。

根据本申请实施例，作为本实施例中的优选，如图3所示，将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定之后还包括：根据不同服务请求路由到对应的所述资源组中，并按照不同服务请求返回实例服务结果，以使所述资源组中的服务实例可以支持不同服务请求的租户进行使用。

具体地，如图7所示，本申请实施例中的预计算olap系统作为一个能支持多租户使用的多维分析平台，在租户之间的在查询时一般会不同服务请求，对于每个查询的资源组，允许按照需求配置所述服务实例的个数。负载均衡模块会根据不同服务请求自动路由到不同的查询资源组中，满足不同优先级的查询请求。所述不同服务请求可以根据实景场景或需求进行确定。

需要注意的是，由于允许按照需求配置所述服务实例的个数，且在资源组中包括至少一个实例服务，故，所述资源组中的服务实例可以支持不同服务请求的租户进行使用。在本申请中并不对于具体的实例服务数量或者类型进行限定，只要能够满足不同服务请求的条件即可。

根据本申请实施例，作为本实施例中的优选，如图3所示，将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定之后还包括：根据单个资源组与多个租户的映射关系路由到对应的所述资源组中，并按照单个资源组与多个租户的映射关系返回实例服务结果，以使所述资源组中的服务实例可以支持单个资源组与多个租户的映射关系的租户进行使用。

具体地，如图7所示，本申请实施例中的预计算olap系统作为一个能支持多租户使用的多维分析平台，在租户之间的在查询时一般会存在单个资源组与多个租户的映射关系，对于每个查询的资源组，允许按照需求配置所述服务实例的个数。负载均衡模块会根据单个资源组与多个租户的映射关系自动路由到不同的查询资源组中，满足不同优先级的查询请求。所述单个资源组与多个租户的映射关系通产可以是指，单个资源组与多个租户之间的映射关系。

需要注意的是，由于允许按照需求配置所述服务实例的个数，且在资源组中包括至少一个实例服务，故，所述资源组中的服务实例可以支持单个资源组与多个租户的映射关系的租户进行使用。在本申请中并不对于具体的实例服务数量或者类型进行，只要能够满足单个资源组与多个租户的映射关系的条件即可。

在上述操作中，通过设置所述资源组的优先级和/或查询场景，以使预计算olap系统在部署、开发和查询时更加灵活高效。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本申请实施例，还提供了一种用于实施上述基于预计算olap模型的多租户服务方法的装置1，根据包括至少一个服务实例的资源组，对多个租户提供服务，如图8所示，该装置1包括：资源组服务模块11，用于将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，以使租户在执行预设操作时所述服务实例只能访问该租户所对应的所述hadoop集群用户中的数据权限

本申请实施例的资源组服务模块100中具体地，为了提高资源利用率，单个服务实例可以支持不同租户的使用。在管理租户时，会绑定对应hadoop集群的用户，而服务实例在运行时绑定的是hadoop超级用户。

在租户每次去执行开发、构建或者查询时，服务实例都会只能访问该用户所对应hadoop用户的数据权限从而确保数据隔离，且服务实例的个数不会随着租户的增加而增加。

本申请实施例中的方法，通过将租户与对应的hadoop集群用户绑定，并且在服务实例运行时与hadoop集群超级用户绑定，可以使得每个子系统以资源组形式服务多租户场景，并且每个资源组可独立升缩、线性扩容，提高了整个集群的资源利用率。同时，在使用时控制租户能使用到的数据资源，完成隔离数据，在构建时设置资源队列，控制资源隔离。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

本申请的实现原理：

以下通过结合附图1-7对本申请的实现原理进行详细说明。

如图1所示，传统的多租户技术，都是针对不同用户部署不同的工具服务实例，让不同服务实例，单独服务于不同用户。这样每个用户在运行自己的构建或查询任务，都有自己单独的服务实例进行支撑，且配置不同的hadoopkerberos用户，这样用户在进行模型开发时只使用了自己的认证文件，只能访问自己的数据。这样使得不同用户间的权限和数据隔离变的可能。而当启用不同服务实例服务不同用户，虽然能完全实现多租户，达到数据隔离，当用户多的情况，olap预计算工具服务实例就需要部署很多，这样需要很多的计算资源，且每个用户的使用频次和对资源的要求不一致，使得部分服务实例得不到充分的使用，导致了极大的资源浪费。同时预计算olap系统中的建模、构建、查询工具都耦合在一起，不能根据实际环境隔离部署，在开发使用时不够灵活。

具体地，以金融行业的it报表开发模式为例，其数仓开发团队需要服务于不同的业务部门，所以数仓团队也有不同的it部门，每个部门都需要共同使用预计算olap平台的资源，但需要实现每个部门的数据和权限的隔离。多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性，这个称之为多租户。传统的多租户环境每个租户需要配备固定的serviceinstance(服务实例)，各自使用对应权限的hadoop集群的kerberos用户。当cube构建作业或查询任务发起时，loadbalance服务会自动转发请求到对应的租户的服务实例中运行并返回结果。

如图2所示，每个预计算olap系统的服务实例，在部署时需要配置该实例所服务的租户，同时需要配置hadoop集群的kerberos用户，在启动初始化后，该服务实例所执行的操作，包括获取有权限的数据，执行cube构建和cube查询操作，都会使用该kerberos用户。由图2中可以看出，由于每个租户的实例所使用的hadoop用户都不相同，而每个kerberos用户所具有的权限都不相同，这样则实现了租户之间的数据隔离。

针对上述缺陷分析可知，在传统的基于预计算olap系统中的多租户部署方案中，需要配置每个租户对应的服务实例，如果租户很多，则需要启动对应个数的服务实例，需要占用的资源很多。此外，租户在实际使用时，有的租户构建和查询的任务相对较少，启动的服务实例占用了集群的资源，但几乎不被使用，导致了极大的浪费，部署租户时需要初始化和配置实例。

另外，由于在现有的预计算olap系统中的建模、构建、查询工具都耦合在一起，不能根据实际环境隔离部署，在开发使用时不够灵活。

如图3所示，本申请在已有的预计算olap系统的多租户架构的基础上，采用解耦预计算olap系统中的三大子系统，包括建模系统、预计算系统、查询系统。子系统间不共享任何数据和元数据，只通过文件交换的形式沟通。达到在超大型企业中跨网络部署的目的，即子系统间可以网络隔离，只保留文件上传下载通道，最大化安全隔离性和部署灵活性。从而达到在超大型企业中跨网络部署的目的，即子系统间可以网络隔离，只保留文件上传下载通道，最大化安全隔离性和部署灵活性。

如图3所示是基于预计算olap系统的多租户架构方案，可以有效解决现有技术方案的缺陷，用固定的资源组配置方案，服务于更多的租户使用，在解耦架构的同时提高集群的资源的利用率。

由于在传统的多租户架构中，服务实例和租户是完全绑定的形式，这样租户多的情况下，服务实例需要部署非常多的实例。所以为了提高资源利用率，单个服务实例可以支持不同租户的使用。如图4所示，是基于预计算olap系统以资源组形式服务多个租户的应用场景，具体地，租户在管理时，会绑定对应hadoop集群的用户，通过在所述服务实例在运行时绑定的是hadoop超级用户，租户每次去执行开发、构建或查询时，服务实例都会只能访问该用户所对应hadoop用户的数据权限，这样确保数据隔离。且所述服务实例的个数不会随着租户的增加而增加。查询系统的资源组能支持不同优先级的查询。在使用时控制租户能使用到的数据资源，完成隔离数据，在构建时设置资源队列，控制资源隔离。

如图5所示，每个资源组可以部署一个或多个实例，同时可以配置该资源组的的角色模式，所述资源组就会以定义好的角色模型运行。采用资源组形式服务多个租户，服务实例的部署方式与租户的个数可以没有必然关系。如图5所示，角色模型可以包括，开发模式、构建模式或者查询模式等。每个所述建模子系统、预计算子系统、查询系统子系统以资源组形式服务多租户场景，每个资源组可独立升缩、线性扩容，提高了整个集群的资源利用率。

如图6所示，建模系统100进行模型开发，同时采用独立restapi接口支持把开发好的模型导出。预计算系统200进行cube数据立方体构建，也有独立的接口完成数据同步，查询系统300完成cube数据立方体查询，能完成组件解耦。建模系统、预计算系统、查询系统三个子系统完全解耦，可以跨网络部署，子系统间不共享任何数据和元数据，只通过文件交换的形式沟通。

所述建模系统100，支持多租户在统一的建模系统中，进行模型开发和cube设计，以结构化文件形式存储，同时支持接口导入导出元数据文件，供其他系统使用。所述预计算系统200，根据设计的模型，对数据仓库中的数据按不同的维度组合进行预聚合并保存聚合结果。所述预计算的cube结果，支持接口形式导出到其他子系统。查询系统300，提供对预计算cube结果的高效查询服务。在子系统解耦隔离后，可以实现部署达到在超大型企业中跨网络部署的目的，子系统间支持网络隔离，只保留文件上传下载通道，最大化安全隔离性和部署灵活性。

如图7所示，所述基于预计算olap系统作为一个能支持多租户使用的多维分析平台，在多租户之间的在查询时一般会有优先级的区分，同时每个查询的资源组，允许按照需求配置实例的个数。负载均衡模块可以根据查询用户所设定的优先级自动路由到不同的查询资源组中，满足不同优先级的查询请求。

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