一种集群中的数据处理方法、电子设备和存储介质与流程

1.本发明涉及但不限于计算机信息领域，尤其涉及一种集群中的数据处理方法、电子设备和存储介质。


背景技术：

2.伴随各类应用系统应用需求的不断提升，数据处理的实时性要求也越来越高。同时应用规模不断增大，采用集群进行分布式处理也普及。为了满足实时性需求，应用服务器(集群中的节点)将部分关键业务数据缓存在内存中，以减少磁盘或外部数据的访问开销，提升业务处理效率。在集群方案中，如何协同多个节点间数据处理任务的分发，并避免不同节点间缓存数据的冲突，一直是本领域不断探索的方向。


技术实现要素：

3.本公开实施例提供一种集群中的数据处理方法、电子设备和存储介质，利用数据分区对应的相对固定的优先处理节点，根据待处理数据的分区标识进行数据分发，保持集群中的各节点能够相对固定地缓存并处理确定分区的数据，避免了集群中多节点缓存数据处理的冲突，也避免了随机分配处理节点导致各节点缓存数据量过大，显著提升了集群系统的处理性能和稳定性。
4.一方面，本公开实施例提供了一种集群中的数据处理方法，包括，获取待处理记录；
5.根据所述待处理记录中的数据分区标识，确定所述数据分区标识对应在集群中的优先处理节点为处理所述待处理记录的目标节点，将所述待处理记录分发到所述目标节点上；
6.根据所述待处理记录，更新所述目标节点上缓存的历史记录集合。
7.另一方面，本公开实施例还提供一种电子设备，包括：
8.一个或多个处理器；
9.存储装置，用于存储一个或多个程序，
10.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本公开中任一实施例所述的集群中的数据处理方法。
11.另一方面，本公开实施例一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本公开中任一实施例所述的集群中的数据处理方法。
12.本发明实施例充分利用了数据分区和分区优先处理节点设置关系，保持集群中各节点进行缓存数据更新时的数据范围的相对稳定。
13.在阅读并理解了附图和详细描述后，可以明白其他方面。
附图说明
14.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现
有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。
15.图1是本发明实施例提供的一种集群中数据处理方法的流程图；
16.图2是本发明示例中一种高性能车辆聚档的集群系统的示意图；
17.图3是本发明示例中一种高性能车辆聚档的集群系统出现节点故障时的示意图。
18.本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
19.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
20.需要说明，本发明实施例中所有方向性指示(诸如上、下、左、右、前、后
……
)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。
21.另外，在本发明中如涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
22.在本发明中，除非另有明确的规定和限定，术语“连接”、“固定”等应做广义理解，例如，“固定”可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
23.另外，本发明各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。
24.现实生活中，各种实时数据处理的业务系统随处可见，根据应用规模和系统可用性要求，集群方案应用广泛。以车辆动态监控系统为例，统计、管理、历史记录追溯等业务功能都需要获取城市或地区车辆动态的档案信息，这些动态档案信息描述的是“一段周期”内城市或地区出现过的车辆信息。其中“一段周期”也称为留存期，如果车辆的过车时间已不在留存期内，则需要从车辆动态档案信息中删除，这也称为车辆聚档。保存车辆聚档数据的模块或子系统称为聚档库，聚档库中的过车信息，以车辆标识为主键要求全局唯一。由于城市或地区每天来往车次的数据量非常庞大，要提供稳定可靠的业务保证，整个应用系统需要具备容错能力、支持应用服务器和聚档库规模的在线扩展，因此，相关系统采用集群方案部署应用，由集群中的多个节点进行分布式业务处理。
25.相关方案中，为了实现上述过车数据的准确聚档，使用spark/flink/storm/flume等流式处理引擎实时处理数据，采用基于redis做全局唯一的判断。如果采用redis单机模
式，则整个系统无法实现线性扩展，也不能引入多个节点进行负荷分担，无法满足大数据量应用需求。如果使用redis集群模式，则每条业务数据的处理都需要与redis交互，显著增大了服务器系统的网络io开销，影响整体业务处理性能。
26.针对上述方面的不足，本公开实施例提出了集群环境下的数据处理方案，依据数据的分区标识，分发到相对固定的处理节点，使得不同处理节点在相对固定的分区数据范围进行数据缓存和处理(例如，全局唯一判断)，有效控制了各处理节点的缓存数据量，避免了多节点之间缓存数据的冲突，保证了整体业务系统的可靠性和稳定性。
27.需要说明的是，本公开实施例提供的集群中数据处理方法，可以应用于多种业务系统中，不限于进行示例性说明而举例的车辆数据聚档应用。还可用于人员监测系统、物流监测等等。根据本公开实施例记载的方面，本领域技术人员对应调整相关方面，均可达成相应技术目标。
28.在相关实施例之前，先介绍几个本公开实施例涉及的方面：
29.spark：apache spark是专为大规模数据处理而设计的快速通用的计算引擎。spark提供了大量的库，包括spark core、spark sql、spark streaming、mllib、graphx等。
30.redis：remote dictionary server)，即远程字典服务，是一个开源的使用ansi c语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的api。
31.flink：apache flink是由apache软件基金会开发的开源流处理框架，其核心是用java和scala编写的分布式流数据流引擎。flink以数据并行和流水线方式执行任意流数据程序，flink的流水线运行时系统可以执行批处理和流处理程序。
32.storm：storm是twitter开源的分布式实时大数据处理框架，可以简单、可靠的处理大量的数据流。
33.flume：flume是cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统。
34.spark执行器：spark执行器是spark作业真正计算处理数据的基本单元。
35.spark驱动器：用于执行spark任务的main方法，负责向执行器发布计算任务。
36.kafka：kafka是由apache软件基金会开发的一个开源流处理平台，由scala和java编写。kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在相关系统中的所有动作流数据。
37.rocketmq：rocketmq是由阿里捐赠给apache的一款分布式、队列模型的开源消息中间件。
38.聚档：也可称为归档，将去重过滤后数据落地到持久化存储。
39.本公开提供一种集群中的数据处理方法，如图1所示，包括，
40.步骤101，获取待处理记录；
41.步骤102，根据所述待处理记录中的数据分区标识，确定所述数据分区标识对应在集群中的优先处理节点为处理所述待处理记录的目标节点，将所述待处理记录分发到所述目标节点上；
42.步骤103，根据所述待处理记录，更新所述目标节点上缓存的历史记录集合。
43.一些示例性实施例中，所述待处理记录中至少包括以下信息：目标标识和记录时
间。其中，目标标识是聚档库或各节点自身缓存中查重的标识，即聚档库或各节点的缓存中每个目标标识只记录一条数据。其中，记录时间表示相关事件的发生时间，或者，待处理记录的产生时间，或者，其他被用于判断记录的时间有效性的时间，不限于本公开实施例示例的内容。
44.一些示例性实施例中，步骤101中所获取的待处理记录可以是来自kafka、rocketmq等消息中间，使用sparking streaming实时获取。
45.一些示例性实施例中，所述待处理记录还包括应用所需的其他相关信息。例如，所述待处理记录为过车记录，来自监控系统的过车记录。则目标标识为：车牌号码；或者，目标标识为：车牌号码+车牌颜色；或者其他可以唯一标识车辆的数据；待处理记录还包括：车辆颜色、车牌类型、车辆品牌等信息。
46.需要说明的是，不同应用系统所涉及的管理目标或业务主体不同，其对应待处理记录中目标标识的内涵不同，其他包括的方面也不同，不限于本公开实施所例举的范围和形式。
47.一些示例性实施例中，步骤102中数据分区标识对应在集群中的优先处理节点根据以下方式确定：
48.根据所述数据分区标识，按照所述集群所包括的处理节点的数量进行哈希取模，在所述集群所包括的处理节点中确定所述数据分区标识对应的优先处理节点。即，按照哈西取模的结果，从集群所包括的处理节点中分别为各数据分区标识确定一个对应的优先处理节点。
49.一些示例性实施例中，所述待处理记录中的数据分区标识根据以下方式确定：根据所述待处理记录中的目标标识，按照分区数量进行哈希取模确定所述待处理记录中的数据分区标识。即，按照哈西取模的结果，确定各待处理记录对应的数据分区标识。一些示例性实施例中，数据分区标识也称为分区号。
50.可以看到，在集群系统建立时，集群系统所包括的分布式处理节点的数量确定后，根据上述方式，能够为每一个分区确定一个相对固定的优先处理节点，也称为该分区的偏好节点。在集群系统建立时，整体数据规划的分区数量也确定，对于同一个管理目标或业务主体，其目标标识保持不变，则根据上述方式所确定的数据分区标识也保持不变。
51.需要说明的是，在目标相同的情况下，步骤101中所获取的待处理记录中的目标标识相同，该待处理记录的数据分区标识和该目标的历史记录的数据分区标识相同，则步骤102中所确定的将要处理该待处理记录的目标节点和该目标的历史记录被处理的节点相同。也就是说，根据本公开实施例的方案，在集群中各节点均正常可用的情况下，同一目标的记录可以保持在同一个节点上处理，这个节点上就缓存了该目标最新的记录数据；或者，还可以理解为，归属同一个分区的记录数据保持在确定的优先处理节点上处理。这样，集群中的不同节点上分别缓存并处理确定的一个或多个分区的数据，有效地控制了各节点上缓存的数据量，同时，在分担缓存的情况下，避免了不同节点之间的对同一目标记录的处理冲突，确保整体系统查重的准确性，提高了后续缓存数据同步到聚档库时的执行效率。
52.一些示例性实施例中，所述分区数量大于或等于集群系统中包括的节点数量。这样，每个节点可以被确定为至少一个分区的优先处理节点。
53.一些示例性实施例中，所述方法还包括步骤100，所述集群中的节点加载缓存数
据，包括以下步骤：
54.确定所述节点作为优先处理节点时对应的一个或多个数据分区标识，根据所述一个或多个数据分区标识从聚档库中获取对应的历史记录加载到缓存中。
55.需要说明的是，集群建立后，所包括的节点确定，根据上述方案可以知晓，每个节点均被确定为一个或多个数据分区对应的优先处理节点。因此，启动集群，即启动全部节点后，各节点将自身对应的一个或多个数据分区的历史记录从聚档库中加载至自身的缓存中，以便后续处理新记录时在自身缓存中更新或新增，或删除记录。
56.一些示例性实施例中，步骤102中根据所述待处理记录中的数据分区标识，确定所述数据分区标识对应在集群中的优先处理节点为处理所述待处理记录的目标节点，包括：
57.根据所述待处理记录中的数据分区标识，确定所述数据分区标识对应在集群中的优先处理节点；
58.在所述优先处理节点可用的情况下，将所述优先处理节点确定为处理所述待处理记录的目标节点；
59.在所述优先处理节点不可用的情况下，获取所述集群中当前可用节点数量；根据所述数据分区标识，按照所述集群中当前可用节点数量的数量进行哈希取模，在当前可用节点中确定所述数据分区标识对应的临时处理节点；将所述临时处理节点确定为处理所述待处理记录的目标节点。
60.即，按照哈西取模的结果，从集群中当前可用的节点中分别为各数据分区标识确定一个对应的临时处理节点。
61.需要说明的是，集群中的节点并不能一直保持全部可用。在步骤102给待处理记录确定目标节点时，可能出现优先处理节点可用或不可用的情况：
62.(一)在优先处理节点(即分区的偏好节点)可用时，则正常将该待处理记录分发到其对应的优先处理节点，由这个优先处理节点执行步骤103的缓存更新处理。可以看到，由于该优先处理节点在启动时已加载了所述待处理记录的归属分区的全部历史记录，因此基于此进行查重、更新历史记录或新增记录都是准确的。
63.(二)在优先处理节点(即分区的偏好节点)不可用时，仅对原本要分发到该不可用节点的待处理记录进行二次分发，在当前可用节点的范围内进行分发，使得其他可用节点分担该不可用节点的处理任务，这些参与二次分发的节点对于该待处理记录归属的分区来说，称为临时处理节点。即，在某个节点不可用时，其原先对应的分区的待处理记录被分担到其他节点进行处理，以此保持整体业务的顺利进行，并不因为某个节点的不可用而中断相关业务处理，提升了整体系统的容错能力。这时，这些其他可用节点，既是某一个或多个分区记录的优先处理节点，也担当临时处理节点，分担其他分区的记录处理任务。
64.相应地，步骤103中根据所述待处理记录，更新所述目标节点上缓存的历史记录集合，包括：
65.在所述目标节点是所述待处理记录中的数据分区标记对应的优先处理节点的情况下，根据所述待处理记录中的目标标识更新所述目标节点上缓存的所述目标标识的历史记录或加入所述待处理记录到所述目标节点的缓存中；
66.在所述目标结点不是所述待处理记录中的数据分区标记对应的优先处理节点的情况下，根据所述待处理记录中的数据分区标记从聚档库中获取对应的历史记录同步到所
述目标结点的缓存中；根据所述待处理记录中的目标标识，更新缓存的所述目标标识的历史记录或加入所述待处理记录到所述目标节点的缓存中。
67.需要说明的是，因为分发数据的步骤102根据优先处理节点是否可用，出现了上述两种情况，对于接收到待处理记录的节点来说，步骤103的执行也对应两种情况：
68.(一)接收到所述待处理记录的节点(目标节点)本身就是所述待处理记录的分区所对应的优先处理节点，则该节点就根据待处理记录进行自身缓存数据的处理，包括：当缓存中已存在所述待处理记录中的目标标识的历史记录时，根据待处理记录更新历史记录；当缓存中不存在所述待处理记录中的目标标识的历史记录时，则将该待处理记录加入缓存中。可以看到，这时接收该待处理记录的节点是以优先处理节点的角色执行步骤103。
69.(二)接收到所述待处理记录的节点(目标节点)本身不是所述待处理记录的分区所对应的优先处理节点的情况下，也就是说在该待处理记录的分区对应的优先处理节点当前不可用，无法正常处理该待处理记录的情况下，该待处理记录被分担到临时处理节点。
70.这时，接收该待处理记录的节点还以临时处理节点的角色执行步骤103，包括：
71.根据接收到的所述待处理记录中的数据分区标记从聚档库中获取对应的历史记录同步到自身缓存中；根据所述待处理记录进行缓存数据的处理，包括：当缓存中已存在所述待处理记录中的目标标识的历史记录时，根据待处理记录更新历史记录；当缓存中不存在所述待处理记录中的目标标识的历史记录时，则将该待处理记录加入缓存中。
72.需要说明的是，对于集群中的各节点来说，在全部节点正常可用时，待处理记录根据数据分区对应的优先处理节点(分区的偏好节点)进行分发，每个节点接收到的待处理记录，对于该节点来说，称为第一待处理记录；在一个或多个节点不可用时，对所述一个或多个节点被分配的第一待处理记录进行二次分发，对于其他各可用节点接收到的这些被二次分发的待处理记录，称为第二待处理记录，也称为临时待处理记录。上述第一待处理记录和第二待处理记录是为了对待处理记录进行区别，不包含其他内涵，更不代表各节点在进行后续记录处理时的优先级。
73.一些示例性实施例中，上述步骤还包括：记录聚档库同步的数据分区标记；或者，记录聚档库同步的数据分区标记和聚档库同步时间。
74.一些示例性实施例中，接收该待处理记录的节点还以临时处理节点的角色执行步骤103，包括：
75.在确定满足第二待处理数据缓存加载条件的情况下，根据接收到的所述待处理记录中的数据分区标记从聚档库中获取对应的历史记录同步到自身缓存中；根据所述待处理记录进行缓存数据的处理，包括：当缓存中已存在所述待处理记录中的目标标识的历史记录时，根据待处理记录更新历史记录；当缓存中不存在所述待处理记录中的目标标识的历史记录时，则将该待处理记录加入缓存中。
76.其中，满足第二待处理数据缓存加载条件，包括：
77.当接收到的第二待处理记录中的数据分区标识所指示的分区数据未被加载时，确定满足第二待处理数据缓存加载条件。
78.一些示例性实施例中，可以根据已记录的聚档库同步的数据分区标记判断是否已加载。可选地，本领域技术人员可以采用其他方式确定是否已加载。
79.例如，集群中节点a不可用时，执行步骤102，将以节点a作为优先处理节点的分区
的记录，被二次分发到其他节点。这些其他的可用节点，既以优先处理节点的角色按照(一)的方案进行本地缓存更新，也以临时处理节点的角色按照(二)的方面进行本地缓存的更新。这些节点上的缓存数据都将根据有关写入聚档库的方案在满足预设聚档条件时被同步到聚档库中。
80.当节点a恢复可用时，节点a启动后，执行步骤100，从聚档库中加载最新的对应分区的历史记录。这时，以节点a为优先处理节点的分区数据无需要被二次分发到其他节点，节点a按照(一)的方案接收待处理记录并进行本地缓存处理。其他节点也将不再被分发到以节点a为优先处理节点的待处理数据，整个集群系统恢复正常运行模式。
81.一些示例性实施例中，集群中多个节点不可用时，与上述一个节点不可用的实施过程相似，先按照在全部节点可用的情况下所确定的优先处理节点分发，再将该次分发中分发到所述多个不可用节点的待处理记录在当前可用节点范围内进行二次分发。本领域技术人员根据上述记载可以知晓具体实施方面，在此不一一赘述。
82.需要说明的是，如何确定集群系统中各节点可用或不可用或恢复可用，以及如何通知集群中其他节点，根据相关集群方案实施即可，具体方案不属于本技术保护或限定的范围。例如，当节点掉线或宕机时，spark驱动器与集群中所有节点的执行器进行远程过程调用(rpc)通信，以获知哪些节点不可用，哪些节点可用，以及新的节点数量和节点；当掉线或宕机的节点恢复后，会与spark驱动器进行rpc通信，spark驱动器得知后与集群中所有节点进行rpc通信，获取新的节点可用信息，以及新的可用节点数量。
83.一些示例性实施例中，所述方法还包括：
84.步骤104，在满足预设的缓存清理条件时，清理所述目标节点上缓存的过期数据。
85.一些示例性实施例中，所述满足预设的缓存清理条件包括以下一个或多个：
86.当前节点上缓存的历史记录数大于预设的第一数量阈值时，确定满足预设的缓存清理条件；
87.当前节点上缓存的历史记录数的总数据存储量大于预设的第一存储量阈值时，确定满足预设的缓存清理条件；
88.预设的缓存清理时间间隔达到时，确定满足预设的缓存清理条件；
89.当前节点获取到新一批的待处理记录时，确定满足预设的缓存清理条件。
90.一些示例性实施例中，所述清理所述目标节点上缓存的过期数据，包括以下方式的一种或多种：
91.计算缓存中各历史记录的已缓存时长，删除已缓存时长大于预设的第一时长阈值的缓存记录；其中，已缓存时长＝当前时间-记录时间；
92.根据各历史记录的记录时间，将记录时间最早的n条历史记录删除；n为正整数；
93.根据各历史记录的记录时间，将记录时间最早的前百分之m的历史记录删除；m为正数。
94.一些示例性实施例中，满足预设的缓存清理条件还包括：
95.当前节点作为临时处理节点，超过预设时长未接收到一个或多个数据分区标识的第二待处理记录时，确定满足预设的缓存清理条件。其中，预设时长不限于特定时长，可以根据业务需要灵活设定。
96.相应地，这时所述清理所述目标节点上缓存的过期数据，包括：将缓存中所述一个
或多个数据分区标识对应的历史记录删除。
97.需要说明的是，当前节点作为临时处理节点，超过预设时长没有接收到一个或多个不属于自身处理分区的待处理记录时，先确定所述一个或多个分区标识，将所述一个或多个分区的缓存历史记录删除。超过预设时长没有接收到一个或多个不属于自身处理分区的待处理记录，表明这一个或多个分区标识对应的第二待处理记录可能由于归属节点(根据数据分区标识确定的优先处理节点)的可用性的恢复，已不再需要其他临时处理节点分担处理，则是此时，当前节点删除这些缓存的历史记录。
98.一些示例性实施例中，所述方法还包括：
99.步骤105，在满足预设的聚档条件时，将所述目标节点上缓存的记录同步至聚档库。
100.一些示例性实施例中，所述满足预设的聚档条件包括以下一个或多个：
101.预设的缓存聚档时间间隔达到时，确定满足预设的聚档条件；
102.缓存记录被删除时，确定满足预设的聚档条件；
103.缓存记录被更新时，确定满足预设的聚档条件；
104.缓存记录被新增时，确定满足预设的聚档条件；
105.缓存更新和/或新增记录数大于预设的变化数量阈值时，确定满足预设的聚档条件。
106.其中，所述聚档库可以是数据库，也可以是文件，或其他可持久化存储数据的形式，不限于特定方式。
107.一些示例性实施例中，步骤104和步骤105的执行顺序可以根据情况调整，不限于特定的先后顺序。
108.需要说明的是，各节点上的缓存数据同步到聚档库的具体方式不属于本技术保护或限定的范围，本领域技术人员根据相关技术方式实施即可，不限定特定方式。
109.一些示例性实施例中，所述方法还包括：
110.步骤106，在满足预设的聚档库清理条件时，清理所述聚档库中的过期数据。
111.一些示例性实施例中，所述满足预设的聚档库清理条件包括以下一个或多个：
112.聚档库中历史记录数大于预设的第二数量阈值时，确定满足预设的聚档库清理条件；
113.聚档库中历史记录数的总数据存储量大于预设的第二存储量阈值时，确定满足预设的聚档库清理条件；
114.预设的聚档库清理时间间隔达到时，确定满足预设的聚档库清理条件。
115.一些示例性实施例中，清理所述聚档库中的过期数据，包括以下方式的一种或多种：
116.计算聚档库各历史记录的已保存时长，删除已缓存时长大于预设的第二时长阈值的历史记录；其中，已保存时长＝当前时间-记录时间；
117.根据聚档库中各历史记录的记录时间，将记录时间最早的p条历史记录删除；p为正整数；
118.根据聚档库中各历史记录的记录时间，将记录时间最早的前百分之q的历史记录删除；q为正数。
119.其中，所述第一时长阈值和第二时长阈值独立设置，可以相同，也可以不同。
120.需要说明的是，本公开实施例中所述的节点代表集群中一个执行分布式任务的逻辑节点，并不特别限定是物理节点。在spark集群处理方案中，一个物理节点上包括一个或多个执行器，每个执行器可以独立执行分布式任务，每个执行器也视为本技术实施例中所述的节点。
121.可以看到，本公开实施例提供的集群中数据处理方法，利用数据分区对应的优先处理节点机制，根据待处理记录的数据分区标识分发数据，保持集群中的各节点能够相对固定地缓存并处理确定分区的数据，避免了集群中多节点缓存数据处理的冲突，也避免了随机分配处理节点导致各节点缓存数据量过大，提升了整体系统的处理性能。在一些示例性实施例中，通过二次分发的方式，在保持正常可用节点的原有数据处理范围的同时，及时分担不可用节点的数据处理任务，整体提升了系统可用性和健壮性。
122.本公开实施例还提供一种电子设备，包括：
123.一个或多个处理器；
124.存储装置，用于存储一个或多个程序，
125.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上述实施例中任一所述的集群中的数据处理方法。
126.本公开实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器实现如上述实施例中任一所述的集群中的数据处理方法。
127.示例
128.本示例以的spark方案实现集群处理逻辑，以车辆监控系统的过车数据的聚档方案为例，整体业务系统逻辑如图2所示。本示例中，每一个执行器为一个逻辑节点，下述记载中在未进行特别说明的情况下，所述节点均代表执行器。
129.步骤1：车辆监控前端设备检测并识别得到的过车数据记录在下表中：
130.表1—车辆聚档表(过车记录)
131.[0132][0133]
每次车辆经过，前端车辆监控设备都将产生新的过车记录。其中，目标标识(id)为：车牌颜色+车牌号码，以此为主键(key)按照分区数量进行哈希取模确定数据分区标识，也称为分区号(partition_id)；待处理记录的记录时间在本示例中为过车时间。或者，产生的新的过车记录中数据分区标识(partition_id)也可以为空。
[0134]
步骤2：前端车辆监测设备产生的待处理记录(待处理过车记录)先接入kafka、rocketmq等消息中间件，集群系统使用spark streaming实时获取过车数据(待处理过车记录)。
[0135]
步骤3：集群中各spark执行器处理如下：
[0136]
3.1、各节点确定以自身为优先处理节点的数据分区标识\分区号，从聚档库加载聚档过车数据至执行器内存中作为历史过车数据缓存。其中，以分区号按执行器数量取模，确定该分区号对应的优先处理节点，每个节点根据此方式即可确定哪些分区将自身作为优先处理节点(偏好节点)。
[0137]
3.2、当spark streaming获取的待处理过车数据中数据分区标识为空(partition_id)时，则将key(车辆唯一标识(id)：车牌颜色+车牌号码))按照分区数量进行哈希取模确定数据分区标识(partition_id)，并将该标识写入待处理的过车数据中。
[0138]
3.3、由于spark streaming处理不同批次的数据时，无法保证相同key的数据分配在同一节点处理，因此先确定每个分区的优先处理节点，也称为spark分区节点偏好，spark会根据优先处理节点(节点偏好)将对应分区的数据分发到指定节点进行处理，保证同一辆车在同一个节点上处理。优先处理节点的确定规则如下：将数据分区标识\分区号按执行器数量取模，获得一个该分区对应的优先处理节点(偏好节点)，将待处理过车记录发往对应的优先处理节点，以此保证同一key只会发往同一物理节点中的同一执行器，并告知对应节点将会发往的数据分区标识\分区号。
[0139]
3.4、为避免因集群故障切换导致优先处理节点(节点偏好)无法满足的情况，进行如下处理：
[0140]
1、当待处理记录对应的优先处理节点掉线或宕机时，spark驱动器与集群中所有节点的执行器进行rpc通信，获得新的节点数量(执行器数量)。原有正常可用节点处理的分区数据(待处理过车记录)继续以原节点数(原有执行器数量)哈希取模，无节点处理的分区数据以新节点数进行哈希取模。无节点处理的分区数据经计算获得新节点号后，spark将此分区数据发往所确定的新节点进行计算处理。如图3所示，原本由物理节点0上执行器处理的分区数据(待处理过车记录)被重新分配到其他物理节点的执行器上处理。其中，图3只示意性显示了被二次分发到物理节点1的执行器上处理的数据流，未体现被二次分发到其他物理节点上执行器的数据流。
[0141]
2、所有节点接收到被分发的待处理过车记录时，也得知发至自身处理的数据分区标识\分区号。节点在处理分区数据(待处理过车记录)前，先读取分区数据携带的数据分区标识\分区号，当读取的数据分区标识\分区号属于自身应处理的一系列数据分区标识\分区号，则正常处理数据。当读取的数据分区标识\分区号不属于自身应处理的一系列数据分区标识\分区号时，此节点会从聚档库中查询当前待处理过车记录的分区标识\分区号对应的所有数据缓存至执行器内存中，并继续运行spark作业。
[0142]
3、当掉线或宕机的节点恢复后，会与spark驱动器进行rpc通信，spark驱动器得知后与集群中所有节点进行rpc通信，获取新的节点数量并哈希取模，继续步骤2。
[0143]
4、所有节点在经过一段时间(所述预设时长，时间可自行配置)，不再读取到不属于自身处理的一个或多个分区号时，将缓存中所有此一个或多个分区号对应缓存的历史记录删除。
[0144]
步骤4：使用执行器(节点)内存中缓存的历史过车信息过滤每个分区中过车数据，更新或新加入过车信息至缓存，并将新加入缓存中的过车信息(过车信息中包括分区号)写入聚档库。
[0145]
步骤5：执行器(节点)内存中缓存数据量过大会因内存溢出而导致spark集群宕机，故给节点中执行器设置第一数量阈值(例如：1000万，一座城市来往过车信息经去重后大约为1000万)。
[0146]
spark streaming作业处理每批数据前，先进行内存缓存清理，具体清理规则如下：
[0147]
1、遍历缓存中所有数据，将每条数据的过车时间与服务器系统当前时间对比，超过给定缓存留存期(第一时长阈值)的数据从缓存中删除。
[0148]
2、判断缓存当前数据量，当数据量超过最大容量(第一数量阈值，1000万)时，将缓
存中数据根据过车时间进行排序，将过车时间最早的前100万(缓存最大容量十分之一)缓存数据删除。
[0149]
步骤6：聚档库中的车辆聚档表中将每条数据过车时间超出聚档库留存期(第二时长阈值)的数据删除。
[0150]
可以看到，相关技术方案中基于redis集群做全局唯一性判断去重，由于需频繁与redis集群做交互，容易导致redis集群宕机，大大增加了服务器的负担。
[0151]
本示例方案通过使用spark集群中的内存做缓存，避免了对其他组件产生的冲击，还可通过添加spark集群中节点数量来线性扩展提升处理量以及做到负载均衡，能够依靠spark集群自身实现高性能、高实时、高扩展、高容错的车辆聚档。
[0152]
本示例提供的集群中数据处理方法，使用分布式内存流式计算框架，用车辆唯一标识哈希取模的方法确定分区，并采用按分区分配优先处理节点(分区节点偏好)的机制实现过车数据到执行器的分发，以达到负载均衡。并利用执行器内的内存作为局部车辆聚档库缓存，实现各个执行器数据处理分区化、局部化，可以实现灵活实现线性扩展。针对集群中故障切换引起执行器下线，导致过车数据无法按照节优先处理节点(分区节点偏好)转发的情况，使用临时车辆聚档缓存加载手段，实现集群故障的容错处理机制，显著提升了整体系统的健壮性。
[0153]
本领域技术人员可以理解，对于其他应用的集群方案处理其他应用记录数据的情况下，采样本公开实施例提供的数据处理方案，都能保持集群中的各节点能够相对固定地缓存并处理确定分区的数据，避免了集群中多节点缓存数据处理的冲突，也避免了随机分配处理节点导致各节点缓存数据量过大，显著提升了集群系统的处理性能和稳定性。本公开实施例所记载的过车记录的聚档方案用于示例性说明相关细节，并不限定本公开实施例的适用范围。
[0154]
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
[0155]
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是在本发明的构思下，利用本发明说明书及附图内容所作的等效结构变换，或直接/间接运用在其
他相关的技术领域均包括在本发明的专利保护范围内。