智慧交通云平台建设方案.docx
《智慧交通云平台建设方案.docx》由会员分享，可在线阅读，更多相关《智慧交通云平台建设方案.docx（86页珍藏版）》请在冰点文库上搜索。
智慧交通云平台建设方案
智慧交通云平台建设方案
（此文档为word格式，下载后你可任意修改编辑）
1系统总体设计
1.1云计算系统设计方案概述
1.1.1系统基本功能
按照全省公安机关信息化建设总体规划，为实现对重点车辆的自动比对和动态管控、对异常车辆行踪的自动研判预警、对特定车辆行车轨迹的自动生成、对重要节点道路交通信息的远程再现、对基层单位和执勤民警的勤务实施管理等建设目标，为交通管理、治安管控、侦查破案、巡逻防范、反恐处突等各项公安工作提供服务保障。
系统的基本功能和性能如下：
海量数据存储
能够对百亿级的海量交通监控数据进行存储，保存时间为2年。
海量数据实时处理、实时入库、生成索引
能够对百亿级的海量交通监控数据进行实时处理，能够处理每天500万条记录，能够实时处理约60条/秒的实时数据流量。
百亿级数据秒级查询能力、秒级实时业务响应
高效实时数据查询架构，提供秒级响应时间，1天的记录能在5秒钟内查询出来，一周记录能在15秒内查询出来。
1.1.2主要设计思想和设计目标、设计原则
设计思想：
将海量数据分解到由大量X86架构计算机构成的低成本云计算平台上进行实时处理，依靠分布式云计算软件进行容错，从而提升智慧交通云平台海量数据分析的实时性和性价比。
设计目标：
利用大量性价比高的计算机，建立云计算平台，能够对流量超过500w条/天的原始交通监控数据流进行实时处理。
系统具有可动态可伸缩性、高度容错性和响应实时性，达到较之传统方案有一个数据量级的性能价格比提升。
设计原则：
（1）前瞻性技术与实际应用环境相结合
本项目是既是先进技术应用示范项目，又是工程实施型项目。
把握技术正确性和先进性是前提，但是前瞻性技术实施必须在云计算平台的实际应用环境和实际监控流量的基础上进行，必须结合云计算平台的实际情况进行研究和开发，只有与实际应用环境相结合才有实际应用价值。
（2）学习借鉴国外先进技术与自主创新相结合
在云计算平台用于超大规模数据处理方面，国内外几乎是在一个起跑线上；但在关键技术研究及既往的技术积累方面，国外一些大公司有着明显的优势。
同时，智慧交通云平台所将要面对的交通监控数据流高达500w条/天，是一个世界级的云计算应用。
我们将积极学习借鉴国外先进的云计算技术，同时与自主创新相结合，形成功能强大、性能卓越的能够满足实际应用环境需求的云计算数据处理和分析平台。
（3）遵循公安320工程相关标准规范
本项目的设计将严格遵循公安320工程相关标准规范。
1.1.3智慧交通云平台的云计算解决方案
在公安网内部，构建若干X86架构计算/存储节点，虚拟出海量存储空间、处理能力和数据管理能力。
同时研制面向应用的分布式数据处理软件，满足数据汇总、数据上报、数据入库、数据查询、数据计算和数据管理等应用需求。
图表1智慧交通云平台云计算解决方案
1.1.4系统的主要技术特点
实时性：
平台在高效率并行分布式软件的支撑下，可以实时完成交管数据入库、分析和管理工作，如数据汇总、数据上报、数据入库、数据查询、数据计算和数据管理等。
海量数据入库不会出现数据堆积现象，各类分析和查询工作基本都在秒级完成，具有前所未有的高效性。
高可靠性：
基于对云计算可靠性深厚的研究积累，彻底解决了当前分布式计算平台易出现的单点故障问题。
任何一个节点出现故障，系统将自动屏蔽，而且不会出现丢失数据的现象。
包括查询任务分配节点、计算任务分配节点、HDFS元数据节点、HDFS数据存储节点、MapReduce JobTracker节点、MapReduceWorker节点、HBase管理节点、HBaseRegion节点等。
可伸缩性：
在不停机的情况下，增加节点，平台的处理能力自动增加；减少节点，平台的处理能力自动缩减。
这样，可以做到与云计算平台的无缝对接，根据计算和存储任务动态地申请或释放资源，最大限度地提高资源利用率。
高性价比：
采用X86架构廉价计算机构建云计算平台，用软件容错替代硬件容错，大大节省成本。
在目标性能和可靠性条件下，可比传统的小型机加商用数据库方案节省10倍左右的成本。
全业务支持：
采用分布式数据库模式，绝大部分海量数据存放于分布式平台并进行分布式处理，少量实时性要求很高的数据存放于关系数据库中，可支撑各种类型的业务。
不仅支撑查询、统计、分析业务，还可支撑深度数据挖掘和商业智能分析业务。
1.2系统总体构架
1.2.1系统基本组成与构架
智慧交通云平台是一个处于交管数据采集与交管数据监测应用之间的系统。
从系统基本组成与构架上来看，该共享平台由7个主要部分组成：
历史数据汇总处理系统，上报数据上报系统，实时数据入库系统，交管数据存储系统，交管数据查询分析应用系统，数据管理系统以及系统管理。
1.2.2系统功能构架
智慧交通云平台需要提供的7大主要功能描述如下。
（1）历史数据汇总处理系统
历史数据汇总处理主要负责把南京市6个分散的数据中心的历史数据，进行读取解析处理，并将处理后的历史数据汇入一个统一的数据中心。
在内部处理模块上，历史数据汇总系统主要包括三个模块：
读取模块、解析模块和汇总模块。
读取模块主要负责各个数据中心历史数据的读取处理，解析模块主要负责把读取到的历史数据解析成合理的数据格式，而汇总模块主要负责把解析好的历史数据上传到统一的数据中心。
在系统构架上，为了满足6个分散的数据中心处理需要，需要在每一个数据中心处安装一个数据汇总程序。
（2）上报数据上报处理信系统
上报数据上报处理负责把市数据中心的数据，按照一定的需求（按时间段或一定的数据量），上报给省厅数据中心。
在内部处理模块上,上报数据上报系统主要包括三个模块：
读取模块、解析模块和上报模块。
读取模块主要负责市数据中心需要上报数据的读取处理，解析模块主要负责把读取到的数据解析成合理的数据格式，而上报模块主要负责把解析好的数据上传到的省厅数据中心。
在系统构架上，为了满足市数据中心处理需要，需要在市数据中心处安装一个数据上报程序。
而省厅数据中心需要提供数据上报的接口。
（3）实时数据入库系统
实时数据入库系统主要负责全市每个卡口产生的数据实时入库。
在内部处理模块上，实时数据入库系统主要包括三个模块：
接受模块、解析模块和数据入库模块。
接受模块主要负责接收每个卡口产生的数据流，解析模块主要负责把接受到的数据流解析成合理的数据格式，而数据入库模块负责把解析好的数据加入到市数据中心。
在系统架构上，为了使每个卡口的数据能实时入库市数据中心，需要在每一个负责接受卡口数据的工控机上安装一个实时数据入库系统。
（4）交管数据存储系统
原始交管数据，将全部存储在智慧交通云平台的云存储资源中。
资源池提供两种存储资源：
一种是结构化数据存储资源，用于存储少量的接口中间数据；另一种是分布式文件系统，用于存储海量的非结构化数据。
为了满足和适应数据量、数据特征和查询处理的不同需求，将采用一种混搭式的数据存储方案。
对容量巨大、常规数据库难以处理的数据，如交管数据，将主要存储在基于HDFS的分布式文件系统中；这些数据将通过HDFS接口进行访问和计算处理。
而对于部分数据量不大、且查询响应性能要求很高的数据，如用于报警比对的中间数据，将被存放在关系数据库中。
关系数据库将采用SybaseASE版本。
这些数据将通过结构化数据存储访问接口（如JDBC）进行访问。
在存储构架上，若以存储3年的原始交管数据、报警信息数据和针对快速查询建立的索引数据，在10000条/s的交管数据流量下，将大约需要512TB的存储容量，按照每个存储节点16TB的存储容量，加上少量的冗余节点，将需要32个存储节点。
（5）交管数据查询分析应用系统
交管数据查询分析应用主要提供包括实时监控、报警监控、车辆轨迹与回放、电子地图、报警管理、布控管理、设备管理、事件检测报警、流量统计和分析等功能。
车辆轨迹查询处理时，由于交管数据量巨大，难以存储在常规的关系数据库中，而如果直接存储在HDFS或HBase中又难以保证查询效率。
为此，需要考虑对交管数据进行索引处理，并将索引数据存储在HDFS或Hbase中。
为了建立交管数据索引，需要在交管数据传送到云存储系统中时，进行实时的索引处理。
但由于交管数据流量巨大，需要调度使用多台服务器节点进行并行处理。
此外，用户从客户端发起以上各种数据查询分析任务时，也会产生大量并发的查询任务。
以上各种查询分析计算任务的处理将需要考虑在计算集群上进行并行化任务调度和负载均衡处理。
这些并行计算任务及负载均衡处理将使用Zookeeper基于计算集群完成统一的控制和实现。
在系统构架上，以上查询分析计算任务将需要使用一个大规模数据并行计算集群。
在编程实现上，存储在数据库中的数据将使用常规的数据库查询语言实现；对存储在分布式文件系统中的交管数据，针对不同的处理要求，在数据量极大而处理实时性要求不是特别高的情况下，为了方便对海量数据的并行处理，将采用MapReduce编程方式实现；而对于那些实时性要求很高的查询分析计算，由于MapReduce启动作业需要较长的时间开销，将不适合采用MapReduce编程实现，而需要用非MapReduce编程方式实现。
（6）数据管理系统
在实际使用中，可能用户会对某一时间段或者类型的数据特别关心，就可以通过数据管理系统查询并导出这部分数据以供使用。
包括数据查询和数据导出两大部分。
数据查询让用户以自定义的条件查询出数据，而数据导出就是将这些数据以合理的格式导出到数据中心以外。
（7）系统管理
系统管理主要包括智慧交通云平台的配置管理、系统安全管理、系统用户管理，以及数据备份、系统故障监测复等管理维护功能。
配置管理是其中最主要的部分，是系统各个模块正常运行的基础。
系统应能够对网络地址、设备地址等进行配置；能够对用户做权限管理，以防止数据外泄；并能及时有效的对数据进行备份和故障检测等工作，防止数据的意外丢失。
系统应支持树图、数据表格、网络拓扑图形式展示配置数据。
1.2.3系统总体构架与功能模块
基于以上基本的系统组成和功能构架，系统的详细总体构架和功能模块设计如图所示。
图表3智慧交通云平台总体构架与功能模块图
上图中，自底向上分为五个层面。
最下层是硬件平台层，将使用南京市公安局云计算中心所提供的计算、存储和网络资源。
从系统处理系统的角度看，这一层主要包括云存储计算集群，此外还包括接口和管理服务器、包括用于实现客户端访问的Web服务器。
第二层是系统软件层，包括移动的云存储系统软件，综合分析云计算软件平台，以及Web服务软件等。
云存储系统将提供基于SybaseASE关系数据库的结构化数据存储访问能力，以及基于HDFS的分布式文件系统存储访问能力，分别提供基于JDBC/SQL的数据库访问接口以及HDFS访问接口。
综合分析云计算软件平台可提供对HDFS、Hbase数据的访问，并提供MapReduce编程模型和接口、以及非MapReduce模型的编程接口，以及用于实现并行计算任务负载均衡和服务器单点失效恢复的Zookeeper。
第三层是智慧交通云平台中的数据层，包括原始交管数据、索引数据、用于分析的中间数据、以及系统配置数据等。
其中，原始交管数据、索引数据等海量数据将存储在南京公安局云存储系统的HDFS分布式文件系统中，用HDFS接口进行存储和访问处理；而其它用于分析的中间数据等数据量不大、但处理响应性能要求较高的数据，将存储在云存储系统的关系数据库系统中，用JDBC/SQL进行存储和访问处理。
第四层是交管数据处理软件层，主要完成智慧交通云平台所需要提供的诸多功能，包括实时监控、报警监控、车辆轨迹查询与回放、电子地图、报警管理、布控管理、设备管理、事件检测报警、流量统计和分析、系统管理等功能。
最上层是客户端用户界面软件，主要供用户查询和监视相关的数据信息，除了事件检测报警不需要用户界面外，其它部分都需要实现对应的用户界面。
1.3系统基本功能与处理方案
1.3.1交管数据入库功能与处理方案
交管数据入库系统总架构如图：
图表4智慧交通云平台架构
智慧交通云平台通过实时数据入库系统接入采集层的交管数据，数据分配进入负载均衡机，负载均衡机根据集群各节点负载情况，动态分配交管数据到各存储处理机，进行报警检测、建立索引等处理，同时将交管数据存入分步式存储系统。
负载均衡机功能
监控所集群机器负载情况，动态分配交管数据。
监控所有集群机器，如果发现问题，那么就把分配给这台机器的交管数据重新分配到其他机器，去除单点故障，提高系统可靠性。
负载均衡机采用Paxos算法解决一致性问题，集群在某一时刻只有一个Master负责均衡能力，当Master宕机后，其他节点重新选举Master。
保证负载均衡机不会存在单点问题，集群机器一致性。
实时业务
对于实时性要求高的业务应用，如：
实时监控、实时报警，走实时专道。
1.3.2数据存储功能与处理方案
数据存储处理总架如图：
图表5数据存储处理架构
数据存储系统提供如下功能：
交管数据处理：
接收来自数据汇总和数据入库系统的交管数据，索引模块实时生成索引，以提高查询速度。
生成的索引存储到HDFS中，以供查询交管数据使用。
专题业务分析，通过MapReduce并行计算，同期提取业务数据，将结果分存两路，一路存入Hbase或日志详单存储，一路存入关系型数据库。
报警数据处理
智慧交通云平台对接收到的实时交管数据进行计算，以判断这辆车有没有符合报警条件。
如果符合，会对报警信息入库，并同时通过对外实时报警的接口，将报警信息迅速展示到用户界面上。
1.3.3查询分析功能与处理方案
交管数据查询构架如图：
图表6交管数据接入
当客户发起请求后，客户端把请求发向查询接口服务器，查询接口服务器解析查询请求，后向Master任务调度机发送查询任务执行命令；Master回应执行命令节点信息，查询服务器根据节点信息将查询命令发向查询计算模块，进行具体查询操作，将查询结果返回给客户端，呈现给用户。
1.4系统互联与管理
1.4.1组网方案
组网方案如图：
图表7组网方案
我司可向公安数据中心申请VPN或公网IP服务，如果系统出故障，可以保障第一时间远程排查。
1.4.2网络管理
1.4.2.1服务器间网络安全检查
系统自管理通过启用网络安全检查进程（netinspect）,定期检查整个系统的网络状况，并上报各服务模块网络流量信息，在终端形成网络拓扑图，实时在界面呈现各节点网络状态，管理员也能及时了解，各服务模块的网络流量机承载的负荷。
若出现网络故障，netinspect进程实时上报故障情况，在网络拓扑图上以报警方式提示，或以短信的方式提示，便于管理员及时发现问题，并恢复网络故障，确保系统在安全的网络环境下运行。
1.4.2.2服务模块进程监控管理
系统自管理通过启用服务模块运行状态检查进程（proinspect）,定期检查整个系统的服务模块进程运行状况，并上报各服务模块进程的运行状态信息，在终端将运行的进程的状态以表格形式显示，定时更新进程的运行状态信息。
通过它管理员也能及时了解，各服务模块的进程运行负荷。
若在固定的时间内没有更新，视为进程运行故障，启动主机代理自动恢复故障进程，保障各服务模块进程持续稳定的运行的状态。
1.4.2.3系统性能监控管理
系统自管理通过启用服务模块性能检查进程（serverinspect）,定期检查整个系统的各服务器性能指标，包括CPU开销、内存占用、IO峰值、网络流量、连接数等。
并上报各服务性能指标，在终端形成拓扑图，实时在界面呈现各节点服务器性能状态，管理员也能及时了解，各服务节点处理性能及资源开销。
若性能持续高负荷，拓扑图上以报警方式提示，或以短信的方式提示，便于管理员及时发现问题，查找问题的来源或重新评估服务器配置情况，为系统稳定运行提供一个确实可靠的标准。
1.4.2.4系统日志分析处理
系统各服务模块在运行期间写日志文件，将进程的模块编号、服务器的IP、出错页码等日志的状态（错误、告警、提示）等级别的信息保存磁盘文件，供工程师来分析系统运行状态。
同时日志分析进程（loganalyse）分析日志文件，将重要的日志信息，进行对比、分析并汇总后，生产统一格式的日志信息，提取出来，写入的数据库表中，终端管理通过查询界面来来显示，能及时了解到系统的运行的状态。
1.4.2.5系统运行状态及报警处理
系统运行报警分为以下几种：
服务器运行状态报警
服务器网络状态报警
服务模块进程报警
日志模块状态报警
1.4.3系统安全
1.4.3.1网络安全
为保障整个系统稳定运行，首先要保障系统在网络方面是安全的。
从硬件、软件方面做相应的安全措施。
硬件：
所有的网络设备都要1+1冗余配置，涉及以下网络硬件设备冗余配置
以太网100M/1000M网卡
以太网网络交换设备
光纤网络接口FC/HBA
SAN光纤网络交换机
软件：
在整个系统上部署防火墙软件、及自产的安全管理管理软件模块来保障系统平稳运行。
1.4.3.2数据文件安全性
见集群可靠性章节。
1.5系统可靠性与扩展性
1.5.1系统可靠性
HDFS可靠性概述：
HDFS包括元数据节点（Namenode）和数据节点（Datanode），Namenode是一个中心服务器，负责管理文件系统的Namespace和客户端对文件的访问。
，Datanode在集群中一般是一个节点一个，Datanode是文件系统中真正存储数据的地方。
DataNode所在机器挂了怎么办？
HDFS（HadoopDistributedFileSystem）默认的最基本的存储单位是64M的数据块（block）。
一个文件对应的所有BLOCK全部按照一定的部署策略存在于DataNode上，文件的所有block为了容错都会被复制（一般为3份），每个文件的block大小和replication因子都是可配置的。
Datanode每3分钟向Namenode发送心跳，如果10分钟datanode没有向Namenode发送心跳，则Namenode认为该Datanode已经dead，Namenode将取出该Datanode上对应的block，对其进行复制。
Namenode挂了怎么办？
Namenode主控服务器，为了避免主节点失效而影响整个系统正常工作，我们采用基于HDFS的改进方案Avatar，同时可开启两个Namenode，主Namenode和secondNamenode，实际工作的只有主Namenode。
主Namenode将所有关于文件和目录的操作记录都会写入日志，并定时序列化到本地做镜像，并且保存到本地的NFS服务器，同时secondNamenode读取主Namenode所在NFS服务器的日志并对镜像日志做CheckPoint。
故障后，secondNamenode升级为Namenode，通过镜像数据和文件日志迅速恢复系统。
数据服务器可通过分布式协同服务机制得知关于主控服务器的更迭情况，然后向新的主控注册并继续发送心跳。
HBase可靠性概述：
HBase系统由HBase集群和ZooKeeper集群组成。
HBase的可靠性由其自身的ZooKeeper机制保证。
HBase包括Hregion服务器群和Master主服务器构成。
Master负责管理Hregion。
物理上，一张表是被拆成多个块，一张完整的表格是保存在多个Hregion上面的。
master挂掉怎么办？
由于master只维护表和region的元数据，因此master下线短时间内对整个hbase集群没有影响，master保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来），因此，启动HBase时可以再启动一个备用的master，实际工作的只有主master，当主master所在节点宕机，会自动切换到备用master所在节点。
Hregionserver挂掉怎么办？
物理上，表格分为多个Region一张表是被拆成多个块，一张完整的表格是保存在多个Hregionserver上面的。
并且分布在多台Hregionserver中，物理上所有数据存储在Hadoop的HDFS上，由一些子表服务器来提供数据服务，提供服务时，子表先查HMemcache，如果没有，再查HDFS上的HStore，由HDFS来保证数据的可靠性。
如果丢失Region的数据所在节点的datanode宕机，HDFS会自动映射到其他节点，从而保证Region数据的可靠性。
ZooKeeper挂掉怎么办？
Zookeeper分为2个部分：
服务器端和客户端。
启动Zookeeper服务器集群环境后，多个Zookeeper服务器在工作前会选举出一个Leader，在接下来的工作中这个被选举出来的Leader死了，而剩下的Zookeeper服务器会知道这个Leader死掉了，在活着的Zookeeper集群中会继续选出一个Leader，选举出leader的目的是为了可以在分布式的环境中保证数据的一致性。
MapReduce可靠性概述：
MapReduce整体上可以分为这么几条执行的线索，JobTracker与JobTracker是一个master服务，软件启动之后JobTracker接收job，负责调度job的每一个子任务task运行于TaskTracker上，并监控它们，如果发现有失败的task就重新运行它。
一般情况应该把JobTracker部署在单独的机器上。
TaskTracker是运行于多个节点上的slaver服务。
TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务。
TaskTracker都需要运行在HDFS的DataNode上，
JobTracker0挂掉怎么办？
在系统启动时同时启动备份JobTracker1节点，当JobTracker0节点宕机时，ZooKeeper会在其上启动JobTracker进程替代JobTracker0节点，虚拟IP会指向此节点，TaskTracker会注册到此节点上，未完成的MapReduce作业会被ZooKeeper调度到此节点上重新执行。
TaskTracker挂掉怎么办？
JobTracker是一个master服务，软件启动之后JobTracker接收job，负责调度job的每一个子任务task运行于TaskTracker上，并监控它们，如果发现有失败的task就重新运行它。
并且将其负责的task分配给其他TaskTracker上。
1.5.2系统扩展性
已有的Hadoop集群规模
Hadoop是一个相当有弹性和扩展性的平台，它既可以在成千上万的机器上跑，也可以在很小规模上运行。
目前最大的Hadoop集群有四千台机器。
Hadoop扩展优势：
与其它分布式系统相比，使用Hadoop的好处在于它的水平的可扩展性，在少量结点上，用Hadoop处理有限的数据时，不能展示Hadoop的性能，因为开始Hadoop程序相关的代价比较高，其它并行/分布程序方式，比如MPI（MessagePassingInterface）可能在2台，4台或许10多台计算机上有更好的性能，尽管在少量机器上协同工作在这种系统上也许会取得更好的性能，但这种为性能所要付出的努力是非线性的增长。
用其它分布式框架所写的程序在从十台机器的级别到成百上千台机器需要大量的重构工作，这也许要程序重写几次，并且其它框的基础元素会限制应用的规模大小。
但是特别设计的Hadoop有着水平的可扩展性，一个Hadoop程序写完后，在10个结点上运行，如果迁徙到更大的集群上运行，几乎不需要做什么工作，Hadoop平台会管理数据和硬件资源并提供与可用资源成比例的可靠性能。
Hadoo
升级会员 