CN103001796A - 服务端处理网络日志数据的方法及装置 - Google Patents

Abstract

本发明提供一种服务端处理网络日志数据的方法和装置，涉及计算机技术领域。服务端处理网络日志数据的方法包括：记录原始日志数据；根据原始日志数据以预定周期生成日志文件，其中，日志文件中的每条日志数据包括多个栏目的内容，并且，各栏目分别具有各自的栏目索引信息；查询日志文件中的注释字段，每个注释字段分别记录了日志数据中对应栏目的字段所代表的预定统计项目含义；将各注释字段分别与对应栏目的栏目索引信息相关联；根据预定统计项目对应栏目的索引信息提取该栏目的日志数据；对提取的日志数据进行统计以获取预定统计项目的统计结果。通过服务端收集原始日志，减轻了客户端的压力，本发明的应用更加灵活方便。

Description

服务端处理网络日志数据的方法及装置

技术领域

本发明涉及计算机技术领域，特别涉及一种服务端处理网络日志数据的方法和装置。

背景技术

日志统计分析是指对用户访问日志或系统日志运用统计方法及与分析对象有关的知识，从定量与定性的结合上进行的研究。随着互联网的发展，网站产生的用户访问日志或系统日志成爆发式增长，如何利用好这些日志信息，从这些信息中提取有效信息，从而提高网络资源利用率并进一步提高用户体验成为了当前互联网技术领域的关注点。而对日志进行统计分析从而获取有效的统计分析结果是解决该技术问题的方法之一。

在日志统计分析的发展过程当中，目前已经出现了一些日志统计分析系统，比如Google Analytics等。这些日志统计分析系统类似于应用软件，可以通过在浏览器端安装一个Javascript(JS)插件，用于收集用户访问日志，然后根据收集到的数据进行统计分析，展示固定的报表。

然而，目前的日志统计分析有很多局限性。例如，必须在客户端插入一段JS代码来收集用户日志，如果用户浏览器设置里禁用了JS功能或用户使用的是手机浏览器，则无法有效的执行客户端的JS代码，从而影响日志收集，也会影响日志统计分析的准确性和覆盖面。而且，目前的日志统计分析还加重了客户端的任务，占用了客户端的处理资源（CPU和内存），对用户使用的硬件有一定要求，也会加重用户设备的负载，进而影响用户体验。另外，在现有技术中，日志统计分析系统收集的用户字段都是通过字段索引来标明字段含义，对字段的增删改查维护起来很繁杂。

在用户状态标记方面，现有技术通过客户端的COOKIE方式，记录生成用户ID，并且在客户端判断用户的新老状态。这会导致以下问题：第一，COOKIE中的“用户首次访问”字段丢失时，用户将成为新用户，对统计分析新老UV（Unique visitor独立访客)会造成直接误差；第二，不支持二次计算，例如在发布某一个版本后，发现计算用户状态的逻辑存在错误，需修复此错误后重新发布版本，在此期间上传的用户状态数据都是错误的，而且无法修正，对统计分析结构直接造成影响。

发明内容

本发明实施例提供一种服务端处理网络日志数据的方法和装置，以提供对日志数据进行安全、灵活、方便的处理方案。

本发明为了实现上述目的提供一种服务端处理网络日志数据的方法，包括：记录原始日志数据；根据原始日志数据以预定周期生成日志文件，其中，日志文件中的每条日志数据包括多个栏目的内容，并且，各栏目分别具有各自的栏目索引信息；查询日志文件中的注释字段，每个注释字段分别记录了日志数据中对应栏目的字段所代表的预定统计项目含义；将各注释字段分别与对应栏目的栏目索引信息相关联；根据预定统计项目对应栏目的索引信息提取该栏目的日志数据；对提取的日志数据进行统计以获取预定统计项目的统计结果。

