一种用于智慧城市建设的大数据平台

技术领域

本发明涉及数据管理领域，特别涉及一种用于智慧城市建设的大数据平台。

背景技术

在多个政府部门之间，产生了大量的数据，包括公安的人口、企业、车辆数据，人社的 社保、劳动等数据，卫计的卫生、计生数据，审批及工作中产生的大量文档数据，以及执法 所产生的海量的视频数据，构成了海量的、对城市的方方面面具有重要影响的数据。这些数 据往往存储在各个部门的自建系统中，在数据共享中会存在技术对接难，数据泄密等问题。

未来智慧城市的建设潜在要求：以完善的机制体制和全面的安全体系为保障，以弹性动 态的基础设施平台为基础，以信息资源数据的共享、交换、融合、服务为核心，以多部门的 业务流程协同为手段，打造可持续运营的、实用的、能够真正服务于社会管理、城市管理和 社会经济管理的信息化体系，并将信息化与体制机制深度融合和互相促进。

因此有必要提供一种大数据平台来匹配未来智慧城市建设的需求。

发明内容

本发明的目的在于克服现有技术的缺点与不足，提供一种用于智慧城市建设的大数据平 台。

本发明的目的通过以下的技术方案实现：

一种用于智慧城市建设的大数据平台，包括大数据基础平台、数据交换平台、数据管理 平台、运行支撑平台和数据门户；其中，

大数据基础平台包括运维管理组件、分布式数据库、分布式数据仓库、分布式计算模块、 流数据处理及消息框架、数据采集管理组件、数据运维管理组件；所述运维管理组件提供大 数据平台组件部署及动态扩容；所述分布式数据库采用分布式数据库Hbase，同时利用HBase 中的主从复制和循环复制，使得平台达到一种高可用的状态；所述分布式数据仓库采用分布 式数据仓库Hive；所述分布式计算模块利用分布式计算框架，为上层应用提供大数据分布式 计算支撑及算法库支撑，提供数据存储访问及分布式计算任务的调度、运行支撑环境能力； 所述流数据处理及消息框架采用小批量流式处理方式，每隔设定间隔处理当前批次数据；支 持复杂SQL应用和在线流式机器学习；所述数据采集管理组件对数据源的提供者、业务来源、 连接信息、连接状态进行管理，实现对数据来源的跟踪，并对数据库进行数据采集；所述数 据运维管理组件提供对大数据平台数据的统一监控和运维管理；

数据交换平台包括数据桥接子系统、数据传输子系统、前置交换子系统和交换管理监控 子系统；数据桥接子系统用于完成委办局业务系统信息库与前置信息库或交换平台之间双向 安全、可靠的信息交换，并实现数据格式转换；数据传输子系统即消息总线系统，作为前置 交换子系统之间的信息交换通道，用于实现交换信息的打包、转换、传递、路由、解包日志 服务；前置交换子系统作为各委办局与数据交换平台进行数据交换的窗口，一方面从各业务 系统提取数据，向中心提交，另一方面从数据中心接收数据，并向业务系统传递数据；交换 管理监控子系统作为数据交换平台的中心管理模块，协同委办局交换前置机和中心交换前置 机的运行并对数据交换平台的运行情况进行管理和监控；

数据管理平台用于实现资源目录服务、数据质量管理及业务建模；所述业务建模是构建 用户接口或上层业务应用与基础数据之间的逻辑模型，业务对象和业务分析模型在此实例化， 应用服务层是生成并操作接收信息的业务规则和函数的集合，它们通过业务规则完成该任务， 并由此被封装到在物理上与应用程序程序逻辑本身相独立的组件中；

运行支撑平台用于为顶层应用开发提供共性的服务组件、用户权限管理、监控及接口服 务；

数据门户用于资源展示、在线查询及门户管理。

所述运维管理组件提供大数据平台部署工具、组件部署管理及动态增加机器节点管理工 具；同时提供组件服务监控管理，提供组件的运行状态、组件的负载情况监控及组件的启动、 停止、移除；当组件故障自动迁移，节点组件出现故障时，集群中的其它节点中的相应组件 自动接管故障组件的工作，保证组件正常服务。

所述运维管理组件包括运维管理组件Agent和运维管理组件Server；

运维管理组件Server会读取Stack和Service的配置文件；当用运维管理组件创建集群 的时候，运维管理组件Server传送Stack和Service的配置文件以及Service生命周期的控 制脚本到运维管理组件Agent；Agent拿到配置文件后，会下载安装公共源里软件包；安装完 成后，运维管理组件Server会通知Agent去启动Service；之后运维管理组件Server会定 期发送命令到Agent检查Service的状态，Agent上报给Server，并呈现在运维管理组件的 GUI上；

运维管理组件Server支持RestAPI，这样能够很容易的扩展和定制化运维管理组件；甚 至于不用登陆运维管理组件的GUI，只需要在命令行通过curl就能够控制运维管理组件，以 及控制Hadoop的cluster。

所述分布式数据库的HBase复制是一种在不同HBase部署中复制数据的方法，它能够作 为一种故障恢复的方法，并提供HBase层次的高可用性；在实际应用中，能够将数据从一个 面向页面的集群复制到一个MapReduce集群，后者能够同时处理新数据和历史数据，然后再 自动将数据传回面向页面请求的集群；

HBase复制中最基本的架构模式是“主推送”，因为每个regionserver都有自己的WAL 或HLog，所以很容易保存现在正在复制的位置；一个主集群能够将数据复制到任意数目的从 集群，每个regionserver都会参与复制自己的修改；复制是异步进行的，意味着集群可以是 地理上彼此远离的，它们之间的连接可以在某个时刻断开，在主集群上的修改不能马上在从 集群上进行同步；所有的WALEdits都会被复制以保证原子性。

来自每个regionserver的HLog是HBase复制的基础，并且只要它们需要将数据复制到 从集群，它们就必须被保存到HDFS上；每个regionserver从它需要的最老的日志开始复制， 同时在zookeeper中保存当前恢复的位置来简化错误恢复；每个从集群恢复的位置可能不同， 但它们处理的HLog队列内容是相同的；参与复制的集群的规模可以不对等，主集群会通过随 机分配尽量均衡从集群的负载。

所述分布式数据仓库Hive的元数据是存储到Mysql中，利用mysql的ha对Hive的元数 据进行高可用设计，具体如下：

安装MySQLHA集成环境的两个节点要配置无密码环境，并且两个节点互相加入了对方节 点的known-hosts文件；

Heartbeat主从节点都需要两个网卡，一个网卡需要为外网访问提供服务，另一个网卡 需要为心跳线服务，两个网卡配置IP不能在同一子网中，心跳线所使用网卡IP不要设置路 由信息；主节点上的两个不同用处的网卡名称应该分别与从节点上的两个不同用处的网卡对 应并相同。

所述分布式数据仓库Hive的数据管理按照使用层次分为元数据存储、数据存储和数据交 换：

(1)元数据存储

Hive将元数据存储在RDBMS中，有三种模式可以连接到数据库：

SingleUserMode：此模式连接到一个In-memory的数据库Derby，一般用于UnitTest；

MultiUserMode：通过网络连接到一个数据库中，这是最常用的模式；

RemoteServerMode：用于非Java客户端访问元数据库，在服务器端启动一个MetaStoreServer，客户端则利用Thrift协议通过MetaStoreServer来访问元数据库；

(2)数据存储

首先，Hive没有专门的数据存储格式，也没有为数据建立索引，用户可以非常自由地组 织Hive中的表，只需要在创建表的时候告诉Hive数据中的列分隔符和行分隔符，它就可以 解析数据了；

其次，Hive中所有的数据都存储在HDFS中，Hive中包含4种数据模型：Table、ExternalTable、Partition、Bucket；

Hive中的Table和数据库中的Table在概念上是类似的，每一个Table在Hive中都有 一个相应的目录来存储数据；

Partition对应于数据库中Partition列的密集索引，但是Hive中Partition的组织方 式与数据库中的很不相同；在Hive中，表中的一个Partition对应于表下的一个目录，所有 的Partition数据都存储在对应的目录中；

Buckets对指定列计算hash，根据hash值切分数据，是为了便于并行，每一个Buckets 对应一个文件；将user列分散至32个Bucket上，对user列的值计算hash；

ExternalTable指向已经在HDFS中存在的数据，能够创建Partition，它和Table在元 数据的组织结构上是相同的，而在实际数据的存储上则有较大的差异；

在Table的创建过程和数据加载过程中，实际数据会被移动到数据仓库目录中，之后对 数据的访问将会直接在数据仓库的目录中完成；删除表时，表中的数据和元数据将会被同时 删除；

