CN108959291B - 查询方法及相关装置 - Google Patents

Abstract

本发明实施例提供针对异构数据源的查询方法及相关装置，以快速查询到异构数据源中的数据。该方法包括获取查询请求，该查询请求包括查询条件及其类型；根据类型及查询条件，从多个查询策略中确定出最优的查询策略；执行确定出的最优的查询策略，以获取符合上述查询条件的综合数据记录，以实现高速查询。其中，综合数据记录是，将来自各异构数据源的、相关联的数据进行整合处理而得到的。这样可实现一次性查询出所有信息，无需去各个系统分别查询，节约了查询时间，并方便了用户使用。

Description

查询方法及相关装置

技术领域

本发明涉及计算机技术领域，更具体的说是涉及查询方法及相关装置。

背景技术

在现阶段，企业不同的业务数据可能存储在不同的数据源(异构数据源)中。异构数据源可指数据源所依赖的业务应用系统、数据库管理系统不同。

例如，员工在购买办公物资过程中，从员工申请物资到物资配送到员工座位，涉及需求、订单、验收、领用等多个环节，不同环节对应不同的业务用系统，各应用系统对应的数据源存储在不同的数据库管理系统中，构成异构数据源。

在现有查询方式中，用户需要分别查询各个系统以获取信息，这种方式易导致查询到的信息不完整，并且耗时。

因此，如何快速查询到异构数据源中的数据，是目前研发的热门。

发明内容

有鉴于此，本发明实施例提供查询方法及相关装置，以快速查询到异构数据源中的数据。

为实现上述目的，本发明实施例提供如下技术方案：

一种针对异构数据源的查询方法，包括：

获取查询请求，所述查询请求至少包括查询条件及其类型；

至少根据所述查询条件的类型，从多个查询策略中确定出最优的查询策略；

执行确定出的最优的查询策略，以获取符合所述查询条件的综合数据记录；

其中，符合所述查询条件的综合数据记录是，将来自各异构数据源的、相关联的数据进行整合处理而得到的。

一种针对异构数据源的查询装置，包括：

查询模块，用于：

获取查询请求，所述查询请求至少包括查询条件及其类型；

至少根据所述查询条件的类型，从多个查询策略中确定出最优的查询策略；

执行确定出的最优的查询策略，以获取符合所述查询条件的综合数据记录；

符合所述查询条件的综合数据记录是，将来自各异构数据源的、相关联的数据进行整合处理而得到的。

一种查询系统，包括：中间服务器，所述中间服务器包括上述的查询装置。

在本发明实施例中，在获取查询请求后，根据查询请求包含的查询条件及类型，从多个查询策略中确定出最优的查询策略，使用最优的查询策略进行查询，以实现高速查询。同时，查询出的综合数据记录是将来自各异构数据源的、相关联的数据进行整合处理而得到的，这样可实现一次性查询出所有信息，无需去各个系统分别查询，节约了查询时间，并方便了用户使用。

附图说明

图1a和1b为本发明实施例提供的查询系统的示例性结构图；

图2a为本发明实施例提供的查询装置或中间服务器的计算机架构示例图；

图2b、图2c为本发明实施例提供的查询装置或中间服务器的示例性结构图；

图3为本发明实施例提供的具体应用场景示例图；

图4a、图4b、图6a、图6b、图7、图8为本发明实施例提供的针对异构数据源的查询方法的示例性流程图；

图5a和图5b为本发明实施例提供的浏览器端查询界面的示例性结构图；

图5c为本发明实施例提供的手机APP客户端跟踪界面的示例性结构图。

具体实施方式

本发明提供针对异构数据源的查询方法及相关装置(例如查询装置、查询系统)。

图1a示出了上述查询系统的一种示例性结构，其至少可包括：负载均衡集群101、前端服务器集群102、中间服务器集群103和后端存储集群104。

其中，负载均衡集群101包含至少一个负载均衡服务器，前端服务器集群102包括多个web服务器，中间服务器集群103包括多个中间服务器。

负载均衡集群在接收到客户端发送的查询请求(包括查询条件等)后，会根据负载均衡算法，将该查询请求发送至web服务器集群102的一个web服务器上。

接收到查询请求的web服务器，会将上述查询请求发送至中间服务器集群103中的一个中间服务器上。上述查询装置即为中间服务器，或者为中间服务器的组成部分。

中间服务器可执行上述查询方法，通过查询后端存储集群104中存储的综合数据记录或通过实时计算，最终获取到符合查询条件的综合数据记录。

上述查询装置可以硬件或软件的形式部署于中间服务器中。

需要说明的是，综合数据记录是将来自各异构数据源的、相关联的数据进行整合处理而得到的。整合处理可包括汇总、过滤、清洗、数据格式化等。

