具体实施方式

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

需要说明的是，本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请实施例的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

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

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。为了便于理解本申请实施例上述的技术方案及其产生的技术效果，本申请实施例首先对于相关专业名词进行解释：

Bitcask：是一个日志型、基于哈希表结构的键值对存储模型。日志型数据存储模型所有写操作只追加而不修改老的数据，在Bitcask模型中，数据文件以日志型只增不减的写入文件，而文件有一定的大小限制，当文件大小增加到相应的限制时，就会产生一个新的文件，老的文件将只读不写。在任意时间点，只有一个文件是可写的，在Bitcask模型中称其为Active Data File，而其他的已经达到限制大小的文件，称为Older Data File。

RocksDB：使用一套日志结构的KV存储引擎。为快速而又低延迟的存储设

备进行优化处理，最大限度地发挥读写性能。可以适合于多种不同工作量类型。既提供了一些基础的操作，例如打开和关闭数据库，也提供了高级的数据库操作，比如合并、压缩过滤，也提供了读写支持。

ElasticSearch：ElasticSearch是一种分布式存储搜索引。ElasticSearch的数据存储模式单一，数据存储成本也较大。

QPS：Queries Per Second，是每秒查询率,是一台设备每秒能够相应的查询次数，是对一个设备在规定时间内所处理流量多少的衡量标准,即每秒的响应请求数，也即是最大吞吐能力。

相关技术中为了实现海量日志数据的聚合，通常可以将日志记录写入到ElasticSearch，由ElasticSearch对日志进行存储以及建立索引(比如通过分词的方式建倒排列表)，在查询时，即可根据关键词查找倒排列表，从而定位到该关键词对应的日志。但是，由于对日志记录做分词、建倒排较为消耗资源，因此，造成了机器资源的过高消耗，并且随着日志记录的数据量增大，这一问题日益突出。

为了降低海量日志记录的聚合造成的资源消耗，本申请实施例提供日志数据处理方法、系统、存储介质及电子设备。

请参阅图1，图1是本说明书实施例提供的日志数据处理方法的一种可行的实施框架示意图，如图1所示，该实施框架可以至少包括业务处理设备01、日志记录设备02、日志第一聚合设备03、日志第二聚合设备04和分布式文件系统05，每一业务处理设备01对应一个日志记录设备02。其中，业务处理设备01用于为用户提供对应的业务，比如消息查询业务、账户查询业务、多媒体业务等，本公开实施例并不对具体的业务内容进行限制。并且，对于每一业务，可以运行在一个或多个业务处理设备01中。在一个实施例中，根据业务标识，可以唯一确定运行该业务标识指向的业务的一个或多个业务处理设备01。业务处理设备01可以与用户终端进行交互从而提供上述业务，用户终端包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端等。本申请并不对业务处理设备01所能够提供的业务进行限定，这些业务可以为各种场景提供对应的业务，比如消息交互、多媒体应用、智慧交通或者生活等场景，智慧交通场景可以包括行程分享、车辆加油、车辆充电等业务，生活场景包括旅游或者听书等业务。在一个实施例中，本申请可以应用于自动驾驶领域，对自动驾驶领域相关技术方案生成的日志进行管理。自动驾驶领域通常需要应用到地图处理、环境感知、行为决策、路径规划、运动控制等技术，这一领域有着广泛的应用前景。地图处理中的地图可以包括矢量地图数据或影像地图数据，其中矢量地图数据是以矢量格式存储，影像地图数据以图片格式存储，通过对地图进行数据处理，可以使得其为自动驾驶领域的相关技术提供支持，并且产生对应的日志记录。

对于每个业务处理设备01，设置唯一与其对应的日志记录设备02。该日志记录设备02用于生成该业务处理设备01的日志记录，将该日志记录分批次存储在分布式文件系统05中与该业务处理设备01相对应的日志文件中，并且基于日志记录产生的时间为该日志文件生成第二索引文件，并且在分布式文件系统05中将日志文件与该第二索引文件相关联。