ExternalTable只有一个过程，因为加载数据和创建表是同时完成的；实际数据是存储 在Location后面指定的HDFS路径中的，它并不会移动到数据仓库目录中；

(3)数据交换

数据交换主要分为以下几个部分

用户接口：包括客户端、Web界面和数据库接口；

元数据存储：通常是存储在关系数据库中的；

解释器、编译器、优化器、执行器；

Hadoop：用HDFS进行存储，利用MapReduce进行计算；

用户接口主要有三个：客户端、数据库接口和Web界面；其中最常用的是客户端；Client 是Hive的客户端，当启动Client模式时，用户会想要连接HiveServer，这时需要指出 HiveServer所在的节点，并且在该节点启动HiveServer；Web界面是通过浏览器访问Hive 的；

Hive将元数据存储在数据库中，Hive中的元数据包括表的名字、表的列和分区及其属 性、表的属性、表数据所在的目录；

解释器、编译器、优化器完成HQL查询语句从词法分析、语法分析、编译、优化到查询 计划的生成；生成的查询计划存储在HDFS中，并在随后由MapReduce调用执行；

Hive的数据存储在HDFS中，大部分的查询由MapReduce完成。

所述数据采集管理组件对数据库进行数据采集，提供自数据库中采集数据的功能，并进 行定时的自动化采集；数据采集包括数据库数据采集、结构化文件数据采集、非结构化文件 数据采集；结构化文件数据采集，提供自结构化数据文件中采集数据的功能，并对文件中的 数据行进行自动化字段拆分；非结构化文件数据采集，提供自FTP自动化定时采集非结构化 文件，并对采集到的文件进行统一管理；数据采集通过ETL实现，ETL负责将分散的、异构 数据源中的数据如关系数据、平面数据文件抽取到临时中间层后，进行清洗、转换、集成， 最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘提供决策支持的数据。

所述业务建模构建的逻辑模型包括居民身份验证模型、数据综合模型、城市运行体征动 态模型、城市数据综合分析模型、移动电子政务模型。

用于智慧城市建设的大数据平台，其数据库连接有数据采集单元，所述数据采集单元一 方链接数据库，一方链接VPN，如源数据库为多个，则部署与源数据库对应的多个数据采集 单元，数据采集单元具体配置如下：

(1)基本信息配置：设置合作伙伴编码与名称，设置数据采集单元采集端编码；导出文 件配置：导出文件的保存路径、数据文件名、数据文件列分隔符、导出文件的编码格式，目 前数据文件默认为文本文件方式；

(2)链接配置：配置需要链接的数据库的数据库类型、链接的IP地址、数据库用户名 和密码；配置对应的ETL系统入库端的链接地址、用户名及密码；

(3)数据集配置：配置需要提取的数据集清单与每种数据集的采集周期；

(4)脚本编写及植入：可手工编写数据提取的SQL语句或存储过程，然后将脚本植入 到数据采集单元中；

(5)运行监控：监控数据采集的过程，日志自动保存与输出、报错提醒等；

(6)数据打包上传：对已经提取的数据进行加密、打包且上传到数据加载单元；根据机 房环境和数据库种类的不同，为数据采集单元设计不同的部署方式。

所述数据交换平台对基础空间地理信息库、人口数据库、法人数据库等三大基础数据库 的信息进行加工处理：

1)数据清洗

对各委办局采集或交换来的数据按照基础数据的标准格式要求进行检查整理，对不符合 质量要求或者错误的数据进行更正，最终确保数据的准确，数据清洗的目的是数是保证数据 库数据质量；

2)数据比对

对数据的字段、条件、合理数值范围、检查时段、预警方式，按照不同数据类型、数据 来源、变动方式进行单独或组合设置，由系统按照设置的比对指标，对各基础数据库的信息 进行综合比对分析，并生成比对结果，并根据授权情况，将比对结果分类下发到相关委办局， 对数据进行核查；核查后反馈的数据，将再次进入数据加工环节；在核查过程中，按照设置 的监管指标对各部门核查信息进行综合分析，并生成监察结果；

3)异常数据反馈

异常数据反馈实现数据采集、清洗、比对同数据采集委办局形成互动，将清洗和比对工 作中发现的异常数据反馈给数据提供委办局，提醒数据提供单位核实的同时，也帮助提高委 办局自身业务数据准确性；

4)数据入库

在数据入库时，配置定义入库规则和配置定义入库流程，支持顺序入库，并行入库；新 增数据字段在入库前，要完成新增信息资源目录服务登记工作，包括进行入库元数据和入库 目录的编目、注册、发布、审核；信息资源目录在开展基础应用、扩展应用和专业利用等应 用中起承上启下的关键作用，为各种应用提供基础数据管理服务，包括访问用户认证、用户 授权、监控、日志。

所述用于智慧城市建设的大数据平台，其逻辑架构包括：

数据采集接入层，是指不同部门按照业务需求，确定信息交换流程，在部门间实现具有 主动推送特点的连续、实时信息传输；信息交换有集中交换、分布交换与混合交换三种模式； 数据交换是用于实现数据的发送与接收，对参与者的合法性进行验证，并通过与数据传输中 间件的配合，实现可靠的数据交换；

数据处理层，对不同委办局交换而来的数据经过数据清洗、比对、融合环节而形成数据 库；其中，数据比对是对采集回来的各类数据，进行关键字段的比较核对，形成各类型属性 数据在主表上的挂靠，同时也将采集过来的各个类型属性数据中信息错误或有差异的数据进 行更正、统一；针对已经采集并清洗后的数据，分类同地理、自然人口、组织单位三大库主 表进行数据比对，比对上的数据，分主表和附属信息表存储，包括新增、修改；主表信息， 累计增加，附属表比对上后携带主表id存储；无法比对上的附属表信息作为异常数据存储， 以便统计和后期反馈；

数据融合层，通过地理信息库标准地址和自然人口身份证号码进行三大库整合，使三大 相对独立的对象进行关联，有效的实现地理、人口、组织单位的紧密结合，从而构成完整的 基础信息数据库：(1)主体对象表抽取，对各个部门采集数据进行清洗后，将信息过后的数 据分主次抽取，抽取地理、人口、组织单位三大主体对象，形成主体库；(2)主题表关联， 各主题库通过对应的主题表中的主键相互关联；(3)业务属性信息关联，以主题表关联形成 了数据关联融合的整体框架，各业务属性信息之间也需要通过相应的主键进行关联；(4)属 性信息与地理信息的关联，属性信息与地理信息的关联地址编码通过地址编码实现，地址编 码的过程通常包括地址标准化和地址匹配，地址标准化是指在进行地址编码之前，将道路地 址处理为一种熟悉的、常用的格式，纠正道路和地址名称的形式，地址匹配指确定具体地址 事件的空间位置，并且将其绘制在地图上，最终目标是为给定地址；

数据仓库层，是一个面向主题、集成的、非易失的、随时间变化的数据集合，能够对平 台数据进行分类、元数据抽取、数据统计、模型搭建、历史数据存储，为智能分析提供多角 度、多层次、多时间面的数据支持，同时存放了大量的历史统计静态数据，对于以时间为主 线的环比、同比、趋势等分析可提供直接的数据支持；

数据应用层为用户提供应用服务。

本发明与现有技术相比，具有如下优点和有益效果：

1)本发明实现党委、政府所有部门及临时设立的机构的数据交换，基础数据集中、清洗、 整理，以合理的数据结构进行存储，打破部门信息壁垒，解决信息孤岛问题。

2)本发明形成一整套数据清洗整理体系，前期采集数据通过采集-清洗-反馈-修改-再次 采集数据循环，清洗整理，后期各个部门新生产的数据，都以几个数据主体部门数据为基础， 产生数据后，再采集清洗，逐步提升基础数据质量。

3)本发明形成整套数据共享体系。数据采集清洗整理后，集中到政务大数据平台，各个 部门对已整理的数据提出数据要求，在实现数据安全、保密等多重权限控制情况下，以多种 方式提供给部门用户。实现部门之间的数据共享、共用，统一数据环境，减少部门之间数据 差异，提高各部门数据质量，方便部门应用。

4)本发明实现综合应用的建设。在完善的数据采集、清洗、共享体系下，在完整、实时、 权威及合理结构化的政务数据融合服务平台之上，实现区域化整体数据应用，为组织单位、 公众群体提供完整的数据展现、全面的基础数据服务，以及为领导决策层提供全面的、多层 次的、直观的、实时有效的数据分析，解决当前部门应用片面不完整，无法宏观把控的局面。

