一种跨系统多维度数据检索处理方法及装置与流程

本发明实施例涉及计算机技术领域，具体涉及一种跨系统多维度数据检索处理方法及装置。

背景技术：

业主服务系统的项目出发点，就是使经纪人能够深入社区，与业主建立中长频联系，改变经纪人传统作业模式。采用责任划分的方式建立经纪人与业主间高质量的维护关系，提升业主体验。为了实现以上目标，对平台而言，需要能提供对房屋、业主、经纪人责任分配关系等多个实体、多维度的检索查询功能。责任划分为了提高作业质量和对业主的骚扰情况，经纪人作业工作需要在归属自己的责任房屋下进行，而责任划分也就是用于分配经纪人作业范围，是经纪人作业的前提。

检索功能的数据来源是跨系统、多维度的，除去房屋基础信息外，还包括房屋现状采集(业主服务系统)、业主完备情况(业主服务系统)、房屋当前及历史委托情况(f系统)、房屋网签历史(s系统)、房屋租赁数据(r系统)、业主防打扰屏蔽(r系统)等维度。由于数据存在于不同的系统之间，后端程序需要调用各个子系统获取数据，然后对每个查询条件进行相应数据的过滤，然后针对过滤后的数据构建列表并返回前端展示给经纪人。

现有的方式存在如下问题：

(1)数据检索查询次数多

针对来自经纪人不同标签组合下的查询请求，业主服务系统需要根据查询(n个)，逐个处理每个标签条件下符合条件的数据，然后聚合各个条件的数据结果来构建最终的分页结果集。从上面的程序可以看出，数据的筛选标签是关联到不同的系统之间的，针对每个标签我们需要查询不同的系统，每次查询都有一次系统rpc调用或者http调用。

(2)中间临时结果集数据量大

由于不同的条件聚合产生最终的分页结果数据，为此在每个条件检索时，我们尽可能的缩小临时结果集s的大小，但是可能为了一个最终结果分页数据，我们中间需要缓冲更多的临时结果，直到最后条件结果出现后，才获取正常的结果split(s)。

(3)系统资源占用多

为了处理一次结果m条数据的产生，后台系统可能进行了n次系统间远程通信，且系统间的通信流量和系统本地内存使用量都远远大于m的量。而且在不同条件数据结果集的构建中，也会占用cpu时间进行逻辑处理。

(4)接口响应慢，用户体验差

系统间数据网络传输、系统内数据统计计算集合，都是接口处理响应的时间组成，数据逻辑越复杂，可以想象接口响应时间也会越多，对于用户来说，是非常差的系统体验。

(5)系统扩展支持

针对业务系统功能的逐步丰富，业务服务需要引入更多的系统展示和筛选，对这种情况现有的系统架构，系统功能的扩展性较差，如果筛选条件增加，那么对于的系统及网络代价的增长速度也难以预测。

在实现本发明实施例的过程中，发明人发现现有方法的数据检索查询次数多，中间临时结果集数据量大，系统资源占用多，接口响应慢，且系统扩展不便。

技术实现要素：

由于现有方法存在上述问题，本发明实施例提出一种跨系统多维度数据检索处理方法及装置。

第一方面，本发明实施例提出一种跨系统多维度数据检索处理方法，包括：

获取各系统的数据库中的若干类数据；

根据预设维度对所述若干类数据进行整理，得到所述预设维度的汇总数据；

根据预设筛选参数对所述汇总数据进行检索，得到目标检索数据。

可选地，所述根据预设筛选参数对所述汇总数据进行检索，得到目标检索数据，具体包括：

根据企业级搜索应用服务器solr的语法规则对预设筛选参数进行预处理，通过所述solr的应用程序接口api调用预处理后的预设筛选参数，对所述汇总数据进行检索，得到目标检索数据。

可选地，所述方法还包括：

根据预设周期，对所述api进行增量校验或全量数据匹配。

可选地，所述方法还包括：

根据数据流、变化频率和数据场景，对所述汇总数据进行更新。

可选地，所述方法还包括：

将所述汇总数据和/或所述目标检索数据存储在本地。

可选地，所述预设筛选参数包括业主完备、房屋委托、房屋现状、成交时间、成交公司、是否屏蔽和租赁到期。

第二方面，本发明实施例还提出一种跨系统多维度数据检索处理装置，包括：

数据获取模块，用于获取各系统的数据库中的若干类数据；