日志第一聚合设备03可以分阶段对于各日志记录设备02产生的日志进行基于业务请求标识的聚合，得到第一索引临时文件，并由日志第二聚合设备04对各第一索引临时文件进行基于业务请求标识的聚合，得到第一索引文件，并且将该第一索引文件存储在分布式文件系统05之中。分布式文件系统05在存储有日志文件、第二索引文件和第一索引文件的情况下，可以支持高效的日志记录查询服务。

上述实施框架还包括查询请求交互设备06和至少一个查询执行设备07。该查询请求交互设备作为与用户交互的接口，可以用于接收日志记录查询请求以及反馈日志查询结果。若存在多个查询执行设备07，则该查询请求交互设备通过与各查询执行设备07交互，可以为用户提供并发的日志查询服务。对于每一查询执行设备07，可以通过与分布式文件系统05的交互，得到日志查询结果，并将该日志查询结果反馈至查询请求交互设备06。

本申请实施例中提及的上述任一设备或系统可以为移动终端、台式电脑、平板电脑、笔记本电脑、数字助理、智能可穿戴设备等各种可以具备通信能力和数据处理能力的实体设备，也可以包括运行于实体设备中的软体。当然，还可以是服务器，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器，本申请在此不做限制。

本申请实施例所提供的方法还可以涉及区块链，即本申请实施例提供的方法可以基于区块链实现，或者本申请实施例提供的方法中涉及到的数据可以基于区块链存储，或本申请实施例中提供的方法的执行主体可以位于区块链中。区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

以下介绍本申请实施例的一种日志数据处理方法，图2示出了本申请实施例提供的一种日志数据处理方法的流程示意图，本申请实施例提供了如实施例或流程图上述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)，上述方法可以包括：

S101.基于目标设备中产生的日志记录，得到上述目标设备对应的日志文件，上述目标设备为运行目标业务进程的任一上述业务处理设备，上述目标业务进程为运行有目标业务的任一进程，每一上述日志记录均包括业务请求标识。本申请实施例中的方法可以应用于日志数据处理系统中，该日志数据处理系统可以包括多个业务处理设备，而多个业务处理设备可以处理多种业务，并且每个业务可以运行在多个业务处理设备之上。举例来说，可以提供账户处理业务10和消息处理业务20，账户处理业务10运行在业务处理设备11和业务处理设备12中，而消息处理业务20运行在业务处理设备21和业务处理设备22中，目标业务可以为账户处理业务和消息处理业务中的任一业务，以目标业务为账户处理业务为例，则目标业务进程运行在业务处理设备11和业务处理设备12中。

根据上述说明可知，目标设备可以为上述业务处理设备11、业务处理设备12、业务处理设备21和业务处理设备22中的任一设备。也就是说，针对某个具体运行某种业务的业务处理设备，都会对应得到日志文件。本公开实施例中日志文件被存储在分布式业务系统中，而不同业务处理设备的日志被写入自己独占的日志文件，相互间的数据写入过程无竞争，从而显著提升了日志文件的写入效率。

在一个实施例中，为了降低日志数据处理系统的耦合，并且提升日志文件的写入速度，可以为每个业务处理设备设置对应的日志记录设备。每一上述日志记录设备将对应的业务处理设备产生的日志记录写入上述分布式文件系统内上述目标设备对应的日志文件中。

本申请实施例中，每个日志记录均包括业务请求标识(callid)。唯一标识一次用户请求，每条日志记录中都会携带callid信息。在每个业务请求的处理过程中，可能会导致关联的业务处理设备产生对应的日志记录。举个例子，用户账户A请求向用户账户B发送消息，这一请求的业务请求标识为(100001)，为了执行该请求，业务处理设备11和业务处理设备22都执行了相应的操作，从而均对应产生了日志记录，并且产生的日志记录中都携带业务请求标识(100001)。

