CN106407480A - 一种信息查询方法和系统 - Google Patents

Abstract

本发明实施例提供一种信息查询方法和系统，涉及智能交通系统应用领域，能够提供更小时间粒度的问题信息和日志分析信息，提高了车厂用户处理其客户问题的效率。该方法包括：获取查询开始信号；根据查询开始信号生成相应的行键组合；其中，行键组合中的行键与行键对应的车辆请求信息按照索引关系存储于第一数据库中，行键的键值包含日期；根据行键组合从第一数据库中查找与行键组合中行键对应的车辆请求信息；依据车辆请求信息生成查询界面，查询界面包含当日日志；接收客户端发送的查询信号，在行键组合中的行键对应的车辆请求信息中查询与查询信号对应的车辆请求信息查询界面中生成相应的查询日志。本发明的实施例应用于信息查询。

Description

一种信息查询方法和系统

技术领域

本发明涉及智能交通系统应用，尤其涉及一种信息查询方法和系统。

背景技术

近几年来随着汽车的家庭普及程度越来越广，人们自驾出行的频率也越来越高，为了扩大消费群体的占有率，可靠及时的路况信息成为诸多车厂推销产品，占领后装市场的有力手段。目前市场上的路况服务提供商也鳞次栉比，但服务的专业性和稳定性也都参差不齐。如何检查与校验路况服务提供商的服务稳定性也成了各大车厂亟待解决的问题。随着车厂路况信息服务项目的时间越来越长，车辆越来越多，暴漏出来的问题也越来越复杂，针对客户提出的各种问题，开发出一种快速、准确的定位问题的原因的软件产品对于校验路况服务的稳定性是非常重要的。

而现阶段的软件产品所提供的查询项目比较单一、时间粒度较大，对于客户的问题不能及时反馈处理，没有一个准确的日志分析信息。所以需要一种产品能够更有效的去查询客户问题，可以做出更准确的日志分析，更好的服务于客户。客户的问题以车辆请求的形式在软件产品中表示，系统或者人工对客户问题的应答包含在车辆请求信息中。

发明内容

本发明的实施例提供一种信息查询方法和系统，能够提供更小时间粒度的问题信息和日志分析信息，提高了车厂用户处理其客户问题的效率。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，提供一种信息查询方法，包括：

获取查询开始信号；根据查询开始信号生成相应的行键组合；其中，行键组合中包含行键，行键与行键对应的车辆请求信息按照索引关系存储于第一数据库中，行键的键值包含日期；根据行键组合从第一数据库中查找与行键组合中行键对应的车辆请求信息；依据车辆请求信息生成查询界面，查询界面包含当日日志；将查询界面反馈给客户端；接收客户端发送的查询信号，在行键组合中的行键对应的车辆请求信息中查询与查询信号对应的车辆请求信息查询界面中生成相应的查询日志后返回给客户端。

第二方面，提供一种信息查询系统，包括：

获取单元，用于在用户的触发下发送查询开始信号；组合单元，用于接收查询开始信号后生成相应的行键组合；其中，行键组合中包含行键，行键与行键对应的车辆请求信息按照索引关系存储于第一数据库中，行健的键值包括日期；搜索单元，用于根据组合单元生成的行键组合从第一数据库中查找与行键组合中行键对应的车辆请求信息并发送给处理单元；处理单元，用于依据搜索单元搜索到的车辆请求信息生成查询界面并发送给客户端，查询界面包含当日日志；

获取单元还用于，接收用户通过客户端触发发送查询信号；搜索单元还用于在接收到客户端发送的查询信号后，在行键组合中的行键对应的车辆请求信息中查询与获取单元接收的查询信号对应的车辆请求信息并发送给处理单元，处理单元依据接收到的车辆请求信息在查询界面生成查询日志发送给客户端。

上述方案中提供的信息查询方法和系统，首先在客户端在用户触发下，发送与用户需要查询的内容对应的查询开始信号，而后根据不同的查询开始信号生成相应的行键组合，根据行键组合从第一数据库中搜索与行键组合中行键键值对应的车辆请求信息，其中，行键与行键对应的车辆请求信息是按照索引关系存储于第一数据库中的；然后根据搜索到的与行键组合中行键键值对应的车辆请求信息生成查询界面，查询界面包含相应的当天日志；比如当天城市日志或者当天车辆请求日志。通过将相应的查询界面发送给客户端显示从而使得车厂客户直观的了解到车厂提供的路况服务问题的多少以及车厂本身对客户问题的反馈程度。进一步的，因为行键中都包含日期，例如2016年10月26日，所以在生成日志时，时间粒度可以达到一天这一级别，可以很好的使车厂用户获得更精确的日志分析；再加上在生成当日车辆请求日志时，行键键值包含车辆ID可以更明确知道哪一辆车向车厂反馈了什么问题，使得车厂用户得到的日志信息更为精确；其次，在用户观看查询界面上日志的后通过客户端发送查询信号后，根据查询信号搜索相应的车辆请求信息并生成查询日志到查询界面上返回给客户端，使得用户可以了解到自己想要的信息。所以本发明实施例提供的信息查询方法及系统可以更为直观的反映更小时间粒度的日志分析信息，使得车厂用户清楚的了解其客户反应的问题，提高了车厂用户处理其客户问题的效率，提高了服务质量。

附图说明

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

