CN104699718B - 用于快速引入业务数据的方法和装置 - Google Patents

Abstract

本申请公开了一种用于快速引入业务数据的方法，包括：接收按照约定格式封装的业务数据；根据约定格式从所述业务数据中获取反映业务属性的数据信息；将获取的所有数据信息存储在采用key‑value结构的存储***中。本申请同时提供一种用于快速引入业务数据的装置。使用本申请提供的方法，能够将业务数据快速引入到应用中，并且节省开发资源、提高软件开发和后期维护的效率。

Description

用于快速引入业务数据的方法和装置

技术领域

本申请涉及数据引入领域，具体涉及一种快速引入业务数据的方法。本申请同时提供一种用于快速引入业务数据的装置。

背景技术

随着互联网的发展，互联网上的数据源日益增多，进入了数据急剧膨胀的大数据时代，同时基于这些大数据的业务也越来越多，例如：网络金融、网络购物、社交媒体、支付宝业务、电子商务、即时通讯等业务层出不穷，而且随着网络技术的日新月异和用户需求的变化，原有业务又不断衍生出若干个新的业务，从而为网络用户提供全方位的、高质量的服务。

随着互联网业务的日益增多，对各种业务数据进行监控和统计分析的需求也应运而生。一方面，为了使各种业务能够更好地、更安全地为用户服务，出现了与业务相关的风险监控管理应用；另一方面，为了针对大数据进行复杂的数据挖掘和预测性分析，洞察大数据内部潜在的价值，从而提供有广阔前景的新产品或服务，出现了很多与分析业务数据相关的应用，例如：分析用户的购买行为、网站流量统计、IP来源信息统计、搜索关键词分析等应用。

上述各种应用***或应用程序的功能，都是基于对相关业务数据的分析或监控才能实现。为了不影响用户对业务数据的访问，也为了简化对业务数据的访问控制，每开发一种新的应用***或应用程序，通常需要将业务数据引入到应用***或应用程序的内部。传统的数据引入方式包括下述步骤：需求分析、***设计、数据库表结构设计、硬编码工作，测试、发布上线、业务应用等。整个过程需要花费一定的人力、物力、时间。

在数据量小，并且应用***或应用程序有限的情况下，传统方法是可行的，但是随着大数据时代的到来，业务数据越来越多，与业务相关的应用***或应用程序也越来越多，需要将各种业务数据引入到各种各样的应用中，传统的引入方法就无法胜任了。

以支付宝业务的风险控制管理核心监控***为例，该应用***用于对盗用、欺诈、盗卡等风险进行各种监控，避免出现因为这些风险导致的资金损失，从而保障客户资金以及交易安全。一方面，随着支付宝新业务的不断增加，需要引入到风险控制管理核心监控***中的业务数据越来越多；另一方面，各种各样的业务数据除了要引入到该风险控制管理核心监控***外，可能还需要引入到新开发的对支付宝业务数据进行分析管理的其他应用***或应用程序中。那么如果采用传统的数据引入过程，每个应用***或应用程序每引入一次新的业务数据，就要重复一次上述的各个开发步骤，要花费大量的人力、物力、时间，不仅是对软件开发资源的浪费，而且后期***的维护成本也会不断上升，导致整个软件开发阶段和维护阶段的效率低下。

发明内容

本申请提供一种用于快速引入业务数据的方法，以解决现有方法引入业务数据效率低下的问题。

本申请同时提供一种用于快速引入业务数据的装置。

本申请提供一种用于快速引入业务数据的方法，包括如下步骤：

接收按照约定格式封装的业务数据；

根据约定格式从所述业务数据中获取反映业务属性的数据信息；

将获取的所有数据信息存储在采用key-value结构的存储***中。

可选的，在所述接收按照约定格式封装的业务数据的步骤之前，向所述业务发出针对所述业务数据的订阅申请，并约定传输所述业务数据采用的封装格式。

可选的，在所述接收按照约定格式封装的业务数据的步骤之前，创建与所述业务数据对应的业务数据定义；

相应的，所述接收按照约定格式封装的业务数据包括：

判断是否存在与当前要接收的业务数据相对应的业务数据定义；

若是，接收所述业务数据；若否，放弃接收所述业务数据。

可选的，所述业务数据定义包括：唯一标识所述业务数据的业务数据标识码和与之对应的业务数据属性定义；所述业务数据属性定义包括：业务数据所包含的每个数据的名称、获取其值的方法和该数据是否具备主键数据的属性。

可选的，在所述接收按照约定格式封装的业务数据之前，根据所述业务数据属性定义，判断是否需要计算衍生数据；若是，生成衍生数据配置，在所述配置中指定需要计算的衍生数据及其计算方法；

相应的，所述根据约定格式从所述业务数据中获取反映业务属性的数据信息的步骤，具体包括：

根据约定格式从所述业务数据中获取反映业务属性的数据信息，作为基础数据；

判断是否存在衍生数据配置；

若是，根据所述基础数据和所述存储***中存储的与所述业务数据相关的历史累计数据，针对所述衍生数据配置中的每一个衍生数据，采用所述衍生数据配置中与所述衍生数据对应的计算方法，计算所述衍生数据；

相应的，所述将获取的所有数据存储在采用key-value结构的存储***中是指：

