一种基于众包地图更新的海量数据接入处理方法及系统与流程

本发明涉及大数据领域，尤其涉及一种基于众包地图更新的海量数据接入处理方法及系统。

背景技术：

众包地图数据为众包采集的高精度地图数据，基于车端众包采集的地图数据对于高精度地图制作，以及高精度地图更新具有重要作用。然而随着接入的众包地图数据增多，对服务端的海量数据处理提出了更高要求。

目前，对于海量接入数据处理方案有将接入数据传至kafka队列，然后通过流处理引擎，将数据实时写入hbase数据库，可以基本满足数据存储及分析处理要求，然而，随着数据量的进一步增加，服务器端负载过大，难以保证数据的实时处理要求。

技术实现要素：

有鉴于此，本发明实施例提供了一种基于众包地图更新的海量数据接入处理方法及系统，以解决现有海量数据接入处理时服务器端负载过大，难以满足数据实时处理要求的问题。

在本发明实施例的第一方面，提供了一种基于众包地图更新的海量数据接入处理方法，包括：

接收车端众包地图更新数据后，通过基于lvs中的nat机制将数据转发至后台服务器；

基于keepalived和nginx代理进行服务转发后，由服务集群nio创建多线程数据处理任务，并通过kafka生成多任务消息队列；

获取消息队列中数据处理任务进行微服务处理，将处理后的更新数据存储至hdfs文件系统，并在非结构化数据库hbase中进行管理。

在本发明实施例的第二方面，提供了一种基于众包地图更新的海量数据接入处理系统，包括：

数据接入模块，用于接收车端众包地图更新数据后，通过基于lvs中的nat机制将数据转发至后台服务器；

数据处理模块，用于基于keepalived和nginx代理进行服务转发后，由服务集群nio创建多线程数据处理任务，并通过kafka生成多任务消息队列；

数据存储模块，用于获取消息队列中数据处理任务进行微服务处理，将处理后的更新数据存储至hdfs文件系统，并在非结构化数据库hbase中进行管理。

本发明实施例中，接收车端众包地图更新数据后，通过基于lvs中的nat机制将数据转发至后台服务器；基于keepalived和nginx代理进行服务转发后，由服务集群nio创建多线程数据处理任务，并通过kafka生成多任务消息队列；获取消息队列中数据处理任务进行微服务处理，将处理后的更新数据存储至hdfs文件系统，并在非结构化数据库hbase中进行管理。可以对接入的海量数据进行实时快速的处理及存储，实现服务器端负载均衡，解决了现有海量众包地图更新数据接入处理时服务器端负载过大，难以满足实时性的问题，有效提升服务器的数据处理速度，保障服务端的实时性、可靠性及兼容性。

附图说明

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

图1为本发明的一个实施例提供的基于众包地图更新的海量数据接入处理方法的流程示意图；

图2为本发明的一个实施例提供的基于众包地图更新的海量数据接入处理方法的框架结构示意图；

图3为本发明的一个实施例提供的基于众包地图更新的海量数据接入处理系统结构示意图。

具体实施方式

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

本发明的说明书或权利要求书及上述附图中的术语“包括”以及其他相近意思表述，意指覆盖不排他的包含，如包含一系列步骤或单元的过程、方法或系统、设备没有限定于已列出的步骤或单元。

请参阅图1，图1为本发明实施例提供的一种基于众包地图更新的海量数据接入处理方法的流程示意图，包括：

s101、接收车端众包地图更新数据后，通过基于lvs中的nat机制将数据转发至后台服务器；

所述车端众包地图更新数据为基于车端采集的众包地图数据，服务端生成更新地图后，可以根据用户请求返回更新的地图数据，在所述车端众包地图更新数据中可以包括用户上传的众包地图数据、地图更新请求数据。所述lvs(linuxvirtualserver)即linux虚拟服务器，用于将用户请求调度发送至后台web服务器，所述nat(networkaddresstranslation)即网络地址转换，通过数据报头可以使得外部请求访问内部私有ip主机。基于lvs中的nat机制可以决定对哪些流量数据进行负载均衡。

可选的，对预定众包地图更新数据进行nat地址转换处理，记录处理所述预定众包地图更新数据的服务器地址，并将后续接收的所述预定众包地图更新数据转发至对应的服务器地址。

s102、基于keepalived和nginx代理进行服务转发后，由服务集群nio创建多线程数据处理任务，并通过kafka生成多任务消息队列；

所述keepalived用于实现服务器的高可用，通过检测服务器状态防止单点故障导致业务无法访问的问题。所述nginx为一个高性能的http和反向代理服务器，基于keepalived和nginx代理可以根据网络请求类型，进行服务分流，具体的，基于nginx对http应用的请求进行分流，如根据http域名、目录结构进行服务分流。

所述ni即及newio，基于nio可以为数据提供缓存支持的数据容器。由服务集群nio根据用户请求创建多线程的数据处理任务，基于kafka消息订阅发布系统，方便数据的实时处理。

优选的，在用户请求高并发情况下，将车端众包更新数据存储至redis中，根据业务逻辑，定期将所述车端众包更新数据同步至关系型数据库postgresql中。

