CN110704422A - 数据查询方法、装置、系统、计算机设备及存储介质 - Google Patents

Abstract

本发明涉及数据查询方法、装置、系统、计算机设备及存储介质，属于互联网技术领域。该方法包括：接收业务端发送的数据查询请求；数据查询请求通过预先设定的接口接收；根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；候选数据由应用端的事件数据批量整合得到；将所查询的目标数据返回给业务端。上述技术方案，解决了业务端和应用端有较大的负荷，影响业务端和应用端的正常运行，使得数据的查询效率低下的问题。不需要业务端和应用端一一交互，能有效减少业务端和应用端的负载，提高业务端查询应用端数据的效率。

Description

数据查询方法、装置、系统、计算机设备及存储介质

技术领域

本发明涉及互联网技术领域，特别是涉及数据查询方法、装置、系统、计算机设备及存储介质。

背景技术

随着互联网系统的高速发展，业务端往往需要向应用端查询大量的数据，以便进行业务处理。而根据业务需要，应用端的种类和数量往往较多。在传统的解决方案中，业务端需要去调度各个应用端以查询原始数据或者加工后的数据。

在实现本发明过程中，发明人发现传统方式中至少存在如下问题：业务端需要与各个应用端分别进行交互才能查询到对应的数据，而各个应用端可能需要针对业务端的需求做额外的数据存储和数据加工，且大量的历史数据会在应用端中积压。这种情况下，业务端和应用端都会有较大的负荷，这些负荷会影响业务端和应用端的正常运行，使得数据的查询效率低下。

发明内容

基于此，本发明实施例提供了数据查询方法、装置、系统、计算机设备及存储介质，在数据查询过程中能有效降低业务端和应用端的负载，提高数据查询的效率。

本发明实施例的内容如下：

第一方面，本发明实施例提供一种数据查询方法，包括以下步骤：接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；所述候选数据由所述应用端的事件数据批量整合得到；将所查询的目标数据返回给所述业务端。

在一个实施例中，所述数据库包括hbase数据库；所述根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤之前，还包括：接收客户端发送的hfile文件；所述hfile文件由客户端中的hive工具对应用端的事件数据批量整合得到，并由所述客户端的bulkload工具跑批上传；将所述hfile文件作为候选数据存入所述hbase数据库中。

在一个实施例中，所述客户端包括第一子客户端和第二子客户端；所述根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤之前，还包括：接收第一子客户端发送的离线数据；所述离线数据中所包含的数据内容根据第一配置页面中输入的配置信息确定；接收第二子客户端发送的实时数据；所述实时数据中所包含的数据内容根据第二配置页面中输入的配置信息确定；根据所述离线数据和/或所述实时数据得到所述候选数据；将所得到的候选数据存入所述数据库中。

在一个实施例中，所述第一子客户端包括CRM系统；所述接收第一子客户端发送的离线数据的步骤，包括：接收所述CRM系统发送的离线数据。

在一个实施例中，所述接收业务端发送的数据查询请求的步骤，包括：接收业务端通过预先设定的dubbo接口发送的数据查询请求；其中，所述dubbo接口根据各个应用端的标签字段设定；所述标签字段根据字段配置界面输入的字段配置信息确定。

在一个实施例中，所述根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤，包括：确定与所述dubbo接口对应的目标标签字段；从所述数据库中确定与所述目标标签字段对应的候选数据，作为所述目标数据。

第二方面，本发明实施例提供一种数据查询装置，包括：请求接收模块，用于接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；数据查询模块，用于根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；所述候选数据由所述应用端的事件数据批量整合得到；数据返回模块，用于将所查询的目标数据返回给所述业务端。

第三方面，本发明实施例提供一种数据查询系统，包括：离线数据处理单元、实时数据处理单元、数据查询单元以及数据库；所述离线数据处理单元、所述实时数据处理单元以及所述数据查询单元分别与所述数据库网络连接；所述离线数据处理单元，用于接收第一子客户端发送的离线数据，将所述离线数据作为候选数据存入所述数据库中；所述实时数据处理单元，用于接收第二子客户端发送的实时数据，将所述实时数据作为候选数据存入所述数据库中；所述数据查询单元，用于接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；根据所述数据查询请求，从所述数据库的候选数据中查询对应应用端的目标数据；将所查询的目标数据返回给所述业务端。

