CN105808653B - 一种基于用户标签系统的数据处理方法及装置 - Google Patents

Abstract

本发明实施例公开了一种用户标签系统及基于用户标签系统的数据推送系统，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题。本发明实施例基于用户标签系统的数据处理方法包括：获取到来自Hive平台的标签数据；对标签数据进行标签运算；将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据。

Description

一种基于用户标签系统的数据处理方法及装置

技术领域

本发明涉及大数据技术领域，尤其涉及一种基于用户标签系统的数据处理方法及装置。

背景技术

大数据就是互联网发展到现今阶段的一种表象或特征而已，没有必要神话它或对它保持敬畏之心，在以云计算为代表的技术创新大幕的衬托下，这些原本很难收集和使用的数据开始容易被利用起来了，通过各行各业的不断创新，大数据会逐步为人类创造更多的价值。

数据挖掘(英语：Data mining)，又译为资料探勘、数据采矿。它是数据库知识发现(英语：Knowledge-Discovery in Databases，简称：KDD)中的一个步骤。数据挖掘一般是指从大量的数据中通过算法搜索隐藏于其中信息的过程。数据挖掘通常与计算机科学有关，并通过统计、在线分析处理、情报检索、机器学习、专家系统(依靠过去的经验法则)和模式识别等诸多方法来实现上述目标。

目前的数据挖掘的方式有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致了数据挖掘效率低下的技术问题。

发明内容

本发明实施例提供的一种基于用户标签系统的数据处理方法及装置，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题。

本发明实施例提供的一种基于用户标签系统的数据处理方法，包括：

获取到来自Hive平台的标签数据；

对所述标签数据进行标签运算；

将运算处理后的所述标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的所述标签数据。

优选地，获取到来自Hive平台的标签数据之前还包括：

建立标签运算任务表，并进行对应的status字段的定义；

按照每隔第一预置时间段对用户基本信息同步表进行扫描，若所述status为待执行或最近一次更新时间非当日，则将所述status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同所述tag标签表的标签进行一个任务的合并，并写入所述标签运算任务表中，生成对应的待操作的SQL语句。

优选地，对所述标签数据进行标签运算具体包括：

按照每隔第二预置时间段对所述标签运算任务表进行扫描，若所述status为待执行或标签数据版本标识少于当日，则将所述status更新为查询中；

链接所述Hive平台，在所述标签运算任务表中所述SQL语句，并根据预置标签规则，查询出与所述SQL语句对应的结果，将所述结果保存至所述Hive平台中。

优选地，链接所述Hive平台，在所述标签运算任务表中所述SQL语句，并根据预置标签规则，查询出与所述SQL语句对应的结果，将所述结果保存至所述Hive平台中之后还包括：

建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义；

按照每隔第三预置时间段对所述用户群数据表进行扫描，若所述status为创建中或最近一次更新时间少于当天的记录，则将所述status更新为处理中；

判断所述标签数据是否准备完毕，若否，则将所述status设置为标签数据未准备就绪，若存在所述标签数据准备失败，则将所述status设置为标签数据准备失败，若所述标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理。

优选地，所述的基于用户标签系统的数据处理方法还包括：

建立用户基本信息同步表，并进行对应的status字段的定义；

在所述用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步；

按照每隔第四预置时间段对所述用户基本信息同步表进行扫描，若所述status为标签数据待更新或最近一次更新时间非当日，则将所述status更新为处理中，并从所述Hive平台中导出用户、设备基本信息的数据量，并将用户、设备基本信息缓存至所述Redis集群中。

本发明实施例提供的一种基于用户标签系统的数据处理装置，包括：

获取单元，用于获取到来自Hive平台的标签数据；

第一运算单元，用于对所述标签数据进行标签运算；

缓存单元，用于将运算处理后的所述标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的所述标签数据。

优选地，所述的基于用户标签系统的数据处理装置还包括：