图1为本发明的实施例提供的一种信息查询方法流程图；

图2为本发明的另一实施例提供的一种信息查询方法流程图；

图3为本发明的再一实施例提供的一种信息查询方法流程图；

图4为本发明的实施例提供的一种信息查询方法逻辑图；

图5为本发明的实施例提供的一种信息查询方法中当日车辆请求日志示意图；

图6为本发明的实施例提供的一种信息查询方法中应答日志示意图；

图7为本发明的实施例提供的一种信息查询方法中验证部分流程图；

图8为本发明的实施例提供的一种信息查询方法中验证单元实际效果图；

图9为本发明的实施例提供的一种信息查询方法中服务状态日志示意图；

图10为本发明的实施例提供的一种信息查询方法中当日城市日志示意图；

图11为本发明的实施例提供的一种信息查询方法中的路况图；

图12为本发明的实施例提供的一种信息查询系统结构示意图；

图13为本发明的另一实施例提供的应答日志下载效果图；

图14为本发明的实施例提供的一种信息查询方法中服务状态日志查询流程图；

图15为本发明的实施例提供的一种信息查询方法中路况图查询流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了便于清楚描述本发明实施例的技术方案，在本发明的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分，本领域技术人员可以理解“第一”、“第二”等字样并不是在对数量和执行次序进行限定。

需要说明的是，本发明实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本发明实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。本发明实施例中，“的(英文：of)”，“相应的(英文：corresponding，relevant)”和“对应的(英文：corresponding)”有时可以混用，应当指出的是，在不强调其区别时，其所要表达的含义是一致的。本方案中的“A和/或B”指保护方案“A”或者方案“B”或者方案“A与B”三种情况。

Hadoop实现了一个分布式文件系统(Hadoop Distributed File System，以下简称HDFS)。HDFS有高容错性的特点，并且设计用来部署在低廉的(low-cost)硬件上；而且它提供高传输率(high throughput)来访问应用程序的数据，适合那些有着超大数据集(large data set)的应用程序。HDFS放宽了(relax)POSIX(Portable Operating SystemInterface可移植操作系统接口)的要求，可以以流的形式访问(streaming access)文件系统中的数据，用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。

HBase是一个分布式的、面向列的开源数据库，该技术来源于Fay Chang所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache(web(Wired Eqivalent Privacy有线等效保密协议)服务器)的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口(应用程序编程接口)。用户可以通过http(超文本传输协议)请求，向搜索引擎服务器提交一定格式的XML(可扩展标记语言)文件，生成索引；也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。

目前各个车厂为了保证自己提供的路况服务更为稳定准确，所以均需要一种用来对顾客反馈路况服务问题进行统计、查询和分析的软件系统。而现阶段的软件产品所提供的查询项目比较单一、时间粒度较大，对于客户的问题不能及时反馈处理，没有一个准确的日志分析信息。所以需要一种产品能够更有效的去查询客户问题，可以做出更准确的日志分析，更好的服务于客户。

针对上述问题，本发明的实施例基于Solr和HBase提供一种信息查询方法，其中，Hadoop实现了一个分布式文件系统(Hadoop Distributed File System，简称HDFS)。HDFS有高容错性的特点，并且设计用来部署在低廉的(low-cost)硬件上；而且它提供高传输率(high throughput)来访问应用程序的数据，适合那些有着超大数据集(large data set)的应用程序。HDFS放宽了(relax)POSIX(Portable Operating System Interface可移植操作系统接口)的要求，可以以流的形式访问(streaming access)文件系统中的数据，用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。HBase是一个分布式的、面向列的开源数据库，该技术来源于Fay Chang所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache(web(Wired Eqivalent Privacy有线等效保密协议)服务器)的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口(应用程序编程接口)。用户可以通过http(超文本传输协议)请求，向搜索引擎服务器提交一定格式的XML(可扩展标记语言)文件，生成索引；也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。

基于上述内容参照图1所示，本发明实施例提供一种信息查询方法，包括：

11、信息查询系统获取查询开始信号。

此处所说的获取查询开始信号是用户通过客户端的按键或者可触控屏幕等一些可操作的输入设备的操作来生成查询开始信号，查询开始信号的种类由用户自行决定。

12、信息查询系统根据查询开始信号生成相应的行键组合；其中，行键组合中包含行键，行键与行键对应的车辆请求信息按照索引关系存储于第一数据库中，所述行键的键值包含日期。

具体的，日期如2016年6月7日。在本发明实施例中，接收到查询开始的信号时根据查询开始信号获取至少一个预存的行键，将获取到的行键按照车辆每日最后一次发送请求的时间排序生成行键组合，每日最后一次发送请求的时间如2016年6月7日10时6分6秒。

示例性的，本发明实施例使用solr这种搜索引擎在接收到用户通过客户端的操作发送的查询开始信号时完成对上述的行键的组合，solr中本身也是在用户操作或者系统自动录入各种在查询过程中需要的行键键值。

13、信息查询系统根据行键组合从第一数据库中查找与行键组合中行键对应的车辆请求信息。

具体的，solr生成行键组合后根据行键组合中行键的键值从第一数据库(本发明实施例中使用Hbase作为第一数据库)搜索到与行键键值有索引关系的车辆请求信息。

14、信息查询系统依据车辆请求信息生成查询界面，该查询界面包含当日日志。

