用户画像数据处理方法和装置

技术领域

本申请涉及数据处理技术领域，具体涉及一种用户画像数据处理方法和装置。

背景技术

通常实时数据的输出是属于某一类的专业数据，例如，用户信令话单、用户上网日志话单、用户计费话单等，使用实时数据时，需要结合用户特征数据，用户挖掘数据立体的展现用户实时画像模型。

目前，通常采用先进行实时计算，将数据落地到关系型数据库后，再对数据进行关联查询，由于该方式需要实现数据落地环节以及全内存数据计算，从而增加了I/O消耗，因此不能满足大数据实时存储与计算的需求，继而降低数据的计算效率。

发明内容

本申请实施例提供一种用户画像数据处理方法和装置，用以解决数据的计算效率低的问题。

第一方面，本申请实施例提供一种用户画像数据处理方法，包括：

根据数据标识计算规则确定用户的实时数据对应的标签信息；

确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签；

根据所述待填充标签、所述标签信息以及字段标识填充对象数据；

根据所述对象数据以及标签的计算规则确定用户画像。

在一个实施例中，所述根据所述待填充标签的类型从设定数据库中获取所述待填充标签包括：

若所述待填充标签的类型为热点标签，则从第一设定数据库中获取所述热点标签；

若所述待填充标签的类型为非热点标签，则从第二设定数据库中获取所述非热点标签；

其中，所述待填充标签包括所述热点标签和所述非热点标签，所述设定数据库包括所述第一设定数据库和所述第二设定数据库。

在一个实施例中，所述确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签之前，还包括：

确定设定时间段内历史标签的使用频率，将所述使用频率大于或等于设定阈值的所述历史标签作为所述热点标签；

若所述热点标签不存在所述第一设定数据库，则将所述热点标签存储至所述第一设定数据库。

在一个实施例中，所述确定设定时间段内历史标签的使用频率，将所述使用频率大于或等于设定阈值的所述历史标签作为所述热点标签之后，包括：

将所述使用频率小于所述设定阈值的所述历史标签作为非热点标签；

删除所述第一设定数据库中的所述非热点标签。

在一个实施例中，所述根据数据标识计算规则确定用户的实时数据对应的标签信息之前，还包括：

根据用户的号码信息标识全量标签；

根据所述全量标签的类型对所述全量标签的数据进行存储，所述全量标签包括所述热点标签和所述非热点标签。

在一个实施例中，所述根据数据标识计算规则确定用户的实时数据对应的标签信息之前，还包括：

确定所述实时数据的数据特征；

根据所述数据特征确定所述数据标识计算规则。

在一个实施例中，所述根据所述对象数据以及标签的计算规则确定用户画像，包括：

根据所述标签的计算规则确定待计算标签；

根据所述对象数据以及所述待计算标签确定所述用户画像。

第二方面，本申请实施例提供一种用户画像数据处理装置，包括：

第一确定模块，用于根据数据标识计算规则确定用户的实时数据对应的标签信息；

第二确定模块，用于确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签；

填充模块，用于根据所述待填充标签、所述标签信息以及字段标识填充对象数据；

第三确定模块，用于根据所述对象数据以及标签的计算规则确定用户画像。

第三方面，本申请实施例提供一种电子设备，包括处理器和存储有计算机程序的存储器，所述处理器执行所述程序时实现第一方面所述的用户画像数据处理方法的步骤。

第四方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现第一方面所述的用户画像数据处理方法的步骤。

本申请实施例提供的用户画像数据处理方法和装置，通过根据数据标识计算规则确定用户的实时数据对应的标签信息；确定待填充标签，根据待填充标签的类型从设定数据库中获取待填充标签；根据待填充标签、标签信息以及字段标识填充对象数据；根据对象数据以及标签的计算规则确定用户画像。本申请实施例减少了数据落地环节和全内存数据计算，使得减少了I/O消耗，通过实时画像填充的方式，提升了数据计算效率。

附图说明

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

图1是本申请实施例提供的用户画像数据处理方法的流程示意图之一；

图2是本申请实施例提供的用户画像数据处理方法的流程示意图之二；