标签运算任务表建立单元，用于建立标签运算任务表，并进行对应的status字段的定义；

第一扫描处理单元，用于按照每隔第一预置时间段对用户基本信息同步表进行扫描，若所述status为待执行或最近一次更新时间非当日，则将所述status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同所述tag标签表的标签进行一个任务的合并，并写入所述标签运算任务表中，生成对应的待操作的SQL语句。

优选地，第一运算单元具体包括：

第一扫描子单元，用于按照每隔第二预置时间段对所述标签运算任务表进行扫描，若所述status为待执行或标签数据版本标识少于当日，则将所述status更新为查询中；

查询子单元，用于链接所述Hive平台，在所述标签运算任务表中所述SQL语句，并根据预置标签规则，查询出与所述SQL语句对应的结果，将所述结果保存至所述Hive平台中。

优选地，第一运算单元还包括：

建立子单元，建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义；

第二扫描子单元，用于按照每隔第三预置时间段对所述用户群数据表进行扫描，若所述status为创建中或最近一次更新时间少于当天的记录，则将所述status更新为处理中；

判断子单元，用于判断所述标签数据是否准备完毕，若否，则将所述status设置为标签数据未准备就绪，若存在所述标签数据准备失败，则将所述status设置为标签数据准备失败，若所述标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理。

优选地，所述的基于用户标签系统的数据处理装置还包括：

用户基本信息同步表建立单元，用于建立用户基本信息同步表，并进行对应的status字段的定义；

创建单元，用于在所述用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步；

第二扫描处理单元，用于按照每隔第四预置时间段对所述用户基本信息同步表进行扫描，若所述status为标签数据待更新或最近一次更新时间非当日，则将所述status更新为处理中，并从所述Hive平台中导出用户、设备基本信息的数据量，并将用户、设备基本信息缓存至所述Redis集群中。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例提供的一种基于用户标签系统的数据处理方法及装置，其中，基于用户标签系统的数据处理方法包括：获取到来自Hive平台的标签数据；对标签数据进行标签运算；将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据。本实施例中，通过获取到来自Hive平台的标签数据；对标签数据进行标签运算；将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题。

附图说明

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

图1为本发明实施例提供的一种基于用户标签系统的数据处理方法的一个实施例的流程示意图；

图2为本发明实施例提供的一种基于用户标签系统的数据处理方法的另一个实施例的流程示意图；

图3为本发明实施例提供的一种基于用户标签系统的数据处理装置的一个实施例的结构示意图；

图4为本发明实施例提供的一种基于用户标签系统的数据处理装置的另一个实施例的结构示意图；

图5为数据流的示意图；

图6为业务运营示意图。

具体实施方式

本发明实施例提供的一种用户标签系统及基于用户标签系统的数据推送系统，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1，本发明实施例提供的一种基于用户标签系统的数据处理方法的一个实施例包括：

101、获取到来自Hive平台的标签数据；

本实施例中，当需要对标签数据进行处理的时候，首先需要获取到来自Hive平台的标签数据。

102、对标签数据进行标签运算；

当获取到来自Hive平台的标签数据之后，需要对标签数据进行标签运算。

103、将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据。

当对标签数据进行标签运算之后，需要将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据。

本实施例中，通过获取到来自Hive平台的标签数据；对标签数据进行标签运算；将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题。

上面是对基于用户标签系统的数据处理方法的过程进行详细的描述，下面将对具体过程和附加过程进行描述，请参阅图2，本发明实施例提供的一种基于用户标签系统的数据处理方法的另一个实施例包括：

201、建立标签运算任务表，并进行对应的status字段的定义；

本实施例中，当需要对标签数据进行处理的时候，首先需要建立标签运算任务表，并进行对应的status字段的定义。

202、按照每隔第一预置时间段对用户基本信息同步表进行扫描，若status为待执行或最近一次更新时间非当日，则将status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同tag标签表的标签进行一个任务的合并，并写入标签运算任务表中，生成对应的待操作的SQL语句；