s103、获取消息队列中数据处理任务进行微服务处理，将处理后的更新数据存储至hdfs文件系统，并在非结构化数据库hbase中进行管理。

每个任务经微服务化处理后，对应的处理结果可以存储至至hdfs文件系统，或根据处理结果访问hbase中存储的数据。所述hbase为基于hdfs(hadoopdistributedfilesystem)、分布式的非关系型数据库，基于hbase管理海量众包地图更新数据。

优选的，在用户请求高并发情况下，将车端众包更新数据存储至redis中，根据业务逻辑，定期将所述车端众包更新数据同步至关系型数据库postgresql中。

优选的，配置主从数据库，设定在从库中进行数据读取，在主库进行增加、删除、修改操作。

可选的，在hbase中数据存储于hdfs文件系统，并通过zookeeper进行master和regionserver的协调管理。

在本发明另一个实施例中，提供了基于众包地图更新的海量数据接入处理方法对应的框架结构示意图，如图2所示：

在lvs4层负载均衡模块210中，是基于ip+端口的负载均衡，通过发布三层的ip地址(vip)，然后加四层的端口号，决定哪些流量需要做负载均衡，对需要处理的流量进行nat处理，转发至后台服务器，并记录下tcp或者udp的流量是由对应的哪台服务器处理，后续同样来源的所有流量都可以转发到同一台服务器处理。lvs工作在网络4层之上，没有流量的产生，对内存和cpu的资源消耗也比较低，同时工作稳定，其自身有完整的双机热备方案，负载均衡能力较为突出。

在7层负载均衡模块220，为基于url等应用层信息的负载均衡，即在四层的基础上考虑应用层的特征，如同一web服务器的负载均衡，除了根据vip加80端口判断是否为需要处理的流量，还可根据七层的url、浏览器类别、语言来决定是否要进行负载均衡。nginx工作在网络的7层上，可以针对http应用进行分流，比如针对域名、目录结构。nginx对网络稳定性依赖较小，可以承担高负载压力且稳定，一般能支撑几万次的并发量。nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。，

在一个实施例中，在高并发的情况下，可以将车端采集的数据先存入到redis，再根据一定业务逻辑，定期同步到关系型数据库postgresql中，对于平台的性能可以大幅提升。

对于众包地图数据更新应用系统，采用了关系型数据库postgresql和大数据hadoop分布式进行存储。相关的应用系统数据存储在postgresql中，测绘数据存储到hadoop中的hdfs中。根据应用服务器的特点和数据库服务器的特点进行底层的优化，由于应用服务器需要的磁盘空间较小，可以防止一台服务器出现问题连带的其他服务不能使用。

将应用程序对数据库的读写操作分配到多个数据库服务器上，从而降低单台数据库的访问压力。一般可以通过配置主从数据库的方式，数据的读取来自从库，对数据库增加修改删除操作主库。

在数据存储服务模块230中，由于hbase表能够容纳上百亿行、上百万列。面向列的存储，数据在表中是按照列进行存储的，能够动态的增加列并对列进行各种操作，并能够接近准实时的查询(百毫秒以内)，支持多版本数据。其中，hbase中的数据存储于hdfs中且依赖于zookeeper进行master和regionserver的协调管理。

本实施例提供的方法，基于数据转发、缓存、分布式任务处理、海量数据存储等多方面的负载均衡设计，可以实现海量数据的快速处理，满足系统实时性要求。

应理解，上述实施例中各步骤的序号大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定，

图3为本发明实施例提供的一种基于众包地图更新的海量数据接入处理系统的结构示意图，包括：

数据接入模块310，用于接收车端众包地图更新数据后，通过基于lvs中的nat机制将数据转发至后台服务器；

可选的，所述通过基于lvs中的nat机制将数据转发至后台服务器包括：

对预定众包地图更新数据进行nat地址转换处理，记录处理所述预定众包地图更新数据的服务器地址，并将后续接收的所述预定众包地图更新数据转发至对应的服务器地址。

数据处理模块320，用于基于keepalived和nginx代理进行服务转发后，由服务集群nio创建多线程数据处理任务，并通过kafka生成多任务消息队列；

可选的，所述基于keepalived和nginx代理进行服务转发包括：

基于nginx对http应用的请求进行分流，并通过端口检测对应服务器内部故障。

可选的，在用户请求高并发情况下，将车端众包更新数据存储至redis中，根据业务逻辑，定期将所述车端众包更新数据同步至关系型数据库postgresql中。

数据存储模块330，用于获取消息队列中数据处理任务进行微服务处理，将处理后的更新数据存储至hdfs文件系统，并在非结构化数据库hbase中进行管理。

可选的，所述数据存储模块330包括：

配置单元，用于配置主从数据库，设定在从库中进行数据读取，在主库进行增加、删除、修改操作。

优选的，在hbase中数据存储于hdfs文件系统，并通过zookeeper进行master和regionserver的协调管理。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，包括步骤s101至s103，所述的存储介质包括如：rom/ram、磁碟、光盘等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。