如果在所述根据约定格式从所述业务数据中逐一获取反映业务属性的数据信息的步骤中，计算了衍生数据，则将所述基础数据和所述衍生数据合并并存储到所述采用key-value结构的存储***中；

否则，直接将所述基础数据合并并存储到所述采用key-value结构的存储***中。

可选的，所述衍生数据配置中指定的计算方法，包括：***提供的公共的计算方法和/或自定义的计算方法。

可选的，所述与所述业务数据相关的历史累计数据，采用如下方式生成：根据所述存储***中存储的需累计的业务数据，按照预先定义的时间间隔，计算所述业务数据与所述时间间隔对应的累积值并存储在所述存储***中。

可选的，所述将获取的所有数据信息存储在采用key-value结构的存储***中，具体是指，采用与所述业务数据对应的业务数据标识码和主键数据作为数据存储的键值，将获取的所有数据信息存储在所述存储***中。

可选的，所述方法进一步包括，根据应用的需求，从所述存储***中获取需引入的业务数据并引入。

可选的，所述根据应用的需求，从所述存储***中获取需引入的业务数据并引入包括：

将某个业务的业务数据引入到需要使用该业务数据的某个应用中；或者，

将多个业务的业务数据依次引入到需要使用所述多个业务的业务数据的某个应用中；或者，

将某个业务的业务数据分别引入到需要使用该业务数据的多个应用中。

可选的，所述方法进一步包括，根据应用的需求，从所述存储***中获取需引入的业务数据并引入；

其中，所述根据应用的需求，从所述存储***中获取需引入的业务数据并引入具体是指：根据应用提供的业务数据标识码，从所述存储***中获取与所述业务数据标识码对应的业务数据；或者，根据应用提供的业务数据标识码和主键数据值，从所述存储***中获取与所述业务数据标识码对应的、并且与所述主键数据值相关的业务数据。

可选的，所述接收按照约定格式封装的业务数据包括：

通过同步接口调用方式，接收按照约定格式封装的业务数据；或者，

通过异步消息投递方式，接收按照约定格式封装的业务数据。

可选的，所述采用key-value结构的存储***是指Hbase、Tair、LevelDB或Redis存储***中的一种。

本申请同时提供一种用于快速引入业务数据的装置，包括：

业务数据接收单元，用于接收按照约定格式封装的业务数据；

业务数据获取单元，用于根据约定格式从所述业务数据中获取反映业务属性的数据信息；

业务数据存储单元，用于将获取的所有数据信息存储在采用key-value结构的存储***中。

与现有技术相比，本申请具有以下优点:

本申请提供的用于快速引入业务数据的方法，通过将接收到的、按照预先约定格式传输的业务数据存储在采用key-value结构的存储***中，当应用***或应用程序需要引入所述业务数据时，不用进行传统的***设计、数据库表结构设计、编码等重复工作，而是直接从所述存储***中获取所需的业务数据即可；采用本申请提供的方法，不仅能够实现快速引入业务数据的目的，而且能够节省开发资源、提高软件开发和后期维护的效率；当多个应用***或者应用程序需要引入同一个业务的业务数据时，上述优点更为显著。

在本申请的一种优选实施方式中，在接收数据之前，根据标准化数据定义生成相关的衍生数据配置，并且在接收基础业务数据的同时，根据衍生数据配置，计算相关的衍生数据，从而能够为应用***或应用程序提供更为丰富的业务数据。

在本申请的另一种优选实施方式中，基于key-value存储***支持的多种数据查询方式，可以为需要引入业务数据的应用***或应用程序提供不同粒度的业务数据，从而便于应用***或应用程序根据使用业务数据的具体需求灵活地、分批地获取业务数据。

附图说明

图1为本申请的用于快速引入业务数据的方法的实施例的流程图；

图2为本申请的用于快速引入业务数据的装置的实施例的示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，分别提供了一种用于快速引入业务数据的方法、以及一种用于快速引入业务数据的装置。在下面的实施例中逐一进行详细说明。

请参考图1，其为本申请的一种用于快速引入业务数据的方法实施例的流程示意图。所述方法包括如下步骤：

步骤101：接收按照约定格式封装的业务数据。

本申请提供的方法，能够快速地将业务数据引入到应用***或应用程序中，为了实现这一目的，首先要顺利地接收业务数据并准确地从中提取每个数据的相关信息，因此在接收业务数据之前，需要与提供业务数据的一方进行协商，约定好传输业务数据所采用的封装格式，并进行标准化数据定义。

首先，针对业务数据信息和封装格式等进行协商。在本实施例的一个具体的例子中，为了将与淘宝旺旺登录相关的业务数据引入到CTU***（风险控制管理核心监控***）中，首先向淘宝旺旺登录业务发送业务数据的订阅申请，发起针对业务数据信息和封装格式等的协商过程，双方在此过程中协商以下四类信息：

1）确定与该业务数据整体相关的概要信息，包括：业务数据标识码，对业务数据的描述、业务数据的来源等。业务数据标识码作为业务数据的唯一标识，用于区分不同的业务数据，在传输业务数据时携带对应的业务数据标识码，便于采用本申请提供的方法接收时能够识别该业务数据。

2）与该业务数据相关的细节信息，例如：具体包含哪些数据，每个数据的名称、含义、取值范围（即长度）等信息，本申请提供的方法，要将业务数据存储在采用key-value结构的存储***中，此步骤中定义的每个数据的名称就是相当于key值（例如：userid）。

