CN103546514B - 一种处理延迟发送的日志数据的方法和系统 - Google Patents

Abstract

本方案涉及处理延迟发送的日志数据的装置、系统和方法。该装置包括：日志接收模块，用于接收由终端侧发送的用户行为日志，其中用户行为日志包含终端侧采集到的日志数据及其实际发生时间；延迟判断模块，用于根据实际发生时间判断在日志接收模块接收的用户行为日志为延迟还是非延迟日志；初始计算模块，用于根据日志数据的实际发生时间，按预设策略对延迟判断模块判断的非延迟日志的日志数据进行初始计算；修正计算模块，用于根据延迟判断模块判断的属于延迟日志的日志数据及其实际发生时间，按预设策略对初始计算模块的计算结果进行修正计算；结果输出模块，用于将初始计算模块与修正计算模块的计算结果进行输出。

Description

一种处理延迟发送的日志数据的方法和系统

技术领域

本申请涉及移动数据处理技术领域，尤其涉及移动数据平台中处理延迟发送的日志数据的装置、系统和方法。

背景技术

随着移动互联网的迅猛发展，移动应用(App，应用程序)市场的竞争也日趋激烈，移动应用的开发者要发展就必须为用户提供优质的产品功能与服务，并能够针对市场变化和用户需求做出快速反应。为此，实时采集并分析用户的使用习惯，是把握最新用户需求和优化用户体验的关键一步。但由于移动应用的特殊性，与传统互联网不同，其用户的操作行为大多是在手机客户端上完成的，这也意味着用户行为日志必须传到服务器后，才能被开发者进行分析处理，实现应用的监测和优化等。

但由于移动应用的特殊性，用户的行为日志有时往往不能够实时传回到服务器，这有两方面原因：一方面是一些离线类应用(如离线游戏、电子读物)，其用户在使用应用的大多数时候是不需要用手机联网的，这就导致其在离线(脱网)时所产生的行为日志只有等用户下次使用该应用联网时才能发回服务器，这个时间延迟有可能是数天、数周、甚至数月，完全由应用自身决定；另一方面是，由于目前移动应用的上传过程都是会产生流量的，通过WIFI方式一般是不计流量费用的，但如果通过GPRS或其他移动通讯商的收费联网方式上传日志到服务器所产生的流量则是要计费的，所以导致应用开发者为了顾及用户感受，不得不将行为日志发回服务器的时机安排在不计流量费用时发送，这也导致了一部分日志数据延迟发回服务器，其延迟时间可能为数个小时或数天。另外，考虑到数据压缩，日志采集器往往也会缓存一部分日志后再发送，这个过程也会导致日志发送过程的延迟。

日志延迟发回服务器，如果时间较长，超过了日志数据计算频度的时间间隔，就会造成数据失真，从而不能按时全面地为应用开发者展现客户真实准确的结果。对于这个问题，现有的移动应用技术的处理策略大概分为两大类：(1)忽略接收到的延迟发送过来的日志数据；(2)认可延迟发送过来的日志数据，并再一次计算操作时反映到结果中，相当于一种数据修正。第一种策略，操作简单、计算量小，但所带来的问题就是没有全面地反映用户的实际使用情况的总量，如果应用的离线日志程度很高的话，则应用开发者在服务器上所看到结果就严重失真了。第二种策略，对结果进行了必要的修正，但计算的时间空间复杂度会增加很多，这是因为需要重新计算延迟发送日志数据所在实际发生时间所涉及的所有指标，时间复杂度将增加，而为了完成修正，有些修正计算还需要保存之前的中间结果(比如独立用户数列表)，也会造成空间复杂度将要增加；并且往往是时间离得越近则修正的作用越不明显(因为数据延迟时间长度的概率分布往往不是几个小时，而可能是几天左右)，从而导致在对数据进行趋势分析时，修正后的计算结果往往会在近期出现一些下滑的趋势，过一段时间修正完后，又会发现之前的下滑不存在了，这种不稳定性的下滑往往不能代表真实的趋势方向，而完全是由于数据延迟所造成，从而给应用开发者的数据分析带来干扰。