在一个实施例中，服务端处理网络日志数据的方法还包括：在确定文件指针为日志文件的第一行或确定日志文件为空文件之后，在日志文件中写入对应于各栏目的注释字段。

在一个实施例中，对提取的日志数据进行统计以获取预定统计项目的统计结果的步骤包括：将用户的所有访问轨迹记录并不断更新于数据库，访问轨迹至少包括用户的第一次访问时间和存在的所有后续访问时间。

在一个实施例中，服务端处理网络日志数据的方法还包括：在将用户的所有访问轨迹记录并不断更新于数据库之后，根据数据库记录的用户的访问轨迹，将只有第一次访问时间的用户的状态标识为新用户，将存在后续访问时间的用户标识为老用户。

在一个实施例中，服务端处理网络日志数据的方法还包括：在将用户的所有访问轨迹记录并不断更新于数据库之后，根据数据库记录的用户的访问轨迹，将预定周期内存在后续访问时间的用户标识为预定周期留存用户。

本发明为了实现上述目的还提供一种服务端处理网络日志数据的装置，包括：原始日志记录模块，用于记录原始日志数据；日志文件生成模块，用于根据原始日志数据以预定周期生成日志文件，其中，日志文件中的每条日志数据包括多个栏目的内容，并且，各栏目分别具有各自的栏目索引信息；注释查询模块，用于查询日志文件中的注释字段，每个注释字段分别记录了日志数据中对应栏目的字段所代表的预定统计项目含义；关联模块，用于将各注释字段分别与对应栏目的栏目索引信息相关联；数据提取模块，用于根据预定统计项目对应栏目的索引信息提取该栏目的日志数据；数据统计模块，用于对提取的日志数据进行统计以获取预定统计项目的统计结果。

在一个实施例中，服务端处理网络日志数据的装置还包括：字段注释模块，用于在确定文件指针为日志文件的第一行或确定日志文件为空文件之后，在日志文件中写入对应于各栏目的注释字段。

在一个实施例中，数据统计模块包括：访问轨迹记录单元，用于将用户的所有访问轨迹记录并不断更新于数据库，访问轨迹至少包括用户的第一次访问时间和存在的所有后续访问时间。

在一个实施例中，数据统计模块还包括：用户状态标识单元，用于在将用户的所有访问轨迹记录并不断更新于数据库之后，根据数据库记录的用户的访问轨迹，将只有第一次访问时间的用户的状态标识为新用户，将存在后续访问时间的用户标识为老用户。

在一个实施例中，数据统计模块还包括：用户状态标识单元，用于在将用户的所有访问轨迹记录并不断更新于数据库之后，根据数据库记录的用户的访问轨迹，将预定周期内存在后续访问时间的用户标识为预定周期留存用户。

基于上述技术方案，通过服务端收集原始日志，减轻了客户端的压力，增加了系统的容错能力（即使屏蔽JS，也不影响日志收集）。另外在日志文件中增加了注释字段，如果需要进行调整日志中的字段顺序、增加或删除某些字段等操作，只需对注释行进行修改，不需修改整个分析统计方法，相比于现有技术，本发明的应用更加灵活方便。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是根据本发明实施例的应用场景的示意图；

图2是根据本发明实施例的服务端处理网络日志数据的方法流程图；

图3是根据本发明另一实施例的服务端处理网络日志数据的方法流程图；

图4是根据本发明实施例的分析日志数据中某一字段的方法流程图；

图5是根据本发明实施例的新老用户判断方法的流程图；

图6是根据本发明实施例的预定周期留存用户的判断方法流程图；

图7是根据本发明实施例的服务端处理网络日志数据的装置结构示意图；

图8是根据本发明另一实施例的服务端处理网络日志数据的装置结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例作进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

现在将参考附图进一步详细描述本发明。本发明可以许多不同的形式来实现，不应该被理解为仅限于此处所阐述的实施例。这些实施例只作为示例提供，以便为本领域技术人员提供对本发明的完全理解。