5)本发明的大数据平台通过将各委办局及投资公司信息资源梳理和整合，建立基础地理 空间库、人口库、法人库、宏观经济库、信用信息库和城市建筑信息库六大基础库，建立信 息系统的基底数据，实现城市管理中各要素的全面管理，为应用信息系统建设提供统一的数 据服务。通过统一的数据管理平台，提供数据标准化工具，使得数据的收集、清理、整合等 更加标准与完善，实现各个系统数据的一致性，保证不同来源的信息能够无缝使用，实现提 供数据检查、数据转换、数据入库、数据库性能调优、数据备份与恢复管理、数据权限控制、 数据导入导出、数据查询统计等功能，在保证数据高效应用基础上，保证数据的安全性。通 过建立数据交换平台，需实现自动抓取各委办局和投资公司信息系统中的增量数据，使得各 个单位收集及产生的数据向公共基础数据库的汇聚，保证公共基础数据库数据的能更新、可 更新和及时更新，保障公共基础数据库数据的现势性。

附图说明

图1为一种用于智慧城市建设的大数据平台的逻辑架构图。

具体实施方式

下面结合实施例及附图对本发明作进一步详细的描述，但本发明的实施方式不限于此。

大数据平台依托城市级智慧城市云计算中心和大数据平台，对所需计算、存储、网络资 源进行扩容，为形成一体化的智慧城市支撑与应用体系奠定基础。以资源整合、信息共享、 协同应用为主线，通过数据资源统一管理、共享交换与综合应用，形成智慧城市整体框架， 为“智慧城市”建设提供数据资源共享化、基础平台标准化、辅助决策智能化、智慧服务享 受“一站式”的核心基础支撑，带动各领域的资源共享交换、业务协同、智能化应用与便捷 化智慧服务。项目最终建成开放、可共享的高端计算环境，服务于政府信息化、同时为企业 创造新型科研、生产手段和资源服务，为科研提供国际水准的现代化科研环境，为跨行业跨 学科的技术合作创造机会，引导培育开发一批推动经济建设和行业发展的应用项目，培育新 的经济增长点，培养和吸引一批高级信息技术人才。

大数据平台在整个架构中每一层贯穿安全保障体系和标准规范体系，全面保障城市大数 据平台的整体安全和平稳运行，范围涵盖整个城市。如图1，用于智慧城市建设的大数据平 台的逻辑架构如下：

1.1.1.数据采集接入层

数据接入是指不同部门按照业务需求，确定信息交换流程，在部门间实现具有主动推送 特点的连续、实时信息传输。

典型的应用有公文交换、部门间基础信息交换、综合治税信息交换、信用信息交换、社 会保障信息交换等。信息交换有集中交换、分布交换与混合交换等三种模式。数据交换的主 要任务是实现数据的发送与接收，对参与者的合法性进行验证，并通过与数据传输中间件的 配合，实现可靠的数据交换。

数据可靠传输的目的是实现传输过程中的“不错、不丢、不重”。数据传输的可靠性由所 选定的中间件软件保证，通过数据传输中的数据压缩/解压缩以及断点续传等功能，保证数据 交换的可靠性。

1.1.2.数据处理层

不同委办局交换而来的数据经过数据清洗、比对、融合环节，为城市政务大数据平台打 造信息完整、结构清晰合理、数据准确及时的权威数据库。

1、数据清洗

由于信息共享平台数据采集部门较多，各个数据采集部门的信息化建设程度各异，数据 维护程度也各自不同，信息共享平台对从各个数据采集部门采集回来的数据进行规范性清洗， 屏蔽数据采集过程中，数据格式错误、无用甚至对信息共享平台有危害的数据。为信息共享 平台建设数据服务中心提供前期的一个数据过滤。

2、数据比对

数据比对主要是对采集回来的各类数据，进行关键字段的比较核对，形成各类型属性数 据在主表上的挂靠，同时也将采集过来的各个类型属性数据中信息错误或有差异的数据进行 更正、统一。

针对已经采集并清洗后的数据，分类同地理、自然人口、组织单位三大库主表进行数据 比对，比对上的数据，分主表和附属信息表存储，包括新增、修改。主表信息，累计增加， 附属表比对上后携带主表id存储。无法比对上的附属表信息作为异常数据存储，以便统计和 后期反馈。

数据比对主要分为程序比对和人工比对两种手段，程序无法识别的数据由人工进行核实。

3、异常数据反馈

异常数据反馈功能，将数据采集、清洗、比对同数据采集部门形成互动。将清洗和比对 工作中发现的异常数据反馈给数据提供部门，提醒数据提供部门核实的同时，也帮助提高部 门自身业务数据准确性。

1.1.3.数据融合层

数据共享平台在完成数据比对，形成地理信息、自然人口、组织单位三大对象数据结构 体系后，通过地理信息库标准地址和自然人口身份证号码进行三大库整合，使三大相对独立 的对象进行关联，有效的实现地理、人口、组织单位的紧密结合，从而构成完整的城市基础 信息数据库，数据融合的过程如下所示：

1、主体对象表抽取

对各个部门采集数据进行清洗后，将信息过后的数据分主次抽取，抽取地理、人口、组 织单位三大主体对象，形成主体库。

其中地理信息库主表，主要由地理信息构成，以地址信息id为主键，详细地址信息为主 要字段，形成地址信息库主表。

自然人口信息库主表，主要由公安自然人口信息构成，以人口信息id(或身份证号)为 主键，以自然人口地址信息、自然人姓名、性别等信息为主要字段，形成自然人口信息库主 表。

组织单位信息库主表，主要由工商企业登记信息、编办事业单位信息、民政社会团体、 民办非企业单位及质监局的组织机构代码颁证信息构成，以组织单位id为主键，以工商注册 号、组织机构代码证、组织单位名称、注册地址、办公地址等信息为主要字段，形成组织单 位信息库主表。

2、主题表关联

各主题库通过对应的主题表中的主键相互关联，如组织单位主题表通过企业地址与地址 信息主题表关联、人口主题表通过人员居住地址与地理信息主题表关联、自然人主题表通过 身份证号与组织单位主题表关联。

3、业务属性信息关联

以主题表关联形成了数据关联融合的整体框架，各业务属性信息之间也需要通过相应的 主键进行关联，如自然人口民政、劳动、计生、卫生信息等为属性专题数据表，通过身份证 号与自然人主题表关联。

4、属性信息与地理信息的关联

属性信息与地理信息的关联地址编码主要通过地址编码实现。地址编码的过程通常包括 两个明确的步骤，即地址标准化和地址匹配。地址标准化是指在进行地址编码之前，将道路 地址处理为一种熟悉的、常用的格式，纠正道路和地址名称的形式等。目前宁波市规划局已 经采集了20多万条标准地址数据，具备了地址匹配的基础条件。地址匹配指确定具体地址事 件的空间位置，并且将其绘制在地图上，最终目标是为给定地址，如：企业地址、人员居住 地址等返回最准确的匹配结果，并通过GIS服务器在地图上找到并标明每条地址所对应的位 置。

地址编码的方式有3种：定位到道路、定位到区域以及定位到道路和定位到区域相结合 的方式。

定位到道路：是通过道路名和门牌号码进行匹配，在参考主题中每一个路段都具有道路 名和起止门牌号码信息，在地理编码时，首先首先根据地址信息中道路名找到参考主题中相 同名称的路段，然后根据地址信息中的门牌号及每个路段的起止门牌号码信息找到门牌号所 在路段，最后根据门牌号及该路段的起止门牌号码信息进行内插确定该记录在该路段上的位 置。

定位到区域：将地址中具有区域属性的记录与地图地址相应属性的区域记录进行比较， 如果匹配成功，则将待查地址区域以点要素形式生成在地图的相应区域内。

定位到区域以及定位到道路和定位到区域相结合的方式：是将上述两个方法折中的方式 来实现的。

采用地址编码的优点：信息自动匹配，信息自动关联融合，减少了人力物力开销。缺点： 匹配信息存在不准确现象，系统实现过程复杂。

1.1.4.数据仓库层

随着城市大数据平台将越来越多的部门数据收集整合起来，信息共享平台数据内容越来 越复杂，更多的数据信息无法得到有效的分析利用。而随着社会信息化的快速发展，平台用 户决策任务越来越重，决策频率也越来越高，原始的数据分析已经无法负荷这种大量度、高 频率、多维度的决策支持工作，为此信息共享平台引入数据仓库技术。

数据仓库是一个面向主题、集成的、非易失的、随时间变化的数据集合，能够对平台数 据进行分类、元数据抽取、数据统计、模型搭建、历史数据存储等操作，为智能分析提供多 角度、多层次、多时间面的数据支持，方便智能分析中数据统计，利用数据仓库，新的分析 需求无需从原始数据进行重新归总统计，可直接利用初步综合数据或中度综合数据甚至高度 综合数据，从而节约数据分析时间，快速支持用户决策，同时也节约了分析系统设计开发成 本。