第四方面，本发明实施例提供一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；所述候选数据由所述应用端的事件数据批量整合得到；将所查询的目标数据返回给所述业务端。

第五方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；所述候选数据由所述应用端的事件数据批量整合得到；将所查询的目标数据返回给所述业务端。

上述技术方案中的一个技术方案具有如下优点或有益效果：接收业务端通过设定接口发送的数据查询请求，根据该数据查询请求从候选数据中查询目标数据，并将该目标数据返回给业务端。不需要业务端和应用端一一交互，能有效减少业务端和应用端的负载，提高业务端查询应用端数据的效率。

附图说明

图1为一个实施例中数据查询方法的应用环境图；

图2为一个实施例中数据查询方法的流程示意图；

图3为一个实施例中数据上传的流程示意图；

图4为另一个实施例中数据上传的流程示意图；

图5为一个实施例中hbase数据导入配置页面的界面示意图；

图6为一个实施例中准实时数据入库配置页面的界面示意图；

图7为一个实施例中字段源配置页面的界面示意图；

图8为另一个实施例中数据查询方法的流程示意图；

图9为一个实施例中数据查询装置的结构框图；

图10为一个实施例中数据查询系统的结构框图；

图11为一个实施例中计算机设备的内部结构。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本申请提供的数据查询方法可以应用于如图1所示的应用环境中。该应用环境包括网络连接的业务端101、服务器102和应用端103。业务端101向服务器102发送数据查询请求，服务器102据此获取对应的应用端103上传的目标数据并返回给业务端101。业务端101和应用端103可以是终端设备也可以是服务器，其中，终端设备可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。服务器102也可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

本发明实施例提供一种数据查询方法、装置、系统、计算机设备及存储介质。以下分别进行详细说明。

在一个实施例中，如图2所示，提供了一种数据查询方法，以该方法应用于图1中的服务器102端为例进行说明，包括以下步骤：

S201、接收业务端发送的数据查询请求；数据查询请求通过预先设定的接口接收；该预先设定的接口与应用端对应。

其中，业务端指的是能根据应用端发送的数据完成特定业务功能的设备，例如：数据分析设备、数据统计设备、风险控制设备、消息推送设备等。而应用端可以指某些应用(例如：购物APP)或者安装有应用的终端设备(此时也可以称为应用终端)，也可以指某些功能系统或者运行有功能系统的设备，这个功能系统可以为CRM(客户关系管理，能实时获取客户在使用特定应用时产生的数据)系统，应用端在运营应用的过程中会获取产生的各种事件数据，而应用端可以将这些事件数据发送到服务器中进行集中管理，以便业务端从服务器中获取各个应用端对应的数据。进一步地，业务端和应用端的数量可以为一个、两个、甚至多个。更进一步地，业务端和应用端可以有对应的标识，以使服务器能够对它们进行区分，这些标识可以存储在服务器对应的数据库中。

其中，预先设定的接口可以按照设定规则生成的接口，这个设定规则可以包含有数据查询请求与候选数据的对应关系，因此，服务器在接收到数据查询请求时，根据其所使用的接口就能确定对应的候选数据，进而得到目标数据(业务端所需查询的数据)。进一步地，不同的接口可以对应不同的查询字段(这个查询字段可以由用户选择，也可以是根据一定的算法确定)，服务器在接收到数据查询请求时，根据其对应的查询字段就能查询到对应的候选数据，进而得到目标数据。更进一步地，不同的应用端可以对应有不同的查询字段，换句话说，不同的接口对应不同的应用端，服务器在接收到通过A接口发送的数据查询请求时，就能获知业务端是要查询对应的a应用端的数据，因此可以将a应用端上传的候选数据确定为目标数据。

