查询方法、装置以及存储介质

技术领域

本申请涉及数据处理技术，特别是涉及一种查询方法、装置以及存储介质。

背景技术

随着大数据时代的来临，数据给人们的生产和生活带来了有力的决策支撑，在营销行业诞生了精准营销的概念。所谓精准营销其实就是通过客户的信息为客户构建不同的标签，通过标签组合构建成客群，最终得出的客群就是客户想要营销的对象。对于标签系统的实现方式各不相同，查询得到客群的效率也不一样，本专利申请专注于解决零售行业的标签系统中的标签组织方式和检索方式，以一种灵活的方式定义客群，以一种快速的查询方式得到客群结果。

但是，当前的一些标签系统实现是通过开发固定的页面，定制化客户标签需求来实现标签系统。在检索数据方面，也是固定的检索逻辑，无法实现客户自定义逻辑的客群。例如，目前大部分系统是通过将标签固化到WEB界面上，客户可以任意的选择标签。但是这种方式客户无法自由的定义标签之间的关系，如图1所示，如果客户要想获取性别是“男”或者年龄在“0～18”岁的客户，则无法实现。在该图中只能表达行为为“男”且年龄在“0～18”岁的客户，如果要想表达“或”的关系，则系统需要定制开发。

针对上述的现有技术中存在的标签系统不能实现客户标签的定制化需求，并且只能通过固定的检索逻辑进行检索，从而无法实现客户自定义逻辑的客群的技术问题，目前尚未提出有效的解决方案。

发明内容

本公开的实施例提供了一种查询方法、装置以及存储介质，以至少解决现有技术中存在的标签系统不能实现客户标签的定制化需求，并且只能通过固定的检索逻辑进行检索，从而无法实现客户自定义逻辑的客群的技术问题。

根据本公开实施例的一个方面，提供了一种查询方法，包括：响应于用户在交互界面上进行的与查询任务相关的界面操作，在交互界面上显示与查询任务对应的树状图形，其中树状图形的节点组件用于表示与查询任务相关的标签信息；生成与树状图形对应的树状查询模型，其中树状查询模型的节点与树状图形的节点组件所表示的标签信息对应；以及根据树状查询模型的节点所对应的标签信息，进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息。

根据本公开实施例的另一个方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时由处理器执行以上所述的方法。

根据本公开实施例的另一个方面，还提供了一种查询装置，包括：树状图形显示模块，配置用于响应于用户在交互界面上进行的与查询任务相关的界面操作，在交互界面上显示与查询任务对应的树状图形，其中树状图形的节点组件用于表示与查询任务相关的标签信息；查询模型生成模块，配置用于生成与树状图形对应的树状查询模型，其中树状查询模型的节点与树状图形的节点组件所表示的标签信息对应；以及查询模块，配置用于根据树状查询模型的节点所对应的标签信息，进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息。

根据本公开实施例的另一个方面，还提供了一种查询装置，包括：处理器；以及存储器，与处理器连接，用于为处理器提供处理以下处理步骤的指令：响应于用户在交互界面上进行的与查询任务相关的界面操作，在交互界面上显示与查询任务对应的树状图形，其中树状图形的节点组件用于表示与查询任务相关的标签信息；生成与树状图形对应的树状查询模型，其中树状查询模型的节点与树状图形的节点组件所表示的标签信息对应；以及根据树状查询模型的节点所对应的标签信息，进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息。

从而本公开的实施例，通过树状结构标签的组织，客户能够表达标签的层级关系，例如要表达某段时间内累计消费金额则需要先添加一个交易时间标签，再在时间标签后面添加一个累计消费金额子标签，这样就能表达客户想要的是某段时间内的累计消费金额。并且通过树状结构，可以定义父子标签以及兄弟标签之间的逻辑关系(例如父节点和子节点之间为且的关系，兄弟节点之间可为且也可以为或，具体情况由客户指定)。进而解决了现有技术中存在的标签系统不能实现客户标签的定制化需求，并且只能通过固定的检索逻辑进行检索，从而无法实现客户自定义逻辑的客群的技术问题，目前尚未提出有效的解决方案。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：

图1是用于实现根据本公开实施例1所述的方法的计算设备的硬件结构框图；

