环保项目解决方案书.pdf
《环保项目解决方案书.pdf》由会员分享,可在线阅读,更多相关《环保项目解决方案书.pdf(87页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、环保环保数据汇聚处理项目数据汇聚处理项目解决方案书解决方案书目录目目录录1系统总体设计.11.1云计算系统设计方案概述.11.1.1系统基本需求及功能.11.1.2主要建设目标和建设原则.21.1.3系统的主要技术特点.21.1.4系统的主要性能指标.31.2系统总体构架.51.2.1系统基本组成与构架.51.2.2系统功能构架.51.2.3系统总体构架与功能模块.101.3系统基本功能与处理方案.111.3.1交管数据入库功能与处理方案.111.3.2数据存储功能与处理方案.131.3.3查询分析功能与处理方案.141.4系统可靠性与扩展性.151.4.1系统可靠性.151.4.2系统扩展性
2、.171.5系统设计性能.181.5.1交管数据流量处理能力.181.5.2数据存储能力.181.5.3查询分析计算性能.191.6定制开发方案.192硬件云平台建设方案.222.1交换机详细指标.222.2云存储集成套件详细指标.222.3云计算/存储主控制服务器节点详细指标.232.4云计算/存储从服务器节点详细指标.232.5数据采集服务器详细指标.242.6应用服务器详细指标.242.7数据库服务器详细指标.252.8管理控制台服务器详细指标.253软件系统设计与关键技术方法.273.1系统软件平台.27目录3.2历史数据汇聚上报处理流程.273.3实时数据入库流程.283.4数据存储
3、子系统.293.4.1海量数据分布式数据存储构架.293.4.2适应应用需求的混合存储策略.313.4.3HDFS 数据存储.313.4.4HBase 数据存储.343.4.5Database 数据存储.363.4.6数据存储的可靠性.383.4.7数据压缩.393.5数据查询与统计分析子系统.413.5.1数据查询与统计分析系统基本构架.413.5.2交管数据查询功能与用户界面.413.5.3实时报警功能与用户界面.423.5.4车辆轨迹回放功能与用户界面.433.6基于云方案的交管数据查询索引与查询优化技术.433.6.1基于分布式数据库的交管数据查询索引处理方案.433.7交管数据处理集
4、群的可靠性与负载均衡设计.443.7.1负载均衡处理机的单点失效容错处理.443.7.2查询处理机的单点失效容错处理.483.8计算与存储集群的可靠性与负载均衡设计.493.8.1计算与存储集群 Master 单点失效容错处理.493.8.2计算与存储集群的负载均衡处理.553.8.3HDFS 的可靠性设计.583.8.4HBase 可靠性设计.603.8.5MapReduce 计算可靠性设计.613.9查询统计计算可靠性与负载均衡设计.643.9.1基于 Zookeeper 的单点失效和负载均衡设计.643.10系统安全性设计.663.10.1安全保障体系框架.663.10.2云计算平台的多
5、级信任保护.683.10.3基于多级信任保护的访问控制.723.10.4云平台安全审计.743.10.5云计算综合安全网关.774实施方案.81目录4.1时间进度.814.2测试和验收.814.3技术支持服务.814.4培训服务.82图表 1“3.20”道路图像监控数据汇聚处理云平台的基本组成与构架.5图表 2“3.20”道路图像监控数据汇聚处理云平台总体构架与功能模块图.10图表 3“3.20”道路图像监控数据汇聚处理云平台架构.12图表 4 数据存储处理架构.13图表 5 交管数据接入.14图表 6 分布式文件存储系统吞吐量指标.19图表 7 系统软件结构.27图表 8 数据汇聚上报处理流
6、程.28图表 9 实时数据入库流程.28图表 10 分布式计算流程.29图表 11 Hadoop 结构.30图表 12 HDFS 结构.33图表 13 HDFS Namenode、DataNode 和客户端们之间的交互.34图表 14 HDFS 数据压缩与组织.40图表 15 数据查询子系统构架.41图表 16 用户界面图.42图表 17 实时报警功能.42图表 18 车辆轨迹回放.43图表 19 负载均衡机分布图.45图表 20 负载均衡机宕机预案.46图表 21 Master 节点宕机预案.47图表 22 查询处理单点失效容错处理.48图表 23 Master 单点失效容错处理.49图表
7、24 AvatarNode0 以 Pimary 启动过程.51图表 25 AvatarNode1 以 Standby 启动过程.52图表 26 DataNode 启动过程.52图表 27 AvatarNode0 宕机后的状态.53图表 28 AvatarNode1 切换为 Primary 过程.53图表 29 AvatarNode0 重启过程.54图表 30 AvatarNode 启动切换流程图.55图表 31 Avatar 体系架构图.58图表 32 HBase 系统架构.60图表 33 作业提交.63图表 34 JobTracker0 宕机.63图表 35 作业注销.64图表 36 Zoo
8、keeper 基本工作结构图.64图表 37 基于 Zookeeper 的查询分析计算单点失效和.66图表 38 基于深度防护战略的 IATF 模型.66目录图表 39 云部署模型的实现.67图表 40 多级信任保护.68图表 41 基于可信第三方的平台认证.69图表 42 主要因素平台证书.69图表 43 云存储安全子系统接口关系图.72图表 44 基于多级信任保护的多级访问控制流程.73图表 45 数据安全交换平台.73图表 46 云存储安全审计体系结构.75图表 47 安全日志审计系统结构图.76图表 48 Cloud-USG 三种部署模式.79系统总体设计云计算解决方案书 第 1页1
9、系统总体设计系统总体设计1.1 云计算系统设计方案概述云计算系统设计方案概述1.1.1系统基本需求及功能系统基本需求及功能按照全省机关“320”工程建设的要求,需要对全市 500 多个车辆监控点实时抓拍的车辆轨迹数据进行及时汇聚、管理和分析服务。目前,全市已经建成江宁、浦口、六合、高淳、溧水及市政府信息中心等六个数据分中心数据库。经初步测算,仅集中存储全市“320”文字数据、图片的位置索引,以及车牌小图片片段数据(图像数据在需要时可以按照索引自动到相应的分中心图片系统进行分布调用),按照数据存储 3 年要求,总记录数近 200 亿条,原始数据总存储容量约 120TB,高峰时段每秒产生的数据将超
10、过 1 万条记录(每条记录 5K 数据量,包括文字数据、图片索引和号牌特征图片)。加上要为原始数据记录创建查询索引以及保存从原始数据统计分析出的中间结果数据,需提供总量为 150TB的原始数据存储量。如此庞大的数据量使得现有的关系式数据库已经难以提供相应的数据存储管理和处理能力。为此,需要考虑基于云平台的分布式海量数据存储和处理解决方案。本项目的基本建设要求是本项目的基本建设要求是:在市局集中建设一套适应海量数据处理的高性能道路图像监控数据存储和计算平台,该平台将从现有的六个数据分中心获取和汇聚道路监控数据,以便提供集中式的道路监控数据管理功能,为开展各种车辆监控数据应用提供海量数据存储管理和
11、计算服务能力。系统的基本功能和性能如下:海量历史交通监控数据汇总海量历史交通监控数据汇总能够对百亿级的海量历史交通监控数据进行汇总处理。海量原始交通监控数据上报海量原始交通监控数据上报能够对百亿级的海量上报交通监控数据进行上报处理。海量原始数据实时入库、生成索引海量原始数据实时入库、生成索引能够对流量超过 10000 条/m 的全量原始交通监控数据流进行实时处理。系统总体设计云计算解决方案书 第 2页海量数据存储、计算海量数据存储、计算能够存储百亿级别的数据,并完成各种复杂业务应用计算。百亿级数据秒级查询能力百亿级数据秒级查询能力高效索引算法,智能化调度任务系统,满足秒级查询速度。秒级实时业务
12、响应秒级实时业务响应高效实时数据通道,对于像实时监控、告警等实时业务,提供秒级响应时间。1.1.2主要建设目标和建设原则主要建设目标和建设原则建设目标建设目标:利用大量普通的性价比高的商用服务器,构建一个高性能的云计算平台,对峰值流量超过 10000 条/秒、3 年高达 150TB 的总数据量进行存储处理,以便为实时监控、报警监控、车辆轨迹回放、电子地图、报警管理、布控管理、设备管理、事件检测报警、流量统计和分析等多种应用业务提供海量数据存储管理支撑和计算服务能力。建设原则:建设原则:(1)前瞻性技术与实际应用环境相结合在技术方案上,本系统必须充分利用目前先进的云计算和海量数据处理相关技术,保
13、证系统技术的前瞻性和先进性。(2)高可靠性、高扩展性、高可获得性、实时性和高性价比的云平台与此同时,通过利用业界成熟的云计算和海量数据并行计算平台和技术,提供切实可行的海量数据存储处理解决方案,并保证所设计实现的系统具有高可靠性、高扩展性和高可获得性;同时,通过云平台的海量数据并行处理,保证数据查询响应的实时性;此外,系统将利用比传统方案更为低廉的价格,提供更高的处理能力,达到较之传统方案至少一个数量级的性价比提升。(3)遵循 320 工程相关标准规范在项目设计和工程实施上,本项目所有的数据格式、接口等要遵循 320 工程相关标准规范。1.1.3系统的主要技术特点系统的主要技术特点实时性实时性
14、:系统在分布式海量数据存储和并行处理能力的支撑下,需要实时完系统总体设计云计算解决方案书 第 3页成交管数据获取、入库、以及数据汇总、上报、查询、分析计算和管理等工作,保证海量数据的获取和入库不会出现数据堆积现象,各类基本的数据查询操作基本都在秒级完成,大规模或复杂的分析计算在分钟级完成,实现传统数据库所难以达到的处理能力和处理效率。高可靠性高可靠性:系统应采用目前业界成熟可靠的海量数据处理平台和技术,需要考虑数据存储和计算时的系统可靠性,避免系统主节点的单点失效,并具有存储和计算节点失效检测和恢复的容错处理能力,保证不出现系统瘫痪和数据出错现象。高可扩展性高可扩展性:系统构架和方案必须具有高
15、可扩展性,保证在将来应用系统规模扩大时能根据需要随时增加节点以扩大系统的数据存储能力和计算能力;并能在不停机的情况下增加节点,以保证应用服务的连续性。高可获得性高可获得性:项目使用市场上标准的普通商用服务器,采用标准的网络构建云计算平台,云计算平台通用性强,且任何节点损坏都易于更换和维护;云计算系统软件尽可能采用业界广为使用的开源系统,既节省软件费用,也易于获得。高性价比高性价比:替代使用价格昂贵的高端专用存储和计算设备,采用价格不高的普通服务器,大大节省系统的构建和维护成本,同时通过云计算平台的并行化计算能力可提供比传统方案更高的计算性能,获得很高的性价比。全业务支持全业务支持:海量数据分布
16、存储,少量数据关系复杂或实时性要求很高的数据存放于关系数据库,采用这种分布式海量数据存储为主、关系数据库为辅的混合式数据存储模式,可存储各种不同规模和不同媒体和类型的数据,满足各种不同的数据处理和应用业务需求。1.1.4系统的主要性能指标系统的主要性能指标数据存储和处理指标数据存储和处理指标系统总体设计云计算解决方案书 第 4页3 年的原始道路监控数据量为 120TB,加上要为原始数据记录创建查询索引以及保存从原始数据统计分析出的中间结果数据,需提供总量为 150TB 的数据存储量;为了保证数据存储的可靠性防止数据丢失,系统要求采用 3 倍副本方式保存数据,因此,云平台需要提供 150 x 3
17、=450TB 的总存储量。同时,系统必须能实时接收和处理峰值流量高达 1 万条/秒的实时入库数据,包括实时接收保存和创建索引处理。硬件系统指标硬件系统指标为了保证计算集群的存储和计算性能,每个服务器节点配置为不低于 2 颗Intel 至强 5645 六核处理器,内存 24G,62T(RAID0)SAS 热插拔硬盘;而集群计算和存储主控节点配置为不低于2颗Intel至强5660六核处理器,内存32G,52T(RAID1)SAS 热插拔硬盘;关系数据库服务器配置为不低于 2 颗 Intel 至强 5660 六核处理器,内存 24G,32T(RAID1)SAS 热插拔硬盘;应用分析服务器和数据采集服
18、务器配置均为不低于2颗Intel至强5645六核处理器,内存16G,应用服务器采用 600GB15000 转 SAS 热插拔硬盘,数据采集服务器采用2T(RAID1)SAS 热插拔硬盘。详细指标要求参见本文建设内容部分描述。计算响应时间计算响应时间实时入库时延实时入库时延:道路监控数据从分中心获取后入库处理(包括创建查询索引)时的时间延迟小于 5 秒,并保证不会出现数据堆积现象。查询响应查询响应:查询响应依赖于上层应用的具体查询分析的复杂程度、查询时所涉及到的时间跨度和具体数据量、及上层应用查询具体的设计实现方法。由于本项目并不包括上层应用的开发,因此,本项目中难以确定和评估上层应用的查询响应
19、时间。但为了保证本项目所设计实现的系统能满足实时查询响应能力、并制定项目验收时的有效评估标准,本项目要求对最常用的指定车辆牌号在不同时间段的查询能达到实时响应。具体要求是,平均计算,对单个车辆牌号 1 个月内的轨迹查询返回和结果读出在 1 秒内完成,6 个月内的轨迹查询返回和结果读出在5 秒内完成,6-12 个月内的轨迹查询返回和结果读出在 10 秒内完成(其中全部查询结束至第一个结果读出应在 3 秒内完成),而 1-3 年的轨迹查询和结果返回系统总体设计云计算解决方案书 第 5页应在 30 秒内完成(其中全部查询结束至第一个结果读出应在 10 秒内完成)。1.2 系统总体构架系统总体构架1.
20、2.1系统基本组成与构架系统基本组成与构架“3.20”道路图像监控数据汇聚处理项目是一个处于交管数据采集与交管数据监测应用之间的系统。从系统基本组成与构架上来看,该共享平台由 7 个主要部分组成:历史数据汇聚系统、实时数据入库系统、数据存储管理系统、数据上报处理系统,数据应用接口、数据查询导出系统以及系统管理。在基础设施构架上,在市局集中建设一套适应海量数据处理的高性能道路图像监控数据存储和计算平台,作为“3.20”道路图像监控数据汇聚处理项目的基础设施和支撑平台。图表 1“3.20”道路图像监控数据汇聚处理云平台的基本组成与构架1.2.2系统功能构架系统功能构架“3.20”道路图像监控数据汇
21、聚处理云平台需要提供的 7 大数据处理和服务功能描述如下。(1 1)历史)历史数据数据汇聚汇聚系统总体设计云计算解决方案书 第 6页历史数据汇总处理主要负责把 6 个分散的数据中心的历史数据,进行读取解析处理,并将处理后的历史数据汇入一个统一的数据中心。在内部处理模块上,历史数据汇总系统主要包括三个模块:读取模块、解析模块和汇总模块。读取模块主要负责各个数据中心历史数据的读取处理,解析模块主要负责把读取到的历史数据解析成合理的数据格式,而汇总模块主要负责把解析好的历史数据上传到统一的数据中心。在系统构架上,为了满足 6 个分散的数据中心处理需要,需要在每一个数据中心处安装一个数据汇总程序。接口
22、调用说明接口调用说明:鉴于历史数据是存储在 Oracle 关系数据库中,在这里数据汇总程序的读取模块将通过结构化数据存储访问接口(如 JDBC)访问和读取其中的历史数据。汇总模块则会利用“3.20”道路图像监控数据汇聚处理云平台的云存储系统提供的数据添加接口把解析好的历史数据添加到云存储系统中。(这里的数据添加接口以 jar 包的方式集成到数据汇总程序中。调用十分方便、简洁,调用方法类似于一般的应用程序利用 JDBC 向传统的关系数据库中添加数据。)接口安全性说明:接口安全性说明:数据添加接口把从 Oracle 数据库中读取到的历史数据,利用网络,传输给云存储系统,由云存储系统完成历史数据的入
23、库操作。当整个流程都准确无误的完成后,云存储系统会返还一个“成功”标记给数据汇总系统。当数据汇总系统明确的得到了“成功”标记后,记录下这条已经完成汇总操作的数据,然后进行下一条历史数据的汇总操作。否则会判断本次汇总操作失败,并进行失败处理(如:判定本次汇总操作失败的原因、记录到日志中、进行再次汇总操作等)。这样可以最大限度上,保证在各种异常情况下(如:网络阻塞)数据汇总的安全性。是否有必要使用消息中间件(如是否有必要使用消息中间件(如 IBMIBM MQMQ):MQMQ 负责在两个系统之间传递消息负责在两个系统之间传递消息:这两个系统可以是异构的,处于不同硬件、不同操作系统、用不同语言编写,只
24、需要简单的调用几个 MQ 的 API,就可以互相通讯,你不必考虑底层系统和网络的复杂性。而“3.20”道路图像监控数据汇聚处理云平台的数据汇总系统和云存储系统并不是一般的两个相互孤立的系统,它们之间的关系很类似于应用程序对于传统系统总体设计云计算解决方案书 第 7页数据库的关系。消息中间件在这么并没有相应的应用场景。但但 MQMQ 的功能仅限于消息队列的功能仅限于消息队列:至于应用 A 发给应用 B 的消息格式是怎样的、能不能被应用 B 解析,MQ 管不了,他只是尽力将消息发到目的地(MQ 能够应付多种异常情况,例如网络阻塞、临时中断等等)。“3.20”道路图像监控数据汇聚处理云平台的数据汇总
25、系统已经能够对多种异常情况进行处理。故从分析来看,数据汇总系统和云存储系统之间不需要再加入一个中间件来保证数据传输的安全性。(2 2)实时实时数据入库数据入库实时数据入库主要负责从分中心所采集的全市每个卡口产生的实时数据同步地传送给本系统进行实时入库处理(需要通过网闸等安全隔离交换设备)。在内部处理模块上,实时数据入库系统主要包括三个模块:接受模块、解析模块和数据入库模块。接受模块主要负责接收每个卡口产生的数据流,解析模块主要负责把接受到的数据流解析成合理的数据格式,而数据入库模块负责把解析好的数据加入到市数据中心。在系统架构上,为了使每个卡口的数据能实时入库市数据中心,需要在每一个负责接受卡
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 环保 项目 解决方案
限制150内