一种数据处理的方法及装置.pdf

本申请公开了一种数据处理的方法及装置，用以解决现有技术中事件信息的处理效率较低的问题。该方法实时计算系统对当前事件信息处理得到结果数据后，根据该结果数据携带的数据标识，判断该数据标识对应的写入时刻到当前时刻的时间长度是否超过设定时间长度，若是，则将该结果数据写入到数据库中，并将该数据标识对应的写入时刻更新为当前时刻，否则保存该结果数据，并处理下一个事件信息。上述方法由于只有在写入时刻到当前时刻的时间长度超过设定时间长度时才将结果数据写入到数据库，其余时间可处理后续的事件信息，因此可在保证实时计算系统和数据库中的数据一致的前提下，有效提高事件信息的处理效率。

1.  一种数据处理的方法，其特征在于，包括：
对当前事件信息进行处理，得到结果数据，并保存在本地；
根据所述结果数据携带的数据标识，确定记录的所述数据标识对应的写入时刻，所述写入时刻为上一次将携带所述数据标识的结果数据写入到数据库中的时刻；
判断所述写入时刻到当前时刻的时间长度是否超过设定时间长度；
若是，则将本地保存的所述结果数据写入到数据库中，并将所述数据标识对应的写入时刻更新为当前时刻；
否则，继续在本地保存所述结果数据，并对下一个事件信息进行处理。

2.  如权利要求1所述的方法，其特征在于，所述当前事件信息和所述下一个事件信息包括物流事件信息，所述结果数据包括物流结果数据。

3.  如权利要求1所述的方法，其特征在于，当前事件信息中携带属性信息，属性信息与处理进程以及数据标识对应；
对当前事件信息进行处理，得到结果数据，具体包括：
根据所述当前事件信息中携带的属性信息，将所述当前事件信息分配给所述属性信息对应的处理进程；
所述处理进程根据所述当前事件信息，对本地保存的携带所述属性信息对应的数据标识的结果数据进行更新，将更新后的结果数据作为对当前事件信息进行处理得到的结果数据。

4.  如权利要求3所述的方法，其特征在于，对本地保存的携带所述属性信息对应的数据标识的结果数据进行更新，具体包括：
提取本地保存的携带所述属性信息对应的数据标识的结果数据，并对提取的结果数据进行更新；
若未从本地提取到携带所述数据标识的结果数据，则从数据库中读取携带所述数据标识的数据到本地，并对读取到本地的数据进行更新。

5.  如权利要求3所述的方法，其特征在于，所述方法还包括：
所述处理进程将得到的所述结果数据记录在日志文件中；
对所述处理进程进行监控；
当监控到所述处理进程异常时，针对所述处理进程对应的每个数据标识，将所述处理进程在所述日志文件中最后一次记录的携带该数据标识的结果数据写入到数据库中。

6.  如权利要求1所述的方法，其特征在于，所述方法还包括：
在满足预设触发条件时，将本地保存的所有结果数据写入到数据库中；
其中，所述预设触发条件包括：接收到将本地保存的结果数据写入到数据库中的写入指令。

7.  如权利要求6所述的方法，其特征在于，所述方法还包括：
预先在所述数据库中设定指定业务类型，所述数据库在接收到用户的查询请求后，判断查询请求中携带的所要查询的业务类型是否为预设的指定业务类型，若是，则发送将指定业务类型的结果数据写入到数据库中的写入指令。

8.  一种数据处理的装置，其特征在于，包括：
事件处理模块，用于对当前事件信息进行处理，得到结果数据，并保存在本地；
确定模块，用于根据所述结果数据携带的数据标识，确定记录的所述数据标识对应的写入时刻，所述写入时刻为上一次将携带所述数据标识的结果数据写入到数据库中的时刻；
判断模块，用于判断所述写入时刻到当前时刻的时间长度是否超过设定时间长度；
写入模块，用于当所述判断模块的判断结果为是时，将本地保存的所述结果数据写入到数据库中，并将所述数据标识对应的写入时刻更新为当前时刻；
所述事件处理模块还用于，当所述判断模块的判断结果为否时，继续在本地保存所述结果数据，并对下一个事件信息进行处理。

9.  如权利要求8所述的装置，其特征在于，所述当前事件信息和所述下一个事件信息包括物流事件信息，所述结果数据包括物流结果数据。

