CN104283719A - 一种日志的处理方法、装置及服务器 - Google Patents

Abstract

本发明提供了一种日志的处理方法、装置及服务器，其中方法包括：针对当前时间段的用户日志文件，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取并实时处理；按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理，若是，则转向读取和处理下个时间段的用户日志文件。本发明实现了对用户日志数据的实时读取和处理，可以尽早地得到有价值的信息，达到了高效处理日志的目的。

Description

一种日志的处理方法、装置及服务器

技术领域

本发明涉及数据处理技术领域，尤其涉及一种日志的处理方法、装置及服务器。

背景技术

在数据处理技术领域，通常会采用一种载体将某种行为相关的数据进行记录下来用于分析，例如，在计算机中，这种载体例如可以是用户行为日志等，一种纯文本。根据提前制定的记录规则，该载体记录了用户个体的全部行为，随着客户端用户的增多、用户行为的复杂，该载体的容量大小也会随之变大。

举个实际的例子来说，在客户端发起点播视频的操作并加载成功后，客户端会将用户的行为数据发送给服务器，这些行为数据包括：播放操作、播放的内容、频道、播放的码率和网络速率等数据。服务器会将这些数据按照设定的格式例如W3C的格式存储为日志，并可以通过读取这些日志记录的内容，对用户的行为数据进行处理例如进行统计和分析，从而得到有价值的信息。

因此，越高效地对日志进行处理，可以越早地得到有价值的信息，但是，目前在服务器侧，通常用户日志文件是按时间段(按小时或者按天)来生成的，例如每天或者每个小时生成一个用户日志文件，当前一个小时内的用户行为数据实时更新并保持在一个用户日志文件中，需要到下一个小时到来后才会生成新的用户日志文件，也就是说须等到下个小时到来后，上一个小时的用户日志文件中的数据才会停止更新。当前日志处理的方式是在一个用户日志文件停止更新以后才开始处理该用户日志文件，这样，对于用户行为数据的处理，相对这些数据的产生，发生了一个小时的延迟，无法做到高效地对用户的行为数据进行实时的处理。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种日志的处理方法、装置及服务器。

基于上述问题，本发明实施例提供的一种日志的处理方法，包括：

针对当前时间段的用户日志文件，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取并实时处理；

按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理，若是，则转向读取和处理下个时间段的用户日志文件。

本发明实施例提供的一种日志的处理装置，包括：

实时读取模块，用于针对当前时间段的用户日志文件，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取；以及当判断模块判断完成了当前时间段内用户日志的读取和处理时，转向读取下个时间段的用户日志文件；

实时处理模块，用于对实时读取模块读取的数据进行实时处理；

判断模块，用于按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理。

本发明实施例提供的服务器，包括本发明实施例提供的上述日志的处理装置。

本发明实施例的有益效果包括：

本发明实施例提供的日志的处理方法、装置及服务器，在当前时间段用户日志文件生成并不断更新的过程中，对当前时间段的用户日志文件，按照增量的方式，不断进行读取，并对读取的日志数据进行实时的处理，直到完成了当前时间段内用户日志文件的读取和处理，转向下个时间段的用户日志文件的读取和处理，这样，可以实现对用户日志数据的实时读取和处理，可以尽早地得到有价值的信息，达到了高效处理日志的目的，克服了现有技术中对用户日志文件延迟处理带来的弊端。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例提供的日志的处理方法的流程图；

图2为本发明实施例提供的日志的处理方法的一种实例的流程图；

图3为本发明实施例提供的实例中读取用户日志文件步骤的流程图；

图4为本发明实施例提供的日志的处理装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

下面结合说明书附图，对本发明实施例提供的一种日志的处理方法、装置及服务器的具体实施方式进行说明。

本发明实施例提供的一种日志的处理方法，如图1所示，具体包括以下步骤：

S11、针对当前时间段的用户日志文件，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取并实时处理；

S12、按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理；若是，则执行下述S13，否则，转向S11；

S13、读取和处理下个时间段的用户日志文件。

本发明实施例中提及的当前时间段的用户日志文件，是指在当前时间段内产生的用户日志数据生成的用户日志文件，下个时间段的用户日志文件的含义以此类推。

