CN111290910B - 日志处理方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请公开了一种日志处理方法、装置、服务器及存储介质，该日志处理方法包括：获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据；获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据；根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果；根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。本方法可以实现对关联性的日志文件的处理。

Description

日志处理方法、装置、服务器及存储介质

技术领域

本申请涉及数据处理技术领域，更具体地，涉及一种日志处理方法、装置、服务器及存储介质。

背景技术

随着业务需求的发展，出现了很多依赖于日志数据的业务场景，例如跟踪日志源的运行状态的业务场景，定位日志源中异常点的业务场景，构建搜索引擎的业务场景，以及更新本地日志文件的业务场景，等等。其中，对日志数据的处理通常依靠业务系统进行，业务系统通常被写入有相关判断逻辑，来实时处理日志数据，例如系统实时在线用户，业务系统会维护一个值来反应在线用户数量。但是，业务系统难以实时的处理具有关联性的日志数据。

发明内容

鉴于上述问题，本申请提出了一种日志处理方法、装置、服务器及存储介质。

第一方面，本申请实施例提供了一种日志处理方法，所述方法包括：获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据；获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据；根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果；根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。

第二方面，本申请实施例提供了一种日志处理装置，所述第一获取模块用于获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据；所述第二获取模块用于获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据；所述数据处理模块用于根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果；所述日志生成模块用于根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。

第三方面，本申请实施例提供了一种服务器，包括：一个或多个处理器；存储器；一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行上述第一方面提供的日志处理方法。

第四方面，本申请实施例提供了一种计算机可读取存储介质，所述计算机可读取存储介质中存储有程序代码，所述程序代码可被处理器调用执行上述第一方面提供的日志处理方法。

本申请提供的方案，通过获取目标用户的第一日志文件，该第一日志文件包括当前业务的业务数据，获取前一次记录的该目标用户的第二日志文件，该第二日志文件至少包括历史业务数据，根据当前业务的业务数据以及当前业务的业务数据，生成业务处理结果，然后根据业务处理结果以及第一日志文件，生成第三日志文件并将第三日志文件进行存储。可以实现在实时处理与历史日志数据具有关联性的日志时，能够从前一次记录的日志文件中获取到历史业务数据，并进行日志数据的处理，从而实现对关联性的日志文件的处理。

附图说明

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

图1示出了根据本申请一个实施例的方法流程图。

图2示出了根据本申请另一个实施例的日志处理方法流程图。

图3示出了根据本申请又一个实施例的日志处理方法流程图。

图4示出了根据本申请一个实施例的日志处理装置的一种框图。

图5示出了本申请一个实施例提供的日志处理装置中日志生成模块的框图。

图6是本申请实施例的用于执行根据本申请实施例的日志处理方法的服务器的框图。

图7是本申请实施例的用于保存或者携带实现根据本申请实施例的日志处理方法的程序代码的存储单元。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

日志在计算机领域是一个较为宽泛的概念，任何应用系统都可能产生日志数据。日志数据实际上是一种按照时间顺序存储的事件或行为的记录，日志数据通常包括事件主体、发生时间、事件内容等。

日志数据的处理往往依靠业务系统进行，传统的业务系统中，往是在业务系统中直接写入相关判断逻辑，用以反应系统的运行状态，例如系统实时在线用户，业务系统会直接维护一个值来反应在线用户数量。此外，现有的实时业务系统计算的数据往往只是简单的sum(值的累加)、count(出现的次数)等，也就只能进行不需要历史数据即可计算的非关联性日志。而需要历史数据才能进行计算的关联性日志，则需要通过将全量的日志数据存储起来，然后通过离线处理来进行计算，例如，前一天的日志数据可能存储起来后在第二天才进行计算和处理，这就使得日志文件处理的实时性不足。

针对上述问题，发明人提出了本申请实施例提供的日志处理方法、装置、服务器以及存储介质，可以在实时处理与历史日志数据具有关联性的日志时，能够从前一次记录的日志文件中获取到历史业务数据，并进行日志数据的处理，从而实现对关联性的日志文件的处理。其中，具体的日志处理方法在后续的实施例中进行详细的说明。

