基于流式数据处理的用户标签获取方法及装置

技术领域

本发明涉及大数据的数据分析技术领域，尤其涉及一种基于流式数据处理的用户标签获取方法、装置、计算机设备及存储介质。

背景技术

用户兴趣挖掘是现今互联网用户端产品非常重要的基础技术手段，结合采集到的用户行为数据，运用不同的技术手段去表达用户信息以满足不同的产品需求，如广告投放、信息流推荐、小视频推荐等等，不同的技术实现方案对兴趣标签的准确性和时效性有不同侧重。

传统的用户兴趣挖掘，更倾向于刻画出长期稳定的用户兴趣，而难以捕捉即时用户行为带来的兴趣变化。

现阶段，业内出现同样有对用户兴趣的近实时刻画，但是缺乏对整体架构系统的设计，程序稳定性，数据一致性，计算性能等全方面考虑。

发明内容

本发明实施例提供了一种基于流式数据处理的用户标签获取方法、装置、计算机设备及存储介质，旨在解决现有技术中传统的用户兴趣挖掘，更倾向于刻画出长期稳定的用户兴趣，而难以捕捉即时用户行为带来的兴趣变化，导致分析结果准确率降低的问题。

第一方面，本发明实施例提供了一种基于流式数据处理的用户标签获取方法，其包括：

获取当前系统时间，判断所述当前系统时间是否满足标签离线更新流程启动条件；其中，所述标签离线更新流程启动条件对应一个标签离线更新流程启动时间点；

若所述当前系统时间满足所述标签离线更新流程启动条件，获取Hive数据库中已存储的当前用户数据集；

将根据所述当前用户数据集及调用对应的离线标签更新策略，计算得到与所述当前用户数据集中各用户分别对应的当前用户标签集，并获取和存储当前用户标签集对应的当前更新标识时间；

将所述各用户分别对应的当前用户标签集存储至HBase数据库和/或Redis数据库；

若所述当前系统时间不满足所述标签离线更新流程启动条件，消费Kafka平台中的实时用户数据集；以及

根据所述实时用户数据集及调用对应的在线标签更新策略，得到与所述实时用户数据集中各用户分别对应的实时用户标签集。

第二方面，本发明实施例提供了一种基于流式数据处理的用户标签获取装置，其包括：

流程启动判断单元，用于获取当前系统时间，判断所述当前系统时间是否满足标签离线更新流程启动条件；其中，所述标签离线更新流程启动条件对应一个标签离线更新流程启动时间点；

离线流程启动单元，用于若所述当前系统时间满足所述标签离线更新流程启动条件，获取Hive数据库中已存储的当前用户数据集；

离线标签更新单元，用于将根据所述当前用户数据集及调用对应的离线标签更新策略，计算得到与所述当前用户数据集中各用户分别对应的当前用户标签集，并获取和存储当前用户标签集对应的当前更新标识时间；

标签集存储单元，用于将所述各用户分别对应的当前用户标签集存储至HBase数据库和/或Redis数据库；

在线流程启动单元，用于若所述当前系统时间不满足所述标签离线更新流程启动条件，消费Kafka平台中的实时用户数据集；以及

在线标签更新单元，用于根据所述实时用户数据集及调用对应的在线标签更新策略，得到与所述实时用户数据集中各用户分别对应的实时用户标签集。

第三方面，本发明实施例又提供了一种计算机设备，其包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的基于流式数据处理的用户标签获取方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其中所述计算机可读存储介质存储有计算机程序，所述计算机程序当被处理器执行时使所述处理器执行上述第一方面所述的基于流式数据处理的用户标签获取方法。

本发明实施例提供了一种基于流式数据处理的用户标签获取方法、装置、计算机设备及存储介质，通过利用流式计算框架和在线存储数据库，不仅能够在指定时间段启动离线流程基于当前用户数据集更新标签，而且也能在其他非离线更新标签时间段秒级捕捉用户的行为数据，根据实时变化的数据做出相应的标签更新，提高了用户兴趣挖掘结果的准确性。