在本发明实施例中，用户日志文件按照时间来生成的，在同一个时间段内的日志数据，会保存在一个用户日志文件中，例如IIS日志，将一个小时内发生的用户日志数据保存在同一个用户日志文件中，假设当前时间是8月29号11点0分第0秒，那么11点之前的数据会写入到以10点为标记的用户日志文件中，11点以后新到达的用户日志数据都会写入到新生成的以11点为标记的文件中，按照现有技术的做法，需要当前时间达到11点以后即以10点为标记的用户日志文件不再更新之后，再对其进行处理，而本发明实施例提供的日志的处理方法，在当前时间段用户日志文件生成并不断更新的过程中，对当前时间段的用户日志文件，按照增量的方式，不断进行读取，并对读取的日志数据进行实时的处理，直到完成了当前时间段内用户日志文件的读取和处理，转向下个时间段的用户日志文件的读取和处理，这样，可以实现对用户日志数据的实时读取和处理，例如前述以10点为标记的用户日志文件，在其内容不再更新后的短暂时间内，就已经完成了用户日志数据的读取和处理，而对这些用户行为数据的及时处理，可以尽早地得到有价值的信息，达到了高效处理日志的目的。

当然，本发明实施例中，用户行为日志格式可以采用IIS W3C格式的日志，但不局限于IIS W3C格式的日志，日志的载体是.log日志文件，但不局限于.log文件，也可以是其他后缀名的纯文本文件。

为了更好地说明本发明实施例提供的上述日志的处理方法，下面分别对上述各个步骤进行详细的说明。

进一步地，上述流程中S11中，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取的步骤，在具体实施时，可以通过下述过程实现：

周期性地对当前时间段的用户日志文件进行读取，并在每次读取时，根据已完成读取的数据量，确定本次读取的起点位置，然后从本次读取的起点位置开始读取，并在本次读取结束时，记录已完成读取的数据量。

上述增量读取的方式，即从原则上来说，就是指从上次读取的结束位置作为下次读取的开始位置，但是，由于在实际应用时，由于用户日志文件中包含的是一行一行的用户行为数据，每一行都是一条完整的用户行为数据(只有对完整的用户行为数据进行处理才有意义)，但是用户日志文件又存在读写的并行处理过程，即：日志服务器(例如IIS服务器)不断向用户日志文件中写入用户日志数据的过程中，同时又会不断地读取日志并进行实时处理，这样，容易出现这样一种情况即：一行用户行为数据还未写入完整，就被读取出来，导致断行，这种断行的用户行为数据对用户行为的分析是没有意义的，因此，为了避免断行对用户日志文件处理过程的影响，在本发明实施例中，在上述S11中，每次读取结束时，除了需要记录已读取的数据量(累积到本次读取时已完成读取的数据量)之外，还需要记录下本次读取的最后一行数据的数据量大小。

并且，相应地，上述S11中，每次读取时，根据下述公式确定本次读取的起点位置：

起点位置＝已完成读取的数据量-上次读取的最后一行的数据量。

用户日志文件中包含的一条一条的用户行为数据彼此是以特定的分隔符来分隔的，例如回车换行符等等，本发明实施例对此不做限定，对于本次读取的最后一行数据的数据量大小，可以通过读取的最后一个字节到最近的一个分隔符所经历的字节数来确定。

上述做法，在每次读取时，都将起点位置提前到上次读取的数据中最后一个分隔符之后，能够保证每次读取的用户日志数据都能够被完整地读取和处理，避免了读取用户日志文件时发生末尾断行情况对最终的用户行为分析的影响。

举例来说，在当第一次读取日志文件时，读取的数据量为50字节，最后一行的数据量大小为5字节，假设第一次读取的起始位置为0，则下一次即第二次读取的起始位置为50-5＝45字节，以此类推。

进一步地，在上述S11中，在确定本次读取的起点位置之后，还可以判断本次读取时当前用户日志文件的数据增加量(较已读取的数据量)是否超过设定的读取阈值；如果超过，则本次读取时只读取等于该读取阈值的数据量。

进一步地，上述S11中，对用户日志文件中的数据进行实时读取后，进行实时处理的过程包括但不限于：对用户日志文件中的日志数据进行解析，然后构建数据对象，将数据对象写入数据库等操作，对用户日志文件中的数据进行处理的方式可以参照现有技术，在此不再赘述。

进一步地，本发明实施例提供的日志处理方法中的步骤S12中，可以通过下述方式来判断是否完成了当前时间段内用户日志文件的读取和处理：

当判断当前时间距离当前用户日志文件所属时间段已达到设定的第一时间阈值，和/或当前用户日志文件已超过设定的第二时间阈值未更新，则确定已完成了当前时间段内用户日志的读取和处理。

举例来说，假设当前时间为11点04分，则判断当前时间距离当前用户日志文件所属的时间段(10点)已满足设定的时间阈值(例如1小时03分)则确定已完成以10点为标记的用户日志文件的读取和处理。