数据整理模块，用于根据预设维度对所述若干类数据进行整理，得到所述预设维度的汇总数据；

数据检索模块，用于根据预设筛选参数对所述汇总数据进行检索，得到目标检索数据。

可选地，所述数据检索模块具体用于根据企业级搜索应用服务器solr的语法规则对预设筛选参数进行预处理，通过所述solr的应用程序接口api调用预处理后的预设筛选参数，对所述汇总数据进行检索，得到目标检索数据。

第三方面，本发明实施例还提出一种电子设备，包括：

至少一个处理器；以及

与所述处理器通信连接的至少一个存储器，其中：

所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行上述方法。

第四方面，本发明实施例还提出一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机程序，所述计算机程序使所述计算机执行上述方法。

由上述技术方案可知，本发明实施例通过对个系统数据库中的若干类数据进行整理，得到预设维度的汇总数据，并直接对汇总数据进行检索，减少了数据检索查询的次数，避免了过多的中间临时结果，系统资源占用少，接口响应快，且利于系统的扩展。

附图说明

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

图1为本发明一实施例提供的一种跨系统多维度数据检索处理方法的流程示意图；

图2为本发明另一实施例提供的一种跨系统多维度数据检索处理方法的流程示意图；

图3为本发明一实施例提供的跨系统多维度数据检索处理的交互示意图；

图4为本发明一实施例提供的一种跨系统多维度数据检索处理装置的结构示意图；

图5为本发明一实施例提供的电子设备的逻辑框图。

具体实施方式

下面结合附图，对本发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

图1示出了本实施例提供的一种跨系统多维度数据检索处理方法的流程示意图，包括：

s101、获取各系统的数据库中的若干类数据。

其中，所述各系统为需要与业主服务系统进行交互的系统，例如包括房屋当前及历史委托情况的f系统、包括房屋网签历史的s系统、包括房屋租赁数据和业主防打扰屏蔽的r系统。

所述若干类数据包括房屋当前及历史委托情况、房屋网签历史、房屋租赁数据和业主防打扰屏蔽等维度的数据。

s102、根据预设维度对所述若干类数据进行整理，得到所述预设维度的汇总数据。

其中，所述预设维度为预先设置的维度，例如以房屋为维度，进行数据整理，将不同数据按照房屋进行统计整理。

所述汇总数据为包含了各类存储在不同数据库中的数据的汇总。

s103、根据预设筛选参数对所述汇总数据进行检索，得到目标检索数据。

其中，所述预设筛选参数包括业主完备、房屋委托、房屋现状、成交时间、成交公司、是否屏蔽和租赁到期。

具体地，常规的标签筛选过程中，集合s为中间结果集，具体步骤如下：

a1、查询经纪人自身的负责房屋集合列表，赋值为s；是否有标签筛选条件？没有标签筛选项，执行步骤a3；有则执行步骤a2；

a2、针对列表所需所有标签集合中的每个标签，查询房屋集合下所有符合该标签的数据t；此时最终结果集为t与s的交集；若s为空，则执行步骤a3，否则继续执行步骤a2；

a3、聚合了所有条件筛选结果的s，若s为空直接返回；否则获取对应的分页数据，切割后返回slit(s)。

简单来说，上述标签筛选的过程中，一旦发现筛选条件中有空集，则立即结束，无筛选结果。

上述标签筛选过程采用的条件筛选方案的弊端是，不论最终结果集s是多少，针对n个筛选标签，在集合s不为空的前提下，系统要做n次数据查询和取交集的过程，最后进行数据的分页返回给前端。已系统初期以房源委托(f系统)、业主完备(业主服务系统)两个筛选标签为例，系统优化后处理流程如图2所示，以系统存在业主、委托两个标签(n＝2)来说明：

b1、查询经纪人分配的全部房屋数据s；s为空转b4。

b2、查询业主标签，即s中房屋关联的所有业主数据t，此时的t赋值给s；s为空转b4。

b3、查询委托标签，根据s中房屋查询委托数据t’,此时将t’赋值给s；s为空转b4。

b4、处理结果集s，空或者是对分页数据切割，处理结束。

针对业务服务系统的需求，经纪人对业主数据的管理是以房屋为维度，也就是针对系统间的房屋委托、房屋现状、成交历史、业主管理都会最终聚合到房屋上。在此前提下，通过消除数据分散在不同系统间管理和存储的现象，将各维度的数据聚合到同一条房屋记录上，这样，针对每个房屋维度的数据，我们可以通过一次查询直接过滤所有的筛选条件，将符合结果的数据获取，然后转化成最后的结果集返回给经纪人。