请参阅图1，图1示出了本申请一个实施例提供的日志处理方法的流程示意图。所述日志处理方法用于实现在实时处理与历史日志数据具有关联性的日志时，能够从上一次记录的日志文件中获取到历史业务数据，并进行日志数据的处理，从而实现对关联性的日志文件的处理。在具体的实施例中，所述日志处理方法应用于如图4所示的日志处理装置400以及配置有所述日志处理装置400的服务器100(图6)。下面将以服务器为例，说明本实施例的具体流程，当然，可以理解的，本实施例所应用的服务器可以为传统服务器、云服务器等，在此不做限定。下面将针对图1所示的流程进行详细的阐述，所述日志处理方法具体可以包括以下步骤：

步骤S110：获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据。

在本申请实施例中，服务器可以获取待处理的第一日志文件。待处理的第一日志文件可以为实时产生的日志文件，例如，用户在进行业务时产生的日志文件。服务器获取的待处理的第一日志文件可以为目标用户的第一日志文件，该目标用户可以为任意用户，在产生目标用户的第一日志文件后，服务器可以实时的获取到该第一日志文件。

在一些实施方式中，目标用户进行业务时可以于业务服务器产生第一日志文件，然后对日志文件进行处理的服务器可以从业务服务器实时获取到目标用户的第一日志文件；业务服务器产生第一日志文件后，也可以将第一日志文件输出至指定的服务器，然后用于处理日志的服务器可以实时从该指定的服务器获取第一日志文件；业务服务器以及用于处理日志文件的服务器可以为同一个服务器，在目标用户进行业务时产生第一日志文件后，即可获取到待处理的第一日志文件。

在一些实施方式中，第一日志文件可以为业务服务器中预先进行了埋点的日志，也就是说，目标用户进行业务时，如果触发了埋点的相应操作，则会产生日志。这样可以保证需求的数据和信息被记录到日志中，并且后续被服务器所处理。

在一些实施方式中，目标用户进行的当前业务的业务数据被记录于日志文件中，其中，业务数据的具体内容可以不作为限定，可以根据实际的业务需求而设置。例如，在进行任务管理的业务时，则业务数据可以包括姓名、任务的标识、任务名称、时间等信息。

步骤S120：获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据。

在本申请实施例中，服务器可以在获取到目标用户的第一日志文件后，还可以获取前一次记录的目标用户的第二日志文件。其中，第二日志文件可以为前一次对目标用户的日志文件进行处理后，最终生成的日志文件。

在一些实施方式中，以往对日志文件进行处理后产生的最终的日志文件，可以存储于该用于处理日志文件的服务器，也可以存储与外部的存储设备(例如其他的服务器等)中，从而用于处理日志文件的服务器，在对日志文件进行处理时，能够快速方便的获取到目标用户的第二日志文件。

在一些实施方式中，第二日志文件中可以包括历史业务数据。历史业务数据可以为前一次处理日志文件时的日志文件中的所有业务数据，也就是说处理后最终的日志文件中包括处理时获得的日志文件中的所有业务数据；历史业务数据也可以为前一次处理日志文件时的日志文件中的部分数据，例如，可以为处理时的日志文件中被用于计算的日志数据。

在一些实施方式中，第二日志文件的业务类型可以与第一日志文件的业务类型相同，从而可以能够根据第二日志文件中的历史业务数据，对第一日志文件中的业务数量进行处理。例如，第一日志文件的业务类型为关于项目的流水信息的类型，则第二日志文件的业务类型也为关于项目的流水信息的类型，从而可以第一日志文件以及第二日志文件中均包括关于项目的流水信息，这样就可以根据流水信息的业务数据，进行相应的计算，获得关于项目的其他信息。

步骤S130：根据所述当前业务的业务数据以及所述当前业务的业务数据，生成业务处理结果。

在本申请实施例中，服务器在获取到目标用户的本次的第一日志文件，以及前一次记录的目标用户的第二日志文件之后，则可以根据第一日志文件中的业务数据，以及第二日志文件中的历史业务数据，针对与历史业务数据具有关联性的业务处理需求，进行处理，以获得业务处理结果。