S102.对各上述业务处理设备产生的日志记录进行基于业务请求标识的聚合，得到第一索引文件，上述第一索引文件用于记录携带有目标业务请求标识的日志记录的存储位置，上述目标业务请求标识为各上述业务处理设备产生的日志记录中的任一业务请求标识。

本申请实施例中，分布式文件系统中存储每个业务处理设备对应的日志文件，每一日志文件中的每一日志记录均携带有业务请求标识。为了提升基于业务请求标识查询日志记录的速度，可以针对业务请求标识生成全局索引，该全局索引在本申请实施例中被称为第一索引文件。该第一索引文件可以以键值对的形式进行数据组织，其中，键对应于某个业务请求标识(目标业务请求标识)，值对应于携带有该目标业务请求标识的各日志记录在分布式文件系统中的存储位置。依然沿用上述举例，业务请求标识100001指向的业务请求在被处理的过程中，业务处理设备11产生的日志记录100被存储在日志文件A中，业务处理设备22产生的日志记录200被存储在日志文件B中，则根据业务请求标识100001查询第一索引文件，可以得到日志记录100和日志记录200在分布式文件系统中的存储位置，从而可以快速定位携带有相同业务请求标识的日志记录，显著提升日志记录查询速度。

第一索引文件的生成过程可以被理解为一种聚合过程，为了提升上述聚合过程的聚合速度，本申请实施例中可以将这一聚合过程分为两步，一步为模块间聚合，一步为全局聚合。具体来说，请参阅图3，图3是本说明书实施例提供的第一索引文件生成方法流程示意图，包括：

S1021.对第二目标时间区间内各上述业务处理设备产生的日志记录进行基于业务请求标识的聚合，得到第一索引临时文件，上述第二目标时间区间为根据第二时间分段策略确定出的任一时间区间。

本公开实施例并不对第二时间分段策略进行限定，示例性的，可以以5分钟的时间间隔进行时间分段。比如，每五分钟执行一次步骤S1021。

举例来说，在时刻T2触发执行步骤S1021,则可以对时间区间[T1，T2]内各业务处理设备产生的日志记录进行基于业务请求标识的聚合，其中T1为T2的前五分钟，这五分钟内各业务处理设备产生的日志记录都可以参与到基于业务请求标识的聚合，携带有相同的业务请求标识的日志记录被聚合起来。根据该业务请求标识，即可确定对应的日志记录在分布式文件系统的存储位置。这一步骤专注于对各业务处理设备产生的记录的横向聚合，本申请实施例中称其为模块间聚合。通过这一模块间聚合，可以将QPS减少到原来的千分之一的量级。

步骤S1021可以由图1中的日志第一聚合设备03实施，上述日志第一聚合设备03分时间段对各上述业务处理设备产生的日志记录进行基于业务请求标识的聚合，得到每一时间段对应的第一临时索引文件。

S1022.对各上述第一索引临时文件进行基于业务请求标识的聚合，得到上述第一索引文件。

上述日志第一聚合设备03还可以将每一上述第一临时索引文件发送至日志第二聚合设备04，也就是说，步骤S1021的执行结果就是产生多个第一索引临时文件，而日志第二聚合设备04可以对于各第一索引临时文件再次进行基于业务请求标识的聚合，聚合原理上文已有示例，在此不再赘述。由于每一第一临时索引文件均包含特定时间段内各个业务处理设备产生的日志记录的相关信息，因此，本申请实施例将对第一临时索引文件的聚合过程称为全网聚合，通过全网聚合，可以达到这样一种效果，通过一次IO操作，可以读取与某个业务请求标识相关联的全部日志记录的存储位置。

具体来说，上述日志第二聚合设备04对各第一临时索引文件进行基于业务请求标识的聚合，得到第一索引文件，以及将上述第一索引文件写入上述分布式文件系统05。