图1是根据本发明实施例的应用场景的示意图。在应用场景100中包括：用户设备101、原始日志记录服务器102、原始日志清洗服务器104、统计日志存储计算服务器106、统计结果存储服务器108和报表服务器110。

其中，原始日志记录服务器102可以用于记录用户的访问信息，包括访问时间、访问URL、用户ID、用户设备信息等。原始日志记录服务器102还可以预定周期将日志切割为单独的日志文件，例如，每天0点把前一天的日志切割为单独的日志文件，用作增量统计分析。另外，原始日志记录服务器102还可以对日志的字段按实际含义做注释，以便分析日志时，按注释来理解字段含义。原始日志记录服务器102可以定期将处理后的日志同步到原始日志清洗服务器104上，作为清洗日志的数据源。

原始日志清洗服务器104可以用于把所有原始日志记录服务器102发送过来的日志合并为一个日志文件，用以整体分析。原始日志清洗服务器104还可以用于去除统计不要的日志记录，如404或204记录等没有实际意义的访问。原始日志清洗服务器104还可以用于根据已有的日志字段对日志数据进行补充，例如根据产品ID补充产品分类等。原始日志清洗服务器104还可以用于标记用户在不同的统计周期(如日、周、月)的新、老、留存等状态，用于分析用户的新、老、质量等。原始日志清洗服务器104产生的结果可以被同步到统计日志存储计算服务器106中。

统计日志存储计算服务器106可以用于统计分析如服务项目的PV（pageview页面点击量）、UV、留存率、跳出率、停留时间等的各种预定统计项目。统计日志存储计算服务器106还可以用于补充当次统计之外的数据，如昨日的UV、累计到昨日的用户数等，以用于留存率（连续访问）或用户数累计等统计。统计日志存储计算服务器106产生的结果可以被同步到统计结果存储服务器108。在一个实施例中，为了增加系统的稳定性，服务器集群中可以对日志进行不低于三个副本的备份，用于系统容灾。

统计结果存储服务器108可以用于存储按不同周期(如日、周、月)、不同统计维度(如按时间、按地点、按平台、按产品等)、不同数据项(如PV、UV、留存率等)统计之后的结果数据，用于前台的报表查询。统计结果存储服务器108还可以用于对统计结果按时间进行分区、按统计维度进行索引，以支持数以亿计的统计结果。统计结果存储服务器108用于为报表服务器110提供数据。

报表服务器110可以通过连接统计结果存储服务器108来获取数据并在前台通过各种方式进行展示。

图2是根据本发明实施例的服务端处理网络日志数据的方法流程图。

如图2所示的方法200，在步骤202中，记录原始日志数据。

在步骤204中，根据原始日志数据以预定周期生成日志文件。其中，日志文件中的每条日志数据包括多个栏目的内容，并且，各栏目分别具有各自的栏目索引信息。

在步骤206中，查询日志文件中的注释字段，每个注释字段分别记录了日志数据中对应栏目的字段所代表的预定统计项目含义。

在步骤207中，将各注释字段分别与对应栏目的栏目索引信息相关联。

在步骤208中，根据预定统计项目对应栏目的索引信息提取该栏目的日志数据。

在步骤210中，对提取的日志数据进行统计以获取预定统计项目的统计结果。

基于上述技术方案，通过服务端收集原始日志，减轻了客户端的压力，增加了系统的容错能力（即使屏蔽JS，也不影响日志收集）。另外在日志文件中增加了注释字段，如果需要进行调整日志中的字段顺序、增加或删除某些字段等操作，只需对注释行进行修改，不需修改整个分析统计方法，相比于现有技术，本发明的应用更加灵活方便。

图3是根据本发明另一实施例的服务端处理网络日志数据的方法流程图。

如图3所示的方法300，在步骤302中，记录原始日志数据。原始日志数据可以包括用户的访问信息，例如访问时间、访问URL、用户ID、用户设备信息等。