上述两个条件也可以同时用，也就是两个条件都必须同时满足，既满足时间达到设定的阈值，又满足在一定时间范围内不再发生数据的更新，才判断已完成了当前时间段内用户日志文件的读取和处理。

为了更好地说明本发明实施例提供的上述日志的处理方法，下面以一个简单的实例对其进行说明：

如图2所示的流程图，该实例包括如下步骤：

S21、初始化数据集合以及程序执行期间需要使用的内部变量。

S22、读取文件地址列表(由于用户日志文件可能是多个，需要各用户日志文件的地址)的配置信息。

S23、服务器生成文件名。例如u_ex14082910.log，u_ex是固定前缀，14082910代表14年8月29日10点的日志。

S24、读取文件，按照文件地址列表轮询各用户日志文件并处理；

S25、判断文件列表中的各文件是否已经读完，若是，则转向S26，否则继续执行S24；

S26、当前小时内的文件列表中的各用户日志文件全部处理完毕后，判断是否需要读取下个时间段的日志文件，若是，则转向读取下个时间段的用户日志文件的配置信息，否则，继续执行S24；

在本步骤S26中，判断是否需要读取下个时间段的日志文件，可以使用如下策略：当系统时间已经到达下个时间段，假设已到达下个小时(当前日志文件的文件名变量年月日小时加1等于当前时间的年月日小时)，且轮询每个用户日志文件列表的文件大小的次数已超过一定的阈值没有发生改变。假设阈值＝10，假设当前时间已经进入下个小时，且所有的日志文件大小都轮询了10次都没有发生改变，换言之，所有日志文件在一定的时间段内不再发生改变，那么可以确定已处理完当前一个小时内的用户日志，可以读取下个小时的用户日志文件了。

其中，上述S24中读取用户日志文件并处理的步骤，可以通过如图3所示的流程实现。

在图3所示的流程中，整个用户日志文件内的数据是以数据流的方式不断产生的(以下简称为流)，在生成同一个用户日志文件的时间段内，该数据流会不断发生变化(增量变化)。

具体来说，如图3所示，该流程包括：

S301、初始化数据集合以及需要使用的内部变量；

S302、生成读取文件地址；

S303、根据文件路径判断是网络文件(通过外网的方式访问)还是本地文件，如果是网络文件则执行S304，如果是本地文件则执行S305；

S304、初始化服务器流变量；

S305、则初始化文件流变量；

S306、判断流变量相比于已经处理的字节数是否有变化，如果没有变化说明文件没有被更新，执行S307；如果流大小发生了变化，则执行S309；

S307、判断是否应该读取下个用户日志文件(即下个时间段的用户日志文件)，如果是，则转向S308；否则，结束本流程(即不再读取当前时间段的用户日志文件，继续读取下一个时间段的用户日志文件)；

S308、记录读取的次数，该变量累计到阈值(10次)，用于图2中S25的判断。之后跳出当前时间段的用户日志文件的读取，继续处理下个用户日志文件；

S309、如果流大小发生了变化，那么需要重新解析上次的最后一行数据(避免最后一行不完整的问题),计算本次读取的起点位置＝已读字节数-上次读取的最后一行字节数，继续执行S310；

S310、计算流增加的字节数(即本次需要处理的流的数据量)：

本次需要处理的流的数据量＝最新流大小-已处理流的大小-上次处理的最后一行字节数。

判断该需要处理的流的数据量是否大于设定的阈值，如果需要处理的流的字节数大于阈值，则转向S311，阈值设为2147483648(2G)，则意味着最大一次只处理2G的数据量；否则，直接执行S312；

S311、设定本次读取的数据流的数据量等于该阈值，继续执行S312；

S312、从流最新的起点位置开始读取，如果是第一次则从位置0开始读取，之后则从增量部分开始读取；

S313、判断是否读取到当前用户日志文件内容的最后一行或者到达处理的阈值(流的增量部分大于设定的阈值的情况下)，若是，则执行S314、否则，执行S316～S318；

S314、记录已读字节数和最后一行字节数，然后执行S315；

S315、计算下次去读取起点位置：

下次读取的起点＝本次读取的起点+已读取字节数；

S316、每读取一行流数据，解析数据；

S317、然后构建数据对象；

S318、把对象写入数据库。

基于同一发明构思，本发明实施例还提供了一种日志的处理装置及服务器，由于这些装置和服务器所解决问题的原理与前述日志的处理方法相似，因此该装置和服务器的实施可以参见前述方法的实施，重复之处不再赘述。

如图4所示，本发明实施例提供的日志的处理装置，包括：