3）接收业务数据采用的接口方式。本申请所提供的方法，可以通过多种接口方式接收业务数据，因此在上述协商阶段还需要确定采用何种接口方式，例如：采用同步接口调用方式，或者是采用异步消息投递方式，如果选择采用同步接口调用方式，那么应该明确接口API的名称（例如：standardDataAccess（）函数）和入口参数如何传递，返回值的含义等；如果选择采用异步消息投递方式，那么应该协商消息接收和发送的基本流程。

4）传输业务数据采用哪种封装格式。数据封装格式有多种形式，根据上述所选接口方式的不同，也会有一定的差异。例如，采用API调用方式，可以用一个入口参数传递业务数据标识码，用另外一个参数封装具体的业务数据；如果采用基于消息的异步投递方式，可以约定用消息头部的某几个字节存储业务数据标识码，用另外几个字节存储业务数据总长度，消息体部分封装具体的业务数据。具体到业务数据的封装，可以采用定长数据单元的封装方式，或者采用变长TLV方式，或者其他封装方式，具体采用何种封装格式，不是本申请的核心，只要双方协商一致，业务数据的发送方按照约定好的格式将反映业务属性的数据信息（例如：数据名称key、对应的值value等）进行封装和传输，实施本申请所提供方法的***或装置能够按照约定格式从接收到的业务数据中获取所述数据信息就可以了。

然后，进行标准化数据定义。完成上述协商过程后，就可以根据协商的结果进行与所述业务数据相关的标准化数据定义了，在本实施例的一个具体例子中，上述过程是在标准化数据引入管理页面中完成的。其中，标准化数据定义包括业务数据概要定义和其中的每个数据的细节定义，在每个数据的细节定义中不仅包含协商过程中约定好的数据名称（即key，例如userid）、数据描述等，还要定义获取该数据值的方法，例如采用转换脚本return map.get("userid")来根据数据的名称获取与其对应的具体取值，即：根据key获取value。在接收业务数据时要根据业务数据标识码查找有无对应的标准化数据定义，从而决定是否接收业务数据。

上述标准化数据定义可以存储在数据库中、也可以存储在数据文件中，具体的存储和组织形式，不是本申请的核心，本申请不作限定。

在定义与数据业务整体相关的概要信息时，还可以指定有效时间，即：存储一条具体的业务数据的有效时间，当一条业务数据存放的时间大于有效时间后，所述业务数据将会被淘汰。

在定义与数据业务相关的细节信息时，还可以指定业务数据包括的众多数据中，哪个数据或哪些数据具备主键数据的属性。存储业务数据时，具备主键属性的数据（简称：主键数据）可以作为主键或者主键的一部分，当某个应用***或应用程序需要引入业务数据时，可以根据应用***或应用程序给出的主键数据的具体值，分批引入业务数据。关于这部分说明，请参见步骤103中的相关部分的描述。

之所以要首先进行业务数据定义，第一、是为了能够对接收到的业务数据进行辨识，对于无效业务数据不予接收；第二、可以根据数据的细节定义正确地从接收到的业务数据中提取各个数据；第三，合理地指定主键数据，可以使数据的存储更为合理，能够提高从存储***中读取数据的效率。

为了给需引入业务数据的应用***或应用程序，提供更为丰富的业务数据，本申请还提供了一种优选实施方式，即：在接收业务数据（即：基础数据）的同时，计算衍生数据。为了实现这一功能，在完成上述的业务数据定义后，要判断是否需要计算衍生数据，如果需要，生成衍生数据配置。

所谓衍生数据，是指根据基础数据计算出来的新数据。通常基础数据中提供的都是用户的基本信息，例如：用户标识、手机号码、登录的时间、IP地址、交易数据等，为了从这些基础数据中挖掘出用户行为的潜在规律或趋势，可以采用计算衍生数据的方式，从而为需要引入业务数据的应用***或应用程序提供更为丰富的数据。

在本实施例的一个具体的例子中，根据用户登陆淘宝旺旺的业务数据（即：基础数据），可以衍生计算出很多其他数据，因此需要进行衍生数据的配置。

例如：根据登陆淘宝旺旺的用户标识userid，可以查询该用户上次登陆所使用的IP地址，然后可以根据IP地址获取与该IP地址对应的经纬度信息，从而计算出两次登陆的物理距离ip_distance。该衍生数据ip_distance的计算采用的是公共的计算方法ipDistance（），即：ip_distance=ipDistance(ip,previous_ip)。

再例如：根据登陆淘宝旺旺的用户最近一天的交易笔数和最近十天的交易笔数的均值，可以计算出该用户当前的交易趋势trade_trend。该衍生数据trade_trend的计算采用的是公共的计算方法velocity（），该函数可用于获得历史累积数据，输入的参数包括：累积数据主体（如userid）、累积数据指标（如trade_count）、数据计算函数（如sum或avg等）、以及计算的时间窗口（如1天或10天），具体的计算方法为：

trade_trend=velocity（"userid",user_id,"trade_count","1",["sum"],["1d"]）/velocity（"userid",user_id,"trade_count","1",["avg"],["10d"]）。