在步骤304中，根据原始日志数据以预定周期（如一天、累计一周、一月等）生成日志文件。对原始日志数据的切割可以用于增量统计分析。

在步骤306中，对日志数据的各栏目按实际含义进行注释，以便分析日志时，按注释来理解字段含义。

在现有技术中，日志字段通常都是通过约定的顺序来表示字段含义。例如，日志记录为：

[1108_1108113_1_1][Android][2.3.6][959770b2fb6997b9ef854f31]

其数组结构为：

[“1108_1108113_1_1”，“Android”，“2.3.6”，“959770b2fb6997b9ef854f31”]

一条日志数据对应一个数组。每条日志数据包括多个栏目的内容。各栏目分别具有各自的栏目索引信息，如下标、列数。在上述日志数据中，可以看出如下标0对应的栏目为数据包package，下标1对应的栏目为平台platform等信息。

现有技术实现起来简单，但维护起来可能有两个问题：1、直接查看日志文件，无法了解每个字段代表的含义；2、如果日志字段需要调整顺序、删除或增加一个字段，现有的处理逻辑就会造成错误。根据本发明的实施方式，可以通过添加注释的方式解决以上问题。例如，如果日志数据发生了如下所示的变化：

[20120910231241][1108_1108113_1_1][Android][2.3.6][959770b2fb6997b9ef854f31]

其数组结构为：

[“20120910231241”，“1108_1108113_1_1”，“Android”，“2.3.6”，“959770b2fb6997b9ef854f31”]

若此时继续用下标0=package,1=platform，则会出现读取错误。

根据本发明的实施例，可以在日志文件中进行注释。例如，在日志文件中加入注释行，注释行包括多个注释字段，每个注释字段分别记录日志数据中对应栏目的字段所代表的预定统计项目的含义。

例如，假设在一个实施例中，日志内容可以为：

#Format:FROM_PACKAGE_ID;PLATFORM;PLATFORM_VERSION;USER_ID

[1108_1108113_1_1][Android][2.3.6][959770b2fb6997b9ef854f31]

[1108_1108118_4_2][J2me][][959770b2fb6997b9ef999371]

其中，第一行为注释行。

如果需要增加字段ACCESS_DATETIME，则可以在日志字段的随意位置，增加ACCESS_DATETIME字段，例如，下面把ACCESS_DATETIME记录到第一个字段。如下：

#Format:ACCESS_DATETIME;FROM_PACKAGE_ID;PLATFORM;PLATFORM_VERSION;USER_ID

[20120910231241][1108_1108113_1_1][Android][2.3.6][959770b2fb6997b9ef854f31]

[20120911000000][1108_1108118_4_2][J2me][][959770b2fb6997b9ef999371]

如果需要删除某一字段，如PLATFORM_VERSION，则可以直接删除PLATFORM_VERSION即可，如下：

#Format:ACCESS_DATETIME;FROM PACKAGE_ID;PLATFORM;USER_ID

[20120910231241][1108_1108113_1_1][Android][959770b2fb6997b9ef854f31]

[20120911000000][1108_1108118_4_2][J2me][959770b2fb6997b9ef999371]

以上，增删某一字段，不需要修改原有的统计逻辑。因此，相比于现有技术，本发明的实施例更具扩展性、灵活性。例如，增加新字段时，可随时在日志文件中的任意列增加，只需增加该列的注释，不需修改分析日志的程序；删除字段时，可随意删除日志文件的任意列，只需去掉相应注释，不需修改分析日志逻辑；修改字段顺序时，只需将注释和相应的日志字段同时调整顺序，不需修改分析日志的程序。

在一个实施例中，可以在预定周期的第一条记录前进行注释。这就需要判断文件指针是否为第一行，或判断日志文件是否为空文件。根据本发明的实施例，可以在确定文件指针为日志文件的第一行或确定日志文件为空文件之后，在日志文件中写入对应于各栏目的注释字段。