图3是本申请实施例提供的用户画像数据处理方法的流程示意图之三；

图4是本申请实施例提供的用户画像数据处理方法的流程示意图之四；

图5是本申请实施例提供的用户画像数据处理方法的结构示意图；

图6是本申请实施例提供的消息转对象处理的流程示意图；

图7是本申请实施例提供的实时大数据填充的流程示意图；

图8是本申请实施例提供的规则计算方式的流程示意图；

图9是本申请实施例提供的画像多维计算过程的流程示意图；

图10是本申请实施例提供的号码哈希存储标签的结构示意图；

图11是本申请实施例提供的标签分桶存储的结构示意图；

图12是本申请实施例提供的计算槽位对应的随机4位字符的结构示意图；

图13是本申请实施例提供的Hbase全量标签的存储结构示意图；

图14是本申请实施例提供的用户画像数据处理装置的结构示意图；

图15是本申请实施例提供的电子设备的结构示意图。

具体实施方式

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

图1是本申请实施例提供的用户画像数据处理方法的流程示意图之一。参照图1，本申请实施例提供一种用户画像数据处理方法，可以包括：

步骤S10，根据数据标识计算规则确定用户的实时数据对应的标签信息；

需要说明的是，本申请实施例采用Redis数据库作为内存数据库、Hbase数据库作为实时计算中间缓存层，以Hbase辅助Redis实现全量的标签数据查询，通过线性扩展Hbase节点满足高并行的实时计算。其中，Redis是一个开源内存存储的数据结构服务器，可用作数据库，高速缓存和消息队列代理；HBase是一个分布式的、面向列的开源数据库。

具体地，根据数据标识计算规则确定用户的实时数据对应的标签信息，例如，采用数据标识计算规则对实时数据进行标签标注，得到实时数据中对应的标签信息，如性别、爱好、年龄等标签。

需要说明的是，数据标识计算规则以及标签计算规则是预先设置的，例如，启动flink程序时，对数据标识计算规则、热点标签计算规则进行加载，将数据计算规则加载至flink应用程序缓存，flink可以理解为是分布式处理框架。

其中，计算规则如下所示：

数据标识计算规则：

原始字段名、新字段名、计算规则、字段来源(原始字段、原始字段加工、来源画像)；

标签计算规则：

设定多条件表达方式，如：(a！＝xxx&&b！＝xxx)||c＝xxx，a、b、c为对象字段名，xxx为条件设定的值。

标签字段存放位置信息：

例如：标签1：Redis；标签2：Hbase；标签3：Hbase；

数据采用guava cache从数据库加载至flink应用内存，设定为10分钟更新一次，其中，guava cache是google开源的一款本地缓存工具库，使用多个segments方式的细粒度锁，在保证线程安全的同时，支持高并发场景需求，同时支持多种类型的缓存清理策略，包括基于容量的清理、基于时间的清理、基于引用的清理等。

在一个实施例中，预先构建用户的数据对象，以供便于后续计算处理。具体地，采用flink解析从kafka(开源流处理平台)读入的数据信息，通过设定的报文解析规则，采用JSON方式将报文数据映射到对象的字段中，构造用户的数据对象，如：位置信息、上网信息、订购信息等。例如，参考图6，图6是本申请实施例提供的消息转对象处理的流程示意图。接收JSON字符串(即JSON串)，检验JSON字符串，如果JSON字符串正确，则依据JSON字段构建对象，如果JSON字符串不正确，过滤非JSON字符串。

步骤S20，确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签；

需要说明的是，在对实时数据进行解析确定标签信息后，该标签信息可能还不能满足用户画像的需求，因此需要从设定数据库中获取标签，其中，设定数据库包括Redis数据库(即第一设定数据库)和Hbase数据库(即第二设定数据库)。

确定待填充标签，根据待填充标签的类型从设定数据库中获取待填充标签，其中，待填充标签可以理解为实时数据中没有的，但用户画像所需的标签。具体地，如果待填充标签的类型为热点标签，则从第一设定数据库中获取热点标签；如果待填充标签的类型为非热点标签，则从第二设定数据库中获取非热点标签，其中，待填充标签包括热点标签和非热点标签，设定数据库包括第一设定数据库和第二设定数据库，也即，从Redis数据库获取热点标签，从Hbase数据库获取非热点标签。通过待填充标签的类型从不同的数据库中获取标签，提高了标签的获取效率。