15、信息查询系统将查询界面反馈给客户端。

16、信息查询系统接收客户端发送的查询信号。

当客户端显示了日志后，用户会根据自身需求通过客户端发送查询信号用来查询用户自身需要查询的日志信息。

17、信息查询系统根据查询信号，在行键组合中的行键对应的车辆请求信息中查询与查询信号对应的车辆请求信息并在查询界面生成相应的查询日志后返回给客户端。

上述方案中提供的信息查询方法，首先客户端在用户触发下，发送与用户需要查询的内容对应的查询开始信号，而后根据不同的查询开始信号生成相应的行键组合，根据行键组合从第一数据库中搜索与行键组合中行键键值对应的车辆请求信息，其中，行键与行键对应的车辆请求信息是按照索引关系存储于第一数据库中的；然后根据搜索到的与行键组合中行键键值对应的车辆请求信息生成查询界面，查询界面包含相应的当天日志；比如当天城市日志或者当天车辆请求日志。通过将相应的查询界面发送给客户端显示从而使得车厂客户直观的了解到车厂提供的路况服务问题的多少以及车厂本身对客户问题的反馈程度。进一步的，因为行键中都包含日期，例如2016年6月7日，所以在生成日志时，时间粒度可以达到一天这一级别，可以很好的使车厂用户获得更精确的日志分析；再加上在生成当日车辆请求日志时，行键键值包含车辆ID可以更明确知道哪一辆车向车厂反馈了什么问题，使得车厂用户得到的日志信息更为精确；其次，在用户观看查询界面上日志的后通过客户端发送查询信号后，根据查询信号搜索相应的车辆请求信息并生成查询日志到查询界面上返回给客户端，使得用户可以了解到自己想要的信息。所以本发明实施例提供的信息查询方法及系统可以更为直观的反映更小时间粒度的日志分析信息，使得车厂用户清楚的了解其客户反应的问题，提高了车厂用户处理其客户问题的效率，提高了服务质量。

需要说明的是，上述方案中的查询开始信号可以为分为城市统计查询开始信号和请求查询开始信号，当查询开始信号为城市统计查询开始信号时，行键组合包括城市名称和日期，查询界面包含的是当日城市日志，查询信号包含日期，查询日志为查询信号包含的日期对应的城市日志；当查询开始信号为请求查询开始信号时，行键组合包括车辆ID和日期，查询界面包含的是当日车辆请求日志，查询信号包含日期和/或车辆ID，查询日志为查询信号包含的日期和/或车辆ID对应的车辆请求日日志。

为了清楚地说明上述方案，下面将用两个实施例进行描述：

实施例一：参照图2所示，当查询开始信号为城市统计查询开始信号时，具体信息查询方法如下：

21、信息查询系统获取城市统计查询开始信号。

22、信息查询系统根据城市统计查询开始信号生成相应的行键组合；其中，行键组合中包含行键，行键与行键对应的车辆请求信息按照索引关系存储于第一数据库中，所述行键的键值包含日期。

具体的，行键组合中行键的键值则还包括城市名称。

23、信息查询系统根据行键组合从第一数据库中查找与行键组合中行键对应的车辆请求信息。

24、信息查询系统依据车辆请求信息生成查询界面，该查询界面包含当日城市日志。

具体的，该当日城市日志包括当日日期(Data time)、城市(City)名称和每个城市在日期对应的车辆请求总量(Request Count)。此时该方法还包括信息查询系统根据接收到的城市和日期对应的车辆请求信息计算每个城市车辆请求总数。

25、信息查询系统将查询界面反馈给客户端。

具体的，客户端将把查询界面进行显示供用户观看；示例性的，包含当日城市日志的查询界面部分显示结果如图10所示，界面左边由上至下为WWW RTTI表示信息查询系统名称，监测(Monitoring)指的是在对路况服务进行检测的一系列查询展示；服务状态(Service Status)、会话统计(Session Statistics)、城市统计(City Statistics)均为系统提供的其他查询渠道，可供用户进行选择；服务状态指的系统服务状态即是否正常运行；会话统计为车辆请求日志；城市统计为对每个城市请求情况进行统计；界面上方有系统环境(system)和“请选择日期”(please select date)，此中的当日城市日志其后可通过选择日期查询不同日期的城市请求量统计结果。

26、信息查询系统接收客户端发送的查询信号，查询信号包括查询日期。

示例性的，参照图10所示，在系统返回当日城市日志中可以对日期进行选择，当用户通过对客户端的操作完成选择，客户端发送相应的查询信号，查询信号为客户选择的日期；这里所说的日期包括年月日，例如：2016年6月7日。

27、信息查询系统根据查询信号，在行键组合中的行键对应的车辆请求信息中查询与查询信号对应的车辆请求信息并在查询界面生成相应的城市日志后返回给客户端。

具体的，对于查询界面包含当日城市日志而言，查询信号包含用户选择的日期，信息查询系统根据查询信号向客户端返回与该日期对应的城市日志作为查询日志表现该日期每个城市的车辆请求量统计信息；此时查询界面显示效果和图10相似，只是其中界面显示的日期和每个城市请求量统计结果不同。