附图说明

为了更清楚地说明本发明实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的基于流式数据处理的用户标签获取方法的应用场景示意图；

图2为本发明实施例提供的基于流式数据处理的用户标签获取方法的流程示意图；

图3为本发明实施例提供的基于流式数据处理的用户标签获取装置的示意性框图；

图4为本发明实施例提供的计算机设备的示意性框图。

具体实施方式

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

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

请参阅图1和图2，图1为本发明实施例提供的基于流式数据处理的用户标签获取方法的应用场景示意图；图2为本发明实施例提供的基于流式数据处理的用户标签获取方法的流程示意图，该基于流式数据处理的用户标签获取方法应用于服务器中，该方法通过安装于服务器中的应用软件进行执行。

如图2所示，该方法包括步骤S101～S106。

S101、获取当前系统时间，判断所述当前系统时间是否满足标签离线更新流程启动条件；其中，所述标签离线更新流程启动条件对应一个标签离线更新流程启动时间点。

在本实施例中，为了更清楚的理解本申请的技术方案，下面对所涉及的终端进行详细介绍。本申请是在服务器的角度描述技术方案。其中，本申请的技术方案的应用场景是服务器根据用户对目标应用程序中各信息的访问和点击行为产生的用户数据进行用户兴趣标签的挖掘。

第一是服务器，本申请中的服务器可以理解为服务器集群，其中部署有Spark计算引擎、Streaming流式计算引擎、Hive数据库、HBase数据库、Redis数据库、Kafka平台。也即通过服务器可以根据用户对目标应用程序中各信息的访问和点击行为产生的用户数据进行用户兴趣标签的挖掘。

第二是接收端，服务器分析并挖掘得到的用户标签，可以及时的发送至接收端进行具体应用，例如根据接收端根据用户标签进行信息推送。

在服务器中获取当前系统时间，判断所述当前系统时间是否满足标签离线更新流程启动条件；其中，所述标签离线更新流程启动条件对应一个标签离线更新流程启动时间点，例如将签离线更新流程启动条件设置为每日0点之后启动标签离线更新流程(更具体如每日00:01开始启动标签离线更新流程)，一旦启动标签离线更新流程后，启动标签在线更新流程是禁止启动的，从而有效确保标签数据更新的准确性。

S102、若所述当前系统时间满足所述标签离线更新流程启动条件，获取Hive数据库中已存储的当前用户数据集。

在本实施例中，若当前流程启动条件(例如当前系统时间是00:01)满足标签离线更新流程启动条件，此时服务器中的Spark计算引擎从Hive数据库中获取前一日的当前用户数据集。其中，当前用户数据集可以理解为由前一日各用户对目标应用程序的访问和点击行为产生的用户数据而组成，也可以理解为一种按日统计的用户点击曝光增量数据。

由于用户在前一日打开目标应用程序所访问或点击每一条信息均会产生对应的用户数据(即每一条信息中均内置设置了标签，用户在当日点击了这一信息会产生针该用户对该标签在当日的点击量和曝光次数)，这些用户数据都会存储在服务器的Hive数据库中。若启动了标签离线更新流程，此时服务器是由Spark计算引擎先从Hive数据库中获取已存储的当前用户数据集。

S103、根据所述当前用户数据集及调用对应的离线标签更新策略，计算得到与所述当前用户数据集中各用户分别对应的当前用户标签集，并获取和存储当前用户标签集对应的当前更新标识时间。

在本实施例中，当由Spark计算引擎先从Hive数据库中获取已存储的当前用户数据集之后，在Spark计算引擎中根据所述当前用户数据集及调用对应的离线标签更新策略，计算得到与所述当前用户数据集中各用户分别对应的当前用户标签集。

其中，离线标签更新策略对应的计算公式如下公式(1)和公式(2)：

score_new

其中，score

在一实施例中，步骤S103包括：

获取所述当前用户数据集中各用户分别对应的初始用户标签集；

