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

摘要

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

说明书

技术领域

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

背景技术

随着互联网的发展，云服务平台的应用越来越普及。目前云服务平台 的开放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（Social Network 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:[beenToC  ount,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:[beenToC  ount,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:[beenToC  ount,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:[beenToC  ount,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 （Social Network 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:[beenToC  ount,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:[beenToC  ount,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）等。

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

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

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

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