一种交通信息处理方法、装置及MapReduce平台与流程

本申请涉及数据处理技术领域，更具体地说，涉及一种交通信息处理方法、装置及MapReduce平台。

背景技术：

交通信息处理技术已经有多年的发展，目前主要的地图网站与电子地图客户端都接入了实时交通信息服务，可以让用户在电子地图上看到整个城市或者城市部分区域内道路的交通状况(缓行、拥堵、畅通)。

现有交通信息处理是基于浮动车实时回传的GPS数据进行分析。由于浮动车回传数据量较大，单个节点(node)难以计算全国所有区域的交通信息。因此，现有交通信息处理服务一般是以浮动车回传的同一个城市或者同一种道路集合(例如全国高速)的GPS数据作为一个单元在同一个节点进行处理，即，每个单元的GPS数据由一个节点进行处理。

但是，由于浮动车回传的一个城市或者一种道路集合的GPS数据的数据量也很巨大，单个节点的处理能力和存储能力存在极限，因此，现有的交通信息处理方案仍存在处理效率低、耗费大量时间的问题。

技术实现要素：

有鉴于此，本申请提供了一种交通信息处理方法、装置及MapReduce平台，用于解决现有交通信息处理方式无法快速对大量GPS数据进行处理的问题。

为了实现上述目的，现提出的方案如下：

一种交通信息处理方法，包括：

确定浮动车回传的GPS数据对应的至少一个网格，所述网格为预先对电子地图进行网格划分后得到；

确定与所述网格对应的处理节点；

将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。

优选地，所述确定浮动车回传的GPS数据对应的至少一个网格，包括：

将网格的边界向外平移扩展，得到所述网格对应的扩展网格；

确定所述GPS数据包含的定位坐标所属的至少一个扩展网格；

将确定的扩展网格对应的网格确定为所述GPS数据对应的网格。

优选地，所述确定与所述网格对应的处理节点，包括：

对所述网格的标识进行哈希处理，得到所述标识的哈希值；

用所述标识的哈希值除以处理节点的总个数n，得到余数；

将序号与所述余数相同的处理节点确定为所述网格对应的处理节点，其中，各个处理节点的序号由0至n-1，唯一且不重复。

一种交通信息处理方法，应用于处理节点中，该方法包括：

接收GPS数据；

确定所述GPS数据对应的至少一个网格，并判断确定的网格是否属于本处理节点对应的网格；

若属于，则利用接收到的GPS数据进行交通状态计算，得到所述网格内道路的交通状态。

优选地，在所述确定所述GPS数据对应的网格之前，还包括：

检测接收的GPS数据中是否存在相同的GPS数据，若是，则保留相同的GPS数据中的一个GPS数据，删除其它重复的GPS数据。

优选地，所述判断确定的网格是否属于本处理节点对应的网格，包括：

对确定的网格的标识进行哈希处理，得到所述标识的哈希值；

用所述标识的哈希值除以处理节点的总个数n，得到余数；

判断所述余数是否与本处理节点的序号相同，其中，各个处理节点的序号由0至n-1，唯一且不重复；

若是，则确定所述网格属于本处理节点对应的网格。

一种交通信息处理装置，包括：

网格确定单元，用于确定浮动车回传的GPS数据对应的至少一个网格，所述网格为预先对电子地图进行网格划分后得到；

节点确定单元，用于确定与所述网格对应的处理节点；

数据分发单元，用于将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。

优选地，所述网格确定单元包括：

第一网格确定子单元，用于将网格的边界向外平移扩展，得到所述网格对应的扩展网格；

第二网格确定子单元，用于确定所述GPS数据包含的定位坐标所属的至少一个扩展网格；

第三网格确定子单元，用于将确定的扩展网格对应的网格确定为所述GPS数据对应的网格。

优选地，所述节点确定单元包括：

第一节点确定子单元，用于对所述网格的标识进行哈希处理，得到所述标识的哈希值；

第二节点确定子单元，用于利用所述标识的哈希值除以处理节点的总个数n，得到余数；

第三节点确定子单元，用于将序号与所述余数相同的处理节点确定为所述网格对应的处理节点，其中，各个处理节点的序号由0至n-1，唯一且不重复。

一种交通信息处理装置，应用于处理节点中，该装置包括：

数据接收单元，用于接收GPS数据；

