CN103685207B - 跨数据源的数据整合系统、装置及方法 - Google Patents

Abstract

本发明提出了一种跨数据源的数据整合系统，包括：客户端，用于向服务器发送数据请求消息；服务器，用于对数据请求消息中的动作字段进行解析以生成数据获取指令，并根据数据获取指令从多个开放服务平台中选择至少部分开放服务平台，根据用户的身份信息获得数据，以及对数据进行汇总整合之后提供给客户端和多个开放服务平台；多个开放服务平台，多个开放服务平台中的每一个开放服务平台用于提供数据。本发明还提出了一种服务器、客户端、跨数据源的数据整合方法。本发明利用云服务器强大的计算性能进行排序、比较、拼装等大量计算任务，实现了不同数据平台来源的数据合并、整合，提高了数据查询效率，并减少了用户的流量花费。

Description

跨数据源的数据整合系统、装置及方法

技术领域

本发明涉及互联网云服务平台技术领域，特别涉及一种跨数据源的数据整合系统、服务器、客户端及方法。

背景技术

随着互联网的发展，云服务平台的应用越来越普及。目前云服务平台的开放API接口（Application Programming Interface，应用程序编程接口），普遍是采用Rest风格设计，根据用户请求的一个URL(Uniform/Universal Resource Locator，统一资源定位符)，来返回一组数据，这些返回的数据是系统预定义的，不可以更改的。由此产生了3个问题：

1.有的时候开发者只是需要一个接口返回的一组数据中的一个或几个字段，大量数据的返回会导致用户流量耗费和速度减慢；

2.对于数据取回后有时还需要自己加工计算，自己的计算设备的能力较弱，最终导致开发者的app（Application，应用程序）性能变差和大规模计算无法应用；

3.无法实现多个平台API的信息整合。

发明内容

本发明的目的旨在至少解决所述技术缺陷之一。

为此，本发明的第一个目的在于提出一种跨数据源的数据整合系统，利用云服务器强大的计算性能进行排序、比较、拼装等大量计算任务，实现了不同数据平台来源的数据合并、整合，提高了数据查询效率，并且减少了用户的流量花费。本发明的第二个目的在于提出一种服务器。本发明的第三个目的在于提出一种客户端。本发明的第四个目的在于提出一种跨数据源的数据整合方法。

为达到上述目的，本发明第一方面的实施例公开了一种跨数据源的数据整合系统，包括：客户端、服务器和多个开放服务平台，其中，所述多个开放服务平台，所述多个开放服务平台中的每一个开放服务平台用于提供数据；所述客户端，用于向所述服务器发送数据请求消息，所述数据请求消息包括动作字段和用户的身份信息；所述服务器，用于对所述数据请求消息中的动作字段进行解析以生成数据获取指令，并根据所述数据获取指令从所述多个开放服务平台中选择至少部分开放服务平台，根据所述用户的身份信息从所述至少部分开放服务平台获得数据，以及对所述数据进行汇总整合之后提供给所述客户端。

根据本发明实施例的跨数据源的数据整合系统，利用云服务器强大的计算性能，对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率，并且大大地减少了用户的流量花费。

在本发明的一个实施例中，所述服务器根据所述用户的身份信息获得所述至少部分开放服务平台中每个所对应的令牌和查询参数，并根据所述令牌和查询参数从所述至少部分开放服务平台获得所述数据。

在本发明的一个实施例中，所述令牌包括私人令牌或公共令牌。

在本发明的一个实施例中，所述数据请求消息还包括返回字段，所述服务器用于根据所述返回字段从所述至少部分开放服务平台获得数据，其中，所述返回字段表示所述客户端所希望获得的数据。

在本发明的一个实施例中，所述返回字段为json格式的字符串。

在本发明的一个实施例中，所述数据请求消息还包括扩展字段，所述服务器用于根据所述扩展字段对所述从至少部分开放服务平台获得的数据进行汇总整合，其中，所述扩展字段表示所述客户端所设置的汇总整合的规则。

本发明第二方面的实施例公开了一种服务器，包括：数据管理模块，用于接收客户端发送的数据请求消息，其中，所述数据请求消息包括动作字段和用户的身份信息；解析模块，对所述数据请求消息中的动作字段进行解析以生成数据获取指令；数据获取模块，用于根据所述数据获取指令从所述多个开放服务平台中选择至少部分开放服务平台，并根据所述用户的身份信息从所述至少部分开放服务平台获得数据；数据整合模块，用于对所述数据进行汇总整合之后提供给所述客户端。

根据本发明实施例的服务器，利用云服务器强大的计算性能，根据客户端的数据请求对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率。