由于移动应用在用户手机端所产生的日志数据因诸如上述多种原因往往不能及时发回服务器，而当这种延迟的时间间隔超过了操作的时间间隔时，就会需要考虑在下次计算操作时对其之前所有计算结果是否需要进行数据修正。如果不在之后修正的话就会影响计算结果的全面性与真实准确性；而如果在收到延迟数据后进行数据修正，不单计算时间空间复杂度会增加很多，同时数据计算结果也将会具有一定的不稳定性(尤其是在趋势分析时所带来的失真下滑)。可见，现有的移动应用计算技术存在的移动应用日志数据延迟发送造成数据不全面准确，进而导致简单数据修正策略计算量过大且数据失真等缺陷。

发明内容

针对上述现有技术的缺陷，本申请要解决的技术问题是提供一种处理延迟发送的日志数据的装置、系统和方法，其针对移动应用日志延迟发送所带来的计算不够全面准确的问题，以及进行简单数据修正策略所带来的计算量过大与数据失真等问题，在该处理延迟发送的日志数据的装置、系统和方法中，采用了一种优化的“修正前”与“修正后”两套计算指标相结合的计算与分析策略。

本申请提供的一种处理延迟发送的日志数据的装置，用于网络侧服务器，包括：日志接收模块，用于接收由终端侧发送的用户行为日志，其中，所述用户行为日志包含终端侧采集到的日志数据及其实际发生时间；延迟判断模块，用于根据所述实际发生时间判断在日志接收模块接收的用户行为日志为延迟日志还是非延迟日志；初始计算模块，用于根据日志的日志数据的实际发生时间，按预设策略对延迟判断模块判断的非延迟日志的日志数据进行初始计算；修正计算模块，用于根据延迟判断模块判断的属于延迟日志的日志数据及其实际发生时间，按预设策略对所述初始计算模块的计算结果进行修正计算；结果输出模块，用于将所述初始计算模块与修正计算模块的计算结果进行输出。

本申请还提供的一种处理延迟发送的日志数据的系统，包括终端及服务器，所述终端中包括至少一个应用，其中，所述终端进一步包括：日志采集模块，用于采集针对预设应用的日志数据并生成用户行为日志，发送至所述服务器，其中所述用户行为日志中包含采集到的日志数据及其实际发生时间；所述服务器包括：日志接收模块，用于接收由终端侧发送的所述用户行为日志，其中，所述用户行为日志包含终端侧采集到的日志数据及其实际发生时间；延迟判断模块，用于根据所述实际发生时间判断在日志接收模块接收的用户行为日志为延迟日志还是非延迟日志；初始计算模块，用于根据日志的日志数据的实际发生时间，按预设策略对延迟判断模块判断的非延迟日志的日志数据进行初始计算；修正计算模块，用于根据延迟判断模块判断的属于延迟日志的日志数据及其实际发生时间，按预设策略对所述初始计算模块的计算结果进行修正计算；结果输出模块，用于将所述初始计算模块与修正计算模块的计算结果进行输出。

本申请还提供一种处理延迟发送的日志数据的方法，用于网络侧服务器，包括：接收由终端侧发送的用户行为日志，其中所述用户行为日志中包含终端侧采集到的日志数据及其实际发生时间；用于根据所述实际发生时间判断接收的用户行为日志为延迟日志还是非延迟日志；根据日志的日志数据的实际发生时间，按预设策略对判断为非延迟日志的日志数据进行初始计算；根据判断属于延迟日志的日志数据及其实际发生时间，按预设策略对所述初始计算模块的计算结果进行修正计算；将所述对用户行为数据的初始计算结果与修正计算结果进行输出。

