CN107798037A - 用户特征数据的获取方法及服务器 - Google Patents

Abstract

本发明提供了一种用户特征数据的获取方法及服务器，适用于互联网技术领域，该方法包括：将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；利用计算引擎对已同步的用户基础数据进行分析汇总，得到与各个用户分别对应的特征数据；基于用户属性库的接口，获取业务系统发出的数据访问请求；对所述数据访问请求的合法性进行验证，若数据访问请求合法，则将与数据访问请求匹配的用户的特征数据返回至业务系统。本发明在多业务数据库分离的情况下，能快速地解析出各个用户分别对应的特征数据，实现了对用户特征数据的全面评估，不会影响到现有业务系统的运行，为用户个性化的业务定制以及业务推荐等功能提供了准确的数据支持。

Description

用户特征数据的获取方法及服务器

技术领域

本发明属于互联网技术领域，尤其涉及一种用户特征数据的获取方法及服务器。

背景技术

随着企业信息化的发展，大部分企业都拥有了自己的业务系统。例如，金融保险公司拥有寿险投保系统、财险投保系统以及客户个人信息系统等各类型的业务系统。每个业务系统都有自己的独立数据库，分别存储着企业在该业务方面的运行数据。

然而，如果仅从一个独立数据库上查询业务系统的报表数据，则难以对用户的特征信息进行全面地评估，无法为用户个性化的业务定制以及业务推荐等功能提供数据支持。在跨多个业务数据库且业务数据量过大的情况之下，业务系统无法快速地解析出多维的用户特征分析结果，从而容易影响到业务系统的稳定运行。

综上，现有技术中，在多业务数据库分布的情况下，存在难以快速获取多维的用户特征数据的问题。

发明内容

有鉴于此，本发明实施例提供了用户特征数据的获取方法及服务器，以解决现有技术中，在多业务数据库分布的情况下，难以快速获取多维的用户特征数据的问题。

本发明实施例的第一方面提供了一种用户特征数据的获取方法，包括：

将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；

利用计算引擎对已同步的用户基础数据进行分析汇总，得到与各个用户分别对应的特征数据；

基于所述用户属性库的接口，获取业务系统发出的数据访问请求；

对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统。

本发明实施例的第二方面提供了一种服务器，所述服务器包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的用户特征数据的获取程序，所述处理器执行所述用户特征数据的获取程序时实现如下步骤：

将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；

利用计算引擎对已同步的用户基础数据进行分析汇总，得到与各个用户分别对应的特征数据；

基于所述用户属性库的接口，获取业务系统发出的数据访问请求；

对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统。

本发明实施例的第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有用户特征数据的获取程序，所述用户特征数据的获取程序被至少一个处理器执行时，实现以下步骤：

将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；

利用计算引擎对已同步的用户基础数据进行分析汇总，得到与各个用户分别对应的特征数据；

基于所述用户属性库的接口，获取业务系统发出的数据访问请求；

对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统。

本发明实施例中，在多业务数据库分离的情况下，通过构建汇总有各用户基础数据的用户属性库，能够基于计算引擎快速地解析出各个用户分别对应的特征数据，实现了对用户特征数据的全面评估。并且，由于分析汇总过程是在用户属性库进行的，因此不会影响到现有业务系统的运行。另外，通过利用接口接收数据访问请求，使得各个业务系统能够方便地获取用户的特征数据，进而能够根据不同用户所对应的不同特征数据，为用户个性化的业务定制以及业务推荐等功能提供准确的数据支持。同时，由于避免了业务系统需要自行对其他业务数据库中的用户基础数据执行换算处理，因此，提高了业务系统对于用户特征数据的获取效率。

附图说明

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

图1是本发明实施例提供的用户特征数据的获取方法的实现流程图；

图2是本发明另一实施例提供的用户特征数据的获取方法的实现流程图；

图3是本发明实施例提供的用户特征数据的获取方法S4的一具体实现流程图；

图4是本发明实施例提供的用户特征数据的获取方法S4的另一具体实现流程图；

图5是本发明实施例提供的用户特征数据的获取方法所适用的应用场景示意图；

图6是本发明实施例提供的用户特征数据的获取程序的运行环境示意图；

图7是本发明实施例提供的用户特征数据的获取程序的功能模块图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

为了说明本发明所述的技术方案，下面通过具体实施例来进行说明。