本步骤中，业务端在需要处理特定业务时，通过预先设定的接口向服务器发送数据查询请求，启动服务器的数据查询操作，以使服务器从数据库中查询对应的目标数据。

S202、根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；候选数据由所述应用端的事件数据批量整合得到。

其中，候选数据可以包括自然人级别(具体到个人)和用户级别(具体到注册用户)的数据。

在本步骤中，客户端(将应用端的事件数据上传给服务器的应用或者终端设备)将批量整合得到的候选数据发送给服务器；服务器将候选数据存入数据库中，在接收到数据查询请求时，根据接收数据查询请求的接口从数据库的候选数据库中查询对应的目标数据。

客户端可以实时获取应用端的事件数据，将事件数据中的小文件整合为大文件，并上传给服务器。进一步地，客户端可以定期将大文件上传给服务器，也可以在大文件的文件大小满足设定要求(例如：200-400M)时上传给服务器。当然，在一些实施例中，客户端也可以实时地将获取的事件数据直接发送给服务器，而不经过文件整合的过程。

进一步地，根据客户端上传事件数据的时间，候选数据既可以是实时数据(获取到事件数据之后立刻上传给服务器)，也可以是离线数据(将设定时间段内的历史事实数据上传给服务器)，这种情况下，业务端可以分别对离线数据和实时数据进行查询。更进一步地，候选数据还可以是对实时数据和离线数据整合后得到的数据。实时数据和离线数据的具体说明可以参见后续实施例的详细说明。

S203、将所查询的目标数据返回给业务端。

在本步骤中，服务器将所查询到的目标数据返回给业务端，以使业务端根据业务需求对目标数据进行处理。

在一个实施例中，S203之后，业务端拿到目标数据以后，可以进行一些自己的业务逻辑，比如进行消息推送或者风险控制。例如，业务端在从服务器中获取到某购物APP中的用户注册信息后，根据用户注册信息确定其中的老用户，进而向这些老用户推送消息。

本实施例提供的数据查询方法，服务器作为业务端和应用端的中间平台，能存储应用端上传的候选数据，并向业务端返回其所需的目标数据，不需要业务端和应用端直接进行交互，能有效减少业务端和应用端的负载，提高业务端查询应用端数据的效率。

在一个实施例中，数据库包括hbase数据库；服务器102上运行有CDP系统，该CDP系统在运行过程中实现本发明实施例中的数据查询方法。其中，CDP对于一个字段有两个存储值，一个离线，一个是实时。

其中，离线指的是每天通过定时任务把数据集市中前一天的数据同步到hbase数据库上，因为是存储前一天的数据，所以这些数据可以称为是离线数据，离线数据的保存周期可以是永久(也可以是一个月、一年等较长的时间)。

实时指的是各个业务系统在一些处理关键业务后把一些信息通过消息队列传给CDP系统，举个例子A系统注册用户以后会将注册事件的消息传给CDP系统，CDP系统通过解析消息拿到需要的数据(注册时间等)，然后存入hbase数据库的实时列族中，实时数据的存储周期可以是两天(也可以是其他时间)。另外，对于实时数据，为降低系统的运行效率，可以隔一小段时间(例如：5min、10min等)再将数据上传到hbase数据库，这样的数据可以称为是准实时数据。

上述实施例通过实时和离线的方式来传输和存储应用端的数据，既能保证重要数据及时地被业务端访问到，也能缓解应用端和服务器的运行压力，提高系统的整体运行效率。

在一个实施例中，在业务端查询目标数据之前，客户端需要将对应的事件数据上传至数据库中。即，根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤之前，还包括：接收客户端发送的hfile文件(hbase架构中最小的结构，hbase的数据都在hfile中)；hfile文件由客户端中的hive工具对应用端的事件数据批量整合得到，并由客户端的bulkload工具跑批上传；将hfile文件作为候选数据存入hbase数据库中。

