CN109992417B - 预计算olap系统及实现方法 - Google Patents

Abstract

本申请公开了一种预计算OLAP系统及实现方法。该预计算OLAP系统包括：至少三个子系统，三个所述子系统之间通过解耦隔离部署，且在三个所述子系统中通过文件通道进行通信。本申请解决了资源率用率较低的技术问题。本申请中的预计算OLAP系统通过解耦隔离部署，可以解决组件耦合带来的灵活性问题，在多租户场景下极大的提高了资源利用率，使本申请能应对更加复杂的使用场景。此外，本申请适用于多租户架构，可以让多个用户在共同的环境下共用相同的OLAP预计算工具，且同时确保各用户间数据的隔离性。

Description

预计算OLAP系统及实现方法

技术领域

本申请涉及计算机、数据分析领域，具体而言，涉及一种预计算OLAP系统及实现方法。

背景技术

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

发明人发现，在有多租户时，启动多个服务实例会占用资源。同时，租户实际使用和启动的服务实例不成比例，还造成了资源浪费。进一步，预计算OLAP系统中的子系统之间相互耦合，从而在开发使用时灵活性较差。

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

发明内容

本申请的主要目的在于提供一种预计算OLAP系统及实现方法，以解决资源率用率较低的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种预计算OLAP系统。

根据本申请的预计算OLAP系统包括：至少三个子系统，三个所述子系统之间通过解耦隔离部署，且在三个所述子系统中通过文件通道进行通信。

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

进一步地，所述建模系统中包括第一数据接口，用于进行数据文件的导入或导出，所述预计算系统中包括第二数据接口，用于进行所述预计算数据立方体结果的导出。

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

进一步地，根据预设用户优先级在所述查询系统中执行不同优先级的查询请求。

进一步地，三个所述子系统之间通过解耦隔离时，不共享每个所述子系统中的数据和元数据。

进一步地，所述子系统之间还包括调用构建接口的交互方式。

进一步地，所述子系统之间还包块模型元数据导入的交互方式。

进一步地，所述子系统之间还包括数据同步的交互方式。

为了实现上述目的，根据本申请的另一方面，提供了一种预计算OLAP系统实现方法。

根据本申请的预计算OLAP系统实现方法包括：根据至少包括一个服务实例的资源组，将建模系统、构建系统和查询系统进行解耦部署；在所述建模系统中用于进行模型开发；在所述构建系统用于进行数据立方体构建；在所述查询系统中用于进行预设优先级查询；其中，在所述子系统之间网络隔离，且在所述子系统中通过文件通道进行通信。

在本申请实施例中预计算OLAP系统及实现方法，采用新型的预计算OLAP系统的方式，通过分离出三个子系统，三个所述子系统之间通过解耦隔离部署，且在三个所述子系统中通过文件通道进行通信，达到了在超大型企业中跨网络部署的目的，从而实现了子系统间可以网络隔离，同时保留文件上传下载通道，最大化安全隔离性和部署灵活性的技术效果，进而解决了资源率用率较低的技术问题。

附图说明

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

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

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

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

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

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

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

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

图8是根据本申请实施例的预计算OLAP系统的实现方法流程示意图。

具体实施方式

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

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

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

实施例一

本申请中的预计算OLAP系统，在现有的OLAP系统多租户架构的基础上，解耦预计算OLAP系统中的三大子系统，分别包括：建模系统、预计算系统、查询系统。而且在每个子系统间不共享任何数据和元数据，只通过文件交换的形式沟通。

如图3所示，本申请实施例中的预计算OLAP系统，至少包括：三个子系统，三个所述子系统之间通过解耦隔离部署，且在三个所述子系统中通过文件通道进行通信。对于现有的如图1所示的预计算OLAP系统，在本申请实施例中采用解耦的方式将现有模型中的所述子系统进行解耦隔离部署，并且在子系统之间实现网络隔离，仅通过文件通道进行上传下载文件传输。

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

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

在本申请实施例中通过三个所述子系统，在所述子系统隔离部署达到在超大型企业中跨网络部署的目的，子系统间支持网络隔离，只保留文件上传下载通道，最大化安全隔离性和部署灵活性。

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

具体地，所述建模系统100、预计算系统200、查询系统300三个子系统完全解耦，可以跨网络部署，子系统间不共享任何数据和元数据，只通过文件交换的形式沟通。