综上可知，本申请实施例可以在分布式文件系统中存储每个业务处理设备对应的日志文件，从而使得日志文件本身产生的目录结构就相当于一个快速区分不同设备的索引，提升日志记录查询效率，并且通过基于业务请求标识的聚合生成第一索引文件，从而可以通过单次IO操作即可定位全部关联日志记录的存储位置，从而进一步提升了日志记录查询效率。

通过考虑基于业务请求标识进行日志查询的场景，本申请实施例中设计了第一索引文件，进一步地，本申请实施例还考虑到另一常见的日志查询场景，即基于业务、时间和/或关键字进行日志查询，为了提升这一日志查询场景中的日志查询效率，本申请实施例还可以包括下述步骤：

S201.对上述目标设备中产生的日志记录进行基于时间的聚合，得到上述目标设备的第二索引文件，上述第二索引文件用于记录在第一目标时间区间内产生的日志记录的存储位置，上述第一目标时间区间为根据第一时间分段策略确定出的任一时间区间。

对于每个业务处理设备产生的日志记录，本申请实施例都可以为其生成对应的第二索引文件，也就是说，第二索引文件与该业务处理设备对应的日志记录一一对应，可以用于记录该日志文件中的日志记录的产生时间以及该日志记录的存储位置的对应关系。

本申请实施例并不限定第一时间分段策略的具体内容，比如，可以每三分钟进行一次分段。也就是说，可以按照每个三分钟进行分段的策略进行时间划分得到时间区间，每个时间区间都有三分钟的长度，对于其中的任一时间区间(第一目标时间区间)，第二索引文件记录该时间区间内目标设备产生的日志记录在分布式文件系统中的存储位置。

S202.关联上述第二索引文件以及上述日志文件。

由于第二索引文件记录是与日志文件一一对应的，则可以在分布式文件系统中将第二索引文件记录与日志文件相关联，本申请实施例并不限定具体的关联方式，具体来说，可以将第二索引文件以及上述日志文件存储在相同的目录下。示例性的，存在10个业务处理设备，则分布式系统中的目录中可以包括10个位置，每个位置对应一个业务处理设备，该位置下存储有该业务处理设备对应的日志文件以及第二索引文件。

在一个实施例中，为了提升日志文件的写效率，还可以执行步骤S301：将上述目标设备中产生的日志记录存储在上述目标设备对应的缓存中；在上述缓存中的日志记录的数据量达到预设阈值的情况下，将上述缓存中的日志记录写入上述日志文件。

示例性的，可以由目标设备对应的日志记录设备使用缓冲队列缓存日志记录，累积8MB数据后批量顺序写入对应的日志文件中，相应的，这种操作可以将写QPS降低为原本的4万分之一，当然，也可以累计更多数据后进行批量写入，本申请对于这一预设阈值的大小不做限定。进一步地，该目标设备对应的日志记录设备还可以在上述分布式文件系统中将上述日志文件与上述日志文件对应的第二索引文件相关联。

相关技术中是将日志数据写入到ElasticSearch，由ElasticSearch对日志数据建立倒排，然后根据建立好的倒排表进行日志数据的定位。但是这一索引建立方式需要对日志数据的内容进行分词处理，并且倒排的建立十分耗费资源，从而导致日志数据的入库需要消耗大量的机器资源，并且基于倒排表进行日志数据的定位的效率也较低，无法支持丰富的检索形式。为了解决相关技术中的上述问题，本申请实施例提供了日志数据的处理方法。请参阅图4，图4是本说明书实施例提供的日志数据处理在一个具体场景中的实施过程示意图。图4中的模块相当于该场景中的目标设备，LogAgent为该业务处理设备(目标设备)对应的日志记录设备，LogMergeSvr为该场景中的日志第一聚合设备，LogIdxSvr为该场景中的日志第二聚合设备，QuerySvr为该场景中的查询执行设备。LogAgent聚合写callid索引对应于步骤S301，LogMergeSvr中基于bitcask聚合callid索引对应于步骤S1021,LogIdxSvr中基于Rocksdb聚合callid索引对应于步骤S1022。通过执行步骤S301可以将写QPS减少到万分之一的量级，通过执行步骤S1021-S1022可以经写QPS减少到千万分之一的量级。本申请实施例中步骤S1021、S1022和步骤S301均执行了聚合操作，也就是说，在图4示出的实施过程中，本申请实施例一共执行了三重聚合，通过上述三重聚合可以使用较少的机器资源为日志建立可以支持丰富的检索形式的索引，降低日志入库成本，提升日志查询速度和智能化程度。