网格判断单元，用于确定所述GPS数据对应的至少一个网格，并判断确定的网格是否属于本处理节点对应的网格；

交通状态计算单元，用于在所述网格判断单元判断结果为是时，利用接收到的GPS数据进行交通状态计算，得到所述网格内道路的交通状态。

一种用于处理交通信息的MapReduce平台，包括：数据分发节点和处理节点；

数据分发节点，用于确定浮动车回传的GPS数据对应的至少一个网格，确定与所述网格对应的处理节点，将所述GPS数据分发至所述处理节点，其中所述网格为预先对电子地图进行网格划分后得到；

处理节点，用于接收所述GPS数据，确定所述GPS数据对应的至少一个网格，并判断确定的网格是否属于本处理节点对应的网格，对于属于本处理节 点对应的网格的网格，利用接收到的GPS数据进行交通状态计算，得到所述网格内道路的交通状态。

从上述的技术方案可以看出，本申请实施例提供的交通信息处理方法预先对电子地图进行网格划分，在接收到浮动车回传的GPS数据后，确定GPS数据对应的至少一个网格，然后确定与所述网格对应的处理节点，进而将所述GPS数据分发至处理节点，以供处理节点确定所述网格内道路的交通状态。本申请的方法通过将电子地图划分为多个网格，每个处理节点可以仅负责若干个网格对应的GPS数据，通过将大量的GPS数据分发至多个处理节点进行处理，使得整体处理效率得到了大大提升。

附图说明

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

图1为本申请实施例公开的一种交通信息处理方法流程图；

图2为本申请实施例公开的另一种交通信息处理方法流程图；

图3a为本申请实施例公开的一种网格划分后电子地图示意图；

图3b为本申请实施例公开的一种网格边界扩展后电子地图示意图；

图4为本申请实施例公开的又一种交通信息处理方法流程图；

图5为本申请实施例公开的又一种交通信息处理方法流程图；

图6为本申请实施例公开的一种判断网格是否属于处理节点对应的网格的方法流程图；

图7为本申请实施例公开的又一种交通信息处理方法流程图；

图8为本申请实施例公开的一种应用于数据分发节点的交通信息处理装置结构示意图；

图9为本申请实施例公开的一种应用于处理节点的交通信息处理装置结构示意图；

图10为本申请实施例公开的一种MapReduce平台结构示意图。

具体实施方式

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

本申请公开的交通信息处理方法，主要用于解决现有技术中单个节点处理大量GPS数据所导致的效率低下的问题。本申请将交通信息处理与MapReduce平台进行结合，由于MapReduce平台有众多的处理节点，多个处理节点可以同时工作，因此通过将海量的GPS数据分发给不同的处理节点同时进行处理，解决了海量GPS数据的处理效率问题。

其中，处理节点可以理解为用于进行数据处理的服务器，一个处理节点对应一台服务器，如一台计算机等。

本申请的方法基于MapReduce平台，MapReduce平台包括数据分发节点和处理节点，其中数据分发节点主要用于进行GPS数据的分发工作，而处理节点则用于接收GPS数据，并利用GPS数据进行交通状态的计算工作。

接下来，首先从数据分发节点一侧对本申请方案进行介绍，参见图1，图1为本申请实施例公开的一种交通信息处理方法流程图。

如图1所示，该方法包括：

步骤S100、确定浮动车回传的GPS数据对应的至少一个网格；

具体地，浮动车回传的GPS数据需要上传至MapReduce平台中，MapReduce平台提供了数据仓库的功能，海量的GPS数据可以上传至MapReduce的文件系统中，其会根据GPS数据所属的网格，将GPS数据分网格保存。

在本申请实施例中，所述浮动车回传的GPS数据可以是浮动车实时回传至MapReduce平台的数据，也可以是其他平台实时接收后传递至MapReduce平台的GPS数据。

本实施例预先按照一定的层级对电子地图进行网格划分，得到若干个网格，其中各个网格的大小均相同。通过调整层级大小，可以控制网格的大小。 可以理解的是，将电子地图进行网格划分后，一个网格对应一个确定的地理区域范围。

可选的，为了节约存储空间以及节约带宽，可以采用gzip或者lzo等压缩技术对海量GPS数据进行压缩后再上传至MapReduce平台。

步骤S110、确定与所述网格对应的处理节点；