在本发明的一个实施例中，所述数据获取模块根据所述用户的身份信息获得所述至少部分开放服务平台中每个所对应的令牌和查询参数，并根据所述令牌和查询参数从所述至少部分开放服务平台获得所述数据。

在本发明的一个实施例中，所述令牌包括私人令牌或公共令牌。

在本发明的一个实施例中，所述数据获取模块用于根据所述返回字段从所述至少部分开放服务平台获得数据，其中，所述返回字段表示所述客户端所希望获得的数据。

在本发明的一个实施例中，所述返回字段为json格式的字符串。

在本发明的一个实施例中，所述数据请求消息还包括扩展字段，所述数据整合模块用于根据所述扩展字段对所述从至少部分开放服务平台获得的数据进行汇总整合，其中，所述扩展字段表示所述客户端所设置的汇总整合的规则。

本发明第三方面的实施例公开了一种客户端，包括：发送模块，用于向服务器发送数据请求消息，所述数据请求消息包括动作字段和用户的身份信息；接收模块，用于从所述服务器接收所述服务器根据所述数据请求消息获取并进行汇总整合的数据。

根据本发明实施例的客户端，可以提交数据请求使云服务器对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率，并且大大地减少了用户的流量花费。

在本发明的一个实施例中，所述数据请求消息还包括返回字段，所述服务器用于根据所述返回字段从所述至少部分开放服务平台获得数据，其中，所述返回字段表示所述客户端所希望获得的数据。

在本发明的一个实施例中，所述返回字段为json格式的字符串。

在本发明的一个实施例中，所述数据请求消息还包括扩展字段，所述服务器用于根据所述扩展字段对所述从至少部分开放服务平台获得的数据进行汇总整合，其中，所述扩展字段表示所述客户端所设置的汇总整合的规则。

本发明第四方面实施例公开了一种跨数据源的数据整合方法，包括以下步骤：接收客户端发送的数据请求消息，其中，所述数据请求消息包括动作字段和用户的身份信息；对所述数据请求消息中的动作字段进行解析以生成数据获取指令；根据所述数据获取指令从所述多个开放服务平台中选择至少部分开放服务平台；根据所述用户的身份信息从所述至少部分开放服务平台获得数据；对所述数据进行汇总整合之后提供给所述客户端。

根据本发明实施例的跨数据源的数据整合方法，利用云服务器强大的计算性能，对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率，并且大大地减少了用户的流量花费。

在本发明的一个实施例中，所述根据用户的身份信息从所述至少部分开放服务平台获得数据进一步包括：根据所述用户的身份信息获得所述至少部分开放服务平台中每个所对应的令牌和查询参数；根据所述令牌和查询参数从所述至少部分开放服务平台获得所述数据。

在本发明的一个实施例中，所述令牌包括私人令牌或公共令牌。

在本发明的一个实施例中，所述数据请求消息还包括返回字段，所述方法还包括：根据所述返回字段从所述至少部分开放服务平台获得数据，其中，所述返回字段表示所述客户端所希望获得的数据。

在本发明的一个实施例中，所述数据请求消息还包括扩展字段，所述方法还包括：根据所述扩展字段对所述从至少部分开放服务平台获得的数据进行汇总整合，其中，所述扩展字段表示所述客户端所设置的汇总整合的规则。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明所述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本发明实施例的跨数据源的数据整合系统的示意图；

图2为根据本发明一个实施例的跨数据源的数据整合系统的数据流向示意图；

图3为根据本发明实施例的服务器的示意图；

图4为根据本发明实施例的客户端的示意图；

图5为根据本发明一个实施例的跨数据源的数据整合方法的流程图；以及

图6为根据本发明另一个实施例的跨数据源的数据整合方法的流程图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

如图1所示，本发明第一方面实施例的跨数据源的数据整合系统包括：客户端101、服务器102和多个开放服务平台103。

具体地，客户端101用于向服务器102发送数据请求消息，数据请求消息包括动作字段和用户的身份信息。服务器102用于对数据请求消息中的动作字段进行解析以生成数据获取指令，其中解析方法可包括语义解析等方法，并根据数据获取指令从多个开放服务平台中选择至少部分开放服务平台，根据用户的身份信息从至少部分开放服务平台获得数据，以及对数据进行汇总整合之后提供给客户端101。多个开放服务平台103中的每一个开放服务平台用于提供数据。在本发明的一个实施例中，与服务器102相连的会有多个开放服务平台（API）103，但是服务器每次根据客户端101的需求可能会仅从多个开放服务平台中选择一部分开放服务平台，例如服务器102对于需要查询的开放服务平台进行功能筛选，例如，只选其中质量高的renren和sina，qq，但是不要开心网的信息。