在本实施例的上述具体例子中，因为要根据基础数据计算上述衍生数据，因此在完成标准化数据定义后，生成了衍生数据配置。在该配置中指定了需要计算ip_distance和trade_trend这两个衍生数据，并且指定了与这两个衍生数据对应的计算方法。当然，在其他实施方式中，需要计算哪些衍生数据以及衍生数据的数量，是根据基础数据来确定的，可以与本实施例所述的具体例子中的配置不同，这些变更都不影响本申请的核心，本申请不作限定。

在本实施例的上述具体例子中，生成的衍生数据配置中，不仅包括衍生数据，还包括对应的计算方法。在其他实施方式中，衍生数据配置中可以仅包含需要计算的衍生数据，而在具体计算衍生数据时，采用图形界面等方式动态配置计算衍生数据的具体计算方法并进行计算。

最后，接收业务数据。完成上述协商、数据定义和衍生数据的配置过程后，就可以接收业务数据了。按照协商好的接口方式，通过同步API调用方式或者异步消息传递方式接收按照约定格式传输的业务数据时，为了避免接收到无效的业务数据，给***带来不必要的处理负担，首先应该检查该业务数据是否是经过协商的有效业务数据，即：提取该业务数据携带的业务数据标识码，在标准化数据定义中查找是否存在与该业务数据标识码对应的标准化数据定义（即：概要定义和细节定义都是完备的），如果存在，接收业务数据；否则，放弃接收业务数据。

步骤102：根据约定格式从所述业务数据中获取反映业务属性的数据信息。

接收到业务数据后，就可以根据约定好的格式，逐一获取封装在业务数据中的反映业务属性的具体数据信息，例如：每个数据的名称和对应的取值。在本步骤中正确地提取数据信息，是步骤103将数据存储在key-value存储***的前提条件。

对采用key-value结构的存储***的最简单的定义就是，该***提供两个接口，一个是put接口用于存储数据，一个是get接口用于读取数据。put的时候，传进key与value，就可以把数据写到HASH表或者类似B树一类的索引结构的节点中，get的时候，传进key，就可以获得与key对应的值value。目前对上述存储***的名称存在多种表述方式，例如：key-value、key/value、keyvalue等，在本文中统一采用key-value的表述方式。

之所以要选择采用key-value结构的存储***，因为该***具有良好的可扩展性，这也是它最大的优势。所谓良好的可扩展性，具体包括两方面内容：一方面，是指采用key-value结构的存储***可以支持极大的海量数据，该存储***的分布式的架构决定了只要动态添加更多的机器或者存储节点，就能够保证存储更多的数据；另一方面，是指该存储***可以支持数量很多的并发查询，一个采用key-value结构的存储***，可以很轻松地支持上千个甚至更多的并发查询。

采用key-value结构的存储***，与传统的关系型数据库***的一个很大的区别就是数据格式没有严格的定义，在关系型数据库中，数据定义就是对数据的约束（例如：数据类型、长度、能否为空等），包括数据之间的关系和数据的完整性。在采用key-value结构的存储***中是没有严格的数据定义的，对于某一个key、与之对应的value可以是任意的数据类型。

传统的关系型数据库往往不具备存储海量数据所需的高可靠性及可扩展性，同时很多互联网业务的绝大部分的检索都是基于主键的查询，并不需要作关系查询，在这种情况下，使用key-value存储***将会是一个很好的选择。它被广泛应用于缓存，搜索引擎等等领域。采用key-value结构的存储***包括但不限于：Hbase、Tair、mile、LevelDB或Redis等存储***。本实施例的一个具体的例子中，采用的是Hbase存储***，当然在其他实施方式中，也可以使用其他采用key-value结构的存储***，同样可以实现本申请所提供的方法。

Hbase是一个采用key-value结构的、分布式的存储***，用于存储海量数据。Hbase采用的是基于列的存储模式，而且列是可以动态扩展的，适合于非结构化数据的存储，对于空值的存储是不占用任何空间的。Hbase采用的是由rowkey（行主键）、column key(列簇column family和列column，一个列簇中可以包括多个列)、timestamp(时间戳)三部分组成的三维有序存储，其中，rowkey表示唯一一行，column key对应某一列，而timestamp则用于标识某个数据的各个不同版本。

在Hbase存储***中还有两个比较重要的概念：最大版本值（maxVersion）和数据存储生命周期（TTL）。由于在Hbase存储***中，同一个值的多个版本是并存的，并且可以通过查询操作获取，使用maxVersion可以限定存储和查询的最大版本值，超过这个值的版本无法被查询，并且在数据整理时会被删除。TTL则用于设置表中数据的生命周期，超过该周期的数据将被自动删除。

在步骤101中接收到有效的业务数据后，本步骤根据标准化数据定义中的数据细节定义中提供的方法，获取业务数据中的每个数据及其取值，即：得到key、value对的具体值，在本申请的一个具体例子中，根据接收到的业务数据中的每个数据key，获取其取值value，采用的是标准数据定义时指定的转换脚本，例如：接收到的业务数据中包括userid，执行标准数据定义时指定的转换脚本return map.get("userid")获取与该userid对应的value值，在接收到的业务数据中可能还包含其他数据，采用上述类似的方法，逐一获取与每个key对应的value值。

在本实施例的一个具体例子中，采用了执行转换脚本的方式获取与key对应的value值，在其他实施方式中，也可以采用其他方式获取。