而针对系统数据被打平后的数据，可以采用mysql或者nosql进行存储，但是需要该存储具有动态的扩展性方便后续筛选条件的新增，同时具有高效的检索性能，将目光投放到公司现有的检索系统。采用检索系统的理由是，该检索系统由专门的团队来进行维护，且系统有良好的监控体系，使用成品而不是自行开发可以让业务人员有更多的精力投入在业务需求中。

本实施例提供的业主服务系统可以轻松应对以后更多类似系统数据的接入和检索需求，在减少工作量和系统扩展性都有很大进步提升；数据更新和查询分离开来，使得查询的逻辑非常的简洁，数据查询速度大大提高，系统的查询处理压力也明显减少，用户的使用体验得到了优化，目前针对数据的查询，接口响应时间缩短80％。

本实施例通过对个系统数据库中的若干类数据进行整理，得到预设维度的汇总数据，并直接对汇总数据进行检索，减少了数据检索查询的次数，避免了过多的中间临时结果，系统资源占用少，接口响应快，且利于系统的扩展。

进一步地，在上述方法实施例的基础上，s103具体包括：

根据企业级搜索应用服务器solr的语法规则对预设筛选参数进行预处理，通过所述solr的应用程序接口api调用预处理后的预设筛选参数，对所述汇总数据进行检索，得到目标检索数据。

通过对预设筛选参数进行预处理，能够得到整理后的筛选参数，便于后续的检索；同时通过api调用预处理后的预设筛选参数，对所述汇总数据进行检索，能够迅速返回所有的结果数据，后端程序只需要做一层数据展示的封装工作，就可以将结果返回给前端展示。

进一步地，在上述方法实施例的基础上，所述方法还包括：

s104、根据预设周期，对所述api进行增量校验或全量数据匹配。

具体地，由于多个系统间的数据交互，难免会出现接口调用超时而导致的增量内容丢失情况，除了在接口调用的异常超时重试情况外，需要有定期增量校验或者全量数据匹配的过程。

业主服务系统中管理的房屋数据量仅次于楼盘字典系统，有几千万的数据，该过程的时长要长达十几个小时之，每日进行数据全量匹配也不太现实久。需要一些定期校验策略来解决增量可能存在的丢失问题：一是通过楼栋数据量房屋检验补充房屋的增量；二是通过局部数据轮询更新的方式，每日更新局部的数据，可以将不同区域间的数据进行更新。

进一步地，在上述方法实施例的基础上，所述方法还包括：

s105、根据数据流、变化频率和数据场景，对所述汇总数据进行更新。

具体地，针对数据条件的筛选都直接在已经被打平的数据存储中进行，避免了之前提到的数据筛选无法直接分页、系统间数据传输量大的问题，针对数据的存取按需查询，只返回特定的查询结果分页，对系统检索的处理逻辑和资源占用都有了很大的优化。检索设计的思想是已空间代价换取时间优化，同时将系统间数据的变化平滑分布在数据的实时更新后，数据的查询与数据的更新是隔离的，系统对于功能的扩展支持更加灵活和明确。

业主服务系统检索设计模块分为两大部分，一是检索维护，二是检索查询。将两者隔离开来，减少模块间的逻辑耦合，升级也可以独立进行。

如图3所示，是目前检索数据更新模块的系统交互图，不同的箭头类型代表了两个模块(search模块和solr-api模块)的数据交互。search模块主要用于构建数据，solr-api模块主要用于提供接口。

其中加灰的r、u系统直接与业主服务系统交互，数据间接存放检索；无底色的s、f系统则是通过数据库binlog的方式来触发检索增量，最后获取变化数据；search模块和solr模块是本实施例提供的跨系统多维度数据检索处理方法的核心模块，search主要用于数据库内容的监听及数据内存的获取，最后将数据存放进solr，构建索引，最终实现数据的快速查询。

检索维护部分主要内容在于将各个系统间的数据由业主服务系统进行数据处理整合，最终存放到检索构成索引。

针对图3所示系统f、s、r、u的数据，结合业务场景和数据更新特性，有本地数据落地和本地数据不落地两种存储方式。

