具体实施方式
在相关技术中,开发者在创建数据仓库时,通常会为数据仓库预先定义一个存储容量较大的数据指标池,基于数据仓库中的数据产生的各类数据指标,都会以维度建模的方式,存放到这个指标池中。
同时,为了便于用户对数据指标池中的数据指标池进行查询检索,在将数据指标存放至数据指标池之前,通常都会针对数据指标的命名进行标准化处理;从而,用户通过现有的搜索引擎技术,基于标准化处理后的数据指标名称,就可以在数据指标池中查询检索到需要的数据指标。
然而,这种方案虽然使用户能够准确的查询到数据指标池中有哪些相似的数据指标,但查询到的数据指标通常是一个比较孤立的变量,并不会与实际的业务产生联系,因此用户即使查询到了需要的数据指标,也无法追溯出该数据指标的来源;
例如,用户无法获知查询到的该数据指标,是基于数据仓库中的哪张业务数据表中的业务数据计算得到的,只能通过手动的对相关的业务数据表中的业务数据进行汇总来确定。
可见,现有的数据指标查询方案,虽然通过对数据指标的名称进行标准化处理,并结合现有的搜索引擎技术,能满足用户的数据指标查询需求,但无法追溯查询到的数据指标的来源。而且,在实际应用中,如果用户无法获知数据指标的来源,还可能会对数据指标的正常使用带来影响。
有鉴于此,本申请提出一种将数据仓库的数据指标池划分为具有层级关系的多个指标集合,并基于核心业务数据表与数据指标之间的数据依赖关系,来优化数据指标查询的技术方案。
在实现时,可以基于所述数据仓库中的核心业务数据表构建核心业务数据表集合,并建立所述核心业务数据表集合中的各核心业务数据表,与各层级的指标集合中的数据指标之间的数据依赖关系;以及,建立各层级的指标集合中的数据指标之间的数据依赖关系;在基于用户输入的与待查询数据指标相关的查询索引,在数据指标池中查询对应的数据指标时,可以将查询到的数据指标,以及与该数据指标存在数据依赖关系的核心业务数据表和其它层级的指标集合中的数据指标作为查询结果返回给用户,从而可以优化数据指标的查询过程,使得用户在查询数据指标池中的数据指标时,不仅可以查询到需要的数据指标,而且还可以查询到与该数据指标存在数据依赖关系的数据指标以及核心业务数据表,追溯出该数据指标的来源。
下面通过具体实施例并结合具体的应用场景对本申请进行描述。
请参考图1,图1是本申请一实施例提供的一种数据仓库中的数据指标查询方法,应用于服务端;其中,所述数据仓库包括数据指标池;所述数据指标池中的数据指标被划分为具有层级关系的多个指标集合数据;所述方法执行以下步骤:
步骤101,基于所述数据仓库中的核心业务数据表构建核心业务数据表集合;
步骤102;建立所述核心业务数据表集合中的各核心业务数据表,与各层级的指标集合中的数据指标之间的数据依赖关系;以及,建立各层级的指标集合中的数据指标之间的数据依赖关系;
步骤103,基于用户输入的与待查询数据指标相关的查询索引,在所述数据指标池中查询对应的数据指标;
步骤104,将查询到的数据指标,以及与该数据指标存在数据依赖关系的核心业务数据表和其它层级的指标集合中的数据指标作为查询结果返回至所述用户。
上述服务端,可以包括搭载数据仓库的服务器、服务器集群、或者基于服务器集群搭建的业务平台。
上述核心业务数据表,是指用于存储数据仓库的运营方的核心业务数据的数据表;在实际应用中,上述核心业务数据,通常可以包括那些存放于数据仓库的中间层以及基础层的数据。例如,以与支付业务平台对接的数据仓库为例,上述核心业务数据表,具体可以包括与支付业务相关的交易表、事件表、以及会员表,等等。
上述核心业务数据表集合,是指基于数据仓库中的核心业务数据表构建的指标集合;该核心业务数据表中的元素,即为与各类核心业务对应的核心业务数据表;例如,以与支付业务平台对接的数据仓库为例,该核心业务数据表中的元素,通常可以包括与支付业务相关的交易表、事件表、以及会员表,等等。
上述数据依赖关系,也可以称之为“血缘关系”;对于数据指标而言,上述“血缘关系”表达的是数据指标,与计算得到该数据指标所采用的计算参数之间的计算逻辑;
具体而言,由于对于一个数据指标而言,计算得到该数据指标的计算参数,可以是原始的业务数据,也可以是在原始的业务数据的基础上计算得到的其它数据指标;因此,在本申请中,上述“血缘关系”可以划分为两类:
第一类是数据指标与原始的业务数据表之间的“血缘关系”,通过这一类“血缘关系”可以表达出计算该数据指标所采用的基础数据来源;比如,当前的数据指标是基于哪些核心业务数据进行进一步的计算得到的。
另一类是数据指标与其它数据指标之间的“血缘关系”,通过这一类“血缘关系”可以表达出该数据指标,与计算得到该数据指标的其它数据指标之间的计算逻辑;比如,当前的数据指标是基于哪些现有的数据指标进行进一步的计算得到的。
以下结合数据指标的层级划分、数据依赖关系的构建、以及数据指标的查询三个阶段,对本申请的技术方案进行详细描述。
1)数据指标的层级划分
在本申请中,提出一种对数据仓库的数据指标池(以下简称“指标池”)中的数据指标,进行分层管理的指标池架构。通过将数据指标池中的数据指标之间,以及数据指标与原始的业务数据之间的“血缘关系”,作为对指标池进行分层的依据,将指标池中的数据指标划分为多个具有层级关系的指标集合,从而可以对数据仓库的数据指标池中大量的数据指标进行更加高效的管理。
请参见图2,图2为本申请示出的一种对指标池中的数据指标进行分层的示意图。
如图2所述,在对指标池中的数据指标进行分层时:
一方面,可以查找出指标池中由数据仓库中的原始业务数据,直接计算得到的基础数据指标,然后将查找的这些基础数据指标划分为第一级指标集合。其中,划分出的该第一级指标集合,也可以称之为“基础指标集合”,该集合中的数据指标均为基于原始的业务数据直接计算得到的基础指标。
另一方面,当划分出第一级指标集合后,可以进一步查找上述指标池中由上述第一级指标集合中的基础指标直接计算得到的二级数据指标,然后将查找的这些二级数据指标划分为第二级指标集合。
当第一级指标集合以及第二级数据指标划分完成后,由于在第一级指标集合以及第二级指标集合的基础上,还能够进一步衍生出更多的计算指标,因此还可以进一步查找上述指标池中由上述第一级指标集合以及第二级指标集合中的任一指标集合,或者多个指标集合中的数据指标计算得到的三级数据指标,然后将查找的这些三级数据指标划分为第三级指标集合;
依此类推,当三级指标集合创建完成后,如果指标池中还存在由第一至第三级指标集合中的数据指标计算得到的第N(N大于3)级数据指标时,还可以采用相同的方式,查找上述指标池中由上述第一级指标集合至第N级指标集合中的任一指标集合,或者多个指标集合中的数据指标计算得到的N级数据指标,然后将查找的这些N级数据指标划分为第N级指标集合,直到针对指标池中的数据指标均分层完毕。
其中,需要说明的是,按照以上示出的分层方式,虽然可以将指标池划分为N个具有数据依赖关系的指标集合,但由于在计算各数据指标时所采用的逻辑算子的复杂程度各有差异,因此对于一些采用复杂算子计算得到的数据指标,可能无法作为计算参数被更高层级的数据指标直接使用,而造成分层得到的各指标集合中的数据指标的可用性较差的问题。
可见,在采用以上示出的分层方式对指标池中的数据指标进行分层时,充分考量计算得到各数据指标时所使用的逻辑算子是否单一是十分有必要的。
有鉴于此,在示出的另一种实施方式中,为了进一步优化对指标池进行分层后各层级的指标集合中的数据指标的可用性,在按照以上示出的分层方式基于在计算数据指标时所采用的逻辑算子的原子性,来对指标池中的数据指标进行分层。
其中,所谓逻辑算子,包括那些在计算数据指标时所采用的基础逻辑算法;比如,上述逻辑算子可以包括count、sum、max、min等逻辑算法。而所述逻辑算子的原子性,是指在计算数据指标时,仅能够采用单一的逻辑算子。在基于采用的逻辑算子的原子性对指标池进行分层时,可以将指标池中的数据指标是否采用了单一的逻辑算子,作为分层的依据,将那些均采用了单一的逻辑算子的数据指标划分至同一个数据指标层中。
请继续参见图2,当考量了逻辑算子的原子性后,在对指标池中的数据指标进行分层时:
首先,可以将指标池中由数据仓库中的原始业务数据,采用单一的逻辑算子直接计算得到的基础数据指标,划分为第一级指标集合。
其次,当划分出第一级指标集合后,可以进一步将指标池中由上述第一级指标集合中的基础指标,采用单一的逻辑算子直接计算得到的二级数据指标划分为第二级指标集合;
以此类推,可以在第一级和第二级指标集合的基础上,基于指标池中由第一至第N(N大于3)级指标集合中的数据指标,采用单一的逻辑算子直接计算得到的第N级数据指标划分为第N级指标集合,直到针对指标池中的数据指标均分层完毕。
例如,以与支付业务平台对接的数据仓库为例,假设指标池如下表所示:
指标 |
指标维度 |
所属的城市 |
IP |
最近180天交易次数 |
账户、IP |
最近180天交易次数最大的IP |
账户 |
账户最近180天交易次数最大的IP所属的城市 |
账户 |
通过上表可知,指标“所属的城市”以及“最近180天交易次数”均为基于原始的交易数据(相当于上述原始的业务数据)采用单一的逻辑算法直接计算得到,因此可以将指标“所属的城市”以及“最近180天交易次数”划分至第一级指标集合;
指标“最近180天交易次数最大的IP”为针对第一级指标“最近180天交易次数”采用单一的逻辑算法直接计算得到,因此可以将指标“最近180天交易次数最大的IP”划分至第二级指标集合;
指标“账户最近180天交易次数最大的IP所属的城市”为基于第一级指标“所属的城市”以及第二级指标“最近180天交易次数最大的IP”采用单一的逻辑算法直接计算得到,因此可以将指标“账户最近180天交易次数最大的IP所属的城市”划分至第三级指标集合。
可见,通过这种方式,不仅能够将指标池划分为N个具有数据依赖关系的指标集合,而且可以确保每一级指标集合中的数据指标,均为采用单一的逻辑算子计算得到的数据指标,从而使得每一级指标集合中的数据指标,均能够作为计算参数被更高层级的数据指标直接使用,可以提升分层后的各层级的指标集合中的数据指标的可用性。
当然,除了以上描述的上述N级指标集合中的数据指标,均需要遵循采用的逻辑算子的单一性原则以外,在实际应用中,为了降低对指标池进行分层的复杂度,可以仅上述第一级指标集合中的数据指标来遵循这一原则。
例如,在示出的一种实施方式中,上述N级指标集合中,至少上述第一级指标集合中的数据指标需要遵循采用的逻辑算子的单一性原则,而除了第一级指标集合以外的其它层级的指标集合,可以不遵循这一原则,从而可以在确保上述N级数据指标集合中的可用性的前提下,尽可能的降低指标池分层的复杂度。
2)数据依赖关系的构建
在本申请中,当完成针对上述指标池的层级划分后,为了能够描述出核心业务与上述指标池中各层级的指标集合中的数据指标之间的联系,通过各层级的指标集合中的数据指标来真实的反映核心业务的具体状况,还可以进一步建立数据仓库中的核心业务数据表,与各层级的指标集合中的数据指标之间;以及,各层级的指标集合中的数据指标之间的“血缘关系”。
在初始状态下,数据仓库的运营方,可以基于实际的业务需求,将需要重点关注的业务定义为核心业务,并通过运营人员对数据仓库中与核心业务相关的核心业务数据表进行人工标注。
而服务端则可以在后台读取数据仓库中与运营方定义的核心业务相关的核心业务数据表,然后基于读取到的核心业务数据表来创建核心业务数据表集合。
例如,以与支付业务平台对接的数据仓库为例,支付业务为该数据仓库的运营方的核心业务,而上述核心业务数据表,通常可以包括与支付业务相关的交易表、事件表、以及会员表,等等。上述服务端在创建核心业务数据表中,可以从上述数据仓库的中间层以及基础层中,读取与支付业务相关的数据表,然后基于读取到的数据表来创建上述核心业务数据表集合。
当完成核心业务数据表集合创建完成后,上述服务端可以进一步开启创建核心业务数据表集合中的元素,与各层级的指标集合中的数据指标之间的“血缘关系”;以及,各层级的指标集合中的数据指标之间的“血缘关系”的流程。
一方面,核心业务数据表与各层级的指标集合中的数据指标之间的“血缘关系”,通常表达的是计算该数据指标所采用的基础数据来源;即该数据指标是基于哪些核心业务数据表中的业务数据进行进一步的计算得到的。
在这种情况下,上述服务端可以遍历各层级的指标集合中的数据指标,反向追溯在计算各层级的指标集合中的数据指标时所采用的基础数据的来源,确认出计算该数据指标所采用的业务数据所归属的核心业务数据表。
例如,在实现时,数据仓库在基于自动采集或者人工导入的业务数据,计算沉淀数据指标时,默认可以在后台自动标记计算各数据指标时所采用的数据来源,或者也可以由运营人员手动标注出计算各数据指标时的数据来源(比如标注出各数据指标是采用哪一类型的业务数据,或者现有指标进行计算得到的),从而上述服务端可以通过在后台自动查找已经标注的信息,反向追溯出计算各层级的指标集合中的数据指标所采用的数据来源。
如果通过上述反向追溯确认出某一数据指标是直接采用原始的业务数据计算得到的,并且该数据指标的数据来源命中了上述核心业务数据表中的核心业务数据表,此时上述服务端可以创建该数据指标,与计算该数据指标时所采用的业务数据所归属的核心业务数据表之间的“血缘关系”。
其中,需要说明的是,对于核心业务数据表而言,可以与任意层级的指标集合中的任一数据指标存在“血缘关系”。
另一方面,各层级的指标集合中的数据指标之间的“血缘关系”,通常表达的数据指标,与计算得到该数据指标的上一级数据指标之间的计算逻辑;即该数据指标是基于哪些现有的数据指标进行进一步的计算得到的。
在这种情况下,上述服务端在遍历各层级的指标集合中的数据指标的过程中,如果通过反向追溯确认出某一数据指标,并不是直接采用原始的业务数据计算得到的,而是采用较低的其它层级的指标集合中的一个或者多个数据指标直接计算得到,此时上述服务端可以创建该数据指标,与计算该数据指标时所采用的其它指标集合中的数据指标之间的“血缘关系”。
其中,需要说明的是,对于任一层级的指标集合中的数据指标,可以与较低的其它层级中的任一低层级的数据指标存在“血缘关系”。
请参见图3,图3为本例示出的一种建立核心业务数据表与各层级的数据指标;以及各层级的数据指标之间的“血缘关系”的示意图。
在图3中,上述数据仓库与支付业务平台对接;上述核心业务指标集合由交易表、时间表、会员表以及其它表等与支付业务相关的业务数据表构成;指标池中包括指标1-指标9共9个数据指标。指标1-指标3被划分为第一级指标集合;指标4-6被划分为第二级指标集合;指标7-9被划分为第三级指标集合。
在创建“血缘关系”时,上述服务端可以遍历指标池中的各数据指标,追溯计算各数据指标时的数据来源。
假设追溯出指标1为基于交易表和会员表中的业务数据,采用单一的逻辑算子计算得到,那么上述服务端可以建立指标1与交易表和会员表之间的“血缘关系”;
假设追溯出指标2为基于事件表中的业务数据,采用单一的逻辑算子计算得到,那么上述服务端可以建立指标2与事件表之间的“血缘关系”;
假设追溯出指标3为基于其它表中的业务数据,采用单一的逻辑算子计算得到,那么上述服务端可以建立指标3与其它表之间的“血缘关系”;此时针对第一级指标集合中的数据指标的“血缘关系”创建完成,上述服务端可以继续遍历第二级指标集合中的数据指标。
假设追溯出指标4可以基于交易表中的业务数据,采用单一的逻辑算子计算得到;也可以基于第一级指标集合中的指标1和指标2,采用单一的逻辑算子计算得到;那么上述服务端可以分别建立指标4与交易表;以及指标4与指标1和指标2之间的“血缘关系”;
假设追溯出指标5基于第二级指标集合中的指标2,采用单一的逻辑算子计算得到;那么上述服务端可以建立指标5与指标2之间的“血缘关系”;
假设追溯出指标6基于第二级指标集合中的指标3,采用单一的逻辑算子计算得到;那么上述服务端可以建立指标6与指标3之间的“血缘关系”;此时针对第二级指标集合中的数据指标的“血缘关系”创建完成,上述服务端可以继续遍历第三级指标集合中的数据指标。
假设追溯出指标7基于第二级指标集合中的指标5,采用单一的逻辑算子计算得到;那么上述服务端可以建立指标7与指标5之间的“血缘关系”;
假设追溯出指标8基于第二级指标集合中的指标4和指标5,采用单一的逻辑算子计算得到;那么上述服务端可以建立指标8与指标4和指标5之间的“血缘关系”;
假设追溯出指标9基于第一级指标集合中的指标3;以及第二级指标集合中的指标5,采用单一的逻辑算子计算得到;那么上述服务端可以建立指标9与指标3和指标5之间的“血缘关系”;至此,针对各层级的指标集合中的数据指标的“血缘关系”创建完成。
3)数据指标的查询
在本例中,当完成核心业务数据表,与各层级的指标集合中的数据指标之间;以及,各层级的指标集合中的数据指标之间的“血缘关系”的创建后,用户可以通过数据仓库面向提供的用户界面,输入一个查询索引,来快速的完成相关数据指标的查询检索。
在实际应用中,用户在查询检索上述指标池中的数据指标时,通常存在以下示出的两种查询场景:
在一种查询场景下,假设用户对于想要查询的数据指标的“血缘关系”并不明确,此时输入的查询索引可以仅包括查询关键词。上述数据仓库的搜索引擎,可以基于输入的该查询关键词,遍历上述指标池中各层级的指标集合,来完成数据指标的查找,并在完成查找后将查询到的目标数据指标返回给用户;同时,由于指标池中已经维护了该数据指标相关的“血缘关系”,因此,除了返回查询到的该目标数据指标以外,与该目标数据指标存在“血缘关系”的核心业务表,以及与该目标数据指标存在“血缘关系”的其它层级的数据指标,也可以作为查询结果一并返回。
可见,通过这种方式,使得用户在基于输入的查询关键词来查询数据指标时,可以查询到与该数据指标存在数据依赖关系的数据指标以及核心业务数据表,追溯出该数据指标的来源以及完整的计算过程。
例如,请参见图4,图4为本例示出的一种查询数据指标的示意图;假设用户通过输入查询关键字查询图3中所示出的指标8,那么数据仓库的搜索引擎返回的查询结果,可以如图4所示,用户通过查看查询结果,可以追溯出计算指标8的业务数据可能来源于交易表、事件表、会员表及其它表。
在另一种查询场景下,假设用户对于想要查询的数据指标的“血缘关系”十分明确,此时输入的查询索引除了可以包括查询关键词以外,还可以包括用户指定的核心业务数据表。即用户可以基于某张指定的核心业务数据表,来查找想要的数据指标。
在这种情况下,上述数据仓库的搜索引擎,首先可以基于指标池中维护的核心业务数据表与各层级的数据指标之间的“血缘关系”,查询出与用户指定的核心业务数据表存在“血缘关系”的数据指标,然后基于查询到的数据指标创建第一数据指标集合。
当第一数据指标集合创建完成后,搜索引擎可以基于指标池中维护的各层级的数据指标之间的“血缘关系”,进一步查询出与上述第一数据指标集合中的各数据指标存在“血缘关系”的数据指标,并基于查询到的数据指标创建第二数据指标集合。
当第二数据指标集合创建完成后,搜索引擎可以基于指标池中维护的各层级的数据指标之间的“血缘关系”,进一步查询出与上述第二数据指标集合中的各数据指标存在“血缘关系”的数据指标,并基于查询到的数据指标创建第三数据指标集合。
依次类推,当第三数据指标集合创建完成后,如果指标池中还存在由第一至第三级指标集合中的数据指标计算得到的第N(N大于3)级数据指标时,还可以采用相同的方式,查询与第N-1数据指标集合中的数据指标存在“血缘关系”的其它层级的指标集合中的数据指标,基于查询到的数据指标创建第N数据指标集合。
当完成以上查询后,此时搜索引擎可以基于用户输入的查询关键字,分别在上述第一数据指标集合至上述第N数据指标集合中来完成数据指标的查询。
其中,需要说明的是,在实际应用中,由于上述“血缘关系”是一种双向的“血缘关系”,在这种情况下,上述第一数据指标集合至第N数据指标集合中的部分数据指标,可能会存在重复;为了避免由于各数据指标集合中的元素存在重复,而导致的部分元素与用户输入的查询关键字进行重复匹配的问题,可以针对上述第一数据指标集合至第N数据指标集合中的元素进行取交集运算,然后基于取交集运算的结果,创建一个目标集合,从而搜索引擎可以基于用户输入的查询关键字,在上述目标集合来完成数据指标的查询。
通过以上实施例可见,由于在基于用户输入的查询关键词完成数据指标的查询之前,根据用户指定的核心业务表以及指标池中维护的“血缘关系”,对查找范围进行了筛选,使得本次查询操作,可以只在与用户指定的核心业务数据存在血缘关系的数据指标的范围内进行查询,因此可以显著的提升查询速度,提高查询效率。
当完成以上查询后,可以将查询到的目标数据指标,以及与该目标数据指标存在“血缘关系”的核心业务表,以及与该目标数据指标存在“血缘关系”的其它层级的数据指标,作为查询结果一并返回。
当然,在这种情况下,由于用户指定的核心业务表,和查询到的与该目标数据指标存在“血缘关系”的核心业务表通常相同,因此在查询结果中也可以不包含与该目标数据指标存在“血缘关系”的核心业务表。
例如,请参见图5,图5为本例示出的另一种查询数据指标的示意图;假设用户希望基于交易表以及查询关键字来查询如图3所示出的指标8,那么数据仓库的搜索引擎首先可以基于指标池维护的“血缘关系”,查找出所有与交易表存在“血缘关系”的数据指标;如图3所示,此时所有与交易表存在“血缘关系”的数据指标包括指标1和指标4,那么可以基于指标1和指标4创建第一数据指标集合{指标1、指标4}。
进一步的,搜索引擎可以基于指标池维护的“血缘关系”,查找与第一数据指标集合中的指标1和指标4存在“血缘关系”的其它层级的数据指标;如图3所示,此时所有与指标1和指标4存在“血缘关系”的数据指标包括指标1、指标2、指标4和指标8,那么可以基于指标1、指标2、指标4和指标8创建第二数据指标集合{指标1、指标2、指标4、指标8}。
最后,搜索引擎可以针对第一数据指标集合和第二数指标集合中的元素进行取交集计算,得到目标数据指标集合{指标1、指标2、指标4、指标8};搜索引擎可以遍历目标数据指标集合,基于用户输入的查询关键词来完成本次查找,并向用户返回查询结果,不再赘述。
通过以上各实施例可知,本申请通过将数据仓库的数据指标池划分为具有层级关系的多个指标集合,并基于所述数据仓库中的核心业务数据表构建核心业务数据表集合,然后建立所述核心业务数据表集合中的各核心业务数据表,与各层级的指标集合中的数据指标之间的数据依赖关系;以及,建立各层级的指标集合中的数据指标之间的数据依赖关系;
当基于用户输入的与待查询数据指标相关的查询索引,在数据指标池中查询对应的数据指标时,可以将查询到的数据指标,以及与该数据指标存在数据依赖关系的核心业务数据表和其它层级的指标集合中的数据指标作为查询结果返回给用户,从而可以优化数据仓库中的数据指标的查询过程,使得用户在查询数据指标池中的数据指标时,不仅可以查询到需要的数据指标,而且还可以查询到与该数据指标存在数据依赖关系的数据指标以及核心业务数据表,追溯出该数据指标的来源。
与上述方法实施例相对应,本申请还提供了装置的实施例。
请参见图6,本申请提出一种数据仓库中的数据指标查询装置60,应用于服务端;其中,请参见图7,作为承载所述数据仓库中的数据指标查询装置60的服务端所涉及的硬件架构中,通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等;以软件实现为例,所述数据仓库中的数据指标查询装置60通常可以理解为加载在内存中的计算机程序,通过CPU运行之后形成的软硬件相结合的逻辑装置,所述装置60包括:
构建模块601,基于所述数据仓库中的核心业务数据表构建核心业务数据表集合;
建立模块602,建立所述核心业务数据表集合中的各核心业务数据表,与各层级的指标集合中的数据指标之间的数据依赖关系;以及,建立各层级的指标集合中的数据指标之间的数据依赖关系;
查询模块603,基于用户输入的与待查询数据指标相关的查询索引,在所述数据指标池中查询对应的数据指标;
返回模块604,将查询到的数据指标,以及与该数据指标存在数据依赖关系的核心业务数据表和其它层级的指标集合中的数据指标作为查询结果返回至所述用户。
在本例中,所述装置60还包括:
划分模块605(图6中未示出),将所述数据指标池中,由所述数据仓库中的业务数据计算得到的数据指标,划分为第一级指标集合;将所述数据指标池中,由所述第一指标集合中的数据指标计算得到的数据指标,划分为第二级指标集合;以及,将所述数据指标池中,由所述第一级指标集合至第N级指标集合中的任一指标集合,或者多个指标集合中的数据指标计算得到的数据指标,划分为第N级指标集合;其中,所述N大于等于3。
在本例中,各级指标集合中的数据指标,均为采用单一的逻辑算子计算得到;或者,至少所述第一级指标集合中的数据指标,为采用单一的逻辑算子计算得到。
在本例中,所述建立模块602进一步:
建立各层级的指标集合中的数据指标,与在计算该数据指标时所采用的业务数据所归属的核心业务数据表之间的数据依赖关系;以及,
建立各层级的指标集合中的数据指标,与计算该数据指标时所采用的其它层级的指标集合中的数据指标之间的数据依赖关系。
在本例中,所述查询索引包括查询关键词;
所述查询模块603:
在所述数据指标池中查询与所述查询关键词对应的目标数据指标;
当查询到所述目标数据指标时,进一步查询与所述目标数据指标存在数据依赖关系的核心业务数据表,以及与所述目标数据指标存在数据依赖关系的其它层级的指标集合中的数据指标。
在本例中,所述查询索引包括查询关键词,以及由用户指定的核心业务数据表;
所述查询模块603:
查询与用户指定的所述核心业务数据表存在数据依赖关系的数据指标,并基于查询到的数据指标创建第一数据指标集合;
查询与所述第一数据指标集合中的数据指标存在数据依赖关系的其它层级的指标集合中的数据指标,基于查询到的数据指标创建第二数据指标集合;
查询与第N-1数据指标集合中的数据指标存在数据依赖关系的其它层级的指标集合中的数据指标,基于查询到的数据指标创建第N数据指标集合;其中,所述N大于等于3。
基于所述查询关键词在所述第一数据指标集合至所述第N数据指标集合中查询对应的目标数据指标。
在本例中,所述查询模块603进一步:
针对所述第一数据指标集合至第N数据指标集合中的元素进行取交集运算,得到目标集合;
基于所述查询关键词在所述目标集合中查询对应的目标数据指标。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。