发明内容
本申请提出一种数据仓库中的数据查询方法,所述数据仓库搭载元数据模型;所述元数据模型包括业务元数据;其中,所述数据仓库中的业务数据表被配置为若干业务实体;所述业务元数据包括所述若干业务实体,和与所述若干业务实体相关的业务数据表的物理存储信息之间的映射关系;所述方法包括:
通过可视化界面向用户输出预配置的所述若干业务实体;
获取用户在所述可视化界面中选择的目标业务实体,并在所述业务元数据中查询与所述目标业务实体存在映射关系的物理存储信息;
基于查询到的所述物理存储信息构建查询指令;
执行所述查询指令从所述数据仓库中查询对应的业务数据表,并将查询结果通过所述可视化界面向用户输出。
可选的,所述业务实体,包括预配置的业务实体对象、业务实体属性、以及业务实体对象之间的关联关系;
所述映射关系包括:
业务实体对象,和与该业务实体对象相关的业务数据表的物理存储信息之间的第一映射关系;
业务实体属性,和与该业务实体属性相关的业务数据表的物理存储信息之间的第二映射关系;以及,
业务实体对象之间的关联关系,和与该关联关系相关的业务数据表的物理存储信息之间的第三映射关系。
可选的,所述通过可视化界面向用户输出预配置的所述若干业务实体,包括:
通过所述可视化界面向用户输出业务实体关系图;
其中,所述业务实体关系图包括与业务实体对象对应的查询节点、与业务实体属性对应的查询节点、以及与业务实体对象之间的关联关系对应的查询节点。
可选的,所述获取用户在所述可视化界面中选择的目标业务实体,并在所述业务元数据中查询与所述目标业务实体存在映射关系的物理存储信息,包括:
获取用户在所述可视化界面中选择的查询节点;
如果用户选择的所述查询节点为与业务实体对象对应查询节点,查询所述第一映射关系得到与该业务实体对象存在映射关系的物理存储信息;
如果用户选择的所述查询节点为与业务实体属性对应的查询节点,查询所述第二映射关系得到与该业务实体属性存在映射关系的物理存储信息;以及,
如果用户选择的所述查询节点为与业务实体之间的关联关系对应的查询节点,查询所述第三映射关系得到与该关联关系对应的物理存储信息。
可选的,所述元数据模型还包括用于自动构建查询指令的技术元数据;
所述基于查询到的所述物理存储信息构建查询指令,包括:
基于查询的所述物理存储信息以及所述技术元数据自动构建查询指令。
可选的,还包括:
获取用户在所述可视化界面中输入的业务实体配置信息;
基于获取到的业务实体配置信息,将所述数据仓库中的业务数据表配置为若干业务实体。
本申请还提出一种数据仓库中的数据查询方法,所述数据仓库搭载元数据模型;所述元数据模型包括业务元数据;其中,所述数据仓库中的业务数据表被配置为若干业务实体;所述业务元数据包括所述若干业务实体,和与所述若干业务实体相关的业务数据表的物理存储信息之间的映射关系;所述装置包括:
输出模块,通过可视化界面向用户输出预配置的所述若干业务实体;
获取模块,获取用户在所述可视化界面中选择的目标业务实体,并在所述业务元数据中查询与所述目标业务实体存在映射关系的物理存储信息;
构建模块,基于查询到的所述物理存储信息构建查询指令;
查询模块,执行所述查询指令从所述数据仓库中查询对应的业务数据表,并将查询结果通过所述可视化界面向用户输出。
可选的,所述业务实体,包括预配置的业务实体对象、业务实体属性、以及业务实体对象之间的关联关系;
所述映射关系包括:
业务实体对象,和与该业务实体对象相关的业务数据表的物理存储信息之间的第一映射关系;
业务实体属性,和与该业务实体属性相关的业务数据表的物理存储信息之间的第二映射关系;以及,
业务实体对象之间的关联关系,和与该关联关系相关的业务数据表的物理存储信息之间的第三映射关系。
可选的,所述输出模块:
通过所述可视化界面向用户输出业务实体关系图;
其中,所述业务实体关系图包括与业务实体对象对应的查询节点、与业务实体属性对应的查询节点、以及与业务实体对象之间的关联关系对应的查询节点。
可选的,所述获取模块:
获取用户在所述可视化界面中选择的查询节点;
如果用户选择的所述查询节点为与业务实体对象对应查询节点,查询所述第一映射关系得到与该业务实体对象存在映射关系的物理存储信息;
如果用户选择的所述查询节点为与业务实体属性对应的查询节点,查询所述第二映射关系得到与该业务实体属性存在映射关系的物理存储信息;以及,
如果用户选择的所述查询节点为与业务实体之间的关联关系对应的查询节点,查询所述第三映射关系得到与该关联关系对应的物理存储信息。
可选的,所述元数据模型还包括用于自动构建查询指令的技术元数据;
所述构建模块:
基于查询的所述物理存储信息以及所述技术元数据自动构建查询指令。
可选的,所述获取模块进一步:
获取用户在所述可视化界面中输入的业务实体配置信息;
所述装置还包括:
配置模块,基于获取到的业务实体配置信息,将所述数据仓库中的业务数据表配置为若干业务实体。
本申请中,可以将数据仓库中的业务数据表抽象为若干业务实体,并将这些业务实体,和与这些业务实体相关的业务数据表的物理存储信息之间的映射关系,作为业务元数据进行集中维护;同时可以通过可视化界面向用户输出预配置的各业务实体;当用户需要查询和使用数据仓库中存储的数据时,可以获取用户在可视化界面中选择的目标业务实体,并在上述业务元数据中查询到与该目标业务实体存在映射关系的物理存储信息,然后基于查询到的物理存储信息自动构建查询指令,并执行该查询指令来查询相关的业务数据表在上述可视化界面向用户输出;
一方面,由于在数据的查询过程中,用户仅需要在可视化界面中输出的各业务实体关系的关联关系中,选择相关的目标业务实体,即可在后台基于维护的业务元数据自动查询相关的物理存储信息,并基于查询到的物理存储信息自动编辑查询指令完成业务数据表的查询和展示,因此可以显著降低数据仓库中的数据的使用门槛,使得那些并不了解数据仓库的底层存储特性的普通用户,也可以从业务视角更加快捷的查询和使用数据仓库中的业务数据;
另一方面,由于数据仓库可以将各业务实体,和各业务实体相关的业务数据表的物理存储信息的映射关系作为元数据在元数据模型中进行集中存储,在数据的查询过程中,并不要求用户熟悉数据仓库中各个业务数据表的物理存储信息,因此在数据仓库的底层存储呈现多样化的场景下,可以屏蔽掉数据仓库的底层存储的多样化对数据查询造成的影响,从而可以显著降低数据仓库中的数据的查询难度。
具体实施方式
本申请旨在提出一种基于实体建模法,对数据仓库进行建模,将数据仓库中维护的业务数据表抽象成为若干业务实体,并将这些业务实体,和与这些业务实体相关的业务数据表的物理存储信息之间的映射关系,作为业务元数据,在数据仓库的元数据模型中进行集中维护,进而来降低数据仓库中的数据的使用门槛,以及屏蔽掉数据仓库的底层存储的多样化对数据查询造成的影响的技术方案。
在实现时,可以通过可视化界面向用户输出预配置的各业务实体;当用户需要查询和使用数据仓库中存储的数据时,可以获取用户在上述可视化界面中选择的目标业务实体,并在上述业务元数据中查询到与该目标业务实体存在映射关系的物理存储信息,然后基于查询到的物理存储信息自动构建查询指令,并执行该查询指令来查询相关的业务数据表在上述可视化界面向用户输出;
一方面,由于在数据的查询过程中,用户仅需要在可视化界面中输出的各业务实体关系的关联关系中,选择相关的目标业务实体,即可在后台基于维护的业务元数据自动查询相关的物理存储信息,并基于查询到的物理存储信息自动编辑查询指令完成业务数据表的查询和展示,因此可以显著降低数据仓库中的数据的使用门槛,使得那些并不了解数据仓库的底层存储特性的普通用户,也可以从业务视角更加快捷的查询和使用数据仓库中的业务数据;
另一方面,由于数据仓库可以将各业务实体,和各业务实体相关的业务数据表的物理存储信息的映射关系作为元数据在元数据模型中进行集中存储,在数据的查询过程中,并不要求用户熟悉数据仓库中各个业务数据表的物理存储信息,因此在数据仓库的底层存储呈现多样化的场景下,可以屏蔽掉数据仓库的底层存储的多样化对数据查询造成的影响,从而可以显著降低数据仓库中的数据的查询难度。
下面通过具体实施例并结合具体的应用场景对本申请进行描述。
请参考图1,图1是本申请一实施例提供的一种数据仓库中的数据查询方法,应用于服务端;所述数据仓库搭载元数据模型;所述元数据模型包括业务元数据;其中,所述数据仓库中的业务数据表,被配置为若干业务实体;所述业务元数据包括所述若干业务实体,和与所述若干业务实体相关的业务数据表的物理存储信息之间的映射关系;所述方法执行以下步骤:
步骤101,通过可视化界面向用户输出预配置的所述若干业务实体;
步骤102;获取用户在所述可视化界面中选择的目标业务实体,并在所述业务元数据中查询与所述目标业务实体存在映射关系的物理存储信息;
步骤103,基于查询到的所述物理存储信息构建查询指令;
步骤104,执行所述查询指令从所述数据仓库中查询对应的业务数据表,并将查询结果通过所述可视化界面向用户输出。
上述服务端,可以包括搭载数据仓库的服务器、服务器集群、或者基于服务器集群搭建的业务平台。
上述元数据模型,是指用于集中维护与数据仓库相关的元数据的数据模型;例如,在传统的数据仓库中,与数据仓库相关的元数据,通常可以包括用于描述数据仓库内的数据结构以及数据的建立方法的相关数据。
上述物理存储信息,具体可以包括数据仓库中各业务数据表的表结构信息,以及各业务数据表之间的关联关系等与各业务数据表的底层数据存储相关的信息。即在本申请中,任意形式的与各业务数据表的底层数据存储相关的信息,都可以纳入到上述物理存储信息的范畴。
例如,在传统的数据仓库中,上述表结构信息通常包括物理表信息、物理表结构信息、物理集群信息、物理表索引信息等等。其中,上述物理表信息,用于描述各业务数据表的存储文件类型等存储属性信息;上述物理表结构信息,用于描述各业务数据表的行数、列数以及所包含的数据量等信息;上述物理集群信息,用于描述各业务数据表所在的服务器集群的相关信息;上述物理表索引信息,用于描述可快速访问各业务数据表的查询关键词等的信息。上述各业务数据表之间的关联关系,通常用于描述同一类业务数据相关的业务数据表之间的关联性;比如,假设有多张业务数据表隶属于同一种业务类型,那么可以建立该多张业务数据表之间的关联关系。
以下以业务实体的划分、元数据模型的搭建、基于业务实体的数据查询三个阶段对本申请的技术方案进行详细描述。
1)业务实体的划分
在本申请中,业务运营人员可以采用实体建模法,并结合实际的业务需求和业务视角,对数据仓库进行建模。
其中,上述实体建模法,并不是数据仓库建模中常见的一种方法。
所谓实际建模法,是指参照哲学中客观世界是由一个个实体、以及实体与实体之间的关系组成的原理,将数据仓库中维护的大量业务数据表,抽象出若干业务实体,然后通过在数据仓库中搭建元数据模型,并在元数据模型中定义相关的业务元数据,来描述抽象出的这些业务实体之间的关系的建模理念。
需要说明的是,基于数据仓库中存储的大量业务数据表,抽象出若干业务实体,可以称之为上述实体建模法的初步建模过程。而与之对应的是,在抽象出的若干业务实体的基础上,通过在元数据模型中定义相关的业务元数据,来进一步描述这些业务实体之间的关系,可以称之为上述实体建模法的最终建模过程。
在本例中,上述业务实体,具体是指基于数据仓库中存储的各类业务数据,而抽象出的若干业务对象;在本申请中,上述业务实体具体可以包括业务实体对象、业务实体属性、以及业务实体对象之间的关联关系。
上述业务实体对象,具体是指抽象出的业务实体的名称,通常与业务运营人员所关注的业务视角相对应;
例如,以移动端的支付业务为例,业务运营人员可以基于业务视角,将与支付业务相关的业务数据表,定义成为诸如“国内支付账户”、“支付环境”、“手机号”、“设备ID”、“网络类型”以及“交易类型”等业务实体。此时,定义完成的每一个业务实体,均为业务运营人员所关注的一个业务视角。
上述业务实体对象之间的关联关系,具体是指用于描述已抽象出的各业务实体之间的关系的信息。对于各业务实体之间的关系,可以包括任意形式的,能够描述不同的业务实体之间的联系的信息;比如,社交关系、业务数据的相关性,等等。即在实际应用中,任何形式的能够体现各业务实体之间的联系的信息,都可以作为定义各业务实体之间的关联关系的参考依据。
上述业务实体属性,是指用于描述各业务实体的信息;在本申请中,上述业务实体属性,可以包括描述业务实体对象的属性,和描述业务实体对象之间的关联关系的属性信息。即在实际应用中,任何形式的能够描述各业务实体,以及各业务实体之间的关系的信息,都可以作为上述业务实体属性。
例如,对于业务实体“国内支付账户”而言,为其定义的属性可以包括“是否实名”以及“最后一次登录的时间”,等等。
在本申请中,当完成基于实体建模法的初步建模过程后,数据仓库中存储的业务数据表,可以被进一步划分为与各业务实体对象相关的业务数据表、与业务实体属性相关的业务数据表,以及与各业务实体之间的关联关系相关的业务数据表等三类。
需要说明的是,在实际应用中,以上描述的基于实体建模法的初步建模过程,可以由业务运营人员通过上述服务端提供的一个可视化界面,来手动完成。
在示出的一种实时方式中,上述服务端可以预先搭载相关的建模工具,并通过该建模工具面向业务运营人员提供一个可视化界面;其中,在该可视化界面中,可以分别提供与“业务实体对象”、“业务实体属性”以及“业务实体对象之间的关系”对应的配置选项(比如配置按钮)。
而用户可以通过触发上述配置选项(比如点击),进入到相关的配置页面,在该配置界面中手动的输入业务实体配置信息,来完成以上描述的业务实体的配置过程,将数据仓库中存储的业务数据表,抽象成为若干个自定义的业务实体。
例如,在一个例子中,当用户触发了上述配置选项时,上述建模工具可以进入到对应的配置界面,并通过该配置界面将当前数据仓库存储的业务数据表以列表的形式向上述业务运营人员输出,从而上述业务运营人员可以在输出的列表中,选择相应的业务数据表,并在上述配置界面中输入相应的配置信息(比如与业务实体对象、业务实体属性以及业务实体对象之间的关系对应的主题名称),来完成业务实体配置过程。
而上述建模工具,则可以在后台获取用户通过上述配置界面输入的业务实体配置信息,并基于获取到的业务实体配置信息,将上述数据仓库中存储的业务数据表抽象成为若干业务实体。
例如,以业务运营人员触发了与“业务实体对象”对应的配置选项为例,当上述建模工具检测到用户针对该配置选项的触发操作,可以进入到配置界面,并在该配置界面中以列表的形式输出该业务运营人员当前可操作的业务数据表,然后获取用户在该配置界面中输入的业务实体对象的主题名称,以及用户选择出的业务数据表,在后台进行绑定,来完成“业务实体对象”的配置过程。
当然,在实际应用中,当业务运营人员的业务需求或者业务视角发生变化,业务人员可以通过上述可视化界面重复执行以上描述的业务实体配置过程,对已配置完成的业务实体进行更新,具体的过程不再赘述。
2)元数据模型的搭建
当完成以上描述的基于实体建模法的初步建模过程后,此时可以在抽象出的若干业务实体的基础上,继续完成上述实体建模法的最终建模过程,为数据仓库搭建元数据模型,并通过在该元数据模型中定义相关的业务元数据,来进一步描述这些业务实体之间的关系。
在本例中,上述元数据模型中集中维护的元数据,可以包括技术元数据和业务元数据两类。
其中,在上述业务元数据中,可以包括与各业务数据表相关的物理存储信息,以及由业务运营人员抽象出的上述若干业务实体,和与这些业务实体相关的业务数据表的物理存储信息之间的映射关系;而上述技术元数据中,可以具体包含那些用于基于各业务数据表的物理存储信息,自动构建查询指令的元数据。
在本例中,在初始状态下,在上述业务元数据中,可以仅包含与数据仓库存储的各业务数据表相关的物理存储信息。即在未完成以上描述的基于实体建模法的初步建模过程时,默认可以仅将与数据仓库存储的各业务数据表相关的物理存储信息作为业务元数据,在上述元数据模型中进行集中维护。
当完成了以上描述的基于实体建模法的初步建模过程后,由于此时数据仓库中的业务数据表已经被抽象成为了若干个业务实体,因此在这种情况下,上述建模工具可以基于已经集中维护的与各业务数据表相关的物理存储信息,进一步创建这些业务实体,和与这些业务实体相关的业务数据表的物理存储信息之间的映射关系,并将创建的映射关系作为业务元数据在元数据模型中进行集中维护。
在实现时,由于当完成基于实体建模法的初步建模过程后,数据仓库中存储的业务数据表,已经被进一步划分为与各业务实体对象相关的业务数据表、与业务实体属性相关的业务数据表,以及与各业务实体之间的关联关系相关的业务数据表等三类;因此,在这种情况下,可以在上述元数据模型中,进一步维护各业务实体对象,和与各业务实体对象相关的业务数据表的物理存储信息之间的第一映射关系;各业务实体属性,和与各业务实体属性相关的业务数据表的物理存储信息之间的第二映射关系;以及,各业务实体对象之间的关联关系,和与该关联关系相关的业务数据表的物理存储信息之间的第三映射关系。
需要说明的是,上述第一映射关系,用于描述各业务实体对象,和存储这些业务实体对象相关的业务数据的业务数据表的物理存储信息之间的映射关系;上述第二映射关系,用于描述各业务实体属性,和存储这些业务实体属性相关的业务数据的业务数据表的物理存储信息之间的映射关系;上述第三映射关系,用于描述各业务实体对象之间的关联关系,和存储与该关联关系相关的业务数据的业务数据表的物理存储信息之间的映射关系。
例如,在一种实现方式中,元数据模型可以在逻辑上被划分为“物理表信息模块”、“物理表链接模块”、“业务信息模块”以及“桥接表”等。
一方面,假设元数据模型集中维护的物理存储信息,可以包括各业务数据表的表结构信息,以及各业务数据表之间的关联关系信息两类,分别如下表1和表2所示:
表名 |
备注 |
phy_tables |
物理表信息 |
phy_columns |
物理表结构信息 |
cluster_info |
物理集群信息 |
phy_indexes |
物理表索引信息 |
表1:表结构信息
表名 |
备注 |
phy_tablink |
物理表关联关系信息 |
表2:业务数据表关联关系信息
在初始状态下,对于表1中维护的信息,可以集中存储到“物理表信息模块”中;对于表2中维护的信息,可以集中存储到“物理表链接模块”。
另一方面,当完成了以上描述的基于实体建模法的初步建模过程后,数据仓库中的业务数据表已经被抽象成为了若干个业务实体,如下表3所示:
表名 |
备注 |
obj_info |
实体对象信息 |
obj_prop |
实体属性信息 |
link_info |
实体对象关系信息 |
link_prop |
实体对象关系属性信息 |
表3:业务实体信息
对于表3中维护的信息,可以集中存储到“业务信息模块”。然后,可以基于上述表1以及表3中集中维护的信息,创建各业务实体,和与各业务实体相关的业务数据表的物理存储信息之间的桥接表(即上述映射关系)。其中创建的上述桥接表具体可以如下表4所示:
表名 |
备注 |
obj_phy |
实体对象-物理表桥接表 |
obj_prop_phy |
实体属性-物理表桥接表 |
link_phy |
实体对象关系-物理表桥接表 |
link_porp_phy |
实体对象关系属性-物理表桥接表 |
表4:桥接表
此时表4中维护的各类桥接表,描述的就是各业务实体,和与各业务实体相关的业务数据表的物理存储信息之间的映射关系。对于表4中维护的各类桥接表,最终将作为上述元数据模型中的业务元数据,在上述元数据模型中进行集中维护和管理。
请继续参见图2,图2为本例示出的一种元数据模型的架构图。
如图2所示,在物理层面,数据仓库中存储的各搭载了多样化的底层存储系统;比如,图2示出的为数据仓库搭载了ODPS、ADS以及hbase等底层存储系统。数据仓库中的各业务数据表,分别存储在底层存储系统。
在业务层面,数据仓库的底层存储系统中存储的各业务数据表,可以配置成为由业务实体对象、业务实体属性以及业务实体之间的关系组成的若干个业务实体。
其中,为了“打通”物理层面到业务层面之间的数据引用关系,在搭建上述元数据模型时,还可以针对物理层面的各底层存储系统,与业务层面上抽象出的各业务实体,分别创建对应的桥接表,用于维护各业务实体,和与各业务实体相关的业务数据表的物理存储信息之间的映射关系。
由于不同的底层存储系统中,业务数据表的表结构等物理存储信息存在差异,因此对于普通的业务运营人员而言,很难熟练的掌握各种底层物理存储系统的表结构等物理存储等信息。
请继续参见图2,在本申请中,由于在搭建元数据模型时,已经通过创建如图2所示出的桥接表,维护了各业务实体,和与各业务实体相关的业务数据表的物理存储信息之间的映射关系,因此用户在需要查询并使用数据仓库中的业务数据表时,即使不熟悉各底层存储系统中存储的各业务数据表的物理存储信息,仍然不会影响用户的正常数据查询。
可见,通过这种方式,可以有效的屏蔽掉数据仓库的底层存储的多样化对数据查询造成的影响,显著降低数据仓库中的数据的查询难度。
3)基于业务实体的数据查询
在本例中,当基于实体建模法完成对数据仓库的建模后,上述服务端可以将数据仓库的元数据模型中集中维护的业务元数据,通过可视化界面向业务运营人员输出,从而业务运营人员需要从业务视角查询和使用数据仓库中的业务数据表时(比如从业务视角对部分业务数据表执行简单的数据分析),可以通过在上述可视化界面选中相应的业务实体,来触发上述服务端通过维护的上述业务元数据来查询相关的业务数据表的物理存储信息。
在示出的一种实施方式中,上述服务端可以将配置完成的各业务实体,以实体关系图的形式,通过上述可视化界面向业务运营人员输出。
在本例中,上述实体关系图,具体可以是一种能够描述各业务实体之间的关系的可视化数据结构。
其中,由于各业务实体,由业务实体对象、业务实体属性和业务实体对象之间的关系组成,因此在通过上述可视化界面输出各业务实体时,可以将组成该业务实体的业务实体对象、业务实体属性和业务实体对象之间的关系,分别抽象成为对应的查询节点,然后向业务运营人员输出。
通过这种方式,上述服务端最终通过上述可视化界面向用户输出的实体关系图,可以包括与业务实体对象对应的查询节点、与业务实体属性对应的查询节点、以及与业务实体对象之间的关联关系对应的查询节点,等等。从而,如果业务运营人员需要从业务视角查询和使用数据仓库中的业务数据表,则只需要在上述可视化界面输出的查询节点中,选中相应的查询节点即可。
其中,需要说明的是,上述实体关系图在上述可视化界面中最终呈现出的可视化形态,在本申请中不进行特别限定,具体可以是如图2中示出的能够描述各业务实体之间的关系的ER(Entity Relationship Diagram,实体联系图)图,也可以是能够描述各业务实体之间的关系的可视化列表。即在实际应用中,可以将配置完成的各业务实体,以ER图的形式输出,也可以组织成列表的形式输出。
请参见图3,图3为本例示出的一种通过可视化界面输出业务实体的示意图。
如图3所示,上述可视化界面具体可以是一个查询界面,对于配置完成的各业务实体,可以组织成树状列表的形式,通过上述可视化界面向业务运营人员进行输出。比如,图3示出的可视化界面中,各业务实体对象和描述各业务实体对象的属性,以及各业务实体对象之间的关系与描述该关系的属性,可以分别以“主目录-子目录”的树状列表的形式进行输出。
其中,对于树状列表中的每一个目录,都分别对应一个能够被业务运营人员进行选择的查询节点。在实际应用中,业务运营人员可以基于实际的业务视角,在上述树状列表中选中相应的目录,来触发上述服务端来执行后续的数据查询过程。
在本例中,上述服务端可以在后台获取用户在上述可视化界面中选中的查询节点,并识别用户选中的查询节点的类型,然后基于识别出的查询节点的类型,调用业务元数据中维护的相关映射关系,来自动获取与用户选中的查询节点存在映射关系的物理存储信息。
具体的,如果上述服务端识别出用户选中的查询节点,为与业务实体对象对应查询节点,此时可以查询业务元数据中维护的各业务实体对象,和与这些业务实体对象相关的业务数据表的物理存储信息之间的映射关系(即上述第一映射关系),得到与该业务实体对象存在映射关系的物理存储信息;
如果上述服务端识别出的用户选中的查询节点,为与业务实体属性对应查询节点(可以包括与描述业务实体对象的属性对应的查询节点,和与描述业务实体对象之间的关系的属性对应的查询节点),此时可以查询业务元数据中维护的各业务实体属性,和与这些业务实体属性相关的业务数据表的物理存储信息之间的映射关系(即上述第二映射关系),得到与该业务实体属性存在映射关系的物理存储信息;
如果上述服务端识别出的用户选中的查询节点,为与与业务实体之间的关系对应查询节点,此时可以查询业务元数据中维护的各业务实体之间的关系,和与这些业务实体之间的关系相关的业务数据表的物理存储信息之间的映射关系(即上述第三映射关系),得到与该业务实体之间的关系存在映射关系的物理存储信息。
在本例中,当上述服务端识别出用户选择的查询节点的类型,并调用业务元数据中维护的相关映射关系,成功获取与用户选中的查询节点存在映射关系的物理存储信息后,可以基于上述元数据模型中维护的技术元数据,以及获取到的物理存储信息,自动构建对应的查询指令,然后自定执行该查询指令,从数据仓库的底层存储系统中查询相应的业务数据表,然后将查询结果,通过上述可视化界面向业务运营人员输出。
通过这种方式,由于在整个查询过程中,可以由服务端基于查询到的底层存储系统相关的物理存储信息,自动构建并执行查询指令来完成数据表的查询,而对于业务运营人员而言,完全不需要深入了解数据仓库的底层存储系统的存储特性,因此可以显著降低数据仓库中的业务数据表的使用门槛,使得那些并不了解数据仓库的底层存储特性的业务运营人员,也可以从业务视角更加快捷的查询和使用数据仓库中的业务数据。
请继续参见图3,在图3示出的可视化界面中,还可以包括与查询结果对应的数据展示区域,以及针对查询到的业务数据表执行数据分析的数据分析区域。
在实际应用中,当上述服务端通过执行自动构建的查询指令,从数据仓库的底层存储系统中读取到业务运营人员需要的业务数据表时:
一方面,可以将查询到的业务数据表,导入到上述数据展示区域,向业务运营人员进行输出展示;
另一方面,在上述数据分析区域,可以预先提供与特定的数据分析操作相关的若干功能选项;在这种情况下,业务运营人员在对上述数据展示区域中输出展示的业务数据表进行确认后,可以在上述数据展示区域中执行进一步的操作,将数据展示区域展示的这些业务数据表作为输入数据,导入到上述数据分析区域,然后基于实际的数据分析需求,通过触发相应的数据分析的功能选项,来执行针对导入的这些业务数据表的数据分析操作。当然,当数据分析结束后,上述服务端还可以将数据分析后得到的相关分析结果(比如一些与业务相关的指标),在上述数据分析区域向业务运营人员及时的进行反馈输出。
至此,业务运营人员基于业务视角的业务数据表的查询以及分析过程完成。需要说明的是,在实际应用中,如果业务运营人员的业务需求或者业务视角发生变化,此时可以选择对上述可视化界面中输出的业务数据表进行清除,并重新选中相关的查询节点,来触发上述服务端重新执行以上示出的数据查询过程。
通过以上各实施例可知,本申请提出了一种基于实体建模法,对数据仓库进行建模,可以将数据仓库中的业务数据表抽象为若干业务实体,并将这些业务实体,和与这些业务实体相关的业务数据表的物理存储信息之间的映射关系,作为业务元数据进行集中维护;同时可以通过可视化界面向用户输出预配置的各业务实体;当用户需要查询和使用数据仓库中存储的数据时,可以获取用户在可视化界面中选择的目标业务实体,并在上述业务元数据中查询到与该目标业务实体存在映射关系的物理存储信息,然后基于查询到的物理存储信息自动构建查询指令,并执行该查询指令来查询相关的业务数据表在上述可视化界面向用户输出;
一方面,由于在数据的查询过程中,用户仅需要在可视化界面中输出的各业务实体关系的关联关系中,选择相关的目标业务实体,即可在后台基于维护的业务元数据自动查询相关的物理存储信息,并基于查询到的物理存储信息自动编辑查询指令完成业务数据表的查询和展示,因此可以显著降低数据仓库中的数据的使用门槛,使得那些并不了解数据仓库的底层存储特性的普通用户,也可以从业务视角更加快捷的查询和使用数据仓库中的业务数据;
另一方面,由于数据仓库可以将各业务实体,和各业务实体相关的业务数据表的物理存储信息的映射关系作为元数据在元数据模型中进行集中存储,在数据的查询过程中,并不要求用户熟悉数据仓库中各个业务数据表的物理存储信息,因此在数据仓库的底层存储呈现多样化的场景下,可以屏蔽掉数据仓库的底层存储的多样化对数据查询造成的影响,从而可以显著降低数据仓库中的数据的查询难度。
与上述方法实施例相对应,本申请还提供了装置的实施例。
请参见图4,本申请提出一种数据仓库中的数据查询装置40,应用于服务端;其中,所述数据仓库搭载元数据模型;所述元数据模型包括业务元数据;其中,所述数据仓库中的业务数据表被配置为若干业务实体;所述业务元数据包括所述若干业务实体,和与所述若干业务实体相关的业务数据表的物理存储信息之间的映射关系。
请参见图5,作为承载所述数据仓库中的数据查询装置40的服务端所涉及的硬件架构中,通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等;以软件实现为例,所述数据仓库中的数据查询装置40通常可以理解为加载在内存中的计算机程序,通过CPU运行之后形成的软硬件相结合的逻辑装置,所述装置40包括:
输出模块401,通过可视化界面向用户输出预配置的所述若干业务实体;
获取模块402,获取用户在所述可视化界面中选择的目标业务实体,并在所述业务元数据中查询与所述目标业务实体存在映射关系的物理存储信息;
构建模块403,基于查询到的所述物理存储信息构建查询指令;
查询模块404,执行所述查询指令从所述数据仓库中查询对应的业务数据表,并将查询结果通过所述可视化界面向用户输出。
在本例中,所述业务实体,包括预配置的业务实体对象、业务实体属性、以及业务实体对象之间的关联关系;
所述映射关系包括:
业务实体对象,和与该业务实体对象相关的业务数据表的物理存储信息之间的第一映射关系;
业务实体属性,和与该业务实体属性相关的业务数据表的物理存储信息之间的第二映射关系;以及,
业务实体对象之间的关联关系,和与该关联关系相关的业务数据表的物理存储信息之间的第三映射关系。
在本例中,所述输出模块401:
通过所述可视化界面向用户输出业务实体关系图;
其中,所述业务实体关系图包括与业务实体对象对应的查询节点、与业务实体属性对应的查询节点、以及与业务实体对象之间的关联关系对应的查询节点。
在本例中,所述获取模块402:
获取用户在所述可视化界面中选择的查询节点;
如果用户选择的所述查询节点为与业务实体对象对应查询节点,查询所述第一映射关系得到与该业务实体对象存在映射关系的物理存储信息;
如果用户选择的所述查询节点为与业务实体属性对应的查询节点,查询所述第二映射关系得到与该业务实体属性存在映射关系的物理存储信息;以及,
如果用户选择的所述查询节点为与业务实体之间的关联关系对应的查询节点,查询所述第三映射关系得到与该关联关系对应的物理存储信息。
在本例中,所述元数据模型还包括用于自动构建查询指令的技术元数据;
所述构建模块403:
基于查询的所述物理存储信息以及所述技术元数据自动构建查询指令。
在本例中,所述获取模块402进一步:
获取用户在所述可视化界面中输入的业务实体配置信息;
所述装置40还包括:
配置模块405(图4中未示出),基于获取到的业务实体配置信息,将所述数据仓库中的业务数据表配置为若干业务实体。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。