本申请还提供一种处理延迟发送的日志数据的方法，用于包括终端及服务器的网络，所述终端中包括至少一个应用，其中，所述方法包括如下步骤：在终端侧采集针对预设应用的日志数据并生成用户行为日志，发送至所述服务器，其中所述用户行为日志中包含采集到的日志数据及其实际发生时间；在服务器侧接收由终端侧发送的所述用户行为日志，其中所述用户行为日志中包含终端侧采集到的日志数据及其实际发生时间；根据所述实际发生时间判断所述接收的用户行为日志为延迟日志还是非延迟日志；根据日志的日志数据的实际发生时间，按预设策略对判断为非延迟日志的日志数据进行初始计算；根据对判断属于延迟日志的日志数据及其实际发生时间，按预设策略对日志数据的初始计算结果进行修正计算；将所述初始计算与修正计算的计算结果进行输出。

为了解决这一系列问题，本申请提出的上述技术方案，实现了一种优化的“修正前”与“修正后”两套数据采集计算相结合的数据处理方法，避免了只计算修正前或只计算修正后的日志数据所带来的结果不全面准确、数据失真的困扰，同时还达到避免进行简单数据修正所造成的计算量过大的目的。

附图说明

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

图1为移动用户日志数据延迟发送的处理框图。

图2为本申请具体实施方式的延迟传送的日志数据的处理框图。

图3为本申请具体实施方式的“修正前”和“修正后”显示图。

图4为本申请具体实施方式的延迟传送的日志数据处理流程图。

图5为本申请具体实施方式的结构框图。

具体实施方式

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

在诸如CNZZ移动数据平台的等技术中，移动终端101上的APP应用被用户操作后会生成应用的日志数据，实时传回给服务器111：日志采集器103、107、离线采集/发送105，从而使得移动数据平台能帮助开发者实时监控应用App的使用情况(分析113)，优化115应用的开发。但通常会存在延迟传送109该日志数据的情况。日志数据通常记录在诸如用户行为日志中缓存在终端本地当联网时发送到服务器，或者实时发送到服务器。

其中，日志数据包含但不限于：App的系统运行状态信息、用户行为数据/信息以及这些数据或信息的实际发生时间(日志数据的实际发生时间)。

图2描述本申请具体实施方式的移动应用延迟传回的日志数据的修正处理框图。框图中包括实现本申请处理方法和系统的组成部分：移动终端201，App移动应用(应用程序)203，应用日志计算模块205，实时传回的日志207，延迟传回的日志209，服务器211，计算模块213，修正计算模块215，时间轴217，修正前的各周期的计算结果219(如图示上方圆圈中的T、T-1、……、T-k、T-k-1)，修正后的各周期的计算结果221(如图示下方圆圈中的T、T-1、……、T-k、T-k-1)，k代表修正计算模块215中的有效修正期，k的类型随时刻T的变化，如T为日(按日计算，该日内，即T的范围内)则k代表天数，可以设置为日(通常，k为整数)；T为年(按年计算，该年内，即T的范围内)则该k代表年数，可以设置为年；T为小时，k可以设置为小时，等等。而T、T-1、……、T-k、T-k-1为计算日志数量的某个时刻，T时刻代表了一个时间点，T-k代表T时刻之前的k个统计周期的时间点。

图2展示了在某个计算时刻T，移动应用203传回日志数据的处理情况。

移动终端201如手机、平板电脑等便携式移动设备上的App应用203在用户使用/运行后，应用日志计算模块205会对该应用203的日志数据进行初步处理，如简单的采集计算等，并将该日志数据发送到服务器211。终端201采集用户行为日志时，在每份日志中包含用户行为数据和“实际发生时间”，而服务器211端接收日志时给每份日志有“实际接收时间”。服务器211每次收到的应用日志数据，如果其“实际发生时间”在上一次计算操作之前，则其为延迟发送的日志数据或称延迟传回的日志209。

沿着时间轴217，进行每个周期的日志数据的计算：在时刻T进行计算操作时，如果传到服务器211的日志的“实际发生时间”在该计算操作发生的时刻T，则为实时传回的日志207，利用服务器211上的计算模块213计算这些实时传回的日志207的日志数据，该计算模块213不计算延迟传回的日志209的用户行为数据。计算完成则输出计算了的日志的结果即修正前的结果。