根据所述离线标签更新策略中的第一离线标签更新子策略及所述当前用户数据集中各用户分别对应的初始用户标签集，计算获取每一个初始用户标签集中各标签对应的累计点击量产生标签得分；

其中，所述第一离线标签更新子策略对应公式为：

根据离线标签更新策略中的第二离线标签更新子策略及所述初始用户数据集中各标签对应的累计点击量产生标签得分，计算获取每一个初始用户标签集中各标签对应的当日最终得分；

其中，所述第二离线标签更新子策略对应公式为：

score_new

将每一个初始用户标签集中各标签按分别对应的当日最终得分进行降序排序，并根据各标签的排名值筛选获取排名值未超出预设的排名阈值的标签，组成各用户分别对应的当前用户标签集。

其中，所述获取所述当前用户数据集中各用户分别对应的初始用户标签集包括：

根据所述当前用户数据集中各条用户数据分别对应的用户唯一识别标签进行用户数据分组，将同一用户的用户数据划分在同一数据组内；

根据各用户对应数据组统计得到对应的初始用户标签集。

在本实施例中，当启动了标签离线更新流程并从Hive数据库中获取前一日的当前用户数据集后，先是根据各条用户数据分别对应的用户唯一识别标签进行用户数据分组，以将同一用户的用户数据分在同一数据组内，之后可以根据各用户对应数据组统计得到对应的初始用户标签集。

例如，用户1在前一日打开目标应用程序所访问或点击信息而产生对应的初始用户标签集中包括标签1、标签2、标签3、标签4、标签5、标签6、标签7、标签8。且上述标签1-标签8中每一标签均对应有累计点击量和累计曝光次数，这样即可上述公式(1)和公式(2)分别计算获取各用户对应的当前用户标签集。若用户1在前一日针对标签1的信息点击而得到的当日最终得分为S1，用户1在前一日针对标签2的信息点击而得到的当日最终得分为S2，用户1在前一日针对标签3的信息点击而得到的当日最终得分为S3，用户1在前一日针对标签4的信息点击而得到的当日最终得分为S4，用户1在前一日针对标签5的信息点击而得到的当日最终得分为S5，用户1在前一日针对标签6的信息点击而得到的当日最终得分为S6，用户1在前一日针对标签7的信息点击而得到的当日最终得分为S7，用户1在前一日针对标签8的信息点击而得到的当日最终得分为S8，且S1>S8>S3>S4>S6>S2>S5>S7,预设的排名阈值为5，则用户1对应的当前用户标签集包括标签1、标签8、标签3、标签4和标签6。通过这一方式得到的各用户的初始用户标签集，能够更加准确的体现用户的近期兴趣标签。

S104、将所述各用户分别对应的当前用户标签集存储至HBase数据库和/或Redis数据库。

在本实施例中，当通过标签离线更新流程完成了对各用户的兴趣标签的更新后，将将各用户分别对应的当前用户标签集存储至HBase数据库，且同时存储于Redis数据库。

在一实施例中，所述将各用户分别对应的当前用户标签集存储至HBase数据库，包括：

将各用户对应的当前用户标签集分别按一列数据加入到HBase数据库中的中间数据表，且对应列的列名为当前系统时间对应的日期及其前一日日期组合组成。

即将各用户分别对应的当前用户标签集以一列数据的形式加入到HBase数据库中的中间数据表，且该列的列名为当前系统时间对应的日期及其前一日日期组合组成。通过将当前用户标签集存储在中间数据表中，便于保存历史数据以供下一日的离线流程计算调用结果。

在一实施例中，所述将所述当前用户标签集存储至HBase数据库和/或Redis数据库，包括：

将各用户分别对应的当前用户标签集存储至Redis数据库中的结果表，或是将各用户分别对应的当前用户标签集存储至HBase数据库中的结果表，或是将各用户分别对应的当前用户标签集分别存储至Redis数据库中的结果表及至HBase数据库中的结果表；