图2是根据本公开实施例1所述的查询的系统的示意图；

图3是根据本公开实施例1的所述的查询方法的流程示意图；

图4是根据本公开实施例1的所述的查询交互界面的示意图；

图5是根据本公开实施例1的所述的树桩查询模型的示意图；

图6是根据现有技术所述的查询界面的示意图；

图7是根据本公开实施例2所述的查询装置的示意图；以及

图8是根据本公开实施例3所述的查询装置的示意图。

具体实施方式

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

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

实施例1

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

本实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的计算设备中执行。图1示出了一种用于实现查询方法的计算设备的硬件结构框图。如图1所示，计算设备可以包括一个或多个处理器(处理器可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器、以及用于通信功能的传输装置。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算设备还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算设备中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器可用于存储应用软件的软件程序以及模块，如本公开实施例中的查询方法对应的程序指令/数据存储装置，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的查询方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算设备的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与计算设备的用户界面进行交互。

此处需要说明的是，在一些可选实施例中，上述图1所示的计算设备可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是，图1仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算设备中的部件的类型。

图2是根据本实施例所述的查询系统的示意图，具体的该查询系统例如可以是一种客群信息查询系统。参照图2所示，该系统包括用户终端设备100、服务器200以及数据库300。其中，用户终端设备100用于提供与用户进行交互的交互界面，从而供用户输入进行客群查询的标签信息。服务器200配置用于与用户终端设备100进行通信，根据用户终端设备100发送的查询指令在数据库300中查询相关的客群信息。数据库300用于存储客群信息，并且根据服务器200的查询请求向服务器200返回查询结果数据。此外数据库300例如可以作为数仓收集客户数据，数仓可以使用hive构建。数据通常会包含两部分数据，及客户属性信息和客户交易信息。所以可以在数仓层构建两张宽表，及客户属性和客户交易信息。

需要说明的是，系统中的用户终端设备100、服务器200以及数据库300均可适用上面所述的硬件结构。

在上述运行环境下，根据本实施例的第一个方面，提供了一种查询方法，该方法例如可以由图2中所示的用户终端设备实现。图3示出了该方法的流程示意图，参考图3所示，该方法包括：

S302：响应于用户在交互界面上进行的与查询任务相关的界面操作，在交互界面上显示与查询任务对应的树状图形，其中树状图形的节点组件用于表示与查询任务相关的标签信息；

S304：生成与树状图形对应的树状查询模型，其中树状查询模型的节点与树状图形的节点组件所表示的标签信息对应；以及

S306：根据树状查询模型的节点所对应的标签信息，进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息。

具体地，参见图2所示，用户终端设备100可以显示与用户交互的交互界面，其中用户可以通过交互界面进行与查询任务相关的界面操作，例如可以在该交互界面上设置待查询的客群信息的标签信息。

并且，图4示出了交互界面的示意图，其中该交互界面例如可以是一个web界面。参考图4所示，用户可以通过在该交互界面上对节点组件进行拖曳等操作，从而构建与查询任务相关的树状图形。其中图4示出了该树状图形具有多个节点组件，包括“XX客群”、“客户属性1”、“客户属性1.1”、“客户属性1.1.1”、“客户属性1.1.2”、“客户属性2”、“客户交易标签：交易门店”......“客户交易标签：交易时间”等等。

其中用户可以通过终端设备在各个节点组件中输入相应的标签信息。例如，根据收集到的客户数据，我们可以在这些数据里面提取许多标签，而这些标签可以划分为两类，即客户属性标签和客户交易标签。客户属性标签(即，cust标签)可以有：姓名、性别、年龄、身高、生日、职业、婚否、是否黑名单用户、有效积分等；交易标签可以有：交易时间、单笔交易金额、品类、品牌、交易门店、获取积分、购买次数、累计消费金额、购买次数占比、购买金额占比等。而针对交易标签，又可以将其分为两类标签，我称之为行为标签(即action标签)和结果标签(即，result标签)。行为标签可以理解为客户单次购买的行为属性，例如购买的品类、品牌、消费金额、获取的积分、购买门店等，而结果标签可以是客户多次购买行为的一个运算结果，例如累计消费次数、累计消费金额、消费金额占比等。

然后，用户终端设备100生成与状图形对应的树状查询模型，其中树状查询模型的节点与树状图形的节点组件所表示的标签信息对应。其中图5示出了一个树状查询模型的示意图。其中树状查询模型例如是与用户在交互界面上构建的树状图形相对应。并且树状查询模型的节点与树状图形的节点组件所表示的标签信息对应。

然后，用户终端设备100根据树状查询模型的节点所对应的标签信息，进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息。具体地，用户终端设备100可以与服务器200进行交互，根据各个节点的标签信息在数据库300中进行查询，从而最终确定与用户输入的查询任务对应的数据信息。

正如背景技术中所述的，当前的一些标签系统实现是通过开发固定的页面，定制化客户标签需求来实现标签系统。在检索数据方面，也是固定的检索逻辑，无法实现客户自定义逻辑的客群。这种方式客户无法自由的定义标签之间的关系，其中图6是根据现有技术的查询界面的示意图，如图6所示，如果客户要想获取性别是“男”或者年龄在“0～18”岁的客户，则无法实现。在该图中只能表达行为为“男”且年龄在“0～18”岁的客户，如果要想表达“或”的关系，则系统需要定制开发。

有鉴于此，根据本公开的技术方案，提供了一种基于树状查询模型的查询方法。从而，用户可以在交互界面上通过拖曳节点组件的方式形成与查询任务相关的树状图形。然后，可以根据用户形成的树状图形，生成对应的树状查询模型，并根据树状查询模型的节点的标签信息，进行与查询任务相关的查询操作。

从而通过这种方式，通过树状结构标签的组织，客户能够表达标签的层级关系，例如要表达某段时间内累计消费金额则需要先添加一个交易时间标签，再在时间标签后面添加一个累计消费金额子标签，这样就能表达客户想要的是某段时间内的累计消费金额。并且通过树状结构，可以定义父子标签以及兄弟标签之间的逻辑关系(例如父节点和子节点之间为且的关系，兄弟节点之间可为且也可以为或，具体情况由客户指定)。

从而，通过树状结构的标签组织，能够清晰的表达过滤数据的先后顺序(按照从根节点开始从上往下，从左往右的顺序，而一般非树状结构的标签无法表达这个逻辑)。举例：例如非树状结构的标签客户选择了购买时间t1～t2、购买门店merchant1、累计消费金额100w，这个时候首先客户不太好理解这个累计消费金额是仅仅代表在t1～t2这段时间的累计消费还是代表在t1～t2这段时间在门店merchant1的累计消费，或者其它。但是通过树结构就能清晰的表达，如果要仅仅表达t1～t2时间段的累计消费，则选项消费时间标签，然后在其后面选择子标签——累计消费金额。进而解决了现有技术中存在的标签系统不能实现客户标签的定制化需求，并且只能通过固定的检索逻辑进行检索，从而无法实现客户自定义逻辑的客群的技术问题，目前尚未提出有效的解决方案。

此外，关于图4所示的树状图形以及图5所示的树状查询模型，可以定义如下：

a)树的根节点代表客群