服务器102根据用户的身份信息获得至少部分开放服务平台103中每个所对应的令牌（token）和查询（query）参数，并根据令牌和查询参数从至少部分开放服务平台103获得数据。其中，令牌包括私人令牌或公共令牌。

根据本发明实施例的跨数据源的数据整合系统，可以针对各类现有的api接口，比如人人网api，新浪微博api，腾讯开发平台api，将各不同api框架的数据平台分别作为独立的数据源进行管理，进行query和submit（提交），同时将query结果按需裁剪或增加特性信息。

其中，同类型数据整合，不局限于以下几类

1）地理位置整合：

例如，从大众点评api和百度身边api同时获得中关村的餐馆列表，自动整合其中的评论和菜价信息----当展示时，用户可以使用框架特性，进行对菜价求平均值等操作。

2）以人为维度整合

获取一个用户在人人，weibo，地图，身边等等api提供的用户数据，为用户组织一个timeline，整合过程中，开发者可以使用框架对特性信息进行整合和裁剪。

3）以组织为维度整合

获取一个组织在不同平台的api接口提供的数据，可以组建timeline，或者完善各平台的评价，留言，做分析或暂时存储等。

【实施例1】

在本实施例中，服务器102接收数据消息后，按照动作字段user，选择SNS（SocialNetwork Site，社交网站）等用户关系类开放服务平台103的api，将id转换为各个平台对应的token和query参数，将数据请求的结果按照语义进行拼装、整合，向客户端101返回，具体如下：

数据请求url为：http://api.baidu.com/user?id=123

A平台api返回：

B平台api返回：

合并结果：

在进行上述合并过程时，应用了如下规则：

1.字段名合并规则：

对于uname和name自动，根据通用分析规则，合并成为name，同时将字段归并（merge）成为name。

2.字段内容合并规则:

字段内容不同时默认合并为一个json数组，当开发者配置主merge平台为A平台时，系统会将name字段格式化为：fish。

3.将不同平台返回数据的类型格式化:

不同平台的返回数据的类型会出现有差异，主要有两部分：

1.返回格式，有的是xml，有的是json等等，取得数据时本平台统一格式化成json格式。

2.数据结构差异，主要可能出现嵌套层次问题，系统可以自定义数据处理规则，默认集成了对数据的去嵌套处理，将{{}}处理为{}。

为将不同平台的返回数据进行类型格式化，可在数据请求中包括返回（return）和/或扩展（extend）字段。其中，返回字段表示客户端101所希望获得的数据，即需要返回的字段值，服务器102根据返回字段从至少部分开放服务平台103获得数据。返回字段可以是json格式的字符串。扩展字段表示客户端101所设置的汇总整合的规则，服务器102根据扩展字段对从至少部分开放服务平台获得的数据进行汇总整合。

【实施例2】

本实施例为实施例1的变型，用户需要查询店名和电话，于是可定义返回字段为：return={name,phone}，即表示客户端需要返回name字段和phone字段，此时数据请求url变为：

http://api.baidu.com/user?id=123&return={name,phone}

这时返回值变为：

extend字段用来表示需要计算的返回的字段。extend字段可以是一个json格式的字符串。

数据请求中可以加入extend可以要求服务器进行计算，计算类型包括通用的四则运算，同时还支持sort，！，=，>，<等通用运算符及规则，且可以扩展。

【实施例3】

当用户请求一个商户列表时，默认数据请求的url为：

http://api.baidu.com/shops?p=1&pn=2(其中，p是起始页，pn是每页个数)，当请求时，按照动作字段shops，系统选取大众点评、百度身边等生活消费类类平台的api，生成各个平台对应的token和query参数，获取数据请求的结果，并将结果按照语义拼装、整合后的数据返回给客户端（其中，拼装、整合过程和前一实施例中的user一致）：

平台返回：

当需要获取一个用户想要的字段时，可以支持获取一个字段能够返回收藏该商店数量和去过该商店数量的和，此时可定义一个扩展字段extend={allCount:[collectCount,+,bennToCount]},此时数据请求url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={allCount:{collectCount,+,bennToCount}}

此时返回值为：

即，返回值中额外增加了allCount字段，这一字段可供服务器进行比较、排序用，作为对数据进行整合的参考依据。

【实施例4】

本实施例为实施例3的变型，用户需要获取评分在15分以上的商户，即需要获取score>15的商户时，可定义extend={{score,>,15}},此时数据请求url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={socre:[score,>,15]}

此时返回值为：

即，实施例3的返回结果中，KFC的表项因为score值为10，不满足score>15的extend条件，所以未出现在返回结果中。