本申请可以预先设定网格与处理节点间的对应关系，或者设置一定的对应算法，在确定网格之后，按照对应算法可以确定该网格对应的处理节点。

需要说明的是，一个网格仅与一个处理节点对应，而一个处理节点可能处理多个网格的GPS数据。

举例说明如：预先设置的网格与处理节点的对应关系中，网格1与处理节点1对应，网格2与处理节点2对应，若GPS数据1落入了网格1，GPS数据2落入了网格2，则GPS1数据需要分发至处理节点1，GPS数据2需要分发至处理节点2。

步骤S120、将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。

具体地，在确定GPS数据所分发的处理节点之后，将其分发至对应的处理节点，处理节点可以利用GPS数据计算网格内道路的交通状态。

本申请实施例提供的交通信息处理方法预先对电子地图进行网格划分，在接收到浮动车回传的GPS数据后，确定GPS数据对应的至少一个网格，然后确定与所述网格对应的处理节点，进而将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。本申请的方法通过将电子地图划分为多个网格，每个处理节点可以仅负责若干个网格对应的GPS数据，通过将大量的GPS数据分发至多个处理节点进行处理，使得整体处理效率得到了大大提升。

在本申请的另一个实施例中，介绍了另一种交通信息处理方法，参见图2。

如图2所示，该方法包括：

步骤S200、将网格的边界向外平移扩展，得到所述网格对应的扩展网格；

如图3所示，图3a为对电子地图进行网格划分后得到的结果，其中A-I各个网格之间互相紧邻，互不重叠。图3b为经过网格边界扩展后的结果。其中，为了便于阅读，仅仅对网格E和网格F进行了边界扩展，网格E扩展后 的结果为网格R1，网格F扩展后的结果为网格R2。以网格R1为例说明，为了便于描述，将图3b中网格R1所包含的9个小网格，按照从左到右、从上至下的顺序，依次定位为R11、R12…R19。

可以理解的是，其中R11、R13、R17、R19地位相同，以R11为例，其属于网格A、B、C、D对应的扩展网格的共有区域，因此如果一个GPS数据包含的定位坐标落在网格R11中，则代表该GPS数据与网格A、B、C、D相对应，因此将该GPS数据分发至与A、B、C、D各自对应的处理节点。

进一步，R12、R14、R16、R18地位也相同，以R12为例，其属于网格B和网格E对应的扩展网格的共有区域，因此如果一个GPS数据包含的定位坐标落在网格R12中，则代表该GPS数据与网格B和网格E相对应，因此将该GPS数据分发至与B和E各自对应的处理节点。

再进一步，对于R15，其仅属于网格E对应的扩展网格，因此如果一个GPS数据包含的定位坐标落在网格R15中，则代表该GPS数据与网格E相对应，因此将该GPS数据分发至与E对应的处理节点。

步骤S210、确定所述GPS数据包含的定位坐标所属的至少一个扩展网格，并将确定的扩展网格对应的网格确定为目标网格；

由于每个GPS数据均包含唯一的定位坐标，根据定位坐标在由扩展网格组成的电子地图中的位置，可以确定GPS数据所对应的网格。

一个定位坐标有可能仅属于一个扩展网格，也有可能属于两个或者两个以上的扩展网格。如果一个GPS数据的定位坐标落在两个或者两个以上的扩展网格内，则将其所在的扩展网格所对应的网格确定为目标网格。

步骤S220、确定所述目标网格对应的处理节点；

步骤S230、将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。

具体地，假设在步骤S210中确定一个GPS数据对应两个及两个以上的目标网格，则将该GPS数据分发至这几个目标网格所对应的处理节点中。

在本实施例中，介绍了一种GPS数据与网格对应的具体实施方式。本实施例中对网格划分后的电子地图中的网格进行了边界扩展，扩展的目的主要是考虑到交通信息处理并非网格间孤立的，在计算某段道路的交通状态时，需要依靠用户轨迹的上下文数据，因此在计算网格边缘处道路的交通状态时， 为了提高计算准确度，需要提供与该网格边缘相邻的网格的部分GPS数据，而本实施例正是通过对网格进行边界扩展，使得计算某一网格道路交通状态时能够利用到其相邻网格的部分GPS数据，使得计算精度更高。