b)根节点下面可以随意创建两类标签，客户属性标签和客户交易标签。

c)客户属性标签后面的标签只能选择客户属性标签。

d)客户交易标签后面只能选择客户交易标签。

e)父节点标签和子节点标签的关系永远为“且”，兄弟节点之间的标签由用户指定为“且”或者为“或”。

f)客户交易标签中的result标签后面不能再创建子标签，并且result标签只能作为action标签的子标签。

g)在构造如图2所示的web界面时，约定第一个添加的子节点为左子节点，其次添加的子节点为右子节点，以此类推。

约定单个标签数据结构为：

其中sql是根据标签不同而表示不同的含义，如果标签类型为非result标签时，sql为该标签对应的客户信息或者交易信息字段名称，如果为result标签时，sql字段为结果函数，如count、sum、avg等。标签节点有如下定义：cust标签后面只能接cust标签，action标签后面可以接action标签和result标签，result标签只能作为叶子节点标签，并且只能作为action标签的子标签。cust标签直接过滤cust_info表的数据，而action标签是过滤trans_info的数据，result标签也是过滤trans_info的数据。每个叶子节点得出一个小客群，最后所有的客群通过标签直接的“且”或者“或”关系汇总到根节点形成最终的客群。

可选地，根据树状查询模型进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息的操作，包括：确定与树状查询模型的各个节点对应的数据信息；以及根据树状查询模型的各个节点对应的数据信息以及树状查询模型的各个节点之间的逻辑关系，确定与查询任务对应的数据信息。

