CN112100138A - 一种日志查询方法、装置、存储介质和电子设备 - Google Patents

Abstract

本申请实施例提供一种日志查询方法、装置、存储介质和电子设备，该日志查询方法包括：获取日志查询请求；根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据，并生成包括目标日志数据的日志查询结果；输出日志查询结果。本申请实施例通过利用ClickHouse数据库的查询速度比较快的优势来进行日志数据的查询，从而能够提高查询效率，提升用户体验。

Description

一种日志查询方法、装置、存储介质和电子设备

技术领域

本申请涉及大数据量查询技术领域，具体而言，涉及一种日志查询方法、装置、存储介质和电子设备。

背景技术

由于受到实际应用场景的限制，该应用场景相关的日志数据的存储只能采用单台服务器的构架，而并非是采用分布式的构架。

在实现本发明的过程中，发明人发现现有技术中存在如下问题：在需查询的日志数据的数据量比较大的情况下，会导致单台服务器的压力增大，性能达到瓶颈，从而很容易引起日志查询效率比较低的问题，影响了用户体验。

发明内容

本申请实施例的目的在于提供一种日志查询方法、装置、存储介质和电子设备，以解决现有技术中存在着的日志查询效率比较低的问题。

第一方面，本申请实施例提供了一种日志查询方法，该日志查询方法包括：获取日志查询请求；根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据，并生成包括目标日志数据的日志查询结果；输出日志查询结果。

因此，本申请实施例通过利用ClickHouse数据库的查询速度比较快的优势来进行日志数据的查询，从而能够提高查询效率，提升用户体验。

在一个可能的实施例中，ClickHouse数据库包括至少一种表格，每种表格与一个时间粒度对应。

因此，本申请实施例通过分表的方式来进行数据的存储，从而可快速查找到相关时间范围的表格，进而也能够进一步提高日志查询效率。

在一个可能的实施例中，日志查询请求包括查询时间段和查询条件，根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据，包括：根据查询时间段，从ClickHouse数据库的所有表格中查找与查询时间段匹配的目标表格；从目标表格中查找出与查询条件匹配的目标日志数据。

在一个可能的实施例中，根据查询时间段，从ClickHouse数据库的所有表格中查找与查询时间段匹配的目标表格，包括：按照预设时间粒度，对查询时间段进行时间分割，以获得至少两个时间段；从所有表格中查找与每个时间段匹配的目标表格。

因此，本申请实施例通过对查询时间段的分割，从而能够快速查找到对应的目标表格，进而也能够进一步提高日志查询效率。

第二方面，本申请实施例提供了一种日志查询装置，该日志查询装置包括：获取模块，用于获取日志查询请求；查找模块，用于根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据，并生成包括目标日志数据的日志查询结果；输出模块，用于输出日志查询结果。

在一个可能的实施例中，ClickHouse数据库包括至少一种表格，每种表格与一个时间粒度对应。

在一个可能的实施例中，日志查询请求包括查询时间段和查询条件，查找模块包括：第一查找子模块，用于根据查询时间段，从ClickHouse数据库的所有表格中查找与查询时间段匹配的目标表格；第二查找子模块，用于从目标表格中查找出与查询条件匹配的目标日志数据。

在一个可能的实施例中，第一查找子模块，具体用于：按照预设时间粒度，对查询时间段进行时间分割，以获得至少两个时间段；从所有表格中查找与每个时间段匹配的目标表格。

第三方面，本申请实施例提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行第一方面或第一方面的任一可选的实现方式所述的方法。

第四方面，本申请实施例提供了一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行第一方面或第一方面的任一可选的实现方式所述的方法。

第五方面，本申请提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行第一方面或第一方面的任意可能的实现方式中的方法。

为使本申请实施例所要实现的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种应用场景的示意图；

图2示出了本申请实施例提供的一种日志查询方法的流程图；

图3示出了本申请实施例提供的一种日志查询方法的具体流程图；

图4示出了本申请实施例提供的一种日志查询装置的结构框图；

图5为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

为了解决现有技术中存在着的日志查询效率比较低的问题，本申请实施例巧妙地提出了一种日志查询方案，通过获取日志查询请求，随后根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据，并生成包括目标日志数据的日志查询结果，最后输出日志查询结果。

