智能航运数据处理的分布式弹性计算技术研究与应用

肖榕 金瓯 叶建锋

摘 要： 船联网项目涉及到全国范围的内河航运数据，需要连通所有省级航运数据中心并接入数据，因此需要具备分布式、可线性扩展的并行计算能力。针对船联网项目中智能航运数据处理场景，参考国内外成熟的理论基础，提出了一种两级分布式弹性计算技术，介绍了其计算模型和故障处理机制，并描述了该计算框架的应用场景。这种计算技术可以完成海量航运数据的处理任务，满足上层航运信息服务的需求，并适应今后不断增长的数据量和计算规模。

关键词： 内河航运； 弹性计算技术； 两级分布式； 数据处理

中图分类号：TP301 文献标志码：A 文章编号：1006-8228（2014）06-34-04

0 引言

内河航运是我国综合运输体系的重要组成部分，在我国经济发展中起着非常重要的作用。针对航运市场发展的总体态势，发挥信息化对水路运输行业现代化发展的支撑和引领作用，以信息资源共享为基础，以信息服务为核心，以现代物联网技术、通信技术和信息技术为支撑，以促进水路交通运输产业和物联网产业发展为目标，进行智能航运信息服务应用的研究。

物联网是通过基础设施层的各种感知设备感知物体信息，然后利用网络技术将感知获取的海量数据传输至物联网数据中心，物联网信息服务系统整合了海量数据，为各种物联网应用提供信息服务并接收反馈控制[4]。而船联网是物联网的一个典型的应用，船联网以船舶、航道、陆岸设施为基本节点和信息源，结合具有卫星定位系统、无线通信技术的船载智能信息服务，利用船载电子传感装置，通过网络完成信息交换，在网络平台上完成各节点的属性和动/静态信息的进行提取、监管和利用[5]。

1 平台架构

船联网项目采用一个中心、多个省级分节点的部署架构，借助目前成熟的MapReduce计算模型，结合智能航运数据处理的实际需要，本文提出一种两级分布式计算平台：中心和各省分节点之间组成一个船联网全局性的分布式平台；中心节点自身建设为一个局域分布式平台。这里称大平台为全局分布式框架，中心节点的局域平台为中心分布式框架，示意如图1。

船联网全局分布式框架广域部署，通过中心节点调度各省资源，支撑船联网省级航运业务应用，如区域船舶监控、应急指挥等。中心分布式框架在中心节点局域部署，通过中心主节点调度中心分节点资源，支撑项目全局性的业务应用，如综合监管、统计分析等。

这两级分布式计算框架都需要能够处理航运海量的数据，比如船舶船员基本信息、船舶签证、船舶动态感知数据、航运地理信息数据等。从区别上讲，全局分布式框架侧重各省级分节点与中心节点、分节点之间的互联互通和数据共享；中心分布式框架用于完成中心节点各种数据计算任务，并为全局分布式框架的计算调度提供支持。

2 计算模型

2.1 全局分布式框架计算模型

船联网全局分布式框架的计算模型如下。

⑴ 各省级分节点处理各省航运数据，包括数据的整合、清洗、转换等，即分节点可以处理的计算任务直接在分节点完成。

⑵ 中心节点整合各个分节点上报的数据，包括船舶船员基本信息、船舶签证信息、动态感知信息等。

⑶ 船舶船员基本信息、编码等静态数据由中心节点轮询各分节点采集；船舶签证信息、感知信息等动态数据由分节点主动推送。

⑷ 各分节点只与中心节点联系，分节点之间不直接交换数据。

2.1.1 省级分节点的数据处理

省级分节点负责从各省航运业务系统采集数据，完成省一级的数据整合和清洗，同时可以支撑省一级的航运应用。

例如，A省有一GPS系统采集船舶位置信息，则A省分节点负责从该GPS系统采集船舶位置信息并存储，然后完成数据的校验清洗，再按要求将该数据上传中心节点。A省如有另一业务系统只需要本省船舶GPS信息，则直接从A省分节点获取，不需要向船联网中心节点发起请求。

2.1.2 中心节点的数据处理

船联网中心节点负责接收各个省级分节点上传的已初步清洗的数据，然后再作最终的数据整合。由于在各分节点已清洗过，已屏蔽掉大量数据问题，所以中心节点只需要处理少量计算（主要是再一次检验的计算量）即可完成数据整合。

完成整合后的数据在中心节点落地，交由中心节点作进一步的分析处理。船联网在整合数据的基础上提供全局性的数据服务支持，比如跨区域的数据服务。

2.1.3 节点间的数据传输机制

船联网节点间的数据传输将只在中心节点和分节点之间进行，分节点之间相互隔离。中心节点定期轮询各个省级分节点，将船舶基本信息等主数据采集上来（分节点提供相应的数据库接口），并监控各分节点的运行状态。各个省级分节点通过消息服务，定期将签证、感知信息等动态实时数据推送给中心节点。

2.2 中心分布式框架计算模型