在步骤308中，可以将多个日志文件合并为一个日志文件，用以整体分析。

在步骤310中，可以将统计不需要的日志记录删除。

在步骤312中，可以统计分析各种预定统计项目，如服务项目的PV（pageview页面点击量）、UV、留存率、跳出率、停留时间等。

分析日志时，可以先分析注释字段，来获取每个字段代表的含义，然后通过注释字段下标（栏目索引信息）来提取对应列的日志数据。也就是首先读取注释字段，将注释字段与栏目索引信息相关联，如0=package；1=platform。因此，如果日志数据发生变化，只需改变注释字段，在分析数据时，通过关联栏目索引信息就可以自适应的找到对应栏目的日志内容，进而提取所需的字段。

如图4所示为分析某一字段的流程图。参照下文中的日志内容示例，如需分析PLATFORM字段，在步骤402中，查找如#Format:开头的注释行。在步骤404中，通过如“；”的分隔符提取每个字段代表的含义。在一个实施例中，可以通过各种分隔符来分割各字段的注释。在步骤406中，获取PLATFORM字段的下标。在步骤408中，通过如“][”的分隔符来拆分记录行。在步骤410中，按PLATFORM下标提取字段值。

返回图3，在步骤314中，可以根据已有的日志字段对日志数据进行补充，例如根据产品ID补充产品分类；根据UA信息补充用户平台信息等。

在步骤316中，可以对用户在不同的统计周期(如日周月)的新、老、留存等状态进行标识，用于分析用户的新老、质量等。

在现有技术中，客户端记录用户状态，可能出现不稳定(状态容易丢失)、不容易扩展、客户端逻辑错误造成数据损坏等等情况。根据本发明的实施例，可以将用户的所有访问轨迹记录并不断更新于数据库，访问轨迹至少包括用户的第一次访问时间和存在的所有后续访问时间。例如，可以将数据结构设置为如下所示，以方便判断用户状态，提高标记用户状态的效率：

根据本发明的实施例，记录用户访问轨迹的数据库可以具有支持稀疏存储、能够动态扩展字段、能够快速处理（读取/更新）多条用户记录的多个不同字段中的一种或多种性能。另外，在一个实施例中，数据库可以支持多个备份以在数据出现问题时提供恢复功能，还可以支持多台服务器的分布式存储。

在一个实施例中，根据数据库记录的用户的访问轨迹，可以将只有第一次访问时间的用户的状态标识为新用户，将存在后续访问时间的用户标识为老用户。例如，根据用户ID提取用户访问轨迹中的第一次访问时间字段，如果没有提取到用户访问数据，或用户第一次访问时间和当前时间相等，则为新用户；否则为老用户。如图5所示为新老用户判断方法的流程图。在步骤502中，查询用户ID和访问时间。在步骤504中，根据用户ID，从数据库中获取用户的第一次访问时间。如果获取失败，则进入步骤506，更新用户第一次访问时间，并确定为新用户。如果获取成功，则进入步骤508，判断访问时间是否小于等于第一次访问时间，如果是，则进入步骤506，更新用户第一次访问时间，并确定为新用户；如果否，则确定为老用户。

在另一实施例中，根据数据库记录的用户的访问轨迹，可以将预定周期内存在后续访问时间的用户标识为预定周期留存用户。例如，根据用户ID提取用户访问轨迹中的“上月日期”字段的数据，如果没有提取到用户访问数据，则不是月留存用户；否则为月留存用户。如图6所示为预定周期留存用户的判断方法流程图。月留存用户为例，在步骤602中，查询用户ID和访问时间。在步骤604中，在数据库中添加“本月月份”字段。在步骤606中，根据访问时间获取上月的月份。在步骤608中，根据用户ID，从数据库中获取“上月月份”字段。如果成功获取该字段数据，则确定为月留存用户；如果获取失败，则确定为非月留存用户。