在一些实施方式中，服务器可以根据实际的业务需求，依据当前业务的业务数据以及历史业务数据，计算相应的业务信息。例如，当前业务的业务数据以及历史业务数据中均包括项目的完成度，则可以计算当前时间与前一次的日志文件相距的时间段内的项目完成量。又例如，当前业务的业务数据以及历史业务数据中均包括日志文件的时间，则可以根据业务数据中的时间计算时间花费信息等。当然，以上对业务数据的处理仅为举例，并不构成对具体的业务数据处理的限定，具体的业务数据处理可以根据实际的业务需求而设定。服务器获得的业务处理结果，可以根据具体的业务数据处理而定，例如，业务处理结果可以包括项目完成量、时间花费信息等，在此不做限定。

步骤S140：根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。

在本申请实施例中，服务器在根据当前业务的业务数据，以及历史业务数据，生成业务处理结果之后，可以根据获得的业务处理结果，以及以上获得的目标用户的第一日志文件，生成第三日志文件。

在一些实施方式中，服务器根据业务处理结果以及第一日志文件，生成的第三日志文件可以包括业务处理结果以及第一日志文件中全部的日志数据，从而可以保证存储的日志文件中能够既能包括计算获得的处理结果，也能包括全部的日志数据，这样后续获得目标用户的待处理的日志文件时，无论对于何种处理需求，均能根据存储的日志文件中的日志数据(即历史业务数据)，进行相应的计算处理；当然，服务器生成的第三日志文件中，也可以包括业务处理结果以及第一日志文件中的至少部分日志数据，该至少部分日志数据可以为以上进行计算处理时所使用到的业务数据，这样可以不用将无用的日志数据一并写入到第三日志文件，从而减少日志文件的大小，进而减少占用的存储空间。

由于生成的第三日志文件中既包括了业务数据的业务处理结果，还包括了本次的日志文件中的业务数据，因此可以在下次实时处理需要历史业务数据进行计算和处理的日志文件时，能够直接从存储的日志文件中获取历史业务数据，完成对与历史业务数据具有关联的日志文件时能够实时进行处理。

本申请实施例提供的日志处理方法，通过获取目标用户的第一日志文件，该第一日志文件包括当前业务的业务数据，获取前一次记录的该目标用户的第二日志文件，该第二日志文件至少包括历史业务数据，根据当前业务的业务数据以及当前业务的业务数据，生成业务处理结果，然后根据业务处理结果以及第一日志文件，生成第三日志文件并将第三日志文件进行存储。可以实现在实时处理与历史日志数据具有关联性的日志时，能够从前一次记录的日志文件中获取到历史业务数据，并进行日志数据的处理，从而实现对与历史业务数据具有关联性的日志文件的处理。

请参阅图2，图2示出了本申请另一个实施例提供的日志处理方法的流程示意图。该日志处理方法应用于上述服务器，下面将针对图2所示的流程进行详细的阐述，所述日志处理方法具体可以包括以下步骤：

步骤S210：获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据。

在本申请实施例中，步骤S210可以参阅前述实施例的内容，在此不再赘述。

步骤S220：获取所述第一日志文件的业务类型。

服务器在获取到目标用户的第一日志文件之后，可以获取第一日志文件的业务类型，以确定第一日志文件的业务类型是否为需要历史业务数据进行处理和计算的类型。

在一些实施方式中，业务服务器生成的日志文件中可以包括日志文件的类型标识，该类型标识可以用于表征日志文件的业务类型。作为一种实施方式，在进行日志埋点时，可以对日志文件的类型进行埋点，对于需要历史业务数据进行计算和处理的日志文件，以及不需要历史业务数据进行计算和处理的日志文件，可以用不同的类型标识区分。从而，服务器在获取到第一日志文件后，可以根据日志文件的类型标识，确定出第一日志文件为需要历史业务数据进行计算和处理的业务类型，以及不需要历史业务数据进行计算和处理的业务类型。

步骤S230：如果所述业务类型不为第一指定类型，则根据所述当前业务的业务数据，生成第四日志文件并将所述第四日志文件进行存储。

在本申请实施例中，服务器在确定出第一日志文件的业务类型之后，可以根据第一日志文件的业务类型，确定是否需要获取前一次记录的目标用户的第二日志文件，也就是是否需要获取历史业务数据，以进行第一日志文件的处理。