本申请还提供了一种优选实施方式，即：如果存在衍生数据配置，则根据接收到的业务数据（即：基础数据），计算衍生数据。

在本实施例的一个具体例子中，在步骤101中已经生成了衍生数据配置，并且指定要计算两个衍生数据ip_distance和trade_trend，在本步骤中，按照衍生数据配置中指定的计算方法，根据接收到的基础数据和Hbase中存储的历史累积数据，计算上述衍生数据。上述衍生数据的具体含义和计算方法，在步骤101中详细的说明，具体请参考步骤101中的相关描述。

在本实施例中的上述具体例子中，计算衍生数据时，采用了公共的计算方法，在其他实施方式中，可以采用其他自定义的方法计算衍生数据，计算衍生数据的具体方法，不是本申请的核心，本申请不作限定。

在本实施例的上述具体例子中，计算衍生数据trade_trend时要使用历史累积数据，该历史累积数据也存储在Hbase存储***中，通过存储指定时段的明细数据和日帐数据实现，即：4天之内的数据存储明细，4天之外的数据存储日帐，具体如下：

1）4天之内的数据存储明细，即将累积主体userid和累积策略ID组装成一个rowkey存储到velocity_num表中，并设置该表TTL为4天，maxVersion为200，对每一个累积指标设置一个Column，累积指标包括交易金额、使用余额支付金额等。

2）4天之外的数据存储日帐，即每天执行MR（MapReduce是一种编程模型，用于大规模数据集的并行运算）任务将前一天明细数据累积生成日帐，存储到velocity_num_daily日帐表中，并设置该表TTL为180天，maxVersion为180，累积主体也是指定userid，对每一个累积指标设置一个Column，累积指标包括交易金额、使用余额支付金额等。

在本步骤中，从接收的业务数据中提取了反映业务数据的每个数据及其取值，并根据这些数据（即：基础数据）和历史累计数据，计算了衍生数据，为向采用key-value结构的存储***存储数据作好了准备。

步骤103：将获取的所有数据信息存储在采用key-value结构的存储***中。

本申请提供的方法，将接收到的业务数据以key-value的形式存放在采用key-value结构的***中。本实施例的一个具体的例子中，就是将接收到的业务数据以key-value的形式存储在Hbase存储***中。

在步骤102中，已经完成了业务数据（基础数据）的接收，和衍生数据的计算，在本步骤中，就可以将结果进行合并存储。本实施例的一个具体例子中，采用“业务数据标识码+主键数据”作为数据存储的rowkey，将属于某个特定业务的（即：业务数据标识码对应的业务）、与某个主键数据相关的基础数据和衍生数据合并、存储在Hbase存储***中。

rowkey是Hbase的key-value存储中的key，是一段二进制码流，最大为64KB，内容用户自定义。数据的加载根据rowkey的二进制序由小到大进行排序。通常将要查询的字段作为rowkey，这样可以得到较高的查询效率。

在本实施例的一个具体例子中，在进行标准化数据定义时，指定用户标识userid为主键数据，因此在本步骤中采用“业务数据标识码+userid”作为数据存储的rowkey，将与某个具体的userid对应的数据合并在一起，包括：接收到的基础数据和计算出来的衍生数据，并存储在Hbase表中。在其他实施方式中，也可能没有衍生数据配置，即：不需要计算衍生数据，那么直接根据数据存储的rowkey将某类基础数据（例如：与某个userid对应的业务数据）合并在一起，然后存储在Hbase表中即可。存储过程具体可以采用***提供的put()函数，或者是采用与Hbase client相关的一些封装好的API，例如类似下面的函数调用：

public boolean save(String tableName,String family,String rowkey,String column,String value,long timestamp)；

Hbase中数据的逻辑存储形式如下表所示：

在上表中，有两个列簇：列簇1（column family1）和列簇2（column family2），其中列簇1中有两个列，存放的是接收到的基础数据，列簇2中也有两个列，用于存放计算出来的衍生数据。Hbase中的column Family支持动态扩展，无需预先定义column的数量以及类型，可以根据需要动态添加。

上表是一个简单的Hbase表结构示意，在设计Hbase表结构的时候，要重点考虑以下几个方面的问题：

1）rowkey的散列原则，采用散列方式设计rowkey，可以尽量保证物理存储的负载均衡，提高数据查询效率，避免出现所有新数据都在一个存储节点上堆积的现象。

2）在表结构设计时，尽量将需要查询的字段放在rowkey中，采用类似长窄表（行多列少）的设计模式，查询时更加灵活高效。

3）同一个column family的数据在物理上保存的会比较临近，因此在设计表结构时，可以将需要一次性获取的数据放在同一个column family的列中，也能提高查询的效率。

在本实施例的一个具体例子中，使用“业务数据标识码+userid”作为存储数据的主键，是为了便于对业务数据的查询，既可以灵活地获取与某个业务相关的全部数据，也可以获取某个业务中与特定用户相关的数据（包括基础数据和衍生数据）。

上表仅仅是示意性的，在具体的实施方式中，可能会有不同于上表的逻辑存储结构，与特定用户相关的基础数据和衍生数据也可能包含更多的信息和取值，也可以不采用userid作为主键数据，而采用其他便于查询的字段作为主键数据（例如：登陆时间等），或者仅使用业务数据标识码作为存储数据的主键，这些变更都不影响本申请的核心，都在本申请的保护范围之内。