至此，分布式文件系统中存储有每个业务处理设备对应的日志文件，与日志文件对应的第二索引文件，并且该分布式文件系统中还存储有第一索引文件，在存在上述数据的基础上，本申请实施例还提供了基于上述数据快速进行日志记录查询的方法。该方法可以由图1中查询执行设备07和查询请求交互设备06参与实施，包括：

S401.上述查询执行设备根据查询信息生成日志过滤条件，上述查询信息包括业务标识、时间信息、关键字信息、业务请求标识中的至少一种，将上述日志过滤条件发送至上述分布式文件系统。

请参考图5，其示出相关技术中的日志记录查询框架示意图。图5中可知，相关技术中在QuerySvr(查询执行设备)中进行日志的模糊匹配，匹配的要素可以根据查询信息得到，为了进行模糊匹配，QuerySvr需要将大量相关的日志记录以及相关的索引数据从分布式文件系统中读入QuerySvr，这一过程的重IO操作耗费大量的资源和时间。

为了降低上述重IO操作的资源消耗和时间消耗，本申请实施例中将日志模糊匹配的操作下沉到分布式文件系统中，查询执行设备不再需要进行日志模糊匹配操作，只需生成日志过滤条件即可，该日志过滤条件用于在分布式文件系统中进行日志模糊匹配。

S402.上述分布式文件系统根据上述日志过滤条件进行日志记录的过滤，得到查询结果。

分布式文件系统根据上述日志过滤条件可以执行日志模糊匹配，从而直接得到查询结果，并且将上述查询结果反馈至查询执行设备，从而不再需要执行上述重IO操作，减少了资源和时间的损耗。

在一个实施例中，上述日志数据处理系统还包括查询请求交互设备，上述方法还包括：

S501.上述查询请求交互设备获取日志查询请求，上述日志查询请求包括业务标识、时间信息、关键字信息、业务请求标识中的至少一种。

本公开实施例中查询请求交互设备可以为与用户进行交互的接口，本申请实施例中可以基于业务标识、时间信息、关键字信息、业务请求标识中的至少一种及其组合的形式为用户提供多种的日志查询服务。

S502.根据并发策略确定目标查询执行设备，上述目标查询执行设备为上述日志数据处理系统的多个查询执行设备中的任一查询执行设备。

本申请实施例中并不限定该并发策略的具体内容，可以参考相关技术，示例性的，可以基于负载均衡策略，就近分配策略等进行目标查询执行设备的确定。

S503.将上述日志查询请求路由至上述目标查询执行设备。

目标查询执行设备进行日志查询的过程可以参考前文，在此不再赘述。目标查询执行设备还可以将查询到的日志记录直接反馈或整合后反馈至查询请求交互设备，以使得查询请求交互设备将其反馈至用户。

本申请实施例中每个业务处理设备在分布式文件系统中拥有独占的日志文件，可以通过业务处理设备的标识进行区分，本申请并不对这一标识进行限定，示例性的，其可以为MAC标识或者IP标识。进一步地，本申请实施例中每个业务处理设备对应的日志文件可以被进行分片记录，从而进一步提升查询效率。举例来说，每片可以记录某个小时内的业务处理设备产生的日志记录，也就是说每片日志文件均是小时粒度日志文件。通过业务标识，可以定位该业务标识下的全部业务处理设备，并且快速定位相关的日志文件。该日志文件可以为单个的日志文件或者分片记录的日志文件。