在本申请实施例中，第一指定类型可以为需要历史业务数据进行计算和处理的业务类型。如果第一日志文件的业务类型为第一指定类型，则表示需要获取前一次记录的目标用户的第二日志文件；如果第二日志文件的业务类型不为第一指定类型，则表示不需要获取前一次记录的目标用户的第二日志文件。

在一些实施方式中，如果第一日志文件的业务类型不为第一指定类型，则可以直接根据第一日志文件中的业务数据进行处理，并且生成第四日志文件。其中，生成的第四日志文件中可以包括第一日志文件中的全部业务数据或者部分业务数据。作为一种方式，服务器可以根据业务数据中所有业务数据，生成包括该所有业务数据的第四日志文件；作为另一种方式，在根据第一日志文件中的业务数据生成第四日志文件时，可以确定第一日志文件的业务数据中是否包括多余的业务数据，并将多余的业务数据进行过滤，然后根据过滤后剩余的业务数据，生成第四日志文件。

步骤S240：如果所述第一日志文件的业务类型为第一指定类型，则获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据。

在本申请实施例中，如果第一日志文件的业务类型为第一指定类型，则可以获取前一次记录的该目标用户的第二日志文件，以便服务器根据第二日志文件中的历史业务数据，对第一日志文件进行处理。

步骤S250：根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果。

步骤S260：根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。

在本申请实施例中，步骤S250及步骤S260可以参阅前述实施例的内容，在此不再赘述。

本申请实施例提供的日志处理方法，通过获取目标用户的第一日志文件，该第一日志文件包括当前业务的业务数据，然后获取第一日志文件的业务类型，如果业务类型不为第一指定类型，则根据第一日志文件中的业务数据，生成第四日志文件并将第四日志文件进行存储，如果业务类型为第一指定类型，则获取前一次记录的该目标用户的第二日志文件，该第二日志文件至少包括历史业务数据，根据当前业务的业务数据以及当前业务的业务数据，生成业务处理结果，然后根据业务处理结果以及第一日志文件，生成第三日志文件并将第三日志文件进行存储。可以实现在实时处理与历史日志数据具有关联性的日志时，能够从前一次记录的日志文件中获取到历史业务数据，并进行日志数据的处理，从而实现对与历史业务员数据具有关联性的日志文件的处理。这样在实时处理日志文件时，既能对不需要历史业务数据进行处理的日志文件进行实时处理，也能对需要历史业务数据进行处理的日志文件进行实时处理。

请参阅图3，图3示出了本申请又一个实施例提供的日志处理方法的流程示意图。该日志处理方法应用于上述服务器，下面将针对图3所示的流程进行详细的阐述，所述日志处理方法具体可以包括以下步骤：

步骤S310：接收消息队列MQ服务器发送的目标用户的第一日志文件，所述第一日志文件为业务服务器通过数据采集工具Flume采集到当前业务的业务数据后，利用分布式订阅系统kafka实时进行记录，并输出至所述MQ服务器。

在本申请实施例中，对于业务系统中日志文件的生成和处理过程，可以由业务服务器、消息队列(Message Queue，MQ)服务器以及实时平台(Storm)服务器完成，其中，Storm服务器用于执行本申请实施例提供的日志处理方法。

在一些实施方式中，业务服务器记录日志的方式，可以通过预先对需要记录的接口中埋点，当接口被触发后，将触发接口产生的业务数据写入到本地指定的日志文件中，数据采集工具Flume如果确定本次的日志文件相对前一次记录的日志文件发生变化，则可以采集当前业务的业务数据，并将日志文件输出到分布式订阅系统kafka实时进行记录，且将日志文件输出到MQ服务器。Storm服务器可以从MQ服务器获取待处理的日志文件，以对日志文件进行处理。

其中，Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。kafka一款开源高可用、高吞吐量的分布式消息系统，广泛用于各个互联网平台进行消息的投递订阅，它可以处理消费者规模的网站中的所有动作流数据，Kafka可实时记录从数据采集工具Flume中收集的数据，并作为消息缓冲组件为上游实时计算框架提供可靠数据支撑。Storm是一款开源的分布式实时计算系统，适用于对海量数据的实时处理。