优选地，在所述建模系统100中包括第一数据接口，用于进行数据文件的导入或导出，在所述预计算系统200中包括第二数据接口，用于进行所述预计算数据立方体结果的导出。

所述第一数据接口用于进行数据文件的导入或导出。需要注意的是，在本申请中并不进行限定，只要能够满足导入或导出需求即可。

所述第二数据接口用于进行所述预计算数据立方体结果的导出。需要注意的是，在本申请中并不进行限定，只要能够满足结果导出需求即可。

具体地，所述建模系统100中可以支持多租户在统一的建模系统中，进行模型开发和cube数据立方体设计，以结构化文件形式存储，同时支持接口导入导出元数据文件，供其他系统使用。所述预计算系统200中可以根据设计的模型，对数据仓库中的数据按不同的维度组合进行预聚合并保存聚合结果。预计算的Cube结果，支持接口形式导出到其他子系统。所述查询系统300中可以提供对预计算数据立方体Cube结果的高效查询服务。所述查询系统300可以根据优先级划分为不同查询子系统。

如图6所示，所述子系统之间还包括调用构建接口的交互方式。具体地，在所述建模系统和所述预计算系统之间会进行调用构建接口的交互操作。在所述建模系统中可以同时支持接口导入导出元数据文件，供所述预计算系统使用。比如，所述预计算系统中用于根据所述模型对数据仓库中的数据进行预聚合并保存预计算数据立方体结果。

如图6所示，所述子系统之间还包块模型元数据导入的交互方式。具体地，在所述建模系统和所述查询系统之间会进模型元数据导入的交互操作。在所述查询系统对预计算数据立方体结果进行查询时会对通过模型元数据导入的方式进行交互。

如图6所示，所述子系统之间还包括数据同步的交互方式。具体地，在所述预计算系统和所述查询系统之间会进行数据同步的交互操作。在所述预计算系统中保存预计算数据立方体结果会与所述查询系统进行数据同步。

由于在所述子系统包括：建模系统、预计算系统和查询系统，所述建模系统，用于进行模型开发和数据立方体设计；所述预计算系统，用于根据所述模型对数据仓库中的数据进行预聚合并保存预计算数据立方体结果；所述查询系统，用于对预计算数据立方体结果进行查询。通过在所述建模系统、所述预计算系统以及所述查询系统的三个子系统实现解耦，可以跨网络部署，子系统间不共享任何数据和元数据，只通过文件交换的形式沟通。

实施例二

预计算OLAP系统的使用场景中以资源组形式服务多个租户

根据本申请实施例，作为本实施例中的优选，如图5所示，每个所述子系统中按照不同角色配置不同的资源组，每个所述资源组中部署至少一个服务实例，所述资源组被配置为开发模式、构建模式或者查询模式的角色模式。通过在每个所述资源组部署一个或多个实例服务，同时可以配置该资源组的的角色，经过配置后的所述资源组就会按照定义好的角色模型进行运行。

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

如图4所示，租户在管理时，会绑定对应Hadoop集群的用户，而服务实例在运行时绑定的是Hadoop超级用户，租户每次去执行开发、构建或查询时，服务实例都会只能访问该用户所对应Hadoop用户的数据权限，这样确保数据隔离。且服务实例的个数不会随着租户的增加而增加。

实施例三

预计算OLAP系统使用场景中查询系统的资源组支持不同优先级的查询

根据本申请实施例，作为本实施例中的优选，如图5所示，每个所述子系统中按照不同角色配置不同的资源组，每个所述资源组中部署至少一个服务实例，所述资源组被配置为开发模式、构建模式或者查询模式的角色模式。优选地，还包括根据预设用户优先级在所述查询系统中执行不同优先级的查询请求。

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

区别于现有基于预计算OLAP系统中每个租户需要配备固定的Service instance(服务实例)，各自使用对应权限的Hadoop集群的kerberos用户。当数据立方体Cube构建作业或查询任务发起时，Load Balance负载均衡服务会自动转发请求到对应的租户的服务实例中运行并返回结果。

根据本申请实施例，还提供了一种用于实施上述预计算OLAP系统的预计算OLAP系统实现方法，如图8所示，包括如下步骤：

步骤S102，根据至少包括一个服务实例的资源组，将建模系统、构建系统和查询系统进行解耦部署；

在每个所述资源组可以部署一个或多个实例，同时可以配置该资源组的角色，所述配置的资源组可以定义好的模型角色运行。

步骤S104，在所述建模系统中用于进行模型开发；