【实施例5】

本实施例为实施例3的变型，当需要返回结果按照beenToCount排序时，可定义

extend={beenToCount:[beenToCount,sort,desc]},此时Url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={beenToCount:[beenToCount,sort,desc]}

此时返回数据变成：

即，返回结果按照各表项的beenToCount值进行了排序。

【实施例6】

本实施例为实施例3~5的变型，extend字段支持复合计算，当把实施例3~5结合，按照beenToCount排序和加入allCount放在一起时，extend={beenToCount:[beenToCount,sort,desc],allCount:[collectCount,+,benn ToCount]}

此时数据请求url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={beenToCount:[beenToCount,sort,desc],allCount:[collectCount,+,bennToCount]}

此时返回值变成：

在实施例1~6中，各开放服务平台所返回的数据类型是相同的。

extend字段不限制定义的计算组数量，但是会按照从前到后的方式计算，如果数据请求url中出现不合法的语法(例如对一个string做加法)，则此时该部分规则作废，不做计算。如果当计算到某一个规则时，已经没有满足当前规则的返回数据，则此时不再计算后续规则，直接向客户端返回空值。

下面对数据请求url中的动作字段规则加以说明：

动作字段可包括v（动作）、n（名字）、t（类型）部分，当动作字段只有名字部分时，拆分规则见实施例1~6。当动作字段中有v时，会对v进行解析生成首层查询数据，并将查询结果作为2层查询数据的请求参数。

根据本发明实施例的跨数据源的数据整合系统，可以针对各类现有的api接口，比如人人网api，新浪微博api，腾讯开发平台api，将各不同api框架的数据平台分别作为独立的数据源进行管理，进行query和submit（提交），同时将query结果按需裁剪或增加特性信息。

其中，不同类型数据整合，不局限于以下几类：

a)引导整合

例如：在中关村获取人人网api提供的用户周边的朋友信息和百度地图api提供的交通数据，帮助数个人走到同一个目的地。

b)主动推送

例如：时光网提供电影列表api获得近期电影，在根据人人网api获得用户喜好或者期望的电影，向用户进行推荐。

【实施例7】

当进行商户推荐的query时，数据请求url为：

http://api.baidu.com/promote_shops_by-user?uid=123&p=1&pn=2

对于商户推荐的query，先根据v=promote确定这是一个推荐query，然后根据by-user和uid参数生成该uid对应的各个sns等用户关系类平台token和query参数，请求结果，将结果按照语义拼装，使用return字段获取其中表示用户兴趣的字段interest：[eating,swimming]，解析该字段内容获取shopping和swimming，作为query参数去查询大众点评、百度身边等生活消费类类平台的api，获取一份商户列表：

此时返回值变成：

对于t（本实施例中为by-user），可以根据用户的需求，增加多种类型进行扩展，比如by-user-sport，by-group-ktv等等。

【实施例8】

本实施例的数据流向过程如图2所示，首先，客户端发送数据请求，各网站api管理模块接收该数据请求消息，然后对该数据请求进行语义解析，从所有开放服务api中选取若干个api，例如人人api和sina api。

选择后，根据用户的身份信息从选择的api中获得数据，并进行数据处理和整合，处理完毕后，将整合后的数据发送给客户端，以向客户显示。

根据本发明实施例的跨数据源的数据整合系统，利用云服务器强大的计算性能，对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率，并且大大地减少了用户的流量花费。

如图3所示，本发明第二方面实施例的服务器，包括：数据管理模块301、解析模块302、数据获取模块303和数据整合模块304。

数据管理模块301用于接收客户端发送的数据请求消息，其中，数据请求消息包括动作字段和用户的身份信息。解析模块302对数据请求消息中的动作字段进行语义解析以生成数据获取指令。数据获取模块303用于根据数据获取指令从多个开放服务平台中选择至少部分开放服务平台，并根据用户的身份信息从至少部分开放服务平台获得数据。数据整合模块304用于对数据进行汇总整合之后提供给客户端。

在本发明的一个实施例中，数据管理模块301接收来自客户端的数据请求url为：http://api.baidu.com/user?id=123，其中，动作字段为user，解析模块将动作字段user解析为用户关系，数据获取模块303选择SNS（Social Network Site，社交网站）等用户关系类开放服务平台的api，将id转换为各个平台对应的令牌和查询参数，由数据整合模块304将数据请求的结果按照语义进行拼装、整合后，向客户端返回，具体如下：

A平台api返回：

B平台api返回：

合并结果：

在实际应用中，通常各服务平台的api不尽相同，因此需要对数据进行汇总整合。