作为一种实施方式，业务服务器中在对需要记录的接口中埋点的方式中，可借由面向切面变成(AOP，Aspect Oriented Programming)技术，拦截需要被记录的信息。例如，对于java web系统，可创建一个运行时注解类，并提供注解处理机，注解处理机可以判断当前的注解，按照业务需要记录信息到日志文件中，该运行时注解类可放置于业务系统中需要被记录的方法中，或者类中，用以标识需要被拦截的方法。

其中，AOP是对面向对象编程(OOP，Object Oriented Programming)的补充。在运行时，动态的将代码切入到类的指定方法或者指定位置上的编程思想，就是面向切面的编程。以Spring AOP的概念来说明：Aspect，切面，一个关注点的模块化，这个关注点可能会横切多个对象；JoinPoint，连接点，在程序执行过程中某个特定的点，比如某方法调用的时候或者处理异常的时候；在Spring AOP中，一个连接点总是表示一个方法的执行；Advice，通知，在切面的某个特定的连接点上执行的动作；Pointcut，切点，匹配连接点的断言，通知和一个切入点表达式关联，并在满足这个切入点的连接点上运行(例如，当执行某个特定名称的方法时)；切入点表达式如何和连接点匹配是AOP的核心：Spring缺省使用AspectJ切入点语法。

在本申请实施例中，业务服务器通过以上方式进行日志文件的生成和管理，并通过MQ服务器传输至Storm服务器，可以使数据的处理实时性提升，并具有高容错、高吞吐、低成本的有点。并且通过不同服务器来进行日志文件整个过程的处理，也降低了服务器的处理压力，提升了处理效率。

步骤S320：获取所述第一日志文件的业务类型。

在本申请实施例中，步骤S320可以参阅前述实施例的内容，在此不再赘述。

步骤S330：如果所述业务类型不为第一指定类型，则根据所述当前业务的业务数据，生成第四日志文件并将所述第四日志文件进行存储。

在本申请实施例中，业务系统中往往会按照需要区分为关键日志和流水日志。其中，关键日志为一次性行为所对应的日志，项目的创建、任务的划分等概略性数据；流水日志为多次、持续性的数据所对应的日志，通过流水日志可以分析出项目当前节点的负责人、完成度、当前节点等信息。

在一些实施方式中，第一指定类型可以为需要历史业务数据进行计算和处理的业务类型。如果第二日志文件的业务类型不为第一指定类型，则表示不需要获取前一次记录的目标用户的第二日志文件。

在一些实施方式中，如果第一日志文件的业务类型不为第一指定类型时，可以确定第一日志文件的业务类型是否为第二指定类型。其中，该第二指定类型可以为以上关键日志的类型。对于第二指定类型的日志文件的处理，Storm服务器在获取到业务类型为第二指定类型的日志文件后，则可以直接使用其高级抽象Trident提供的exactly once(有且只处理一次)的语义处理每一条数据，并将获得的第四日志文件入库存储。

其中，Storm Trident是Storm的一种高度抽象的实时计算模型，它可以将高吞吐量(每秒百万级)数据输入、有状态的流式处理与低延时的分布式查询无缝结合起来。Trident拥有联结(join)、聚合(aggregation)、分组(grouping)、函数(function)以及过滤器(filter)这些功能。Trident为数据库或者其他持久化存储上层的状态化、增量式处理提供了基础原语。实时计算的一个关键问题就在于如何管理状态(state)，使得在失败与重试操作之后的更新过程仍然是幂等的。错误是不可消除的，所以在出现节点故障或者其他问题发生时批处理操作还需要进行重试。不过这里最大的问题就在于怎样执行一种合适的状态更新操作(不管是针对外部数据库还是拓扑内部的状态)，来使得每个消息都能够被执行且仅仅被执行一次。Trident通过下面两件事情解决了这个问题：1)在Trident中为每个数据块标记了一个唯一的id，这个id就叫做“事务id”(transaction id)。如果数据块由于失败回滚了，那么它持有的事务id不会改变。2)State的更新操作是按照数据块的顺序进行的。也就是说，在成功执行完块2的更新操作之前，不会执行块3的更新操作。基于这两个基础特性，state更新就可以实现恰好一次(exactly-once)的语义。可以使用任何一种方法来实现state的存储操作，例如数据库、redis、hdfs等。

