智慧城市大数据建设方案.docx

智慧城市大数据建设方案.docx

《智慧城市大数据建设方案.docx》由会员分享，可在线阅读，更多相关《智慧城市大数据建设方案.docx（13页珍藏版）》请在冰豆网上搜索。

智慧城市大数据建设方案

智慧城市大数据建设方案

1项目概述

1.1建设背景

在信息化时代背景下，数据资源的多寡、数据质量的高低直接决定着各类社会主体的运作效率，数据分析应用能力也影响着管理者决策的方向，对数据的全面搜集和有效挖掘利用已经成为当今世界各国信息化建设的重要内容。

自2016年以来，在《智慧城市顶层设计总规》的指导下，开展了业务、资源、系统、基础设施等方面的顶层设计，提出要加强数据中心建设工作，搭建数据中心辅助决策平台，进一步提升数据整合、共享和分析决策能力，并通过数据架构体系的理论研究和网格化社会服务信息化系统的建设，积累了大量人、地、物、组织、房屋、地下空间的基础资源数据和协同业务数据，为数据分析决策、数据共享应用奠定了数据基础。

鉴于以上背景，提出了构建数据中心的整体规划，整合郑州市现有数据库和系统资源，建设统一规范的人、组织、地、物等基础信息库；建设各政府部门之间准确、完整、规范、清晰、权则结合的基础数据信息共享交换平台，实现基础数据信息高度共享和综合应用；通过基础数据和业务数据的整合集中、统一管理，为科学决策提供强大的数据支持；建立和健全数据标准规范体系和数据安全体系，建立一个统一规范、集中部署、安全规范、充分共享的基础信息数据中心。

其中数据中心平台是整体规划的重要核心系统，通过本项目建设，为政务部门和社会公众提供数据共享服务，保障政府决策的科学性、有效性和规范性，提升政府管理能力和公共服务水平。

1.2建设目标

以现有业务系统资源为基础，梳理制定数据资源标范，构建人口、地点、物件、组织和经济五大资源库，实现基础信息的集中、统一与规范管理，实现资源元数据及资源目录管理，提供数据对外共享服务，为政府统计分析及决策支持提供数据支撑，为政务部门和社会公众提供基准数据服务，保障政府决策的科学性、有效性和规范性，提升政府管理能力和公共服务水平。

2需求分析

自2012年以来，经过网格化社会服务信息化工作，目前在数据资源方面已经建成了相互关联的人、地、物、组织、房屋、地下空间基础数据库的建设，整合了120多万条基础数据，其中常驻人口953,998条、流动人口220,444条,境外散居人口8,108条、地21,881条，物信息3,925条、组织信息31,469条。

并且，实现了人-户信息的100%关联、人-房信息的80%关联。

总体上看，初步建立起了支撑网格化社会服务管理的基础信息资源体系，同时还完成了网格化社会服务管理基础数据的动态更新系统建设，为基础数据更新的日常化、业务化奠定了夯实基础。

在业务掌控方面，每天动态更新的4000多条民情日志和社会事件信息。

鉴于以上基础，已经具备了建设统一规范的人、组织、地、物等基础信息库。

通过建设数据中心平台，将实现基础信息的集中、统一与规范管理。

本项目以人口、地点、物件、组织和经济数据资源为核心，结合现有数据资源梳理元数据及数据资源规范，建设统一的数据资源库，提供数据资源管理和对外数据共享服务的两方面技术支撑。

3总体方案概述

3.1总体设计

3.1.1总体架构

本项目应按数据中心建设的总体要求，以构建权威、完整、准确的数据资源库为核心，以数据标准规范、数据管理和共享服务为重点，充分挖掘数据的应用价值和服务效能，进行整体优化设计和资源库建设。

从资源的管理生命周期及数据加工过程视角来看，项目的总体架构分数据提供层、数据整合层、数据资源层、数据应用层和应用访问层。

数据提供层：

现有系统已积累的数据资源，如网格系统数据库。

数据整合层：

对分散在各个系统的数据源进行提取、清洗、整合，完成数据的汇总、校核和质量检查，存在问题的数据向数据源反馈。