因此，本申请实施例通过利用ClickHouse数据库的查询速度比较快的优势来进行日志数据的查询，从而能够提高查询效率，提升用户体验。

为了便于理解本申请实施例，首先在此对本申请实施例中的一些术语进行解释如下：

“ClickHouse”：它是一个用于联机分析处理(Online Analytical Processing，OLAP)的列式数据库管理系统，其解决了传统数据库在数据量较大情况下查询缓慢的问题。

例如，在单个日志查询请求所需查询日志数据的数据量比较大(例如，欲查询某个公司的网络日志，或者所需查询的数据量超过预设数据量等)的情况下，ClickHouse引擎在处理该类日志查询请求时每台服务器每秒最多可达十亿行，且写入速度也非常快，可达到50-200M/s。

请参见图1，图1示出了本申请实施例提供的一种应用场景的示意图。如图1所示的应用场景包括服务器110、采集装置120和ClickHouse数据库130。

应理解，服务器110可以为单台服务器。

还应理解，采集装置120的具体装置可根据实际需求来进行设置，只要保证采集装置120能够采集原始日志数据即可，本申请实施例并不局限于此。

例如，采集装置120可以为交换机，也可以为路由器等。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

具体地，采集装置120可采集内网里所有的原始日志数据，并向服务器110发送采集到的原始日志数据。其中，所有的原始日志数据可包括邮件相关数据和聊天相关数据等。

随后，服务器110可对接收到的原始日志数据进行第一预处理。随后，服务器110可将经第一预处理后的原始日志数据存储到ClickHouse数据库130中。其中，ClickHouse数据库130可以是按照不同的时间粒度进行分表存储的。

应理解，第一预处理所包含的具体操作可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，第一预处理可包括筛选操作，也可包括排序操作，也可包括聚合操作，也可包括脱敏操作等。

这里需要说明的是，由于ClickHouse数据库130可以是按照不同的时间粒度来进行分表存储的，服务器110可将经第一预处理后的原始日志数据存储到其对应的时间粒度的表格中。

可选地，在ClickHouse数据库130可包括时间粒度为分钟对应的分钟表格、时间粒度为小时对应的小时表格、时间粒度为天对应的天表格、时间粒度为周对应的周表格、时间粒度为月对应的月表格和时间粒度为年对应的年表格等情况下，服务器110可分析当前待存储的原始日志数据对应的时间粒度，并将其存储到对应的时间粒度的某个具体表格中。

此外，可按照当前对象(例如，公司等)的数据量来确定具体的存储方式。

可选地，在当前对象每天的数据量大于等于预设数据量的情况下，则可选择以“天”为粒度来进行分表存储；在当前对象每天的数据量小于预设数据量的情况下，则可选择以“月”为粒度来进行分表存储。

应理解，预设数据量的具体值可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，对于第一公司来说，第一公司每天产生的数据量差不多有1000万条，且每天的数据量大于预设数据量(例如，50万或者100万等)，则那么该第一公司的数据存储方式可以选择以“天”为粒度来进行分表存储，且每个表的名称可以是由具体天数和对象的标识构成的(例如，某个天表格的名称为Y20200801，且其存储有2020年8月1日这一天的数据，其中，Y为存储数据对应的对象的标识；另外一个天表格的名称为B20200802，且其存储有2020年8月2日这一天的数据，其中，B为存储数据对应的对象的标识)。

再例如，对于第二公司来说，第二公司每天产生的数据量大约只有50万条，一个月大约1500万条，且每天的数据量小于预设数据量(例如，50万等)，那么该第二公司的数据存储方式可以选择以“月”为粒度来进行分表存储，且每个表的名称可以是具体月数(例如，某个月表格的名称为Z202008，且其存储有2020年8月的数据，其中，Z为存储数据对应的对象的标识；另外一个月表格的名称为N202009，且其存储有2020年9月的数据，其中，N为存储数据对应的对象的标识)。

此外，这里需要说明的是，对于同一对象来说，该对象可采用同一粒度的分表存储方式(例如，对于某一个公司来说，它只能以“天”或者“月”为粒度来进行分表存储)。