当建立标签运算任务表，并进行对应的status字段的定义之后，需要按照每隔第一预置时间段对用户基本信息同步表进行扫描，若status为待执行或最近一次更新时间非当日，则将status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同tag标签表的标签进行一个任务的合并，并写入标签运算任务表中，生成对应的待操作的SQL语句。

203、获取到来自Hive平台的标签数据；

当按照每隔第一预置时间段对用户基本信息同步表进行扫描，若status为待执行或最近一次更新时间非当日，则将status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同tag标签表的标签进行一个任务的合并，并写入标签运算任务表中，生成对应的待操作的SQL语句之后，需要获取到来自Hive平台的标签数据。

204、按照每隔第二预置时间段对标签运算任务表进行扫描，若status为待执行或标签数据版本标识少于当日，则将status更新为查询中；

当获取到来自Hive平台的标签数据之后，需要按照每隔第二预置时间段对标签运算任务表进行扫描，若status为待执行或标签数据版本标识少于当日，则将status更新为查询中。

205、链接Hive平台，在标签运算任务表中SQL语句，并根据预置标签规则，查询出与SQL语句对应的结果，将结果保存至Hive平台中；

当按照每隔第二预置时间段对标签运算任务表进行扫描，若status为待执行或标签数据版本标识少于当日，则将status更新为查询中之后，需要链接Hive平台，在标签运算任务表中SQL语句，并根据预置标签规则，查询出与SQL语句对应的结果，将结果保存至Hive平台中。

206、建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义；

当链接Hive平台，在标签运算任务表中SQL语句，并根据预置标签规则，查询出与SQL语句对应的结果，将结果保存至Hive平台中之后，需要建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义。

207、按照每隔第三预置时间段对用户群数据表进行扫描，若status为创建中或最近一次更新时间少于当天的记录，则将status更新为处理中；

当建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义之后，需要按照每隔第三预置时间段对用户群数据表进行扫描，若status为创建中或最近一次更新时间少于当天的记录，则将status更新为处理中。

208、判断标签数据是否准备完毕，若否，则将status设置为标签数据未准备就绪，若存在标签数据准备失败，则将status设置为标签数据准备失败，若标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理；

当按照每隔第三预置时间段对用户群数据表进行扫描，若status为创建中或最近一次更新时间少于当天的记录，则将status更新为处理中之后，需要判断标签数据是否准备完毕，若否，则将status设置为标签数据未准备就绪，若存在标签数据准备失败，则将status设置为标签数据准备失败，若标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理。

209、将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据；

当判断标签数据是否准备完毕，若否，则将status设置为标签数据未准备就绪，若存在标签数据准备失败，则将status设置为标签数据准备失败，若标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理之后，需要将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据。

210、建立用户基本信息同步表，并进行对应的status字段的定义；

当步骤201和步骤202之后，需要建立用户基本信息同步表，并进行对应的status字段的定义。

211、在用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步；

当建立用户基本信息同步表，并进行对应的status字段的定义之后，需要在用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步。

212、按照每隔第四预置时间段对用户基本信息同步表进行扫描，若status为标签数据待更新或最近一次更新时间非当日，则将status更新为处理中，并从Hive平台中导出用户、设备基本信息的数据量，并将用户、设备基本信息缓存至Redis集群中。

当在用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步之后，需要按照每隔第四预置时间段对用户基本信息同步表进行扫描，若status为标签数据待更新或最近一次更新时间非当日，则将status更新为处理中，并从Hive平台中导出用户、设备基本信息的数据量，并将用户、设备基本信息缓存至Redis集群中。

本实施例中，通过获取到来自Hive平台的标签数据；对标签数据进行标签运算；将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题，进一步提高了挖掘数据的精准性。

为了便于理解，下面将以具体应用场景对图1实施例的基于用户标签系统的数据处理方法进行描述，请参阅图5和图6，应用例包括：

1、用户基本信息同步