数据资源层：

存放整合后数据资源，作为对外提供服务的核心生产库。

资源应用层：

提供数据管理和数据共享服务应用，可以对资源元数据、资源目录进行管理，对外提供数据接口服务。

应用门户层：

提供web应用平台和在线服务接口，提供系统数据的访问。

3.1.2技术架构

本项目是一个以数据管理和数据服务为核心的，技术要求高的大型应用系统，系统的设计既要切实保证整个系统的安全性，同时也要确保系统的开放性、可扩展性、先进性和跨平台性，以满足用户对复杂业务逻辑可定制和可管理的个性化开发需求。

根据架构设计的总体技术路线，本方案将采用基于分布式组件技术的多层应用体系结构、模块化的设计方法的技术架构。

系统技术架构遵循J2EE标准，以成熟的技术平台解决方案为基础进行开发，客户端基于RIA富客户端开发，应用服务共分为Action、IABO、ALBO、DAO四层，其中Actio层为统一代理。

3.1.3数据架构

数据架构设计将达到如下两个目标：

1、为将来的数据设计提供确实可行的依据。

2、从总体上进行分析，避免数据设计中出现的盲目行为。

在进行本系统的设计时，遵循以下基本原则：

●高性能：

数据中心数据库的特点是计算量大，因此在设计中必须保证满足系统的业务需求，做到高性能，因此在硬件和软件选型方面需进行多方面的考虑。

集中运算、集中存储、统一备份：

保证系统的安全性。

●优化系统结构：

按照任务的特点对硬件资源进行选择和系统的架构。

●系统的可靠性和安全性：

系统必须是具有大很强的可靠性，并且充分考虑到安全防范措施。

●系统的可管理性：

系统必须是可管理的，而且管理粒度必须达到一定程度，以减少维护工作量。

●系统的可扩展性：

保护用户的投资，保证系统的可扩展能力。

3.1.4部署方案

系统运行环境，考虑配置采用集群模式。

其拓扑图如下：

3.2安全设计

本系统将按照信息系统安全等级保护3级要求进行建设，定级模式的组合（A3S3G3），要求按照《信息系统安全等级保护基本要求》及《信息系统等级保护安全设计技术要求》等相关国家标准，进行项目建设。

3.2.1数据库安全保障

数据库安全和日志服务是两个相互关联的过程。

数据库中数据的保护一方面通过应用程程序的完整全面来避免系统维护人员和业务科室人员不直接操作数据库中的表，另一方面就是现在基于C/S/S和B/S/S系统架构下，把数据库的直接操作封闭在应用层，来加强保护，还有一个是就通过日志来保护，通过日志一方面保证操作的可追踪性，另一方面保证操作的可逆性。

在此说明系统上如何通过日志服务进行数据保护的。

对需要日志跟踪的表设定为日志，在独立表空间和用户下自动建立该表的对应的日志表，保护对该表的所有插入、修改、删除历史住处，基本信息和原表相同，但加入：

USERID——操作员编号pkg_a_comm。

Fun_A_GetUserID（）;

TRANSNO——交易发起流水号pkg_a_comm。

Fun_A_GetTransID（）

交易发起时，对此操作员产生一个流水号，保证在这次交易过程中所有修改的表都使用同一个流水号，便于完整的按操作事务方式的恢复；

BTRANSNO——冲正交易流水号（如下图的更新方式）

OPTDATE——修改日期

OPTTYPE——修改类型

通过日志引擎把所有的对该表的操作前结果保存在日志表中，因为整个日志跟踪是基于数据库操作的，所以无论是系统管理员直接的数据库操作还是操作员通过应用程序操作的数据库，都能完整的保存操作痕迹和回退方法。

3.2.2应用系统安全设计

3.2.2.1应用系统安全设计策略

展现平台采用安全的WEB应用的B/S/S三层结构，取消了客户机直接访问数据库服务器的可能。

为最大程度地保证系统安全，结合三层结构的特点及本系统的实际需求，设计了"三横三纵"的网状安全方案。