在一些实施例中，可以基于时间信息结合第二索引文件进行日志的查询。示例性的时间信息为2021-8-2015:03，而第二索引文件中相关的记录为[2021-8-2015:00，2021-8-2015:05]，[DB10008-DB10010],则DB10008-DB10010对应的存储地址中的日志记录为2021-8-2015:00至2021-8-2015:05生成的日志记录，在DB10008-DB10010中存储的日志记录中查找可以精准定位2021-8-2015:03产生的日志记录，显然，基于第二索引可以快速进行日志记录的查询。

根据前文可知，第一索引文件是基于业务请求标识聚合得到的，基于第一索引文件即可快速确定与业务请求标识相关的日志记录在分布式文件系统中的存储地址，从而快速定位要查找的日志记录。

对于关键字查询，可以参考相关技术，本申请实施例不做赘述。在一些实施例中，可以将基于业务标识、时间信息、业务请求标识中的任意一项及其组合得到的日志记录反馈至查询执行设备，由查询执行设备基于上述关键字进行日志记录的匹配，得到查询结果。并且上述查询执行设备还可以对于查询结果进行整合或者聚合等处理，并将处理结果反馈至用户。

显而易见，本申请实施例可以支持基于业务标识、时间信息、关键字信息、业务请求标识中的任意一项及其组合进行快速的日志记录查询，具体操作在此不再赘述。

请参考图6，其示出本申请实施例中的日志记录查询框架示意图。每个QuerySvr可以支持进行机器粒度的日志查询，通过生成日志过滤条件，可以将日志模糊匹配下沉到分布式文件系统中执行，分布式文件系统通过自身存储的日志文件、第一索引文件和第二索引文件快速匹配得到查询结果，并将该结果反馈QuerySvr，从而完成并发的日志查询。

请参考图7，其示出本申请实施例中的日志记录数据处理框架示意图。本申请实施例中包括入库和查询两部分，入库是指各将业务处理设备(模块)产生的日志记录以及相应的索引存储在分布式文件系统中的过程，查询是指在分布式文件系统中查询到日志记录的过程。对于每个业务处理设备，对应设置一个日志记录设备(LogAgent)，LogAgent自身可以将对应的模块产生的日志记录分批次写入分布式文件系统，生成对应的第二索引文件。而各个LogAgent均与LogMergeSvr交互进行模块间聚合，LogIdxSvr进行全网聚合，聚合过程可以参考前文，在此不做赘述。

在得到日志记录、第一索引文件以及第二索引文件的基础上，可以进行日志记录的快速查询，该查询过程也可以参考前文，在此不做赘述。

本申请实施例中在分布式文件系统中写入日志文件、第一索引文件和第二索引文件的资源消耗较小，仅仅利用少量机器资源即可实现，机器成本仅仅相当于相关技术中使用ElasticSearch的方案的十分之一，并且基于在分布式文件系统中的日志文件、第一索引文件和第二索引文件可以支持快速的日志记录查询，实现海量日志记录秒级入库、秒级可查，这在日志记录数据量日益庞大的现状下取得了极大优势效果。

本申请实施例还公开了日志数据处理系统，如图8所示，上述系统包括多个业务处理设备，上述系统包括：

日志文件处理模块10，用于基于目标设备中产生的日志记录，得到上述目标设备对应的日志文件，上述目标设备为运行目标业务进程的任一上述业务处理设备，上述目标业务进程为运行有目标业务的任一进程，每一上述日志记录均包括业务请求标识；

第一索引文件获取模块20，用于对各上述业务处理设备产生的日志记录进行基于业务请求标识的聚合，得到第一索引文件，上述第一索引文件用于记录携带有目标业务请求标识的日志记录的存储位置，上述目标业务请求标识为各上述业务处理设备产生的日志记录中的任一业务请求标识。