具体地，在构建树状查询模型之后，为了查询与查询任务相关的客群信息。用户终端设备100首先确定树状查询模型的各个节点对应的数据信息作为中间结果。然后用户终端设备100再根据各个节点之间的逻辑关系，确定与查询任务对应的数据信息(即，客群信息)。从而通过这种方式，可以提高查询的运算效率。

可选地，确定与树状查询模型的各个节点对应的数据信息的操作，包括：通过广度优先算法遍历树状查询模型的各个节点，确定与树状查询模型的各个节点对应的数据信息。

可选地，确定与树状查询模型的各个节点对应的数据信息的操作，还包括：确定树状查询模型的根节点；以及从根节点的子节点开始，逐层确定与树状查询模型的各个节点对应的数据信息。

具体地，参考图5所示，根据本公开所述的查询方法，用户终端设备100先找到根节点(“客群”，ID为1)，然后根据根节点找到其所有的子节点(即“姓名”、“性别”和“购买门店”)。然后用户终端设备100在子节点中找到最左节点。判断如果节点对应的标签为cust标签，则直接查询数仓中cust_info表。然后基于该节点进行深度优先查找，直到其子孙节点有两个及以上的子节点为止。如图5所示，会查询到身高这个标签为止。此时根据深度优先的路径经过的节点标签来构建查询条件，如图5则会构建一个查询语句为select*fromcust_info where姓名＝‘’and身高＝‘’。并且，查询出的中间结果以中间视图的方式保存，视图名称(即中间结果名称)命名规则为：深度优先检索到的最后节点到根节点的路径所经过的节点id的组合。如图5中，如果客群ID为1，姓名节点的id为2，身高节点id为3，则姓名标签的检索结果对应的视图名称为321。这样就检索完了一个节点。接着开始检索“性别”标签，由于其没有子节点，则构建的查询语句为select*from cust_info where性别＝‘’，如果该节点id为6，则生成的视图名称为61。接着查询购买门店，与姓名标签同样的逻辑，不同的是查询的表变为了trans_info，构造出的查询语句为select*from trans_info where购买门店＝‘’and购买时间＝‘’。并且，参考图5所示，由于购买门店节点id为7，购买时间节点id为8，则生成的查询结果视图名称为871。当遍历完第一层节点(即，“姓名”、“性别”以及“购买门店”)后，开始遍历第二层节点。第二层的每个节点遍历方式和第一层一样的逻辑，其差异在于如果当前节点为左节点，并且没有右兄弟节点，则不用构建查询(因为其结果视图在上一步已经生成好，例如身高节点，早在遍历姓名时已经生成好321视图)，如果需要查询，则查询父节点生成好的视图(即父节点已经查询到的中间结果)。当遍历完第二层节点时开始遍历第三层节点，第三层节点的遍历与第二层节点遍历的逻辑一样。当遍历到叶子节点时，系统还需要根据当前节点对应的视图查询出客群。客群的命名规则与数据视图类型，名称为当前节点到根节点路径id组成，前缀为cust，例如到婚否标签节点时得到的客群视图名称为cust_4321,客群视图包含用户id，用户手机号，openid，会员等级等一系列信息。

从而，综上所述，从根节点的子节点开始，逐层确定与树状查询模型的各个节点对应的数据信息的操作，包括根据以下操作获取与查询任务相关的第一中间结果：从作为根节点的子节点的第一节点开始，沿树状查询模型的深度方向逐层对路径上的各个节点进行查询并确定与路径上的各个节点对应的数据信息，直到包含两个以上子节点的第二节点为止，停止对两个以上子节点进行查询，从而获取第一中间结果。

并且，进一步地，从根节点的子节点开始，逐层确定与树状查询模型的各个节点对应的数据信息的操作，包括根据以下操作获取与查询任务相关的第二中间结果：别对两个以上子节点进行查询，从而获取分别与两个以上子节点对应的第二中间结果。