数据仓库还存放了大量的历史统计静态数据，对于以时间为主线的环比、同比、趋势等 分析可提供直接的数据支持，不需向原始的数据分析那样去调用原始的历史数据来重复统计， 也解决有些数据无历史数据记录的弊端。

1.1.5.数据应用层

应用系统是数据融合服务平台建设的目的，通过应用系统的建设，充分发挥基础人口、 组织单位库和地理信息库融合以及多部门信息整合的优势，满足以往做不好或者不能做的业 务应用，以各种灵活的方式为用户提供应用服务，例如部门共享应用、智慧社区、政府应用、 领导桌面、智能分析、权限管理、全面审计、数据目录、单点登录、公众服务等。

一种用于智慧城市建设的大数据平台，包括大数据基础平台、数据交换平台、数据管理 平台、运行支撑平台和数据门户；其中，

一、大数据基础平台：

城市政务服务所需要的数据来自于各委办局和街道，包含传统数据库数据、视频、图片、 声音、日志文件、电子邮件、地图、Word、PDF等各种文档。这些数据分为结构化数据、半 结构化数据和非结构化数据。这些类型的数据无法用传统关系型数据库进行数据处理和分析， 必须借助于大数据基础平台的HDFS、Hbase、MapReduce等技术手段进行处理和分析，支持 顶层应用系统的数据利用。大数据基础平台主要包括如下组件：

1、大数据平台运维管理组件

运维管理组件提供大数据平台组件部署及动态扩容，提供大数据平台部署工具，组件部 署管理及动态增加机器节点管理工具；组件服务监控管理，提供组件的运行状态、组件的负 载情况监控及组件的启动、停止、移除等管理；组件故障自动迁移，节点组件出现故障时， 集群中的其它节点中的相应组件自动接管故障组件的工作，保证组件正常服务。

运维管理组件主要由两部分组成：运维管理组件-agent和运维管理组件-server。在agent 端，采用puppet管理节点；在Server端，采用Jetty,Spring，Jetty，JAX-RS等；可以利用Ganglia， Nagios的分布式监控能力。在运维管理组件的系统架构中，其中master模块接受API和 AgentInterface的请求，完成运维管理组件-server的集中式管理监控逻辑，而每个agent节点 只负责所在节点的状态采集及维护。

运维管理组件Server会读取Stack和Service的配置文件。当用运维管理组件创建集群的 时候，运维管理组件Server传送Stack和Service的配置文件以及Service生命周期的控制脚 本到运维管理组件Agent。Agent拿到配置文件后，会下载安装公共源里软件包(Redhat，就 是使用yum服务)。安装完成后，运维管理组件Server会通知Agent去启动Service。之后运 维管理组件Server会定期发送命令到Agent检查Service的状态，Agent上报给Server，并呈 现在运维管理组件的GUI上。

运维管理组件Server支持RestAPI，这样可以很容易的扩展和定制化运维管理组件。甚 至于不用登陆运维管理组件的GUI，只需要在命令行通过curl就可以控制运维管理组件，以 及控制Hadoop的cluster。

2、分布式数据库

采用分布式数据库Hbase。同时利用HBase中的主从复制和循环复制，使得系统达到一 种高可用的状态。HBase复制是一种在不同HBase部署中复制数据的方法。它可以作为一种 故障恢复的方法，并提供HBase层次的高可用性。在实际应用中，例如，可以将数据从一个 面向页面的集群复制到一个MapReduce集群，后者可以同时处理新数据和历史数据。然后再 自动将数据传回面向页面请求的集群。

HBase复制中最基本的架构模式是“主推送”(master-push)，因为每个regionserver都有 自己的WAL(或HLog)，所以很容易保存现在正在复制的位置。正如众所周知的解决方案 -Mysql的主/从复制，只使用二进制文件来跟踪修改。一个主集群可以将数据复制到任意数目 的从集群，每个regionserver都会参与复制自己的修改。

复制是异步进行的，意味着集群可以是地理上彼此远离的，它们之间的连接可以在某个 时刻断开，在主集群上的修改不能马上在从集群上进行同步(最终一致性)。和SQL语句不 同，所有的WALEdits(包括来自客户端的Put和Delete产生的多单元格操作)都会被复制以 保证原子性。

来自每个regionserver的HLog是HBase复制的基础，并且只要它们需要将数据复制到从 集群，它们就必须被保存到HDFS上。每个regionserver从它需要的最老的日志开始复制，同 时在zookeeper中保存当前恢复的位置来简化错误恢复。每个从集群恢复的位置可能不同，但 它们处理的HLog队列内容是相同的。参与复制的集群的规模可以不对等。主集群会通过随 机分配尽量均衡从集群的负载。

3、分布式数据仓库

采用分布式数据仓库Hive。XData-Hadoop发行版中Hive的元数据是存储到Mysql中， 利用mysql的ha对hive的元数据进行高可用设计。具体如下：

安装MySQLHA集成环境的两个节点要配置无密码环境，并且两个节点互相加入了对方 节点的known-hosts文件。

Heartbeat主从节点都需要两个网卡，一个网卡需要为外网访问提供服务，一个网卡需要 为心跳线服务，两个网卡配置IP不能在同一子网中，心跳线所使用网卡IP不要设置路由信 息。主节点上的两个不同用处的网卡名称应该分别与从节点上的两个不同用处的网卡对应并 相同。

Hive是建立在Hadoop上的数据仓库基础构架。它提供了一系列的工具，用来进行数据 提取、转化、加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。 Hive定义了简单的类SQL查询语言，称为QL，它允许熟悉SQL的用户查询数据。作为一个数据仓库，Hive的数据管理按照使用层次可以从元数据存储、数据存储和数据交换三个方面 来介绍。

(1)元数据存储

Hive将元数据存储在RDBMS中，有三种模式可以连接到数据库：

SingleUserMode：此模式连接到一个In-memory的数据库Derby，一般用于UnitTest。

MultiUserMode：通过网络连接到一个数据库中，这是最常用的模式。

RemoteServerMode：用于非Java客户端访问元数据库，在服务器端启动一个MetaStoreServer，客户端则利用Thrift协议通过MetaStoreServer来访问元数据库。

(2)数据存储

首先，Hive没有专门的数据存储格式，也没有为数据建立索引，用户可以非常自由地组 织Hive中的表，只需要在创建表的时候告诉Hive数据中的列分隔符和行分隔符，它就可以 解析数据了。

其次，Hive中所有的数据都存储在HDFS中，Hive中包含4种数据模型：Table、ExternalTable、Partition、Bucket。

Hive中的Table和数据库中的Table在概念上是类似的，每一个Table在Hive中都有一 个相应的目录来存储数据。例如，一个表pvs，它在HDFS中的路径为：/wh/pvs，其中，wh是在hive-site.xml中由${hive.metastore.warehouse.dir}指定的数据仓库的目录，所有的Table 数据(不包括ExternalTable)都保存在这个目录中。

Partition对应于数据库中Partition列的密集索引，但是Hive中Partition的组织方式与数 据库中的很不相同。在Hive中，表中的一个Partition对应于表下的一个目录，所有的Partition 数据都存储在对应的目录中。例如：pvs表中包含ds和city两个Partition，则对应于 ds＝20090801,city＝US的HDFS子目录为：/wh/pvs/ds＝20090801/city＝US；对应于 ds＝20090801,city＝CA的HDFS子目录为：/wh/pvs/ds＝20090801/city＝CA。

Buckets对指定列计算hash，根据hash值切分数据，目的是为了便于并行，每一个Buckets 对应一个文件。将user列分散至32个Bucket上，首先对user列的值计算hash，比如，对应 hash值为0的HDFS目录为：/wh/pvs/ds＝20090801/city＝US/part-00000；对应hash值为20的 HDFS目录为：/wh/pvs/ds＝20090801/city＝US/part-00020。

ExternalTable指向已经在HDFS中存在的数据，可以创建Partition。它和Table在元数据 的组织结构上是相同的，而在实际数据的存储上则有较大的差异。

在Table的创建过程和数据加载过程(这两个过程可以在同一个语句中完成)中，实际 数据会被移动到数据仓库目录中。之后对数据的访问将会直接在数据仓库的目录中完成。删 除表时，表中的数据和元数据将会被同时删除。

ExternalTable只有一个过程，因为加载数据和创建表是同时完成的。实际数据是存储在 Location后面指定的HDFS路径中的，它并不会移动到数据仓库目录中。

(3)数据交换

数据交换主要分为以下几个部分：

用户接口：包括客户端、Web界面和数据库接口。

元数据存储：通常是存储在关系数据库中的，如MySQL、Derby等。