经过上述三个步骤，业务数据已经存储在采用key-value结构的存储***中。如果有应用***或应用程序需要使用该业务数据，可以直接从存储***中获取所述业务数据，从而实现快速引入业务数据的目的。

采用key-value结构的存储***，可以为访问其业务数据的应用***或应用程序提供不同粒度的数据查询服务，以满足应用***或应用程序的不同需求。在本实施例的一个具体例子中，既可以查询与某个业务相关的数据，也可以查询某个业务中与特定用户相关的数据，这是因为Hbase***提供了灵活的查询机制。

通常情况下，Hbase是根据rowkey来进行查询的，支持3种方式：

1）通过单个rowkey访问，即按照某个rowkey键值进行get操作，获取与该rowkey对应的数据。

2）通过rowkey的范围进行scan，即通过设置startRowKey和endRowKey，在这个范围内进行扫描，获取所需的数据。例如：如果Hbase存储***中存放了多个业务的数据，那么可以通过设置startRowKey为accessCode1，endRowKey为accessCode2，就可以得到业务数据标识码为accessCode1的所有业务数据。需要注意的是，因为rowkey存储时是按照字典排序，所有scan出来的数据也是按照字典排序的。

3）全表扫描，即直接扫描整张表中所有记录。

除了上述查询方式，Hbase还支持基于列的查询方式，即：通过指定rowkey、columnfamily、column，获取某个指定数据的value的所有版本值，这些所有版本值是按照TimeStamp进行排序的；同样的道理，也可以通过指定rowkey、column family、column和TimeStamp来获取指定数据的指定版本的唯一值。

在本实施例的一个具体例子中，使用的是Hbase存储***，在其他实施方式中，也可以使用其他采用key-value结构的存储***，这些存储***都提供了较为灵活的查询方式，都可以实现上述的类似功能。

综上所述，采用key-value结构的存储***，可以为需要引入业务数据的应用***或应用程序提供不同粒度的业务数据。在本实施例的一个具体例子中，采用“业务数据识别码+userid”作为存储旺旺登陆业务数据的主键，因此当支付宝的风险控制管理核心监控***需要引入该业务数据时，可以通过指定旺旺登陆业务的业务数据识别码，获取旺旺登陆业务的所有业务数据；也可以通过指定旺旺登陆业务的业务数据识别码和某个用户的userid，来获取旺旺登陆业务数据中与该用户相关的业务数据。

通常业务数据的引入都是采用成批引入的方式，但是也不排除应用***或者应用程序需要引入某个具体数据的情况，这种情况下，可以按照上述指定rowkey、columnfamily、column（以及TimeStamp）的方式，查询并引入某个具体的数据。

在本实施例的一个具体例子中，将rowkey设计为“业务数据标识码+userid”，在其他实施方式中，可以在rowkey中包含其他需要查询的字段，例如设计为<key1>-<key2>-<key3>...这样的形式，每个key都是一种可能的查询条件，可以为每个key设定一个起始和结束的值。对于只想查key1的所有数据，可以将key1设置为开始值，将key1+1设置为结束值，这样scan的时候可以通过设定startRowKey和endRowKey就能查到所有的key1的value，同理迭代，每个子key都可以这样被设计到rowkey中，从而能够为应用***或者应用程序提供更为细化的业务数据。由此可见，存储***的主键设计对于提供高效灵活的查询方式是非常重要的，不同的实施方式可以采取不同的设计，并不局限于本实施例中上述具体例子中的设计方式，但是各种设计方式的变更，都不影响本申请的核心，都在本申请的保护范围之中。

根据应用***或者应用程序的需求，从采用key-value格式的存储***中获取数据后，就可以直接将数据提供给应用***或者应用程序使用。作为一种可选的方式，为了便于应用***或应用程序使用业务数据，可以与其约定引入数据的格式，那么在从所述存储***中获取了业务数据之后，解析获取的数据，并按照所述约定的格式，重新组装成一个数据集，然后再提供给应用***或应用程序。在这个过程中，还可以从存储***中提取一些点数据，例如，在本实施例的一个具体例子中，获取了与某个用户相关的旺旺登陆业务数据后，还可以查询与该用户相关的历史累积数据（例如：交易金额、使用余额支付金额等），并将这些点数据，与上述获取的业务数据，一起封装成一个与该用户对应的数据集，然后提供给应用***或者应用程序。

在本实施例的一个具体的例子中，将淘宝旺旺登陆业务的业务数据存储在Hbase存储***中，并引入到了支付宝的风险控制管理核心监控***中。此后，如果其他应用***或者应用程序（例如：分析淘宝旺旺用户交易行为的应用***或应用程序）同样需要引入淘宝旺旺登陆业务的业务数据，则可以直接从Hbase存储***中获取淘宝旺旺登陆业务的业务数据并引入；同样的道理，支付宝的风险控制管理核心监控***，也可以根据需要，引入其他淘宝新业务的业务数据。也就是说，采用本申请提供的方法，多个应用***或应用程序可以引入同一个业务的业务数据；而一个应用***或应用程序也可以引入多个业务的业务数据。