步骤S106，在所述构建系统用于进行数据立方体构建；

步骤S108，在所述查询系统中用于进行预设优先级查询；

如图8所示，具体地，在上述步骤S104至步骤S108中，在所述建模系统中通过对开发资源进行模型开发，同时通过预先配置的Rest API数据接口支持可以将已经开发完成的模型导出。通过在所述构建系统构建系统进行数据立方体Cube构建，也有独立的接口完成数据同步，查询工具完成数据立方体Cube查询，从而能完成子系统的解耦。

在所述子系统之间网络隔离，且在所述子系统中通过文件通道进行通信。

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

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

本申请的实现原理：

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

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

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

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

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

Claims (7)

1.一种预计算OLAP系统，其特征在于，包括：至少三个子系统，三个所述子系统之间通过解耦隔离部署同时所述子系统间支持网络隔离，且在三个所述子系统中通过文件通道进行通信，三个所述子系统之间通过解耦隔离时，不共享每个所述子系统中的数据和元数据；

每个所述子系统中按照不同角色配置不同的资源组，每个所述资源组中部署至少一个服务实例，所述资源组被配置为开发模式、构建模式或者查询模式的角色模式，根据预设用户优先级在查询系统中执行不同优先级的查询请求；

其中，所述预计算OLAP系统的使用场景中以资源组形式服务多个租户，通过重构资源组，以资源组形式服务多个租户，从而在所述服务实例的部署方式与所述租户的个数不会有相关联性；

其中，所述预计算OLAP系统使用场景中查询系统的资源组支持不同优先级的查询，预计算OLAP系统作为一个能支持多租户使用的多维分析平台，在租户之间的在查询时一般会有优先级的区分，对于每个查询的资源组，允许按照需求配置所述服务实例的个数，当数据立方体Cube构建作业或查询任务发起时，负载均衡服务会根据查询用户所设定的优先级自动路由到不同的查询资源组中，满足不同优先级的查询请求。

2.根据权利要求1所述的预计算OLAP系统，其特征在于，所述子系统包括：建模系统、预计算系统和查询系统，

所述建模系统，用于进行模型开发和数据立方体设计；

所述预计算系统，用于根据所述模型对数据仓库中的数据进行预聚合并保存预计算数据立方体结果；

所述查询系统，用于对预计算数据立方体结果进行查询。

3.根据权利要求2所述的预计算OLAP系统，其特征在于，所述建模系统中包括第一数据接口，用于进行数据文件的导入或导出，所述预计算系统中包括第二数据接口，用于进行所述预计算数据立方体结果的导出。

4.根据权利要求1所述的预计算OLAP系统，其特征在于，所述子系统之间还包括调用构建接口的交互方式。

5.根据权利要求1所述的预计算OLAP系统，其特征在于，所述子系统之间还包块模型元数据导入的交互方式。

6.根据权利要求1所述的预计算OLAP系统，其特征在于，所述子系统之间还包括数据同步的交互方式。

7.一种预计算OLAP系统实现方法，其特征在于，包括如下步骤：

根据至少包括一个服务实例的资源组，将建模系统、构建系统和查询系统进行解耦部署；

在所述建模系统中用于进行模型开发；

在所述构建系统用于进行数据立方体构建；

在所述查询系统中用于进行预设优先级查询；

其中，在子系统之间网络隔离同时所述子系统间支持网络，且在所述子系统中通过文件通道进行通信，三个所述子系统之间通过解耦隔离时，不共享每个所述子系统中的数据和元数据；

每个所述子系统中按照不同角色配置不同的资源组，每个所述资源组中部署至少一个服务实例，所述资源组被配置为开发模式、构建模式或者查询模式的角色模式，根据预设用户优先级在所述查询系统中执行不同优先级的查询请求；

其中，所述预计算OLAP系统的使用场景中以资源组形式服务多个租户，通过重构资源组，以资源组形式服务多个租户，从而在所述服务实例的部署方式与所述租户的个数不会有相关联性；

其中，所述预计算OLAP系统使用场景中查询系统的资源组支持不同优先级的查询，预计算OLAP系统作为一个能支持多租户使用的多维分析平台，在租户之间的在查询时一般会有优先级的区分，对于每个查询的资源组，允许按照需求配置所述服务实例的个数，当数据立方体Cube构建作业或查询任务发起时，Load Balance负载均衡服务会自动转发请求到对应的租户的服务实例中运行并返回结果。

Images