在一些实施方式中，如果第一日志文件的业务类型不为第一指定类型，也不为第二指定类型，即第一日志文件的业务类型为流水日志的类型中的不需要历史业务数据进行计算的类型，则可以根据第一日志文件中的业务数据进行相应的统计和计算后，形成第四日志文件并存储入库。例如，例如统计发生次数，每处理一条数据，就将该数据出现的次数累加1即可，然后更新到指定外部存储，例如数据库、redis等。

另外，如果第一日志文件的业务类型不为第一指定类型，也不为第二指定类型时，Storm服务器还可以获取上次记录的第五日志文件，该第五日志文件的业务类型为第二指定类型，也就是关键日志类型。Storm服务器可以根据关键日志，对第一日志文件中的业务数据进行补全，具体可以获取第五日志文件中与第一日志文件不同的目标数据，也就是第一日志文件中不存在但是第五日志文件中存在的业务数据，然后根据第一日志文件中的当前业务的业务数据，以及获得的目标数据，生成第四日志文件，并将第四日志文件进行存储。例如：一项任务领取时，领取的信息包括用户id(userId)，用户名(userName)、任务id(taskId)、任务名称(taskName)，后续这个用户需要多次的操作才能完成该任务，那么项目关键日志可以包含userId、userName、taskId、taskName，流水日志中只需要记录userId、taskId、每次操作的时间以及其他用于计算用户完成该任务的信息数据，通过流水日志计算完成该用户的任务信息后，通过关键日志可补充该userId在该projectId下的名称信息(用户名、任务名)。

步骤S340：如果所述第一日志文件的业务类型为第一指定类型，获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据。

步骤S350：根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果。

步骤S360：根据所述业务处理结果以及所述第一日志文件，生成包括所述业务处理结果以及所述第一日志文件的第三日志文件。

步骤S370：将所述第三日志文件存储到指定数据对象的指定字段。

在本申请实施例中，Storm服务器可以定义有指定数据对象，并且该指定数据对象中设定有指定字段。该指定数据对象中的指定字段用于存储每次处理的日志文件中的业务数据，以作为下次处理时使用的历史业务数据。例如，定义数据对象A，该数据对象A中设定一个字段set，字段类型为Set，用以存储历史业务数据(来自每次处理的日志文件，并剔除额外的数据以减轻存储压力)，再按照需求定义需要统计的字段信息用以存储每次计算后的业务处理结果，例如完成数量counts、项目花费时间costs，若需要分项目统计，可额外定义一个map，其key即为项目的id，value为每次计算后的结果信息。

Storm服务器在对第一日志文件中的当前业务的业务数据以及第二日志文件中的历史业务数据进行处理，获得业务处理结果之后，可以将处理结果与第二日志文件中所包括的前一次处理日志文件的处理结果进行比对，如果有变化则可以将处理结果更新至业务服务器。并且Storm服务器根据业务处理结果以及第一日志文件形成第三日志文件，将第三日志文件存储到指定数据对象的指定字段，存储到Trident state中指定的外部存储中，例如数据库、redis等存储。利用Trident state特性，每一次存储的日志不会多存，也不会少存，并且恰好存一次，保存和提取的过程无需手动编码，提升了便利性。

其中，redis是一个开源的key-value存储系统，基于内存的高速存取和其分布式可扩展的特性，为互联网应用的高并发，高可用提供了高效的解决方案。redis常用于作为分布式应用的缓存层，在各个服务器实例之间共享数据，为客户端请求提供快速的反馈，缓解应用数据库底层的压力，同时其丰富的数据结构和API更为各种应用场景提供了强有力的支撑。