而由于实际情况下常常存在着延迟传回的日志209(或称延迟发送的日志)，如：在时刻T进行计算操作时，传到服务器211的日志的“实际发生时间”在进行计算操作的时刻T之前，判断其为延迟发送的日志209，则需要利用服务器211上的修正计算模块215对修正前的结果进行修正计算即获得修正后的结果。修正后的结果与上述修正前的结果一同输出。

在时刻T进行日志数据计算操作。移动应用App203延迟传回日志209的数据参与计算修正215的过程，也就是延迟传回的日志209送达修正计算模块215，参与计算的修正。每次接收到手机客户端201延迟发送来的日志209，会重新计算其数据到该延迟发送来的日志209的“实际发生时间”当时所属的计算结果中，以实现对数据的修正。而本方案，不是无限制地对所有实际发生时间当时所属的计算结果都进行修正，而是预先设置了k代表的有效修正期,日志“实际发生时间”与当前计算时间相差大于一定阈值，将不再对该计算结果进行修正。例如：对于延迟传回的日志209，根据日志的“实际发生时间”去找到其应该被修正的那一期(即前面所述统计“周期”)的日志的数据计算结果，如果那一期已经超过了有效修正期区间[T-1,T-k]，不在该区间内(即“实际发生时间”与当前计算时间相差大于了一定阈值)，则不再修正计算。此策略是为了控制修正对日志的数据的计算所带来的时间空间复杂度快速增长的一种优化方法，通过k这一“有效修正期”的设置，一定程度上有效控制了修正行为带来的计算时间空间复杂度的增长(限制了一个区间、区域)。由此，既全面真实地考虑了实际的数据状况避免数据失真，又减少简单数据修正的计算量以提高数据处理效率。

在下面的处理延迟日志数据的方法流程中将进一步举例描述修正计算。

“修正前”219和“修正后”221的日志的数据的计算结果都将保存起来，并在图3的趋势图中一同展现。

在图3中，演示了某个应用的日志计算，按每天计算一次的频率下，所体现出的某段时间内，如该应用的日趋势比较，根据本申请方案，展示了2012年02月21日至2012年03月05日两个星期(此处，由于以天为一个统计周期，则两个星期代表14个统计周期)内，修正前和修正后的两条“启动用户数”每天(如对日志计算数据的时刻T如3月5日开始，3月5日、3月4日、……2月21日)的对比以及这段时间(时刻T如3月5日开始，前两周如追溯到2月21日)形成的曲线对比：“修正前”与“修正后”的两条“启动用户数”的趋势线(图示假设当前计算操作时间为3月5日)。

其中，虚线代表“修正前”的趋势线：忽略接收到的延迟发送过来的日志，仅计算某时刻及其以前的每个周期的实时传回的日志207的数据。比如：有5200个用户的日志“实际发生时间”为02月27日、这些日志被传到服务器211并于02月27日这个时间的计算操作中被执行数据计算，同样，2月21日3900、……2月24日4550、……3月5日7150。但02月27日还收到了300个日志“实际发生时间”为2月24日、和500个日志“实际发生时间”为02月21日的日志，但这300或500个日志在此都不计算其数据而是忽略掉，让其转到修正计算模块215进行修正处理。输出上述从2月21日开始到3月5日每天的修正前的结果，图3所示“虚线”。

实线代表的是“修正后”的趋势线：认可延迟发送过来的日志209，并再一次计算操作时反映到计算结果中，而该再一次的计算操作，要求根据日志的“实际发生时间”去找到其应该被修正的那一期计算结果，如果那一期超过了有效修正期区间[T-1,T-k]内则不再修正。比如：3月5日的计算操作中，还收到100个日志“实际发生时间”为2月29日、和200个日志“实际发生时间”为02月24日的日志，在修正计算模块215中，会找到这100个日志的“实际发生时间”——2月29日以及这200个日志“实际发生时间”——02月24日。当前计算操作时间T为3月5日(按日计算)，有效修正期k设为6，则有效修正期区间[3月4日，2月28日]。由于2月24日的不在有效修正区间内，于是，该200个日志的数据不再在2月24日中进行计算,2月24日显示的修正后的数据，应当保持在前一周期，其以k为6、若当前计算操作时间T为2月27日时已经修正过的2月24日计算这“9100”的日志的数据，输出显示就保持为9100。由于2月29日在有效修正区间内，则该100个日志的数据应再在2月29日进行计算，2月29日显示的修正后的11700中就包含了后加上去的这100。