在一些实施例中，为了更好地对系统功能进行划分，可以将对数据进行集中管理的平台(包括：CDP系统)称为云上系统，而其他的平台(包括：业务端、客户端、应用端)称为云下系统。当然，具体划分方式也可以不一样。

进一步地，以从CRM上传数据到数据库中为例，如图3所示，传统的同步是由CRM生成.DAT后缀的数据文件(每一行都需要同步标签属性值)，并持续实时地将这些事件数据上传至云上的DXP文件管理系统，然后与DXP文件管理系统连接的CDP批处理系统通过触发离线同步任务去读取.DAT文件，逐行地把事件数据通过接口更新到云上hbase数据库中，而.DAT文件中的每一行都是一个小hfile文件，因此，这样做的缺点在于会持续有小文件写入hbase数据库中，造成集群压力。

针对于传统的云下hive同步云上hbase的方案，本发明实施例做了优化处理。如图4所示，采用的优化方案是先通过云下hive工具把事件数据生成hfile文件块，然后借助调度系统distcp将hfile文件块拷贝到云上的HDFS(Hadoop分布式文件系统，可以理解为事件数据发送至hbase数据库之前的临时存放系统)中。在hfile文件块满足一定条件时，Hadoop客户端执行bulkload命令以将hfile文件块批量导入至hbase数据库中，这种在云下hive层面生成较大的hfile文件再上传至hbase数据库的方案，避免了传输大批量小文件导致的低效问题和集群压力。

在一个实施例中，客户端包括第一子客户端和第二子客户端；根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤之前，还包括：接收第一子客户端发送的离线数据；离线数据中所包含的数据内容根据第一配置页面中输入的配置信息确定；接收第二子客户端发送的实时数据；实时数据中所包含的数据内容根据第二配置页面中输入的配置信息确定；根据离线数据和/或实时数据得到候选数据；将所得到的候选数据存入数据库中。

依据实现的功能，第一子客户端也可以称为是离线数据处理客户端，第二子客户端也可以称为是实时数据处理客户端。第一子客户端和第二子客户端可以通过同一个客户端实现也可以通过不同的客户端实现。另外，第一子客户端和第二子客户端可以分别连接各个应用端，以从这些应用端中获取对应的事件数据。

另一方面，第一子客户端和第二子客户端可以直接由应用端来实现，即应用端自己将事件数据发送给服务器。

第一配置页面可以如图5所示，用户可以通过图5所示的hbase数据导入配置页面选择所需的数据api名称、执行sql、hbase表、列族、字段、导数方式(支持全量和增量)，服务器根据这些配置信息从第一子客户端发送的离线数据中选择对应字段的数据，并将所选择的数据存储至hbase数据库中。同时，业务端能从hbase数据库中获取到对应字段的数据。

第二配置页面可以如图6所示，用户可以通过图6所示的hbase数据导入配置页面选择所需的消费事件码、表达式等，服务器根据这些配置信息从第二子客户端发送的实时数据中选择对应的数据内容，并将所选择的数据存储至hbase数据库中。其中，消费事件码可以指第二子客户端发过来的注册事件的名称比如“register_event”，服务器对消费事件码进行配置就能够与第二子客户端进行通信了；表达式指的是服务器对某些字段进行的简单处理，比如发过来的消息可能成功可能失败，配一个表达式“result＝success”，表示这个消息里面的result字段只有为suceess的时候才会处理，才会更新到hbase数据库中。进一步地，以图6所示的内容为例，在接收到客户端发送的数据时，服务器从中选择消费事件码、用户号、手机号、客户号、身份证等符合第二配置页面要求的信息，作为候选数据存入hbase数据库中。

另外，第一配置页面和第二配置页面也可以设置在客户端上，用户根据需要在客户端上进行设置，以向服务器发送特定的事件数据。第一配置页面和第二配置页面还可以设置在应用端上。

在一些实施例中，第一配置页面和第二配置页面的内容可以替换，也可以重新整合。换句话说，实时数据和离线数据中所包含的事件数据可以相同，也可以不同。更进一步地，用户可以随时通过第一配置页面和第二配置页面对hbase数据库中所存储数据的类型进行更新。