10.  如权利要求8所述的装置，其特征在于，当前事件信息中携带属性信息，属性信息与处理进程以及数据标识对应；
所述事件处理模块具体用于，根据所述当前事件信息中携带的属性信息，将所述当前事件信息分配给所述属性信息对应的处理进程，使所述处理进程根据所述当前事件信息，对本地保存的携带所述属性信息对应的数据标识的结果数据进行更新，将更新后的结果数据作为对当前事件信息进行处理得到的结果数据。

11.  如权利要求10所述的装置，其特征在于，所述事件处理模块具体用于，提取本地保存的携带所述属性信息对应的数据标识的结果数据，并对提取的结果数据进行更新，若未从本地提取到携带所述数据标识的结果数据，则从数据库中读取携带所述数据标识的数据到本地，并对读取到本地的数据进行更新。

12.  如权利要求11所述的装置，其特征在于，所述处理进程将得到的所述结果数据记录在日志文件中；
所述装置还包括：
监控模块，用于对所述处理进程进行监控，当监控到所述处理进程异常时，针对所述处理进程对应的每个数据标识，将所述处理进程在所述日志文件中最后一次记录的携带该数据标识的结果数据写入到数据库中。

一种数据处理的方法及装置
技术领域
本申请涉及计算机技术领域，尤其涉及一种数据处理的方法及装置。
背景技术
在计算机技术不断发展的今天，实际应用场景中需要对产生的事件信息进行实时的处理，得到结果数据，并将结果数据存储在数据库中，以便后续查询。
具体的，可通过实时计算系统接收并实时处理事件信息，再将处理得到的结果数据写入数据库。
例如，在物流信息处理场景中，一条某物流机构的发货信息、揽收信息、派送信息等都是一条事件信息。而结果数据则可以是对某物流机构在某个时间段（如，当天）内的发货量、揽收量、派送量等进行统计的结果。
具体的，当物流信息系统生成了一个事件信息后，则将该事件信息发送给实时计算系统。实时计算系统则可将该事件信息分配给自身的某个处理进程进行处理，该处理进程根据该事件信息中携带的属性信息，以及预设的属性信息与数据标识的对应关系，确定该属性信息对应的结果数据的数据标识，再根据之前得到的该数据标识的结果数据，对该数据标识的结果数据进行更新，最后将更新后的结果数据写入到数据库中。
然而，对于数据库而言，单位时间内可以向该数据库写入数据的次数是有限制的，而对于实时计算系统而言，实时计算系统中的每个处理进程都是串行处理各事件信息的，只有在将当前的事件信息对应的结果数据写入到数据库中之后，才会对下一个事件信息进行处理，因此，一旦实时计算系统在单位时间内向数据库写入数据的次数大于数据库的限制，就将导致事件信息的堆积，降低了事件信息的处理效率，甚至会导致实时计算系统故障。
例如，对于一个数据库而言，每秒可以向该数据库写入数据的次数最大是10000次，假设每个事件信息会导致4个结果数据的更新，则实时计算系统最多只能支持每秒10000/4=2500个事件信息的处理。如果实时计算系统在1秒内接收到了2501个事件信息，则由于数据库写入数据的限制（每秒10000次）而导致的实时计算系统每秒只能处理2500个事件信息，就会使2501-2500=1个事件信息的堆积。显然，如果实时计算系统在1秒内接收到的事件信息远大于2500个，就会造成大量的事件信息堆积，降低了事件信息的处理效率，甚至会导致实时计算系统故障。
发明内容
本申请实施例提供一种数据处理的方法及装置，用以解决现有技术中由于单位时间内向数据库写入数据的次数存在限制而导致事件信息堆积，事件信息的处理效率较低，甚至导致实时计算系统故障的问题。
本申请实施例提供的一种数据处理的方法，包括：
对当前事件信息进行处理，得到结果数据，并保存在本地；
根据所述结果数据携带的数据标识，确定记录的所述数据标识对应的写入时刻，所述写入时刻为上一次将携带所述数据标识的结果数据写入到数据库中的时刻；
判断所述写入时刻到当前时刻的时间长度是否超过设定时间长度；
若是，则将本地保存的所述结果数据写入到数据库中，并将所述数据标识对应的写入时刻更新为当前时刻；
否则，继续在本地保存所述结果数据，并对下一个事件信息进行处理。
本申请实施例提供的一种数据处理的装置，包括：
事件处理模块，用于对当前事件信息进行处理，得到结果数据，并保存在本地；
确定模块，用于根据所述结果数据携带的数据标识，确定记录的所述数据 标识对应的写入时刻，所述写入时刻为上一次将携带所述数据标识的结果数据写入到数据库中的时刻；
判断模块，用于判断所述写入时刻到当前时刻的时间长度是否超过设定时间长度；
写入模块，用于当所述判断模块的判断结果为是时，将本地保存的所述结果数据写入到数据库中，并将所述数据标识对应的写入时刻更新为当前时刻；
所述事件处理模块还用于，当所述判断模块的判断结果为否时，继续在本地保存所述结果数据，并对下一个事件信息进行处理。
本申请实施例提供一种数据处理的方法及装置，该方法实时计算系统对当前事件信息处理得到结果数据后，根据该结果数据携带的数据标识，判断记录的该数据标识对应的写入时刻到当前时刻的时间长度是否超过设定时间长度，若是，则将该结果数据写入到数据库中，并将该数据标识对应的写入时刻更新为当前时刻，否则继续在本地保存该结果数据，并处理下一个事件信息。上述方法由于实时计算系统只有在写入时刻到当前时刻的时间长度超过设定时间长度时才将结果数据写入到数据库，其余时间实时计算系统可处理后续的事件信息，因此可在保证实时计算系统和数据库中的数据一致的前提下，有效提高事件信息的处理效率，不会造成事件信息的堆积，可有效降低因事件信息堆积而出现故障的几率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的数据处理的过程；
图2为本申请实施例提供的正常情况下数据处理过程的示意图；
图3为本申请实施例提供的异常情况下数据处理过程的示意图；
图4为本申请实施例提供的数据处理的装置结构示意图。
具体实施方式
由于在实际应用场景中，对于某些业务而言，实时计算系统在对当前事件信息处理得到结果数据后，延迟一段时间再将结果数据写入到数据库中并不会对业务造成很大影响，因此，延迟一段时间再将结果数据写入到数据库中是完全可以接受的，而在延迟的这段时间内，实时计算系统就可以处理下一个事件信息，这样就可以突破由于数据库单位时间写入数据的次数限制而导致的实时计算系统处理事件信息的速度瓶颈，从而可在保证实时计算系统和数据库中的数据一致的前提下，提高事件信息处理效率，降低由于事件信息堆积而出现故障的几率。
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
图1为本申请实施例提供的数据处理的过程，具体包括以下步骤：
S101：对当前事件信息进行处理，得到结果数据，并保存在本地。
在本申请实施例中，实时计算系统可通过自身的处理进程对当前事件信息进行处理，得到相应的结果数据，并保存在本地的存储介质中，如保存在本地的内存或硬盘中。其中，当前事件信息中携带属性信息，结果数据中携带数据标识，还可携带结果值，数据标识用于唯一标识该结果数据。
具体的，由于实时计算系统可通过多个处理进程分别处理不同的事件信息，用以并发处理事件信息，提高事件信息的处理效率，因此，本申请实施例中可预设属性信息、处理进程以及数据标识这三者之间的对应关系。其中，一个处理进程可对应多个属性信息，一个处理进程可对应多个数据标识，但一个 属性信息只能对应一个处理进程，一个数据标识只能对应一个处理进程，使得一个处理进程处理的事件信息为携带与该处理进程对应的属性信息的事件信息，得到的结果数据为携带该处理进程对应的数据标识的结果数据。也即，一个处理进程只处理携带与该处理进程对应的属性信息的事件信息，一个处理进程只能得到携带与该处理进程对应的数据标识的结果数据。
从而，实时计算系统处理当前事件信息并得到结果数据的方法具体可以为：实时计算系统根据当前事件信息中携带的属性信息，将当前事件信息分配给该属性信息对应的处理进程，该处理进程则根据当前事件信息，对本地保存的携带该属性信息对应的数据标识的结果数据进行更新，并将更新后的结果数据作为对当前事件信息进行处理得到的结果数据。
例如，当前事件信息为物流机构A在时间T对订单标识为1的订单执行了发货操作的信息，则当前事件信息中携带的属性信息可以为物流机构的标识信息（即，物流机构A）、订单标识、操作类型（即，发货操作）中的一种或几种的组合。
假设上述当前事件信息中携带的属性信息为“物流机构A+发货操作”，预设的属性信息“物流机构A+发货操作”对应的处理进程为1，对应的数据标识为“物流机构A发货量”，则实时计算系统将上述当前事件信息分配给处理进程1，处理进程1则确定该当前事件信息中携带的属性信息“物流机构A+发货操作”对应的数据标识为“物流机构A发货量”，因此，提取本地保存的携带数据标识为“物流机构A发货量”的结果数据。
假设提取的结果数据中携带的结果值为n（表示当前统计的物流机构A的发货量为n），则处理进程1根据上述当前事件信息，将提取的结果数据中携带的结果值更新为n+1，并将更新后的结果数据作为对上述当前事件信息进行处理得到的结果数据。
由于实际应用场景中实时计算系统还可能是由若干个计算服务器所构成的服务器集群系统，因此，可在实时计算系统中添加分发服务器，并在分发服 务器中预设属性信息与计算服务器的对应关系，在各计算服务器中预设属性信息与处理进程和数据标识的对应关系。由分发服务器接收事件信息，并根据预设的属性信息与计算服务器的对应关系以及接收到的事件信息中携带的属性信息，将接收到的事件信息发送给实时计算系统中相应的计算服务器。再由计算服务器根据预设的属性信息与处理进程和数据标识的对应关系，对该事件信息进行处理。
S102：根据该结果数据携带的数据标识，确定记录的该数据标识对应的写入时刻。
在本申请实施例中，实时计算系统可针对保存的每个结果数据，记录该结果数据中携带的数据标识对应的写入时刻，其中，该数据标识对应的写入时刻为上一次将携带该数据标识的结果数据写入到数据库中的时刻。从而，实时计算系统通过上述步骤S101处理当前事件信息得到结果数据并保存在本地后，则可确定该结果数据中携带的数据标识对应的写入时刻。
S103：判断该写入时刻到当前时刻的时间长度是否超过设定时间长度，若是，执行步骤S104，否则执行步骤S105。
其中，该设定时间长度可以根据需要进行设定，例如可设定为10秒。具体的，可预先针对业务确定将结果数据写入数据库的最长延迟时间，并将上述设定时间长度设定为不大于该最长延迟时间。
S104：将本地保存的该结果数据写入到数据库中，并将该数据标识对应的写入时刻更新为当前时刻。
如果判定该写入时刻到当前时刻的时间长度超过了设定时间长度，实时计算系统则将步骤S101得到的保存在本地的结果数据写入到数据库中，并将得到的该结果数据中携带的数据标识对应的写入时刻更新为当前时刻。
其中，在将结果数据写入到数据库中时，实时计算系统可根据步骤S101得到的结果数据中携带的数据标识，确定数据库中保存的携带该数据标识的数据，并将确定的数据库中保存的数据直接更新为该结果数据，也可将确定的数 据库中保存的数据中携带的结果值更新为该结果数据中携带的结果值。
进一步的，实时计算系统还可根据步骤S101得到的结果数据中携带的数据标识，确定数据库中保存的携带该数据标识的数据，并判断数据库中保存的携带该数据标识的数据是否与步骤S101得到的结果数据相同，若相同，则无需将步骤S101得到的结果数据写入数据库，若不同，则将确定的数据库中保存的数据更新为该结果数据。
S105：继续在本地保存该结果数据，并对下一个事件信息进行处理。
如果判定该写入时刻到当前时刻的时间长度未超过设定时间长度，实时计算系统则可继续在本地保存步骤S101得到的该结果数据，并继续对下一个事件信息进行处理。
通过上述方法，实时计算系统只有在写入时刻到当前时刻的时间长度超过设定时间长度时才将结果数据写入到数据库，若未超过设定时间长度，实时计算系统则可暂时在本地保存结果数据，并处理后续的事件信息，而无需等待至将结果数据写入数据库后再处理后续的事件信息，因此可在保证实时计算系统和数据库中的数据一致的前提下（在延迟上述设定时间长度后可保证实时计算系统和数据库中的数据一致），有效提高事件信息的处理效率，不会造成事件信息的堆积，降低了因事件信息堆积而出现故障的几率。
进一步的，由于在物流信息处理场景中，传输到实时计算系统的物流事件信息具有连续、数据量较大的特点，而并非是离散、分批次的批量传输到实时计算系统中的，因此，上述如图1所示的数据处理方法可用于物流信息处理场景中，即，本申请实施例所述的当前事件信息和下一个事件信息包括物流事件信息，所述的结果数据包括物流结果数据。当然，如图1所示的数据处理方法也可用于其他具有连续、数据量较大特点的数据处理场景中，如，商品交易信息处理场景。
下面以在物流信息处理场景中应用如图1所示的数据处理方法为例，对本申请实施例提供的数据处理方法的效果进行说明。
在物流信息处理场景中，事件信息主要包括某物流机构进行发货的事件信息、揽收的事件信息、进/出中转站的事件信息、签收的事件信息等，而每个事件信息可能会导致多个物流结果数据的更新。
例如，对于“物流机构A对订单1执行了发货操作”的事件信息，假设订单1的卖家用户为用户a，发货地为城市b，收货地为城市c，则该事件信息会导致“物流机构A发货量”、“物流机构A为用户a提供的发货量”、“物流机构A从城市b发货的发货量”、“物流机构A发往城市c的发货量”这4个物流结果数据的更新（具体是将这4个结果数据中携带的结果值均加1）。
再如，对于“物流机构A对订单1执行了揽收操作”的事件信息，假设上一个揽收地为城市d，当前揽收地为城市e，下一个揽收地为城市f，则该事件信息会导致“物流机构A揽收量”、“物流机构A在城市e从城市d揽收的揽收量”、“物流机构A在城市e的揽收量”、“物流机构A从城市e揽收后发往城市f的发货量”这4个物流结果数据的更新（具体是将这4个结果数据中携带的结果值均加1）。
仍假设每秒可以向数据库写入数据的次数最大是10000次，平均每个物流事件信息会导致4个物流结果数据的更新，由于物流事件信息并不是离散的批量传输到实时计算系统的，而是连续不断且大量传输到实时计算系统的，假设每秒传输到实时计算系统中的物流事件信息为20000个，那么按照现有技术的方法，处理进程对于上述的物流事件信息，需要将更新后的4个物流结果数据均写入数据库后，才能处理下一个物流事件信息，每秒最多可以处理10000/4=2500个物流事件信息，远低于每秒接收到20000个物流事件信息的速度，因此会造成事件信息堆积。而按照本申请如图1所示的方法，如果预设时间长度为10秒，则由于只有在写入时刻到当前时刻的时间长度超过10秒时才向数据库写入一次物流结果数据，若未超过则可直接处理下一个物流事件信息，因此实时计算系统每秒最多可处理10000/4×10=25000个事件信息，大于每秒接收到20000个物流事件信息的速度，因此，在物流信息处理场景中，本 申请实施例提供的数据处理方法相比于现有技术中相同条件下实时计算系统每秒最多可处理2500个事件信息的效率而言，本申请提供的数据处理方法将事件信息的处理效率提升了10倍，不会造成事件信息的堆积。另外，由于对于物流信息处理场景而言，将更新后得到的物流结果数据延迟10秒写入数据库是可以满足物流业务数据查询的要求的，因此，将更新后得到的物流结果数据延迟10秒写入数据库也不会对物流业务数据的查询造成较大的影响。
进一步的，由于本申请实施例中实时计算系统是在本地保存结果数据的。因此，在图1所示的步骤S101中，实时计算系统在处理当前事件信息并得到结果数据的过程中，根据当前事件信息，对本地保存的携带该属性信息（该属性信息为当前事件信息中携带的属性信息）对应的数据标识的结果数据进行更新时，具体可以提取本地保存的携带该属性信息对应的数据标识的结果数据，并对提取的结果数据进行更新，若未从本地提取到携带该数据标识的结果数据，则可以从数据库中读取携带该数据标识的数据到本地，并对读取到本地的数据进行更新。另外，若实时计算系统也未从数据库中读取到携带该数据标识的数据，则可在本地（如本地内存或硬盘）添加携带该数据标识的结果数据，并根据该当前事件信息，对添加的该结果数据进行更新，或者，也可以将添加的结果数据中携带的结果值置为预设的初始值，并根据该当前事件信息，对添加的结果数据中携带的结果只进行更新。其中，该预设的初始值可根据实际需要进行设定，例如设定为0。
例如，处理进程1确定当前事件信息中携带的属性信息“物流机构A+发货操作”对应的数据标识为“物流机构A发货量”后，可提取本地内存中保存的携带数据标识为“物流机构A发货量”的结果数据，并对提取的结果数据进行更新。如果未从本地内存中提取到携带数据标识为“物流机构A发货量”的结果数据，也即，内存中不存在携带数据标识为“物流机构A发货量”的结果数据，则从数据库中读取携带数据标识为“物流机构A发货量”的数据到本地内存，并对读取的结果数据进行更新。如果未从数据库中读取到携带数据标 识为“物流机构A发货量”的数据，也即，本地内存中和数据库中均不存在携带数据标识为“物流机构A发货量”的数据，则可在本地内存中添加携带数据标识为“物流机构A发货量”的结果数据，并将添加的该结果数据中携带的结果值置为0，并对添加的该结果数据进行更新。
上述方法可保证实时计算系统本地的某个结果数据在更新时，经过预设时间长度后被写入到数据库中，也即，数据库中的数据在经过预设时间长度后会与实时计算系统内存中的相应结果数据保持一致，或者说，实时计算系统在更新了一个结果数据并经过预设时间长度后，即可在从数据库中正确的查询到该数据。然而，在实际应用场景中会存在实时计算系统中某个处理进程出现异常而中断的情况，如果某个处理进程中断，那么该处理进程保存在本地的结果数据也会被清空，而采用本申请上述的延迟预设时间长度后再将结果数据写入数据库的方法，如果本地的结果数据在被清空之前尚未被写入数据库，则会出现本地的结果数据丢失而导致数据库与实时计算系统中的数据不一致的情况，这就会导致不能在数据库中查询到正确的数据，会降低数据处理的准确性。
因此，为了保证数据库中存储的数据的准确性，本申请实施例中处理进程在通过步骤S101处理当前事件信息得到结果数据并保存在本地后，还要将得到的结果数据记录在日志文件中。还可在实时计算系统中或在该实时计算系统之外设置监控装置，用于对实时计算系统的各处理进程进行监控。当监控到处理进程异常时，则针对该处理进程对应的每个数据标识，将该处理进程在日志文件中最后一次记录的携带该数据标识的结果数据写入到数据库中。这样，即可在处理进程出现异常而中断时，仍可保证数据库中的数据与实时计算系统本地的数据一致，可有效提高数据库中存储的数据的准确性。其中，处理进程将得到的结果数据记录在日志文件中时，可将得到结果数据的时间信息记录在日志文件中，则实时计算系统在根据日志文件将结果数据写入数据库中时，可针对每个数据标识，将该处理进程记录的携带该数据标识、且对应的时间信息最晚的结果数据写入到数据库中。
其中，上述监控装置可以是ZooKeeper组件，该ZooKeeper组件可设置于实时计算系统的计算服务器上，也可设置于独立于实时计算系统的其他系统上。对于实时计算系统的一个处理进程而言，该处理进程在正常运行时，即使不处理任何事件信息，该处理进程也是处于运行状态而不是中断状态，因此，若采用ZooKeeper组件监控处理进程，处理进程可在启动时在ZooKeeper组件上注册一个临时节点，该临时节点只与该处理进程对应，如果该处理进程处于运行状态，则该临时节点一直存在，一旦该处理进程中断，则该临时节点就消失，从而ZooKeeper组件可对自身的每个临时节点进行监控，一旦发现某个临时节点消失，即可确定该临时节点对应的处理进程出现异常而中断，从而可通知实时计算系统根据日志文件中的记录，针对该处理进程对应的每个数据标识，将该处理进程在日志文件中最后一次记录的携带该数据标识的结果数据写入到数据库中，以保证数据库中数据的准确性。
下面以图2和图3为例说明本申请实施例中正常情况下和异常情况下的数据处理方法。
假设实时计算系统有3个处理进程，分别为进程1、进程2和进程3，这3个处理进程对应的数据标识分别为R1、R2、R3，各处理进程都将结果数据保存在本地的内存中。
假设实时计算系统接收到了两个当前事件信息，分别为事件1和事件3，事件1携带的属性信息对应进程1和数据标识R1，事件3携带的属性信息对应进程3和数据标识R3。当前内存中保存的携带R1的结果数据中携带两个结果值，第一结果值为100，第二结果值为200，当前内存中保存的携带R3的结果数据中也携带两个结果值，第一结果值为300，第二结果值为400。R1对应的写入时刻为2011年11月11日12:00:00，R3对应的写入时刻为2011年11月11日12:01:00，当前时刻为2011年11月11日12:01:02。预设时间长度为10秒。则：
图2为本申请实施例提供的正常情况下数据处理过程的示意图，在图2中， 进程1处理事件1，则将内存中携带数据标识为R1的结果数据中的第一结果值由100更新为101，并将第二结果值由200更新为201。进程3处理事件3，则将内存中携带数据标识为R3的结果数据中的第一结果值由300更新为301，并将第二结果值由400更新为401。进程2不处理事件。
对于进程1来说，其得到了携带数据标识R1的结果数据，而由于R1对应的写入时刻为2011年11月11日12:00:00，当前时刻为2011年11月11日12:01:02，因此R1对应的写入时刻到当前时刻的时间长度超过了预设时间长度10秒，从而进程1将内存中携带数据标识R1的结果数据写入到数据库中，并更新内存中保存的R1对应的写入时刻为当前时刻2011年11月11日12:01:02。
对于进程3来说，其得到了携带数据标识R3的结果数据，而由于R3对应的写入时刻为2011年11月11日12:01:00，当前时刻为2011年11月11日12:01:02，因此R1对应的写入时刻到当前时刻的时间长度未超过预设时间长度10秒，从而进程3暂不将内存中携带数据标识R3的结果数据写入到数据库中，可处理下一个自身所要处理的事件信息。
当然，进程1和进程3还要将得到的结果数据以及得到结果数据的时间信息（得到结果数据的时间信息即为当前时刻2011年11月11日12:01:02）记录在日志文件中。
在图2所示的过程中，ZooKeeper组件对进程1、进程2和进程3进行监控，对这3个进程均未监控到异常，因此实时计算系统无需根据日志文件将结果数据写入数据库，而且，携带数据标识R1的结果数据在数据库中和实时计算系统的内存中是保持一致的，但是，由于R3对应的写入时刻到当前时刻的时间长度未超过10秒，因此数据库中携带数据标识R3的数据和实时计算系统的内存中携带数据标识R3的结果数据并不一致。
图3为本申请实施例提供的异常情况下数据处理过程的示意图，在图3中，假设在2011年11月11日12:02:00时，进程3出现异常而中断，则ZooKeeper组件监控到进程3出现异常，因此通知实时计算系统针对进程3对应的每个数 据标识，确定进程3在日志文件中最后一次记录的携带该数据标识的结果数据。
实时计算系统确定进程3在日志文件中最后一次记录的携带R3的结果数据为2011年11月11日12:01:02记录的结果数据，因此将该携带R3的结果数据写入到数据库中，以保证进程3出现异常时，数据库中存储的数据仍是准确的。
当然，根据日志文件向数据库中写入数据后，也可将写入的结果数据中携带的数据标识对应的写入时刻更新为写入数据库的时刻。上述是仅以进程3对应一个数据标识为例进行说明的，事实上，进程3可对应多个数据标识。
需要说明的是，上述图2和图3是以用于监控处理进程的监控装置（如图2和图3所示的ZooKeeper组件）是部署在实时计算系统内部为例进行说明的，监控装置还可以独立于实时计算系统部署，这里就不再一一赘述。
另外，为了进一步保证数据库中保存的数据的准确性，实时计算系统还可在满足预设触发条件时，将本地保存的所有结果数据写入到数据库中。其中，该预设的触发条件可以是：根据设定的周期，当确定当前周期的结束时刻到来时，确定满足预设的触发条件。这是由于本申请实施例中对于实时计算系统的本地保存的携带某个数据标识的结果数据而言，只有本地保存的该结果数据被更新时，才会判断该数据标识对应的写入时刻到当前时刻的时间长度是否超过预设时间长度，从而根据判断结果决定是否将更新后的结果数据写入数据库中，因此，实际应用场景中不可避免的会存在下述的极端情况：
一个结果数据被更新时，判定写入时刻到当前时刻的时间长度未超过预设时间长度，因此该结果数据未被写入数据库，但后续的该结果数据在很长的一段时间内都未被更新，因此导致该结果数据在很长一段时间都未被写入到数据库中。
在出现上述极端情况时，也会导致数据库中存储的数据的准确性下降，因此，实时计算系统可按照设定的周期，在每个周期结束时，将本地保存的所有结果数据都写入到数据库中，其中该设定的周期大于上述设定时间长度。例如， 实时计算系统可每24小时将本地保存的所有结果数据写入数据库中，以避免出现上述极端情况而导致数据库中存储的数据不准确的问题。
上述预设的触发条件还可以是：当实时计算系统接收到将内存中结果数据写入到数据库中的写入指令时，确定满足预设的触发条件，将本地保存的所有结果数据写入到数据库中。
进一步地，还可包括：预先在所述数据库中设定指定业务类型，所述数据库在接收到用户的查询请求后，判断查询请求中携带的所要查询的业务类型是否为预设的指定业务类型，若是，则发送将指定业务类型的结果数据写入到数据库中的写入指令。
由于在实际应用场景中，如果某个业务要求实时计算系统在得到结果数据后不能延迟过长的时间再将结果数据写入数据库。为向用户提供更加准确、及时的结果数据，可预先在数据库中设定指定业务类型（例如，实时性要求高的业务类型，如要求延迟时间短的业务类型），数据库在接收到用户的查询请求后，则可判断查询请求中携带的所要查询的业务类型是否为预设的指定业务类型，若是，则发送将所有结果数据写入到数据库中的写入指令，此时，可将本地保存的所有结果数据写入到数据库中，再向用户提供数据，如果不是预设的指定业务类型时，可直接根据数据库查询结果向用户提供其所查询的数据。
以上为本申请实施例提供的数据处理的方法，基于同样的思路，本申请实施例还提供一种数据处理的装置，如图4所示。
图4为本申请实施例提供的数据处理的装置结构示意图，具体包括：
事件处理模块401，用于对当前事件信息进行处理，得到结果数据，并保存在本地；
确定模块402，用于根据所述结果数据携带的数据标识，确定记录的所述数据标识对应的写入时刻，所述写入时刻为上一次将携带所述数据标识的结果数据写入到数据库中的时刻；
判断模块403，用于判断所述写入时刻到当前时刻的时间长度是否超过设 定时间长度；
写入模块404，用于当所述判断模块的判断结果为是时，将本地保存的所述结果数据写入到数据库中，并将所述数据标识对应的写入时刻更新为当前时刻；
所述事件处理模块401还用于，当所述判断模块的判断结果为否时，继续在本地保存所述结果数据，并对下一个事件信息进行处理。
所述当前事件信息和所述下一个事件信息包括物流事件信息，所述结果数据包括物流结果数据。
当前事件信息中携带属性信息，属性信息与处理进程以及数据标识对应；
所述事件处理模块401具体用于，根据所述当前事件信息中携带的属性信息，将所述当前事件信息分配给所述属性信息对应的处理进程，使所述处理进程根据所述当前事件信息，对本地保存的携带所述属性信息对应的数据标识的结果数据进行更新，将更新后的结果数据作为对当前事件信息进行处理得到的结果数据。
所述事件处理模块401具体用于，提取本地保存的携带所述属性信息对应的数据标识的结果数据，并对提取的结果数据进行更新，若未从本地提取到携带所述数据标识的结果数据，则从数据库中读取携带所述数据标识的数据到本地，并对读取到本地的数据进行更新。
所述处理进程将得到的所述结果数据记录在日志文件中；
所述装置还包括：
监控模块405，用于对所述处理进程进行监控，当监控到所述处理进程异常时，针对所述处理进程对应的每个数据标识，将所述处理进程在所述日志文件中最后一次记录的携带该数据标识的结果数据写入到数据库中。
所述写入模块404还用于，在满足预设触发条件时，将本地保存的所有结果数据写入到数据库中，其中，所述预设触发条件包括：接收到将本地保存的所有结果数据写入到数据库中的写入指令。
进一步地，预先在所述数据库中设定指定业务类型，所述写入指令为，在所述数据库接收到用户的查询请求后，判断查询请求中携带的所要查询的业务类型是否为预设的指定业务类型，若是，则发送将指定业务类型的结果数据写入到数据库中的写入指令。
具体的上述数据处理的装置可以位于实时计算系统中。
本申请实施例提供一种数据处理的方法及装置，该方法实时计算系统对当前事件信息处理得到结果数据后，根据该结果数据携带的数据标识，判断记录的该数据标识对应的写入时刻到当前时刻的时间长度是否超过设定时间长度，若是，则将该结果数据写入到数据库中，并将该数据标识对应的写入时刻更新为当前时刻，否则继续在本地保存该结果数据，并处理下一个事件信息。上述方法由于实时计算系统只有在写入时刻到当前时刻的时间长度超过设定时间长度时才将结果数据写入到数据库，其余时间实时计算系统可处理后续的事件信息，因此可在保证实时计算系统和数据库中的数据一致的前提下，有效提高事件信息的处理效率，不会造成事件信息的堆积，可有效降低因事件信息堆积而出现故障的几率。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。