其中，所述将各用户分别对应的当前用户标签集存储至Redis数据库中的结果表，包括：

获取当前用户标签集对应的所述当前更新标识时间；

根据所述当前更新标识时间及预设的数据保存时长，计算得到当前数据失效时间点；

将当前用户标签集对应的所述当前数据失效时间点与对应的当前用户标签集进行绑定存储。

即将各用户分别对应的当前用户标签集存储至Redis数据库或HBase数据库是将各用户分别对应的当前用户标签集存储至Redis数据库中的结果表，或是将各用户分别对应的当前用户标签集存储至HBase数据库中的结果表。通过将标签离线更新流程在当前计算得到的结果保存在结果表中，可以便于后续的标签在线更新流程调用结果。

其中，当前用户标签集中各标签的失效时间是24小时(即预设的数据保存时长是24小时)，且各标签均带有当前更新标识时间这一FLAGTIME标识，也即各标签以FLAGTIME标识的时间为起始时间且在24小时之后失效。

S105、若所述当前系统时间不满足所述标签离线更新流程启动条件，消费Kafka平台中的实时用户数据集。

在本实施例中，若当前系统时间不满足标签离线更新流程启动条件，表明当前时间不在标签离线更新流程启动条件对应的时间段内，此时可以启动标签在线更新流程。具体是通过Streaming流式计算引擎从Kafka平台消费得到实时用户数据集。

其中，实时用户数据集从Kafka平台消费得到后是存储至Redis数据库，更具体的是存储在Redis数据库的当日数据表中。

S106、根据所述实时用户数据集及调用对应的在线标签更新策略，得到与所述实时用户数据集中各用户分别对应的实时用户标签集，将所述实时用户标签集存储至HBase数据库。

在本实施例中，当由Streaming流式计算引擎先从Kafka平台消费得到实时用户数据集之后，在Streaming流式计算引擎中根据所述实时用户数据集及调用对应的在线标签更新策略，得到与所述实时用户数据集中各用户分别对应的实时用户标签集。

其中，在线标签更新策略对应的计算公式如下公式(3)：

score_s_new

其中，score

在一实施例中，步骤S106包括：

获取所述实时用户数据集中各用户分别对应的初始实时用户标签集；

根据所述在线标签更新策略中的第一在线标签更新子策略及所述实时用户数据集中各用户分别对应的初始实时用户标签集，计算获取每一个初始实时用户标签集中各标签对应的实时累计点击量产生标签得分；

其中，所述第一在线标签更新子策略对应公式为：

根据在线标签更新策略中的第二在线标签更新子策略及所述初始实时用户数据集中各标签对应的实时累计点击量产生标签得分，计算获取每一个初始实时用户标签集中各标签对应的实时最终得分；

其中，所述第二在线标签更新子策略对应公式为：

score_s_new

score_s_new

将每一个初始实时用户标签集中各标签按分别对应的实时最终得分进行降序排序，并根据各标签的排名值筛选获取排名值未超出预设的排名阈值的标签，组成各用户分别对应的实时用户标签集。

在本实施例中，当启动了标签在线更新流程并从Kafka平台消费得到实时用户数据集之后，也是先是根据各条用户数据分别对应的用户唯一识别标签进行用户数据分组，以将同一用户的用户数据分在同一数据组内，之后可以根据各用户对应数据组统计得到对应的实时用户标签集。