在一个实施例中，第一子客户端包括CRM系统；接收第一子客户端发送的离线数据的步骤，包括：接收CRM系统发送的离线数据。

上述实施例提供的数据查询方法，通过配置页面的设置来进行候选数据的存储，能针对性地进行数据的存储，使得整个系统更能满足用户的需求。同时，可以根据业务方的需求动态地更新需要的业务字段数据，可拓展性强。

在一个实施例中，服务器通过dubbo接口给业务端提供实时的查询服务。即S201包括：接收业务端通过预先设定的dubbo接口发送的数据查询请求；其中，dubbo接口根据各个应用端的标签字段设定；标签字段根据字段配置界面输入的字段配置信息确定。

进一步地，根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤，包括：确定与dubbo接口对应的目标标签字段；从数据库中确定与目标标签字段对应的候选数据，作为目标数据。

其中，服务器根据数据查询请求获取的数据，可以是对数据进行覆盖、保留首次、累加、累减后得到的数据。即，服务器可以对事件数据进行覆盖、保留首次、累加、累减等处理，得到候选数据，并将候选数据存储至数据库中。

更进一步地，字段配置界面可以如图7所示。服务器根据业务端发送数据查询请求的dubbo接口确定对应的“数据api”，并通过“数据api”这个字段来查询目标数据。一般来说每个应用端都会配置各自的数据api，通过图7可以看到不同的数据api都配置了不同的标签字段，服务器根据“数据api”查询业务端订阅的标签字段，然后将对应的目标数据发送给业务端，业务端从目标数据中解析出想要的数据。这样的好处是业务端不需要配置具体的标签，而应用端的数据查询还是受到服务器统一配置管控的，能有效简化业务端和应用端的运行压力。

为了更好地理解上述方法，如图8所示，以下以CDP系统为例，详细阐述一个本发明数据查询方法的应用实例。CDP系统包括离线数据处理模块、实时数据处理模块、数据查询模块以及hbase数据库，它们的连接关系可以如图8所示。其中，数据查询模块与外部业务系统(即前述实施例中的业务端)网络连接，用于接收外部业务系统发送的数据查询请求；实时数据处理模块与应用终端网络连接，用于接收应用终端发送的事件数据；离线数据处理模块与CRM系统网络连接，用于接收CRM系统发送的离线数据。具体业务交互如下：

1、CRM系统每天从APP数据集市中获取事件数据，并生成事件数据视图快照表，每日对数据进行清洗，从中抽取数据，以得到T-1客户离线数据。CRM系统将T-1离线数据通过hive工具压缩成hfile文件并通过bulkload跑批上传至离线数据处理模块，并通过离线数据处理模块批量更新到hbase数据库中。

2、实时数据处理模块实时接收应用终端通过hive工具对事件数据压缩成hfile文件并通过bulkload跑批上传的数据，并将所获取的数据实时插入hbase数据库中，保证准实时数据的准确性。

3、数据查询模块通过dubbo接口给外部业务系统提供实时的查询服务。具体的，数据查询模块接收外部业务系统通过dubbo接口发送的数据查询请求，根据dubbo接口确定对应的目标标签字段；从hbase数据库中确定与该目标标签字段对应的候选数据，并将该候选数据作为目标数据发送给外部业务系统，以使外部业务系统根据目标数据完成对应的业务。

在传统的外部业务系统查询应用端数据的方法中，外部业务系统按需去各个应用端查询数据，这样做的缺点有很多，比如：1、需要调用大量的应用端，这样系统耦合很强并且很不方便；2、外部业务系统需要在应用端上运行大量的查询进程，会带给应用端较大的业务负载，影响应用端正常的功能；3、很多历史数据(首次注册时间、申请贷款次数等客户历史行为标签)在应用端中是不会保存或者不会完整保存的，如果需要这些字段就没有一个查询的接口可以实现对应数据的查询需求；4、很多客户历史数据是需要进行一些加工的，比如申请贷款次数就需要进行累加处理，很多应用端也不适合做这种额外的处理。