当k设为10，当前计算操作时间T为3月5日，有效修正期区间[3月4日，2月24日]，那么2月24日的200个日志、2月29日的100个日志都包括到9100、11700中，即显示的9100包含这200个日志，11700中包含这100个日志。通常k固定了、计算的区间也就固定了、对应该k的各个周期、计算时刻的修正结果也会在k限定的区间内对应保存下来。

通过“数据修正”行为，考虑了延迟发送来的日志，对于日志数据计算的全面性的保证；通过保留“修正前”的计算结果，避免了数据延迟所可能带来的短期趋势的失真。同一张趋势图(图3所示)中，对比展示修正前和修正后的结果，能更加全面客观地进行分析，也可以说，在一定程度上能揭示应用用户离线数据的占比。

参见图3可见，对于开发者来说，该趋势图展示了，修正后的计算量比修正前的明显要高很多。这是因为有大量的日志是延迟发送过来的，且这个差距也能反映出延迟发所日志的比例，并可作为离线上网用户量的一种估计基础，所以“修正”操作是对计算的全面客观准确性很有必要的操作。但如果单纯看这条“修正后”的趋势线，会发现在近期有一个明显的下滑，但这其实并不是真实的趋势，而是由于近期的延迟的数据尚未发回服务器，所带来的失真下滑，而“修正前”的趋势线却平稳地反映出此应用的启动用户数其实是稳定增长的，这才是真实的趋势。因此，修正前和修正后两条趋势线的一起联合展现给开发者或使用该计算平台的用户带来更全面的数据分析价值。

下面将结合图4描述本申请具体实施方式的数据处理流程。

移动终端201上的应用203被用户操作，由应用日志计算模块205初始处理，传送日志数据到服务器211，开始计算某计算时刻T的用户操作应用的某项日志数据。

步骤401，从移动终端201获得的日志数据207、209传回到服务器211，日志包含实时传回的日志207、延迟传回的日志209，日志包含用户行为数据及其实际发生时间。

在步骤403，判断接收(即移动终端发送到服务器211的)的是否为延迟传回的日志209：日志实际发生时间(如3月3日发生)在上一次计算操作(如3月4日的计算操作)之前，则此时收到的该日志为延迟传回的日志209，即判断为“是”。该日志进入修正计算模块215，在步骤407完成利用延迟日志的数据的修正。设置一个k值，代表有效修正期。比如，在当前计算时刻T时刻(如图3所示的2012年3月5日)，设置k为10，按日趋势比较。延迟日志209能够进行修正计算的区间为该延迟日志的实际发生时间是在[2012年3月4日，2012年2月24日]内，超过该区间的实际发生日志的日期如2012年2月21日的100个延迟日志，则那一期(2012年2月21日)的计算结果虽然也需要被修正，但是由于该期不在上述区间内，那么不作为修正计算的数据使用，将在3月5日收到的实际发生时间为2月21日的100个日志不再加入到以往已经修正过的2月21日的结果中。当然，如果k为13，则有效修正区间为[2012年3月4日，2012年2月21日],3月5日收到的实际发生时间为2月21日的日志加入到修正前的3900上得到最后的7800。由此控制了修正行为带来的计算时间空间复杂度的增长。

在步骤411，沿着时间轴217，形成修正后的趋势曲线，并在上述计算趋势图中显示T时刻往前各周期的修正后的计算结果221，如图2下方的T、T-1、T-2、T-k、T-k-1(k代表着修正有效期，即只修正多少个统计周期以内收到的延迟日志)，从而控制修正操作的时间空间计算复杂度，即有所限制(比如：在T时刻收到T-k-1这个时间点的延迟日志，我们也就不会把这份数据再修正了，只是修正T时刻收到实际在T-1到T-k之间发生的日志)。