步骤S30，根据所述待填充标签、所述标签信息以及字段标识填充对象数据；

在确定填充标签信息后，根据待填充标签、标签信息以及字段标识填充对象数据，其中，字段标识用于标识标签数据的填充区域。例如，参考图7，在进行实时大数据填充时，根据数据标识计算规则，对来源画像的数据进行填充，依据字段的数据来源标识，自动路由至Redis或Hbase获取标签数据，将获取的信息填充于流信息，以备后续的计算使用。具体地，采用flink从kafka读取数据，按照设定的字段规则，进行报文解析，从原始报文中提取字段赋值于新对像字段，同时加载规则引擎，将需要做表达式计算的公式，转换成可执行实例，同时缓存于内存，以加速同类公式的流数据计算。然后，寻找需要Redis或Hbase填充的字段，将需要Hbase填充的字段的报文推回kafka，等待查询Hbase的流应用计算，以减少因Hbase查询速度慢，影响整体的实时计算效率，不需要Redis或Hbase填充或只需要Redis填充的数据，则继续下一步操作，如采用Redis查询标签填充数据。

步骤S40，根据所述对象数据以及标签的计算规则确定用户画像。

需要说明的是，用户画像是指根据用户的属性、用户偏好、生活习惯、用户行为等信息而抽象出来的标签化用户模型。

在填充对象数据后，根据对象数据以及标签的计算规则确定用户画像，具体地，根据标签的计算规则确定待计算标签，然后根据对象数据以及待计算标签确定用户画像。例如，在进行画像多维实时计算时，根据预先设定的数据标识，该数据标识为多个标签组合，将多个标签的数据实时填充于流数据中，设定相应的计算公式，例如：性别＝＝男&&终端＝＝iphone，依据公式得出的TURE或FLASE实时判断记录是否符合条件，同时将符合条件的数据输出，即用户画像数据，实现实时精准获取数据的效果，同时提高数据的计算效率。

根据从Redis或Hbase查询并填充的多维标签数据，依据预先设定的计算规则，提取该计算公式，依据图8提供的方式，将计算公式转换为Groovy脚本语言的类字段串，采用Groovy将脚本类动态转换为可执行的实例，再将计算公式对应的参数值代入计算公式，流应用代码执行其计算公式，得出TURE或FLASE的结果，将结果为TURE的数据进行输出，实现基于个体的实时精准营销以及与个体相关的实时大数据服务。

例如，参考图9，获取填充对象数据，假设标签为“男”和“青年人”，提取计算公式，根据该计算公式对标签进行计算，并转换公式为实例，同时缓存公式，通过流应用代码执行该计算公式，输出结果。

本申请实施例提供的用户画像数据处理方法，通过根据数据标识计算规则确定用户的实时数据对应的标签信息；确定待填充标签，根据待填充标签的类型从设定数据库中获取待填充标签；根据待填充标签、标签信息以及字段标识填充对象数据；根据对象数据以及标签的计算规则确定用户画像。本申请实施例减少了数据落地环节和全内存数据计算，使得减少了I/O消耗，通过实时画像填充的方式，提升了数据计算效率。

参考图2，图2是本申请实施例提供的用户画像数据处理方法的流程示意图之二。在本申请实施例中，确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签之前，还包括：

步骤S21，确定设定时间段内历史标签的使用频率，将所述使用频率大于或等于设定阈值的所述历史标签作为所述热点标签；

步骤S22，若所述热点标签不存在所述第一设定数据库，则将所述热点标签存储至所述第一设定数据库。

需要说明的是，热点标签是指使用频率比较高的标签，其中，可通过历史标签的使用情况提前预测各个时间段的热点标签。