例如针对系统f、s数据，通过检索search监听对应数据库字段的insert、update事件来主动调用业主接口获取增量内容，然后写入检索solr创建索引。而针对系统r、u数据，由于后续有经纪人进行编辑更新的动作，业主服务系统在本地数据库进行存储，系统间通过消息通信的方式感知数据变动，主动拉取更新同步本地，最后由search监听本地数据字段的对应事件，获取此时的增量内容，更新solr索引数据。

检索查询部分类似筛选数据过程，但是经过接入检索系统后的数据查询步骤大大简化，针对用户的筛选参数进行预处理，根据solr的语法规则整合好查询条件，直接通过solr的api进行调用，会迅速返回所有的结果数据，后端程序只需要做一层数据展示的封装工作，就可以将结果返回给前端展示。

针对不同数据类型的增量监听机制，是在综合考虑数据量、变化频率、数据场景的基础上来决定的。

具体地，针对数据增量的更新，检索中一次更新内容只有局部，而不需要对所有的系统数据都进行，这时，充分利用了检索数据的列存储特性，根据每次增量的模块内容，增量查询特定模块的数据，并返回局部更新内容，这样既减少了网络带宽资源，同时大大减少了对其他依赖系统的调用压力。

本实施例提供的方法突破了原有架构对多维度数据查询的局限性，极大提高了跨系统检索效率；通过集中式存储数据索引，能够解决多维度查询情况下，跨系统调用的问题，提高查询效率；通过数据库binlog的方式触发索引更新，业务方提供索引接口；通过数据库binlog触发索引更新，能够做到索引触发及时，延迟小的问题；索引数据由业务方提供，避免了检索团队对业务数据的了解，增加了业务灵活性。

进一步地，在上述方法实施例的基础上，所述方法还包括：

s106、将所述汇总数据和/或所述目标检索数据存储在本地。

具体地，业主服务系统在本地数据库进行存储，系统间通过消息通信的方式感知数据变动，主动拉取更新同步本地。

通过将汇总数据和/或目标检索数据存储在本地，减少了数据检索查询的次数，避免了过多的中间临时结果，系统资源占用少，接口响应快。

图4示出了本实施例提供的一种跨系统多维度数据检索处理装置的结构示意图，所述装置包括：数据获取模块401、数据整理模块402和数据检索模块403，其中：

所述数据获取模块401，用于获取各系统的数据库中的若干类数据；

所述数据整理模块402，用于根据预设维度对所述若干类数据进行整理，得到所述预设维度的汇总数据；

所述数据检索模块403，用于根据预设筛选参数对所述汇总数据进行检索，得到目标检索数据。

具体地，所述数据获取模块401获取各系统的数据库中的若干类数据；所述数据整理模块402根据预设维度对所述若干类数据进行整理，得到所述预设维度的汇总数据；所述数据检索模块403根据预设筛选参数对所述汇总数据进行检索，得到目标检索数据。

本实施例通过对个系统数据库中的若干类数据进行整理，得到预设维度的汇总数据，并直接对汇总数据进行检索，减少了数据检索查询的次数，避免了过多的中间临时结果，系统资源占用少，接口响应快，且利于系统的扩展。

进一步地，在上述装置实施例的基础上，所述数据检索模块403具体用于根据企业级搜索应用服务器solr的语法规则对预设筛选参数进行预处理，通过所述solr的应用程序接口api调用预处理后的预设筛选参数，对所述汇总数据进行检索，得到目标检索数据。

进一步地，在上述装置实施例的基础上，所述装置还包括：

根据预设周期，对所述api进行增量校验或全量数据匹配。

进一步地，在上述装置实施例的基础上，所述装置还包括：

根据数据流、变化频率和数据场景，对所述汇总数据进行更新。

进一步地，在上述装置实施例的基础上，所述装置还包括：

将所述汇总数据和/或所述目标检索数据存储在本地。

进一步地，在上述装置实施例的基础上，所述预设筛选参数包括业主完备、房屋委托、房屋现状、成交时间、成交公司、是否屏蔽和租赁到期。

本实施例所述的跨系统多维度数据检索处理装置可以用于执行上述方法实施例，其原理和技术效果类似，此处不再赘述。

参照图5，所述电子设备，包括：处理器(processor)501、存储器(memory)502和总线503；

其中，

所述处理器501和存储器502通过所述总线503完成相互间的通信；

所述处理器501用于调用所述存储器502中的程序指令，以执行上述各方法实施例所提供的方法。

本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法。

本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

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