解释器、编译器、优化器、执行器。

Hadoop：用HDFS进行存储，利用MapReduce进行计算。

用户接口主要有三个：客户端、数据库接口和Web界面，其中最常用的是客户端。Client 是Hive的客户端，当启动Client模式时，用户会想要连接HiveServer，这时需要指出HiveServer 所在的节点，并且在该节点启动HiveServer。Web界面是通过浏览器访问Hive的。

Hive将元数据存储在数据库中，如MySQL、Derby中。Hive中的元数据包括表的名字、 表的列和分区及其属性、表的属性(是否为外部表等)、表数据所在的目录等。

解释器、编译器、优化器完成HQL查询语句从词法分析、语法分析、编译、优化到查询 计划的生成。生成的查询计划存储在HDFS中，并在随后由MapReduce调用执行。

Hive的数据存储在HDFS中，大部分的查询由MapReduce完成(包含*的查询不会生成 MapRedcue任务，比如select*fromtbl)。

以上从Hadoop的分布式文件系统HDFS、分布式数据库HBase和数据仓库工具Hive入 手介绍了Hadoop的数据管理，它们都通过自己的数据定义、体系结构实现了数据从宏观到 微观的立体化管理，完成了Hadoop平台上大规模的数据存储和任务处理。

4、分布式计算模块

利用MapReduce、Spark等分布式计算框架，为上层应用提供大数据分布式计算的支撑， 提供Mahout，MLlib等算法库支撑，提供数据存储访问及分布式计算任务的调度、运行支撑 环境能力。

MapReduce

XData-SDH的大数据批处理的计算模式是MapReduce，这是MapReduce设计之初的主要 任务和目标。MapReduce是一个单输入、两阶段(Map和Reduce)的数据处理过程。首先，MapReduce对具有简单数据关系、易于划分的大规模数据采用“分而治之”的并行处理思想；然后将大量重复的数据记录处理过程总结成Map和Reduce两个抽象的操作；最后MapReduce提供了一个统一的并行计算框架，把并行计算所涉及到的诸多系统层细节都交给计算框架去 完成，以此大大简化了程序员进行并行化程序设计的负担。

MapReduce的简单易用性使其成为目前大数据处理最成功的主流并行计算模式。在开源 社区的努力下，开源的Hadoop系统目前已成为较为成熟的大数据处理平台，并已发展成一 个包括众多数据处理工具和环境的完整的生态系统。目前几乎国内外的各个著名IT委办局都 在使用Hadoop平台进行委办局内大数据的计算处理。

HadoopHDFS是GoogleGFS存储系统的开源实现，主要应用场景是作为并行计算环境 (MapReduce)的基础组件，同时也是BigTable(如HBase、HyperTable)的底层分布式文件系统。HDFS采用master/slave架构。一个HDFS集群是有由一个Namenode和一定数目的Datanode组成。Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。

HadoopMapReduce是一个使用简易的软件框架，基于它写出来的应用程序能够运行在由 上千个商用机器组成的大型集群上，并以一种可靠容错的方式并行处理上TB级别的数据集。

一个MapReduce作业(job)通常会把输入的数据集切分为若干独立的数据块，由Map 任务(task)以完全并行的方式处理它们。框架会对Map的输出先进行排序，然后把结果输 入给Reduce任务。通常作业的输入和输出都会被存储在文件系统中。整个框架负责任务的调 度和监控，以及重新执行已经失败的任务。

Spark分布式计算框架

Spark是一个通用的并行计算框架，是一种快速处理大规模数据的通用引擎。

HadoopMapReduce的每一步完成必须将数据序列化写到分布式文件系统导致效率大幅降 低。Spark尽可能地在内存上存储中间结果，极大地提高了计算速度。

MapReduce是一路计算的优秀解决方案，但对于多路计算的问题必须将所有作业都转换 为MapReduce模式并串行执行。

Spark扩展了MapReduce模型，允许开发者使用有向无环图(DAG)开发复杂的多步数 据管道。并且支持跨有向无环图的内存数据共享，以便不同的作业可以共同处理同一个数据。

Spark不是Hadoop的替代方案而是其计算框架HadoopMapReduce的替代方案。Hadoop 更多地作为集群管理系统为Spark提供底层支持。

Spark可以使用本地Spark，HadoopYARN或ApacheMesos作为集群管理系统。Spark支 持HDFS，Cassandra，OpenStackSwift作为分布式存储解决方案。

Spark采用Scala语言开发运行于JVM上，并提供了Scala，Python，Java和R语言API， 可以使用其中的Scala和Python进行交互式操作。

5、流数据处理及消息框架

支持主流的流处理框架，框架采用小批量流式处理方式，每隔设定间隔(100毫秒)处 理当前批次数据；可支持复杂SQL应用和在线流式机器学习。并且支持Kafka,Flume等常见 消息队列或采集工具，兼容现有Hadoop生态系统。支持storm流式处理框架。具有扩展性强、 容错性强、延迟低、吞吐高等特点。而且可以将kafka，storm，Hbase等组件连接起来。

SparkStreaming流式计算

随着大数据的发展，人们对大数据的处理要求也越来越高，原有的批处理框架MapReduce 适合离线计算，却无法满足实时性要求较高的业务，如实时推荐、用户行为分析等。 SparkStreaming是建立在Spark上的实时计算框架，通过它提供的丰富的API、基于内存的高 速执行引擎，用户可以结合流式、批处理和交互试查询应用。本节将详细介绍SparkStreaming 实时计算框架的原理与特点、适用场景。

Spark是一个类似于MapReduce的分布式计算框架，其核心是弹性分布式数据集，提供 了比MapReduce更丰富的模型，可以在快速在内存中对数据集进行多次迭代，以支持复杂的 数据挖掘算法和图形计算算法。SparkStreaming是一种构建在Spark上的实时计算框架，它扩 展了Spark处理大规模流式数据的能力。

SparkStreaming的优势在于：

能运行在100+的结点上，并达到秒级延迟。

使用基于内存的Spark作为执行引擎，具有高效和容错的特性。

能集成Spark的批处理和交互查询。

为实现复杂的算法提供和批处理类似的简单接口。

SparkonYarn启动后，由SparkAppMaster把Receiver作为一个Task提交给某一个SparkExecutor；Receive启动后输入数据，生成数据块，然后通知SparkAppMaster；SparkAppMaster会根据数据块生成相应的Job，并把Job的Task提交给空闲SparkExecutor执 行。

分布式消息框架

分布式消息系统属于中间件产品，功能是将前端采集来的数据进行分布式缓存，以供后 端进行实时处理。

Kafka是一种分布式的，基于发布/订阅的分布式消息系统，可以用来缓存采集的流数据。

Topic：特指Kafka处理的消息源的不同分类。

Partition：Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个 有序的队列。partition中的每条消息都会被分配一个有序的id(offset)。

Message：消息，是通信的基本单位，每个producer可以向一个topic(主题)发布一些 消息。

Producers：消息和数据生产者，向Kafka的一个topic发布消息的过程叫做producers。

Consumers：消息和数据消费者，订阅topics并处理其发布的消息的过程叫做consumers。

Broker：缓存代理，Kafa集群中的一台或多台服务器统称为broker。

6、数据采集管理组件

对数据源的提供者、业务来源、连接信息、连接状态等进行管理，实现对数据来源的跟 踪；数据库数据采集，提供自Oracle、SQLServer、MySql等数据库中采集数据的功能，并进 行定时的自动化采集；结构化文件数据采集，提供自结构化数据文件中采集数据的功能，并 对文件中的数据行进行自动化字段拆分；非结构化文件采集，提供自FTP自动化定时采集非 结构化文件，并对采集到的文件进行统一管理。

数据源管理

可实现对数据源，可实现对本地文件、主流结构化数据库、分布式数据存储等数据源的 提供者、业务来源、连接信息、连接状态等进行管理。

支持的本地化文件包括excel、csv等；

支持的主流结构化数据库包括MySql、Oracle、PostgreSql、SQLserver、DB2、MonetDB 等；

支持的分布式数据存储包括HDFS、Hive、Hbase等。

数据采集

数据采集包括数据库数据采集、结构化文件数据采集、非结构化数据采集。数据采集通 过ETL工具实现，ETL负责将分散的、异构数据源中的数据如关系数据、平面数据文件等抽 取到临时中间层后，进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机 分析处理、数据挖掘提供决策支持的数据。

该系统采用SOA技术架构设计，采用组件复用和框架技术，以SOA面向服务的架构为 基础，通过该服务平台开发出的应用系统具备松散耦合、可重用服务、标准化的服务接口、 支持各种消息模式，实现应用系统之间以及与其他外部应用系统无缝、高效集成。

ETL