例如，用户1在当天(当天可以记为第t日)打开目标应用程序所访问或点击信息而产生对应的实时用户标签集中包括标签11、标签12、标签13、标签14、标签15、标签16、标签17、标签18。且上述标签11-标签18中每一标签均对应有累计点击量和累计曝光次数，这样即可上述公式(3)和公式(4)分别计算获取各用户对应的当前用户标签集。若用户1在当日针对标签1的信息点击而得到的实时最终得分为S11，用户1在当日针对标签12的信息点击而得到的实时最终得分为S12，用户1在当日针对标签13的信息点击而得到的实时最终得分S13，用户1在当日针对标签14的信息点击而得到的实时最终得分为S14，用户1在当日针对标签15的信息点击而得到的实时最终得分为S15，用户1在当日针对标签16的信息点击而得到的实时最终得分为S16，用户1在当日针对标签17的信息点击而得到的实时最终得分为S17，用户1在当日针对标签18的信息点击而得到的实时最终得分为S18，且S12>S18>S11>S15>S16>S13>S14>S17,预设的排名阈值为5，则用户1对应的实时用户标签集包括标签11、标签18、标签11、标签15和标签16。通过这一方式得到的各用户的实时用户标签集，秒级捕捉用户的行为数据，根据实时变化的信息做出相应的推荐策略。

在一实施例中，步骤S106之后还包括：

将所述实时用户标签集存储至Redis数据库。

在本实施例中，当通过标签在线更新流程完成了对各用户的兴趣标签的更新后，将将各用户分别对应的实时用户标签集存储至Redis数据库，以作为其他接口调用的数据基础。

该方法利用流式计算框架和在线存储数据库，不仅能够在指定时间段启动离线流程基于当前用户数据集更新标签，而且也能在其他非离线更新标签时间段秒级捕捉用户的行为数据，根据实时变化的数据做出相应的标签更新，提高了用户兴趣挖掘结果的准确性。

本发明实施例还提供一种基于流式数据处理的用户标签获取装置，该基于流式数据处理的用户标签获取装置用于执行前述基于流式数据处理的用户标签获取方法的任一实施例。具体地，请参阅图3，图3是本发明实施例提供的基于流式数据处理的用户标签获取装置的示意性框图。该基于流式数据处理的用户标签获取装置100可以配置于服务器中。

如图3所示，基于流式数据处理的用户标签获取装置100包括：流程启动判断单元101、离线流程启动单元102、离线标签更新单元103、标签集存储单元104、在线流程启动单元105、在线标签更新单元106。

流程启动判断单元101，用于获取当前系统时间，判断所述当前系统时间是否满足标签离线更新流程启动条件；其中，所述标签离线更新流程启动条件对应一个标签离线更新流程启动时间点。

在本实施例中，在服务器中获取当前系统时间，判断所述当前系统时间是否满足标签离线更新流程启动条件；其中，所述标签离线更新流程启动条件对应一个标签离线更新流程启动时间点，例如将签离线更新流程启动条件设置为每日0点之后启动标签离线更新流程(更具体如每日00:01开始启动标签离线更新流程)，一旦启动标签离线更新流程后，启动标签在线更新流程是禁止启动的，从而有效确保标签数据更新的准确性。

离线流程启动单元102，用于若所述当前系统时间满足所述标签离线更新流程启动条件，获取Hive数据库中已存储的当前用户数据集。

在本实施例中，若当前流程启动条件(例如当前系统时间是00:01)满足标签离线更新流程启动条件，此时服务器中的Spark计算引擎从Hive数据库中获取前一日的当前用户数据集。其中，当前用户数据集可以理解为由前一日各用户对目标应用程序的访问和点击行为产生的用户数据而组成，也可以理解为一种按日统计的用户点击曝光增量数据。

由于用户在前一日打开目标应用程序所访问或点击每一条信息均会产生对应的用户数据(即每一条信息中均内置设置了标签，用户在当日点击了这一信息会产生针该用户对该标签在当日的点击量和曝光次数)，这些用户数据都会存储在服务器的Hive数据库中。若启动了标签离线更新流程，此时服务器是由Spark计算引擎先从Hive数据库中获取已存储的当前用户数据集。

离线标签更新单元103，用于根据所述当前用户数据集及调用对应的离线标签更新策略，计算得到与所述当前用户数据集中各用户分别对应的当前用户标签集，并获取和存储当前用户标签集对应的当前更新标识时间。

在本实施例中，当由Spark计算引擎先从Hive数据库中获取已存储的当前用户数据集之后，在Spark计算引擎中根据所述当前用户数据集及调用对应的离线标签更新策略，计算得到与所述当前用户数据集中各用户分别对应的当前用户标签集。