另外，这里需要说明的是，虽然上面以具体天数和对象的标识构成的表格名称(即不同的对象的数据存储到不同的表格中)为例来进行描述的，但本领域的技术人员应当理解，其还可只以具体天数为表格的名称，从而ClickHouse数据库130可存储有内网对应的时间的数据(即不同对象的数据可存储到同一表格内)，本申请实施例并不局限于此。

此外，在服务器110获取到日志查询请求的情况下，服务器110可根据日志查询请求，从ClickHouse数据库130中查找出与日志查询请求匹配的目标日志数据，并生成包括目标日志数据的日志查询结果。随后，服务器110可输出日志查询结果，以供用户浏览。

需要说明的是，本申请实施例提供的日志查询方案还可以进一步拓展到其他合适的应用场景中，而不限于图1所示的应用场景。

请参见图2，图2示出了本申请实施例提供的一种日志查询方法的流程图。如图2所示的日志查询方法可应用于单台服务器(为了便于描述，下文中以服务器来进行描述)，该日志查询方法包括：

步骤S210，服务器获取日志查询请求。

应理解，日志查询请求所包含的具体内容可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，日志查询请求可包括查询时间段和查询条件。其中，查询时间段可以是欲查询日志数据的时间范围；查询条件可以是对查询时间段对应的所有日志数据进行处理(例如，排序、过滤或者筛选等)的条件。

例如，查询时间段可以是2020年5月。

再例如，查询条件可以是排序，也可以是查询某个设备相关的数据，也可以是查询某个用户相关的数据等。

这里需要说明的是，对于查询时间段和查询条件来说，用户可根据实际需求来进行设置，本申请实施例并不局限于此。

再例如，日志查询请求除了查询时间段和查询条件之外，还可包括接口地址等。其中，接口地址可以是指与ClickHouse数据库相关的接口的地址，从而服务器能够通过该接口地址对应的接口进行日志的查询。

还应理解，服务器获取日志查询请求的具体方式也可根据实际需求来进行设置。

例如，服务器可接收客户端发送的日志查询请求，也可通过客户端上的浏览器来获取日志查询请求，也可以是定时触发的日志查询请求等。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

具体地，由于日志查询页面可设置有查询时间的输入框、查询条件的输入框(例如，可选择通过高亮显示的方式来显示与需过滤类型相关的数据，从而后续用户可对高亮显示的日志数据进行过滤操作等)和导出目标日志数据的格式的选择框等，用户在点击提交之后，服务器可获取包含有用户设置的多项内容的日志查询请求。

步骤S220，服务器根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据。其中，日志查询请求可包括查询时间范围和查询条件。其中，查询条件可以是包含查询对象的相关查询语句。

应理解，ClickHouse数据库可包括至少一种表格，每种表格与一个时间粒度对应，且每种表格可对应有多个表格。

例如，ClickHouse数据库可包括与第一对象相关的天表格，也可包括与第二对象相关的月表格，也可以包括与第三对象相关的年表格等。

还应理解，时间粒度所对应的具体时间单位可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，时间粒度所对应的具体时间单位可以为分钟，也可以为小时，也可以为天，也可以为月，也可以年等。

再例如，在时间粒度所对应的具体时间单位为分钟的情况下，ClickHouse数据库可包括与分钟对应的分钟表格，且在ClickHouse数据库中，某对象一分钟产生的数据量可对应有一个分钟表格；在时间粒度所对应的具体时间单位为小时的情况下，ClickHouse数据库可包括与小时对应的小时表格，且在ClickHouse数据库中，另外一个对象一个小时产生的数据量可对应有一个小时表格；在时间粒度所对应的具体时间单位为天的情况下，ClickHouse数据库可包括与天对应的天表格，且在ClickHouse数据库中，另外一个对象一天产生的数据量可对应有一个天表格；在时间粒度所对应的具体时间单位为月的情况下，ClickHouse数据库可包括与月对应的月表格，且在ClickHouse数据库中，另外一个对象一个月产生的数据量可对应有一个月表格等。

还应理解，服务器根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据的具体过程可根据实际需求来进行设置，本申请实施例并不局限于此。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