在本申请实施例中，确定设定时间段内(如每周/每月)历史标签的使用频率，将使用频率大于或等于设定阈值的历史标签作为热点标签，如果热点标签不存在第一设定数据库，则将热点标签存储至第一设定数据库。例如，采用历史标签的使用频率，对每年每个月的标签使用情况，进行时间序列数据预测，提前预知当月使用量比较高的标签，并将使用量高的标签提前放于Redis数据库，采用定时小频率(如10分钟)计算当前标签的使用情况，即时将当前的热点标签切换至Redis数据库。具体地，基于时序数据预测热点标签，每月计算可能在当月使用量高的标签，并将该标签加载至Redis数据库，通过标签每年的使用规律，定义其周期为月，以其过去五年每月的标签使用总量为曲线的坐标点，通过其这一两年内的标签使用规律，预测标签使用走向，同时增加季节时序数据预测，结合月周期和季周期的标签使用量进行当月的标签使用量预测，进行增减内存数据库的标签数据，以满足热点标签的高速查询，同时对应更新数据标签对应的来源标识。

即时发现热点标签，采用定时器定时扫描标签的使用情况，对当前被检测出的热点标签通过Redis存储的标签列表判断，是否存在于内存数据库，如不存在，则将标签数据从标签数据库中抽取至Redis数据库，以备标签高速查询使用，同时对应更新数据标签对应的来源标识。

在一个实施例中，将使用频率小于设定阈值的历史标签作为非热点标签，然后删除第一设定数据库中的非热点标签。需要说明的是，为保证Redis数据库的最大效率，解决Redis数据库低存储高消耗，以及Redis数据库自动过期带来集群繁忙，影响整体集群计算性能的问题，本申请实施例采用预计算的方式，从历史标签使用数据中，筛选出经常被使用的热点标签，区别于Redis数据库自动过期机制，每隔一小时将新上线的热点标签导入至Redis数据库，同时每天清除非热点标签的标签数据，基于此，提高了Redis数据库的最大效率。

在一个实施例中，为实现在Redis数据库中快速地获取号码标签以及标签定位，本申请实施例采用哈希模型与可排序列表模型存储号码对应的标签，以及标签列表，例如，参考图10，图10是本申请实施例提供的号码哈希存储标签的结构示意图。

为充分发挥Redis集群节点的性能，加速标签定位效率，以可排序列表分桶方式，将标签分布到Redis数据库的16384槽位，以发挥匹配标签的最大性能，例如，参考图11，图11是本申请实施例提供的标签分桶存储的结构示意图。基于此，通过标签分桶存储，提高了标签的定位效率。

为保证槽位能分配到16384槽位中，采用随机4位字符，使用crc16算法计算值，对16384取余，筛选出0～16383对应的字符组合，作为可排序列表的key值，例如，参考图12，图12是本申请实施例提供的计算槽位对应的随机4位字符的结构示意图。基于此，通过计算槽位对应的随机4位字符，提高了槽位分配的准确性。

参考图3，图3是本申请实施例提供的用户画像数据处理方法的流程示意图之三。在本申请实施例中，所述根据数据标识计算规则确定用户的实时数据对应的标签信息之前，还包括：

步骤S11，根据用户的号码信息标识全量标签；

步骤S12，根据所述全量标签的类型对所述全量标签的数据进行存储，所述全量标签包括所述热点标签和所述非热点标签。

为减轻Redis数据库的存储压力，可将全量标签存储于高性能的查询Hbase数据库中，具体地，根据用户的号码信息标识全量标签，然后根据全量标签的类型对全量标签的数据进行存储。需要说明的是，由于Hbase数据库的查询性能较于Redis数据库要低很多，但Hbase数据库可以使用廉价的磁盘存储大数据，因此采用号码后3位+号码为rowkey方式存储号码对应的标签信息，将号码分为1000个分片，以加速查询性能，同时以多列的方式存储号码对应的标签，对标签进行类别划分，存放于不同的列簇，例如，参考图13，图13是本申请实施例提供的Hbase全量标签的存储结构示意图。

需要说明的是，全量标签包括热点标签和非热点标签，通过Hbase数据库存储全量标签，当缓存数据丢失时，可直接从Hbase数据库中读取全量标签，实现数据双重保障。

需要说明的是，在Hbase数据库中，按号码范围做数据分片，通过将数据分散到不同的Hbase存储节点，以多硬盘提高读取速度，提升Hbase的读性能。

