发明内容
有鉴于此,本申请提供了一种确定目标对象的方法、数据存储方法及对应装置,以便于提高确定目标对象的时效性。
本申请提供了如下方案:
根据第一方面,提供了一种确定目标对象的方法,包括:
获取确定目标对象的需求条件,所述需求条件包含第一匹配策略;
在数据仓库中查询与所述第一匹配策略对应的时间聚合窗口的聚合数据,得到满足所述第一匹配策略的对象;
利用满足所述第一匹配策略的对象确定目标对象;
其中,所述数据仓库中各时间聚合窗口的聚合数据是按照预设的时间聚合周期对各时间聚合窗口内获取的流式数据进行聚合处理后得到的,所述流式数据包括对象数据。
根据本申请实施例中一可实现的方式,所述预设时间聚合周期包括一个以上时长粒度的时间聚合周期;
分别按照各时间预设周期执行所述聚合处理,得到一个以上时长粒度的各时间聚合窗口的聚合数据。
根据本申请实施例中一可实现的方式,在所述存储仓库中,各时间聚合窗口的聚数据依据行键进行存储;
所述行键至少包括对象标识和聚合时间戳。
根据本申请实施例中一可实现的方式,所述第一匹配策略被配置为包含时间值、时间类型、运算符和标签条件的表达式;
在所述数据仓库中查询与所述第一匹配策略对应的时间聚合窗口的聚合数据,得到满足所述第一匹配策略的对象包括:
确定所述数据仓库中与所述时间类型和时间值匹配的时间聚合窗口,在该时间聚合窗口中确定与所述标签条件匹配的对象作为满足所述第一匹配策略的对象。
根据本申请实施例中一可实现的方式,所述需求条件包括多于一个的第一匹配策略以及所述多于一个的第一匹配策略之间的逻辑关系;所述利用满足所述第一匹配策略的对象确定目标对象包括:按照所述逻辑关系,对满足各第一匹配策略的对象进行逻辑处理,得到所述目标对象;或者,
所述需求条件还包含第二匹配策略以及第一匹配策略与第二匹配策略之间的逻辑关系;所述利用满足所述第一匹配策略的对象确定目标对象包括:在所述数据仓库的离线数据中查询与所述第二匹配策略相匹配的对象;按照所述逻辑关系,对满足所述第一匹配策略的对象和与所述第二匹配策略相匹配的对象进行逻辑处理,得到所述目标对象。
根据本申请实施例中一可实现的方式,所述方法应用于用户促活场景,所述对象数据包括用户行为数据,所述目标对象为促活的目标用户。
根据本申请实施例中一可实现的方式,获取到用户访问目标资源的事件后,执行所述获取确定目标对象的需求条件的步骤;
依据预设的对象圈选周期,执行所述在数据仓库中查询与所述第一匹配策略对应的时间聚合窗口的聚合数据的步骤;
所述方法还包括:若确定所述用户为目标用户,则依据预设的促活策略向所述用户推送促活信息。
根据第二方面,提供了一种数据存储方法,包括:
获取包含对象数据的流式数据;
按照预设时间聚合周期对当前时间聚合窗口内获取的对象数据进行聚合处理,得到各时间聚合窗口的聚合数据并存储于数据仓库。
根据本申请实施例中一可实现的方式,所述预设时间聚合周期包括一个以上时长粒度的时间聚合周期;
分别按照各时间预设周期执行所述聚合处理,得到一个以上时长粒度的各时间聚合窗口的聚合数据。
根据本申请实施例中一可实现的方式,在所述存储仓库中,各时间聚合窗口的聚数据依据行键进行存储;
所述行键至少包括对象标识和聚合时间戳。
根据第三方面,提供了一种确定目标对象的装置,包括:
条件获取单元,被配置为获取确定目标对象的需求条件,所述需求条件包含第一匹配策略;
数据查询单元,被配置为在数据仓库中查询与所述第一匹配策略对应的时间聚合窗口的聚合数据,得到满足所述第一匹配策略的对象;
对象确定单元,被配置为利用满足所述第一匹配策略的对象确定目标对象;
其中,所述数据仓库中各时间聚合窗口的聚合数据是按照预设的时间聚合周期对各时间聚合窗口内获取的流式数据进行聚合处理后得到的,所述流式数据包括对象数据。
根据第四方面,提供了一种数据存储装置,包括:
数据获取单元,被配置为获取包含对象数据的流式数据;
聚合存储单元,被配置为按照预设时间聚合周期对当前时间聚合窗口内获取的对象数据进行聚合处理,得到各时间聚合窗口的聚合数据并存储于数据仓库。
根据第五方面,提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述第一方面和第二方面中任一项所述的方法的步骤。
根据第六方面,提供了一种电子设备,其特征在于,包括:
一个或多个处理器;以及
与所述一个或多个处理器关联的存储器,所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行上述第一方面和第二方面中任一项所述的方法的步骤。
根据本申请提供的具体实施例,本申请公开了以下技术效果:
本申请实施例中数据仓库存储的聚合数据一方面是由实时的流式数据得来,另一方面对实时的流式数据按照预设的时间聚合周期对时间聚合窗口内的流式数据进行聚合处理后,将各时间聚合窗口的聚合数据存储于数据仓库,以方便能够依据需求条件中的第一匹配策略快速查询对应时间聚合窗口的对象数据,从而提高确定目标对象的时效性。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本申请保护的范围。
在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。
应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地,取决于语境,短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
图1示出了可以应用本申请实施例的示例性系统架构。如图1中所示,该系统架构主要包括:服务层设备110、数据仓库120、计算层设备130和运营配置平台140。
其中,服务层设备110主要负责从运营配置平台140获取确定目标对象的需求条件,服务层设备110依据该需求条件从数据仓库中确定哪些对象为目标对象。
运营配置平台140具备对目标对象的需求条件进行配置,对象的管理、标签的生产等功能。
计算层设备130负责获取实时的对象数据和/或离线的对象数据,对获取的对象数据进行处理后存储于数据仓库。
数据仓库120用以存储对象数据,在本申请实施例中可以将对实时的对象数据和离线的对象数据进行分开存储,例如将实时的对象数据存储于Hbase数据库,将离线的对象数据存储于离线数据库。
服务层设备110在确定出目标对象后,可以提供给业务层设备实现具体的服务。业务层设备面向用户,向用户提供具体的服务。
需要说明的是,上述服务层设备110、数据仓库120、计算层设备130和运营配置平台140可以设置于服务器端,可以分别独立设置于不同的服务器或服务器集群,其中的部分或全部也可以设置于相同的服务器或服务器集群。
图2为本申请实施例提供的确定目标对象的方法流程图,该方法基于图1所示系统实现,如图2中所示,该方法包括以下步骤:
步骤202:获取确定目标对象的需求条件,该需求条件包含第一匹配策略。
通常在确定目标对象时需要一定的需求条件,即满足该需求条件的对象被认为是目标对象。需求条件中可以包含多个匹配策略,本实施例中以提高时效性为目的,因此可以认为第一匹配策略是具有较高时效性要求的匹配策略,例如2小时内访问5个商品,再例如30分钟内访问母婴类目,等等。
步骤204:在数据仓库中查询与第一匹配策略对应的时间聚合窗口的聚合数据,得到满足第一匹配策略的对象。其中,数据仓库中各时间聚合窗口的聚合数据是按照预设的时间聚合周期对各时间聚合窗口内获取的流式数据进行聚合处理后得到的,该流式数据包括对象数据。
步骤206:利用满足上述第一匹配策略的对象确定目标对象。
可以看出,上述流程中数据仓库中存储的聚合数据一方面是由实时的流式数据得来,另一方面对实时的流式数据按照预设的时间聚合周期对时间聚合窗口内的流式数据进行聚合处理后,将各时间聚合窗口的聚合数据存储于数据仓库,以方便能够依据需求条件中的第一匹配策略快速查询对应时间聚合窗口的对象数据,从而提高确定目标对象的时效性。
本申请实施例中所涉及的对象可以是诸如用户、商品、企业等多种类型的对象,对象数据也可以是诸如用户行为数据、商品属性数据、企业行为数据等等。作为一种典型的应用场景,本申请实施例所提供的技术方案可以应用于用户促活场景,即依据预设的促活需求条件来识别促活的目标用户,该场景下使用的对象数据主要是用户行为数据,即依据用户行为数据来确定符合预设促活需求条件的用户,并依据预设的促活策略对这些用户推送促活信息。为了方便理解,后续均以该典型的应用场景为例。
下面结合实施例分别对上述各步骤进行详细描述。在本申请实施例中,对流式数据进行的聚合处理并存储于数据仓库可以由图1所示系统中的计算层设备130执行,该处理是实时的且不断执行的。为了方便理解,首先对该部分处理进行详细描述。
作为一种可实现的方式,可以首先在计算层执行如图3中所示的数据存储流程,包括以下步骤:
步骤302:获取包含对象数据的流式数据。
步骤304:按照预设时间聚合周期对当前时间聚合窗口内获取的对象数据进行聚合处理,得到当前时间聚合窗口的聚合数据并存储于数据仓库。
图3所示处理可以由诸如Blink等数据流式处理引擎执行。诸如Blink等数据流式处理引擎可以对获取到的海量的对象数据进行实时、流畅地处理。
上述的时间聚合周期可以采用较短的时间周期以满足时效性要求,例如分钟级别的聚合周期、小时级别的聚合周期。如果没有较高的时效性要求,则可以采用诸如天级别的聚合周期。如果具有更高的时效性要求,甚至可以采用秒级别的聚合周期。
举个例子,实时获取包含用户行为数据的流式数据,然后以5分钟为一个时间聚合周期,每5分钟都对该5分钟的时间聚合窗口内的用户行为数据进行聚合处理,并将该5分钟的聚合数据存储于数据仓库。
在对用户行为数据进行聚合处理的过程中可以依据图1所示系统中运营配置平台140生产的标签,对用户行为数据进行标注处理。该标签可以是反映用户行为的相关属性的,例如行为类型。利用标签对用户行为数据进行标注处理是为了方便后续在数据仓库中查询时能够快速实现第一匹配策略与用户行为数据的匹配。该查询匹配的部分将在后续实施例中详述。
另外,数据仓库中存储聚合数据时,会存储聚合数据对应的时间聚合窗口的信息。例如采用一些时间戳来标识时间聚合窗口,以方便后续查询。
上述各时间聚合窗口对应的聚合数据可以存储于诸如Hbase等分布式数据库。在诸如Hbase等分布式数据库通常是分布式的、面向列的数据库,它和一般关系型数据库的最大区别是:适合于存储非结构化的数据,还有就是它基于列的而不是基于行的模式。以HBase为例,其采用KeyValue(键值)的列存储。Rowkey(行键)就是KeyValue的Key,表示唯一一行。Rowkey可以由用户自定义。数据加载时,一般也是根据Rowkey的二进制序由小到大进行的。另外,HBase是根据Rowkey来进行检索的,通过找到某个Rowkey(或者某个Rowkey范围)所在的Region(区域),然后将查询数据的请求路由到该Region获取数据。
在本申请实施例中,各时间聚合窗口的聚合数据在Hbase中进行存储时,同样依据Rowkey进行存储。其中可以定义Rowkey是找包括对象标识和聚合时间戳。以确定促活的目标用户的应用场景为例,可以涉及Rowkey诸如“账户ID散列-账户类型-账户ID-聚合时间戳”。其中,散列是把任意长度的输入(本实施例指的是账户ID)通过散列算法变换成固定长度的输出,该输出就是散列值。这种转换是一种压缩映射,散列值的空间通常远小于输入的空间,简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要。其中,账户类型可以包括诸如设备ID、Cookie、客户端ID、用户名等类型。
上述预设时间聚合周期可以采用统一的时长粒度,例如均采用5分钟为一个时间聚合周期,时间聚合窗口为5分钟。
但作为一种更有选的实施方式,可以采用多于一个的时长粒度。例如,采用多种分钟粒度的时间聚合周期以及小时粒度的时间聚合周期。例如,每10分钟对当前10分钟时间聚合窗口内的用户行为数据进行聚合处理,并在数据仓库中存储各10分钟的时间聚合窗口的聚合数据。与此同时,每小时对当前1小时时间聚合窗口内的用户行为数据进行聚合处理,并在数据仓库中存储各小时的时间聚合窗口的聚合数据。这种多时长粒度的时间聚合窗口,能够提高查询性能,降低服务调用中网络请求的IO(读写)次数。例如,要查询2022年4月1日12点~13点访问过母婴类目的用户,则仅需要以小时为时长粒度,查询12点~13点对应的时间聚合窗口的聚合数据即可。而不必查询分钟粒度的时间聚合窗口后再进行计算,显然降低了IO次数,提高了查询性能。
采用多时长粒度的时间聚合窗口,例如采用分钟粒度和小时粒度,用户查询Hbase一次最多返回60条数据。若仅分钟粒度汇总,则用户查询Hbase一次最多返回1440条数据。显然提高了查询性能。
对于各时间聚合窗口内的用户行为数据实际上是基于标签进行标注处理的,这些标签从整体上对用户进行了描述,可以看做是形成了各时间聚合窗口的用户画像数据。进行聚合处理时,除了依据时间聚合窗口进行聚合存储之外,在时间聚合窗口内可以进一步基于标签类型进行聚合,将具有相同标签类型的对象数据进行聚合。例如,将访问数据进行聚合,将点击数据进行聚合,将曝光数据进行聚合等等。
下面结合实施例对上述步骤202即“获取确定目标对象的需求条件,该需求条件包含第一匹配策略”进行详细描述。
需求条件中可以包含多个匹配策略,本实施例中以提高时效性为目的,因此可以认为第一匹配策略是具有较高时效性要求的匹配策略,例如2小时内访问5个商品,再例如30分钟内访问母婴类目,等等。
作为一种可实现的方式,本申请实施例中可以将第一匹配策略配置为包含时间值、时间类型、运算符和标签条件的表达式。其中标签条件可以至少包括标签类型(可以采用标签名体现)和运算符,还可以进一步包括标签期望值。例如,可以将第一匹配策略定义为如下表达:
[时间值][时间类型][标签名][运算符][标签期望值]
其中,上述时间值、时间类型的特殊配置是为了满足时间聚合窗口的动态的数据聚合操作。运算符可以是诸如包含运算符、不包含运算符、数值计算、IN(用来判断一个对象指定的属性是否在该对象或其原型链上)等。
以第一匹配策略“两小时内浏览5个商品详情页”为例,假设当前时间为2022年4月1日13点,则该第一匹配策略可以表达为:
[2022040111][2小时][PV][>=][5]
其中,“2022040111”是时间聚合窗口的起始时间,“2小时”是时间聚合窗口的时间类型,即以2小时为时长,“PV”是标签名,即浏览页面行为,“>=”是运算符,“5”是DVP的期望值。
在一些场景下,确定目标对象的需求条件可以包含多个第一匹配策略,或者除了第一匹配策略之外还同时包含第二匹配策略。其中第二匹配策略主要用以进行离线数据的查询匹配。这些场景下,对第一匹配策略按照上述方式进行表达获得表达式后,可以进一步包含多个第一匹配策略之间的逻辑关系,或者第一匹配策略与第二匹配策略之间的逻辑关系。
上述的逻辑关系可以包括:取交集、取并集、取差集等处理,简称为交并差逻辑算子。
下面结合实施例对上述步骤204即“在数据仓库中查询与第一匹配策略对应的时间聚合窗口的聚合数据,得到满足第一匹配策略的对象”进行详细描述。
在本步骤中,在数据仓库中查询与第一匹配策略对应的时间聚合窗口的聚合数据,得到满足第一匹配策略的对象。作为一种可实现的方式,可以基于上述第一匹配策略的表达式,确定与第一匹配策略的时间类型对应的时间聚合窗口。在这些时间聚合窗口中进一步确定第一匹配策略的表达式中时间值对应的时间聚合窗口,在该时间聚合窗口的聚合数据中与第一匹配策略的标签条件进行查询匹配,将查询匹配到的对象作为满足第一匹配策略的对象。
以上述第一匹配策略“两小时内浏览5个商品详情页”为例,其表达式为[2022040111][2小时][PV][>=][5]。首先在Hbase中确定时长粒度为2小时的时间聚合窗口。若不存在2小时的时间聚合窗口,而是仅存在1小时的时间聚合窗口,则可以确定1小时的时间聚合窗口后续进行合并查询。然后再确定2022040111对应的2小时的时间聚合窗口,在该时间聚合窗口中的聚合数据中查询,获取所有浏览商品详情页的数据;再从中确定浏览商品详情页数量大于或等于5的账户ID作为满足第一匹配策略的用户。
下面结合实施例对上述步骤206即“利用满足上述第一匹配策略的对象确定目标对象”进行描述。
若确定目标对象的需求条件仅包括一个第一匹配策略,则直接将满足该第一匹配策略的对象确定为目标对象。
若确定目标对象的需求条件包括多于一个的第一匹配策略以及多于一个的第一匹配策略之间的逻辑关系,则可以按照该逻辑关系,对满足各第一匹配策略的对象进行逻辑处理,得到目标对象。
例如,若确定目标对象的需求条件为:“两小时内浏览5个商品详情页”且“10分钟内访问母婴类目”这两个第一匹配策略,两个第一匹配策略之间的逻辑关系为“取交集”,则可以分别确定出满足“两小时内浏览5个商品详情页”的对象构成的第一对象集合和满足“10分钟内访问母婴类目”的对象构成的第二对象集合后,将第一对象集合和第二对象集合取交集,得到目标对象。
若需求条件除了包含第一匹配策略之外,还包含第二匹配策略以及第一匹配策略与第二匹配策略之间的逻辑关系,则在步骤206之前,在数据仓库的离线数据中查询与第二匹配策略相匹配的对象。然后在步骤206中,按照第一匹配策略与第二匹配策略之间的逻辑关系,对满足第一匹配策略的对象和与第二匹配策略相匹配的对象进行逻辑处理,得到目标对象。
其中,数据仓库中的离线数据是目前传统的技术实现,在此不做详细描述,其存储的数据是“批式(batch)数据”,通常是每隔较长一段时间进行一次收集和更新,是历史数据。例如每周在数据仓库中更新一次离线数据,每三天在数据仓库中更新一次离线数据。并且,其数据来源也并非流式数据,在离线数据中也并没有时间聚合窗口和聚合数据的概念。
举个例子,若确定目标对象的需求条件为:“10分钟内访问母婴类目”且“三天内新注册用户”。其中,“10分钟内访问母婴类目”为第一匹配策略,具有很高的时效性要求,需要查询Hbase数据库。“三天内新注册用户”为第二匹配策略,对时效性要求低,需要查询离线数据。第一匹配策略和第二匹配策略之间的逻辑关系为“取交集”。则可以分别确定出满足“10分钟内访问母婴类目”的第一对象集合和满足“三天内新注册用户”的第二对象集合,将第一对象集合和第二对象集合取交集,得到目标对象。可以看出,通过上述方式能够实现“实时+离线”组合式的目标对象圈选。
在通过上述流程获取到目标对象后,就能够基于预设的服务层策略针对目标对象进行相应的服务。以确定促活用户为例,就能够依据预设的促活策略向用户推送促活信息。其中,促活信息可以是一些推广信息、优惠券等等来促进用户活跃。
另外,本申请中除了针对目标用户进行统一促活之外,还可以采用针对各用户分别判断是否为目标用户并进行错时促活(即错开促活的时间)的方式。该大致过程可以如图4中所示,包括以下步骤:
步骤402:获取到用户访问目标资源的事件。
其中目标资源可以是一个应用、一个页面、一个系统等等。例如,获取到用户访问目标应用后,开始执行步骤404持续关注用户的账户ID。
步骤404:持续关注该用户的账户ID。
本不会走中持续关注该用户的账户ID指的是,基于该账户ID进行是否为促活用户的识别。
步骤406:获取确定促活用户的需求条件,遍历各第一匹配策略。
步骤408:在数据仓库的Hbase中查询与当前遍历到的第一匹配策略对应的时间聚合窗口的聚合数据,得到满足当前遍历到的第一匹配策略的用户。
步骤410:判断是否遍历完毕,如果是,执行步骤412;否则,遍历下一个第一匹配策略,转至执行步骤408。
步骤412:将满足各第一匹配策略的用户依据需求条件中的逻辑关系进行逻辑处理,得到最终的促活用户。
步骤414:判断该用户是否为促活用户,如果是,执行步骤416;否则,继续关注该用户的账户ID,转至执行步骤404。
步骤416:通知服务层该用户为促活用户,在服务层依据促活策略向该用户推送促活信息。
其中对服务层的通知可以通过诸如MetaQ(MetaQ为一种消息中间件)消息下发,通过上述流程可以保证对用户的促活精确到分钟级的时效性,从而实现对用户的精细化促活。另外,由于对目标对象的识别是在由用户访问目标资源的事件触发的,鉴于各用户访问目标资源的时间不同,因此可以实现针对各用户进行错时促活。
下面在以图5为例对本申请实施例所提供方式体现在系统各层面上的内容进行描述,以圈选目标用户为例。如图5中所示,基础数据包括离线数据和实时数据。其中离线数据用以提供给计算层的ODPS(Open Data Processing Service,开放数据处理服务)数据任务来构建离线画像,并存储于数据仓库中诸如ODPS数据库。实时数据由计算层的Blink流计算任务依据预设的时间聚合周期实时对当前时间聚合窗口的用户行为数据进行聚合处理,得到当前时间聚合窗口的聚合数据,并存储于数据仓库的Hbase中,来构建实时画像。其中,Blink流计算任务在对用户行为数据进行聚合处理时,依据运营配置平台生产的标签对用户行为数据进行标注后,将当前时间聚合窗口内的用户行为数据依据标签进行聚合处理。
作为一种可实现的方式,Hbase中存储的实时画像是诸如小时、分钟等较小时长粒度的时间窗口的聚合数据,用以满足高时效性的查询需求。而离线画像中是较长时间的用户行为数据,通常是天级别、周级别甚至月级别。
运营配置平台负责对用户进行管理且负责目标用户的需求配置(用户圈选配置),即配置确定目标用户的需求条件,供服务层调用。服务层主要负责目标用户的确定,即依据确定目标对象的需求条件,查询数据仓库从而得到目标用户。其中,服务器层在确定目标用户时,可以根据需求条件查询Hbase数据库,或者查询Hbase和离线数据库,将查询得到的用户进行逻辑处理后得到目标用户,该部分的具体处理参见本申请之前各实施例中的相关记载,不再赘述。
服务层将确定出的目标用户信息提供给业务层,由业务层基于预设的策略向目标用户提供服务。例如可以应用于诸如触达场景、营销导购、搜索推荐,等等。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
根据另一方面的实施例,提供了一种确定目标对象的装置。图6示出根据一个实施例的该确定目标对象的装置的示意性框图。如图6所示,该装置600包括:条件获取单元601、数据查询单元602和对象确定单元603,还可以进一步包括服务提供单元604。其中,各组成单元的主要功能如下:
条件获取单元601,被配置为获取确定目标对象的需求条件,需求条件包含第一匹配策略。
数据查询单元602,被配置为在数据仓库中查询与第一匹配策略对应的时间聚合窗口的聚合数据,得到满足第一匹配策略的对象。
对象确定单元603,被配置为利用满足第一匹配策略的对象确定目标对象。
服务提供单元604被配置为基于预设的服务策略,对对象确定单元603确定的目标对象提供服务。
其中,数据仓库中各时间聚合窗口的聚合数据是按照预设的时间聚合周期对各时间聚合窗口内获取的流式数据进行聚合处理后得到的,流式数据包括对象数据。
作为其中一种优选的实施方式,上述预设时间聚合周期包括一个以上时长粒度的时间聚合周期。其中,上述时长粒度通常为较短的时长,例如小时、分钟、甚至秒级别。
作为一种可实现的方式,在存储仓库中,各时间聚合窗口的聚数据依据行键进行存储;行键至少包括对象标识和聚合时间戳。
作为一种可实现的方式,第一匹配策略可以被配置为包含时间值、时间类型、运算符和标签条件的表达式。其中标签条件可以至少包括标签类型(可以采用标签名体现)和运算符,还可以进一步包括标签期望值。运算符可以是诸如包含运算符、不包含运算符、数值计算、IN等。
数据查询单元602可以具体被配置为确定数据仓库中与时间类型和时间值匹配的时间聚合窗口,在该时间聚合窗口中确定与标签条件匹配的对象作为满足第一匹配策略的对象。
作为其中一种可实现的方式,上述需求条件可以包括多于一个的第一匹配策略以及多于一个的第一匹配策略之间的逻辑关系。这种情况下,对象确定单元603可以按照逻辑关系,对满足各第一匹配策略的对象进行逻辑处理,得到目标对象。
作为另一种可实现的方式,需求条件还包含第二匹配策略以及第一匹配策略与第二匹配策略之间的逻辑关系。这种情况下,对象确定单元603在数据仓库的离线数据中查询与第二匹配策略相匹配的对象;按照逻辑关系,对满足第一匹配策略的对象和与第二匹配策略相匹配的对象进行逻辑处理,得到目标对象。
上述的逻辑关系可以包括:取交集、取并集、取差集等处理。
其中,上述条件获取单元601、数据查询单元602和对象确定单元603可以设置于图1所示系统的服务层设备110中,服务提供单元604可以设置于图1所示系统的业务层设备。
作为一种典型的应用场景,该装置可以应用于用户促活场景,对象数据可以包括用户行为数据,目标对象可以为促活的目标用户。
条件获取单元601获取到用户访问目标资源的事件后,执行获取确定目标对象的需求条件的处理。数据查询单元602依据预设的对象圈选周期,执行在数据仓库中查询与第一匹配策略对应的时间聚合窗口的聚合数据的处理。
服务提供单元604被配置为若对象确定单元603确定用户为目标用户,则依据预设的促活策略向用户推送促活信息。
根据另一方面的实施例,提供了一种数据存储装置。图7示出根据一个实施例的该数据存储装置的示意性框图。如图7所示,该装置700包括:数据获取单元701和聚合存储单元702。其中,各组成单元的主要功能如下:
数据获取单元701,被配置为获取包含对象数据的流式数据。
聚合存储单元702,被配置为按照预设时间聚合周期对当前时间聚合窗口内获取的对象数据进行聚合处理,得到各时间聚合窗口的聚合数据并存储于数据仓库。
上述的时间聚合周期可以采用较短的时间周期以满足时效性要求,例如分钟级别的聚合周期、小时级别的聚合周期。
作为一种可实现的方式,上述预设时间聚合周期可以包括一个以上时长粒度的时间聚合周期。这种多时长粒度的时间聚合窗口,能够提高查询性能,降低服务调用中网络请求的IO(读写)次数。
相应地,聚合存储单元702分别按照各时间预设周期执行聚合处理,得到一个以上时长粒度的各时间聚合窗口的聚合数据。
作为一种可实现的方式,在存储仓库中,各时间聚合窗口的聚数据依据Rowkey进行存储;Rowkey至少包括对象标识和聚合时间戳。
聚合存储单元702进行聚合处理时,可以基于标签类型进行聚合,将具有相同标签类型的对象数据进行聚合。例如,将访问数据进行聚合,将点击数据进行聚合,将曝光数据进行聚合等等。
数据获取单元701和聚合存储单元702可以设置于图1所示系统的计算层设备130中。
需要说明的是,本申请实施例中可能会涉及到对用户数据的使用,在实际应用中,可以在符合所在国的适用法律法规要求的情况下(例如,用户明确同意,对用户切实通知,等),在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。
由以上实施例所提供的方法和装置可以具备以下优点:
1)本申请实施例中数据仓库存储的聚合数据一方面是由实时的流式数据得来,另一方面对实时的流式数据按照预设的时间聚合周期对时间聚合窗口内的流式数据进行聚合处理后,将各时间聚合窗口的聚合数据存储于数据仓库,以方便能够依据需求条件中的第一匹配策略快速查询对应时间聚合窗口的对象数据,从而提高确定目标对象的时效性。
2)本申请实施例中时间聚合周期可以依据实际需求进行定义,并且可以采用多种时长粒度的时间聚合窗口,能够提高查询性能,降低服务调用中网络请求的IO(读写)次数。
3)本申请实施例提供了结合实时数据和离线数据进行目标对象确定的方案,实现离线和实时组合的灵活配置,即实现了基于流批一体的目标对象确定,提升了目标对象的确定效率。在应用于促活用户的圈选场景时,能够显著提升服务的UV(Unique Visitors,独立访客)渗透率。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
另外,本申请实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。
以及一种电子设备,包括:
一个或多个处理器;以及
与所述一个或多个处理器关联的存储器,所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行前述方法实施例中任一项所述的方法的步骤。
其中,图8示例性的展示出了电子设备的架构,具体可以包括处理器810,视频显示适配器811,磁盘驱动器812,输入/输出接口813,网络接口814,以及存储器820。上述处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814,与存储器820之间可以通过通信总线830进行通信连接。
其中,处理器810可以采用通用的CPU、微处理器、应用专用集成电路(ApplicationSpecific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本申请所提供的技术方案。
存储器820可以采用ROM(Read Only Memory,只读存储器)、RAM(RandomAccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器820可以存储用于控制电子设备800运行的操作系统821,用于控制电子设备800的低级别操作的基本输入输出系统(BIOS)822。另外,还可以存储网页浏览器823,数据存储管理系统824,以及确定目标对象的装置/数据存储装置825等等。上述目标对象的装置/数据存储装置825就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之,在通过软件或者固件来实现本申请所提供的技术方案时,相关的程序代码保存在存储器820中,并由处理器810来调用执行。
输入/输出接口813用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
网络接口814用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线830包括一通路,在设备的各个组件(例如处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814,与存储器820)之间传输信息。
需要说明的是,尽管上述设备仅示出了处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814,存储器820,总线830等,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本申请方案所必需的组件,而不必包含图中所示的全部组件。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统或系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上对本申请所提供的技术方案进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本申请的限制。