本实施例提供的数据查询方法，具有以下技术效果：1、CDP系统提供了一个统一的查询接口，可以根据专门的配置页面去配置查询的标签字段，不需要业务端和应用端一一交互，免去跟多个应用端的耦合，能有效减少业务端和应用端的负载，提高业务端查询应用端数据的效率。2、CDP系统的客户标签数据存储在hbase数据库中，这种no-sql数据库较之于业务系统的关系型数据库查询存储速度更快，并且CDP系统是一个独立系统，可以减小各个应用端的压力。3、CDP系统每天从CRM数据集市中同步前一天清洗的离线数据，并且接入消息队列进行准实时的数据加工和更新，清洗出满足需求的数据。4、采用hive压缩成hfile文件，通过bulkload跑批上传至hbase数据库的方式，相对而言更加稳定和高效。

需要说明的是，对于前述的各方法实施例，为了简便描述，将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。

基于与上述实施例中的数据查询方法相同的思想，本发明还提供数据查询装置，该装置可用于执行上述数据查询方法。为了便于说明，数据查询装置实施例的结构示意图中，仅仅示出了与本发明实施例相关的部分，本领域技术人员可以理解，图示结构并不构成对装置的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图9所示，数据查询装置包括请求接收模块901、数据查询模块902和数据返回模块903，详细说明如下：

请求接收模块901，用于接收业务端发送的数据查询请求；数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应。

数据查询模块902，用于根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；候选数据由所述应用端的事件数据批量整合得到。

数据返回模块903，用于将所查询的目标数据返回给业务端。

本实施例提供的数据查询装置，服务器作为业务端和应用端的中间平台，能存储应用端上传的候选数据，并向业务端返回其所需的目标数据，不需要业务端和应用端一一交互，能有效减少业务端和应用端的负载，提高业务端查询应用端数据的效率。

在一个实施例中，数据库包括hbase数据库；还包括：文件接收模块，用于接收客户端发送的hfile文件；hfile文件由客户端中的hive工具对应用端的事件数据批量整合得到，并由客户端的bulkload工具跑批上传；文件上传模块，用于将hfile文件作为候选数据存入hbase数据库中。

在一个实施例中，该客户端包括第一子客户端和第二子客户端；还包括：第一数据接收模块，用于接收第一子客户端发送的离线数据；离线数据中所包含的数据内容根据第一配置页面中输入的配置信息确定；第二数据接收模块，用于接收第二子客户端发送的实时数据；实时数据中所包含的数据内容根据第二配置页面中输入的配置信息确定；候选数据确定模块，用于根据离线数据和/或实时数据得到候选数据；数据存储模块，用于将所得到的候选数据存入数据库中。

在一个实施例中，第一子客户端包括CRM系统；第一数据接收模块，还用于接收CRM系统发送的离线数据。

在一个实施例中，请求接收模块901，还用于接收业务端通过预先设定的dubbo接口发送的数据查询请求；其中，dubbo接口根据各个应用端的标签字段设定；标签字段根据字段配置界面输入的字段配置信息确定。

在一个实施例中，数据查询模块902，包括：字段确定子模块，用于确定与dubbo接口对应的目标标签字段；候选数据确定子模块，用于从数据库中确定与目标标签字段对应的候选数据，作为目标数据。

需要说明的是，本发明的数据查询装置与本发明的数据查询方法一一对应，在上述数据查询方法的实施例阐述的技术特征及其有益效果均适用于数据查询装置的实施例中，具体内容可参见本发明方法实施例中的叙述，此处不再赘述，特此声明。