后端存储集群104中存储的综合数据记录，有一部分是中间服务器定期计算得到的，例如，中间服务器可每隔10分钟从各异构数据源处获取数据，将获取到的相关联的数据进行整合处理，得到综合数据记录，并存储至后端存储集群104；还有一部分，是中间服务器实时计算出符合查询条件的综合数据记录后，存储至后端存储集群104。

此外，中间服务器还可从定期或实时计算得到的综合数据记录中筛选出热点综合数据记录。

因此，后端存储集群104可包括数据库和高速缓存器。其中，数据库用于存储中间服务器定期或实时计算得到的综合数据记录，而高速缓存器用于存储上述热点综合数据记录。

考虑到在一些场景下，可能不需要使用多个web服务器和多个中间服务器。则请参见图1b，上述查询系统也可包括web服务器、中间服务器和后端存储集群104。

图2a则示出了上述中间服务器的一种通用计算机系统结构。

上述计算机系统可包括总线、处理器201、存储器202、通信接口203。

在一个示例中，上述计算机系统还可包括输入设备204和输出设备205。

处理器201、存储器202、通信接口203、输入设备204和输出设备205通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

处理器201可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(NetworkProcessor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specificintegrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

处理器201可包括主处理器(CPU)等。处理器201的个数可为一个或多个。

存储器202中保存有执行本发明技术方案的程序，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。更具体的，存储器202可以包括只读存储器(read-only memory，ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、flash等等。

输入设备204可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入装置、触摸屏、计步器或重力感应器等。

输出设备205可包括允许输出信息给用户的装置，例如显示屏、打印机、扬声器等。

通信接口203可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(WLAN)等。

处理器201通过执行存储器202中所存放的程序以及调用其他设备，可实现图4a、图4b、图6a、图6b、图7、图8所示实施例提供的针对异构数据源的查询方法。

图2b示出了上述查询装置的一种可能的结构示意图，包括：查询模块1、条件分析模块2和计算模块3。

在本申请其他实施例中，请参见图2c，上述查询装置还可包括异步定时模块4。

本文后续将介绍各模块所执行的操作。

上述查询装置及查询系统可应用针对异构数据源查询的各种应用场景。例如，其可应用于需求物资跟踪场景。

更具体的，员工在使用采购平台购买物资过程中，从员工申请物资到物资配送到员工座位，请参见图3，涉及需求、订单、验收、领用等多个环节，采购平台的数据生产模块中的需求子模块、订单子模块、验收子模块、库存子模块、领用子模块为多个业务应用系统，数据生产模块中的各个子模块在采购的过程中支撑业务流程处理，并产生业务数据(需求数据、订单数据、验收数据、库存数据、领用数据)。

各业务应用系统的业务数据一般以单据的形式存储。以采购流程为例，用户首先需要提交需求单，假定一个需求单上同时申请对电脑和公仔进行购买，后续会基于该需求单生成两个订单，订单A和订单B，其中，订单A用于购买电脑，订单B用于购买公仔。并且，这两个订单上都会存储需求单的GUID(Globally Unique Identifier，全局唯一标识符GUID)。这样，订单上的数据与需求单上数据存在关联。

其他环节的单据也是如此，是以需求单为基准单据，存储需求单的GUID。

每个子模块都有自己的独立数据存储，用以支撑内部业务流程，构成异构数据源。在各异构数据源中存储数据，其格式可能完全不一样、大小、时间、分布等也可能都不同。

本申请实施例提供的查询系统可作为采购平台的组成部分，实现一键快速查询所有环节的信息。

除采购跟踪外，本发明实施例所提供的方案还可用于物流发货跟踪，对物品发货进行全流程跟踪。该全流程跟踪贯穿网平系统、物流需求系统、物流订单系统、物流供应商系统、物流配送系统等；异构数据源包括网平数据、采购系统、物流系统、外部供应商数据等。使用本发明实施例所提供的方案，可打破异构系统的隔阂进行整合实时查询，能一键查询所有节点信息。

下面将基于上面的本申请涉及的共性方面，对本申请实施例进一步详细说明。

图4a和图4b示出了中间服务器(查询装置)所执行的查询方法的一种示例性流程，包括：

400：客户端发送查询请求。

用户可通过浏览器客户端或手机APP客户端(例如微信客户端)来发送查询请求。

不同的客户端有不同的查询入口(手机APP客户端可对应第一查询入口，浏览器客户端可对应第二查询入口)，在底层调用不同的查询方法。

上述查询请求至少可包括查询条件及其类型。以“使用人＝Alice”为例，“Alice”是查询条件，而“使用人”为查询条件的类型。此外，上述查询请求中还可包括用户标识、展示条数等。

在以(PC)浏览器客户端发送查询请求的场景下，用户可通过浏览器客户端提供的查询界面输入查询条件。

上述查询界面支持多个类型的查询条件的输入。以需求物资跟踪场景为例，请参见图5a，其提供的查询界面提供的查询条件的类型多种多样，涉及多个环节。例如，“需求单编号”、“需求地点”、“物料类别”、“需求部门”、“需求入口”、“需求用途”等类型对应需求环节，“订单编号类型”则对应订单环节。

此外，状态也作为一种类型，其具体的取值视物资采购的进度而定，包括审批中(审批环节)、采购执行(采购环节)、领用中、领用完毕(领用环节)等。

而在手机APP客户端发送查询请求的场景下，考虑到移动终端屏幕尺寸受限，可设计查询条件为缺省查询条件。

以需求物资跟踪场景为例，可将用户账号对应的具体的申请人或使用人作为缺省查询条件。举例来讲，假定用户账户对应的具体申请人或使用人为Alice，则在打开手机APP客户端的跟踪界面时，无需用户输入，直接触发生成查询条件为Alice的查询请求。

无论通过何种场景发送查询请求，查询请求一般是SQL语句。

401：中间服务器获取查询请求；

实际中，客户端发送的查询请求会先到达前端web服务器，再由web服务器发送至中间服务器。

更具体的，请参见图3，查询请求会到达中间服务器的查询模块1。

402：中间服务器至少根据上述查询条件的类型，从多个查询策略中确定出最优的查询策略；

前述提及，中间服务器可通过查询后端存储集群104中存储的综合数据记录或通过实时计算，最终获取到符合查询条件的综合数据记录。

在一个示例中，后端存储集群104可采用数据库存储中间服务器定期或实时计算得到的综合数据记录(可称为现有综合数据记录)。还可采用高速缓存器存储现有综合数据记录中的热点综合数据记录。

因此，中间服务器至少可通过下述三种途径获取到综合数据记录：

查询高速缓存器中存储的热点综合数据记录；

查询数据库中存储的现有综合数据记录；

实时计算得到综合数据记录。

当然，上述三种途径还可组合使用。

上述三种途径可对应三类查询策略，中间服务器可分析查询条件及其类型，得到分析结果，并根据上述分析结果，从上述三类查询策略中选择其一作为最优的查询策略。

在另一个示例中，在未采用高速缓存器存储热点综合数据记录的情况下，中间服务器可通过下述两种途径获取到综合数据记录：

查询数据库中存储的现有综合数据记录；

实时计算得到综合数据记录。

当然，上述两种途径还可组合使用。

上述两种途径可对应两类查询策略，同样的，中间服务器可分析查询条件及其类型，得到分析结果，并根据上述分析结果，从上述两类查询策略中选择其一作为最优的查询策略。

更具体的，请参见图3，查询模块1将调用条件分析模块2，由条件分析模块2分析上述查询条件及其类型，得到分析结果，并向查询模块1返回分析结果。

查询模块1会根据分析结果，从多个查询策略中确定出最优的查询策略。

403：中间服务器执行确定出的最优的查询策略，以获取符合上述查询条件的综合数据记录；

更具体的，请参见图3，查询模块1将根据分析结果，调用计算模块3进行实时计算得到符合查询条件的综合数据记录；或者，查询模块1会根据分析结果，向数据库或高速缓存器查询符合查询条件的综合数据记录。

404：中间服务器返回符合上述查询条件的综合数据记录。

中间服务器(的查询模块1)会向前端web服务器返回上述综合数据记录，再由前端web服务器返回至客户端。

可以理解的是，当未查询出符合查询条件的综合数据记录时，中间服务器会返回表征查询失败的信息，或返回空集。

在400部分已经介绍了客户端可分为浏览器客户端或手机APP客户端。不同的客户端，其对综合数据记录的展现形式也可不相同。

例如，请参见图5b示出的浏览器客户端的查询界面，其可根据多个维度(查询条件的类型)，多种查询条件来过滤数据，显示物品明细、当前处理状态。

当选中某一条综合数据记录时，还可显现浮动窗口，显示物资走向、各环节的处理人等。

并且，若用户的查询权限足够大，通过浏览器客户端可查询大批量数据。举例来讲，一般用户的查询权限限定只能看到本用户的物资数据。但特定的用户，例如部门秘书，其查询权限可支持其查询整个部门的物资数据。

而对于通过手机APP端查询的场景，在一个示例中，请参见图5c，可只显示以该用户为使用人的综合数据记录。且对于用户来讲，无需要手动输入或选择查询条件，从而简化了用户操作。

可见，在本发明实施例中，可根据查询请求包含的查询条件及类型，从多个查询策略中确定出最优的查询策略，使用最优的查询策略进行查询，以实现高速查询。而查询出的综合数据记录是将来自各异构数据源的、相关联的数据进行整合处理而得到的，这样可实现链接各种数据源、一次性查询出所有信息，让用户实时看到申请物资的进度及其他关联信息，无需用户去各个系统分别查询，节约了查询时间，方便了用户使用。

下面，将介绍中间服务器如何定期计算得到综合数据记录。

请参见图6a，定期计算得到综合数据记录可至少包括如下步骤：

601：获取预设时间内，与各异构数据源的增量数据相关联的、来自各异构数据源的数据；

601部分可由中间服务器上的异步定时模块4，定期触发计算模块3执行。

需要说明是，上述预设时间，可指本次获取时刻与上次获取时刻之间的时间段。例如，在12:00执行了一次获取操作，那么在12:10再次执行获取时，获取的是12:00～12:10之间的、与各异构数据源的增量数据相关联的、来自各异构数据源的数据。

更具体的，请参见图6b，601部分可进一步细化包括：

6011：确定上述预设时间内，各异构数据源的增量数据；

所谓增量数据指：在上一次获取之后的新数据。

沿用前例，假定在12:00～12:10之间有10条订单记录上的数据发生了变化，那这10条订单记录上发生变化的数据为增量数据。

同理，假定在12:00～12:10之间新增了两个需求单，那这两个需求单为增量数据。

可通过时间戳来判断数据是否发生了变化。

6012：确定增量数据对应的基准单标识；

在数据变化较多时，可分批次获取增量数据和基准单标识。

在一个示例中，标识具体为GUID。

前已述及，各异构数据源处的单据，会存储基准单的GUID。例如，在物资采购场景下，是以需求单为基准单。存储同一基准单的GUID的单据，其数据之间存在关联。

6013：获取与上述基准单标识相关联的、来自各异构数据源的数据。

由于有多个异构数据源，所以可多线程并发获取各异构数据源处，与基准单标识相关联的数据。

以前述图3所示的具体应用场景为例，可多线路并发获取需求数据、订单数据、领用数据中与基准单标识相关联的数据。

获取的数据后续会进行整合处理，得到综合数据记录。

602：对获取到的数据进行整合处理，得到综合数据记录；

602部分可由中间服务器上的计算模块3执行。

更具体的，请参见图6b，602部分可进一步细化包括：

6021：对获取到的数据进行清洗处理。

清洗处理中会对数据进行校验，去除无效的数据(例如过时数据和过渡数据)。

6022：以基准单标识(GUID)为基础，对清洗处理后的数据进行关联组合。

在本步骤中，会把对应同一GUID的数据关联组合在一起，这样，可获取同一GUID对应的完整信息。

6023：对关联组合的数据进行字段映射、筛选、格式化处理，得到综合数据记录。

综合数据记录是以某种格式的表格的形式展示的，存储综合数据记录的表格(可称为综合记录表)，其字段、字段值的数据格式等，与各异构数据源单据的字段、字段值的格式可能不相同。此外，关联组合的数据中的一些信息，也可能并不需要展示给用户。例如，订单里的供应商信息、审批信息，可不用展示给用户。

因此，可对关联组合的数据进行筛选、字段映射、格式化等处理，得到综合数据记录。

其中，筛选处理可包括筛选掉不必要的数据；

字段映射可包括将综合记录表的字段链接到相应的数据库字段；

格式化可包括将填入综合记录表同一字段的数据的格式，转换为综合记录表要求的格式。例如，在异构数据源中，状态值1、2、3、4分别表征审批中、采购执行、领用中、领用完毕。而在生成综合数据记录时，需要把状态值转换为综合记录表要求的格式，例如将状态值1转换为审批中、将状态值2转换为采购执行、将状态值3转换为领用中，将状态值4转换为领用完毕。

603：将得到的综合数据记录存储至数据库。

数据库可进一步包括可写数据库和只读数据库(只读数据库可为云数据库)。只读数据库的数量可为多个。

在一个示例中，可将计算得到的综合数据记录写入可写数据库，并同步至只读数据库。

603部分可由中间服务器上的计算模块3执行。

在本发明其他实施例中，在603部分之后，还可包括如下步骤：

604：从得到的综合数据记录中筛选出热点综合数据记录，并将上述热点综合数据记录缓存至高速缓存器(例如redis缓存服务器)。

604部分可由中间服务器上的计算模块3执行。

在不同的场景下，可根据不同的筛选条件筛选热点综合数据记录。

以采购场景为例，可根据时间、用户、状态等维度(或任意组合)筛选出热点综合数据记录。

例如，查询者可能更关心未完成状态的物资的进度及相关信息，因此，可将最近一段时间内(例如一个月或几个月)、处于未完成状态(状态为“审批中、采购执行、领用中)的综合数据记录筛选出来，作为热点综合数据记录。

再例如，可维护一个用户列表，用户列表中示例性得可包括优先级(权限)比较高的用户账号(例如部门秘书的账号)。用户列表上的用户所涉及的综合数据记录，也会被筛选出来，作为热点综合数据记录。

再例如，有些物料类型，查询者会比较关心。例如，相较于书本纸笔，查询者可能更关心电脑的进度及相关信息，因此，可维护一个物料类型列表，物料类型列表上的物料类型所涉及的综合数据记录，也会被筛选出来，作为热点综合数据记录。

可动态统计各维度的访问情况，找到访问频率高的维度，动态调整热点综合数据记录筛选的条件。

高速缓存器可进一步包括主备用高速缓存副本。在主用高速缓存副本发生障碍时，可将备用高速缓存副本作为主用高速缓存副本，将原主用高速缓存副本作为备用高速缓存副本。

与数据库相类似，在一个示例中，可将热点综合数据记录缓存至主用高速缓存副本，并同步至备用高速缓存副本。

更具体的，可以使用人或申请人为粒度存储热点综合数据记录：同一使用人或申请人的综合数据记录存储在一起。例如，可将使用人为Alice的所有综合数据记录存储在一起。

高速缓存副本处的数据可以快速查询，可采用分布式多库读取，读取时可根据负载读取不同的高速缓存副本。

热点综合数据记录示例性得可用于满足手机APP客户端的快速高效查询。

下面，将重点介绍中间服务器如何分析查询条件及其类型，得到分析结果，以及，如何根据上述分析结果，从上述三类查询策略中选择其一作为最优的查询策略。

请参见图7，图7示出了中间服务器(查询装置)所执行的查询方法的另一种示例性流程，包括：

700：中间服务器定期计算得到综合数据记录，将计算得到的综合数据记录存储至数据库，筛选出热点综合数据记录缓存至高速缓存器。

700部分的具体描述可参见前述实施例601-604部分的记载，在此不作赘述。

701：接收来自客户端的查询请求。

用户可通过浏览器客户端或手机APP客户端(例如微信客户端)来发送查询请求。

不同的客户端有不同的查询入口，例如，手机APP客户端可对应第一查询入口，浏览器客户端可对应第二查询入口。

701部分与前述实施例中的400部分相类似，在此不作赘述。

702：中间服务器分析上述查询条件及类型，若满足第一条件，得到上述查询请求涉及查询热点数据的第一分析结果，进入703部分，若满足第二条件，得到上述查询请求涉及查询小批量数据的第二分析结果，进入708部分，若满足第三条件，得到上述查询请求涉及查询大批量数据的第三分析结果，进入711部分。

更具体的，可由条件分析模块2执行702部分，第一或第二或第三分析结果，可返回给查询模块1。

中间服务器或条件分析模块2如何获取查询请求中的查询条件及类型，请参见前述实施例中的401部分和402部分的介绍，在此不作赘述。

下面将结合不同客户端查询的具体场景，介绍第一至第三条件所包含的内容。

前已述及，手机APP客户端可对应第一查询入口，浏览器客户端可对应第二查询入口，则：

(1)，上述第一条件至少可包括：查询请求通过第一查询入口获取。

第一条件对应的是通过移动客户端查询的场景，在此场景下，一般要求快捷、高效，可通过查询热点综合数据记录而实现，因此，第一条件对应的分析结果为涉及查询热点数据。

(2)，上述第二条件至少包括：查询请求通过第二查询入口获取，并且，查询条件为指定类型的查询条件；

(3)，上述第三条件至少包括：查询请求通过第二查询入口获取，并且，查询条件不为指定类型的查询条件。

第二条件和第三条件对应的是通过浏览器客户端查询的场景。

在通过浏览器客户端查询的场景下，又进一步分成两大类情况：

第一类情况：查询条件为指定类型；第二类情况：查询条件不为指定类型。

以通过浏览器客户端查询物资为例，请参见图5a和图5b，对于“结算月份”、“预算月度”等类型，即使输入具体月份，也极可能涉及到大批量数据查询。

而对于“需求单编号”、“使用人”、“订单编号”、“申请人”这些类型，若输入具体的需求单编号、具体的使用人、具体的订单编号、具体的申请人，则一般会涉及小批量数据。例如，输入需求单编号“PR-GO-201504280166”，可能会查询到一条或几条综合数据记录。

因此，“需求单编号”、“使用人”、“订单编号”、“申请人”这些类型可作为指定类型。

此外，在实际中，用户可能会输入多个类型的查询条件。例如，用户在图5a所示的查询界面中，输入需求单编号“PR-GO-201504280166”、输入使用人为Alice，输入结算月份为2017年4月等，只要其中有一个或多个查询条件的类型为指定类型，即可认为满足第二条件。

在本发明其他实施例中，上述第二条件还可进一步包括：指定类型的查询条件是完整的数据。

这是考虑到，与输入“PR-GO-201504280166”相比，若用户在需求单编号一栏中仅输入“PR-GO”，则也可能会涉及到大批量数据查询；同理，与输入“Alice”相比，若用户在使用人一栏中仅输入“A”，则也可能会涉及到大批量数据查询。

因此，除查询类型为指定类型外，也可进一步限定查询条件需为完整的数据。

在具体实现时，由于一般的类型字段都有其要求的格式，若输入的查询条件满足格式要求，可确定输入的查询条件为完整的数据。例如，假定需求单编号的格式要求包括：前缀为“PR-GO-”，后面跟着12位数字。若输入的查询条件满足上述格式要求，则确定输入的查询条件为完整的数据。

此外，在本发明其他实施例中，还可结合查询权限(查询权限可由查询模块1确定)，来确定是涉及小批量数据查询，还是大批量数据查询。例如，一般用户的查询权限限定只能看到本用户的物资数据。但特定的用户，例如部门秘书，其查询权限可支持其查询整个部门的物资数据。因此，一般用户输入“电脑”这一查询条件，只涉及查询该用户购买的电脑的物资数据，而秘书输入“电脑”这一查询条件，可能涉及查询整个部门购买的电脑的物资数据。

综上，在本步骤中，可根据查询请求的入口、查询条件类型等的不同，来得到不同的分析结果，从而确定出查询请求是涉及热点数据查询，还是涉及小批量数据查询，还是涉及大批量数据查询。后续可根据不同的分析结果，选择有针对性的查询策略，以实现查询时间最小化。

703：中间服务器确定第一查询策略为针对第一分析结果的最优的查询策略；

第一查询策略可至少包括，在上述高速缓存器中查询符合上述查询条件的综合数据记录。

这是因为，第一分析结果是涉及手机APP客户端(例如微信客户端)场景下的热点数据查询，而高速缓存器中存储的是热点综合数据记录，所以可在高速缓存器中查询符合查询条件的综合记录。

更具体的，可由前述的查询模块1执行703部分。

704：中间服务器在上述高速缓存器中查询符合上述查询条件的热点综合数据记录，并返回。

可由前述的查询模块1执行704部分。查询模块1会将热点综合数据记录返回给web服务器，由web服务器返回给手机APP客户端。

需要说明的是，查询请求中携带了展示条数，其指示了手机APP客户端(例如微信客户端)首屏页面展示的记录的条数。

假定，查询请求中携带的展示条数为5。而中间服务器查询到7条，则返回5条热点综合数据记录用于首屏页面展示；当然，如果查询到的热点综合数据记录小于5条，则把查询到的热点综合数据记录全部返回。

705：中间服务器实时计算符合上述查询条件的综合数据记录，并将实时计算得到的综合数据记录存储至上述数据库。

可由前述的查询模块1调用计算模块3执行705部分。

前述提及了，中间服务器会定期计算综合数据记录，并筛选一部分更新至高速缓存器，高速缓存器中的记录并不是最新最全的。

因此，在查询热点综合数据记录的同时或之后，中间服务器可实时计算符合上述查询条件的综合数据记录。

此外，在将实时计算得到的综合数据记录存储至数据库之后，还可从中筛选出热点综合数据记录缓存至高速缓存器。具体如何筛选可参见前述介绍，在此不作赘述。

在具体实现时，可直接在各异构数据源上查询符合查询条件的数据，然后将相关联的数据整合为一条综合数据记录。

举例来讲，以物资采购为例，假定查询条件为Alice，则可查询各需求单、订单、采购单中使用人为Alice的数据。再根据各数据中包含的基准单的GUID，对数据进行关联处理，将相关联的数据整合为综合数据记录。

706：中间服务器接收加载第i页(i不等于1)页面的加载请求，从上述数据库中获取用于第i屏页面的展示的目标综合数据记录。

可由前述的查询模块1执行706部分。

在实际中，用户可能会进行翻页操作，从而会发送页面加载请求。例如，在某些手机APP客户端，用户在浏览至第i-1屏底部时，进行向上滑动操作，将会触发发送页面加载请求。

加载请求中携带了页面次序参数(以指示加载的是第几页)，以及展示条数(例如5条)。

由于在705部分，已经实时计算出了最新的、符合查询条件的综合数据记录并存储至数据库，所以，可从数据库中获取未经展示的，且符合上述查询条件的目标综合数据记录，用于第i屏页面的展示。

因此，第一查询策略还可包括：在接收加载第i页页面的加载请求，从数据库中获取用于第i屏页面的展示的目标综合数据记录。

此外，需要注意的是，首屏展示的综合数据记录，是从高速缓存器中获取的，而高速缓存器中的数据并不是最新最全的。因此，若加载请求为加载第二页页面的加载请求时，还可执行下述707部分。

707：在接收到加载第二页页面的加载请求后，中间服务器使用数据库中经实时计算得到的综合数据记录更新上述首屏页面。

更具体的，可由前述的查询模块1返回经实时计算得到的、用于首屏页面更新的综合数据记录。

707部分也为第一查询策略的一部分。

708：中间服务器确定第二查询策略为针对第二分析结果的最优的查询策略；

更具体的，可由前述的查询模块1执行708部分。

上述第二查询策略包括，实时计算符合上述查询条件的综合数据记录。

第二分析结果是涉及浏览器客户端场景下的小批量数据查询，因此，可直接实时计算符合上述查询条件的综合数据记录。

当然，在本发明其他实施例中，针对第二分析结果，也可直接向数据库或高速缓存器查询符合上述查询条件的综合数据记录，在此不作赘述。

709：中间服务器实时计算符合上述查询条件的综合数据记录，并返回。

可由前述的查询模块1调用计算模块3执行709部分。

如何实时计算可参见705部分的描述，在此不作赘述。

710：中间服务器将实时计算得到的综合数据记录存储至数据库。

此外，还可从实时计算得到的综合数据记录中筛选出热点综合数据记录存储至高速缓存器。具体如何筛选可参见前述介绍，在此不作赘述。

可由前述的查询模块1调用计算模块3执行710部分。

711：中间服务器确定第三查询策略为针对第三分析结果的最优的查询策略。

更具体的，可由前述的查询模块1执行711部分。

上述第三查询策略可包括，在数据库中查询符合上述查询条件的综合数据记录。

712：中间服务器在数据库中查询符合查询条件的综合数据记录，并返回。

综上，在本实施例中，根据查询请求的入口、查询条件类型等的不同，得到不同的分析结果，从而确定出查询请求是涉及热点数据查询，还是涉及小批量数据查询，还是涉及大批量数据查询。并根据不同的分析结果，选择有针对性的查询策略：

手机APP客户端首页查询直接路由到高速缓存器获取热点数据，并触发实时计算；翻页加载，则路由至数据库获取综合数据记录；

通过浏览器端查询时，若查询条件包括具体使用人/申请人、具体单据号、时间区间等，则直接拉取异构数据源处数据实时计算，返回有限集合的综合数据记录；并至少将实时计算结果更新至数据库；

否则，路由至数据库查询符合查询条件的综合数据记录。

请参见图8，图8示出了中间服务器(查询装置)所执行的查询方法的又一种示例性流程。

与图7所示实施例相比，在本实施例中，不再考虑入口。上述流程包括：

800-801与前述700-701部分相同，在此不作赘述。

802：中间服务器分析上述查询条件及类型，若上述查询条件为指定类型的查询条件，得到上述查询请求涉及查询热点数据的第四分析结果，进入803部分，否则，得到上述查询请求不涉及查询热点数据的第五分析结果，进入804部分。

更具体的，可由条件分析模块2执行702部分，第四或第五或第三分析结果，可返回给查询模块1。

关于指定类型的查询条件的相关记载，请参见前述实施例702部分，在此不作赘述。

在本实施例中，可根据查询条件是否为指定类型的查询条件，来得到不同的分析结果，从而确定出查询请求是涉及热点数据查询，还是不涉及热点数据查询。后续可根据不同的分析结果，选择有针对性的查询策略，以实现查询优化。

803：中间服务器确定第一查询策略为针对第四分析结果的最优的查询策略，并执行。

第一查询策略的相关记载请参见前述703-707部分的记载，在此不作赘述。

由于本实施例不再区分入口，因此，前述关于手机APP客户端的首屏及非首屏展示的方式，可同样适应于浏览器客户端。

804：中间服务器确定第三查询策略为针对第五分析结果的最优的查询策略，并执行。

第三查询策略的相关记载请参见前述711-712部分的记载，在此不作赘述。

综上，本发明实施例所提供的技术方案具有如下优点：

节省资源成本。用户能快速的自助查询到详细信息，不需要再去各个模块查询各种信息，更加不需要线下找相关业务人员咨询信息。

提升异构系统关联查询的性能。各个系统查询性能大幅度提升，带了客观的用户体验。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、WD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (13)

1.一种针对异构数据源的查询方法，其特征在于，包括：

获取查询请求，所述查询请求至少包括查询条件及其类型；

分析所述查询条件及类型，得到分析结果；

根据所述分析结果，从多个查询策略中选择出最优的查询策略；

执行确定出的最优的查询策略，以获取符合所述查询条件的综合数据记录；

其中，符合所述查询条件的综合数据记录是，将来自各异构数据源的、相关联的数据进行整合处理而得到的；

其中，所述分析所述查询条件及类型，得到分析结果包括：

若满足第一条件，得到所述查询请求涉及查询热点数据的第一分析结果；

若满足第二条件，得到所述查询请求涉及查询小批量数据的第二分析结果；

若满足第三条件，得到所述查询请求涉及查询大批量数据的第三分析结果；其中，所述第一条件至少包括：所述查询请求通过第一查询入口获取，所述第二条件至少包括：所述查询请求通过第二查询入口获取，并且，所述查询条件的类型为指定类型，所述第三条件至少包括：所述查询请求通过第二查询入口获取，并且，所述查询条件的类型不为指定类型；

所述多个查询策略包括第一查询策略、第二查询策略和第三查询策略，所述第一查询策略为针对所述第一分析结果的最优的查询策略，所述第一查询策略包括在高速缓存器中查询符合所述查询条件的综合数据记录，所述第二查询策略为针对所述第二分析结果的最优的查询策略，所述第二查询策略包括实时计算符合所述查询条件的综合数据记录，所述第三查询策略为针对所述第三分析结果的最优查询策略，所述第三查询策略包括在数据库中查询符合所述查询条件的综合数据记录。

2.如权利要求1所述的方法，其特征在于，在所述获取查询请求之前，还包括：

获取预设时间内，与各异构数据源的增量数据相关联的、来自各异构数据源的数据；

对获取到的、相关联的数据进行整合处理，得到综合数据记录；

将得到的综合数据记录存储至数据库。

3.如权利要求2所述的方法，其特征在于，所述获取预设时间内，与各异构数据源的增量数据相关联的、来自各异构数据源的数据包括：

确定所述预设时间内，各异构数据源的增量数据；

确定增量数据对应的基准单标识；

获取与所述基准单标识相关联的、来自各异构数据源的数据。

4.如权利要求2所述的方法，其特征在于，在对获取到的、相关联的数据进行整合处理，得到综合数据记录之后，还包括：

从得到的综合数据记录中筛选出热点综合数据记录；

将所述热点综合数据记录存储至高速缓存器。

5.如权利要求1所述的方法，其特征在于，所述分析所述查询条件及类型，得到分析结果包括：

若所述查询条件为指定类型的查询条件，得到所述查询请求涉及查询热点数据的第四分析结果；否则，得到所述查询请求不涉及查询热点数据的第五分析结果。

6.如权利要求5所述的方法，其特征在于，

所述多个查询策略包括第一查询策略和第三查询策略；

所述根据所述分析结果，从所述多个查询策略中选择出最优的查询策略包括：

确定第一查询策略为针对所述第四分析结果的最优的查询策略；

确定第三查询策略为针对所述第五分析结果的最优的查询策略。

7.如权利要求1所述的方法，其特征在于，所述第一查询策略还包括：

实时计算符合所述查询条件的综合数据记录；

将实时计算得到的综合数据记录存储至所述数据库。

8.如权利要求7所述的方法，其特征在于，

在所述高速缓存器中查询到的、符合所述查询条件的综合数据记录，用于在首屏页面中展示；

在接收到加载第i页页面的加载请求后，所述第一查询策略还包括：

从所述数据库中获取用于第i屏页面的展示的目标综合数据记录；其中，所述目标综合数据记录为经实时计算得到、未经展示，且符合所述查询条件的综合数据记录。

9.一种针对异构数据源的查询装置，其特征在于，包括：

查询模块，用于：

获取查询请求，所述查询请求至少包括查询条件及其类型；

分析所述查询条件及类型，得到分析结果；

根据所述分析结果，从多个查询策略中选择出最优的查询策略；

执行确定出的最优的查询策略，以获取符合所述查询条件的综合数据记录；

其中，符合所述查询条件的综合数据记录是，将来自各异构数据源的、相关联的数据进行整合处理而得到的；

其中，所述分析所述查询条件及类型，得到分析结果包括：

若满足第一条件，得到所述查询请求涉及查询热点数据的第一分析结果；

若满足第二条件，得到所述查询请求涉及查询小批量数据的第二分析结果；

若满足第三条件，得到所述查询请求涉及查询大批量数据的第三分析结果；其中，所述第一条件至少包括：所述查询请求通过第一查询入口获取，所述第二条件至少包括：所述查询请求通过第二查询入口获取，并且，所述查询条件的类型为指定类型，所述第三条件至少包括：所述查询请求通过第二查询入口获取，并且，所述查询条件的类型不为指定类型；

所述多个查询策略包括第一查询策略、第二查询策略和第三查询策略，所述第一查询策略为针对所述第一分析结果的最优的查询策略，所述第一查询策略包括在高速缓存器中查询符合所述查询条件的综合数据记录，所述第二查询策略为针对所述第二分析结果的最优的查询策略，所述第二查询策略包括实时计算符合所述查询条件的综合数据记录，所述第三查询策略为针对所述第三分析结果的最优查询策略，所述第三查询策略包括在数据库中查询符合所述查询条件的综合数据记录。

10.如权利要求9所述的装置，其特征在于，还包括：

计算模块，用于获取预设时间内，与各异构数据源的增量数据相关联的、来自各异构数据源的数据；对获取到的、相关联的数据进行整合处理，得到综合数据记录；将得到的综合数据记录存储至数据库。

11.如权利要求10所述的装置，其特征在于，在所述获取预设时间内，与各异构数据源的增量数据相关联的、来自各异构数据源的数据的方面，所述计算模块具体用于：

确定所述预设时间内，各异构数据源的增量数据；

确定增量数据对应的基准单标识；

获取与所述基准单标识相关联的、来自各异构数据源的数据。

12.一种查询系统，所述查询系统包括中间服务器，所述中间服务器包括如权利要求9中的查询装置。

13.一种计算机系统，所述计算机系统包括处理器和存储器，所述存储器存储指令，所述处理器执行所述指令实现如权利要求1至8中任意一项所述的方法。

Images