通过服务端对用户状态的记录和标记，使数据不容易丢失。通过服务端的数据结构，可以扩展停留时间、访问深度等字段以判断用户粘性、质量等。另外，可以增加、修改统计逻辑，如增加季度新老/留存等，并实现修改/修复留存概念(第二天访问两次以上算日留存等)的容错性。

返回图3，在步骤318中，可以补充当次统计之外的数据，如昨日的UV、累计到昨日的用户数等，以用于留存率（连续访问）或用户数累计等统计。

在步骤320中，存储按不同周期(如日、周、月)、不同统计维度(如按时间、按地点、按平台、按产品等)、不同数据项(如PV、UV、留存率等)统计之后的结果数据，用于前台的报表查询。

在步骤322中，对统计结果按时间进行分区、按统计维度进行索引，以支持数以亿计的统计结果。

在步骤324中，通过各种方式展示统计结果以供用户查询。

方法300中的各步骤的执行不限定于图3所示的顺序。可根据实际应用需要调整各步骤顺序或仅组合其中的某些步骤来形成不同的实施方式。

基于以上技术方案，由于日志收集放到了服务端，所以减轻了客户端的计算压力，并且不需要客户端安装js插件，增加了系统的容错能力。通过在原始日志的头部增加注释行来说明每个字段的含义，有效的解决了日志字段在实际运行中的删除其中几个字段、修改字段含义、调整字段顺序、增加字段等问题。另外，用户状态(按统计周期计算新老留存等)计算放到了服务端，增加了用户状态计算的灵活性(可灵活增/删/改用户状态的计算规则)、准确性(不会因客户端丢失访问时间数据而影响计算结果)、可扩展性(可随时增加新的用户状态)。此外，还可以支持二次统计，由于所有的日志处理(如去除无效数据、补充字段数据、增加用户状态等)都是在服务端进行，所以如果需要对历史数据进行处理，直接重复运行即可。

图7是根据本发明实施例的服务端处理网络日志数据的装置700的结构示意图。装置700包括：原始日志记录模块702、日志文件生成模块704、注释查询模块706、关联模块708、数据提取模块710和数据统计模块712。

原始日志记录模块702，用于记录原始日志数据。

日志文件生成模块704，用于根据所述原始日志数据以预定周期生成日志文件，其中，所述日志文件中的每条日志数据包括多个栏目的内容，并且，各栏目分别具有各自的栏目索引信息。

注释查询模块706，用于查询所述日志文件中的注释字段，每个注释字段分别记录了日志数据中对应栏目的字段所代表的预定统计项目含义。

关联模块708，用于将各所述注释字段分别与对应栏目的所述栏目索引信息相关联。

数据提取模块710，用于根据所述预定统计项目对应栏目的索引信息提取该栏目的日志数据。

数据统计模块712，用于对提取的日志数据进行统计以获取预定统计项目的统计结果。

图8是根据本发明另一实施例的服务端处理网络日志数据的装置800的结构示意图。装置800所包括的原始日志记录模块802、日志文件生成模块804、注释查询模块806、关联模块808、数据提取模块810和数据统计模块812与图7所示的相应模块类似，此处不再赘述，仅对不同处进行详细描述。

图8所示的服务端处理网络日志数据的装置800还包括字段注释模块805，用于在确定文件指针为所述日志文件的第一行或确定所述日志文件为空文件之后，在所述日志文件中写入对应于各栏目的注释字段。

在一个实施例中，如图7或图8所示的数据统计模块712或812可以包括访问轨迹记录单元，用于将用户的所有访问轨迹记录并不断更新于数据库，所述访问轨迹至少包括用户的第一次访问时间和存在的所有后续访问时间。

在一个实施例中，如图7或图8所示的数据统计模块712或812还可以包括第一用户状态标识单元，用于在将用户的所有访问轨迹记录并不断更新于数据库之后，根据所述数据库记录的用户的访问轨迹，将只有第一次访问时间的用户的状态标识为新用户，将存在后续访问时间的用户标识为老用户。