可选地，由于服务器中可存储有多个表格，服务器可根据查询时间段(在M个表格存储有M个对象的数据的情况下，服务器可根据目标查询请求中的查询条件所包含的查询对象和查询时间段，M为正整数)，从多个表格中查找出与查询时间段匹配的目标表格(或者与查询时间段和查询对象匹配的目标表格)，即目标表格对应的时间段为查询时间段，从而能够大幅度缩小查找范围。以及，服务器还可根据日志查询请求中的查询条件，从目标表格中查找出与查询条件匹配的目标日志数据，从而由于无需对每个表格进行相关内容的查找，只需在目标表格中进行查找即可，进而能够提高日志查询效率。

例如，在查询时间段为2020年8月且查询条件是与第一查询对象的相关条件的情况下，服务器可基于上述查询时间段来查询出与第一查询对象相关的日志数据。

此外，由于可能会出现查询时间段为一个较长的时间段的情况，这里为了进一步提高日志查询效率，服务器可按照预设时间粒度，对查询时间段进行时间分割，以获得至少两个时间段，随后服务器可从所有表格中查找出与至少两个时间段中每个时间段匹配的目标表格。

例如，在查询时间段为2020年8月30日13点14分至2020年9月1日15点18分且查询条件是与第一查询对象的相关条件的情况下，可以“天”为粒度，将上述查询时间范围分为2020年8月30日13点14分至2020年8月30日23点59分、2020年8月31日0点0分至2020年8月31日23点59分以及2020年9月1日0点0分至2020年9月1日15点18分这三个时间段，以及服务器可分别从第一对象的8月对应的月表格和9月对应的月表格中查找出与上述三个时间段对应的日志数据。以及，在呈现相关日志数据时，可按照不同的时间段来进行呈现(例如，用户可从日期选择框中选择不同的时间段来显示不同时间段对应的数据)。

应理解，预设时间粒度对应的具体时间单位也可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，预设时间粒度对应的具体时间单位可以为分钟、小时、天、周、月和年中的至少一个。

此外，这里需要说明的是，服务器可先将所有时间段对应的表格(例如，在查询时间段为4个月，且每个月的时间段对应有一个月表格)进行汇总，然后再从汇总的表格中查找出目标日志数据，也可先从每个时间段对应的表格中查找日志数据，然后再将查找到的所有日志数据进行汇总，以获得目标日志数据，本申请实施例并不局限于此。

可选地，服务器可存储有记录历史查询记录(例如，对于第一对象来说，历史查询记录信息可以包括历史查询时间和历史查询结果)的表格，从而在服务器接收到新的日志查询请求的情况下，可将新的日志查询请求和记录历史查询记录的表格相匹配，从而可获得与新的日志查询请求关联度最高的历史查询记录，进而可根据关联度最高的历史查询记录来快速查找与新的日志查询请求匹配的目标日志数据，从而也能够提高查询效率。其中，与新的日志查询请求关联度最高的历史查询记录是指与新的日志查询请求的查询时间和查询对象最接近的历史查询记录。

例如，在服务器接收到新的日志查询请求为查询第一对象从2020年8月30日13点14分至2020年9月1日15点18分的日志数据的情况下，可将该新的日志查询请求和记录历史查询记录的表格相匹配，从而获得新的日志查询请求关联度最高的历史查询记录为查询第一对象从2020年8月29日0点0分至2020年9月1日15点18分的历史查询记录，随后可根据该关联度最高的历史查询记录来快速查找与新的日志查询请求匹配的目标日志数据，从而也能够减少查询范围，且无需遍历每个表格，进而能够提高查询效率。

此外，考虑到随着时间增加，可能会导致服务器的存储空间被历史查询记录占用，磁盘被占满引起的查询也会死掉的情况，服务器可统计所有历史查询记录中每条历史查询记录的被使用次数。

其中，服务器在确定当前历史查询记录的被使用次数大于等于预设次数的情况下，则保留当前历史查询记录；服务器在确定当前历史查询记录的被使用次数小于预设次数的情况下，则进一步确定当前历史查询记录的存储时间是否超过预设时间，若超过预设时间，则删除当前历史查询记录，若没有超过预设时间，则返回继续统计当前历史查询记录的使用次数。

也就是说，这里为了避免新存储的历史查询记录被马上删除的情况，只有在存储时间超过预设时间且使被使用次数小于预设次数的情况下，删除历史查询记录。

应理解，预设次数的具体次数和预设时间的具体时间均可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，不同的历史查询记录的预设次数可不同，也可相同。