本发明实施例所述的用户特征数据的获取方法可在安装有分布式文件系统的服务器上执行。其中，分布式文件系统可以是Hadoop分布式文件系统(HDFS文件系统)，其能够适合运行在通用硬件(commodity hardware)上，能提供高吞吐量的数据访问。图1示出了本发明实施例提供的用户特征数据的获取方法的实现流程，详述如下：

S1：将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库。

本发明实施例中，业务数据库用于管理和存储业务系统所产生的数据资源，数据资源包括用户基础数据。其中，用户是指业务所直接面对的客户，即用户基础数据为与客户相关的业务资料或基本信息。例如，寿险投保系统所产生的用户基础数据为保单客户的个人基础数据。不同业务系统所产生的用户基础数据可存储于不同的业务数据库中。

利用hadoop技术将各个业务数据库所存储的用户基础数据分别同步至HDFS文件系统后，由于用户基础数据包括用户在办理不同业务时的个人资料以及消费信息，因而在实质上，拥有各个业务系统所产生的用户基础数据的HDFS文件系统构成了一个用户属性库，其也是一个数据库。

在上述用户基础数据的同步过程中，虽然存在有传输时间差，无法保持业务数据库与用户属性库之间的实时同步，但由于用户属性库对资源数据的实时性要求不高，因此上述用户基础数据的同步方式可以满足用户属性库的建设需求。

S2：利用计算引擎对已同步的用户基础数据进行分析汇总，得到与各个用户分别对应的特征数据。

本发明实施例中，SPARK是指Apache Spark，是专为大规模数据处理而设计的快速通用的计算引擎。SPARK计算引擎启用了内存分布数据集，除了能够提供交互式查询外，还可以优化迭代工作负载。

用户属性库采用SPARK计算引擎以及ETL(Extraction，Transformation，Loading)工具对收集完的大量用户基础数据执行转换和过滤分析处理后，最终按照预先定义好的数据仓库模型，将处理结果加载到数据仓库中，则该处理结果即为汇总后的用户特征数据。用户属性库所存储的用户特征数据是针对用户在各业务系统的使用情况、使用习惯以及关注业务的汇总信息，是针对每个用户进行的汇总统计。

由于用户属性库是Hadoop分布式文件系统，因此，在实际的系统结构上，可以由多台服务器组成一个Hadoop分布式文件系统。用户基础数据同步至HDFS文件系统时，还可以将来源于不同业务数据库的用户基础数据分别同步至不同的服务器，由每台服务器分别采用SPARK计算引擎以及ETL工具对该台服务器上已同步的用户基础数据进行分析汇总，此后再将各台服务器的分析结果执行汇总。

本发明实施例中，由于用户属性库使用了多台服务器并行的方式实现用户基础数据的分析汇总，因此，提高了系统的数据处理效率。

S3：基于所述用户属性库的接口，获取业务系统发出的数据访问请求。

接口是用户属性库与外部其他部件进行信息交换的共享边界，采用java的servlet进行开发，以预设的表达程序结构的形式以及预设的SQL语言提供的数据组成。用户的特征数据均由用户属性库的接口对外进行发布。企业内部的其他业务系统如果需要获取或调用某个用户的特征数据，则采用post的方式自行调用用户属性库提供的接口，进而发出数据访问请求。其中，用户属性库通过http协议与业务系统实行交互。

作为本发明的另一个实施例，如图2所示，上述步骤S1具体包括：

S11：基于JOB方式，以预设的时间间隔将各个业务数据库中的用户基础数据同步至Hadoop分布式文件系统，以构建用户属性库。

在上述S2之后，S3之前，上述用户特征数据的获取方法还包括：

S21：将所述各个用户分别对应的特征数据保存至所述用户属性库的临时表，并在下一次将各个业务数据库中的用户基础数据同步至所述用户属性库之前，删除所述临时表中已存储的所述特征数据。

本发明实施例中，JOB为数据库所提供的一个定期执行某个存储过程或者包体的功能。为了使HDFS文件系统能够触发同步操作，在数据库层面通过SQLJOB定时作业的方式实现数据同步，其实现原理包括：通过JOB方式创建数据同步任务，并在该数据同步任务所对应的执行条件中，设置任务执行时刻以及任务执行间隔。当当前的时刻达到该预设的任务执行时刻时，或者，当当前的时刻与该任务执行时刻的差值为任务执行间隔的倍数时，令HDFS文件系统创建数据库连接，用于分别与各个业务数据库相连。此后，执行预设于HDFS文件系统的SQL语句，根据SQL语句的语法解析结果，若业务数据库中存在有SQL语句所对应的表参数时，则令HDFS文件系统以预设的身份权限从业务数据库中读取用户基础数据，并将读取到的用户基础数据更新插入至HDFS文件系统。