在一个实施例中，如图7或图8所示的数据统计模块712或812还可以包括第二用户状态标识单元，用于在将用户的所有访问轨迹记录并不断更新于数据库之后，根据所述数据库记录的用户的访问轨迹，将预定周期内存在后续访问时间的用户标识为预定周期留存用户。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种服务端处理网络日志数据的方法，其特征在于，包括：

记录原始日志数据；

根据所述原始日志数据以预定周期生成日志文件，其中，所述日志文件中的每条日志数据包括多个栏目的内容，并且，各栏目分别具有各自的栏目索引信息；

查询所述日志文件中的注释字段，每个注释字段分别记录了日志数据中对应栏目的字段所代表的预定统计项目含义；

将各所述注释字段分别与对应栏目的所述栏目索引信息相关联；

根据所述预定统计项目对应栏目的索引信息提取该栏目的日志数据；

对提取的日志数据进行统计以获取预定统计项目的统计结果。

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

在确定文件指针为所述日志文件的第一行或确定所述日志文件为空文件之后，在所述日志文件中写入对应于各栏目的注释字段。

3.根据权利要求1所述的方法，其特征在于，所述对提取的日志数据进行统计以获取预定统计项目的统计结果的步骤包括：

将用户的所有访问轨迹记录并不断更新于数据库，所述访问轨迹至少包括用户的第一次访问时间和存在的所有后续访问时间。

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

在将用户的所有访问轨迹记录并不断更新于数据库之后，根据所述数据库记录的用户的访问轨迹，将只有第一次访问时间的用户的状态标识为新用户，将存在后续访问时间的用户标识为老用户。

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

在将用户的所有访问轨迹记录并不断更新于数据库之后，根据所述数据库记录的用户的访问轨迹，将预定周期内存在后续访问时间的用户标识为预定周期留存用户。

6.一种服务端处理网络日志数据的装置，其特征在于，包括：

原始日志记录模块，用于记录原始日志数据；

日志文件生成模块，用于根据所述原始日志数据以预定周期生成日志文件，其中，所述日志文件中的每条日志数据包括多个栏目的内容，并且，各栏目分别具有各自的栏目索引信息；

注释查询模块，用于查询所述日志文件中的注释字段，每个注释字段分别记录了日志数据中对应栏目的字段所代表的预定统计项目含义；

关联模块，用于将各所述注释字段分别与对应栏目的所述栏目索引信息相关联；

数据提取模块，用于根据所述预定统计项目对应栏目的索引信息提取该栏目的日志数据；

数据统计模块，用于对提取的日志数据进行统计以获取预定统计项目的统计结果。

7.根据权利要求6所述的装置，其特征在于，还包括：

字段注释模块，用于在确定文件指针为所述日志文件的第一行或确定所述日志文件为空文件之后，在所述日志文件中写入对应于各栏目的注释字段。

8.根据权利要求6所述的装置，其特征在于，所述数据统计模块包括：

访问轨迹记录单元，用于将用户的所有访问轨迹记录并不断更新于数据库，所述访问轨迹至少包括用户的第一次访问时间和存在的所有后续访问时间。

9.根据权利要求8所述的装置，其特征在于，所述数据统计模块还包括：

用户状态标识单元，用于在将用户的所有访问轨迹记录并不断更新于数据库之后，根据所述数据库记录的用户的访问轨迹，将只有第一次访问时间的用户的状态标识为新用户，将存在后续访问时间的用户标识为老用户。

10.根据权利要求8所述的装置，其特征在于，所述数据统计模块还包括：

用户状态标识单元，用于在将用户的所有访问轨迹记录并不断更新于数据库之后，根据所述数据库记录的用户的访问轨迹，将预定周期内存在后续访问时间的用户标识为预定周期留存用户。

Images