将不同平台返回数据的类型格式化:

不同平台的返回数据的类型会出现有差异，主要有两部分：

1.返回格式，有的是xml，有的是json等等，取得数据时本平台统一格式化成json格式。

2.数据结构差异，主要可能出现嵌套层次问题，系统可以自定义数据处理规则，默认集成了对数据的去嵌套处理，将{{}}处理为{}。

在本发明的一个实施例中，定义返回字段为：return={name,phone},此时请求url变为：

http://api.baidu.com/user?id=123&return={name,phone}

此时返回值变为：

extend用来表示需要计算的返回的字段，extend是一个json格式的字符串。

当用户请求时可以加入extend可以要求服务器做计算，目前支持通用的四则运算，同时还支持sort，！=，>,<等通用规则，且可以扩展。比如，当用户请求一个商户列表时，默认请求的url为：

http://api.baidu.com/shops?p=1&pn=2(其中p是起始页，pn是每页个数)，当请求时，按照动作字段shops，系统加载大众点评，百度身边等生活消费类类平台的api，生成各个平台对应的token和query参数，请求结果，将结果按照语义拼装返回数据（拼装过程和user一致）：

当需要获取一个多出的字段，可以支持获取一个字段能够返回收藏数量和去过数量的和，此时可定义

extend={allCount:[collectCount,+,bennToCount]},此时Url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={allCount:{collectCount,+,bennToCount}}

此时返回值为：

当需要获取score>15的商户时，定义extend={{score,>,15}},此时url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={socre:[score,>,15]}

此时返回值为：

当用户需要返回结果按照beenToCount排序时，可定义

extend={beenToCount:[beenToCount,sort,desc]},此时Url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={beenToCount:[beenToCount,sort,desc]}

此时返回数据变成：

extend支持复合计算，比如，当把以上结果按照beenToCount排序和加入allCount放在一起时，

extend={beenToCount:[beenToCount,sort,desc],allCount:[collectCount,+,benn ToCount]}

此时url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={beenToCount:[beenToCount,sort,desc],allCount:[collectCount,+,bennToCount]}

此时返回值变成：

extend字段不限制定义的计算组数量，但是会按照从前到后的方式计算，如果数据请求url中出现不合法的语法(例如对一个string做加法)，则此时该部分规则作废，不做计算。如果当计算到某一个规则时，已经没有满足当前规则的返回数据，则此时不再计算后续规则，直接向客户端返回空值。

当进行商户推荐的query时：

http://api.baidu.com/promote_shops_by-user?uid=123&p=1&pn=2

对于商户推荐的query，先根据v=promote确定这是一个推荐query，然后根据by-user和uid参数生成该uid对应的各个sns等用户关系类平台token和query参数，请求结果，将结果按照语义拼装，使用return字段获取其中表示用户兴趣的字段interest：[eating,swimming]，解析该字段内容获取shopping和swimming，作为query参数去查询大众点评、百度身边等生活消费类类平台的api，获取一份商户列表：

此时返回值变成：

对于t（本实施例中为by-user），可以根据用户的需求，增加多种类型进行扩展，比如by-user-sport，by-group-ktv等等。

根据本发明实施例的服务器，利用云服务器强大的计算性能，根据客户端的数据请求对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率。

如图4所示，本发明第三方面的实施例的客户端包括：发送模块401和接收模块402。发送模块401用于向服务器发送数据请求消息，其中数据请求消息包括动作字段和用户的身份信息。接收模块402用于从服务器接收服务器根据数据请求消息获取并进行汇总整合的数据。

在本发明的一个实施例中，数据请求消息还包括返回字段和扩展字段。返回字段表示客户端所希望获得的数据，服务器用于根据返回字段从至少部分开放服务平台获得数据。返回字段的类型，可以是json格式的字符串。扩展字段表示客户端所设置的汇总整合的规则，服务器根据扩展字段对从至少部分开放服务平台获得的数据进行汇总整合。

可定义返回字段为：return={name,phone}，即表示客户端需要返回name字段和phone字段，此时数据请求url为：

http://api.baidu.com/user?id=123&return={name,phone}

这时返回值为：

当需要获取一个用户想要的字段时，可以支持获取一个字段能够返回收藏数量和去过数量的和，此时可定义一个扩展字段extend={allCount:[collectCount,+,bennToCount]},此时数据请求url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={allCount:{collectCount,+,bennToCount}}

此时返回值为：

即，返回值中额外增加了allCount字段。

根据本发明实施例的客户端，可以提交数据请求使云服务器对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率，并且大大地减少了用户的流量花费。