特别地，HDFS文件系统创建数据库连接包括创建远程数据库的dblink。基于dblink的方式，HDFS文件系统能够像访问本地数据库一样快速获取远程业务数据库的用户基础数据，提高同步效率。

若JOB方式的数据同步任务中所预设的需要同步的数据为业务系统在预设时间段内所产生的用户基础数据，则执行数据同步任务时，HDFS文件系统只会将业务系统在该预设时间段内所产生的用户基础数据同步至本地。优选地，该预设时间段为当月第一天至当天之前。即，HDFS文件系统只同步每月的1号至当天之前由业务系统所产生的用户基础数据。

在数据同步任务执行的当天，由于当天还没过去，业务数据库中的用户基础数据依然处于实时更新状态，因此，为了避免HDFS文件系统在同步后，因业务数据库中的用户基础数据又出现了更新而导致HDFS文件系统与业务数据库在实质上并不同步的现象发生，HDFS文件系统每次执行数据同步任务时，只同步当天之前由业务系统所产生的用户基础数据。另外，在实际操作中，因用户的业务生效时长都是以月为单位来计算的，并且都是以每个月的31日为失效日，例如，用户在10月2日投保了为期5个月的人寿保单，则第二年的3月31日为该份保单的失效日。故每月1号之前业务数据库中的大部分用户基础数据都是历史数据，为了提高HDFS文件系统对于用户基础数据的同步有效性、降低同步数据量以及提高同步效率，HDFS文件系统仅同步每月的1号至当天之前由业务系统所产生的用户基础数据。

特别地，在用户属性库中，根据用户级别的不同，用户基础数据分为普通级别和重要级别。用户属性库预设有两个JOB任务，分别用于设置关于普通级别和重要级别的用户基础数据的分析汇总动作执行时刻。

例如，用户属性库根据JOB任务所预设的规则，对已同步的重要级别的用户基础数据每天执行一次分析汇总操作，而对普通级别的用户基础数据则每周才执行一次分析汇总操作。

优选地，用户属性库仅在非访问繁忙时段才执行对用户基础数据的分析汇总操作。例如，根据统计结果，业务系统通常会集中在09:00至18:00的时间段访问用户属性库中的用户特征数据，则JOB任务中对已同步于本地的用户基础数据的分析汇总动作的任务执行时刻可以设置为凌晨0:00。

本发明实施例中，通过对用户属性库的分析汇总动作执行时刻进行限定，保证了在业务系统发出数据访问请求时，用户属性库能够及时作出响应，不会因分析汇总操作而占用过多的系统资源，提高了用户属性库的响应效率。通过将特征数据储存于临时表，能够减少用户属性库内存资源的消耗，通过定时对临时表中的特征数据进行清除操作，保证临时表中的数据量不会过多，使用户属性库有更好的性能。

S4：对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统。

用户属性库从接口接收到任一业务系统发出的基于用户特征数据的数据访问请求时，并不是马上将用户的特征数据返回至业务系统，而是先判断该数据访问请求是否合法，包括：判断数据访问请求的来源者是否满足预设的数据获取权限以及判断数据访问请求的数据内容是否参数异常。只有当数据访问请求合法时，用户属性库才查询并返回业务系统所请求获取的用户特征数据。业务系统请求获取的用户特征数据为与数据访问请求中所携带的用户号码相匹配的特征数据。用户属性库根据该用户号码从已存储的数据中执行查询，并将查询得到的特征数据转换为xml格式的数据后返回。

作为本发明的一个实施例，图3示出了上述步骤S4的具体实现流程，详述如下：

S411：判断所述数据访问请求所携带的IP地址以及访问密钥是否均存在于所述用户属性库的配置文件中。

用户属性库对接收到的数据访问请求进行解析处理，从数据访问请求的数据报中读取源IP字段所对应的第一属性值以及访问密钥字段所对应的第二属性值，则该第一属性值即为上述数据访问请求所携带的IP地址，表示了发出数据访问请求的业务系统当前所使用的IP地址，第二属性值即为访问密钥，表示业务系统的操作者所输入的账号密钥。