其中，离线标签更新策略对应的计算公式如下公式(1)和公式(2)：

score_new

其中，score

在一实施例中，离线标签更新单元103包括：

初始用户标签集获取单元，用于获取所述当前用户数据集中各用户分别对应的初始用户标签集；

第一得分计算单元，用于根据所述离线标签更新策略中的第一离线标签更新子策略及所述当前用户数据集中各用户分别对应的初始用户标签集，计算获取每一个初始用户标签集中各标签对应的累计点击量产生标签得分；

其中，所述第一离线标签更新子策略对应公式为：

第二得分计算单元，用于根据离线标签更新策略中的第二离线标签更新子策略及所述初始用户数据集中各标签对应的累计点击量产生标签得分，计算获取每一个初始用户标签集中各标签对应的当日最终得分；

其中，所述第二离线标签更新子策略对应公式为：

score_new

第一得分排序筛选单元，用于将每一个初始用户标签集中各标签按分别对应的当日最终得分进行降序排序，并根据各标签的排名值筛选获取排名值未超出预设的排名阈值的标签，组成各用户分别对应的当前用户标签集。

其中，所述初始用户标签集获取单元还用于：

根据所述当前用户数据集中各条用户数据分别对应的用户唯一识别标签进行用户数据分组，将同一用户的用户数据划分在同一数据组内；

根据各用户对应数据组统计得到对应的初始用户标签集。

在本实施例中，当启动了标签离线更新流程并从Hive数据库中获取前一日的当前用户数据集后，先是根据各条用户数据分别对应的用户唯一识别标签进行用户数据分组，以将同一用户的用户数据分在同一数据组内，之后可以根据各用户对应数据组统计得到对应的初始用户标签集。

例如，用户1在前一日打开目标应用程序所访问或点击信息而产生对应的初始用户标签集中包括标签1、标签2、标签3、标签4、标签5、标签6、标签7、标签8。且上述标签1-标签8中每一标签均对应有累计点击量和累计曝光次数，这样即可上述公式(1)和公式(2)分别计算获取各用户对应的当前用户标签集。若用户1在前一日针对标签1的信息点击而得到的当日最终得分为S1，用户1在前一日针对标签2的信息点击而得到的当日最终得分为S2，用户1在前一日针对标签3的信息点击而得到的当日最终得分为S3，用户1在前一日针对标签4的信息点击而得到的当日最终得分为S4，用户1在前一日针对标签5的信息点击而得到的当日最终得分为S5，用户1在前一日针对标签6的信息点击而得到的当日最终得分为S6，用户1在前一日针对标签7的信息点击而得到的当日最终得分为S7，用户1在前一日针对标签8的信息点击而得到的当日最终得分为S8，且S1>S8>S3>S4>S6>S2>S5>S7,预设的排名阈值为5，则用户1对应的当前用户标签集包括标签1、标签8、标签3、标签4和标签6。通过这一方式得到的各用户的初始用户标签集，能够更加准确的体现用户的近期兴趣标签。

标签集存储单元104，用于将所述各用户分别对应的当前用户标签集存储至HBase数据库和/或Redis数据库。

在本实施例中，当通过标签离线更新流程完成了对各用户的兴趣标签的更新后，将将各用户分别对应的当前用户标签集存储至HBase数据库，且同时存储于Redis数据库。

在一实施例中，所述标签集存储单元104，还用于：

将各用户对应的当前用户标签集分别按一列数据加入到HBase数据库中的中间数据表，且对应列的列名为当前系统时间对应的日期及其前一日日期组合组成。

即将各用户分别对应的当前用户标签集以一列数据的形式加入到HBase数据库中的中间数据表，且该列的列名为当前系统时间对应的日期及其前一日日期组合组成。通过将当前用户标签集存储在中间数据表中，便于保存历史数据以供下一日的离线流程计算调用结果。

在一实施例中，所述标签集存储单元104还用于：