船联网中心节点分布式框架计算模型使用目前较为成熟的MapReduce计算模型。目前世界上最快的1TB排序记录就是由基于MapReduce实现的。

MapReduce将计算任务划分为map和reduce两个阶段。map阶段负责“分”，即把复杂的任务分解为若干个“简单的任务”执行。“简单的任务”有以下几个含义：

⑴ 数据或计算规模相对于原任务要大大缩小；

⑵ 就近计算，即任务会被分配到存放了所需数据的节点进行计算；

⑶ 这些小任务可以并行计算，彼此间几乎没有依赖关系。

reduce阶段负责对map阶段输出的结果进行汇总，即将分割开的任务合并，将与一个key关联的一组中间数值集归约为一个更小的数值集，输出最终的计算结果。

2.2.1 MapReduce执行机制[1-3]

通过将Map调用的输入数据自动分割为M个数据片段的集合，Map被分布到多台机器上调用执行。输入的数据片段能够在不同的机器上并行处理。使用分区函数将Map调用产生的中间key值分成R个不同分区，Reduce调用也被分布到多台机器上执行。分区数量和分区函数由用户来指定。

⑴ 计算程序首先调用的MapReduce库将输入文件分成M个数据片段，每个数据片段的大小一般从 16MB到64MB（可以通过备选参数来控制每个数据片段的大小）。然后计算程序在机群中创建大量的程序副本。

⑵ 这些程序副本中有一个特殊的程序-master。副本中其他程序都是worker程序，由master分配任务。有M个map任务和R个reduce任务将被分配，master将一个map任务或reduce任务分配给一个空闲的worker。

⑶ 被分配了map任务的worker程序读取相关的输入数据片段，从输入的数据片段中解析出key/value对，然后把key/value对传递给计算程序自定义的map函数，由map函数生成并输出的中间key/value对，并缓存在内存中。

⑷ 缓存中的key/value对通过分区函数分成R个区域，之后周期性的写入到本地磁盘上。缓存的key/value对在本地磁盘上的存储位置将被回传给master，由master负责把这些存储位置再传送给reduce worker。

⑸ 当reduce worker程序接收到master程序发来的数据存储位置信息后，使用RPC从map worker所在主机的磁盘上读取这些缓存数据。当reduce worker读取了所有的中间数据后，通过对key进行排序后使得具有相同key值的数据聚合在一起。由于许多不同的key值会映射到相同的reduce任务上，因此必须进行排序。如果中间数据太大无法在内存中完成排序，那么就要在外部进行排序。

⑹ reduce worker程序遍历排序后的中间数据，对于每一个惟一的中间key值，reduce worker程序将这个key值和它相关的中间value值的集合传递给用户自定义的reduce函数。reduce函数的输出被追加到所属分区的输出文件。

⑺ 当所有的map和reduce任务都完成之后，master唤醒计算程序。在这个时候，在计算程序里的对MapReduce调用才返回。

2.2.2 结果数据的处理

在成功完成任务之后，MapReduce的输出存放在R个输出文件中（对应每个Reduce任务产生一个输出文件，文件名由用户指定）。如果这些输出不是最终的业务计算结果，则不需要将这R个输出文件合并成一个文件，而是把这些文件作为另外一个MapReduce的输入，或者在另外一个可以处理多个分割文件的分布式应用中使用。

当得出最终的业务计算结果，可能需要将数据迁移到适合业务应用访问的存储中，比如关系型数据库或支持高并发、低响应延迟的NOSQL数据库中。

3 节点故障处理机制

作为一个分布式计算平台必须要能很好地处理节点故障，不能因为某一个节点的故障而导致整个集群的计算任务失败。对于任务本身因为代码缺陷造成的执行失败，当任务执行次数超过一定阈值后便不再执行，不列为节点故障问题。

3.1 中心节点故障

中心节点分布式框架中存在worker和master两类节点角色。

3.1.1 worker故障

master周期性地ping每个worker。如果在一个约定的时间范围内没有收到worker返回的信息，master将把这个worker标记为失效。所有由这个失效的worker完成的map任务被重设为初始的空闲状态，之后这些任务就可以被安排给其他的worker。同样，worker失效时正在运行的map或reduce任务也将被重新置为空闲状态，等待重新调度[2]。

当worker故障时，由于已经完成的map任务的输出存储在这台机器上，map任务的输出已不可访问了，因此必须重新执行。而已经完成的reduce任务的输出存储在全局文件系统上，因此不需要再次执行。

当一个map任务首先被worker A执行，之后由于worker A失效了，又被调度到worker B执行，这个“重新执行”的动作会通知给所有执行reduce任务的worker。任何还没有从worker A读取数据的reduce任务将从worker B读取数据。

MapReduce可以处理大规模worker失效的情况，MapReduce master只需要简单地再次执行那些不可访问的worker的工作，之后继续执行未完成的任务，直到最终完成这个MapReduce操作。

3.1.2 mastre故障