从而，通过这种方式，根据树的结构判断生成的视图到哪一层节点，而不是每一层都需要生成视图，从而极大的减少了中间视图的量，提高了用户终端设备100的内存的利用率。

可选地，根据树状查询模型的各个节点对应的数据信息以及树状查询模型的各个节点之间的逻辑关系，确定与查询任务对应的数据信息的操作，包括：从树状查询模型的层级最深的第三节点开始，根据各个节点对应的数据信息，确定与查询任务对应的数据信息。

具体地，参考图5所示，计算设备100根据各个节点之间的“且”“或”关系汇总客群，得到最终的客群信息。首先系统查询最深的一层节点，如图5所示，首先会查询到节点ID:11，由前面所述，我们可知系统已经生成好客群视图cust_119871。然后，判断id:11是否有兄弟节点，如果有，则拉出id:11的所有兄弟节点，根据兄弟节点间的且或关系可以将各种节点对应的客群最终汇聚成一个客群。例如A∩B∪C∩D，按照∩优先∪的算法汇聚成一个新的客群视图，这个视图的名称为父节点到根节点的id路径，例如id:11汇聚的结果为cust_9871。以此类推，一层一层遍历完每个标签后，最终将得到一个客群为cust_1视图，这个视图里面的数据则为最终的客群信息。

从而通过该方式，能够更有效率地利用树状查询模型各节点的标签信息以及节点之间逻辑关系，确定与树状查询模型的查询任务对应的数据信息。

此外，参考图1所示，根据本实施例的第三个方面，提供了一种存储介质。存储介质包括存储的程序，其中，在程序运行时由处理器执行以上任意一项所述的方法。

从而通过本公开的实施例，通过树状结构标签的组织，客户能够表达标签的层级关系，例如要表达某段时间内累计消费金额则需要先添加一个交易时间标签，再在时间标签后面添加一个累计消费金额子标签，这样就能表达客户想要的是某段时间内的累计消费金额。并且通过树状结构，可以定义父子标签以及兄弟标签之间的逻辑关系(例如父节点和子节点之间为且的关系，兄弟节点之间可为且也可以为或，具体情况由客户指定)。进而解决了现有技术中存在的标签系统不能实现客户标签的定制化需求，并且只能通过固定的检索逻辑进行检索，从而无法实现客户自定义逻辑的客群的技术问题，目前尚未提出有效的解决方案。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

图7示出了根据本实施例所述的查询装置700，该装置700与根据实施例1的第一个方面所述的方法相对应。参考图7所示，该装置700包括：树状图形显示模块710，配置用于响应于用户在交互界面上进行的与查询任务相关的界面操作，在交互界面上显示与查询任务对应的树状图形，其中树状图形的节点组件用于表示与查询任务相关的标签信息；查询模型生成模块720，配置用于生成与树状图形对应的树状查询模型，其中树状查询模型的节点与树状图形的节点组件所表示的标签信息对应；以及查询模块730，配置用于根据树状查询模型的节点所对应的标签信息，进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息。

可选地，查询模块730，包括：第一节点数据信息确定子模块，用于确定与树状查询模型的各个节点对应的数据信息；以及数据信息确定子模块，用于根据树状查询模型的各个节点对应的数据信息以及树状查询模型的各个节点之间的逻辑关系，确定与查询任务对应的数据信息。

可选地，查询模块730，包括：第二节点数据信息确定子模块，用于从树状查询模型的层级最深的第三节点开始，根据各个节点对应的数据信息，确定与查询任务对应的数据信息。

可选地，第二节点数据信息确定子模块，包括：根节点确定单元，用于确定树状查询模型的根节点；以及节点数据信息确定单元，用于从根节点的子节点开始，逐层确定与树状查询模型的各个节点对应的数据信息。

可选地，节点数据信息确定单元，包括根据以下操作获取与查询任务相关的第一中间结果：第一中间结果获取子单元，用于从作为根节点的子节点的第一节点开始，沿树状查询模型的深度方向逐层对路径上的各个节点进行查询并确定与路径上的各个节点对应的数据信息，直到包含两个以上子节点的第二节点为止，停止对两个以上子节点进行查询，从而获取第一中间结果。