将各用户分别对应的当前用户标签集存储至Redis数据库中的结果表，或是将各用户分别对应的当前用户标签集存储至HBase数据库中的结果表，或是将各用户分别对应的当前用户标签集分别存储至Redis数据库中的结果表及至HBase数据库中的结果表；

其中，所述标签集存储单元104还用于：

获取当前用户标签集对应的所述当前更新标识时间；

根据所述当前更新标识时间及预设的数据保存时长，计算得到当前数据失效时间点；

将当前用户标签集对应的所述当前数据失效时间点与对应的当前用户标签集进行绑定存储。

即将各用户分别对应的当前用户标签集存储至Redis数据库或HBase数据库是将各用户分别对应的当前用户标签集存储至Redis数据库中的结果表，或是将各用户分别对应的当前用户标签集存储至HBase数据库中的结果表。通过将标签离线更新流程在当前计算得到的结果保存在结果表中，可以便于后续的标签在线更新流程调用结果。

其中，当前用户标签集中各标签的失效时间是24小时(即预设的数据保存时长是24小时)，且各标签均带有当前更新标识时间这一FLAGTIME标识，也即各标签以FLAGTIME标识的时间为起始时间且在24小时之后失效。

在线流程启动单元105，用于若所述当前系统时间不满足所述标签离线更新流程启动条件，消费Kafka平台中的实时用户数据集。

在本实施例中，若当前系统时间不满足标签离线更新流程启动条件，表明当前时间不在标签离线更新流程启动条件对应的时间段内，此时可以启动标签在线更新流程。具体是通过Streaming流式计算引擎从Kafka平台消费得到实时用户数据集。

其中，实时用户数据集从Kafka平台消费得到后是存储至Redis数据库，更具体的是存储在Redis数据库的当日数据表中。

在线标签更新单元106，用于根据所述实时用户数据集及调用对应的在线标签更新策略，得到与所述实时用户数据集中各用户分别对应的实时用户标签集。

在本实施例中，当由Streaming流式计算引擎先从Kafka平台消费得到实时用户数据集之后，在Streaming流式计算引擎中根据所述实时用户数据集及调用对应的在线标签更新策略，得到与所述实时用户数据集中各用户分别对应的实时用户标签集。

其中，在线标签更新策略对应的计算公式如下公式(3)：

score_s_new

其中，score

在一实施例中，在线标签更新单元106包括：

初始实时用户标签集获取单元，用于获取所述实时用户数据集中各用户分别对应的初始实时用户标签集；

第三得分计算单元，用于根据所述在线标签更新策略中的第一在线标签更新子策略及所述实时用户数据集中各用户分别对应的初始实时用户标签集，计算获取每一个初始实时用户标签集中各标签对应的实时累计点击量产生标签得分；

其中，所述第一在线标签更新子策略对应公式为：

第四得分计算单元，用于根据在线标签更新策略中的第二在线标签更新子策略及所述初始实时用户数据集中各标签对应的实时累计点击量产生标签得分，计算获取每一个初始实时用户标签集中各标签对应的实时最终得分；

其中，所述第二在线标签更新子策略对应公式为：

score_s_new

score_s_new

第二得分排序筛选单元，用于将每一个初始实时用户标签集中各标签按分别对应的实时最终得分进行降序排序，并根据各标签的排名值筛选获取排名值未超出预设的排名阈值的标签，组成各用户分别对应的实时用户标签集。

在本实施例中，当启动了标签在线更新流程并从Kafka平台消费得到实时用户数据集之后，也是先是根据各条用户数据分别对应的用户唯一识别标签进行用户数据分组，以将同一用户的用户数据分在同一数据组内，之后可以根据各用户对应数据组统计得到对应的实时用户标签集。