即数据采集单元，是数据转出客户端，是与数据库服务器相连的负责采集相关数据的单 元，一方链接数据库，一方链接VPN，如源数据库为多个，则ETL系统采集端部署多个与源 数据库对应。ETL系统采集端功能如下：

(1)基本信息配置：设置合作伙伴编码与名称，设置ETL系统采集端编码；导出文件配置：导出文件的保存路径、数据文件名、数据文件列分隔符、导出文件的编码格式，目前数据文件默认为文本文件方式；

(2)链接配置：配置需要链接的数据库的数据库类型、链接的IP地址、数据库用户名 和密码；配置对应的ETL系统入库端的链接地址、用户名及密码；

(3)数据集配置：配置需要提取的数据集清单与每种数据集的采集周期(比如年、月、 日等)；

(4)脚本编写及植入：可手工编写数据提取的SQL语句或存储过程，然后将脚本植入 到数据采集单元中；

(5)运行监控：监控数据采集的过程，日志自动保存与输出、报错提醒(邮件\短信等) 等；

(6)数据打包上传：对已经提取的数据进行加密、打包且上传到数据加载单元；为保证 数据采集的及时性、准确性，需要根据机房环境和数据库种类的不同，为数据采集单元设计 不同的部署方式。

数据采集单元部署在机房，需要注意以下问题：

根据机房环境，设计如何接入互联网的方案；

数据采集单元通过VPN连入外联区域；

为达到免责目的，数据采集单元务必独立于零售商的硬件设备；

合理设计数据采集单元相对于防火墙的位置；

在一般情况下，采用远程桌面方式执行日常维护。

系统特点：

支持多种运行环境

支持云平台、Windows、Linux、Unix等主流操作系统厂商的运行环境；平台可移植性高， 并可对多终端的数据进行同步和协调。

支持多数据源数据采集

支持多数据源数据采集：支持从主流关系型数据库(oracle，MYSQL，SQLServer，DB2， sydbase，informix，达梦，神通)，webservice接口，文件服务器等多种存储设备中采集数据。

支持大数据存储和访问

全面支持大数据存储和访问，支持大数据环境的数据采集。支持大数据存储载体Hadoop/HDFS和Avro，支持访问HDFS内的文件内容。支持主流NoSQL数据库，包括：Hbase，mongodb等。

图形化作业

支持图形化作业：从图形化界面创建数据采集转换、作业，以流程图方式呈现，具备清 晰，直观的可视化操作界面。

可视化作业

支持可视化作业监控调度：在web可视化界面上统一调度作业，支持作业的执行，暂停， 以及作业的日志报告查看。

支持多数据标准

支持XML、WebServices、JSON，JMS等数据标准；

遵循restful风格

遵循restful风格标准消息传递机制；

7、数据运维管理组件

数据运维管理组件提供对大数据平台数据的统一监控和运维管理，具体功能包括：平台 数据监控，对大数据平台中已有数据存储量、数据增量、表数量、在线访问人数等信息进行 监控；平台数据处理任务管理，对平台中的数据采集处理任务信息进行集中查看及管理；平 台操作日志管理，对平台中的用户登录情况、用户访问数据表的情况进行日志记录，并提供 筛选及查询功能；用户及部门管理，提供多层级的部门管理及用户管理，并提供用户排序等 功能；角色及数据权限管理，提供自定义管理员及平台用户角色的功能，对不同角色可授予 精细至表字段的数据访问权限管理；审批管理，提供审批权限配置工具，并根据配置进行流 转审批管理。

数据监控

整体状态监控

提供对交换节点、交换作业、吞吐量、异常情况的整体监控。

可按照过去一小时、过去一周、过去30天等维度查看数据交换实时流量。

可查看交换节点的服务器名称、主机名或IP地址、端口号、是否主服务器、用途、状态 等详细信息。

■基础数据库

(1)信息资源规划

城市大数据平台作为市政务部门数据交换中心和数据共享中心，需要实现数据的集中交 换和集中存储，因此，在全面建设之前，必须通过信息资源梳理，对城市各委办局之间的输 入数据及输出数据进行全面梳理，分析出需要集中交换与共享的数据。在此基础上，通过与 中心交换的方式，实现各委办局之间的数据共建共享。

信息资源梳理是对城市各委办局在业务开展过程中，从数据的采集、存储、传输到使用 的全面规划。通过对各委办局的信息需求获取、现状信息环境调研、信息需求分析等一系列 数据资源梳理分析工作，站在城市整体的基础之上，设计城市大数据中心需要存储的数据和 交换的数据，并在此基础之上，制定数据存储和交换的数据标准。

(2)基础数据库

城市大数据平台未来需要集中存储的数据包括各委办局需要交换进来的数据和需要交换 出去的数据，两部分数据按照业务主题可划分为人口、法人、空间地理和宏观经济四类数据， 每类数据结合国家目前正在建设的人口库、法人库、空间地理库和宏观经济库等内容，主要 内容包括：

人口类数据：存储与人口相关的各种属性信息，包括人口基本信息、人口扩展信息及专 用信息，人口基本信息中存储人口最基本的数据项信息，包括：姓名、性别、民族、出生日 期、住址、公民身份号码、照片，人口扩展信息中存储户籍、出生、死亡等信息，人口专用信息中按涉及人口管理的委办局具体的行政管理职能存储专用的人口信息，包括卫生、教育、 税务、计生等专有信息。

法人类数据：存储与法人相关的各种信息，包括法人基本信息及法人扩展信息。法人基 本信息中存储法人最基本的数据项信息，包括：机构名称、机构类型、机构住所、法定代表 人姓名、经营或业务范围、注册或登记机构名称、注册或登记号、资金币种、注册资本或开 办资金金额、成立日期、行政区域代码等信息；法人专用信息中按涉及法人管理的委办局具 体的行政管理职能存储专用的法人信息，包括工商、质监、税务等专有信息。

空间地理数据：存储与空间地理有关的元数据库、基础空间数据库、政务信息图层数据 库、地名地址数据库、历史数据库、三维模型数据库等七大类。

宏观经济数据：由部门数据信息和类别数据信息组成。部门数据信息反映从各委办局采 集、清洗、比对后的信息，信息的存储按照数据部门来源划分；类别数据信息是按照经济、 社会、居民生活等数据类型进行存储，同一数据类别的信息可以来源于多个部门。

(3)基础数据框架

数据资源体系框架是城市大数据平台从数据采集、处理、存储和管理的总体架构，为上 层应用提供高档次的数据存储和处理环境，数据资源体系框架主要侧重于业务处理所需的信 息和信息流，从实际业务出发，开展数据资源梳理，从数据采集、处理、传输、到使用进行 统一规划，设计城市大数据平台整体的数据资源架构。从存储信息对象上来看，主要存储三 大库数据、以及从互联网上获取的各种信息的社会综合大数据。

(4)基础数据分区

根据数据资源共享交换平台数据库规划，数据资源共享交换平台的数据存储由交换数据 临时存储区、操作型数据存储区、数据仓库、数据集市4个区域构成，具体建设的时候需要 根据它们各自的特点分别进行设计。

交换数据临时存储区。交换数据临时存储区(ExchangeDataStore，EDS)是用来保证数 据交换过程中安全隔离和临时存储的存储区，其数据结构应与接入的应用系统保持一致。

操作型数据存储区。操作型数据存储区(OperationalDataStore，ODS)存放集成的、可 更新的、近实时的业务数据。ODS主要用于异构业务数据源的明细数据整合后、进入数据仓 库前的存储，并提供企业面向业务的、近实时的统一数据视图，支持企业全局业务数据的近 实时查询与分析。ODS是业务系统间公共和共享数据的存储区，是业务系统与数据仓库间的 数据迁移的缓存区，是支持数据资源共享交换平台应用中实时查询数据的存储区，是日常业 务决策支持的数据存储区。ODS数据模型依据数据模型构建，基于主题域组织，其主题域划 分和核心数据实体与企业数据模型相同。

数据仓库。数据仓库(DataWarehouse，DW)存放面向主题的、集成的、相对稳定的、反应历史变化的数据。数据仓库统一存放与管理经整合后、具体分析价值的企业历史数据，支持基于大量历史数据的企业决策分析。数据仓库中存储从业务系统中到处的用于决策和挖 掘的企业数据，也到处操作型数据的轻度汇总数据。数据仓库的数据一部分通过ODS导入， 一部分通过业务系统直接导入。数据仓库的数据模型按照主题组织，主题域划分与数据模型 相同，数据模型依据数据模型构建。