用基本信息需要从Hive同步到Redis中。用户基本信息按照注册帐号和设备信息分为两类，存放在Redis集群1中。

1.1处理流程

(1)utr_basic_sync:用户基本信息同步表。status字段定义为：

0数据待更新

1处理中(0->1需要锁表更新)

2写入Redis成功

-10用户基本信息更新失败

data_ver:数据版本标识，如20150413

(2)utr_basic_sync中创建两条记录，分别标识帐号信息同步和设备信息同步。

(3)创建任务一，每1分钟扫描utr_basic_sync表一次，当status为0或last_sync_time非当天，更新status＝1，并执行从Hive导出用户基本信息逻辑。(Hive数据库需要有标识，数据已经更新完)

(4)根据Hive中用户、设备基本信息的数据量，启动多线程从Hive中拉取基本信息到Redis中

(5)帐号信息/设备信息均采用增量更新的方式。

(6)任务一并发执行

1.2增量更新

使用SQL对比hive两个表中变化的字段。

1.3Redis中用户基本信息格式

"uid":"",

"user_id":"",

"phone":"",

"mail":"",

"tokens":[mid_deviceToken_appName,mid_deviceToken_appName]

设备信息

mid_deviceToken_appName,mid_deviceToken_appName

为方便API指定返回的字段，帐号信息使用map存储。另外，tokens字段使用约定的mid_deviceToken_appName格式。更新设备信息的同时，需要把设备信息更新到帐号信息的tokens字段中。

1.4同步失败处理

(1)通过设置utr_basic_sync表status＝0，重新执行utr_tag_task的任务合并操作。

(2)在log中打印详细错误信息，在utr_task_log中记录失败信息

2、标签任务生成

2.1处理流程

(1)utr_tag_task:标签运算任务表，每天任务计划根据tag涉及的表，合并为同一个任务写如到utr_tag_task表中。status字段定义：

0待执行

1查询中

2执行增量新增、更新操作

3执行增量删除操作

-10hive查询失败

-11执行增量新增、更新操作

-12执行增量删除操作失败

data_ver:数据版本标识，如20150413

(2)创建任务二，每天1分钟扫描utr_basic_sync表一次，当status为0或last_sync_time非当天，更新status＝1，并取出所有的utr_tag表的所有记录，将相同表的标签，合并成为一个任务，写入到utr_tag_task表中。需要预生成待操作的各条SQL语句。

(utr_tag表中，增加一个字段，表示属性所属的数据表。修改log_id为task_id)

(3)任务二，不需要并发执行。

2.2同步失败处理

(1)在log中打印详细错误信息，在utr_task_log中记录失败信息

(2)通过更新utr_tag中的status＝0，可以重新导出该tag的文件

3、标签运算(hive2Solr)

3.1处理流程

(1)utr_tag_task:标签任务表。status字段定义：

0待执行

1查询中

2执行增量新增、更新操作

3执行增量删除操作

-10hive查询失败

-11执行增量新增、更新操作

-12执行增量删除操作失败

data_ver:数据版本标识，如20150413

(2)创建任务三，每1分钟扫描utr_tag_task表，若status＝0或data_ver少于当天，更新status＝1。(hive需要提供方法查询数据是否已经准备完毕)

(3)每个任务处理逻辑如下：

链接hive，执行utr_tag_task表中的create_sql，根据标签条件的组合，查出结果保存在hive中。结果格式为(uid,tagCode1,tagCode2,tagCode3….)

执行增量新增、更新的sql

执行增量删除的sql

等待sql执行结束，更新utr_tag_task和utr_tag表中的status和data_ver

(4)任务三允许并发执行

3.2同步失败处理

(1)在log中打印详细错误信息，在utr_task_log中记录失败信息

(2)其中一个线程失败，则标识整个tag更新失败

(3)通过更新utr_tag中的status字段，可以重新导入该tag的文件。Tag中存在重复的code不影响。