上述提到的实施例一，首先在客户端在用户触发下，发送城市统计查询开始信号，依据城市统计查询开始信号生成相应的行键组合，其中的行键键值包含城市名称和日期；根据行键组合从第一数据库中搜索与行键组合中行键键值对应的车辆请求信息；然后根据搜索到的与行键组合中行键键值对应的车辆请求信息生成查询界面，查询界面包含当日城市日志，当日城市日志包含各个城市在当天的车辆请求总数。通过将该查询界面发送给客户端显示从而使得车厂客户直观的了解到当日车厂提供的路况服务在各个城市的服务情况以及各个城市出现路况问题的多少。进一步的，因为行键中都包含日期，例如2016年6月7日，所以在生成城市日志时，时间粒度可以达到一天这一级别，可以很好的使车厂用户获得更小时间粒度的日志分析；其次，在用户观看查询界面上日志的后通过客户端发送查询信号后，根据查询信号搜索相应的车辆请求信息并生成查询日志到查询界面上返回给客户端，使得用户可以了解到自己想要知道的任何除未来的某一天的各个城市的车辆发送车辆请求的数量的信息，以便可以针对行的提高某个问题出现较多的城市的路况服务。

实施例二：参照图3所示，当查询开始信号为请求查询开始信号时，具体信息查询方法如下：

31、信息查询系统获取请求查询开始信号。

32、信息查询系统根据请求查询开始信号生成相应的行键组合；其中，行键组合中包含行键，行键与行键对应的车辆请求信息按照索引关系存储于第一数据库中，所述行键的键值包含日期。

具体的，行键组合中行键的键值则还包括车辆ID。

33、信息查询系统根据行键组合从第一数据库中查找与行键组合中行键对应的车辆请求信息。

34、信息查询系统依据车辆请求信息生成查询界面，该查询界面包含当日车辆请求日志。

具体的，当日车辆请求日志包括：当日日期、车辆ID(Drive ID)、车辆位置(Location)、服务版本(LT Version)、版本需求(UAVersion)、当日车辆第一次发送车辆请求的时间(Session Start)、当日车辆最后一次发送车辆请求的时间(Last Request)；此时，该方法还包括当查询界面包含当日车辆请求日志时根据车辆ID和日期对应的车辆请求信息计算相关参数；其中相关参数至少包括以下的一项或多项：当日车辆第一次发送车辆请求和当日车辆最后一次发送车辆请求的间隔时间(Age)、差分更新数(Update Counter)、平均响应时间(Avg Response Time)、最大相应时间(Max Response Time)、平均响应数据大小(Avg Delivered Datasize)、最大响应数据大小(Max Delivered Datasize)；其中，差分更新数指的是车厂的客户发送的车辆请求也就是路况问题在信息查询系统或者车厂员工确认后发现该客户提出的路况问题中对应路况信息改变的次数；响应时间指的是车厂的信息查询系统或者车厂员工对客户问题进行回答解决所用的时间；同理响应数据指的是车厂的信息查询系统或者车厂员工对客户问题进行回答解决时交流信息的数据大小。

35、信息查询系统将查询界面反馈给客户端。

示例性的，包含当日车辆请求日志的查询界面部分结果显示效果如图5所示，最左边由上至下依次为WWW RTTI、监测、服务状态、城市统计；上方由左至右为系统环境、“请选择日期”和“请选择车辆ID”(please select the DriveID)；中间部分为当日车辆请求日志具体内容；该日志可通过选择日期和车辆ID查询不同日期和/或不同车辆ID对应车辆的车辆请求信息或者车辆应答信息。

36、信息查询系统接收客户端发送的查询信号；查询信号包含查询日期和/或查询车辆ID。

示例性的，参照图5所示，在系统返回当日的车辆请求日志中可以对日期和车辆ID进行选择，当用户通过对客户端的操作完成选择，客户端发送相应的查询信号，查询信号可以是日期或者车辆ID或者日期和车辆ID；这里所说的日期包括年月日，例如：2016年6月7日；车辆ID指的是车厂用户对于其每个客户都设置了一个唯一的专属的ID(身份识别码)用来区分不同客户。

37、信息查询系统根据查询信号，在行键组合中的行键对应的车辆请求信息中查询与查询信号对应的车辆请求信息并在查询界面生成相应的查询日志后返回给客户端。

对于查询界面包含当日车辆请求日志而言，当查询信号只包含日期时，向客户端返回如图5所示类似的查询界面，其中包含的查询日志包括的日期和相应车辆请求日志的具体信息与图5不同；当查询信号只包含车辆ID时，返回与该车辆ID对应车辆的所有车辆请求信息给客户端；当查询信号包含日期和车辆ID时，向客户端返回该车辆ID对应车辆在该日期的所有请求信息包括车辆发送的请求和车厂解决的答复，此时返回客户端的查询界面包含的查询日志叫做应答日志，应答日志部分结果显示效果如图6所示。