可以理解的是，与网格对应的扩展网格的大小可以由用户进行设定，根据扩展网格大小的不同，GPS数据所对应的网格的个数也可能不同。

当然，上述仅仅是一种可选的GPS数据与网格的对应方式，如果不考虑网格边缘道路的交通状态的精度，可以直接设定每个GPS数据仅与其包含的定位坐标所属的网格相对应，也即一个GPS数据中的定位坐标落在哪一个网格中，则该GPS数据与该网格相对应。

在本申请的又一个实施例中，介绍了又一种交通信息处理方法，参见图4。

如图4所示，该方法包括：

步骤S400、确定浮动车回传的GPS数据对应的至少一个网格；

步骤S410、对所述网格的标识进行哈希处理，得到所述标识的哈希值；

步骤S420、利用所述标识的哈希值除以处理节点的总个数，得到余数；

步骤S430、将序号与所述余数相同的处理节点确定为所述网格对应的处理节点；

其中，各个处理节点的序号由0至n-1，唯一且不重复，n为处理节点的总个数。

步骤S440、将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。

需要解释的是，网格的标识并不一定是数字格式，因而可以通过哈希处理，将网格标识转换为数字格式的哈希值。由哈希值除以处理节点总个数，得到余数，序号与该余数相同的处理节点即为对应GPS数据的分发对象。

举例如，总共有10个处理节点，序号分别为0-9。确定的与GPS1数据对应的网格为网格B和网格C。通过对网格B和网格C的标识进行哈希处理，得到网格B对应的哈希值为15，网格C对应的哈希值为27。显然，15除以10的余数为5，27除以10的余数为7。则将GPS1数据分发至处理节点5和处理节点7。

可以理解的是，上述例子中仅仅示例了网格B和网格C对应不同处理节点的情况，可以理解的是，在某些情况下网格B和网格C由可能对应同一处理节点，例如网格B的哈希值为15，网格C的哈希值为25，则二者除以10后的余数均为5，也即网格B和网格C均对应处理节点5。

当某一GPS数据对应的至少两个网格均与同一处理节点对应时(例如上述与GPS1数据对应的网格B和网格C，均与处理节点5对应)，按照上述分发方式，需要将相同的两个GPS数据分发给同一处理节点，也即向同一处理节点发两个完全相同的GPS数据。而对于处理节点来说，两个相同的GPS数据对交通信息计算并无任何作用，相反会占用处理节点的存储资源。因此，本实施例中，在检测到发送至同一处理节点的GPS数据中存在相同的GPS数据时，可以只对相同GPS数据中的任意一个GPS数据进行发送，其余相同的GPS数据不进行发送。当然，除此之外，还可以由处理节点来进行相同GPS数据的删除工作，对此本申请不进行限定。

可以理解的是，在判断两个GPS数据是否相同时，可以根据GPS数据包含的用户名和上传时间来进行判断，如果两个GPS数据的用户名和上传时间均相同，则理论上来说这两个GPS数据完全相同，因为同一用户同一时间不可能处于两个不同的定位坐标处。而如果考虑到系统错误等特殊情况，可以在确定两个GPS数据的用户名、上传时间和定位坐标完全相同时，才认为两个GPS数据完全相同。

当然，上述实施例仅仅示例了一种确定与网格对应的处理节点的方式，除此之外在实际应用中，本领域技术人员还可以采用其他方式确定网格与对应的网格，例如设置静态对应关系表，该表用于记录网格标识与处理节点序号间的静态对应关系。这样，通过查询静态关系表，可以直接确定与网格对应的处理节点的序号。另外，上述哈希算法仅为举例，不应视为对本申请使用算法的限制，任何可以使处理节点与网格产生对应关系的算法均可作为本申请具体实施方案。

上述实施例以数据分发节点的角度对方案进行了介绍，接下来本实施例以处理节点的角度对本申请的方案再次进行介绍。

参见图5，图5为本申请实施例公开的另一种交通信息处理方法流程图。

如图5所示，以处理节点的角度分析，该方法包括：

步骤S500、接收GPS数据；

具体地，GPS数据可以是由处理节点分发的。

步骤S510、确定所述GPS数据所对应的至少一个网格，并判断确定的网格是否属于本处理节点对应的网格；

具体地，对于接收的每一个GPS数据，确定与其对应的至少一个网格，并判断各网格是否属于本处理节点对应的网格。具体的判断方式可以有多种，例如预先在处理节点内存储处理列表，该处理列表中标注了本处理节点所应该处理的网格的标识，等等其它方式。