数据集市。数据集市(DataMarkets，DM)是以数据仓库数据为唯一数据源、面向特定 分析应用、俺一定方式重新组织的数据集合，是数据仓库的子集。数据集市基于数据仓库创 建，用于不同业务部门的需求和不同分析应用的分析数据的存储，数据集市的数据模型与企 业数据模型一直，用于描述企业业务部门、企业综合分析以及高级管理人员分析所需的数据。 数据集市模型也按主题组织，但其主题域划分与数据模型不同，数据集市的主题是基于企业 的不同部门、不同人员的分析需求而组织的。

基础数据分层。城市大数据平台数据模型是数据资源层的核心，是整个城市大数据平台 数据资源标准的具体体现，包括两级四层，分别为市级数据模型、应用级数据模型。市级数 据模型包括市级概念数据模型和市级逻辑数据模型。市级概念数据模型定义城市大数据中心 的主题域，反映业务的综合性信息需求。市级逻辑数据模型是对概念数据模型的分解和规范 化，描述实体、属性及实体之间的关系，提供了城市大数据中心的总体数据视图。通过建立 市级数据模型，规范应用级数据模型的设计，可减少信息化应用之间数据的重复定义和不一 致性，从源头上保证数据的质量，降低应用集成和数据共享的难度。市级数据模型应在各应 用系统建设之前，从整个城市的角度，统一、集中设计数据模型，保证数据存储模式合理、 科学。应用级数据模型包括应用级逻辑数据模型和应用级物理数据模型。应用级逻辑数据模 型是针对具体信息化应用的逻辑数据模型，通常为市级逻辑数据模型的子集，为系统开发提 供数据规范。应用级物理数据模型是在应用级逻辑数据模型的基础上，考虑各种具体的技术 实现因素，结合具体数据库管理系统，进行物理结构设计，以满足数据存储需要。应用级数 据模型是应用系统的重要组成部分，按照应用系统建设进程不断建立和完善。

二、数据交换平台

数据交换平台，通过各种方式，逐步采集完善各类基础数据及专题数据；通过数据交换 平台，按照统一的标准和规范，将城市各个委办局的数据资源汇总到城市大数据平台，实现 城市信息资源的汇聚和传递，满足全县各个委办局对实时信息的横向交换以及业务协同等需 求，为城市政务协同、公共服务和辅助决策等提供信息交换和共享服务；为保证数据的动态 准确性，需要对基础空间地理信息库、人口数据库、法人数据库等三大基础数据库的信息进 行数据清洗、数据比对、异常数据反馈、数据入库等加工处理。

(1)数据采集

1)数据采集方向

为了保障人口库、法人库、空间地理信息库和宏观经济库等数据在采集过程中的完整性、 准确性和及时性，应从以下几个方面进行：

建立数据采集组织，实地开展数据采集工作。通过划分区域，由专人负责定时采集和更 新相应区域的四大库数据。通过对采集人员的培训以及制定数据采集制度、数据填报表格， 规范数据采集工作，提高数据采集质量。同时，开发数据采集直报系统，充分利用移动应用 等技术，实现异地数据直报，提高数据采集工作效率。

在行政审批过程中，逐步采集完善基础数据。各委办局、政务服务中心在各事项审批过 程中，登记和审核各种与自然人、法人的相关证件信息和基本信息，这些信息可以作为人口 库和法人库的数据来源。

通过与广西壮族自治区政府建设的电子政务信息系统对接，进行交换获取数据。广西壮 族自治区建设的电子政务类信息化系统包含了大量的基础数据，并且这些系统为政府各部门 提供了开放接口。城市大数据平台可以与这些系统进行对接，获得与城市行政管理范围内的 人口、法人、空间地理和宏观经济数据。

通过人口普查工作完善基础数据库数据。借助每次人口普查工作的开展，收集人口数据， 通常人口普查登记包括了人口的自然特征，如年龄、性别、民族、家庭、生育、死亡等等， 另外还有社会特征，比如人的迁移、分布、文化特征、教育特征、宗教等等。经济特征数据 主要包括就业状况、职业、行业等信息。

2)数据采集步骤

对于数据采集，建议采用分步进行，逐步扩充的原则，先整合目前能够获取的部门数据， 通过对这些数据的整合，搭建起系统的整体框架，并制定相应的数据规范标准以及数据清洗 比对规则。通过平台整体效应，吸引其他委办局实现数据共享。

如果实际业务要求，需要实现数据全面共享，对于未开放数据接口的委办局，采用以下 两种方法获取相关数据。

一是数据首次初始化，可以通过行政手段，协调得到相关历史数据，并根据历史数据结 构建立相关业务数据库，对于新增或更新的数据可以通过在采集页面增加数据收集插件，对 相关数据库中的信息进行更新。

二是在提供一个具有查询权限的用户基础上，可以通过开发具有页面解析功能的插件， 当用户进行查询操作时，通过插件对查询结果页面进行分析，从中获取相关业务数据字段信 息，并将获取的信息保存到市级数据库中。

在具体实施过程中，在对不开放数据接口的委办局，通过相关的页面插件收集数据，存 在一定的风险，如果数据泄露，则会造成非常大的影响，所以建议从易到难，先整合目前能 够开放数据接口的委办局数据，在逐步扩充，最终实现数据的全面共享。

(2)数据交换

通过数据交换平台，按照统一的标准和规范，将城市各个委办局的数据资源汇总到城市 大数据平台，实现城市信息资源的汇聚和传递，满足全市各个委办局对实时信息的横向交换 以及业务协同等需求，为城市政务协同、公共服务和辅助决策等提供信息交换和共享服务。

数据交换的目的是实现传输过程中的“不错、不丢、不重”。数据交换系统核心的功能包 括数据桥接子系统、数据传输子系统、前置交换子系统和交换管理监控子系统。

1)交换桥接子系统

桥接系统的功能完成委办局业务系统信息库与前置信息库(或交换平台)之间双向安全、 可靠的信息交换，并实现数据格式转换。桥接实现方式包括直接连接、通过网闸等定时或实 时传输。主要功能包括数据映射、数据提取、数据抽取、过滤规则配置、数据转换、数据导 出、数据导入、监控管理等功能。

2)交换传输子系统

交换传输系统即消息总线系统，作为前置交换系统之间的信息交换通道，实现交换信息 的打包、转换、传递、路由、解包日志服务等功能。

3)前置交换子系统

为确保各委办局的原有系统的运行不被资源整合所影响，保障原系统的数据安全，使用 前置机作为各委办局与数据交换平台进行数据交换的窗口，一方面从各业务系统提取数据， 向中心提交，另一方面从数据中心接收数据，并向业务系统传递数据。前置机应具备缓存交 换数据，对数据进行过滤、加工和展现的功能。主要由网络通信系统、操作系统、交换信息 库、前置交换环境、交换服务配置工具等组成。

4)交换管理监控子系统

交换监控子系统作为交换系统的中心管理模块，协同委办局交换前置机和中心交换前置 机的运行并对交换系统的运行情况进行管理和监控。管理监控子系统提供对整体的监控、业 务域的管理、节点的管理、传输管理、安全管理、路由管理、统计分析和日志服务等功能。

(3)数据加工

为保证数据的动态准确性，需要对基础空间地理信息库、人口数据库、法人数据库等三 大基础数据库的信息进行加工处理。

数据加工处理流程如下所示。

1)数据清洗

对各委办局采集或交换来的数据按照基础数据的标准格式要求进行检查整理，对不符合 质量要求或者错误的数据进行更正，最终确保数据的准确。数据清洗的目的是数是保证数据 库数据质量。

2)数据比对

对数据的字段、条件、合理数值范围、检查时段、预警方式等内容，按照不同数据类型、 数据来源、变动方式进行单独或组合设置，由系统按照设置的比对指标，对各基础数据库的 信息进行综合比对分析，并生成比对结果，并根据授权情况，将比对结果分类下发到相关委 办局，对数据进行核查。核查后反馈的数据，将再次进入数据加工环节。在核查过程中，系 统按照设置的监管指标对各部门核查信息进行综合分析，并生成监察结果。

3)异常数据反馈

异常数据反馈实现数据采集、清洗、比对同数据采集委办局形成互动，将清洗和比对工 作中发现的异常数据反馈给数据提供委办局，提醒数据提供单位核实的同时，也帮助提高委 办局自身业务数据准确性。

4)数据入库

在数据入库时，配置定义入库规则和配置定义入库流程，支持顺序入库，并行入库。新 增数据字段在入库前，要完成新增信息资源目录服务登记工作，包括进行入库元数据和入库 目录的编目、注册、发布、审核等工作。信息资源目录在开展基础应用、扩展应用和专业利 用等应用中起承上启下的关键作用，为各种应用提供基础数据管理服务，包括访问用户认证、 用户授权、监控、日志等。

三、数据管理平台

(1)资源目录服务