传统的日志处理方案中，对日志文件进行实时处理，通常只处理不需要历史业务数据来处理的日志文件，例如页面访问统计等，来一条日志时，统计值就加1，存储的结果也是汇总后的值，对于需要历史业务数据才能进行处理和计算的日志一般不会实时的处理，而是采用离线计算的方式进行处理，比如当天凌晨会把前一天所有的日志数据从存储(数据库)里拉出来，按一个逻辑来算。而通过本申请实施例提供的日志处理方法，在每一次计算后，将计算结果以及每次处理的日志中的业务数据本身同时存储于指定数据对象中，在下一次处理需要历史业务数据对日志处理时，则可以直接从指定数据对象中获取历史业务数据，并且根据历史业务数据对待处理的日志进行处理。从而不仅能处理不需要历史业务数据即可处理的独立性日志文件，也能够处理需要历史业务数据进行处理的关联性的日志文件。并且，可以支持后端的系统横向扩展，后端增加设备时只需在新的设备上部署flumeng即可，对于日志进行处理的日志处理系统即可无缝接入，适用各种业务系统。

请参阅图4，其示出了本申请实施例提供的一种日志处理装置400的结构框图。该日志处理装置400应用上述的服务器，该日志处理装置400包括：第一获取模块410、第二获取模块420、数据处理模块430以及日志生成模块440。其中，所述第一获取模块410用于获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据；所述第二获取模块420用于获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据；所述数据处理模块430用于根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果；所述日志生成模块440用于根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。

在一些实施方式中，该日志处理装置400还可以包括业务类型获取模块。业务类型获取模块可以用于在所述获取前一次记录的所述目标用户的第二日志文件之前，获取所述第一日志文件的业务类型。在该方式下，第二获取模块420可以具体用于：如果所述第一日志文件的业务类型为第一指定类型，则获取前一次记录的所述目标用户的第二日志文件。

在该实施方式下，该日志处理装置400还可以包括：第一生成模块。第一生成模块可以用于在所述获取所述业务数据的业务类型之后，如果所述业务类型不为第一指定类型，则根据所述当前业务的业务数据，生成第四日志文件并将所述第四日志文件进行存储。

在该实施方式下，第一生成模块可以具体用于：如果所述业务类型不为第一指定类型，且所述业务类型为第二指定类型时，生成包括所述当前业务的业务数据的第四日志文件，并将所述第四日志文件进行存储。

进一步地，第一生成模块还可以具体用于：如果所述业务类型不为第一指定类型，且所述业务类型不为第二指定类型时，获取上次记录的第五日志文件，所述第五日志文件的业务类型为所述第二指定类型；获取所述第五日志文件中与所述第一日志文件不同的目标数据；根据所述当前业务的业务数据以及所述目标数据，生成第四日志文件并将所述第四日志文件进行存储。

在一些实施方式中，请参阅图5，日志生成模块440可以包括：生成单元441以及日志存储单元442。生成单元441用于根据所述业务处理结果以及所述第一日志文件，生成包括所述业务处理结果以及所述第一日志文件的第三日志文件；日志存储单元442用于将所述第三日志文件存储到指定数据对象的指定字段。

在一些实施方式中，第一获取模块410可以具体用于：接收消息队列MQ服务器发送的目标用户的第一日志文件，所述第一日志文件为业务服务器通过数据采集工具Flume采集到当前业务的业务数据后，利用分布式订阅系统kafka实时进行记录，并输出至所述MQ服务器。

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

在本申请所提供的几个实施例中，模块相互之间的耦合可以是电性，机械或其它形式的耦合。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

综上所述，本申请提供的方案，通过获取目标用户的第一日志文件，该第一日志文件包括当前业务的业务数据，获取前一次记录的该目标用户的第二日志文件，该第二日志文件至少包括历史业务数据，根据当前业务的业务数据以及当前业务的业务数据，生成业务处理结果，然后根据业务处理结果以及第一日志文件，生成第三日志文件并将第三日志文件进行存储。可以实现在实时处理与历史日志数据具有关联性的日志时，能够从前一次记录的日志文件中获取到历史业务数据，并进行日志数据的处理，从而实现对关联性的日志文件的处理。