在步骤403，如果判断接收的不是延迟日志209而是每个计算时刻对应的实时传回的日志207(计算时刻得到的日志的实际发生时间与计算时刻相符，比如3月1日实际发生的日志，在3月1日的计算操作时已经被接收并计入)，即判断为“否”，则该日志进入计算模块213，在步骤405完成实时日志的计算，并在步骤409，沿着时间轴217，形成修正前的趋势曲线，并在计算趋势图中显示T时刻往前各周期的修正前的计算结果219，如图2上方的T、T-1、T-2、T-k、T-k-1。

根据显示的两条曲线，开发者或使用者能进行对比分析，避免数据延迟可能带来的短期趋势失真，全面客观准确地反应用户操作应用203的真实情况，防止数据真实度的不稳定性。基于优化的延迟日志数据的处理方式，提高了计算效率，保证了应用使用情况的监控真实性和可靠性，有助于开发者优化应用。

再结合图5的结构框图描述本方案的具体实施手段。

包括终端及服务器的处理延迟发送的日志数据的系统，所述终端中包括至少一个应用，以及采集针对预设应用的用户行为数据并生成用户行为日志、并发送至所述服务器的日志采集模块，该用户行为日志中包含采集到的用户行为数据及其实际发生时间。对应的处理步骤为：在终端侧采集针对预设应用的用户行为数据并生成用户行为日志，发送至所述服务器。

而用于网络侧服务器的处理延迟发送的日志数据装置，包含：接收由终端侧发送的用户行为日志的日志接收模块501，该用户行为日志包含终端侧采集到的用户行为数据及其实际发生时间；根据所述实际发生时间判断在日志接收模块接收的用户行为日志为延迟日志还是非延迟日志的延迟判断模块503；根据日志数据的实际发生时间，按预设策略对延迟判断模块判断的非延迟日志的用户行为日志中的用户行为数据进行初始计算的初始计算模块502；根据延迟判断模块判断的属于延迟日志的用户行为日志中的用户行为数据及其实际发生时间，按预设策略对所述初始计算模块的计算结果进行修正计算的修正计算模块504；以及将所述初始计算模块与修正计算模块的计算结果进行输出的结果输出模块505。对应的处理步骤为：在服务器侧接收由终端侧发送的用户行为日志；根据所述实际发生时间判断在所述接收的用户行为日志为延迟日志还是非延迟日志；根据日志数据的实际发生时间，按预设策略对判断为非延迟日志的用户行为日志中的用户行为数据进行初始计算；根据对判断属于延迟日志的用户行为日志中的用户行为数据及其实际发生时间，按预设策略对所述用户行为数据的初始计算结果进行修正计算；将所述初始计算与修正计算的计算结果进行输出。

进一步的，修正计算模块504判断延迟数据的实际发生时间与所述初始计算模块502执行的初始计算的时间之间的差距，如果所述差距在预设阈值范围内，则根据接收到的延迟数据及其实际发生时间，按预设策略对所述初始计算模块502的初始计算结果进行修正计算。或者，初始计算模块502在预设计算周期内，根据日志数据的实际发生时间，按预设策略对接收到的用户行为日志中的用户行为数据进行初始计算；所述修正计算模块504根据延迟数据的实际发生时间，确定该延迟数据应归属的计算周期，并按预设策略对该计算周期所对应的初始计算结果进行修正计算。对应的处理步骤为：修正计算步骤，判断延迟数据的实际发生时间与所述初始计算的时间之间的差距，如果所述差距在预设阈值范围内，则根据接收到的延迟数据及其实际发生时间，按预设策略对所述初始计算结果进行修正计算；或者，初始计算步骤，在预设计算周期内，根据日志数据的实际发生时间，按预设策略对接收到的用户行为日志中的用户行为数据进行初始计算；而修正计算步骤，根据延迟数据的实际发生时间，确定该延迟数据应归属的计算周期，并按预设策略对该计算周期所对应的初始计算结果进行修正计算。