3.3用户群运算

针对所有的用户群，进行预处理，生成相应的用户数据，只有数据生成完成后，业务系统才可以使用该用户群。

3.3.1处理流程

(1)utr_group表:用户群数据表，同时作为用户群任务表。status(对外状态,api接口仅判断status字段)定义:

0创建中(完成用户群创建)

1已就绪

-10数据准备失败

data_ver:数据版本标识，如20150413

sync_status(同步状态)定义：

0创建中(新建用户群的状态)

1处理中

2正在更新缓存数据

3已完成

-10标签数据未准备就绪

-11标签数据准备失败

-12用户基本信息准备失败(Redis中已有缓存数据，但data_ver未更新)

(2)创建任务四，每1分钟扫描utr_group表，当记录满足：

sync_status＝0或last_sync_time少于当天的记录或(sync_status＝-10andlast_sync_time是5分钟前)，每次取top 1记录，更新sync_status＝1，并执行下面的逻辑：

判断标签是否准备完毕(data_ver为当天)，若否，则设置sync_status＝-10，更新last_sync_time，不写入utr_task_log表；

若存在标签数据准备失败，则直接更新sync_status＝-11，更新last_sync_time，写入log到utr_task_log表；

若标签数据准备完毕，则取用户群条件，拼接Solr查询语句，从Solr中查出记录总数和最大uid；

若记录总数大于500w,按性能优化方案多线程处理；

汇总多线程操作结果，若失败，则清除Redis中已存入的记录；

若记录总数少于500w,则直接单线程处理，若失败，清除Redis中已存入的记录；

若成功，判断用户基本信息是否更新成功，若是，则直接更新data_ver字段，若否，则设置sync_status＝-12，并设置next_data_ver的值

(3)任务四允许并发执行，在quartz中设置任务四可用线程数为6，最多同时有60个线程写入Redis。

3.3.2缓存更新性能优化

若Solr查询出的用户结果总数大于500w，则启按每线程负责处理300w记录计算(最多启动10条线程)，从缓存更新线程池(初始值为50)中启动相应线程数进行处理。Redis中使用单一的list存储用户群结果，key规则为：group_code_data_ver；

3.3.3同步失败处理

(1)sync_status＝-10:通过界面提供的重试功能，设置sync_status＝0，重新执行用户群缓存更新

(2)sync_status＝-11:首先重新执行用户基本信息同步，成功后，通过界面提供的更新数据版本功能，更新data_ver

(3)在log中打印详细错误信息，在utr_task_log中记录失败信息

4、数据清理

4.1 Redis数据清理

(1)用户基本信息：用户基本信息不区分版本，每次更新时，设置过期时间为5天后，不需要考虑清理。

(2)用户群：更新用户群的data_ver同时，设置上一版本的过期时间为24小时后

4.2 Solr数据清理

Solr同时保留2天的数据？创建新的collection前，先删除前两天的collection。如：20150415同步的时候，删除20150413的数据，保留20150414的数据。

5、对外接口(Http)

API接口调用方为内部系统，并发量不大，使用Tomcat对外提供HTTP接口服务。

5.1接口处理流程

(1)判断用户群status＝1,若否，返回错误信息

(2)取data_ver,根据data_ver拼接出Redis中存放的key

(3)根据pageSize和pageNo，定位开始取数据的list和游标开始位置start。

进一步地，基于用户标签系统的数据推送系统具备告警监控功能，30分钟汇总发送，并重置。

基于用户标签系统的数据推送系统可以是如图5进行业务运营，用户标签系统利用一套统一的用户标签体系(360度全景画像)，提供根据用户标签进行特定用户分群的功能。实现了精准营销、个性化推荐，统一营销用户群体，打通营销、广告、促销、个性化推荐数据流，管理用户标签群体生命周期。

需要注意的是，本实施例中用户数据将会区分用户帐号、设备信息，设备标签关于品牌、品类表的标签需要同时打到用户上(标签定义的时候，判断那些标签需要两个Solr同时打上标签)。