在运行过程中，用户属性库会加载自身所需环境的设置和文件的集合，该集合即为配置文件。为了对数据访问请求的合法性进行验证，将允许获取用户特征数据的源IP地址和访问密钥预先保存于配置文件中。配置文件中所保存的合法IP地址包括精确IP地址、IP地址段或者以通配符形式表示的IP地址。只要用户属性库检测到数据访问请求所携带的IP地址与该配置文件中的IP地址相同或者属于该配置文件中的任一IP地址段之内，则可确定数据访问请求所携带的IP地址存在于用户属性库的配置文件中。

S412：若所述数据访问请求所携带的IP地址以及访问密钥均存在于所述用户属性库的配置文件中，则获取所述数据访问请求中的属性信息，所述属性信息包括数据请求参数以及已加密的访问者签名。

本发明实施例中，访问者签名是附加在数据访问请求上的密钥数据，或是对密钥数据所作的一种变换。用户属性库利用预先约定的解密密钥对接收到的访问者签名进行解密，从而判定数据访问请求的来源是否为真实的授权用户，并确认数据访问请求的报文完整性，从而在接收到不法分子所伪造处理的数据访问请求时，用户属性库也能识别出来并对该数据访问请求不作响应，由此提高用户特征数据的传输安全。

特别地，若数据访问请求所携带的IP地址或访问密钥不存在于用户属性库的配置文件中，则用户属性库对该数据访问请求不作响应。

S413：对所述访问者签名进行解密处理，判断解密后的所述访问者签名与所述配置文件中的签名是否相同，并判断所述数据请求参数是否满足预设条件。

S414：若解密后的所述访问者签名与所述配置文件中的签名相同，且所述数据请求参数满足预设条件，则确定所述数据访问请求合法，并将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

预设条件即语法结构规则，包括字符类型属性以及取值范围区间等规则。只有数据访问请求中的各数据请求参数均满足预设的语法结构规则时，用户属性库才确定该数据访问请求合法，并对该数据访问请求作出响应，即，根据其所需用户的特征数据，从用户属性库中查询对应该用户的特征数据后，返回至发出数据访问请求的业务系统。

若解密后的访问者签名与配置文件中的签名不相同，数据访问请求中的任一数据请求参数不满足预设的语法结构规则，则用户属性库生成错误提示信息，并基于该错误提示信息对该数据访问请求作出响应。

例如，在数据访问请求所携带的IP地址和访问密钥均存在于用户属性库的配置文件以及访问者签名合法的情况之下，若数据访问请求的报文内容为“select name frompersons”，则根据语法结构规则，“from”后面的参数类型应当是表名，而用户属性库中，并不存在“persons”这个表，因此，用户属性库确定该数据请求参数不满足预设的语法结构规则，并将生成的错误提示数据包通过接口返回至发出数据访问请求的业务系统。

优选地，用户属性库在接收到数据访问请求时，先判断第一时间段内所接收到的数据访问请求的数量是否达到了预设阈值。其中，第一时间段为接收到该数据访问请求之前的某一时刻至接收到该数据访问请求时的时间区间，且第一时间段的长度为预设时长。若第一时间段内所接收到的数据访问请求的数量已达到了预设阈值，则对当前时刻所接收到的数据访问请求不作响应，也不执行上述步骤S411至步骤S414。

在本发明实施例中，用户属性库通过对预设时长内的数据访问请求的数量进行判断，能够在数量超过阈值时不作出任何响应，避免了用户属性库持续处理大量的数据访问请求，控制了关于数据访问请求的处理频率，保证了用户属性库的正常运行。

特别地，用户属性库对外提供查询用户特征数据时，均采用视图的方式进行。业务系统通过上述接口直接调用用户属性库所提供的视图，能够直接请求获取该视图所对应的用户特征数据。因此，在用户属性库内部发生存储数据的调整时，由于视图与接口均未发生改变，因而通过接口以及视图调用用户属性库内部用户特征数据的业务系统将不会受到影响，该调整过程对业务系统来说是不可见的。

例如，在用户属性库对历史的用户特征数据进行转移或者对大批量的用户特征数据执行分表操作时，虽然用户特征数据的存储结构发生了改变，但在业务系统看来，依然能通过接口调用相同的一个视图来获取自身所需的用户特征数据，因此，本发明实施例提供的用户特征数据获取方法保证了业务系统的正常运作，提高了业务系统的可靠性。