如图5所示，本发明第四方面实施例的跨数据源的数据整合方法，包括以下步骤：

S501：接收客户端发送的数据请求消息，其中，数据请求消息包括动作字段和用户的身份信息。

S502：对数据请求消息中的动作字段进行语义解析以生成数据获取指令。

S503：根据数据获取指令从多个开放服务平台中选择至少部分开放服务平台。

S504：根据用户的身份信息从至少部分开放服务平台获得数据。

S505：对数据进行汇总整合之后提供给客户端。

根据本发明实施例的跨数据源的数据整合系统，可以针对各类现有的api接口，比如人人网api，新浪微博api，腾讯开发平台api，将各不同api框架的数据平台分别作为独立的数据源进行管理，进行query和submit（提交），同时将query结果按需裁剪或增加特性信息。

其中，同类型数据整合，不局限于以下几类

1）地理位置整合：

例如，从大众点评api和百度身边api同时获得中关村的餐馆列表，自动整合其中的评论和菜价信息----当展示时，用户可以使用框架特性，进行对菜价求平均值等操作。

2）以人为维度整合

获取一个用户在人人，weibo，地图，身边等等api提供的用户数据，为用户组织一个timeline，整合过程中，开发者可以使用框架对特性信息进行整合和裁剪。

3）以组织为维度整合

获取一个组织在不同平台的api接口提供的数据，可以组建timeline，或者完善各平台的评价，留言，做分析或暂时保存。

【实施例9】

在本实施例中，服务器接收数据消息后，按照动作字段user，选择SNS（SocialNetwork Site，社交网站）等用户关系类开放服务平台的api，将id转换为各个平台对应的token和query参数，将数据请求的结果按照语义进行拼装、整合，向客户端返回，具体如下：

数据请求url为：http://api.baidu.com/user?id=123

A平台api返回：

B平台api返回：

合并结果：

在进行上述合并过程时，应用了如下规则：

1.字段名合并规则：

对于uname和name自动，根据通用分析规则，合并成为name，同时将字段归并（merge）成为name。

2.字段内容合并规则:

字段内容不同时默认合并为一个json数组，当开发者配置主merge平台为A平台时，系统会将name字段格式化为：fish。

3.将不同平台返回数据的类型格式化:

不同平台的返回数据的类型会出现有差异，主要有两部分：

1.返回格式，有的是xml，有的是json等等，取得数据时本平台统一格式化成json格式。

2.数据结构差异，主要可能出现嵌套层次问题，系统可以自定义数据处理规则，默认集成了对数据的去嵌套处理，将{{}}处理为{}。

为将不同平台的返回数据进行类型格式化，可在数据请求中包括返回（return）和/或扩展（extend）字段。其中，返回字段表示客户端所希望获得的数据，即需要返回的字段值，服务器根据返回字段从至少部分开放服务平台获得数据。返回字段可以是json格式的字符串。扩展字段表示客户端所设置的汇总整合的规则，服务器根据扩展字段对从至少部分开放服务平台获得的数据进行汇总整合。

【实施例10】

本实施例为实施例9的变型，用户需要查询店名和电话，于是可定义返回字段为：return={name,phone}，即表示客户端需要返回name字段和phone字段，此时数据请求url变为：

http://api.baidu.com/user?id=123&return={name,phone}

这时返回值变为：

extend字段用来表示需要计算的返回的字段。extend字段可以是一个json格式的字符串。

数据请求中可以加入extend可以要求服务器进行计算，计算类型包括通用的四则运算，同时还支持sort，！，=，>，<等通用运算符及规则，且可以扩展。

【实施例11】

当用户请求一个商户列表时，默认数据请求的url为：

http://api.baidu.com/shops?p=1&pn=2(其中，p是起始页，pn是每页个数)，当请求时，按照动作字段shops，系统选取大众点评、百度身边等生活消费类类平台的api，生成各个平台对应的token和query参数，获取数据请求的结果，并将结果按照语义拼装、整合后的数据返回给客户端（其中，拼装、整合过程和前一实施例中的user一致），其中，token包括私人token和公共token：

平台返回：

当需要获取一个用户想要的字段时，可以支持获取一个字段能够返回收藏数量和去过数量的和，此时可定义一个扩展字段

extend={allCount:[collectCount,+,bennToCount]},此时数据请求url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={allCount:{collectCount,+,bennToCount}}

此时返回值为：

即，返回值中额外增加了allCount字段，这一字段可供服务器进行比较、排序用，作为对数据进行整合的参考依据。

【实施例12】

本实施例为实施例11的变型，用户需要获取评分在15分以上的商户，即需要获取score>15的商户时，可定义extend={{score,>,15}},此时数据请求url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={socre:[score,>,15]}