步骤S520、对于属于本处理节点对应的网格的网格，利用所述GPS数据进行交通状态计算，得到所述网格内道路的交通状态。

举例如，本处理节点所处理的网格仅为网格1，则利用上传的与网格1对应的所有GPS数据进行网格1交通状态的计算。当然，如果处理节点所处理的网格有多个，则针对每一个网格均进行上述操作即可。

本实施例提供的交通信息处理方法，接收数据分发节点发送的多个GPS数据，并确定各个GPS数据所对应的网格，进而确定各网格是否属于本处理节点的处理范围，如果是，则利用与之对应的GPS数据进行交通状态的计算，得到网格内道路的交通状态信息。本实施例中，用户上传的海量GPS数据分发给多个处理节点进行并行处理，各个处理节点仅需要处理与自己范围内的网格对应的GPS数据，因而单个处理节点的压力大大减少，且整体处理效率也得到了大大提升。

可选的，在接收到GPS数据之后，可以对GPS数据按照上传时间先后进行排序。这样，使得在处理交通信息时可以像按照时间回放一样快速处理多个网格数个月的GPS数据。

此外，还可以按照用户名对GPS数据进行分类排序，同一用户名的GPS数据集中处理，能够提高处理效率。

在上一实施例中仅仅介绍了一种判断网格是否属于本处理节点的处理范围的实施方式。参照上文数据分发节点侧进行GPS数据分发时的策略，本实施例还提供了另外一种判断方式。如图6所示，该方法包括：

步骤S600、对网格的标识进行哈希处理，得到所述标识的哈希值；

步骤S610、利用所述标识的哈希值除以处理节点的总个数，得到余数；

步骤S620、判断所述余数是否与本处理节点的序号相同，其中，各个处理节点的序号由0至n-1，唯一且不重复，n为处理节点的总个数；若是，执行步骤S630，若否，执行步骤S640；

步骤S630、确定所述网格属于本处理节点对应的网格；

步骤S640、确定所述网格不属于本处理节点对应的网格。

在本申请的又一个实施例中，介绍了又一种交通信息处理方法流程图。

如图7所示，该方法包括：

步骤S700、接收GPS数据；

具体地，GPS数据可以是由数据分发节点分发的。

步骤S710、检测接收的GPS数据中是否存在相同的GPS数据，若是，则执行删除操作，保留相同的GPS数据中的一个GPS数据；

步骤S720、确定与所述GPS数据对应的至少一个网格，并判断确定的网格是否属于本处理节点对应的网格；

步骤S730、对于属于本处理节点对应的网格的网格，利用所述GPS数据进行交通状态计算，得到所述网格内道路的交通状态。

在上文数据分发节点侧介绍的方法实施例中已经提到了，当某一个GPS数据对应的至少两个网格均与同一处理节点对应时，有可能会将相同的两个GPS数据分发给同一处理节点，此时重复的GPS数据会占用处理节点的存储资源，为此可以删除一些相同的GPS数据，仅保留相同的GPS数据中的一个GPS数据即可。

下面对本申请实施例提供的交通信息处理装置进行描述，下文描述的交通信息处理装置与上文描述的交通信息处理方法可相互对应参照。

首先，介绍应用于数据分发节点的交通信息处理装置。参见图8，图8为本申请实施例公开的一种应用于数据分发节点的交通信息处理装置结构示意图。

如图8所示，该装置包括：

网格确定单元81，用于确定浮动车回传的GPS数据对应的至少一个网格，所述网格为预先对电子地图进行网格划分后得到；

节点确定单元82，用于确定与所述网格对应的处理节点；

数据分发单元83，用于将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。

本申请实施例提供的交通信息处理装置，在接收到浮动车回传的GPS数据后，确定GPS数据对应的至少一个网格，然后确定与所述网格对应的处理节点，进而将所述GPS数据分发至所述处理节点，以供所述处理节点确定所述网格内道路的交通状态。本申请通过将电子地图划分为多个网格，每个处理节点可以仅负责若干个网格对应的GPS数据，通过将大量的GPS数据分发至多个处理节点进行处理，使得整体处理效率得到了大大提升。

可选的，上述网格确定单元可以包括：