上述提到的实施例二，首先客户端在用户触发下，发送请求查询开始信号；而后请求查询开始信号生成相应的行键组合，行键组合中行键的键值包括车辆ID和日期；根据行键组合从第一数据库中搜索与行键组合中行键键值对应的车辆请求信息；然后根据搜索到的与行键组合中行键键值对应的车辆请求信息生成查询界面，查询界面包含相应的当天车辆请求日志，其中包括车辆ID、车辆位置、服务版本、版本需求、当日车辆第一次请求时间、当日车辆最后一次请求时间等客户需要了解的信息，另外还可以通过计算得到其他的用户想要了解的相关参数(如：当日车辆第一次请求和当日车辆最后一次请求的间隔时间、差分更新数、平均响应时间、最大相应时间、平均响应数据大小、最大响应数据大小等)；而后通过将当日车辆请求日志发送给客户端显示从而使得车厂客户直观的了解到当天车厂提供的路况服务问题的多少以及车厂本身对客户问题的反馈程度，同时，用户可以通过客户端对查询界面包含的日志的日期等条件进行进一步限定从而得到查询日志，用户可以从查询日志得到想要了解的信息(例如：以前的车辆请求日志或者某一个车辆ID对应车辆的每一天的应答日志等)。进一步的，因为行键中都包含日期，例如2016年7月6日，所以在生成日志时，时间粒度可以达到一天这一级别，可以很好的使车厂用户获得更精确的日志分析；再加上在生成车辆请求日志时，行键键值包含车辆ID可以更明确知道哪一辆车向车厂反馈了什么问题，可以使得车厂用户得到的车辆请求日志信息更为精确。

示例性的，上述方案中的信息查询方法逻辑图如图4所示，其中查询开始信号和查询信号皆由用户通过客户端发送，查询开始信号在前，查询信号在后；客户发送查询开始信号给solr进程，solr进程此时依据查询开始信号产生了行键组合即rowkey组合，而后solr根据rowkey组合从第一数据库Hbase中搜索相应的车辆请求信息并对请求信息做处理计算相关参数，而后返回相应的当天日志在查询界面上给客户端，用户根据客户端显示的日志信息，通过客户端发送查询信号给solr进程，而后solr进程通过查询信号从前面查到的与行键组合对应的车辆请求信息中找到与查询信号相对应的车辆请求信息并生成查询日志在查询界面上，然后返回给客户端。

上述方案中提供的信息查询方法和系统，首先在客户端在用户触发下，发送与用户需要查询的内容对应的查询开始信号；而后根据不同的查询开始信号生成相应的行键组合，根据行键组合从第一数据库中搜索与行键组合中行键键值对应的车辆请求信息，其中，行键与行键对应的车辆请求信息是按照索引关系存储于第一数据库中的；然后根据搜索到的与行键组合中行键键值对应的车辆请求信息生成查询界面，查询界面包含相应的当天日志；例如当日城市日志，其中包含各个城市在当天的车辆请求总数；例如当日车辆请求日志，其中包括车辆ID、车辆位置、服务版本、版本需求、当日车辆第一次请求时间、当日车辆最后一次请求时间等客户需要了解的信息，另外还通过计算得到其他用户想要了解的相关参数(如：当日车辆第一次请求和当日车辆最后一次请求的间隔时间、差分更新数、平均响应时间、最大相应时间、平均响应数据大小、最大响应数据大小等)；而后通过将当天日志发送给客户端显示从而使得车厂客户直观的了解到当天车厂提供的路况服务问题的多少以及车厂本身对客户问题的反馈程度，同时，用户可以通过客户端对查询界面包含的日志的日期等条件进行进一步限定从而得到查询日志，用户可以从查询日志得到想要了解的信息(例如：以前的日志消息或者某一个车辆ID对应车辆的应答消息等)。进一步的，因为行键中都包含日期，例如2016年7月6日，所以在生成日志时，时间粒度可以达到一天这一级别，可以很好的使车厂用户获得更精确的日志分析；再加上在生成车辆请求日志时，行键键值包含车辆ID可以更明确知道哪一辆车向车厂反馈了什么问题，使得车厂用户得到的日志信息更为精确。所以本发明实施例提供的信息查询方法及系统可以更为直观的反映更准确的时间粒度更小的日志分析信息，使得车厂用户清楚的了解其客户反应的问题，提高了车厂用户处理其客户问题的效率，提高了服务质量。

进一步的，为了使信息不外泄增加保密度，参照如图7本发明的实施例还提供的信息查询方法还包括：

71、获取客户端发送的验证信息并判断验证信息是否正确。

72、当确认验证信息正确时，获取查询开始信号。

73、当验证信息错误时，发送提示信息。

示例性的，此处的验证信息为用户名和密码，提示信息为显示“登录失败，请输入正确的用户名、密码”用来提示使用者输入正确的用户名和密码。示例性的，本发明实施例提供的信息查询方法若是在电脑通过程序实现的，则此处所说的对验证信息的判断过程是通过用户输入以及电脑通过显示屏的反馈完成的，验证过程所在的界面也叫作登录界面，登录界面如图8所示。

为了可以更详细反复的去了解每个用户反映的问题和解决情况，办发明实施例提供的信息查询方法还包括：

获取客户端发送的下载信号后将查询界面中的日志下载至客户端。

示例性的，此处下载的日志可以为所有用户想要仔细了解的日志；例如应答日志，可以以CSV格式(纯文本纯字符格式)存储在用户指定的存储装置上。

参照如图14所示，为了能提供各个城市路况服务状态的情况，在确定验证信息正确时该信息查询方法还可以包括：

81、获取服务状态查询信号。

82、依据服务状态查询信号从第二数据库搜索服务状态数据。

这里所说的第二数据库一般为前台实时更新的用来快速处理录入的更新数据的数据库。

83、根据服务状态数据生成服务状态日志并返回给客户端。