例如，用户1在当天(当天可以记为第t日)打开目标应用程序所访问或点击信息而产生对应的实时用户标签集中包括标签11、标签12、标签13、标签14、标签15、标签16、标签17、标签18。且上述标签11-标签18中每一标签均对应有累计点击量和累计曝光次数，这样即可上述公式(3)和公式(4)分别计算获取各用户对应的当前用户标签集。若用户1在当日针对标签1的信息点击而得到的实时最终得分为S11，用户1在当日针对标签12的信息点击而得到的实时最终得分为S12，用户1在当日针对标签13的信息点击而得到的实时最终得分S13，用户1在当日针对标签14的信息点击而得到的实时最终得分为S14，用户1在当日针对标签15的信息点击而得到的实时最终得分为S15，用户1在当日针对标签16的信息点击而得到的实时最终得分为S16，用户1在当日针对标签17的信息点击而得到的实时最终得分为S17，用户1在当日针对标签18的信息点击而得到的实时最终得分为S18，且S12＞S18＞S11＞S15＞S16＞S13＞S14＞S17，预设的排名阈值为5，则用户1对应的实时用户标签集包括标签11、标签18、标签11、标签15和标签16。通过这一方式得到的各用户的实时用户标签集，秒级捕捉用户的行为数据，根据实时变化的信息做出相应的推荐策略。

在一实施例中，基于流式数据处理的用户标签获取装置100还包括：

实时用户标签集存储单元，用于将所述实时用户标签集存储至Redis数据库。

在本实施例中，当通过标签在线更新流程完成了对各用户的兴趣标签的更新后，将将各用户分别对应的实时用户标签集存储至Redis数据库，以作为其他接口调用的数据基础。

该装置利用流式计算框架和在线存储数据库，不仅能够在指定时间段启动离线流程基于当前用户数据集更新标签，而且也能在其他非离线更新标签时间段秒级捕捉用户的行为数据，根据实时变化的数据做出相应的标签更新，提高了用户兴趣挖掘结果的准确性。

上述基于流式数据处理的用户标签获取装置可以实现为计算机程序的形式，该计算机程序可以在如图4所示的计算机设备上运行。

请参阅图4，图4是本发明实施例提供的计算机设备的示意性框图。该计算机设备500是服务器，服务器可以是独立的服务器，也可以是多个服务器组成的服务器集群。

参阅图4，该计算机设备500包括通过系统总线501连接的处理器502、存储器和网络接口505，其中，存储器可以包括非易失性存储介质503和内存储器504。

该非易失性存储介质503可存储操作系统5031和计算机程序5032。该计算机程序5032被执行时，可使得处理器502执行基于流式数据处理的用户标签获取方法。

该处理器502用于提供计算和控制能力，支撑整个计算机设备500的运行。

该内存储器504为非易失性存储介质503中的计算机程序5032的运行提供环境，该计算机程序5032被处理器502执行时，可使得处理器502执行基于流式数据处理的用户标签获取方法。

该网络接口505用于进行网络通信，如提供数据信息的传输等。本领域技术人员可以理解，图4中示出的结构，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的计算机设备500的限定，具体的计算机设备500可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

其中，所述处理器502用于运行存储在存储器中的计算机程序5032，以实现本发明实施例公开的基于流式数据处理的用户标签获取方法。

本领域技术人员可以理解，图4中示出的计算机设备的实施例并不构成对计算机设备具体构成的限定，在其他实施例中，计算机设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。例如，在一些实施例中，计算机设备可以仅包括存储器及处理器，在这样的实施例中，存储器及处理器的结构及功能与图4所示实施例一致，在此不再赘述。

应当理解，在本发明实施例中，处理器502可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器502还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable GateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

在本发明的另一实施例中提供计算机可读存储介质。该计算机可读存储介质可以为非易失性的计算机可读存储介质。该计算机可读存储介质存储有计算机程序，其中计算机程序被处理器执行时实现本发明实施例公开的基于流式数据处理的用户标签获取方法。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的设备、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本发明所提供的几个实施例中，应该理解到，所揭露的设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为逻辑功能划分，实际实现时可以有另外的划分方式，也可以将具有相同功能的单元集合成一个单元，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

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

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

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

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。