数据仓库的信息获取方法和装置
技术领域
本申请涉及互联网领域,具体而言,涉及一种数据仓库的信息获取方法和装置。
背景技术
随着网络的发展,人们的生活离不开各种各样的网络账号,通常网络账号会和用户账户的手机号码、邮箱地址等信息绑定,这样用户账户在丢失或者忘记账号密码时可以通过手机号或者邮箱找回密码。在客户电话求助或找回账号密码时需要核实求助对方是否是账户本人,此时需要根据用户账户的历史信息或曾经的行为,以提问的方式进行验证,如:“你最近一次使用的手机号码是多少”、“你最近一次使用的邮箱地址是多少”等,只有用户账户输入正确的手机号或者邮箱地址才能确定是账户本人在进行操作。
目前在数据仓库中通用的查询方法是用当前用户账户信息和用户账户历史变更信息直接join关联,用当前的用户账户信息不等于历史信息记录作为条件来获取用户账户的变更的记录,再将获取的用户账户的变更的记录按时间排序并取用户账户最后一次的变更记录。
比如从4亿条当前用户账户记录和700亿条用户账户的历史变更记录中找出特定用户账户的最后一次的历史信息变更记录的查询方案是:用当前的用户账户信息(如手机号)与历史数据库中的信息逐一比对,获取所有与当前的手机号不同的手机号信息,所有记录不同手机号的信息中变更时间(如修改时间)最晚的为最后一次变更的记录。使用该方法获取当前用户账户的最后一次变更记录需要扫描14亿*700亿次用户账户变更记录的数据。实际测试中,该操作在5小时内未能完成,如果历史数据量达到千亿次级,那么该操作所耗费的时间会更长。
针对现有技术中获取用户账户的最后一次变更的账户信息的效率低的问题,目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种数据仓库的信息获取方法和装置,以至少解决现有技术中获取用户账户的最后一次变更的账户信息的效率低的技术问题。
根据本申请实施例的一个方面,提供了一种数据仓库的信息获取方法,该信息获取方法包括:服务器接收信息获取请求,信息获取请求用于请求获取用户账户最后一次发生变更的属性信息;获取用于记录用户账户的账户属性的第一信息集,其中,第一信息集包括多条属性变更信息,属性变更信息至少包括:变更账户属性的变更时间和变更属性参数;获取第一信息集对应的有序序列,其中,有序序列为按照变更时间排列的序列;提取有序序列中变更时间最晚的第一变更信息;读取有序序列中与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,以得到用户账户最后一次发生变更的属性信息。
根据本申请实施例的另一方面,还提供了一种数据仓库的信息获取装置,应用在服务器上,该信息获取装置包括:接收模块,用于接收信息获取请求,信息获取请求用于请求获取用户账户最后一次发生变更的属性信息;第一获取模块,用于获取用于记录用户账户的账户属性的第一信息集,其中,第一信息集包括多条属性变更信息,属性变更信息至少包括:变更账户属性的变更时间和变更属性参数;第二获取模块,用于获取第一信息集对应的有序序列,其中,有序序列为按照变更时间排列的序列;提取模块,用于提取有序序列中变更时间最晚的第一变更信息;读取模块,用于读取有序序列中与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,以得到用户账户最后一次发生变更的属性信息。
采用本申请,在服务器接收信息获取请求之后,获取用于记录用户账户的账户属性的第一信息集之后,获取记录账户属性的信息集的关于时间的有序序列,并提取该有序序列中变更时间最晚的第一变更信息,并从有序序列中读取与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息(也即最后一次变更的账户信息)。采用本申请,基于按照变更时间排序得到的序列,确定账户最后一次发生变更的属性信息,无需使用第一变更信息(当前账户的属性信息)与第一信息集中的属性变更信息进行匹配处理,即可快速获取用户账户最后一次发生变更的用户账户的属性信息,解决了现有技术中获取用户账户的最后一次变更的账户信息的效率低的问题,达到了快速获取用户账户的账户信息的效果。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是本申请实施例的一种计算机终端的示意图;
图2是根据本申请实施例的数据仓库的信息获取方法的流程图;
图3是根据本申请实施例的可选的数据仓库的信息获取方法的流程图;
图4是根据本申请实施例的数据仓库的信息获取装置的示意图;
图5是根据本申请实施例的一种数据仓库的信息获取装置的示意图;
图6是根据本申请实施例的一种可选的数据仓库的信息获取装置的示意图;
图7是根据本申请实施例的另一种可选的数据仓库的信息获取装置的示意图;以及
图8是根据本申请实施例的一种计算机终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
根据本申请实施例,提供了一种数据仓库的信息获取方法的方法实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
首先,在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释:
数据仓库:是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。
ODPS:中文名称是开放数据处理服务(Open Data Processing Service,简称ODPS),是阿里巴巴集团研发一种数据仓库工具。
hive:hive是基于Hadoop的一个开源数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的sql查询功能,可以将sql语句转换为MapReduce任务进行运行。
信息变更:用户账户信息出于客观事实或公司业务的需要,需要对用户账户信息修改。
用户账户绑定手机:用户账户在支付宝绑定的手机号,用户账户换手机号码会变更会员绑定手机信息。
join操作:在数据仓库中实现笛卡尔积的函数。
本申请实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例。如图1所示,计算机终端101可以为服务器,该服务器可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述电子装置的结构造成限定。例如,计算机终端101还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。
存储器104可用于存储应用软件的软件程序以及模块,如本申请实施例中的数据仓库的信息获取方法对应的程序指令/模块,处理器102通过运行存储在存储器104内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的数据仓库的信息获取方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至计算机终端101。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端101的通信供应商提供的无线网络。在一个实例中,传输装置106包括一个网络适配器(Network Interface Controller,NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置106可以为射频(Radio Frequency,RF)模块,其用于通过无线方式与互联网进行通讯。
在上述运行环境下,本申请提供了如图2所示的数据仓库的信息获取方法。图2是根据本申请实施例的数据仓库的信息获取方法的流程图。如图2所示,数据仓库的信息获取方法包括如下步骤:
步骤S202,服务器接收信息获取请求,信息获取请求用于请求获取用户账户最后一次发生变更的属性信息。
步骤S204,获取用于记录用户账户的账户属性的第一信息集。
步骤S206,获取第一信息集对应的有序序列。
步骤S208,提取有序序列中变更时间最晚的第一变更信息。
步骤S210,读取有序序列中与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,以得到用户账户最后一次发生变更的属性信息。
其中,第一信息集包括多条属性变更信息;属性变更信息至少包括:变更账户属性的变更时间和变更属性参数;有序序列为按照变更时间排列的序列。
采用本申请,在服务器接收信息获取请求之后,获取用于记录用户账户的账户属性的第一信息集之后,获取记录账户属性的信息集的关于时间的有序序列,并提取该有序序列中变更时间最晚的第一变更信息,并从有序序列中读取与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息(也即最后一次变更的账户信息)。采用本申请,基于按照变更时间排序得到的序列,确定用户账户最后一次发生变更的属性信息,无需使用第一变更信息(当前账户的属性信息)与第一信息集中的属性变更信息进行匹配处理,即可快速获取用户账户最后一次发生变更的用户账户的属性信息,解决了现有技术中获取用户账户的最后一次变更的账户信息的效率低的问题,达到了快速获取用户账户的账户信息的效果。
下面以用户账户为例详细介绍本申请:
服务器在接收到信息获取请求之后,从数据仓库中获取支付宝的用户账户的第一信息集,该第一信息集中可以包括多条属性变更信息,每条属性变更信息至少可以变更账户属性的变更时间和变更属性参数,其中,该变更属性参数可以为用户账户的手机号码、邮箱;在获取到第一信息集之后,获取与该第一信息集所对应的有序序列,该有序序列可以是第一信息集中的属性变更信息按照变更时间排序的序列,从而可以从该有序序列的队头或者队尾提取变更时间最晚的第一变更信息(即当前账户的属性信息),然后从有序序列中读取与该第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,以得到账户最后一次发生变更的属性信息(也即最后一次变更的账户信息)。
在上述实施例中,可以从按照时间顺序排序的有序序列中读取与该第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,而不用将当前用户账户的属性信息逐一与第一信息集中的属性变更信息进行比较,从而有效地节省获取用户账户最后一次发生变更的属性信息的时间,同时降低处理器的计算压力。
在上述实施例中,获取的第一信息集可以包括一个用户账户的属性变更信息,有序序列即用户账户的所有属性变更信息按照变更时间排序的序列,通过该有序序列即可得到支付宝的用户账户最后一次发生变更的属性信息。
在上述实施例中,属性变更信息还可以包括:账户标识,其中,获取第一信息集对应的有序序列可以包括:基于变更属性参数的第一属性值和账户标识对第一信息集进行去重,得到第二信息集;按照变更时间对第二信息集中的属性变更信息进行排序,得到有序序列。
可选地,获取的第一信息集也可以包括多个用户账户的属性变更信息,每个用户账户用不同的账户标识表示,从而可以根据各个用户账户的账户标识获取各个用户账户的最后一次发生变更的属性信息。
可选地,基于变更属性参数的第一属性值和账户标识对第一信息集进行去重,得到第二信息集可以包括:获取第一信息集中各条属性变更信息的账户标识、第一属性值和变更时间;获取将属性变更信息中账户标识相同、第一属性值相同且变更时间最晚的属性变更信息,得到第二信息集。获取有序序列中与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息可以包括:读取有序序列中与第一变更信息相邻的属性变更信息,得到第二变更信息。
在本申请的实施例中,变更属性参数可以包括:邮箱、手机号码或账户名称。可选地,变更属性参数还可以包括微博账号等。
上述实施例中的账户标识可以是系统赋予该账户的账户编码;变更属性参数可以包括用户账户的手机号、邮箱地址等。
下面以支付宝的用户账户为例详述本申请的实施例:
服务器接收到信息获取请求之后,从数据仓库中获取支付宝的用户账户的第一信息集,该第一信息集可以包含多个用户账户且每个用户账户对应有多条属性变更信息,每条属性变更信息至少可以包括账户标识、变更账户属性的变更时间以及变更属性参数,每条属性变更信息可以包括至少三个字段,该三个字段为账户标识字段、变更时间字段以及变更属性参数字段。
在获取到第一信息集之后,可以读取第一信息集中各条属性变更信息的账户标识、变更属性参数所对应的第一属性值以及变更时间,若同一个账户标识的一个第一属性值对应有多条属性变更信息,则获取其中变更时间最晚的属性变更信息,并存入第二信息集;若同一个账户标识的一个第一属性值只对应一条属性变更信息,则直接获取该属性变更信息,将其存入第二信息集。
在获取到第二信息集之后,可以根据账户标识获取第二信息集中该账户标识所对应的变更时间最晚的属性变更信息为第一变更信息,与该第一变更信息的变更时间最接近的属性变更信息即用户账户最后一次发生变更的属性信息,也即第二变更信息。具体地,可以在获取到第二信息集之后,对第二信息集中的属性变更信息按照变更时间的顺序进行排序以得到有序序列;在得到有序序列之后,获取该有序序列中变更时间最晚的属性变更信息为第一变更信息,与该第一变更信息相邻的属性变更信息即用户账户最后一次发生变更的属性信息,也即第二变更信息。
需要说明的是,在有序序列中的属性变更信息是按照变更时间进行排列的,因此,变更时间最晚的属性变更信息位于队首(或队头)或者队尾。
表1示出的是记录支付宝的两个用户账户的属性变更信息的历史变更信息集合,该信息集合包括十条属性变更信息,其属性变更信息至少可以包括账户标识、变更账户属性的变更时间以及变更属性参数,其中,变更属性参数至少可以包括手机号和邮箱地址。其中,用户账户的唯一的账户标识可以用“user_id”表示;可能发生变更的手机号可以用“Mobile_num”表示;可能发生变更的邮箱地址可以用“Email”表示;变更时间可以用“gmt_modified”表示。
表1
账户标识 |
手机号 |
邮箱地址 |
变更时间 |
2088XXXX0001 |
158XXXX0001 |
xxxxxx@qq.com |
2010-01-08 12:10:16 |
2088XXXX0001 |
158XXXX0001 |
xxxxxx@126.com |
2010-05-23 10:30:44 |
2088XXXX0001 |
159XXXX0041 |
xxxxxx@126.com |
2012-04-22 16:32:21 |
2088XXXX0001 |
159XXXX0041 |
xxxxxx@126.com |
2013-12-28 11:45:19 |
2088XXXX0001 |
159XXXX3428 |
xxxxxx@126.com |
2014-12-10 21:26:10 |
2088XXXX0002 |
136XXXX7043 |
xxxxxx@qq.com |
2011-03-06 11:32:55 |
2088XXXX0002 |
136XXXX7043 |
xxxxxx@163.com |
2011-05-23 10:32:46 |
2088XXXX0002 |
137XXXX5653 |
xxxxxx@sina.com |
2012-06-12 14:35:28 |
2088XXXX0002 |
137XXXX5653 |
xxxxxx@sina.com |
2013-12-24 12:45:43 |
2088XXXX0002 |
138XXXX4207 |
xxxxxx@sina.com |
2014-11-16 22:26:17 |
若需获取如表1所示的账户标识为“2088XXXX0001”的用户账户最后一次变更的手机号,则可以根据表1所示的历史变更信息集合获取第一信息集,具体地,可以根据属性字段“Mobile_num”、“user_id”以及“gmt_modified”从表1所示的数据集合中获取到如表2所示的第一信息集。
可选地,也可以直接获取表1所示的历史变更信息集合为第一信息集。
表2
账户标识 |
手机号 |
变更时间 |
2088XXXX0001 |
158XXXX0001 |
2010-01-08 12:10:16 |
2088XXXX0001 |
158XXXX0001 |
2010-05-23 10:30:44 |
2088XXXX0001 |
159XXXX0041 |
2012-04-22 16:32:21 |
2088XXXX0001 |
159XXXX0041 |
2013-12-28 11:45:19 |
2088XXXX0001 |
159XXXX3428 |
2014-12-10 21:26:10 |
2088XXXX0002 |
136XXXX7043 |
2011-03-06 11:32:55 |
2088XXXX0002 |
136XXXX7043 |
2011-05-23 10:32:46 |
2088XXXX0002 |
137XXXX5653 |
2012-06-12 14:35:28 |
2088XXXX0002 |
137XXXX5653 |
2013-12-24 12:45:43 |
2088XXXX0002 |
138XXXX4207 |
2014-11-16 22:26:17 |
在表2示出的第一信息集中,存在一个手机号对应一条属性变更信息的情况,也存在同一个手机号对应多条属性变更信息的情况,可以先对第一信息集中同一用户账户的包含相同手机号的属性变更信息进行去重,以得到第二信息集,具体可以根据账户标识(如账户标识)和第一属性值(如手机号)对第一信息集进行去重。对于同一个用户账户,若一个手机号对应一条属性变更信息,则直接该属性变更信息并存入第二信息集;若同一个手机号对应有多条属性变更信息,则获取多条属性变更信息中变更时间最晚的属性变更信息并存入第二信息集。从而可以得到第二信息集。
如表2所示,对于账户标识为“2088XXXX0001”的用户账户,值为“159XXXX3428”的手机号对应一条属性变更信息,值为“158XXXX0001”和“159XXXX0041”的手机号分别对应有两条属性变更信息,因此,可以分别对值为“158XXXX0001”和“159XXXX0041”的手机号所对应的属性变更信息去重。对于值为“158XXXX0001”的手机号,对应的两条属性变更信息的变更时间分别为“2010-01-0812:10:16”和“2010-05-2310:30:44”,经过比较,“2010-05-2310:30:44”比“2010-01-0812:10:16”更晚,即变更时间更大,因此,可以获取变更时间为“2010-05-2310:30:44”的属性变更信息并存入第二信息集中。因为只有一条属性变更信息对应于属性值为“159XXXX3428”的手机号,所以可以直接获取该属性变更信息并存入第二信息集。对于账户标识为“2088XXXX0002”的用户账户,可以使用与上述相同的去重方法去重,得到的第二信息集可以如表3所示。
表3
账户标识 |
手机号 |
变更时间 |
2088XXXX0001 |
158XXXX0001 |
2010-05-23 10:30:44 |
2088XXXX0001 |
159XXXX0041 |
2013-12-28 11:45:19 |
2088XXXX0001 |
159XXXX3428 |
2014-12-10 21:26:10 |
2088XXXX0002 |
136XXXX7043 |
2011-05-23 10:32:46 |
2088XXXX0002 |
137XXXX5653 |
2013-12-24 12:45:43 |
2088XXXX0002 |
138XXXX4207 |
2014-11-16 22:26:17 |
具体地,检测第一信息集中的不同用户账户的账户标识可以用SQL语言中的“group by”语句来实现,检测同一用户账户的绑定手机号信息是否重复也可以通过“groupby”语句来实现,获取同一手机号对应的多条属性变更信息中的变更时间最晚的属性变更信息可以通过“max()”函数来实现。
可以通过SQL语句“group by user_id=2088XXXX0001”筛选出表2中账户标识为“2088XXXX0001”的用户账户所对应的五条属性变更信息,可以通过SQL语句“group byMobile_num=158XXXX0001”筛选出该用户账户的属性变更信息中手机号为“158XXXX0001”的两条属性变更信息,然后通过函数“max(gmt_modified)”确定出上述两条属性变更信息中变更时间最晚的属性变更信息,即变更时间为“2010-05-2310:30:44”的属性变更信息,从而可以将该属性变更信息存入第二信息集中,若用户账户的手机号只对应一条属性变更信息,则直接将这条属性变更信息存入第二信息集中。
可选地,将第二信息集按照账户标识分组,然后再对每组内的属性变更信息按照变更时间由大到小的顺序进行排序。
具体地,可以用SQL语言中的“group by user_id”将如表3所示的第二信息集中的属性变更信息按照账户标识分为两组,然后可以用SQL语句“order by gmt_modifieddesc”将每个组的属性变更信息按照变更时间由大到小的顺序排列,得到的有序序列可以如表4所示。
表4
账户标识 |
手机号 |
变更时间 |
2088XXXX0001 |
159XXXX3428 |
2014-12-10 21:26:10 |
2088XXXX0001 |
159XXXX0041 |
2013-12-28 11:45:19 |
2088XXXX0001 |
158XXXX0001 |
2010-05-23 10:30:44 |
2088XXXX0002 |
138XXXX4207 |
2014-11-16 22:26:17 |
2088XXXX0002 |
137XXXX5653 |
2013-12-24 12:45:43 |
2088XXXX0002 |
136XXXX7043 |
2011-05-23 10:32:46 |
可选地,可以按照变更时间由大到小的顺序直接对如表3所示的第二信息的属性变更信息排序,以得到有序序列;也可以按照变更时间由小到大的顺序对属性变更信息排序。
通过上述实施例,可以对同一属性值(如同一手机号)所对应的多条属性变更信息去重,然后对属性变更信息进行排序,减少了信息数量,提高了查询效率,从而可以快速获取到账户最后一次发生变更的属性信息。
在上述实施例中,获取第一信息集对应的有序序列可以包括:按照变更时间对第一信息集中的属性变更信息进行倒序排序,得到有序序列。
在获取到第一信息集之后,可以直接对第一信息集中的属性变更信息按照变更时间由晚到早的顺序进行排序以得到有序序列。在得到有序序列之后,可以获取该有序序列中变更时间最晚的属性变更信息(即队头的属性变更信息)为第一变更信息,与该第一变更信息的变更时间最接近且变更属性参数的属性值不同的属性变更信息即对应的用户账户最后一次发生变更的属性信息,也即第二变更信息。
具体地,得到的第一信息集如表2所示,可以对表2所示的第一信息集按照变更时间由大到小的顺序排序(即倒序排序),可以得到如表5所示的有序序列。如表5所示,对于账户标识为“2088XXXX0001”的用户账户,变更时间最晚的属性变更信息(即变更时间为“2014-12-1021:26:10”所对应的属性变更信息)即该用户账户的当前信息(即第一变更信息),与第一变更信息的变更时间最接近的变更时间是“2013-12-2811:45:19”,其对应的手机号是“159XXXX0041”,不同于第一变更信息的“158XXXX0001”,因此,变更时间为“2013-12-2811:45:19”所对应的属性变更信息即该用户账户最后一次发生变更的属性信息。
表5
账户标识 |
手机号 |
变更时间 |
2088XXXX0001 |
159XXXX3428 |
2014-12-10 21:26:10 |
2088XXXX0002 |
138XXXX4207 |
2014-11-16 22:26:17 |
2088XXXX0001 |
159XXXX0041 |
2013-12-28 11:45:19 |
2088XXXX0002 |
137XXXX5653 |
2013-12-24 12:45:43 |
2088XXXX0002 |
137XXXX5653 |
2012-06-12 14:35:28 |
2088XXXX0001 |
159XXXX0041 |
2012-04-22 16:32:21 |
2088XXXX0002 |
136XXXX7043 |
2011-05-23 10:32:46 |
2088XXXX0002 |
136XXXX7043 |
2011-03-06 11:32:55 |
2088XXXX0001 |
158XXXX0001 |
2010-05-23 10:30:44 |
2088XXXX0001 |
158XXXX0001 |
2010-01-08 12:10:16 |
需要进一步说明的是,可以用SQL语句“order by gmt_modified desc”对如表2所示的第一信息集按照时间倒序的方式排列,得到如表5所示的有序序列。
可选地,可以按照变更时间从大到小的顺序(即倒序排序)对表2所示的第一信息集的属性变更信息排序;也可以根据变更时间从小到大的顺序(即顺序排序)对表2所示的第一信息集的属性变更信息排序。
可选地,在对表2中的信息排序之后,可以对表5所示的有序序列的同一账户标识对应的属性变更信息按照手机号去重,并按照账户标识进行分组。
通过上述实施例,可以直接对第一信息集按照时间进行排序,即可获取到最后一次发生变更的属性信息。
在上述实施例中,获取有序序列中变更时间最晚的第一变更信息可以包括:读取有序序列中排序为第一位的第一变更信息;或按照自增编号方式对有序序列中的各条属性变更信息进行编号,得到编号序列;读取编号序列中编号最小的第一变更信息。
表6
编号 |
账户标识 |
手机号 |
变更时间 |
1 |
2088XXXX0001 |
159XXXX3428 |
2014-12-10 21:26:10 |
2 |
2088XXXX0002 |
138XXXX4207 |
2014-11-16 22:26:17 |
3 |
2088XXXX0001 |
159XXXX0041 |
2013-12-28 11:45:19 |
4 |
2088XXXX0002 |
137XXXX5653 |
2013-12-24 12:45:43 |
5 |
2088XXXX0002 |
137XXXX5653 |
2012-06-12 14:35:28 |
6 |
2088XXXX0001 |
159XXXX0041 |
2012-04-22 16:32:21 |
7 |
2088XXXX0002 |
136XXXX7043 |
2011-05-23 10:32:46 |
8 |
2088XXXX0002 |
136XXXX7043 |
2011-03-06 11:32:55 |
9 |
2088XXXX0001 |
158XXXX0001 |
2010-05-23 10:30:44 |
10 |
2088XXXX0001 |
158XXXX0001 |
2010-01-08 12:10:16 |
具体地,可以对如表5所示的有序序列的各条属性变更信息进行编号,编号的顺序是由小到大,从而可以得到如表6所示的编号序列,其中,编号最小的属性变更信息即为第一变更信息,如表6所示,编号为1的属性变更信息即为账户标识为“2088XXXX0001”的用户账户的第一变更信息,编号为2的属性变更信息即为账户标识为“2088XXXX0002”的用户账户的第一变更信息。
需要进一步说明的是,获取用户账户的当前手机号可以用SQL语言中的“max(casewhen记录编号=1then手机号码else null end)”语句来实现,获取用户账户最后一次变更的手机号可以用SQL语言中的“max(case when记录编号=2then手机号码else null end)”语句来实现。
可选地,可以对如表5所示的有序序列按照编号由大到小的顺序编号,得到编号序列,其中,编号最大的属性变更信息即为第一变更信息。
可选地,可以对经过去重处理的如表4所示的有序序列按照编号是由大到小的顺序进行编号,在得到的编号序列中,编号为1的属性变更信息的手机号即为用户账户的当前手机号,编号为2的属性变更信息的手机号则为用户账户最后一次发生变更的手机号。
通过上述实施例,对信息集合采用记录行编号的形式进行过滤筛选,可以根据编号直接确定最后一次发生变更的属性信息。
下面将结合图3详述本申请的实施例。如图3所示:
步骤S302,获取全量用户账户历史变更记录的数据集合。
具体地,可以从数据仓库中获取到如表1所示的全量用户账户历史变更记录的数据集合,该数据集合包含两位用户账户的所有属性变更信息,其中,属性变更信息的变更属性参数可以包括用户账户绑定的手机号和邮箱地址。
需要进一步说明的是,将数据仓库中的数据通过脱敏加工以得到全量用户账户历史变更记录的数据集合。
步骤S304,获取账户标识、目标属性变更信息以及变更时间。
如表1示出的数据集合中的变更属性参数包括手机号和邮箱地址,若需获取的账户信息为用户账户最后一次变更的手机号,可以获取包括账户标识(如用户账户ID)、手机号以及变更时间的属性变更信息的第一信息集(如表2所示)。
可选地,若数据集合的变更属性参数包括账户标识、手机号、邮箱地址以及微博账号等,若需获取用户账户最后一次变更的邮箱地址,获取的第一信息集中的属性变更信息可以包括账户标识、邮箱地址以及变更时间。
步骤S306,根据账户标识进行去重处理,并获取变更时间最晚的属性变更信息。
具体地,可以通过逐一判断用户账户的绑定的手机号信息是否重复来判断该用户账户是否有重复的属性变更信息,若该用户账户的某一手机号只对应一条属性变更信息,则直接获取这一条属性变更信息并存入第二信息集;若该用户账户的某一手机号对应有多条属性变更信息,则获取多条属性变更信息中变更时间最晚的属性变更信息,如表2中账户标识为“2088XXXX0002”的用户账户,该用户账户的属性变更信息中有两条与值为“136XXXX7043”的手机号对应的属性变更信息,这两条属性变更信息对应的变更时间分别为“2011-03-0611:32:55”和“2011-05-2310:32:46”,经过比较,“2011-05-2310:32:46”比“2011-03-0611:32:55”更大,因此,获取变更时间为“2011-05-2310:32:46”的属性变更信息为手机号“158XXXX0001”对应的唯一的属性变更信息,并存入第二信息集中。
在上述实施例中,检测第一信息集中的不同用户账户的账户标识可以用SQL语言中的“group by”语句来实现,检测同一用户账户的绑定手机号信息是否重复也可以通过“group by”语句来实现,获取同一手机号对应的多条属性变更信息中的变更时间最晚的属性变更信息可以通过“max()”函数来实现。
需要进一步说明的是,SQL语言是一种结构化查询语言,用于存储数据以及查询、更新和管理关系数据库系统。本申请的技术方案至少可以通过hiveSQL和ODPSQL语言实现。
表7
账户标识 |
邮箱地址 |
变更时间 |
2088XXXX0001 |
xxxxxx@qq.com |
2010-01-08 12:10:16 |
2088XXXX0001 |
xxxxxx@126.com |
2010-05-23 10:30:44 |
2088XXXX0001 |
xxxxxx@126.com |
2012-04-22 16:32:21 |
2088XXXX0001 |
xxxxxx@126.com |
2013-12-28 11:45:19 |
2088XXXX0001 |
xxxxxx@126.com |
2014-12-10 21:26:10 |
2088XXXX0002 |
xxxxxx@qq.com |
2011-03-06 11:32:55 |
2088XXXX0002 |
xxxxxx@163.com |
2011-05-23 10:32:46 |
2088XXXX0002 |
xxxxxx@sina.com |
2012-06-12 14:35:28 |
2088XXXX0002 |
xxxxxx@sina.com |
2013-12-24 12:45:43 |
2088XXXX0002 |
xxxxxx@sina.com |
2014-11-16 22:26:17 |
可选地,若只需获取用户账户最后一次变更的邮箱地址,可以从表1中获取如表7所示的第一信息集,通过SQL语句“group by user_id=2088XXXX0002”筛选出表1中账户标识为“2088XXXX0002”的用户账户所对应的五条属性变更信息,然后可以通过SQL语句“group by Email=xxxxxx@sina.com”筛选出该用户账户的属性变更信息中邮箱地址为“xxxxxx@sina.com”的三条属性变更信息,然后通过函数“max(gmt_modified)”确定出三条属性变更信息中变更时间最晚的属性变更信息,即变更时间为“2014-11-1622:26:17”的属性变更信息,从而可以确定该属性变更信息为邮箱地址“xxxxxx@sina.com”所对应的唯一的属性变更信息。
步骤S308,根据账户标识进行分组,对同一账户标识的变更信息按照变更时间倒序排列,并进行编号。
对得到的用户账户属性变更信息(即变更记录集合数据)按账户标识进行分组,如对表3所示的第二信息集,可以根据账户标识的值(即“2088XXXX0001”和“2088XXXX0002”)将属性变更信息分为两组,然后对同一个账户标识的属性变更信息按照变更时间进行倒序排列,并对属性变更信息进行编号。
具体地,可以用SQL语言中的“group by user_id”将如表3所示的第二信息集中的属性变更信息按照账户标识进行分组,然后可以用SQL语句“order by gmt_modifieddesc”将分组完成后的属性变更信息按照时间倒序的方式排列,得到的有序序列如表4所示。
表8
编号 |
账户标识 |
手机号 |
变更时间 |
1 |
2088XXXX0001 |
159XXXX3428 |
2014-12-10 21:26:10 |
2 |
2088XXXX0001 |
159XXXX0041 |
2013-12-28 11:45:19 |
3 |
2088XXXX0001 |
158XXXX0001 |
2010-05-23 10:30:44 |
1 |
2088XXXX0002 |
138XXXX4207 |
2014-11-16 22:26:17 |
2 |
2088XXXX0002 |
137XXXX5653 |
2013-12-24 12:45:43 |
3 |
2088XXXX0002 |
136XXXX7043 |
2011-05-23 10:32:46 |
如表4所示,对每个组的属性变更信息按照编号从小到大的顺序编号,具体可以通过SQL函数“row_number()”来实现,得到的编号序列如表8所示。
步骤S310,编号为1的信息为第一变更信息(即当前信息),编号为2的信息为第二变更信息(即最后一次变更信息)。
如表8所示的编号序列,对于账户标识为“2088XXXX0001”的用户账户,值为“159XXXX3428”的手机号即为该用户账户的当前手机号,而值为“159XXXX0041”的手机号则为该用户账户最后一次变更的手机号。
需要进一步说明的是,获取用户账户的当前手机号可以用SQL语言中的“max(casewhen记录编号=1then手机号码else null end)”语句来实现,获取用户账户最后一次变更的手机号可以用SQL语言中的“max(case when记录编号=2then手机号码else null end)”语句来实现。
在一个可选的实施例中,也可以从全量历史变更记录的数据集合中获取只包含账户标识、手机号(目标获取的变更属性参数的信息)以及变更时间的属性变更信息,以得到第一信息集,在该实现方案中,第一信息集中没有包含不必要的信息(如邮箱地址),从而可以减少第一信息集的数据量。在获取第一信息集之后,基于手机号对同一用户账户的属性变更信息去重,得到第二信息集,可以进一步地缩减数据量;然后对第二信息集中的同一用户账户的属性变更信息按照时间顺序进行排序,得到有序序列,并直接从有序序列中读取包含用户账户当前手机号的属性变更信息和包含用户账户最后一次变更的手机号的属性变更信息。需要说明的是,在获取有序序列之后,可以按照有序序列中属性变更信息的次序对其编号,若有序序列是顺序排序,编号后的序列中编号为2的属性变更信息为用户账户最后一次变更的手机号。通过上述实施例,可以极大的提高获取用户账户的最后一次变更的账户信息的效率。
以支付宝的用户账户为例,变更属性参数(如用户账户绑定的手机号、邮箱地址以及绑定的微博账号等)中的任意一个发生变更,都会记录用户账户信息的变更时间,并记录一条新的用户账户信息,也即可以生成一条新的属性变更信息。因此,用户账户的数据仓库中的用户账户当前信息达到了14亿条,历史变更信息达到了700亿条,如需要获取用户账户最后一次变更前绑定的手机号,按照现有的技术手段,则需要在数据仓库中用当前用户账户信息和用户账户历史变更信息直接join关联,14亿条用户账户当前信息和700亿条历史变更信息做join操作的数据计算量是14亿*700亿次,在目前数据仓库中的join操作中,这样的计算量非常耗费时间,实际测试中,该join操作在5小时内未能完成。
采用本申请实施例提供的方法,只需对用户账户的历史变更信息进行去重、排序以及编号,就可以直接从编号序列中获取用户账户最后一次变更前绑定的手机号,通过上述方法处理时间短,极大的提高了处理效率。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的数据仓库的信息获取方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本申请各个实施例所述的方法。
实施例2
根据本申请实施例,还提供了一种用于实施上述数据仓库的信息获取方法的数据仓库的信息获取装置,该装置应用在服务器上,如图4所示,该装置包括:接收模块10、第一获取模块30、第二获取模块50、提取模块70以及读取模块90。
其中,接收模块10用于接收信息获取请求,信息获取请求用于请求获取用户账户最后一次发生变更的属性信息;第一获取模块30用于获取用于记录用户账户的账户属性的第一信息集,其中,第一信息集包括多条属性变更信息,属性变更信息至少包括:变更账户属性的变更时间和变更属性参数;第二获取模块50,用于获取第一信息集对应的有序序列,其中,有序序列为按照变更时间排列的序列;提取模块70,用于提取有序序列中变更时间最晚的第一变更信息;读取模块90,用于读取有序序列中与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,以得到用户账户最后一次发生变更的属性信息。
采用本申请,在接收模块接收到信息获取请求之后,第一获取模块获取用于记录用户账户的账户属性的第一信息集之后,第二获取模块获取记录账户属性的信息集的关于时间的有序序列,提取模块提取该有序序列中变更时间最晚的第一变更信息,然后读取模块从有序序列中读取与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息(也即最后一次变更的账户信息)。采用本申请,基于按照变更时间排序得到的序列,确定账户最后一次发生变更的属性信息,无需使用第一变更信息(当前账户的属性信息)与第一信息集中的属性变更信息进行匹配处理,即可快速获取用户账户最后一次发生变更的账户的属性信息,解决了现有技术中获取用户账户的最后一次变更的账户信息的效率低的问题,达到了快速获取用户账户的账户信息的效果。
下面以用户账户为例详细介绍本申请:
服务器的接收模块在接收到信息获取请求之后,从数据仓库中获取用户账户的第一信息集,该第一信息集中可以包括多条属性变更信息,每条属性变更信息至少可以包括变更账户属性的变更时间和变更属性参数,其中,该变更属性参数可以为用户账户手机号码、邮箱;在获取到第一信息集之后,获取与该第一信息集所对应的有序序列,该有序序列可以是第一信息集中的属性变更信息按照变更时间排序的序列,从可以从该有序序列的队头或者队尾提取变更时间最晚的第一变更信息为当前账户的属性信息,然后从有序序列中获取与该第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,可以得到账户最后一次发生变更的属性信息(也即最后一次变更的账户信息)。
在上述实施例中,可以从按照时间顺序排序的有序序列中读取与该第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,而不用将当前账户的属性信息逐一与第一信息集中的属性变更信息进行比较,从而可以有效地节省获取账户最后一次发生变更的属性信息的时间,同时降低处理器的计算压力。
在上述实施例中,属性变更信息还可以包括:账户标识,如图5所示,第二获取模块50可以包括:去重模块510,用于基于变更属性参数的第一属性值和账户标识对第一信息集进行去重,得到第二信息集;第一排序模块530,用于按照变更时间对第二信息集中的属性变更信息进行排序,得到有序序列。
可选地,如图6所示,去重模块510可以包括:第三获取模块511和第四获取模块313,其中,第三获取模块511用于获取第一信息集中各条属性变更信息的账户标识、第一属性值和变更时间;第四获取模块513用于获取将属性变更信息中账户标识相同、第一属性值相同且变更时间最晚的属性变更信息,得到第二信息集。读取模块可以包括第一读取子模块,第一读取子模块用于读取有序序列中与第一变更信息相邻的属性变更信息,得到第二变更信息。
可选地,变更属性参数可以包括:邮箱、手机号码或账户名称。
下面以用户账户为例详述本申请的实施例:
从数据仓库中获取用户账户的第一信息集,该第一信息集可以包含多个用户账户且每个用户账户对应有多条属性变更信息,每条属性变更信息至少可以包括账户标识、变更账户属性的变更时间以及变更属性参数。
在获取到第一信息集之后,还可以读取第一信息集中各条属性变更信息的账户标识、变更属性参数所对应的第一属性值以及变更时间,并读取属性变更信息中账户标识相同、第一属性值相同且变更时间最晚(也即变更时间最晚)的属性变更信息,将其存入第二信息集。
可选地,读取属性变更信息中账户标识相同、第一属性值相同且变更时间最晚的属性变更信息,将其存入第二信息集可以包括:若同一个账户标识的一个第一属性值对应有多条属性变更信息,则获取其中变更时间最晚的属性变更信息,并存入第二信息集;若同一个账户标识的一个第一属性值只对应一条属性变更信息,则直接获取该属性变更信息,将其存入第二信息集。
在获取到第二信息集之后,可以根据账户标识获取第二信息集中该账户标识所对应的变更时间最晚的属性变更信息为第一变更信息,与该第一变更信息的变更时间最接近的属性变更信息即用户账户最后一次发生变更的属性信息,也即第二变更信息。具体地,可以在获取到第二信息集之后,对第二信息集中的属性变更信息按照变更时间的顺序进行排序以得到有序序列;在得到有序序列之后,获取该有序序列中变更时间最晚的属性变更信息为第一变更信息,与该第一变更信息相邻的属性变更信息即用户账户最后一次发生变更的属性信息,也即第二变更信息。
需要说明的是,在有序序列中的属性变更信息是按照变更时间进行排列的,因此,变更时间最晚的属性变更信息位于队头或者队尾。
通过上述实施例,可以对同一属性值(如同一手机号)所对应的多条属性变更信息去重,然后对属性变更信息进行排序,减少了信息数量,提高了查询效率,从而可以快速获取到账户最后一次发生变更的属性信息。
可选地,第二获取模块可以包括第二排序模块,第二排序模块用于按照变更时间对第一信息集中的属性变更信息进行倒序排序,得到有序序列。
通过上述实施例,可以直接对第一信息集按照时间进行排序,即可获取到最后一次发生变更的属性信息。
在获取到第一信息集之后,可以直接对第一信息集中的属性变更信息按照变更时间的顺序进行排序以得到有序序列。在得到有序序列之后,获取该有序序列中变更时间最晚的属性变更信息为第一变更信息,与该第一变更信息的变更时间最接近且变更属性参数的属性值不同的属性变更信息即对应的用户账户最后一次发生变更的属性信息,也即第二变更信息。
在上述实施例中,如图7所示,提取模块70可以包括:第二读取子模块710,用于读取有序序列中排序为第一位的第一变更信息;或处理子模块730,用于按照自增编号方式对有序序列中的各条属性变更信息进行编号,得到编号序列;第三读取子模块750,用于读取编号序列中编号最小的第一变更信息。
通过上述实施例,对有序序列进行编号,从而可以直接确定最大的编号或者最小的编号所对应的属性变更信息即第一变更信息。
在一个可选的实施例中,也可以从全量历史变更记录的数据集合中获取只包含账户标识、手机号(目标获取的变更属性参数的信息)以及变更时间的属性变更信息,以得到第一信息集,在该实现方案中,第一信息集中没有包含不必要的信息(如邮箱地址),从而可以减少第一信息集的数据量。在获取第一信息集之后,基于手机号对同一用户账户的属性变更信息去重,得到第二信息集,可以进一步地缩减数据量;然后对第二信息集中的同一用户账户的属性变更信息按照时间顺序进行排序,得到有序序列,并直接从有序序列中读取包含用户账户当前手机号的属性变更信息和包含用户账户最后一次变更的手机号的属性变更信息。需要说明的是,在获取有序序列之后,可以按照有序序列中属性变更信息的次序对其编号,若有序序列是顺序排序,编号后的序列中编号为2的属性变更信息为用户账户最后一次变更的手机号。通过上述实施例,可以极大的提高获取用户账户的最后一次变更的账户信息的效率。
实施例3
本申请的实施例可以提供一种计算机终端,该计算机终端可以是计算机终端群中的任意一个计算机终端设备,如服务器。可选地,在本实施例中,上述计算机终端也可以替换为移动终端等终端设备。
可选地,在本实施例中,上述计算机终端可以位于计算机网络的多个网络设备中的至少一个网络设备。
可选地,图8是根据本申请实施例的一种计算机终端的结构框图,如图8所示,该计算机终端101可以包括:一个或多个(图中仅示出一个)处理器102、存储器104、数据总线105以及输入输出设备107。
其中,存储器可用于存储软件程序以及模块,如本申请实施例中的数据仓库的信息获取方法和装置对应的程序指令/模块,处理器通过运行存储在存储器内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的数据仓库的信息获取方法。存储器可包括高速随机存储器,还可以包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器可进一步包括相对于处理器远程设置的存储器,这些远程存储器可以通过网络连接至上述计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
处理器可以通过传输装置调用存储器存储的信息及应用程序,以执行下述步骤:服务器接收信息获取请求,信息获取请求用于请求获取用户账户最后一次发生变更的属性信息;获取用于记录用户账户的账户属性的第一信息集;获取第一信息集对应的有序序列;提取有序序列中变更时间最晚的第一变更信息;读取有序序列中与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,以得到用户账户最后一次发生变更的属性信息。
可选地,上述处理器还可以执行如下步骤的程序代码:基于变更属性参数的第一属性值和账户标识对第一信息集进行去重,得到第二信息集;按照变更时间对第二信息集中的属性变更信息进行排序,得到有序序列。
可选地,上述处理器还可以执行如下步骤的程序代码:获取第一信息集中各条属性变更信息的账户标识、第一属性值和变更时间;获取将属性变更信息中账户标识相同、第一属性值相同且变更时间最晚的属性变更信息,得到第二信息集。
可选地,上述处理器还可以执行如下步骤的程序代码:读取有序序列中排序为第一位的第一变更信息;或按照自增编号方式对有序序列中的各条属性变更信息进行编号,得到编号序列;读取编号序列中编号最小的第一变更信息。。
采用本申请,在服务器接收信息获取请求之后,获取用于记录用户账户的账户属性的第一信息集之后,获取记录账户属性的信息集的关于时间的有序序列,并提取该有序序列中变更时间最晚的第一变更信息,并从有序序列中读取与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息(也即最后一次变更的账户信息)。采用本申请,基于按照变更时间排序得到的序列,确定账户最后一次发生变更的属性信息,无需使用第一变更信息(当前账户的属性信息)与第一信息集中的属性变更信息进行匹配处理,即可快速获取用户账户最后一次发生变更的用户账户的属性信息,解决了现有技术中获取用户账户的最后一次变更的账户信息的效率低的问题,达到了快速获取用户账户的账户信息的效果。
本领域普通技术人员可以理解,图8所示的结构仅为示意,计算机终端也可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(MobileInternet Devices,MID)、PAD等终端设备。图8其并不对上述电子装置的结构造成限定。例如,计算机终端101还可包括比图8中所示更多或者更少的组件(如网络接口、显示装置等),或者具有与图8所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:闪存盘、只读存储器(Read-Only Memory,ROM)、随机存取器(RandomAccess Memory,RAM)、磁盘或光盘等。
实施例4
本申请的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以用于保存上述实施例一所提供的数据仓库的信息获取方法所执行的程序代码。
可选地,在本实施例中,上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中,或者位于移动终端群中的任意一个移动终端中。
可选地,在本实施例中,存储介质被设置为存储用于执行以下步骤的程序代码:服务器接收信息获取请求,信息获取请求用于请求获取用户账户最后一次发生变更的属性信息;获取用于记录用户的账户属性的第一信息集;获取第一信息集对应的有序序列;提取有序序列中变更时间最晚的第一变更信息;读取有序序列中与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息,以得到用户账户最后一次发生变更的属性信息。
可选地,在本实施例中,存储介质还被设置为存储用于执行以下步骤的程序代码:基于变更属性参数的第一属性值和账户标识对第一信息集进行去重,得到第二信息集;按照变更时间对第二信息集中的属性变更信息进行排序,得到有序序列。
可选地,在本实施例中,存储介质还被设置为存储用于执行以下步骤的程序代码:获取第一信息集中各条属性变更信息的账户标识、第一属性值和变更时间;获取将属性变更信息中账户标识相同、第一属性值相同且变更时间最晚的属性变更信息,得到第二信息集。
可选地,在本实施例中,存储介质还被设置为存储用于执行以下步骤的程序代码:读取有序序列中排序为第一位的第一变更信息;或按照自增编号方式对有序序列中的各条属性变更信息进行编号,得到编号序列;读取编号序列中编号最小的第一变更信息。
采用本申请,在服务器接收信息获取请求之后,获取用于记录用户账户的账户属性的第一信息集之后,获取记录账户属性的信息集的关于时间的有序序列,并提取该有序序列中变更时间最晚的第一变更信息,并从有序序列中读取与第一变更信息的变更时间最接近且变更属性参数的属性值不同的第二变更信息(也即最后一次变更的账户信息)。采用本申请,基于按照变更时间排序得到的序列,确定账户最后一次发生变更的属性信息,无需使用第一变更信息(当前账户的属性信息)与第一信息集中的属性变更信息进行匹配处理,即可快速获取用户账户最后一次发生变更的用户账户的属性信息,解决了现有技术中获取用户账户的最后一次变更的账户信息的效率低的问题,达到了快速获取用户账户的账户信息的效果。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
在本申请的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。