上述81、82和83步骤主要是通过发送模拟车辆请求给信息查询系统，通过对模拟请求的处理确定系统服务是否正常，只有当系统服务状态正常时，前面所说的信息查询系统查询到的信息才会是正确的。

示例性的，服务状态信息部分显示结果如图9所示，视图最上方由左至右依次为系统环境和地图版本(Map Version)；最左边由上至下依次为WWW RTTI、“你好，管理员”(Hello，admin)、退出(sign out)、监测、会话统计和城市统计；中间的日志显示项目由左至右为城市、状态、上一次交通流更新时间(Latest Flow Timestamp)、最新事件更新时间(Latest Event Timestamp)和时间数；该日志会显示各个城市的服务状态情况、每个城市最新交通流也就是更新录入的新的路况信息的时间、每个城市最新交通事件发生的时间和每个城市最新统计的交通事件总数；能够方便用户了解路况信息服务稳定状况。

进一步的，参照如图15所示，为了能更直观去了解客户提到的路况问题，所以该信息查询方法还包括：

91、获取路况查询信号。

92、依据路况查询信号从第二数据库搜索路况数据。

93、根据路况数据生成路况图并返回给客户端。

通过对路况图的了解，该信息查询系统的操作人员或者系统本身可以通过路况图中各个路段的信息可以针对每一个车辆ID对应的车辆发送的车辆请求中包含的问题进行解答解决。示例性的，路况图部分显示结果如图11所示，该图显示了默认当前城市即北京的路况信息；需要说明的是，如图11所示，在显示路况时，可以通过选择如图11左边部分的城市来显示相应城市的路况图；其中路况图可以包含上面方案中提到的查询界面中日志的某一条或多条信息，比如以一个闪烁的点表示一个车辆ID对应车辆发送车辆请求的位置等或者将日志信息解析后，再将日志信息中每条道路所对应的路况信息(红、黄、绿表示不同的拥堵程度)描画到地图上，仅是以纯粹地图形式表示，这样更加的直观的发映一个城市的路况情况；还可以通过对比日志中的位置信息(比如：XX路从九点开始堵，一直到现在)从地图中了解到该路段的路况状况后反应给对应的车辆。

参照如图12所示，本发明实施例还提供一种信息查询系统，该系统包括：

获取单元1，用于获取用户通过客户端触发的查询开始信号。

组合单元2，用于接收查询开始信号后生成相应的行键组合发送给搜索单元4；其中，行键组合中包含行键，行键与行键对应的车辆请求信息按照索引关系存储于第一数据库3中；行键组合中行键键值包含日期，在这其中日期可以精确到每一天，使得本发明实施例提供的信息查询系统提供的日志时间粒度可以达到一天的级别，相比现有技术更为准确详细。

搜索单元4，用于根据组合单元2生成的行键组合从第一数据库3中查找与行键组合中行键对应的车辆请求信息并发送给处理单元5。

处理单元5，用于依据搜索单元4搜索到的车辆请求信息生成查询界面并发送给客户端0，该查询界面包含当日日志。

获取单元1还用于，接收在用户通过客户端0触发的查询信号；

搜索单元4还用于在接收到客户端发送的查询信号后，在行键组合中的行键对应的车辆请求信息中查询与获取单元1接收的查询信号对应的车辆请求信息并发送给处理单元5，处理单元5依据接收到的车辆请求信息在查询界面生成查询日志发送给客户端0。

可选的，行健键值还包括城市名称；当日日志为当城市日志，当日城市日志包含当日日期、城市名称和在当日日期内车辆发送的车辆请求的总量；此时客户端0发送的查询信号包括查询日期。此时处理单元5还用于根据接收到的城市名称和日期对应的车辆请求信息计算每个城市车辆请求总量。

可选的，行健键值还包括车辆ID；处理单元生成的查询界面包含的当日日志为当日车辆请求日志，车辆请求日志包含：车辆ID、车辆位置、服务版本、版本需求、当日车辆第一次发送车辆请求的时间、当日车辆最后一次发送车辆请求的时间；查询信号包括查询日期和/或查询车辆ID。此时，处理单元5还用于根据接收到的与车辆ID和日期对应的车辆请求信息计算相关参数；处理单元5在生成查询界面中的城市日志时，还用于根据接收到的城市和日期对应的车辆请求信息计算每个城市车辆请求总数；其中，相关参数至少包括以下的一项或多项：当日车辆第一次请求和当日车辆最后一次请求的间隔时间、差分更新数、平均响应时间、最大相应时间、平均响应数据大小、最大响应数据大小。此举措可以满足车厂用户在查询过程中想要直观了解由录入的车辆请求信息可以反映出的其他不能直接得到的信息，方便车厂用户更方便去处理其客户提出的各种问题。

上述方案中提到的客户端0可以是电脑、手机或者其他可操作的终端；各个单元均为solr程序实现整个查询过程中的程序模块或者包含程序模块的物理模块；其中的第一数据库在本发明实施例中优选的为hbase。

该信息查询系统中的组合单元2具体用于根据查询开始信号获取至少一个预存的行键，将行键按照车辆每日最后一次发送请求的时间排序生成所述行键组合。每日最后一次发送请求的时间例如2016年7月6日；优选的，排序呢方式为时间倒序，方便用户可以了解到最新的消息。

在本发明实施例中，组成行键组合的行键的键值均是存储在solr中，而且solr中的数据也会随着hbase中的数据随时更新，以方便车场用户在使用该信息查询系统时能获取到最新的信息。