一个简单的解决办法是，让master周期性的将描述集群计算任务的数据结构的写入磁盘（位于集群以外的位置），即检查点（checkpoint）。如果这个master任务失效了，可以从最后一个检查点（checkpoint）开始启动另一个master进程。然而，由于只有一个master进程，master失效后再恢复是比较麻烦的，因此我们现在的实现是，如果master失效就中止MapReduce运算。客户可以检查到这个状态，并且可以根据需要重新执行MapReduce操作[2]。

当用户提供的map和reduce操作是输入确定性函数（即相同的输入产生相同的输出）时，我们的分布式计算任务在任何情况下的输出都和所有程序以正常的顺序执行所产生的输出是一样的。

3.2 省级分节点故障

基于全局分布式框架的计算模型，如果省级分节点发生故障，则该省的数据将缺失（主要是影响动态感知数据），和该省相关的数据计算任务都将失败。但不会影响其他省与中心节点之间的业务，中心节点仍能保持绝大部分的业务服务能力。

省级分节点需要具备一定的冗灾机制，比如数据库HA、数据备份，以应对分节点故障，保证分节点的不间断运行。同时在省级分节点和中心节点之间的网络设施上也应该有一定的冗余，以应对突发事件。

4 应用场景

以下论述船联网两级分布式计算框架的应用场景，以及在各个场景下集群的计算扩展能力。

4.1 跨省船舶监控

船联网要求实现跨省船舶实现联网监控，比如A省船舶进入B省区域，B省应能够立即获取到该船舶的基本信息和动态感知数据（如GPS）。

在船联网分布式计算框架下，当有船舶跨省行驶，船舶所属省的省级分节点将率先监控到这一行为，分节点会查询该船只的基本信息和签证信息，然后通知中心节点，并开始向中心节点持续发送该船只的动态感知数据。中心节点得到信息后，更新该船只的状态信息，然后联系船舶进入的目的省所在的省级分节点，将船舶基本信息、动态数据也发送给目的省分节点。当船只返回原籍或驶入其他省份，则中心节点变更推送的目的分节点。如此一来，跨省船舶的信息在中心节点和目的省都可以查询和监控，在保证集群线性扩展能力的前提下完成了跨省船舶的监控跟踪。

4.2 航运数据质量分布式管控

智能航运首先需要按照一个统一的数据标准校验其数据质量，通过校验的数据才能应用于应用服务。同时，船联网也需要一套持续可行的数据质量管理机制，保证后续数据处理的规范性。

通过智能航运数据处理的分布式弹性计算框架，可以采取分而治之的方式达到数据质量的管控，同时也能保证整体架构的扩展性。中心节点制定数据质量管控的规范，下发数据标准到各个省级分节点。省级分节点按照数据标准校验并清洗自己负责的部分，转换为符合要求的数据结构，然后将结果数据和数据质量处理报告上报给中心节点。如果省级分节点持续增加，数据在达到一定规模限制后中心节点也可以借助自身的中心分布式框架进行计算扩展。

4.3 海量航运数据挖掘分析

随着海量航运数据的集中，为挖掘数据的内在价值，需要对这些业务数据进行统计分析和数据挖掘，如预测建模、关联分析、数据聚类、异常检测等。进行海量航运数据挖掘分析时，两级分布式计算框架通过全局分布式保证了挖掘模型样本的数据质量，然后在中心分布式框架上完成挖掘分析计算。在中心分布式框架上可以结合mahout、R等挖掘分析软件，更快速地完成分析模型的构建。

5 结束语

两级分布式计算平台的设计体系可以在满足当前智能航运数据处理要求的情况下，充分考虑到今后航运信息化发展中数据爆炸性增长时的计算扩展要求。虽然在初期，整个分布式计算平台的建设需要一定的投入（涉及多个省市以及中心节点的建设），但由于具备良好的线性扩展能力，今后的集群扩展成本将非常可控：平台不需要更换升级，只要不断增加节点，即可以提供不断增长的计算能力。随着具体计算需求的落地和实现，智能航运分布式计算平台将充分挖掘航运数据中的价值，为航运业务应用提供更好的数据支撑和运算服务。

参考文献：

[1] L?mmel R. Google's MapReduce programming model—Revisited[J].Science of computer programming，2008.70（1）： 1-30

[2] Dean J， Ghemawat S. MapReduce： simplified data processing on

large clusters[J]. Communications of the ACM，2008.51（1）：107-113

[3] Urbani J， Kotoulas S， Oren E， et al. Scalable distributed reasoning

using mapreduce[M]//The Semantic Web-ISWC 2009. Springer Berlin Heidelberg，2009：634-649

[4] 周开乐，丁帅，胡小建.面向海量数据应用的物联网信息服务系统研究综述[J].计算机应用研究，2012.29（1）.

[5] 赵学洋，李海红，储凌剑.基于船联网的内河智能航行体系探讨研究[J].新技术新工艺，2013.6：117-121