作为本发明的一个实施例，图4示出了上述步骤S4的另一具体实现流程，详述如下：

S421：获取所述数据访问请求的IP地址。

S422：获取预设时长内基于所述IP地址的历史数据访问请求的总数。

本发明实施例中，根据访问日志文件，用户属性库判断预设时间段内所接收到的数据访问请求的来源IP与S421中的IP地址相同的数量。其中，预设时间段为接收到该数据访问请求之前某一时刻至接收到该数据访问请求时的时间区间，且该预设时间段的长度为预设时长。

上述日志文件的详细报文中记载有各个数据访问请求的来源时间、请求参数、来源IP、用户属性库对各个数据访问请求的处理时长以及处理结果等信息。

S423：若预设时长内基于所述IP地址的历史数据访问请求的总数大于预设阈值，则对所述数据访问请求进行缓存，并在预设时延后对缓存的所述数据访问请求的合法性进行验证。

若预设时长内基于所述IP地址的数据访问请求的总数大于第一预设阈值且小于第二预设阈值，则对所述数据访问请求进行缓存。若数据访问请求缓存于预先创建的缓存区的时长已经达到了预设时长，则用户属性库对该数据访问请求进行合法性验证。

若预设时长内基于所述IP地址的数据访问请求的总数大于第二预设阈值，则不对该数据访问请求进行响应。

S424：若所述数据访问请求合法，则将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

本发明实施例中未提到的步骤原理与上述各个实施例中的步骤原理一致，因此不再一一赘述。

在本发明实施例中，通过对同一来源IP的数据访问请求进行延时处理或者不作出响应，能够在恶意请求出现的情况下，减轻恶意数据请求对用户属性库的资源占用，保障了用户属性库的正常工作；通过对接收到的各个数据访问请求执行日志记录，能够在后期维护过程中后，当用户属性库出现问题时，为维护人员提供排查线索，提高维护效率。

进一步地，用户属性库除了提供上述接口供外部业务系统获取用户的特征数据之外，还为外部的监控服务器提供了监控接口，用于对用户属性库的接口服务进行监控。监控服务器24小时持续检测监控接口是否返回正常响应数据包。当未接收到正常响应数据包时，表示接口服务异常，此时，监控服务器将发出告警提示，以便运维人员迅速执行故障排查工作，尽快恢复接口服务，从而基于该监控接口能够提高用户属性库的可靠性，避免业务系统受到影响。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

作为本发明实施例的一个具体实施示例，在图5所示的一个实际应用场景中，应用数据库分别与寿险系统数据库、财险系统数据库以及理财基金数据库通过网络互连。应用数据库用于将寿险系统数据库、财险系统数据库以及理财基金数据库中各用户的基础信息同步至本地，以令应用数据库构建为上述用户属性库。此后，应用数据库利用SPARK计算引擎对已同步于本地的每个用户的基础信息进行综合分析处理，对于任一用户，基于该用户的寿险投保状况、财险投保状况以及理财基金购买情况等，应用数据库将全面评估得到该用户的消费行为特征数据。另一方面，企业内部的短彩信推送系统经由应用数据库所提供的用户统一视图查询接口，请求并获取应用数据库中用户A的消费行为特征数据，则该短彩信推送系统根据应用数据库所返回的特征数据，得知用户A习惯购买股票型基金和混合型基金，因而筛选短彩信推送系统出关于股票型基金和混合型基金的推送信息，并通过短信方式将该推送信息发送至用户A的手机中。因此，基于应用数据库所提供的接口以及基于应用数据库所汇总分析的用户特征数据，短彩信推送系统等业务系统实现了用户个性化的业务定制以及业务推荐等功能。

对应于上文实施例所述的用户特征数据的获取方法，图6示出了本发明实施例提供的用户特征数据的获取程序60的运行环境示意图，为了便于说明，仅示出了与本发明实施例相关的部分。

在本实施例中，所述的用户特征数据的获取程序60安装并运行于服务器6中。该服务器6可包括，但不仅限于，存储器61、处理器62及显示器63。图6仅示出了具有组件61-63的服务器6，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