可选的，本发明实施例提供的信息查询系统还包括下载单元6，当获取单元1获取到客户端发送的下载信号后，下载单元6下载所述查询界面中的日志到客户端。当该系统的操作人员需要将查询到的日志给其他人看或者气候做具体分析时，可以通过下载单元6将需要的日志下载到客户端0上或者其他可供下载的设备上。示例性的，本发明实施例对于应答日志的下载结果如图13所示，一般使用CSV(纯文本)格式存储在客户端1中。

可选的，该信息查询系统还包括，验证单元7；获取单元还用于在客户端0被触发发送查询开始信号之前，接收用户通过客户端输入的验证信息；验证单元，用于根据获取单元获取的验证信息判断验证信息是否正确；当验证单元确认验证信息正确时，获取单元获取查询开始信号；当验证单元确认验证信息错误时，发送提示信息。

示例性的，验证单元7指的是登录验证，在本发明实施例提供的信息查询系统中，增添验证单元7可以强化系统信息保密性。一般的，验证单元7验证过程的显示效果如图8所示，验证信息示例性的为用户名和密码，当用户输入用户名和密码中任意一个错误或者两者都错误或者少输入一项或两项验证信息时，点击“登录”显示单元会显示如“登录失败，请输入正确的用户名、密码”的提示信息提醒用户重新输入正确的验证信息。

可选的，该信息查询系统在验证单元7确定确证信息正确时，获取单元1还用于获取服务状态查询信号；搜索单元4还用于依据获取单元1获取的服务状态查询信号从第二数据库8获取服务状态数据；处理单元5还用于根据搜索单元4搜索到的服务状态数据生成服务状态日志并发送给客户端0。服务状态信息可以让用户更明确那些城市的路况服务状态良好，那些城市路况服务状态有问题，以便于及时去处理。具体的服务状态日志显示效果如图9。

可选的，该信息查询系统在验证单元7确定确证信息正确时，获取单元1还用于获取路况查询信号；搜索单元4还用于获取单元1获取的路况查询信号从第二数据库8搜索路况数据；处理单元5还用于依据搜索单元4搜索到的路况数据生成路况图发送给客户端0。示例性的，此处的路况图效果类似平常使用的地图软件的效果图，参照图8所示，可以反映不同城市的交通状况，方便车厂用户解决其客户提出的问题也能直观了解路况信息以便及时反映给其客户。

需要说明的是，上述方案中所提到的客户端发出的各个信息或者指令均由用户触发发送，例如在可触控屏幕上触摸特定位置来发送特定给信号，或者也可以是通过键盘或者其他输入设备输入指令或者信息；上述的所有单元可以是独立的或者互相结合的、虚拟的或者实体的，以实现各个单元对应的功能为准。

综上所述，本发明实施例提供的信息查询系统，通过各个虚拟或者物理实体的单元互相之间信息的传输和指令的交互实现了对信息的查询，满足了用户对各种不同信息查询的需求；用户可以通过对客户端的操作发送相应的查询开始信号或服务状态查询信号或路况查询信号给搜索单元，搜索单元从数据库搜索到相应的车辆请求信息发送给处理单元，处理单元根据车辆请求信息生成当天最新日志反馈给客户端显示，用户在观察了当天日志后可以根据显示界面上提供的推荐选择项通过对客户端的操作选择输入查询信号从未可以获得需要的日志信息，同时还可以将需要的日志下载到客户端方便以后详细的分析观察；与现有技术相比，本发明实施例提供的信息查询系统在日志的时间粒度方面更近一步到达了最小一天的日志选择，同时提供了更为丰富的日志信息方面车厂用户观察，使得车厂用户清楚的了解其客户反应的问题，提高了车厂用户处理其客户问题的效率，提高了服务质量。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可以用硬件实现，或固件实现，或它们的组合方式来实现。当使用软件实现时，可以将上述功能存储在计算机可读介质中或作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是计算机能够存取的任何可用介质。以此为例但不限于：计算机可读介质可以包括随机存储器(英文全称：Random AccessMemory，英文简称：RAM)、只读存储器(英文全称：Read Only Memory，英文简称：ROM)、电可擦可编程只读存储器(英文全称：Electrically Erasable Programmable Read OnlyMemory，英文简称：EEPROM)、只读光盘(英文全称：Compact Disc Read Only Memory，英文简称：CD-ROM)或其他光盘存储、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质。此外。任何连接可以适当的成为计算机可读介质。例如，如果软件是使用同轴电缆、光纤光缆、双绞线、数字用户专线(英文全称：Digital Subscriber Line，英文简称：DSL)或者诸如红外线、无线电和微波之类的无线技术从网站、服务器或者其他远程源传输的，那么同轴电缆、光纤光缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在计算机可读介质的定义中。

在本申请所提供的实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。所有单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (16)

1.一种信息查询方法，其特征在于，包括：

获取查询开始信号；

根据所述查询开始信号生成相应的行键组合；其中，所述行键组合中包含行键，所述行键与所述行键对应的车辆请求信息按照索引关系存储于第一数据库中，所述行键的键值包含日期；

根据所述行键组合从第一数据库中查找与所述行键组合中行键对应的车辆请求信息；

依据所述车辆请求信息生成查询界面，所述查询界面包含当日日志；