在一个实施例中，如图10所示，提供一种数据查询系统，包括：离线数据处理单元1001、实时数据处理单元1002、数据查询单元1003以及数据库1004；离线数据处理单元、实时数据处理单元以及数据查询单元分别与数据库网络连接；离线数据处理单元，用于接收第一子客户端发送的离线数据，将离线数据作为候选数据存入数据库中；实时数据处理单元，用于接收第二子客户端发送的实时数据，将实时数据作为候选数据存入数据库中；数据查询单元，用于接收业务端发送的数据查询请求；数据查询请求通过预先设定的接口接收；该预先设定的接口与应用端对应；根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；将所查询的目标数据返回给业务端。本实施例提供的数据查询系统，服务器作为业务端和应用端的中间平台，能存储应用端上传的候选数据，并向业务端返回其所需的目标数据，不需要业务端和应用端一一交互，能有效减少业务端和应用端的负载，提高业务端查询应用端数据的效率。

需要说明的是，本发明的数据查询系统与本发明的数据查询方法对应，在上述数据查询方法的实施例阐述的技术特征及其有益效果均适用于数据查询系统的实施例中，具体内容可参见本发明方法实施例中的叙述，此处不再赘述，特此声明。

此外，上述示例的数据查询装置、系统的实施方式中，各程序模块的逻辑划分仅是举例说明，实际应用中可以根据需要，例如出于相应硬件的配置要求或者软件的实现的便利考虑，将上述功能分配由不同的程序模块完成，即将数据查询装置、系统的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分功能。

本申请提供的数据查询方法可以应用于如图11所示的计算机设备中。该计算机设备可以是服务器，也可以是终端设备，其内部结构图可以如图11所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，处理器用于提供计算和控制能力；存储器包括非易失性存储介质、内存储器，该非易失性存储介质存储有操作系统、计算机程序(该计算机程序被处理器执行时实现一种数据查询方法)和数据库，该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境；数据库用于存储数据查询方法实现过程中产生的各种数据；网络接口用于与外部的终端通过网络连接通信，例如，与业务端连接用于接收业务端发送的数据查询请求，与客户端连接用于接收客户端发送的事件数据。

本领域技术人员可以理解，图11中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现以下步骤：接收业务端发送的数据查询请求；数据查询请求通过预先设定的接口接收；该预先设定的接口与应用端对应；根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；候选数据由所述应用端的事件数据批量整合得到；将所查询的目标数据返回给业务端。

在一个实施例中，数据库包括hbase数据库；处理器执行计算机程序时还实现以下步骤：接收客户端发送的hfile文件；hfile文件由客户端中的hive工具对应用端的事件数据批量整合得到，并由客户端的bulkload工具跑批上传；将hfile文件作为候选数据存入hbase数据库中。

在一个实施例中，该客户端包括第一子客户端和第二子客户端；处理器执行计算机程序时还实现以下步骤：接收第一子客户端发送的离线数据；离线数据中所包含的数据内容根据第一配置页面中输入的配置信息确定；接收第二子客户端发送的实时数据；实时数据中所包含的数据内容根据第二配置页面中输入的配置信息确定；根据离线数据和/或实时数据得到候选数据；将所得到的候选数据存入数据库中。

在一个实施例中，第一子客户端包括CRM系统；处理器执行计算机程序时还实现以下步骤：接收CRM系统发送的离线数据。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：接收业务端通过预先设定的dubbo接口发送的数据查询请求；其中，dubbo接口根据各个应用端的标签字段设定；标签字段根据字段配置界面输入的字段配置信息确定。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：确定与dubbo接口对应的目标标签字段；从数据库中确定与目标标签字段对应的候选数据，作为目标数据。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：接收业务端发送的数据查询请求；数据查询请求通过预先设定的接口接收；该预先设定的接口与应用端对应；根据数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；候选数据由所述应用端的事件数据批量整合得到；将所查询的目标数据返回给业务端。

在一个实施例中，数据库包括hbase数据库；计算机程序被处理器执行时还实现以下步骤：接收客户端发送的hfile文件；hfile文件由客户端中的hive工具对应用端的事件数据批量整合得到，并由客户端的bulkload工具跑批上传；将hfile文件作为候选数据存入hbase数据库中。