所述存储器61在一些实施例中可以是所述服务器6的内部存储单元，例如该服务器6的硬盘或内存。所述存储器61在另一些实施例中也可以是所述服务器6的外部存储设备，例如所述服务器6上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(FlashCard)等。进一步地，所述存储器61还可以既包括所述服务器6的内部存储单元也包括外部存储设备。所述存储器61用于存储安装于所述服务器6的应用软件及各类数据，例如所述用户特征数据的获取程序60的程序代码等。所述存储器61还可以用于暂时地存储已经输出或者将要输出的数据。

所述处理器62在一些实施例中可以是一中央处理器(Central ProcessingUnit,CPU)，微处理器或其他数据处理芯片，用于运行所述存储器61中存储的程序代码或处理数据，例如执行所述用户特征数据的获取程序60等。

所述显示器63在一些实施例中可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。所述显示器63用于显示在所述服务器6中处理的信息以及用于显示可视化的用户界面，例如应用菜单界面、应用图标界面等。所述服务器6的部件61-63通过系统总线相互通信。

请参阅图7，是本发明实施例提供的用户特征数据的获取程序60的功能模块图。在本实施例中，所述的用户特征数据的获取程序60可以被分割成一个或多个模块，所述一个或者多个模块被存储于所述存储器61中，并由一个或多个处理器(本实施例为所述处理器62)所执行，以完成本发明。例如，在图7中，所述的用户特征数据的获取程序60可以被分割成同步模块71、汇总模块72、获取模块73、返回模块74。本发明所称的模块是指能够完成特定功能的一系列计算机程序指令段，比程序更适合于描述所述用户特征数据的获取程序60在所述服务器6中的执行过程。以下描述将具体介绍所述模块71-74的功能。

所述同步模块71用于将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库。

汇总模块72用于利用计算引擎对已同步的所述用户基础数据进行分析汇总，得到各个用户分别对应的特征数据。

获取模块73用于基于所述用户属性库的接口，获取业务系统发出的数据访问请求。

返回模块74用于对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

可选地，所述返回模块74包括：

判断子模块，用于判断所述数据访问请求所携带的IP地址以及访问密钥是否均存在于所述用户属性库的配置文件中。

第一获取子模块，用于若所述数据访问请求所携带的IP地址以及访问密钥均存在于所述用户属性库的配置文件中，则获取所述数据访问请求中的属性信息，所述属性信息包括访问者签名以及数据请求参数。

第一返回子模块，用于若解密后的所述访问者签名与所述配置文件中的签名相同，且所述数据请求参数满足预设条件，则所述数据访问请求合法，并将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

可选地，所述同步模块71包括：

第一同步子模块，用于基于JOB方式，以预设的时间间隔将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库。

所述用户特征数据的获取装置还包括：

存储模块，用于将所述各个用户分别对应的特征数据保存至所述用户属性库的临时表，并在下一次将各个业务数据库中的用户基础数据同步至所述用户属性库之前，删除所述临时表中已存储的所述特征数据。

可选地，所述返回模块74包括：

第二获取子模块，用于获取所述数据访问请求的IP地址。

第三获取子模块，用于获取预设时长内基于所述IP地址的历史数据访问请求的总数。

缓存子模块，用于若预设时长内基于所述IP地址的历史数据访问请求的总数大于预设阈值，则对所述数据访问请求进行缓存，并在预设时延后对缓存的所述数据访问请求的合法性进行验证。

第二返回子模块，用于若所述数据访问请求合法，则将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

可选地，所述同步模块71包括：

第二同步子模块，用于在各个业务数据库中，将预设时间段内的用户基础数据同步至分布式文件系统，以构建用户属性库。

其中，所述预设时间段为当月第一天至当前时刻的前一天。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

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

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

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

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

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

Claims (10)

1.一种用户特征数据的获取方法，其特征在于，包括：

将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；

利用计算引擎对已同步的用户基础数据进行分析汇总，得到与各个用户分别对应的特征数据；

基于所述用户属性库的接口，获取业务系统发出的数据访问请求；

对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统。

2.如权利要求1所述的用户特征数据的获取方法，其特征在于，所述对所述数据访问请求的合法性进行验证，若所述访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统，包括：

判断所述数据访问请求所携带的IP地址以及访问密钥是否均存在于所述用户属性库的配置文件中；

若所述数据访问请求所携带的IP地址以及访问密钥均存在于所述用户属性库的配置文件中，则获取所述数据访问请求中的属性信息，所述属性信息包括数据请求参数以及已加密的访问者签名；