采用本申请提供的用于快速引入业务数据的方法，通过将接收到的、按照预先约定格式传输的业务数据存储在采用key-value结构的存储***中，当应用***或应用程序需要引入业务数据时，直接从所述存储***中获取所需的业务数据并引入即可，不需要进行传统的***设计、数据库表结构设计、编码等重复的工作，不仅能够实现快速引入业务数据的目的，而且能够节省开发资源、提高软件开发和后期维护的效率。当多个应用***或者应用程序需要引入同一个业务的业务数据时，上述有益效果更为显著。

在上述的实施例中，提供了一种用于快速引入业务数据的方法，与之相对应的，本申请还提供一种用于快速引入业务数据的装置。

请参看图2，其为本申请提供的一种用于快速引入业务数据的装置实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关的部分请参见方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种用于快速引入业务数据的装置，包括：业务数据接收单元201，用于接收按照约定格式封装的业务数据；业务数据获取单元202，用于根据约定格式从所述业务数据中获取反映业务属性的数据信息；业务数据存储单元203，用于将获取的所有数据信息存储在采用key-value结构的存储***中。

可选的，所述装置还包括：业务数据订阅单元，用于在所述接收按照约定格式封装的业务数据的步骤之前，向所述业务发出针对所述业务数据的订阅申请，并约定传输所述业务数据采用的封装格式。

可选的，所述装置还包括：业务数据定义单元，用于在所述接收按照约定格式封装的业务数据的步骤之前，创建与所述业务数据对应的业务数据定义；

相应的，所述业务数据接收单元包括：业务数据判断子单元，用于判断是否存在与当前要接收的业务数据相对应的业务数据定义；数据接收执行子单元，用于当业务数据判断子单元的判断结果为，存在与当前要接收的业务数据相对应的业务数据定义时，接收所述业务数据。

可选的，所述业务数据定义单元创建的业务数据定义包括：唯一标识所述业务数据的业务数据标识码和与之对应的业务数据属性定义；所述业务数据属性定义包括：业务数据所包含的每个数据的名称、获取其值的方法、和该数据是否为主键数据。

可选的，所述装置还包括：衍生数据配置单元，用于在所述接收按照约定格式封装的业务数据的步骤之前，根据所述业务数据属性定义，判断是否需要计算衍生数据；若是，生成衍生数据配置，在所述配置中指定需要计算的衍生数据及其计算方法。

相应的，所述业务数据获取单元包括：基础数据获取子单元，用于根据约定格式从所述业务数据中逐一获取反映业务属性的数据信息，作为基础数据；衍生数据判断子单元，用于判断是否存在衍生数据配置；衍生数据计算子单元，用于当衍生数据判断子单元的判断结果为，存在衍生数据配置时，根据所述基础数据和所述存储***中存储的与所述业务数据相关的历史累计数据，针对所述衍生数据配置中的每一个衍生数据，采用所述衍生数据配置中与其对应的计算方法，计算所述衍生数据；

相应的，所述业务数据存储单元具体用于，如果所述业务数据获取单元计算了衍生数据，则将所述基础数据和所述衍生数据合并、存储到所述采用key-value结构的存储***中；否则直接将所述基础数据合并、存储到所述采用key-value结构的存储***中。

可选的，所述衍生数据配置单元生成的衍生数据配置中指定的计算方法，包括：***提供的公共的计算方法、和/或自定义的计算方法。

可选的，所述业务数据获取单元还包括：累计数据计算子单元，用于根据所述存储***中存储的需累计的业务数据，按照预先定义的时间间隔，计算所述业务数据与所述时间间隔对应的累积值并存储在所述存储***中。

可选的，所述业务数据存储单元具体用于，采用与所述业务数据对应的业务数据标识码和主键数据作为数据存储的键值，将获取的所有数据信息存储在所述存储***中。

可选的，所述装置还包括：业务数据引入单元，用于根据应用的需求，从所述存储***中获取需引入的业务数据并引入。

可选的，所述业务数据引入单元具体用于：

将某个业务的业务数据引入到需要使用该业务数据的某个应用中；或者，

将多个业务的业务数据依次引入到需要使用所述多个业务的业务数据的某个应用中；或者，

将某个业务的业务数据分别引入到需要使用该业务数据的多个应用中。

可选的，所述装置还包括：业务数据引入单元，用于根据应用的需求，从所述存储***中获取需引入的业务数据并引入。

其中，所述根据应用的需求，从所述存储***中获取需引入的业务数据并引入具体是指：根据应用提供的业务数据标识码，从所述存储***中获取与所述业务数据标识码对应的业务数据；或者，根据应用提供的业务数据标识码和主键数据值，从所述存储***中获取与所述业务数据标识码对应的、并且与所述主键数据值相关的业务数据。

可选的，所述业务数据接收单元具体用于，通过同步接口调用方式，接收按照约定格式封装的业务数据；或者，通过异步消息投递方式，接收按照约定格式封装的业务数据。

可选的，所述业务数据存储单元具体用于，将获取的所有数据存储在下述任意一种采用key-value结构的存储***中：Hbase、Tair、LevelDB或Redis。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

Claims (12)

1.一种用于快速引入业务数据的方法，其特征在于，包括：

创建与所述业务数据对应的业务数据定义；

接收按照约定格式封装的业务数据；

根据约定格式从所述业务数据中获取反映业务属性的数据信息；

将获取的所有数据信息存储在采用key-value结构的存储***中；