在一个实施例中，该客户端包括第一子客户端和第二子客户端；计算机程序被处理器执行时还实现以下步骤：接收第一子客户端发送的离线数据；离线数据中所包含的数据内容根据第一配置页面中输入的配置信息确定；接收第二子客户端发送的实时数据；实时数据中所包含的数据内容根据第二配置页面中输入的配置信息确定；根据离线数据和/或实时数据得到候选数据；将所得到的候选数据存入数据库中。

在一个实施例中，第一子客户端包括CRM系统；计算机程序被处理器执行时还实现以下步骤：接收CRM系统发送的离线数据。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：接收业务端通过预先设定的dubbo接口发送的数据查询请求；其中，dubbo接口根据各个应用端的标签字段设定；标签字段根据字段配置界面输入的字段配置信息确定。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：确定与dubbo接口对应的目标标签字段；从数据库中确定与目标标签字段对应的候选数据，作为目标数据。

本领域普通技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，作为独立的产品销售或使用。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

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

本发明实施例的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或(模块)单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，不能理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种数据查询方法，其特征在于，包括以下步骤：

接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；

根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；所述候选数据由所述应用端的事件数据批量整合得到；

将所查询的目标数据返回给所述业务端。

2.根据权利要求1所述的方法，其特征在于，所述数据库包括hbase数据库；

所述根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤之前，还包括：

接收客户端发送的hfile文件；所述hfile文件由客户端中的hive工具对应用端的事件数据批量整合得到，并由所述客户端的bulkload工具跑批上传；

将所述hfile文件作为候选数据存入所述hbase数据库中。

3.根据权利要求2所述的方法，其特征在于，所述客户端包括第一子客户端和第二子客户端；

所述根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤之前，还包括：

接收第一子客户端发送的离线数据；所述离线数据中所包含的数据内容根据第一配置页面中输入的配置信息确定；

接收第二子客户端发送的实时数据；所述实时数据中所包含的数据内容根据第二配置页面中输入的配置信息确定；

根据所述离线数据和/或所述实时数据得到所述候选数据；

将所得到的候选数据存入所述数据库中。

4.根据权利要求3所述的方法，其特征在于，所述第一子客户端包括CRM系统；

所述接收第一子客户端发送的离线数据的步骤，包括：

接收所述CRM系统发送的离线数据。

5.根据权利要求1所述的方法，其特征在于，所述接收业务端发送的数据查询请求的步骤，包括：

接收业务端通过预先设定的dubbo接口发送的数据查询请求；其中，所述dubbo接口根据各个应用端的标签字段设定；所述标签字段根据字段配置界面输入的字段配置信息确定。

6.根据权利要求5所述的方法，其特征在于，所述根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据的步骤，包括：

确定与所述dubbo接口对应的目标标签字段；

从所述数据库中确定与所述目标标签字段对应的候选数据，作为所述目标数据。

7.一种数据查询装置，其特征在于，包括：

请求接收模块，用于接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；

数据查询模块，用于根据所述数据查询请求，从数据库的候选数据中查询对应应用端的目标数据；所述候选数据由所述应用端的事件数据批量整合得到；

数据返回模块，用于将所查询的目标数据返回给所述业务端。

8.一种数据查询系统，其特征在于，包括：离线数据处理单元、实时数据处理单元、数据查询单元以及数据库；所述离线数据处理单元、所述实时数据处理单元以及所述数据查询单元分别与所述数据库网络连接；

所述离线数据处理单元，用于接收第一子客户端发送的离线数据，将所述离线数据作为候选数据存入所述数据库中；

所述实时数据处理单元，用于接收第二子客户端发送的实时数据，将所述实时数据作为候选数据存入所述数据库中；

所述数据查询单元，用于接收业务端发送的数据查询请求；所述数据查询请求通过预先设定的接口接收；所述预先设定的接口与应用端对应；根据所述数据查询请求，从所述数据库的候选数据中查询对应应用端的目标数据；将所查询的目标数据返回给所述业务端。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6任一项所述的方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6任一项所述的方法的步骤。

Images