本方案在采集用户行为日志时，将会在每份日志中给出“实际发生时间”，而在服务器端收集日志时，也会给每份日志的“实际接收时间”。所谓“修正前”这类预设计算策略，是指服务器每次收到手机客户端发来的应用日志时，如果其“实际发生时间”是在上一次日志数据计算操作之前(即其为延迟发送的日志)，则不再重新回填到上次的计算结果中(即不再修正上次的计算结果，抛弃式计算)；而所谓“修正后”是指每次接收到的手机客户端延迟发送来的日志，将会重新到实际发生时间当时所属的计算结果中进行其日志数据的计算(即修正当时的计算结果)。为了避免修正所带来时间空间复杂度无限制地增长，本方案设定一个有效修正期k(即数据实际发生时间与当前的计算时间相差大于一定阈值时，将不再对其进行数据修正)，这样的预设计算策略将会使修正过程所带来的时间空间复杂度的增长被控制在一定范围内。

在进行数据分析时，尤其是趋势分析，随着时间变化同一个计算策略将分别提供“修正前”和“修正后”两套值两条趋势线。“修正前”的趋势线采用的“修正前”的计算策略值，从计算学概率角度看，大量用户的平均数据延迟时间是一个相对稳定的分布，所以其对数据准确性干扰所带来的误差也是稳定的，因此“修正前”的趋势线也能较稳定地代表了该计算指标当前的真实趋势。而“修正后”的趋势线采用的“修正后”的计算策略值，“修正后”的计算策略值往往都要高于“修正前”，两者之差从某种意义上也能部分地代表用户“离线”模式下所产生的数据行为。同时，修正后的数据还能够向应用开发者真实全面准确地描述出应用曾经实际发生的用户行为。

本说明书中的各个实施例一般采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块或单元。一般地，程序模块或单元可以包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。一般来说，程序模块或单元可以由软件、硬件或两者的结合来实现。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块或单元可以位于包括存储设备在内的本地和远程计算机存储介质中。

最后，还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其主要思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (8)

1.一种处理延迟发送的日志数据的装置，用于网络侧服务器，其特征在于，包括：

日志接收模块，用于接收由终端侧发送的用户行为日志，其中，所述用户行为日志包含终端侧采集到的日志数据及其实际发生时间；

延迟判断模块，用于根据所述实际发生时间判断在日志接收模块接收的用户行为日志为延迟日志还是非延迟日志；

初始计算模块，用于根据日志的日志数据的实际发生时间，按预设策略对延迟判断模块判断的非延迟日志的日志数据进行初始计算；

修正计算模块，用于判断延迟日志的日志数据的实际发生时间与所述初始计算模块执行的初始计算的时间之间的差距，如果所述差距在预设阈值范围内，则根据延迟判断模块判断的属于延迟日志的日志数据及其实际发生时间，按预设策略对所述初始计算模块的计算结果进行修正计算；

结果输出模块，用于将所述初始计算模块与修正计算模块的计算结果进行输出。

2.如权利要求1所述的装置，其特征在于：

所述初始计算模块进一步用于在预设计算周期内，根据非延迟日志的日志数据的实际发生时间，按预设策略对接收到的非延迟日志的日志数据进行初始计算；

所述修正计算模块进一步用于根据延迟日志的日志数据的实际发生时间，确定该延迟日志的日志数据应归属的计算周期，并按预设策略对该计算周期所对应的初始计算结果进行修正计算。

3.一种处理延迟发送的日志数据的系统，包括终端及服务器，所述终端中包括至少一个应用，其特征在于：

所述终端进一步包括：

日志采集模块，用于采集针对预设应用的日志数据并生成用户行为日志，发送至所述服务器，其中所述用户行为日志中包含采集到的日志数据及其实际发生时间；

所述服务器包括：