此时返回值为：

即，实施例3的返回结果中，KFC的表项因为score值为10，不满足score>15的extend条件，所以未出现在返回结果中。

【实施例13】

本实施例为实施例11的变型，当需要返回结果按照beenToCount排序时，可定义

extend={beenToCount:[beenToCount,sort,desc]},此时Url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={beenToCount:[beenToCount,sort,desc]}

此时返回数据变成：

即，返回结果按照各表项的beenToCount值进行了排序。

【实施例14】

本实施例为实施例11~13的变型，extend字段支持复合计算，当把实施例3~5结合，按照beenToCount排序和加入allCount放在一起时，extend={beenToCount:[beenToCount,sort,desc],allCount:[collectCount,+,benn ToCount]}

此时数据请求url变成：

http://api.baidu.com/shops?p=1&pn=2&extend={beenToCount:[beenToCount,sort,desc],allCount:[collectCount,+,bennToCount]}

此时返回值变成：

在实施例9~14中，各开放服务平台所返回的数据类型是相同的。

extend字段不限制定义的计算组数量，但是会按照从前到后的方式计算，如果数据请求url中出现不合法的语法(例如对一个string做加法)，则此时该部分规则作废，不做计算。如果当计算到某一个规则时，已经没有满足当前规则的返回数据，则此时不再计算后续规则，直接向客户端返回空值。

下面对数据请求url中的动作字段规则加以说明：

动作字段可包括v（动作）、n（名字）、t（类型）部分，当动作字段只有名字部分时，拆分规则见实施例1~6。当动作字段中有v时，会对v进行解析生成首层查询数据，并将查询结果作为2层查询数据的请求参数。

根据本发明实施例的跨数据源的数据整合系统，可以针对各类现有的api接口，比如人人网api，新浪微博api，腾讯开发平台api，将各不同api框架的数据平台分别作为独立的数据源进行管理，进行query和submit（提交），同时将query结果按需裁剪或增加特性信息。

其中，不同类型数据整合，不局限于以下几类：

a)引导整合

例如：在中关村获取人人网api提供的用户周边的朋友信息和百度地图api提供的交通数据，帮助数个人走到同一个目的地。

b)主动推送

例如：时光网提供电影列表api获得近期电影，在根据人人网api获得用户喜好或者期望的电影，向用户进行推荐。

【实施例15】

当进行商户推荐的query时，数据请求url为：

http://api.baidu.com/promote_shops_by-user?uid=123&p=1&pn=2

对于商户推荐的query，先根据v=promote确定这是一个推荐query，然后根据by-user和uid参数生成该uid对应的各个sns等用户关系类平台token和query参数，请求结果，将结果按照语义拼装，使用return字段获取其中表示用户兴趣的字段interest：[eating,swimming]，解析该字段内容获取shopping和swimming，作为query参数去查询大众点评、百度身边等生活消费类类平台的api，获取一份商户列表：

此时返回值变成：

对于t（本实施例中为by-user），可以根据用户的需求，增加多种类型进行扩展，比如by-user-sport，by-group-ktv等等。

【实施例16】

在本发明的一个实施例中，数据请求中包括返回字段和扩展字段，跨数据源的数据整合方法的流程如图6所示：

S601：根据用户需要在数据请求中组合请求参数，在动作字段之外，还可选择性加入返回字段和扩展字段。返回字段、扩展字段应根据用户需求而定义。

S602：对数据请求进行语义分析，根据动作字段，按照筛选规则从所有api库中选出api库。

S603：查询多api库的数据，将请求结果进行基础合并及拼装。

S604：检查有无返回字段，如果有，执行S605；如果没有，执行S608。

S605：将返回数据打包，按照返回字段的要求填充待返回数据的字段格式。

S606：检查有无扩展字段，如果有，执行S607；如果没有，执行S608.

S607：按照扩展字段中的规则，对待返回的数据进行计算、筛选。

S608：将数据返回给客户端。

根据本发明实施例的跨数据源的数据整合方法，利用云服务器强大的计算性能，对从各数据平台获取的数据进行排序、比较、拼装等大量计算任务，实现了由不同api框架数据平台来源的数据的合并、整合，提高了数据的收集、查询效率，并且大大地减少了用户的流量花费。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备（如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统）使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例（非穷尽性列表）包括以下：具有一个或多个布线的电连接部（电子装置），便携式计算机盘盒（磁装置），随机存取存储器（RAM），只读存储器（ROM），可擦除可编辑只读存储器（EPROM或闪速存储器），光纤装置，以及便携式光盘只读存储器（CDROM）。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列（PGA），现场可编程门阵列（FPGA）等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对所述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。在本发明中，术语“多个”是指两个或两个以上。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同限定。