第一网格确定子单元，用于将网格的边界向外平移扩展，得到所述网格对应的扩展网格；

第二网格确定子单元，用于确定所述GPS数据包含的定位坐标所属的至少一个扩展网格；

第三网格确定子单元，用于将确定的扩展网格对应的网格确定为所述GPS数据对应的网格。

当然，上述仅仅是一种可选的GPS数据与网格的对应方式，如果不考虑网格边缘道路的交通状态的精度，可以直接设定每个GPS数据仅与其包含的定位坐标所属的网格相对应，也即一个GPS数据中的定位坐标落在哪一个网格中，则该GPS数据与该网格相对应。

可选的，上述节点确定单元可以包括：

第一节点确定子单元，用于对所述网格的标识进行哈希处理，得到所述标识的哈希值；

第二节点确定子单元，用于利用所述标识的哈希值除以处理节点的总个数n，得到余数；

第三节点确定子单元，用于将序号与所述余数相同的处理节点确定为所述网格对应的处理节点，其中，各个处理节点的序号由0至n-1，唯一且不重复。

当然，上述实施例仅仅示例了一种确定与网格对应的处理节点的方式，除此之外还可以存在其它的网格与处理节点间的对应关系，例如设置静态对应关系表，其中记录网格标识与处理节点序号间的静态对应关系。这样，通过查询静态关系表，可以直接确定与网格对应的处理节点的序号。

接下来，本实施例介绍应用于处理节点一端的交通信息处理装置。参见图9，图9为本申请实施例公开的一种应用于处理节点的交通信息处理装置结构示意图。

如图9所示，该装置包括：

数据接收单元91，用于接收GPS数据；

网格判断单元92，用于确定所述GPS数据对应的至少一个网格，并判断确定的网格是否属于本处理节点对应的网格；

交通状态计算单元93，用于在所述网格判断单元判断结果为是时，利用接收到的GPS数据进行交通状态计算，得到所述网格内道路的交通状态。

本实施例提供的交通信息处理装置，接收数据分发节点发送的多个GPS数据，并确定各个GPS数据所对应的网格，进而确定各网格是否属于本处理节点的对应的网格，如果是，则利用与之对应的GPS数据进行交通状态的计算，得到网格内道路的交通状态信息。本实施例中，用户上传的海量GPS数据分发给多个处理节点进行并行处理，各个处理节点仅需要处理与自己范围内的网格对应的GPS数据，因而单个处理节点的压力大大减少，且整体处理效率也得到了大大提升。

可选的，上述交通信息处理装置还可以包括：

数据排序单元，用于按照上传时间先后的顺序，对接收的若干个GPS数据进行排序。

可选的，上述交通信息处理装置还可以包括：

去重复数据单元，用于检测接收到的GPS数据中是否存在相同的GPS数据，若是，则执行删除操作，仅保留相同的GPS数据中的一个GPS数据。

可选的，上述网格判断单元可以包括：

第一网格判断子单元，用于针对各网格的标识进行哈希处理，得到所述标识对应的哈希值；

第二网格判断子单元，用于利用所述标识对应的哈希值除以处理节点的总个数，得到对应的余数；

第三网格判断子单元，用于判断各余数与本处理节点的序号是否相同，若是，则确定该余数对应的网格属于本处理节点对应的网格，若否，则确定该余数对应的网格不属于本处理节点对应的网格，其中各个处理节点的序号由0至n-1，各不相同，n为处理节点的总个数。

本申请实施例还提供了一种用户处理交通信息的MapReduce平台，如图10所示，该平台包括：

数据分发节点1和若干个处理节点2，其中，

所述数据分发节点1用于确定浮动车回传的GPS数据对应的至少一个网格，确定与所述网格对应的处理节点2，将所述GPS数据分发至所述处理节点2，其中所述网格为预先对电子地图进行网格划分后得到；

所述处理节点2用于接收所述GPS数据，确定与所述GPS数据所对应的至少一个网格，并判断各网格是否属于本处理节点对应的网格，若是，利用所述GPS数据进行交通状态计算，得到所述网格内道路的交通状态。

本申请实施例的MapReduce平台，通过数据分发节点实现GPS数据的分发，将海量的GPS数据分发至不同的处理节点，由各个处理节点分别处理一定网格的GPS数据，使得整体处理效率得到了大大提升。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。