其中，所述接收按照约定格式封装的业务数据包括：

判断是否存在与当前要接收的业务数据相对应的业务数据定义；

若是，接收所述业务数据；若否，放弃接收所述业务数据；

所述业务数据定义包括：唯一标识所述业务数据的业务数据标识码和与之对应的业务数据属性定义；

所述业务数据属性定义包括：业务数据所包含的每个数据的名称、获取其值的方法和该数据是否具备主键数据的属性。

2.根据权利要求1所述的用于快速引入业务数据的方法，其特征在于，在所述接收按照约定格式封装的业务数据的步骤之前，向所述业务发出针对所述业务数据的订阅申请，并约定传输所述业务数据采用的封装格式。

3.根据权利要求1所述的用于快速引入业务数据的方法，其特征在于，在所述接收按照约定格式封装的业务数据之前，根据所述业务数据属性定义，判断是否需要计算衍生数据；若是，生成衍生数据配置，在所述配置中指定需要计算的衍生数据及其计算方法；

相应的，所述根据约定格式从所述业务数据中获取反映业务属性的数据信息的步骤，具体包括：

根据约定格式从所述业务数据中获取反映业务属性的数据信息，作为基础数据；

判断是否存在衍生数据配置；

若是，根据所述基础数据和所述存储***中存储的与所述业务数据相关的历史累计数据，针对所述衍生数据配置中的每一个衍生数据，采用所述衍生数据配置中与所述衍生数据对应的计算方法，计算所述衍生数据；

相应的，所述将获取的所有数据存储在采用key-value结构的存储***中是指：

如果在所述根据约定格式从所述业务数据中逐一获取反映业务属性的数据信息的步骤中，计算了衍生数据，则将所述基础数据和所述衍生数据合并并存储到所述采用key-value结构的存储***中；

否则，直接将所述基础数据合并并存储到所述采用key-value结构的存储***中。

4.根据权利要求3所述的用于快速引入业务数据的方法，其特征在于，所述衍生数据配置中指定的计算方法，包括：***提供的公共的计算方法和/或自定义的计算方法。

5.根据权利要求3所述的用于快速引入业务数据的方法，其特征在于，所述与所述业务数据相关的历史累计数据，采用如下方式生成：根据所述存储***中存储的需累计的业务数据，按照预先定义的时间间隔，计算所述业务数据与所述时间间隔对应的累积值并存储在所述存储***中。

6.根据权利要求1所述的用于快速引入业务数据的方法，其特征在于，所述将获取的所有数据信息存储在采用key-value结构的存储***中，具体是指，采用与所述业务数据对应的业务数据标识码和主键数据作为数据存储的键值，将获取的所有数据信息存储在所述存储***中。

7.根据权利要求1-6任意一项所述的用于快速引入业务数据的方法，其特征在于，所述方法进一步包括，根据应用的需求，从所述存储***中获取需引入的业务数据并引入。

8.根据权利要求7所述的用于快速引入业务数据的方法，其特征在于，所述根据应用的需求，从所述存储***中获取需引入的业务数据并引入包括：

将某个业务的业务数据引入到需要使用该业务数据的某个应用中；或者，

将多个业务的业务数据依次引入到需要使用所述多个业务的业务数据的某个应用中；或者，

将某个业务的业务数据分别引入到需要使用该业务数据的多个应用中。

9.根据权利要求6所述的用于快速引入业务数据的方法，其特征在于，所述方法进一步包括，根据应用的需求，从所述存储***中获取需引入的业务数据并引入；

其中，所述根据应用的需求，从所述存储***中获取需引入的业务数据并引入具体是指：根据应用提供的业务数据标识码，从所述存储***中获取与所述业务数据标识码对应的业务数据；或者，根据应用提供的业务数据标识码和主键数据值，从所述存储***中获取与所述业务数据标识码对应的、并且与所述主键数据值相关的业务数据。

10.根据权利要求1所述的用于快速引入业务数据的方法，其特征在于，所述接收按照约定格式封装的业务数据包括：

通过同步接口调用方式，接收按照约定格式封装的业务数据；或者，

通过异步消息投递方式，接收按照约定格式封装的业务数据。

11.根据权利要求1所述的用于快速引入业务数据的方法，其特征在于，所述采用key-value结构的存储***是指Hbase、Tair、LevelDB或Redis存储***中的一种。

12.一种用于快速引入业务数据的装置，其特征在于，包括：

业务数据定义单元，用于创建与所述业务数据对应的业务数据定义；

业务数据接收单元，用于接收按照约定格式封装的业务数据；

业务数据获取单元，用于根据约定格式从所述业务数据中获取反映业务属性的数据信息；

业务数据存储单元，用于将获取的所有数据信息存储在采用key-value结构的存储***中；

其中，所述业务数据接收单元，包括：

业务数据判断子单元，用于判断是否存在与当前要接收的业务数据相对应的业务数据定义；

数据接收执行子单元，用于当业务数据判断子单元的判断结果为，存在与当前要接收的业务数据相对应的业务数据定义时，接收所述业务数据；

所述业务数据定义包括：唯一标识所述业务数据的业务数据标识码和与之对应的业务数据属性定义；

所述业务数据属性定义包括：业务数据所包含的每个数据的名称、获取其值的方法和该数据是否具备主键数据的属性。