实时读取模块401，用于针对当前时间段的用户日志文件，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取；以及当判断模块判断完成了当前时间段内用户日志的读取和处理时，转向读取下个时间段的用户日志文件；

实时处理模块402，用于对实时读取模块读取的数据进行实时处理；

判断模块403，用于按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理。

进一步地，上述实时读取模块401，具体用于周期性地对当前时间段的用户日志文件进行读取，并在每次读取时，根据已完成读取的数据量，确定本次读取的起点位置，从所述本次读取的起点位置开始读取，并在本次读取结束时，记录已完成读取的数据量。

进一步地，上述实时读取模块401，还用于在本次读取结束时，记录本次读取的最后一行的数据量；以及根据下述公式确定所述本次读取的起点位置：起点位置＝已完成读取的数据量-上次读取的最后一行的数据量。

进一步地，上述实时读取模块401，还用于在确定本次读取的起点位置之后，判断本次读取时当前用户日志文件的数据增加量是否超过设定的读取阈值；若超过，则本次读取时只读取等于所述读取阈值的数据量。

进一步地，上述判断模块403，具体用于当判断当前时间距离所述当前用户日志文件所属时间段已达到设定的第一时间阈值，和/或当前用户日志文件已超过设定的第二时间阈值未更新，则确定已完成了当前时间段内用户日志的读取和处理。

本发明实施例还提供了一种服务器，该服务器包括本发明实施例提供的上述的日志的处理装置。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的日志的处理装置及服务器中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (11)

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

针对当前时间段的用户日志文件，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取并实时处理；

按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理，若是，则转向读取和处理下个时间段的用户日志文件。

2.如权利要求1所述的方法，其特征在于，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取，具体包括：

周期性地对当前时间段的用户日志文件进行读取，并在每次读取时，根据已完成读取的数据量，确定本次读取的起点位置，从所述本次读取的起点位置开始读取，并在本次读取结束时，记录已完成读取的数据量。

3.如权利要求2所述的方法，其特征在于，在本次读取结束时，还包括：记录本次读取的最后一行的数据量；

相应地，所述根据已完成读取的数据量，确定本次读取的起点位置，包括：

根据下述公式确定所述本次读取的起点位置：起点位置＝已完成读取的数据量-上次读取的最后一行的数据量。

4.如权利要求2或3所述的方法，其特征在于，在确定本次读取的起点位置之后，还包括：

判断本次读取时当前用户日志文件的数据增加量是否超过设定的读取阈值；

若超过，则本次读取时只读取等于所述读取阈值的数据量。

5.如权利要求1-3任一项所述的方法，其特征在于，按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理，具体包括：

当判断当前时间距离所述当前用户日志文件所属时间段已达到设定的第一时间阈值，和/或当前用户日志文件已超过设定的第二时间阈值未更新，则确定已完成了当前时间段内用户日志的读取和处理。

6.一种日志的处理装置，其特征在于，包括：

实时读取模块，用于针对当前时间段的用户日志文件，按照增量的方式，对当前时间段内用户日志文件内的数据进行不断进行读取；以及当判断模块判断完成了当前时间段内用户日志的读取和处理时，转向读取下个时间段的用户日志文件；

实时处理模块，用于对实时读取模块读取的数据进行实时处理；

判断模块，用于按照预设的条件，判断是否完成了当前时间段内用户日志的读取和处理。

7.如权利要求6所述的装置，其特征在于，所述实时读取模块，具体用于周期性地对当前时间段的用户日志文件进行读取，并在每次读取时，根据已完成读取的数据量，确定本次读取的起点位置，从所述本次读取的起点位置开始读取，并在本次读取结束时，记录已完成读取的数据量。

8.如权利要求7所述的装置，其特征在于，所述实时读取模块，还用于在本次读取结束时，记录本次读取的最后一行的数据量；以及根据下述公式确定所述本次读取的起点位置：起点位置＝已完成读取的数据量-上次读取的最后一行的数据量。

9.如权利要求7或8所述的装置，其特征在于，所述实时读取模块，还用于在确定本次读取的起点位置之后，判断本次读取时当前用户日志文件的数据增加量是否超过设定的读取阈值；若超过，则本次读取时只读取等于所述读取阈值的数据量。

10.如权利要求7所述的装置，其特征在于，所述判断模块，具体用于当判断当前时间距离所述当前用户日志文件所属时间段已达到设定的第一时间阈值，和/或当前用户日志文件已超过设定的第二时间阈值未更新，则确定已完成了当前时间段内用户日志的读取和处理。

11.一种服务器，其特征在于，所述服务器包括如权利要求6-10任一项所述的日志的处理装置。