具体实施方式
为了使得本公开的目的、技术方案和优点更加清楚,下面将结合本公开的附图,对本公开的技术方案进行清楚、完整地描述。显然,所描述的实施例是本公开的一部分实施例,而不是全部的实施例。基于所描述的本公开的实施例,本领域普通技术人员在无需创造性劳动的前提下所获取的所有其他实施例,都属于本公开保护的范围。
除非另外定义,本公开使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性,而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同,而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接,而是可以包括电性的连接,不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系,当被描述对象的绝对位置改变后,则该相对位置关系也可能相应地改变。
为了保持本公开的以下说明清楚且简明,本公开省略了已知功能和已知部件的详细说明。
图1是根据本公开一示例性实施例示出的一种用户群体画像的构建方法的流程图。图1的方法可以由服务器等设备执行,如图1所示,该方法包括:
S110:将用户群体的历史数据进行缓存。
在本公开实施例中,服务器获取用户群体的全量的历史数据,并将该历史数据进行缓存。具体地,服务器可以是一台服务器,也可以是由若干台服务器组成的服务器集群,或者还可以是一个云计算服务中心,本公开对此不作限制。用户群体中的每个用户可以是视频共享用户、主播用户、文章共享用户或其他类型用户。
历史数据可以包括但不限于用户基本信息、观看用户量、现金收入量、粉丝数量、播出时间偏好、播出时长、地域分布中的一种或多种。进一步地,对于上述的视频共享用户,历史数据可以包括视频点击量、现金收入量、粉丝数量、视频播放时长等数据;对于上述的主播用户,历史数据可以包括观看用户量、现金收入量、粉丝数量、主播播放时长等数据;对于上述的文章共享用户,历史数据可以包括文章点击量、现金收入量及粉丝数量等数据。
进一步地,缓存是指可以进行高速数据交换的存储器,其先于内存与中央处理器(Central Processing Unit,CPU)交换数据,因此,速率很快。缓存的工作原理是当CPU要读取一个数据时,首先从CPU缓存中查找,如果找到,则立即读取并送给CPU处理;如果未找到,则从速率相对较慢的内存中读取并送给CPU处理,同时把这个数据所在的数据块调入缓存中,可以使得以后对整块数据的读取都从缓存中进行,不必再调用内存。
需要说明的是,上述历史数据的具体类型仅为针对不同用户的示例性说明,当该方法应用于其他类型的用户时,也可获取其他类型的用户的历史数据。此外,还需要说明的是,历史数据通常存储在服务器、由多台计算机组成的计算机集群或其他装置中,获取历史数据的过程为从上述装置中提取数据的过程。
S120:确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中。
在本公开实施例中,服务器确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中。
具体地,用户群体目录可以包括但不限于用户群体中的每个用户的用户ID;进一步地,在确定预定用户群体的用户群体目录之后,服务器将预定用户群体中的所有用户ID存储在查询引擎中。这里,查询引擎可以包括但不限于Hive、Impala、Shark/Spark、Stinger、Presto、Druid、ClickHouse等。在该实施例中,查询引擎优选为ClickHouse查询引擎。
ClickHouse是用于联机分析处理(Online Analytical Processing,OLAP)的列式数据库管理系统(column-oriented DataBase Management System,Column-orientedDBMS),其解决了传统数据库在数据量较大情况下查询缓慢的问题。进一步地,ClickHouse至少包括以下优点:数据需要以大批次(大于1000行)进行更新,而不是单行更新,或者根本没有更新操作;数据仅仅是添加到数据库中,而不需要修改;在读取数据时,会从数据库中提取出大量的行,而仅涉及到一小部分列;查询频率相对较低(通常每台服务器每秒查询数百次或更少),对于简单查询,允许大约50毫秒的延迟等。
需要说明的是,用户群体目录不限于如上所述的存储在查询引擎中,而是可以存储在诸如MySQL、Oracle、Sybase、dBASE、DB2的数据库或诸如Redis的key-value存储系统中,本公开对此不作限制。此外,还需要说明的是,本公开的ClickHouse查询引擎中仅存储了包括用户ID的用户群体目录,由于用户群体目录中存储的用户信息项相对较少,因此,能够实现用户群体数据的快速查询。
S130:基于用户群体的历史数据和用户群体目录,构建预定用户群体的用户群体画像。
在本公开实施例中,服务器通过表连接(join)方式将用户群体的历史数据与预定用户群体的用户群体目录中的用户ID进行匹配,以查找与用户ID对应的用户群体数据,并基于该用户群体数据构建预定用户群体的用户群体画像。
具体地,表连接是将一张表中的行按照某个条件(连接条件)与另一张表中的行连接以形成新的行的过程;表连接可以根据连接查询返回的结果分为内连接(inner join)、外连接(outer join)和交叉连接(cross join);也可以根据连接条件所使用的操作符分为相等连接(使用等号操作符)和不等连接(不使用等号操作符)。
进一步地,内连接只返回两张表中所有满足连接条件的行,即使用比较运算符根据每个表中共有的列的值匹配两个表中的行;外连接不但可以返回符合连接和查询条件的数据行,而且还返回不符合条件的一些行,外连接包括左外连接、右外连接和全外连接;交叉连接也称笛卡尔积,因为没有连接条件,所进行的表与表间的所有行的连接。
根据本公开实施例提供的技术方案,通过将用户群体的历史数据进行缓存;确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中;基于用户群体的历史数据和用户群体目录,构建用户群体的用户群体画像,能够帮助快速找到精准用户群体以及用户需求等更为广泛的反馈信息,因此,简化了用户操作,并进一步提升了用户体验。
在本公开的另一个实施例中,在步骤S110的将用户群体的历史数据进行缓存的过程,包括:对用户群体中的每个用户的历史数据进行特征提取,获取每个用户的属性标签和特征数据;将每一个用户的属性标签和特征数据按照第一预定顺序进行缓存,获取用户群体的多维度数据表。
具体地,在将用户群体的历史数据进行缓存之前,服务器获取用户群体的历史数据,并对用户群体中的每一个用户的历史数据进行特征提取,获取每一个用户的属性标签和特征数据。
这里,特征提取是指从原始特征中找出最有效(同类样本的不变性、不同样本的鉴别性、对噪声的鲁棒性)的特征,特征提取的目的在于获取用户群体的属性标签和特征数据,以便后续基于属性标签和特征数据获取用户群体的多维度数据表,从而能够根据多维度数据表描述用户群体画像。属性标签可以包括但不限于年龄、性别、学历、地域、偏好、才艺类型中的一种或多种;特征数据可以包括但不限于主页浏览次数、粉丝数量、播出时间偏好、播出时长、地域分布中的一种或多种。
进一步地,使用协同过滤算法、最大最小距离算法、逻辑回归算法中的一种对属性标签和特征数据进行数据清洗,得到高质量的用户群体数据;这里,数据清洗是对数据进行重新审查和校验的过程,目的在于删除重复信息、纠正存在的错误,并提供数据一致性。
最后,将每一个用户的属性标签和特征数据按照第一预定顺序进行缓存,获取用户群体的多维度数据表。这里,第一预定顺序可以是用户预先设置的顺序,也可以是服务器默认的顺序,本公开对此不作限制。
在本公开的另一个实施例中,用户群体目录包括预定用户群体中的每个用户的用户ID,确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中,包括:选取符合预定条件的用户群体;将用户群体中的所有用户ID按照第二预定顺序存储在查询引擎中。
具体地,用户群体目录可以包括但不限于预定用户群体中的每个用户的用户ID,例如还可以包括每个用户的用户昵称、粉丝数量、地域分布等,本公开对此不作限制。在该实施例中,用户群体目录优选地仅包括每个用户的用户ID,以实现用户群体数据的快速查询。
进一步地,从用户群体中选取符合预定条件的预定用户群体,并将预定用户群体中的所有用户ID按照第二预定顺序存储在查询引擎中。这里,预定条件可以是预先设置的查询条件,例如,性别分布、年龄分组等;第二预定顺序可以是用户预先设置的顺序,也可以是服务器默认的顺序,本公开对此不作限制。
在本公开的另一个实施例中,基于用户群体的历史数据和用户群体目录,构建用户群体的用户群体画像,包括:将用户群体目录中的每个用户ID与多维度数据表进行表连接;在多维度数据表中通过查询引擎查询预定用户群体的用户群体数据。此外,在构建用户群体的用户群体画像之后,可以按照例如第三预定顺序展示表示用户群体画像的用户群体数据。
具体地,将用户群体目录中的每个用户的用户ID与多维度数据表进行表连接,得到用户群体数据;进一步地,在多维度数据表中通过根据预订用户群体的用户ID查询预定用户群体的用户群体数据,最后得到预定用户群体的用户群体数据。
上述所有可选技术方案,可以采用任意结合形成本公开的可选实施例,在此不再一一赘述。
图2是根据本公开另一个示例性实施例示出的一种用户群体画像的构建方法的流程图。如图2所示,该方法包括:
S210:获取用户群体的历史数据;
S220:对用户群体中的每个用户的历史数据进行特征提取,获取每个用户的属性标签和特征数据;
S230:将每个用户的属性标签和特征数据按照第一预定顺序进行缓存,获取用户群体的多维度数据表;
S240:选取符合预定条件的预定用户群体;
S250:将预定用户群体中的所有用户ID按照第二预定顺序存储在查询引擎中;
S260:将所有用户ID中的每个用户ID与多维度数据表进行表连接;
S270:在多维度数据表中通过查询引擎查询预定用户群体的用户群体数据。
根据本公开实施例提供的技术方案,通过获取用户群体的历史数据;对用户群体中的每一个用户的历史数据进行特征提取,获取每一个用户的属性标签和特征数据;将每一个用户的属性标签和特征数据按照预定顺序进行缓存,获取用户群体的多维度数据表;从用户群体的多维度数据表中选取符合预定条件的用户群体;将用户群体中的所有用户ID按照预定顺序存储在查询引擎中;将所有用户ID中的每个用户ID与多维度数据表进行表连接;在多维度数据表中通过查询引擎查询用户群体的用户群体数据;最后在构建用户群体的用户群体画像之后,可以按照第三预定顺序展示表示用户群体画像的用户群体数据,这样,能够帮助快速找到精准用户群体以及用户需求等更为广泛的反馈信息,能够快速构建用户群体画像,因此,简化了用户操作,并进一步提升了用户体验。
下述为本公开装置实施例,可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节,请参照本公开方法实施例。
图3是根据本公开一示例性实施例示出的一种用户群体画像的构建装置的框图。如图3所示,该装置包括:
缓存模块310,用于将用户群体的历史数据进行缓存;
确定模块320,确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中;
构建模块330,用于基于用户群体的历史数据和用户群体目录,构建预定用户群体的用户群体画像。
根据本公开实施例提供的技术方案,通过将用户群体的历史数据进行缓存;确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中;基于用户群体的历史数据和用户群体目录,构建预定用户群体的用户群体画像,能够帮助快速找到精准用户群体以及用户需求等更为广泛的反馈信息,能够快速构建用户群体画像,因此,简化了用户操作,并进一步提升了用户体验。
在本公开的另一个实施例中,缓存模块310包括:提取单元,用于对用户群体中的每一个用户的历史数据进行特征提取,获取每一个用户的属性标签和特征数据;缓存单元,用于将每一个用户的属性标签和特征数据按照第一预定顺序进行缓存,获取用户群体的多维度数据表。
在本公开的另一个实施例中,用户群体目录包括预定用户群体中的每个用户的用户ID,确定模块320包括:选取单元,用于选取符合预定条件的预定用户群体;存储单元,用于将预定用户群体中的所有用户ID按照预定顺序存储在查询引擎中。
在本公开的另一个实施例中,构建模块330包括:连接单元,用于将用户群体目录中的每个用户ID与多维度数据表进行表连接;查询单元,用于在多维度数据表中通过查询引擎查询预定用户群体的用户群体数据。
在本公开的一个实施例中,查询引擎为ClickHouse查询引擎。
在本公开的另一个实施例中,属性标签包括年龄、性别、地域、才艺类型中的至少一种。
在本公开的另一个实施例中,特征数据包括粉丝数量、播出时间偏好、播出时长、地域分布中的至少一种。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
图4是根据本公开一示例性实施例示出的一种电子设备400的框图。如图4所示,该电子设备400至少包括存储器410和处理器420,存储器410上存储有计算机程序,处理器420在执行存储器410上的计算机程序时实现如上所述的实施例提供的方法。
具体地,该方法包括:处理器420将用户群体的历史数据进行缓存;确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中;基于用户群体的历史数据和用户群体目录,构建用户群体的用户群体画像。
在本公开一个实施例中,用户群体目录包括预定用户群体中的每个用户的用户ID,处理器420选取符合预定条件的预定用户群体;将预定用户群体中的所有用户ID按照预定顺序存储在查询引擎中。
在本公开的一个实施例中,处理器420将用户群体目录中的每个用户ID与多维度数据表进行表连接;在多维度数据表中通过查询引擎查询预定用户群体的用户群体数据。
在本公开的一个实施例中,属性标签包括年龄、性别、地域、才艺类型中的至少一种。
在本公开的一个实施例中,特征数据包括粉丝数量、播出时间偏好、播出时长、地域分布中的至少一种。
根据本公开实施例提供的技术方案,通过将用户群体的历史数据进行缓存;确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中;基于用户群体的历史数据和用户群体目录,构建预定用户群体的用户群体画像,能够帮助快速找到精准用户群体以及用户需求等更为广泛的反馈信息,能够快速构建用户群体画像,因此,简化了用户操作,并进一步提升了用户体验。
本公开还提供了一种存储介质,当存储介质中的指令由上述装置400的处理器执行时,使得上述装置400能够执行一种用户群体画像的构建方法,包括:将用户群体的历史数据进行缓存;确定预定用户群体的用户群体目录,并将用户群体目录存储在查询引擎中;基于用户群体的历史数据和用户群体目录,构建用户群体的用户群体画像。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本公开的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或者不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性、机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序校验码的介质。
此外,尽管已经在本文中描述了示例性实施例,其范围包括任何和所有基于本公开的具有等同元件、修改、省略、组合(例如,各种实施例交叉的方案)、改编或改变的实施例。权利要求书中的元件将被基于权利要求中采用的语言宽泛地解释,并不限于在本说明书中或本申请的实施期间所描述的示例,其示例将被解释为非排他性的。因此,本说明书和示例旨在仅被认为是示例,真正的范围和精神由以下权利要求以及其等同物的全部范围所指示。
以上对本公开多个实施例进行了详细说明,但本公开不限于这些具体的实施例,本领域技术人员在本公开构思的基础上,能够做出多种变型和修改实施例,这些变型和修改都应落入本公开所要求保护的范围之内。