Claims (7)

1.一种跨数据源的数据整合系统，其特征在于，包括客户端、服务器和多个开放服务平台，其中，

所述多个开放服务平台，所述多个开放服务平台中的每一个开放服务平台用于提供数据；

所述客户端，用于向所述服务器发送数据请求消息，所述数据请求消息包括动作字段和用户的身份信息，所述数据请求消息还包括返回和/或扩展字段，其中，所述返回字段表示所述客户端需要返回的字段值，所述扩展字段表示所述客户端设置的汇总整合的规则；

所述服务器，用于对所述数据请求消息中的动作字段进行解析以生成数据获取指令，并根据所述数据获取指令从所述多个开放服务平台中选择至少部分开放服务平台，根据所述用户的身份信息和所述返回字段从所述至少部分开放服务平台获得数据，以及根据所述扩展字段对所述数据进行汇总整合之后提供给所述客户端，

其中所述扩展字段包括要求所述服务器进行计算，计算类型包括通用的四则运算，通用运算符及规则，且支持复合计算，根据用户的身份信息获取至少部分开放服务平台中每个所对应的令牌和查询参数，并根据令牌和查询参数从至少部分开放服务平台中获得数据，令牌包括私人令牌或公共令牌。

2.如权利要求1所述的跨数据源的数据整合系统，其特征在于，所述返回字段为json格式的字符串。

3.一种服务器，其特征在于，包括：

数据管理模块，用于接收客户端发送的数据请求消息，其中，所述数据请求消息包括动作字段和用户的身份信息，所述数据请求消息还包括返回和/或扩展字段，其中，所述返回字段表示所述客户端需要返回的字段值，所述扩展字段表示所述客户端设置的汇总整合的规则；

解析模块，对所述数据请求消息中的动作字段进行解析以生成数据获取指令；

数据获取模块，用于根据所述数据获取指令从多个开放服务平台中选择至少部分开放服务平台，并根据所述用户的身份信息和所述返回字段从所述至少部分开放服务平台获得数据，根据用户的身份信息获取至少部分开放服务平台中每个所对应的令牌和查询参数，并根据令牌和查询参数从至少部分开放服务平台中获得数据，令牌包括私人令牌或公共令牌；以及

数据整合模块，用于根据所述扩展字段对所述数据进行汇总整合之后提供给所述客户端，所述扩展字段包括要求所述服务器进行计算，计算类型包括通用的四则运算，通用运算符及规则，且支持复合计算。

4.如权利要求3所述的服务器，其特征在于，所述返回字段为json格式的字符串。

5.一种客户端，其特征在于，包括：

发送模块，用于向服务器发送数据请求消息，所述数据请求消息包括动作字段和用户的身份信息，所述数据请求消息还包括返回和/或扩展字段，其中，所述返回字段表示所述客户端需要返回的字段值，所述扩展字段表示所述客户端设置的汇总整合的规则，其中根据用户的身份信息获取至少部分开放服务平台中每个所对应的令牌和查询参数，并根据令牌和查询参数从至少部分开放服务平台中获得数据，令牌包括私人令牌或公共令牌；以及

接收模块，用于从所述服务器接收所述服务器根据所述数据请求消息获取并进行汇总整合的数据，所述扩展字段包括要求所述服务器进行计算，计算类型包括通用的四则运算，通用运算符及规则，且支持复合计算。

6.如权利要求5所述的客户端，其特征在于，所述返回字段为json格式的字符串。

7.一种跨数据源的数据整合方法，其特征在于，包括以下步骤：

接收客户端发送的数据请求消息，其中，所述数据请求消息包括动作字段和用户的身份信息，所述数据请求消息还包括返回和/或扩展字段，其中，所述返回字段表示所述客户端需要返回的字段值，所述扩展字段表示所述客户端设置的汇总整合的规则；

对所述数据请求消息中的动作字段进行解析以生成数据获取指令；

根据所述数据获取指令从多个开放服务平台中选择至少部分开放服务平台；

根据所述用户的身份信息和所述返回字段从所述至少部分开放服务平台获得数据，根据用户的身份信息获取至少部分开放服务平台中每个所对应的令牌和查询参数，并根据令牌和查询参数从至少部分开放服务平台中获得数据，令牌包括私人令牌或公共令牌；以及

根据所述扩展字段对所述数据进行汇总整合之后提供给所述客户端，所述扩展字段包括要求所述服务器进行计算，计算类型包括通用的四则运算，通用运算符及规则，且支持复合计算。