"三横"是指用户表示层验证、业务逻辑层验证、数据服务层验证；"三纵"是指安全传输、安全审计、限时限地安全访问。

1、用户表示层验证

用户表示层验证主要包括两方面内容：

第一、用户身份认证；第二、数据合法性验证。

用户身份认证主要是解决"用户能否接入系统？

用户能看到什么？

用户能操作什么？

"；数据合法性验证主要是解决“如何保证用户提交的数据都是合法的？

”。

下面分别加以描述：

●用户身份认证

（1）用户身份认证是应用安全的关键，因为多级业务管理模式下用户属于哪级的哪个经办机构或管理机构决定了其所能操作的功能的范围及业务数据的范围，同时用户身份是功能授权的基础。

（2）预留利用基于证书的用户身份认证进一步保障系统的安全。

（3）采用多级功能权限管理，上级机构为下级机构授权，每级机构可以将自身拥有的权限授予本级用户或下级机构。

（4）功能权限分为功能授予的权限与功能使用的权限，功能授予权限表示拥有者可以将该功能授予他人，功能使用权限表示拥有者可以使用该功能。

用户只能看到自己所在角色组所拥有的菜单。

（5）对不同业务、不同操作设置不同的安全级别和操作权限，并配合制定相应的使用管理制度。

●数据合法性验证

（1）我公司的多层框架系统采用自主版权的统一企业应用平台作为开发支撑平台，企业平台提供了所有常用界面层控件，这些控件本身具备录入校验功能。

（2）我公司在多层系统开发中遵循一个约定：

尽量将数据合法性验证在界面层完成，只有必须拿到业务逻辑层才能完成验证的数据才会到中间层再处理。

也就是说"要将非法数据扼杀在摇篮里"，从而减少系统不必要的压力，提高系统的业务办理效率。

2、业务逻辑层验证

业务逻辑层验证主要包括两方面：

第一是由系统统一处理的，对经过加密和签名的数据项进行统一的解密和签名验证处理；第二是各业务环节自行处理的业务约束边界的处理，如黑名单是否地方局已经解锁等。

●安全审计

利用数据库的审计功能记录什么人在什么时间做了什么事，对于安全级别比较高的数据在日志做要做"密印处理"，防止操作者抵赖，提高操作者的责任心。

3.2.2.2应用系统安全层次

1、身份认证

用户在前台界面必须键入其用户名以及口令来证明其是否是合法的用户，只有合法的用户才能登录到应用系统。

2、多级权限控制

系统有很多的功能模块组成，即使对合法用户，也不能操作所有的模块，而是根据用户的工作部门、工作性质授予相应的功能模块；

对同样的数据可以设置不同的操作权限：

查询权限、录入权限、审核权限、审批权限；

3、应用逐级授权机制

本系统权限设计支持逐级授权，上级可以向下一级授予上级拥有的权限，并且下一级不能看见上一级的数据，而上一级可以看见下一级的数据，这样的逐级授权机制满足业务经办要求。

4、应用系统日志

日志管理跟踪记录用户登录系统的信息，操作的业务模块以及操作的重要库表的信息，包括用户名称、操作的模块，对重要库表的操作类型（增、删、改）、字段操作前和操作后的数值等。

通过日志管理，在发生误操作时可以方便的进行回退处理，而且也可以跟踪一些业务操作员的违规操作。

3.2.2.3应用软件权限设计

应用软件权限管理包括模块级权限、数据级权限和操作级权限。

1、模块级权限

模块级权限可以通过角色实现上级权限控制，下级权限需要从上级权限获取权限。

当调整上级权限时，自动实现对下级权限的调整，换句话就是说当从上次权限中取消一个权限时，下级权限中也同样被取消相同的权限。

2、数据级权限

数据级权限通过对域的控制来实现。

这里讲的“域”实际上是数据域的概念。

首先通过对数据域的定义将数据按照域的不同划分成不同的范围，当某操作员被分配属于该域时，该操作人员就获得了该数据域的数据操作权限，该操作员不能对其他数据域中的数据进