在一个实施例中，上述系统还包括第二索引文件获取模块，用于执行下述操作：对上述目标设备中产生的日志记录进行基于时间的聚合，得到上述目标设备的第二索引文件，上述第二索引文件用于记录在第一目标时间区间内产生的日志记录的存储位置，上述第一目标时间区间为根据第一时间分段策略确定出的任一时间区间；关联上述第二索引文件以及上述日志文件。在一个实施例中，上述第一索引文件获取模块20，用于执行下述操作：对第二目标时间区间内各上述业务处理设备产生的日志记录进行基于业务请求标识的聚合，得到第一索引临时文件，上述第二目标时间区间为根据第二时间分段策略确定出的任一时间区间；

对各上述第一索引临时文件进行基于业务请求标识的聚合，得到上述第一索引文件。

在一个实施例中，上述日志文件处理模块用于执行下述操作：

将上述目标设备中产生的日志记录存储在上述目标设备对应的缓存中；

在上述缓存中的日志记录的数据量达到预设阈值的情况下，将上述缓存中的日志记录写入上述日志文件。

在一个实施例中，上述日志数据处理系统还包括日志记录设备、日志第一聚合设备、日志第二聚合设备和分布式文件系统，每一业务处理设备对应一个日志记录设备，其中，每一上述日志记录设备用于将对应的业务处理设备产生的日志记录写入上述分布式文件系统内上述目标设备对应的日志文件中，以及在上述分布式文件系统中将上述日志文件与上述日志文件对应的第二索引文件相关联；

上述日志第一聚合设备用于分时间段对各上述业务处理设备产生的日志记录进行基于业务请求标识的聚合，得到每一时间段对应的第一索引临时文件，以及将每一上述第一临时索引文件发送至日志第二聚合设备；

上述日志第二聚合设备用于对各第一临时索引文件进行基于业务请求标识的聚合，得到第一索引文件，以及将上述第一索引文件写入上述分布式文件系统。

在一个实施例中，上述日志数据处理系统还包括查询执行设备，其中，上述查询执行设备用于根据查询信息生成日志过滤条件，上述查询信息包括业务标识、时间信息、关键字信息、业务请求标识中的至少一种，将上述日志过滤条件发送至上述分布式文件系统；

上述分布式文件系统用于根据上述日志过滤条件进行日志记录的过滤，得到查询结果。在一个实施例中，上述日志数据处理系统还包括查询请求交互设备，其中，

上述查询请求交互设备用于获取日志查询请求，上述日志查询请求包括业务标识、时间信息、关键字信息、业务请求标识中的至少一种；根据并发策略确定目标查询执行设备，上述目标查询执行设备为上述日志数据处理系统的多个查询执行设备中的任一查询执行设备；将上述日志查询请求路由至上述目标查询执行设备。

具体地，本申请实施例公开一种日志数据处理系统与上述对应的方法实施例均基于相同发明构思。详情请参见方法实施例，在此不再赘述。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述一种日志数据处理方法。

本申请实施例还提供了一种计算机可读存储介质，上述计算机可读存储介质可以存储有多条指令。上述指令可以适于由处理器加载并执行本申请实施例上述的一种日志数据处理方法。

进一步地，图9示出了一种用于实现本申请实施例所提供的方法的设备的硬件结构示意图，上述设备可以参与构成或包含本申请实施例所提供的装置或系统。如图9所示，设备10可以包括一个或多个(图中采用102a、102b，……，102n来示出)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图9所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备10还可包括比图9中所示更多或者更少的组件，或者具有与图9所示不同的配置。

应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备10(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中上述的方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种日志数据处理方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至设备10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与设备10(或移动设备)的用户界面进行交互。

需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本申请实施例特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

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

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，上述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上上述仅为本申请实施例的较佳实施例，并不用以限制本申请实施例，凡在本申请实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请实施例的保护范围之内。