步骤S230，服务器生成包括目标日志数据的日志查询结果。

具体地，服务器可对获取的目标日志数据进行第二预处理，随后再根据经过第二预处理后的目标日志数据生成日志数据查询结果。

应理解，第二预处理所包含的操作可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，第二预处理可包括格式转换(例如，时间格式的转换，可将其由具体时间转换为日志浏览界面能够显示的时间戳等)，也可包括生成表格。其中，表格是通过格式转换后的日志数据生成的。

步骤S240，服务器输出日志查询结果。

例如，服务器可向客户端发送日志查询结果，以便于客户端能够显示日志查询结果。

因此，本申请实施例通过利用ClickHouse数据库的查询速度比较快的优势来进行日志数据的查询，从而能够提高查询效率，提升用户体验。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

请参见图3，图3示出了本申请实施例提供的一种日志查询方法的具体流程图。如图3所示的日志查询方法包括：

步骤S310，通过服务器中的存储组件将获取的原始日志数据存储到ClickHouse数据库中。

应理解，存储组件的具体装置可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，存储组件可以为Java中的Stream接口。

这里需要说明的是，虽然图3中描述了步骤S310，但本领域的技术人员应当理解，在ClickHouse数据库中预先存储有与日志查询请求对应的日志数据的情况下，其可直接执行步骤S320，无需再执行步骤S310。

步骤S320，通过服务器中的日志组件获取日志查询请求。

这里需要说的是，对于本申请实施例中的日志组件来说，其可对应不同类型的日志(例如，病毒日志和告警日志等多个日志可共用一个日志组件)。此外，在需要添加新类型的日志的情况下，其无需再开发新日志组件，只需要将新类型的日志相关的参数(例如，其对应的ClickHouse数据库的接口等)导入到日志组件中即可，从而极大地方便了开发人员。

此外，本申请实施例还可实现完全自主的业务，开发人员能掌握日志审计的实现的全部技术细节，这在应对日趋增长的用户需求时更得心应手。

步骤S330，通过服务器中的搜索组件来从ClickHouse数据库中查找与日志查询请求对应的目标日志数据。

应理解，搜索组件的具体装置可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，搜索组件可以是Java中的RESTful接口。

步骤S340，通过服务器中的日志组件生成包括目标日志数据的日志查询结果，并输出日志查询结果。

应理解，上述日志查询方法仅是示例性的，本领域技术人员根据上述的方法可以进行各种变形，修改或变形之后的内容也在本申请保护范围内。

请参见图4，图4示出了本申请实施例提供的一种日志查询装置400的结构框图，应理解，该日志查询装置400能够执行上述方法实施例涉及的各个步骤，该日志查询装置400具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。该日志查询装置400包括至少一个能以软件或固件(firmware)的形式存储于存储器中或固化在日志查询装置400的操作系统(operating system，OS)中的软件功能模块。具体地，该日志查询装置400包括：

获取模块410，用于获取日志查询请求；查找模块420，用于根据日志查询请求，从ClickHouse数据库中查找与日志查询请求匹配的目标日志数据，并生成包括目标日志数据的日志查询结果；输出模块430，用于输出日志查询结果。

在一个可能的实施例中，ClickHouse数据库包括至少一种表格，每种表格与一个时间粒度对应。

在一个可能的实施例中，日志查询请求包括查询时间段和查询条件，查找模块420，包括：第一查找子模块(未示出)，用于根据查询时间段，从ClickHouse数据库的所有表格中查找与查询时间段匹配的目标表格；第二查找子模块(未示出)，用于从目标表格中查找出与查询条件匹配的目标日志数据。

在一个可能的实施例中，第一查找子模块，具体用于：按照预设时间粒度，对查询时间段进行时间分割，以获得至少两个时间段；从所有表格中查找与每个时间段匹配的目标表格。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。

本申请还提供一种电子设备，图5为本申请实施例提供的一种电子设备500的结构框图，如图5所示。电子设备500可以包括处理器510、通信接口520、存储器530和至少一个通信总线540。其中，通信总线540用于实现这些组件直接的连接通信。其中，本申请实施例中的通信接口520用于与其他设备进行信令或数据的通信。处理器510可以是一种集成电路芯片，具有信号的处理能力。上述的处理器510可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器510也可以是任何常规的处理器等。