日志接收模块，用于接收由终端侧发送的所述用户行为日志，其中，所述用户行为日志包含终端侧采集到的日志数据及其实际发生时间；

延迟判断模块，用于根据所述实际发生时间判断在日志接收模块接收的用户行为日志为延迟日志还是非延迟日志；

初始计算模块，用于根据日志的日志数据的实际发生时间，按预设策略对延迟判断模块判断的非延迟日志的日志数据进行初始计算；

修正计算模块，用于判断延迟日志的日志数据的实际发生时间与所述初始计算模块执行的初始计算的时间之间的差距，如果所述差距在预设阈值范围内，则根据延迟判断模块判断的属于延迟日志的日志数据及其实际发生时间，按预设策略对所述初始计算模块的计算结果进行修正计算；

结果输出模块，用于将所述初始计算模块与修正计算模块的计算结果进行输出。

4.如权利要求3所述的系统，其特征在于：

所述初始计算模块进一步用于在预设计算周期内，根据非延迟日志的日志数据的实际发生时间，按预设策略对接收到的非延迟日志的日志数据进行初始计算；

所述修正计算模块进一步用于根据延迟日志的日志数据的实际发生时间，确定该延迟日志的日志数据应归属的计算周期，并按预设策略对该计算周期所对应的初始计算结果进行修正计算。

5.一种处理延迟发送的日志数据的方法，用于网络侧服务器，其特征在于，包括：

接收由终端侧发送的用户行为日志，其中所述用户行为日志中包含终端侧采集到的日志数据及其实际发生时间；

用于根据所述实际发生时间判断接收的用户行为日志为延迟日志还是非延迟日志；

根据日志的日志数据的实际发生时间，按预设策略对判断为非延迟日志的日志数据进行初始计算；

判断延迟日志的日志数据的实际发生时间与所述初始计算的时间之间的差距，如果所述差距在预设阈值范围内，则根据判断属于延迟日志的日志数据及其实际发生时间，按预设策略对初始计算的计算结果进行修正计算；

将对日志数据的初始计算结果与修正计算结果进行输出。

6.如权利要求5所述的方法，其特征在于：

所述初始计算步骤进一步包括：在预设计算周期内，根据非延迟日志的日志数据的实际发生时间，按预设策略对接收到的非延迟日志的日志数据进行初始计算；

所述修正计算步骤进一步包括：根据延迟日志的日志数据的实际发生时间，确定该延迟日志的日志数据应归属的计算周期，并按预设策略对该计算周期所对应的初始计算结果进行修正计算。

7.一种处理延迟发送的日志数据的方法，用于包括终端及服务器的网络，所述终端中包括至少一个应用，其特征在于，所述方法包括如下步骤：

在终端侧采集针对预设应用的日志数据并生成用户行为日志，发送至所述服务器，其中所述用户行为日志中包含采集到的日志数据及其实际发生时间；

在服务器侧接收由终端侧发送的所述用户行为日志，其中所述用户行为日志中包含终端侧采集到的日志数据及其实际发生时间；

根据所述实际发生时间判断所述接收的用户行为日志为延迟日志还是非延迟日志；

根据日志的日志数据的实际发生时间，按预设策略对判断为非延迟日志的日志数据进行初始计算；

判断延迟日志的日志数据的实际发生时间与所述初始计算的时间之间的差距，如果所述差距在预设阈值范围内，则根据对判断属于延迟日志的日志数据及其实际发生时间，按预设策略对日志数据的初始计算结果进行修正计算；

将所述初始计算与修正计算的计算结果进行输出。

8.如权利要求7所述的方法，其特征在于：

所述初始计算步骤进一步包括：在预设计算周期内，根据非延迟日志的日志数据的实际发生时间，按预设策略对接收到的非延迟日志的日志数据进行初始计算；

所述修正计算步骤进一步包括：根据延迟日志的日志数据的实际发生时间，确定该延迟日志的日志数据应归属的计算周期，并按预设策略对该计算周期所对应的初始计算的结果进行修正计算。