可选地，节点数据信息确定单元，包括根据以下操作获取与查询任务相关的第二中间结果：第二中间结果获取子单元，用于分别对两个以上子节点进行查询，从而获取分别与两个以上子节点对应的第二中间结果。

可选地，数据信息确定子模块，包括：数据信息确定子单元，用于从树状查询模型的层级最深的第三节点开始，根据各个节点对应的数据信息，确定与查询任务对应的数据信息。

从而通过本公开的实施例，通过树状结构标签的组织，客户能够表达标签的层级关系，例如要表达某段时间内累计消费金额则需要先添加一个交易时间标签，再在时间标签后面添加一个累计消费金额子标签，这样就能表达客户想要的是某段时间内的累计消费金额。并且通过树状结构，可以定义父子标签以及兄弟标签之间的逻辑关系(例如父节点和子节点之间为且的关系，兄弟节点之间可为且也可以为或，具体情况由客户指定)。

实施例3

图8示出了根据本实施例所述的查询装置800，该装置800与根据实施例1的第一个方面所述的方法相对应。参考图8所示，该装置800包括：处理器810；以及存储器820，与处理器810连接，用于为处理器810提供处理以下处理步骤的指令：响应于用户在交互界面上进行的与查询任务相关的界面操作，在交互界面上显示与查询任务对应的树状图形，其中树状图形的节点组件用于表示与查询任务相关的标签信息；生成与树状图形对应的树状查询模型，其中树状查询模型的节点与树状图形的节点组件所表示的标签信息对应；以及根据树状查询模型的节点所对应的标签信息，进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息。

可选地，根据树状查询模型进行与查询任务相关的查询操作，并确定与查询任务对应的数据信息的操作，包括：确定与树状查询模型的各个节点对应的数据信息；以及根据树状查询模型的各个节点对应的数据信息以及树状查询模型的各个节点之间的逻辑关系，确定与查询任务对应的数据信息。

可选地，确定与树状查询模型的各个节点对应的数据信息的操作，包括：通过广度优先算法遍历树状查询模型的各个节点，确定与树状查询模型的各个节点对应的数据信息。

可选地，确定与树状查询模型的各个节点对应的数据信息的操作，还包括：确定树状查询模型的根节点；以及从根节点的子节点开始，逐层确定与树状查询模型的各个节点对应的数据信息。

可选地，从根节点的子节点开始，逐层确定与树状查询模型的各个节点对应的数据信息的操作，包括根据以下操作获取与查询任务相关的第一中间结果：从作为根节点的子节点的第一节点开始，沿树状查询模型的深度方向逐层对路径上的各个节点进行查询并确定与路径上的各个节点对应的数据信息，直到包含两个以上子节点的第二节点为止，停止对两个以上子节点进行查询，从而获取第一中间结果。

可选地，从根节点的子节点开始，逐层确定与树状查询模型的各个节点对应的数据信息的操作，包括根据以下操作获取与查询任务相关的第二中间结果：分别对两个以上子节点进行查询，从而获取分别与两个以上子节点对应的第二中间结果。

可选地，根据树状查询模型的各个节点对应的数据信息以及树状查询模型的各个节点之间的逻辑关系，确定与查询任务对应的数据信息的操作，包括：从树状查询模型的层级最深的第三节点开始，根据各个节点对应的数据信息，确定与查询任务对应的数据信息。

从而根据本实施例，通过树状结构标签的组织，客户能够表达标签的层级关系，例如要表达某段时间内累计消费金额则需要先添加一个交易时间标签，再在时间标签后面添加一个累计消费金额子标签，这样就能表达客户想要的是某段时间内的累计消费金额。并且通过树状结构，可以定义父子标签以及兄弟标签之间的逻辑关系(例如父节点和子节点之间为且的关系，兄弟节点之间可为且也可以为或，具体情况由客户指定)。进而解决了现有技术中存在的标签系统不能实现客户标签的定制化需求，并且只能通过固定的检索逻辑进行检索，从而无法实现客户自定义逻辑的客群的技术问题，目前尚未提出有效的解决方案。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。