请参阅图3，本发明实施例中提供的一种基于用户标签系统的数据处理装置的一个实施例包括：

获取单元301，用于获取到来自Hive平台的标签数据；

第一运算单元302，用于对标签数据进行标签运算；

缓存单元303，用于将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据。

本实施例中，通过获取单元301获取到来自Hive平台的标签数据；第一运算单元302对标签数据进行标签运算；缓存单元303将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题。

上面是对基于用户标签系统的数据处理装置的各单元进行详细的描述，下面将对附加单元和子单元进行详细的描述，请参阅图4，本发明实施例中提供的一种基于用户标签系统的数据处理装置的另一个实施例包括：

标签运算任务表建立单元401，用于建立标签运算任务表，并进行对应的status字段的定义；

第一扫描处理单元402，用于按照每隔第一预置时间段对用户基本信息同步表进行扫描，若status为待执行或最近一次更新时间非当日，则将status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同tag标签表的标签进行一个任务的合并，并写入标签运算任务表中，生成对应的待操作的SQL语句。

获取单元403，用于获取到来自Hive平台的标签数据；

第一运算单元404，用于对标签数据进行标签运算；

第一运算单元404具体包括：

第一扫描子单元4041，用于按照每隔第二预置时间段对标签运算任务表进行扫描，若status为待执行或标签数据版本标识少于当日，则将status更新为查询中；

查询子单元4042，用于链接Hive平台，在标签运算任务表中SQL语句，并根据预置标签规则，查询出与SQL语句对应的结果，将结果保存至Hive平台中。

建立子单元4043，建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义；

第二扫描子单元4044，用于按照每隔第三预置时间段对用户群数据表进行扫描，若status为创建中或最近一次更新时间少于当天的记录，则将status更新为处理中；

判断子单元4045，用于判断标签数据是否准备完毕，若否，则将status设置为标签数据未准备就绪，若存在标签数据准备失败，则将status设置为标签数据准备失败，若标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理。

缓存单元405，用于将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据。

用户基本信息同步表建立单元406，用于建立用户基本信息同步表，并进行对应的status字段的定义；

创建单元407，用于在用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步；

第二扫描处理单元408，用于按照每隔第四预置时间段对用户基本信息同步表进行扫描，若status为标签数据待更新或最近一次更新时间非当日，则将status更新为处理中，并从Hive平台中导出用户、设备基本信息的数据量，并将用户、设备基本信息缓存至Redis集群中。

本实施例中，通过获取单元403获取到来自Hive平台的标签数据；第一运算单元404对标签数据进行标签运算；缓存单元405将运算处理后的标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的标签数据，解决了目前的数据挖掘的方式虽然有多种，但却无法将挖掘出来的数据对外进行精准的推送，导致的数据挖掘效率低下的技术问题，进一步提高了挖掘数据的精准性。

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

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

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

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

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (6)

1.一种基于用户标签系统的数据处理方法，其特征在于，包括：

获取到来自Hive平台的标签数据；

对所述标签数据进行标签运算；

将运算处理后的所述标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的所述标签数据；

获取到来自Hive平台的标签数据之前还包括：

建立标签运算任务表，并进行对应的status字段的定义；

按照每隔第一预置时间段对用户基本信息同步表进行扫描，若所述status为待执行或最近一次更新时间非当日，则将所述status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同所述tag标签表的标签进行一个任务的合并，并写入所述标签运算任务表中，生成对应的待操作的SQL语句；

对所述标签数据进行标签运算具体包括：

按照每隔第二预置时间段对所述标签运算任务表进行扫描，若所述status为待执行或标签数据版本标识少于当日，则将所述status更新为查询中；

链接所述Hive平台，在所述标签运算任务表中获取所述SQL语句，并根据预置标签规则，查询出与所述SQL语句对应的结果，将所述结果保存至所述Hive平台中。