对所述访问者签名进行解密处理，判断解密后的所述访问者签名与所述配置文件中的签名是否相同，并判断所述数据请求参数是否满足预设条件；

若解密后的所述访问者签名与所述配置文件中的签名相同，且所述数据请求参数满足预设条件，则确定所述数据访问请求合法，并将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

3.如权利要求1所述的用户特征数据的获取方法，其特征在于，所述将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库，包括：

基于JOB方式，以预设的时间间隔将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；

在所述利用计算引擎对已同步的所述用户基础数据进行分析汇总，得到各个用户分别对应的特征数据的步骤之后，还包括：

将所述各个用户分别对应的特征数据保存至所述用户属性库的临时表，并在下一次将各个业务数据库中的用户基础数据同步至所述用户属性库之前，删除所述临时表中已存储的所述特征数据。

4.如权利要求1所述的用户特征数据的获取方法，其特征在于，所述对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的所述特征数据返回至所述业务系统，包括：

获取所述数据访问请求的IP地址；

获取预设时长内基于所述IP地址的历史数据访问请求的总数；

若预设时长内基于所述IP地址的历史数据访问请求的总数大于预设阈值，则对所述数据访问请求进行缓存，并在预设时延后对缓存的所述数据访问请求的合法性进行验证；

若所述数据访问请求合法，则将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

5.如权利要求1所述的用户特征数据的获取方法，其特征在于，所述将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库，包括：

在各个业务数据库中，将预设时间段内的用户基础数据同步至分布式文件系统，以构建用户属性库；

其中，所述预设时间段为当月第一天至当前时刻的前一天。

6.一种计算机可读存储介质，所述计算机可读存储介质存储有用户特征数据的获取程序，其特征在于，所述用户特征数据的获取程序被至少一个处理器执行时，实现如权利要求1-5中任一项所述的用户特征数据的获取方法的步骤。

7.一种服务器，其特征在于，所述服务器包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的用户特征数据的获取程序，所述处理器执行所述用户特征数据的获取程序时实现如下步骤：

将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；

利用计算引擎对已同步的用户基础数据进行分析汇总，得到与各个用户分别对应的特征数据；

基于所述用户属性库的接口，获取业务系统发出的数据访问请求；

对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统。

8.如权利要求7所述的服务器，其特征在于，所述对所述数据访问请求的合法性进行验证，若所述访问请求合法，则将与所述数据访问请求匹配的用户的特征数据返回至所述业务系统的步骤，具体包括：

判断所述数据访问请求所携带的IP地址以及访问密钥是否均存在于所述用户属性库的配置文件中；

若所述数据访问请求所携带的IP地址以及访问密钥均存在于所述用户属性库的配置文件中，则获取所述数据访问请求中的属性信息，所述属性信息包括数据请求参数以及已加密的访问者签名；

对所述访问者签名进行解密处理，判断解密后的所述访问者签名与所述配置文件中的签名是否相同，并判断所述数据请求参数是否满足预设条件；

若解密后的所述访问者签名与所述配置文件中的签名相同，且所述数据请求参数满足预设条件，则确定所述数据访问请求合法，并将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。

9.如权利要求7所述的服务器，其特征在于，所述将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库的步骤，具体包括：

基于JOB方式，以预设的时间间隔将各个业务数据库中的用户基础数据同步至分布式文件系统，以构建用户属性库；

在所述利用计算引擎对已同步的所述用户基础数据进行分析汇总，得到各个用户分别对应的特征数据的步骤之后，所述处理器还用于执行所述用户特征数据的获取程序，以实现以下步骤：

将所述各个用户分别对应的特征数据保存至所述用户属性库的临时表，并在下一次将各个业务数据库中的用户基础数据同步至所述用户属性库之前，删除所述临时表中已存储的所述特征数据。

10.如权利要求7所述的服务器，其特征在于，所述对所述数据访问请求的合法性进行验证，若所述数据访问请求合法，则将与所述数据访问请求匹配的所述特征数据返回至所述业务系统的步骤，具体包括：

获取所述数据访问请求的IP地址；

获取预设时长内基于所述IP地址的历史数据访问请求的总数；

若预设时长内基于所述IP地址的历史数据访问请求的总数大于预设阈值，则对所述数据访问请求进行缓存，并在预设时延后对缓存的所述数据访问请求的合法性进行验证；

若所述数据访问请求合法，则将与所述数据访问请求匹配的所述特征数据返回至所述业务系统。