按照国家信息资源目录体系标准，建立统一的信息资源目录体系，建设统一的信息资源 管理中心，形成“物理分散、逻辑集中”信息资源管理模式；提高信息的交换能力，支持跨部 门间的信息共享和业务协同，提高交各单位、各部门协同、管理水平。

通过借鉴信息资源目录体系，设计城市大数据中心的信息资源目录服务系统，构建信息 资源目录体系和信息资源共享环境，并通过目录服务实现跨部门的共享信息资源发现、定位 与获取。该系统功能主要包括编目传输、目录服务、目录管理及共享服务。

信息资源目录服务系统工作过程分为信息资源目录访问过程、目录服务形成与提供流程 和共享信息资源定位与发现流程：

准备：首先由各部门建立共享信息库，并建立共享信息服务系统，提供共享信息的浏览、 查询和下载等服务；

编目：各部门对共享信息的内容提取特征，通过编目系统形成目录内容库；

注册：由各部门通过目录传输系统将目录内容传送到目录服务中心；

发布：由目录服务中心对各部门的目录内容进行审核发布。

(2)数据质量管理

按照国家信息资源目录体系标准，建立覆盖全先政务的信息资源目录体系，建设全先统 一的信息资源管理中心，形成“物理分散、逻辑集中”信息资源管理模式；提高信息的交换 能力，支持跨委办局之间的信息共享和业务协同，提高全先公共服务和社会管理的水平。

数据质量管理系统的功能包括数据质量监控、数据质量评估、数据质量报告、数据质量 问题处理、数据质量知识库等功能。

数据质量监控：根据数据检验等配置的规则，对发现的数据质量异常情况进行告警和拓 扑呈现。主要包括源系统关键数据稽核、源系统维表稽核、实体数据检查、处理过程检查、 关键指标检查、告警管理、拓扑呈现和规则配置等功能。

数据质量评估：根据设定的评估方法对源接口基础数据质量评估和指标关联性分析，相 关到评估结果以作为系统质量改进的参考和依据。

数据质量报告：对数据质量管理各环节累积的各种信息进行汇总、梳理、统计和分析， 形成统计报告，主要包括：报告生成、报告发布、报告查询和报告归档。

数据质量问题处理：包括问题生成、问题分析、问题处理和问题总结。

数据质量知识库：在平台使用及运维过程中，由数据质量管理系统收集有关数据及过程 问题的处理经验总结，按关键字的形式进行索引和分类管理。

(3)业务建模

业务建模是构建用户接口或上层业务应用与基础数据之间的逻辑模型。业务对象和业务 分析模型在此实例化。应用服务层是生成并操作接收信息的业务规则和函数的集合。它们通 过业务规则(可以频繁更改)完成该任务，并由此被封装到在物理上与应用程序程序逻辑本 身相独立的组件中。

1)居民身份验证模型

居民身份验证模型用于居民个人电子档案建立及居民身份验证，是社区证明系统、业务 流转系统等具体业务系统的支撑服务。它可以通过身份证号验证居民身份，比对大数据平台 中人口信息库中是否具有该居民信息，进行相关业务办理，也可以通过居民生物特征信息(指 静脉信息)进行居民唯一身份验证，以此为依据办理相关业务。

2)数据综合模型

社区综合信息模型是网格化管理体系下动态信息获取的一个重要来源，社区综合信息采 集服务将网格内房屋信息、常住人口、暂住人口、特殊人群、紧急情况等信息，通过表单、 照片、空间定位等多种手段进行采集，并经2.5/3G/4G无线网络将所采集到的信息及时传送 到大数据平台，达到网格动态信息的快速更新、多方共享的目的。其主要功能包括:楼栋信息 采集、门牌信息采集、人员信息采集、事件上报、营业网点信息采集、重点场所信息采集、 紧急事件处理、代办需求处置、帮扶需求、城管事件上报及其他功能等。

3)城市运行体征动态模型

城市运行体征是一个城市在完善基础设施、保障能源及各种资源供给、特殊时期营造相 应氛围、提供安全应急保障等方面开展的工作。城市运行检测以获取城市运行全时段、全要 素信息为基础，进行常态城市运行态势的实时监控、综合评估、发展预测、协调会商、辅助 决策等，其目的是要增强城市管理工作的整体性、协调性、规范性，营造良好的城市环境， 以提升城市综合运营能力，提高城市建设服务管理水平。

4)城市数据综合分析模型

构建城市运行管理数学模型，实现对海量的交通数据、地理位置检测数据、环境数据、 医疗数据、政务数据、教育数据、公安数据的实时、全面、系统的数据采集，存储、分析、挖掘。智慧城市数据分析系统主要完成分析或决策模型的创建、发布和管理等功能，其主要使用对象是各部门业务人员。数据分析系统能够支持指标的数据分析和处理，包括基础信息 的统计分析、城市特征指数分析、宏观经济分析等功能。

5)移动电子政务模型

移动电子政务是指综合运用互联网、手机、固定电话等多种方式，使政府公务人员之间、 政府与公众之间可以随时随地实现相互间的信息传递，从而实现政府组织结构和工作流程的 优化重组，超越时间、空间和部门分割的制约，全方位地向社会提供优质、规范、透明的服 务。通过移动电子政务网上便民服务工程融合政府、民政、税务、工商、人力资源和社会保 障、住房和城乡建设等政府机构，为城市居民打造一个统一服务平台，方便百姓随时随地利 用各种方式进行政府业务查询、办理等。

四、运行支撑平台

(1)引擎。服务引擎主要为顶层应用系统的开发提供共性的服务组件，以减少应用系统 对于共性组件的重复采购，减少资源浪费，提高使用效率。服务引擎由手机短消息、即时通 信、电子邮件、视频通信、GIS空间分析、工作流、搜索、表单定制等服务组成。

(2)权限。权限管理是根据系统设置的安全规则或者安全策略，用户可以访问而且只能 访问自己被授权的资源。权限管理主要包括身份认证服务、单点登录服务和权限验证服务等 服务。

(3)监控。对于城市大数据中心，由于支撑了很多服务和应用，需要把分散在各个应用 系统中的监控功能统一管理，形成一套对城市大数据中心有效监控的措施。统一监控服务要 包含远程监控、本地监控、数据库空间监控、流程监控、负载监控、应用监控、报警通知和 监控展示等服务。

(4)接口。城市大数据平台应充分调动政府、企业、居民等多方力量共同运营、维护与 建设。在平台体系中政府起主导和方向性引导作用，为大数据平台提供政务权威数据和管理 方法；企业为平台提供创新的应用方式；居民为平台提供动态的、鲜活的社会动态数据。城 市大数据中心开放接口服务，是一套专门为这三个方面用户提供的应用服务，使其方便调用 与二次开发。

五、数据门户

通过数据门户建设，整合电子信息资源，建立以信息资源展示、二次开发服务为核心的 政务服务系统；基于海量数据，汇集统计分析、工作动态等决策信息，为各级领导提供决策 服务；拓展政务公开信息统一管理、公共服务、在线互动交流等功能，体现服务型数据中心 新形象、逐步扩展数据门户网站功能，建设综合性政务信息网站门户。数据门户主要包括资 源展示、在线查询和门户管理等功能。

(1)资源展示。信息资源展示服务主要负责对采集的体征数据、事件数据等按照一定的 查询条件统计的结果，在系统界面中以视频播放、列表、直方图、折线图、饼图、态势图、 体征日报等方式展示出来。也可以将空间化专题信息通过GIS系统更加形象具体的展现出来。 信息资源展示的内容包括空间信息地图展示、综合态势展示、事件展示、指标信息展示以及 统计结果展示。

(2)在线查询。随着数据的集中和整合系统可以提供如自然人口库基础信息查询、组织 单位库基础信息查询和地理信息库基础信息查询等专题查询。同时，也可以提供只有数据整 合才可以做到的部门数据关联查询和三库关联查询服务。

(3)门户管理。门户基本管理服务用于实现对大数据中心服务接口对外发布的管理以及 与各部门现有系统的对接；实现综合信息登记、审核和发布，应用系统集成单点登录以及门 户网站内容管理等功能。

应用服务层按企业、民生、政府三大业务领域规划了三类重点专项即面向企业服务、面 向民生服务、面向政府服务。其中，面向企业服务包括中小企业服务平台、产业经济运行监 控平台、智慧招商平台、智慧物流平台；面向民生服务包括市民一卡通、社区公共服务平台、 智慧医疗；面向政府服务包括行政审批平台、政务公开平台、领导决策支持系统、数字城管、 智慧环保、智慧交通、综合应急指挥平台和视频云支撑引擎。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制， 其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应 为等效的置换方式，都包含在本发明的保护范围之内。