存储器530可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。存储器530中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器510执行时，电子设备500可以执行上述方法实施例涉及的各个步骤。

电子设备500还可以包括存储控制器、输入输出单元、音频单元、显示单元。

所述存储器530、存储控制器、处理器510、外设接口、输入输出单元、音频单元、显示单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线540实现电性连接。所述处理器510用于执行存储器530中存储的可执行模块。并且，电子设备500用于执行下述方法：获取日志查询请求；根据所述日志查询请求，从ClickHouse数据库中查找与所述日志查询请求匹配的目标日志数据，并生成包括所述目标日志数据的日志查询结果；输出所述日志查询结果。

输入输出单元用于提供给用户输入数据实现用户与所述服务器(或本地终端)的交互。所述输入输出单元可以是，但不限于，鼠标和键盘等。

音频单元向用户提供音频接口，其可包括一个或多个麦克风、一个或者多个扬声器以及音频电路。

显示单元在所述电子设备与用户之间提供一个交互界面(例如用户操作界面)或用于显示图像数据给用户参考。在本实施例中，所述显示单元可以是液晶显示器或触控显示器。若为触控显示器，其可为支持单点和多点触控操作的电容式触控屏或电阻式触控屏等。支持单点和多点触控操作是指触控显示器能感应到来自该触控显示器上一个或多个位置处同时产生的触控操作，并将该感应到的触控操作交由处理器进行计算和处理。

可以理解，图5所示的结构仅为示意，所述电子设备500还可包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。图5中所示的各组件可以采用硬件、软件或其组合实现。

本申请还提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行方法实施例所述的方法。

本申请还提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行方法实施例所述的方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。

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

本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

Claims (10)

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

获取日志查询请求；

根据所述日志查询请求，从ClickHouse数据库中查找与所述日志查询请求匹配的目标日志数据，并生成包括所述目标日志数据的日志查询结果；

输出所述日志查询结果。

2.根据权利要求1所述的日志查询方法，其特征在于，所述ClickHouse数据库包括至少一种表格，每种所述表格与一个时间粒度对应。

3.根据权利要求2所述的日志查询方法，其特征在于，所述日志查询请求包括查询时间段和查询条件，所述根据所述日志查询请求，从ClickHouse数据库中查找与所述日志查询请求匹配的目标日志数据，包括：

根据所述查询时间段，从所述ClickHouse数据库的所有表格中查找与所述查询时间段匹配的目标表格；

从所述目标表格中查找出与所述查询条件匹配的目标日志数据。

4.根据权利要求3所述的日志查询方法，其特征在于，所述根据所述查询时间段，从所述ClickHouse数据库的所有表格中查找与所述查询时间段匹配的目标表格，包括：

按照预设时间粒度，对所述查询时间段进行时间分割，以获得至少两个时间段；

从所述所有表格中查找与每个所述时间段匹配的目标表格。

5.一种日志查询装置，其特征在于，包括：

获取模块，用于获取日志查询请求；

查找模块，用于根据所述日志查询请求，从ClickHouse数据库中查找与所述日志查询请求匹配的目标日志数据，并生成包括所述目标日志数据的日志查询结果；

输出模块，用于输出所述日志查询结果。

6.根据权利要求5所述的日志查询装置，其特征在于，所述ClickHouse数据库包括至少一种表格，每种所述表格与一个时间粒度对应。

7.根据权利要求6所述的日志查询装置，其特征在于，所述日志查询请求包括查询时间段和查询条件，所述查找模块包括：

第一查找子模块，用于根据所述查询时间段，从所述ClickHouse数据库的所有表格中查找与所述查询时间段匹配的目标表格；

第二查找子模块，用于从所述目标表格中查找出与所述查询条件匹配的目标日志数据。

8.根据权利要求7所述的日志查询装置，其特征在于，所述第一查找子模块，具体用于：按照预设时间粒度，对所述查询时间段进行时间分割，以获得至少两个时间段；从所述所有表格中查找与每个所述时间段匹配的目标表格。

9.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1-4任一所述的日志查询方法。

10.一种电子设备，其特征在于，所述电子设备包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1-4任一所述的日志查询方法。

Images