将所述查询界面反馈给客户端；

接收客户端发送的查询信号，在所述行键组合中的行键对应的车辆请求信息中查询与所述查询信号对应的车辆请求信息所述查询界面中生成相应的查询日志后返回给客户端。

2.根据权利要求1所述的方法，其特征在于，所述行键的键值还包含城市名称；所述当日日志为当日城市日志，其中所述当日城市日志包含当日日期、城市名称和每个城市在所述当日日期内车辆发送的车辆请求的总量；所述查询信号包括查询日期。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

据接收到的所述城市名称和日期对应的车辆请求信息计算每个城市车辆请求总量。

4.根据权利要求1所述的方法，其特征在于，

所述行键的键值还包含车辆ID；所述当日日志为当日车辆请求日志，所述车辆请求日志包含：车辆ID、车辆位置、服务版本、版本需求、当日车辆第一次发送车辆请求的时间、当日车辆最后一次发送车辆请求的时间；所述查询信号包括查询日期和/或查询车辆ID。

5.根据权利要求4所述的方法，其特征在于，所述当日车辆请求日志还包括至少以下相关参数中的一项或多项：当日车辆第一次发送车辆请求和当日车辆最后一次发送车辆请求的间隔时间、差分更新数、平均响应时间、最大相应时间、平均响应数据大小、最大响应数据大小；

其中所述方法还包括：根据所述车辆ID和日期对应的车辆请求信息计算所述相关参数。

6.根据权利要求1所述的方法，其特征在于，所述根据所述查询开始信号生成相应的行键组合包括：

根据所述查询开始信号获取至少一个预存的行键，将至少一个所述行键按照车辆每日最后一次发送车辆请求的时间排序生成所述行键组合。

7.根据权利要求1所述的方法，其特征在于，还包括：

获取客户端发送的下载信号后将所述查询界面中的日志下载至客户端。

8.根据权利要求1所述的方法，其特征在于，在所述获取查询开始信号前，还包括：

获取客户端发送的验证信息并判断验证信息是否正确；

当确定所述验证信息正确时，获取查询开始信号；当所述验证信息错误时，发送提示信息。

9.一种信息查询系统，其特征在于，包括：

获取单元，用于在用户的触发下发送查询开始信号；

组合单元，用于接收所述查询开始信号后生成相应的行键组合；其中，所述行键组合中包含行键，所述行键与所述行键对应的车辆请求信息按照索引关系存储于第一数据库中，所述行健的键值包括日期；

搜索单元，用于根据所述组合单元生成的行键组合从第一数据库中查找与所述行键组合中行键对应的车辆请求信息并发送给处理单元；

处理单元，用于依据所述搜索单元搜索到的车辆请求信息生成查询界面并发送给客户端，所述查询界面包含当日日志；

所述获取单元还用于，接收用户通过客户端触发发送查询信号；

所述搜索单元还用于在接收到客户端发送的查询信号后，在所述行键组合中的行键对应的车辆请求信息中查询与所述获取单元接收的所述查询信号对应的车辆请求信息并发送给处理单元，处理单元依据接收到的车辆请求信息在所述查询界面生成查询日志发送给客户端。

10.根据权利要求9所述的信息查询系统，其特征在于，所述行健键值还包括城市名称；所述当日日志为当城市日志，所述当日城市日志包含当日日期、城市名称和在所述当日日期内车辆发送的车辆请求的总量；此时所述客户端发送的查询信号包括查询日期。

11.根据权利要求10所述的信息查询系统，其特征在于，所述方法还包括：

所述处理单元还用于根据接收到的所述城市名称和日期对应的车辆请求信息计算每个城市车辆请求总量。

12.根据权利要求9所述的信息查询系统，其特征在于，所述行健键值还包括车辆ID；所述当日日志为当日车辆请求日志，所述车辆请求日志包含：车辆ID、车辆位置、服务版本、版本需求、当日车辆第一次发送车辆请求的时间、当日车辆最后一次发送车辆请求的时间；所述查询信号包括查询日期和/或查询车辆ID。

13.根据权利要求12所述的信息查询系统，其特征在于，所述方法还包括：所述处理单元还用于根据接收到的所述车辆ID和日期对应的车辆请求信息计算所述相关参数；

所述相关参数至少包括以下的一项或多项：当日车辆第一次请求和当日车辆最后一次请求的间隔时间、差分更新数、平均响应时间、最大相应时间、平均响应数据大小、最大响应数据大小。

14.根据权利要求9所述的信息查询系统，其特征在于，所述组合单元具体用于根据所述查询开始信号获取至少一个预存的行键，将所述行键按照车辆每日最后一次发送请求的时间排序生成所述行键组合。

15.根据权利要求9所述的信息查询系统，其特征在于，还包括：

所述获取单元用于获取到客户端发送的下载信号；

下载单元，用于在所述获取单元获取到客户端发送的下载信号后，下载所述查询界面中的日志到客户端。

16.根据权利要求9所述的信息查询系统，其特征在于，还包括：

所述获取单元还用于在客户端被触发发送查询开始信号之前，接收用户通过客户端输入的验证信息；

验证单元，用于根据所述获取单元获取的验证信息判断所述验证信息是否正确；

当所述验证单元确认所述验证信息正确时，所述获取单元获取查询开始信号；当所述验证单元确认所述验证信息错误时，发送提示信息。