请参考图6，其示出了本申请实施例提供的一种服务器的结构框图。该服务器100可以是传统服务器、云服务器等能够运行应用程序的电子设备。本申请中的服务器100可以包括一个或多个如下部件：处理器110、存储器120、以及一个或多个应用程序，其中一个或多个应用程序可以被存储在存储器120中并被配置为由一个或多个处理器110执行，一个或多个程序配置用于执行如前述方法实施例所描述的方法。

处理器110可以包括一个或者多个处理核。处理器110利用各种接口和线路连接整个服务器100内的各个部分，通过运行或执行存储在存储器120内的指令、程序、代码集或指令集，以及调用存储在存储器120内的数据，执行服务器100的各种功能和处理数据。可选地，处理器110可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器110可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器110中，单独通过一块通信芯片进行实现。

存储器120可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储服务器100在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

请参考图7，其示出了本申请实施例提供的一种计算机可读存储介质的结构框图。该计算机可读介质800中存储有程序代码，所述程序代码可被处理器调用执行上述方法实施例中所描述的方法。

计算机可读存储介质800可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。可选地，计算机可读存储介质800包括非易失性计算机可读介质(non-transitory computer-readable storage medium)。计算机可读存储介质800具有执行上述方法中的任何方法步骤的程序代码810的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码810可以例如以适当形式进行压缩。

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

Claims (9)

1.一种日志处理方法，其特征在于，所述方法包括：

获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据；

获取所述第一日志文件的业务类型；

如果所述第一日志文件的业务类型为第一指定类型，则获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据；

根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果；

根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。

2.根据权利要求1所述的方法，其特征在于，在所述获取所述第一日志文件的业务类型之后，所述方法还包括：

如果所述业务类型不为第一指定类型，则根据所述当前业务的业务数据，生成第四日志文件并将所述第四日志文件进行存储。

3.根据权利要求2所述的方法，其特征在于，所述如果所述业务类型不为第一指定类型，根据所述当前业务的业务数据，生成第四日志文件并将所述第四日志文件进行存储，包括：

如果所述业务类型不为第一指定类型，且所述业务类型为第二指定类型时，生成包括所述当前业务的业务数据的第四日志文件，并将所述第四日志文件进行存储。

4.根据权利要求3所述的方法，其特征在于，所述如果所述业务类型不为第一指定类型，根据所述当前业务的业务数据，生成第四日志文件并将所述第四日志文件进行存储，还包括：

如果所述业务类型不为第一指定类型，且所述业务类型不为第二指定类型时，获取上次记录的第五日志文件，所述第五日志文件的业务类型为所述第二指定类型；

获取所述第五日志文件中与所述第一日志文件不同的目标数据；

根据所述当前业务的业务数据以及所述目标数据，生成第四日志文件并将所述第四日志文件进行存储。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储，包括：

根据所述业务处理结果以及所述第一日志文件，生成包括所述业务处理结果以及所述第一日志文件的第三日志文件；

将所述第三日志文件存储到指定数据对象的指定字段。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述获取目标用户的第一日志文件，包括：

接收消息队列MQ服务器发送的目标用户的第一日志文件，所述第一日志文件为业务服务器通过数据采集工具Flume采集到当前业务的业务数据后，利用分布式订阅系统kafka实时进行记录，并输出至所述MQ服务器。

7.一种日志处理装置，其特征在于，所述装置包括：第一获取模块、第二获取模块、数据处理模块以及日志生成模块，其中，

所述第一获取模块用于获取目标用户的第一日志文件，所述第一日志文件包括当前业务的业务数据；

所述第二获取模块用于获取所述第一日志文件的业务类型；如果所述第一日志文件的业务类型为第一指定类型，则获取前一次记录的所述目标用户的第二日志文件，所述第二日志文件至少包括历史业务数据；

所述数据处理模块用于根据所述当前业务的业务数据以及所述历史业务数据，生成业务处理结果；

所述日志生成模块用于根据所述业务处理结果以及所述第一日志文件，生成第三日志文件并将所述第三日志文件进行存储。

8.一种服务器，其特征在于，包括：

一个或多个处理器；

存储器；

一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行如权利要求1-6任一项所述的方法。

9.一种计算机可读取存储介质，其特征在于，所述计算机可读取存储介质中存储有程序代码，所述程序代码可被处理器调用执行如权利要求1-6任一项所述的方法。

Images