2.根据权利要求1所述的基于用户标签系统的数据处理方法，其特征在于，链接所述Hive平台，在所述标签运算任务表中获取所述SQL语句，并根据预置标签规则，查询出与所述SQL语句对应的结果，将所述结果保存至所述Hive平台中之后还包括：

建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义；

按照每隔第三预置时间段对所述用户群数据表进行扫描，若所述status为创建中或最近一次更新时间少于当天的记录，则将所述status更新为处理中；

判断所述标签数据是否准备完毕，若否，则将所述status设置为标签数据未准备就绪，若存在所述标签数据准备失败，则将所述status设置为标签数据准备失败，若所述标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理。

3.根据权利要求1或2中任意一项所述的基于用户标签系统的数据处理方法，其特征在于，所述的基于用户标签系统的数据处理方法还包括：

建立用户基本信息同步表，并进行对应的status字段的定义；

在所述用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步；

按照每隔第四预置时间段对所述用户基本信息同步表进行扫描，若所述status为标签数据待更新或最近一次更新时间非当日，则将所述status更新为处理中，并从所述Hive平台中导出用户、设备基本信息的数据量，并将用户、设备基本信息缓存至所述Redis集群中。

4.一种基于用户标签系统的数据处理装置，其特征在于，包括：

获取单元，用于获取到来自Hive平台的标签数据；

第一运算单元，用于对所述标签数据进行标签运算；

缓存单元，用于将运算处理后的所述标签数据缓存至Redis集群，使得外部通信端通过对外接口获取到缓存的所述标签数据；

所述的基于用户标签系统的数据处理装置还包括：

标签运算任务表建立单元，用于建立标签运算任务表，并进行对应的status字段的定义；

第一扫描处理单元，用于按照每隔第一预置时间段对用户基本信息同步表进行扫描，若所述status为待执行或最近一次更新时间非当日，则将所述status更新为查询中，提取预置的所有tag标签表中的所有记录，并将相同所述tag标签表的标签进行一个任务的合并，并写入所述标签运算任务表中，生成对应的待操作的SQL语句；

第一运算单元具体包括：

第一扫描子单元，用于按照每隔第二预置时间段对所述标签运算任务表进行扫描，若所述status为待执行或标签数据版本标识少于当日，则将所述status更新为查询中；

查询子单元，用于链接所述Hive平台，在所述标签运算任务表中获取所述SQL语句，并根据预置标签规则，查询出与所述SQL语句对应的结果，将所述结果保存至所述Hive平台中。

5.根据权利要求4所述的基于用户标签系统的数据处理装置，其特征在于，第一运算单元还包括：

建立子单元，建立用于执行用户群任务的用户群数据表，并进行对应的status字段的定义；

第二扫描子单元，用于按照每隔第三预置时间段对所述用户群数据表进行扫描，若所述status为创建中或最近一次更新时间少于当天的记录，则将所述status更新为处理中；

判断子单元，用于判断所述标签数据是否准备完毕，若否，则将所述status设置为标签数据未准备就绪，若存在所述标签数据准备失败，则将所述status设置为标签数据准备失败，若所述标签数据准备完毕，则提取对应的预置用户群条件，进行Solr数据处理。

6.根据权利要求4至5中任意一项所述的基于用户标签系统的数据处理装置，其特征在于，所述的基于用户标签系统的数据处理装置还包括：

用户基本信息同步表建立单元，用于建立用户基本信息同步表，并进行对应的status字段的定义；

创建单元，用于在所述用户基本信息同步表创建两条记录，分别用于标识帐号信息同步和设备信息同步；

第二扫描处理单元，用于按照每隔第四预置时间段对所述用户基本信息同步表进行扫描，若所述status为标签数据待更新或最近一次更新时间非当日，则将所述status更新为处理中，并从所述Hive平台中导出用户、设备基本信息的数据量，并将用户、设备基本信息缓存至所述Redis集群中。