本申请实施例通过根据用户的号码信息标识全量标签，然后根据全量标签的类型对全量标签的数据进行存储，基于此，减轻了Redis数据库的存储压力，实现数据双重保障。

参考图4，图4是本申请实施例提供的用户画像数据处理方法的流程示意图之四。在本申请实施例中，所述根据数据标识计算规则确定用户的实时数据对应的标签信息之前，还包括：

步骤S13，确定所述实时数据的数据特征；

步骤S14，根据所述数据特征确定所述数据标识计算规则。

具体地，确定实时数据的数据特征，例如数据话单类型、数据类别等，如在电信行业中，所涉及的开关机、订购、拨打/接听电话、收发短信等数据特征，然后根据数据特征确定数据标识计算规则，其中，数据标识计算规则如下所示：

1、获取话单对应的字段原始报文字段值，对应进行字段命名，例如号码定义为usrNbr，标识其从原始报文中提取；

2、原始报文加工后加段值，设定计算公式，例如从卡号标识中提取前5位，设定其表达式为：substring(卡号，0，6)，同时定义更多的表达式，例如日期计算、字符串拼接计算等，采用字符串动态定义运算表达式得同新的字段信息；

3、外部数据来源，依据规则中定义的画像标识，通过标识字段数据从guava cache获取数据来源信息，依据标签信息的来源进行数据路由，将数据取值方式定向于Hbase数据库或Redis数据库。

4、构建规则引擎，采用Groovy脚本语言，嵌入flink应用，以预生成类方式，将规则表达式嵌入至脚本，同时使用hashMap作为数据入参，设计共同的调用函数，同时以表达式为标识，缓存表达式生成的脚本转换的实例，以加速后续的数据计算。例如，参考图8，图8是本申请实施例提供的规则计算方式的流程示意图。具体地，首次加载计算规则，将加载的计算规则转换为Groovy脚本语言，再将Groovy脚本语言转换为java实例，对java实例进行实例缓存，然后依据传参执行实例，最后输出执行结果。

依据Groovy脚本的特点，采用词法分析，将表达式进行断句，例如以空格、操作符、括号为断句标识，分离变量、函数，依据预定义的变量类型，定义准确的类变量，在执行计算函数中通过变量名获取变量值，并转换为对应的变量类型，同时执行规则计算。

规则计算转换为class类，如a+b计算，需预定义a类型和b类型，如a定义为整型，b也定义为整型，则其类表示式为int a，b，定义其执行函数为execute，函数体实现为a＝(int)map.get(“a”)，b＝(int)map.get(“b”)，其函数返回值为return a+b；对于调用函数实现，预先定义公共工具类，采用静态函数的方式注入至Groovy脚本，在Groovy脚本生成的类字段串中，可直接定义函数，转换成可执行类时，在类中直接调用定义的静态函数，从而达到字符串转公式的目的，在Groovy中，采用parseClass的方式将动态字串转换成类实例，同时采用guava cache缓存可执行规则实例，同时动态更新规则，以达到规则变化，计算变化的效果，满足实时大数据计算效率。

本申请实施例通过确定实时数据的数据特征，然后根据数据特征确定数据标识计算规则，基于此，提高了数据的计算效率。

参考图5，图5是本申请实施例提供的用户画像数据处理方法的结构示意图。

在本申请实施例中，采用Redis数据库作为内存数据库、Hbase数据库作为实时计算中间缓存层，以Hbase辅助Redis实现全量的标签数据查询，通过线性扩展Hbase节点满足高并行的实时计算，具体实施步骤如下所示：

1、启动flink程序时，对数据标识计算规则、热点标签计算规则进行加载，将数据计算规则加载至flink应用程序缓存；

2、采用flink解析从kafka读入的数据信息，通过设定的报文解析规则，采用JSON方式将报文数据映射到对象的字段中，构造用户的数据对象；

3、依据实时数据的数据特征获取数据标识计算规则；

4、标签存储，例如，将热点标签存储至Redis数据库，将非热点标签(即冷标签)存储至Hbase数据库；

5、热点标签计算，例如，根据历史标签的使用信息预设不同时间段的热点标签；

6、实时大数据填充；

7、画像多维实时计算。

本申请实施例以Hbase数据库辅助Redis数据库实现全量的标签数据查询，通过线性扩展Hbase节点满足高并行的实时计算，基于此，提升了数据的实时性，减少了数据落地环节以及全内存数据计算，使得减少了I/O消耗，本申请可以满足大数据实时存储与计算需求，通过实时画像填充的方式，提升了数据计算效率，以备后续实时获取有价值的数据。

下面对本申请实施例提供的用户画像数据处理装置进行描述，下文描述的用户画像数据处理装置与上文描述的用户画像数据处理方法可相互对应参照。

参考图14，图14是本申请实施例提供的用户画像数据处理装置的结构示意图，本申请实施例提供的用户画像数据处理装置包括第一确定模块1401、第二确定模块1402、填充模块1403和第三确定模块1404。

第一确定模块1401，用于根据数据标识计算规则确定用户的实时数据对应的标签信息；

第二确定模块1402，用于确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签；

填充模块1403，用于根据所述待填充标签、所述标签信息以及字段标识填充对象数据；

第三确定模块1404，用于根据所述对象数据以及标签的计算规则确定用户画像。

本申请实施例提供的用户画像数据处理装置，通过根据数据标识计算规则确定用户的实时数据对应的标签信息；确定待填充标签，根据待填充标签的类型从设定数据库中获取待填充标签；根据待填充标签、标签信息以及字段标识填充对象数据；根据对象数据以及标签的计算规则确定用户画像。本申请实施例减少了数据落地环节和全内存数据计算，使得减少了I/O消耗，通过实时画像填充的方式，提升了数据计算效率。

在一个实施例中，所述第二确定模块1402具体用于：

若所述待填充标签的类型为热点标签，则从第一设定数据库中获取所述热点标签；

若所述待填充标签的类型为非热点标签，则从第二设定数据库中获取所述非热点标签；

其中，所述待填充标签包括所述热点标签和所述非热点标签，所述设定数据库包括所述第一设定数据库和所述第二设定数据库。

在一个实施例中，所述第二确定模块1402具体用于：

确定设定时间段内历史标签的使用频率，将所述使用频率大于或等于设定阈值的所述历史标签作为所述热点标签；

若所述热点标签不存在所述第一设定数据库，则将所述热点标签存储至所述第一设定数据库。

在一个实施例中，所述第二确定模块1402具体用于：

将所述使用频率小于所述设定阈值的所述历史标签作为非热点标签；

删除所述第一设定数据库中的所述非热点标签。

在一个实施例中，所述第一确定模块1401具体用于：

根据用户的号码信息标识全量标签；

根据所述全量标签的类型对所述全量标签的数据进行存储，所述全量标签包括所述热点标签和所述非热点标签。

在一个实施例中，所述第一确定模块1401具体用于：

确定所述实时数据的数据特征；

根据所述数据特征确定所述数据标识计算规则。

在一个实施例中，所述第三确定模块1404具体用于：

根据所述标签的计算规则确定待计算标签；

根据所述对象数据以及所述待计算标签确定所述用户画像。

图15示例了一种电子设备的实体结构示意图，如图15所示，该电子设备可以包括：处理器(processor)1510、通信接口(Communication Interface)1520、存储器(memory)1530和通信总线1540，其中，处理器1510，通信接口1520，存储器1530通过通信总线1540完成相互间的通信。处理器1510可以调用存储器1530中的计算机程序，以执行用户画像数据处理方法的步骤，例如包括：

根据数据标识计算规则确定用户的实时数据对应的标签信息；

确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签；

根据所述待填充标签、所述标签信息以及字段标识填充对象数据；

根据所述对象数据以及标签的计算规则确定用户画像。

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

另一方面，本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各实施例所提供的用户画像数据处理方法的步骤，例如包括：

根据数据标识计算规则确定用户的实时数据对应的标签信息；

确定待填充标签，根据所述待填充标签的类型从设定数据库中获取所述待填充标签；

根据所述待填充标签、所述标签信息以及字段标识填充对象数据；

根据所述对象数据以及标签的计算规则确定用户画像。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

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