数据中心系统平台（精选12篇）
数据中心系统平台 篇1
为了充分发挥数据集中存储管理与备份的优势, 人民银行广州分行省级数据中心启动省级数据中心自建系统数据集中存储备份平台 (以下简称“自建系统数据集中存储备份平台”) 建设, 逐步将自建系统的数据迁移到省级数据中心存储备份平台中, 依托集中存储系统与IBM磁带库, 进一步提高数据存储与备份管理的规范性、科学性。
一、自建系统数据集中存储备份平台建设
(一) 自建系统数据集中存储备份平台建设目标
自建系统数据集中存储备份平台的建设目标是根据技术环境特点, 将具备迁移条件的分行自建系统数据迁移到数据中心A区集中存储设备;通过A区备份服务器实施相应的备份策略管理, 将迁移后的生产数据备份到磁带库中;初步建立省级数据中心存储与备份管理技术规范, 满足省级数据中心现有系统及未来新建系统数据存储备份需求。
(二) 自建系统数据集中存储备份平台建设的背景
1. 省级数据中心集中存储备份平台状况
省级数据中心集中存储系统分为省级数据中心新上线系统区和账户、财务系统区2个部分。本次实施针对省级数据中心新上线系统区, 该区设备配置如图1所示。
(1) 联想HDS AMS2500磁盘阵列
联想HDS AMS2500磁盘阵列共配置38块300 GB磁盘 (10 T配置) , 其中1块磁盘用于热备, 不存储数据。按照6∶4比例分配, 总行统一推广系统使用该磁盘阵列上的22块硬盘, 剩余15块硬盘由省行自行使用。磁盘阵列前端8个端口, 分别属于2个控制器, 每控制器的第1至3个端口为总行统一推广系统使用, 第4个端口供省行使用。规划如图2所示。
(2) IBM TS3500磁带库
TS3500磁带库配置了6个驱动器和40 T磁带, 其中第1至4个驱动器和30 T磁带供总行统一推广的系统使用, 部署省级数据中心一期的数据备份。剩余2个驱动器和10 T磁带供省行自行使用。
(3) 博科32口光纤交换机
省级数据中心新上线系统区配备了博科32口光纤交换机。
2. 自建系统数据集中存储平台试点系统状况
本次集中存储备份平台实施选择省级数据中心自建系统执法检查系统 (LIAS) 及工资套改系统 (SCMS) 进行系统迁移。LIAS系统和SCMS系统应用服务器和数据库服务器均为X3650 PC Server, 数据库均为DB2数据库, 数据存储在PC Server的自带硬盘。目前数据库备份通过每天晚上执行在线备份脚本完成, 并复制到另一台PC实现异机备份。
(三) 存储区域规划与数据库应用整合规划
自建系统数据集中存储备份平台建设的核心内容是存储区域规划与数据库应用整合规划。我们使用联想HDS AMS2500磁盘阵列供省行自行使用的15块硬盘中的4块组成Raid 5的Raid Group, 作为迁移后自建系统数据库数据的存储区域。当有新的自建应用系统需要分配空间时, 在该Raid Group的862 G内未分配的空间予以分配, 且按照6∶3∶1的比例划分为LUN, 在LUN上创建对应的lv, 分别分配给数据、归档日志、活动日志使用。至于分配空间大小, 则考虑自建应用系统的实际存储需求。
迁移后的数据库应用将整合部署在专用的省级数据中心自建系统数据库服务器中, 该数据库服务器与省级数据中心存储平台连接。各应用数据库将在服务器的新建lv中建立。新建lv的命名如下:自建应用系统简称_data_4k, 自建应用系统简称_db_arclog, 自建应用系统简称_db_log。对应的mount point如下:/gddc/自建应用系统简称_dbdata, /gddc/自建应用系统简称_db_arclog, /gddc/自建应用系统简称_db_log。LIAS系统和SCMS系统初期均分配5 G空间, 具体情况如图3所示。表1描述了相应lv及mount point信息。
(四) 自建系统数据集中存储备份平台建设实施内容
在自建系统数据集中存储备份平台建设过程中, 主要进行了如下实施内容。
1. 实现自建系统服务器与集中存储系统及磁带库SAN组网配置
广州分行省级数据中心自建系统服务器原本没有连接省级数据中心A区集中存储, 需要拉一条光纤连接省级数据中心自建系统服务器和省级数据中心A区集中存储, 并在光纤交换机配置zone, 使得省级数据中心自建系统服务器可以识别省级数据中心A区集中存储以及磁带库。
2. 自建系统数据迁移的准备
在存储系统中建立分行数据保存区, 并在与之相连的省级数据中心自建系统服务器中创建对应逻辑卷, 为自建系统数据迁移做好准备。自建系统迁移需要将自建系统的数据存放在省级数据中心A区集中存储上, 为此需要按照总行存储划分规范, 在集中存储分配给分行自行使用的磁盘组中, 建立划分相应的LUN存放自建系统数据, 并在省级数据中心自建系统服务器上创建对应的逻辑卷组, 为自建系统数据迁移做好准备。
3. 迁移自建系统执法检查系统、工资套改系统的数据
在省级数据中心自建系统服务器上安装数据库管理系统DB2, 并创建相应实例db2admin, 通过db2move操作将执法检查系统、工资套改系统的数据从原有服务器迁移至与总行下发存储连接的服务器中, 实现自建系统数据向总行省级集中存储体系的迁移。
4. 备份执法检查系统、工资套改系统数据, 并进行备份可用性检查
在省级数据中心自建系统服务器安装netbackup软件并配置为media server, 以LAN-free模式实现对统一存储中自建系统数据的备份。利用netbackup管理客户端为执法检查系统、工资套改系统创建相互独立的逻辑磁带池, 并创建备份策略, 每日在线备份相关系统业务以及数据库日志。完成自建系统生产服务器数据磁带库备份实施后, 在备份服务器中安装netbackup客户端, 将备份数据在备份服务器中成功恢复, 实现异机数据恢复, 恢复来验证备份的有效性、可用性。
二、自建系统数据集中存储备份平台建设经验
(一) 自主探索与厂商远程技术支持服务相结合保证工程顺利开展
本次项目在实际过程中遇到了不少的困难, 其中既有netbackup无法备份的问题, 也有netbackup无法进行数据库恢复的问题, 通过自主思考探索, 及时总结自主实施过程中存在的问题, 并积极向厂商寻求电话远程支持, 起到事半功倍的效果。
(二) 安装netbackup服务器的经验
在cluster下安装netbackup服务器时, 如果使用服务地址, 则主机名需要填写/etc/hosts文件里配置的主机名, 不能填写执行hostname命令返回的主机名。
(三) Windows数据库迁移到aix数据库的经验
一是此次数据库迁移主要是在Windows执行db2look命令导出数据库定义脚本, 在Windows执行db2move命令导出数据, 然后在aix创建数据库后, 执行数据库定义脚本, 然后用db2move命令导入数据。
二是数据库定义脚本包含外键的定义时, 需要将数据库定义脚本拆分为两部分, 将外键定义的脚本放到执行db2move命令导入数据之后执行。
三是数据库定义脚本包含identity字段的表定义时, 建表时应该去除identity属性, 在执行db2move命令导入数据之后, 再恢复identity属性, 并将identity起始值设为当前该字段最大值+1。
(四) 执行db2恢复的经验
一是执行数据库恢复的时候可能遇到代码页问题, 可能需要在GBK代码页和ISO8859-1代码页之间进行转换。当执行db2 RESTORE DATABASE process LOAD/usr/openv/netbackup/bin/nbdb2.sl64命令时提示SQL1205N The code page“1386”and/or territory code“1”that has been specified is not valid, 则执行db2set DB2CODEPAGE=819;db2 terminate命令。
二是异机恢复时备机主机和恢复主机间通信需要得到master server的支持。具体是异机恢复前需要在master server执行touch/usr/openv/netbackup/db/altnames No.Restrictions命令。
三是异机恢复时恢复主机需要备份主机备份时用到的参数信息, 包括备份主机名, 备份策略, 备份时间安排等信息。具体是异机恢复:需要到恢复主机/usr openv/netbackup/bin下执行./db2_config, 填写数据库用户home目录, 如db2admin用户为/home/db2admin, 到home目录下执行chmod 777 db2.conf, 参考增加如下信息:
DATABASE process--数据库名
OBJECTTYPE DATABASE
POLICY Self Build_DB_DB2ADMIN_1D--备份策略
SCHEDULE Self Build_DB_DB2ADMIN_1D_Default--备份SCHEDULE
CLIENT_NAME db_svr--备份主机名
ENDOPER
四是执行前滚操作时, 需要将备份主机的对应日志文件复制到恢复主机的日志目录。具体是执行db2rollforward db process to end of logs and stop命令时, 提示SQL4970N LOG日志 (如S0000038.LOG) 挂起报错时, 需在备份主机日志目录或归档日志目录查找相应的报错文件S0000038.LOG, 替换当前数据库日志目录的S0000038.LOG文件。当前数据库日志目录通过db2 ge db cfg for process得到。
五是连接数据库时候可能遇到代码页问题, 可能需要在GBK代码页和ISO8859-1代码页之间进行转换。执行db2 connect to process命令时, 提示SQL0332N CODEPAGE错误, 则执行db2se DB2CODEPAGE=1386, db2 terminate命令。
(五) 要遵守总行对于省级数据中心设备的使用要求
本次项目中涉及到省级数据中心A区存储、光纤交换机、磁带机, 总行关于省级数据中心A区存储哪些盘、光纤交换机哪几个口、磁带机哪些端口归省级数据中心自建系统使用有明确的说明, 在项目实施过程中必须遵守这些规范。
(六) 要有良好的规划
自建系统数据集中存储备份平台建设是一个长期的过程, 自建系统需要逐步迁移到该平台上。众多的系统放到该平台上, 对于存储划分, vg, lv, fs的创建需要遵循一定的规范, 避免随意性。
数据中心系统平台 篇2
社会的稳定离不开公安的帮助，现代化社会已经进入高速发展的时期，为了方便公安的便利，信访人员管控、大数据平台、分析研判等等一系列系统也就孕育而生。重点信访人员管控系统开发,公安大数据平台搭建咨询汪顾问。
信访系统为信访群众提供了快捷、透明的来信来访、网上信访、视频信访、电话信访、短信信访、领导信箱、移动信访、信访微博、信访微信、信访论坛、民意征集、网上评议等诉求投诉、民意表达渠道，让信访人可以非常方便、便捷的选择任一信访投诉方式表达自己的诉求。
汪顾问：13/82//311/579//1而当前，各行业数据爆发性增长，急需转变数据处理模式。在公共安全领域，治安系统、智能交通视频数据呈井喷式增长，已显现出行业大数据的典型特征。公安系统开发
大数据平台的功能主要是：
围绕人、车、物、网、像五要素，整合公安业务数据、社会数据等资源，分析挖掘数据价值，构建数据整合、信息共享、数据研判于一体的人工智能大数据管控平台。
个人全息档案、社交关系分析、活动碰撞分析、案件团伙分析、积分预警、身份轨迹布控等。通过全方面的体系架构，实现从数据汇聚、数据清洗、存储、计算，到数据碰撞、分析、研判、挖掘，最后到业务应用，形成一体化的统一、高效、便捷大数据平台。
源中瑞科技有限公司拥有智慧城市、智慧公安、互联网金融三大事业部，在对各种智慧类系统开发方面有着一定的经验，在全国许多地区已有多处落地，公司现今拥有近200位研发人员，通过不断创新打造出属于我们的定制化不开源系统，与市面上系统都有一定的差异，从而打造出自己的品牌。
数据中心系统平台 篇3
网格化城市管理数据普查采用的传统方法是将所有城市部件、地址兴趣点参照物、区界、街道范围线、监督员责任区范围线、社区线、万米单元网格等数据套印在比例为1∶500地形图中，监督员手拿地图到现场审核，将变化的数据在地图上标注和在表格中进行登记。
能否将这些数据同样装在多普达D600“城管通”手机中，监督员利用多普达D600“城管通”手机在平时工作中随时发现情况随时上报呢？
(一) 多普达D600“城管通”手机端数据容量及工作效率的可行性分析
北京市东城区共有574幅比例为1∶500地形图，一幅图（已由专业公司保密处理）容量大约在0.5M-1M，574幅地形图矢量数据大约有280M，处理压缩后也有近220M，加上比例为1∶500地形图是保密资料也不允许安装在“城管通”手机中。显然依照目前手机的配置，一是无法将这么巨大的数据装入手机使用；二是不符合保密要求。
我们通过对这些资料进行认真细致研究，从现有的资料中抽取需要的要素，有效地解决了上述问题，具体方法如下：
一是依照传统基础数据普查资料制作了如下专题图层，在“城管通”手机端再现了“普查用的地图”。（1）依据最新的地形图资料，制作了东城区现状道路分布图；（2）依据最新的地形图资料，制作了东城区平房院落范围线和楼房范围线分布图；（3）东城区界范围线分布图；（4）东城区10个街道分布图；（5）东城区115个社区分布图；（6）91个监督员责任区分布图；（7）东城区1577个万米单元网格图；（8）东城区近30万个城市部件分布图、3.3万多个地址兴趣点参照物数据分布图。以上八类原始矢量数据共有194.7M。
同时采取以下处理手段：（1）利用ArcGIS的数据简化工具对线、面数据进行抽稀简化；（2）是利用数据转换工具，采用压缩技术将Shape格式的原始数据转换为手机端专用的数据格式，在不影响数据质量的情况下，减少冗余数据，进而减少数据的容量。经专业技术人员的处理，目前手机中八层数据容量大约只有18M。
二是更换“城管通”手机安装数据的方式。按照监督员所属分队（街道）只安装本街道的地图，只显示本责任区内的所有城市部件、地址兴趣点参照物。目前10个街道中“城管通”手机端最大数据量是和平里分队，有6.25M, 最小的是朝阳门分队，有5.09M，完全满足工作使用要求，不会影响“城管通”手机的正常使用。
三是在开发“城管通”手机端程序中通过优化的显示控件、分图库和视野的逐级显示方式，提高了地图操作的响应速度，减少了内存的占用和等待时间，保障了“城管通”手机的工作效率。
四是多普达D600“城管通”手机在Windows Mobile5.0操作系统中增加了Flash的容量，减少RAM的容量，增加了微硬盘，解决了系统存储空间小的问题，为开发数据动态更新功能提供了基础保障。
(二)“城管通”手机端采集数据精度可行性分析
依据中华人民共和国城镇建设行业标准《城市市政监管信息系统管理部件和事件分类、编码及数据要求》（CJ/T214—2007）中的部件空间数据定位精度要求：
（1）空间位置或边界明确的部件，如井盖、灯等，中误差≤±0.5m，在比例为1∶500地形图中误差≤±0.1mm；
（2）空间位置或边界较明确的部件，如亭、广告牌、果皮箱等，中误差≤±1.0m，在比例为1∶500地形图中误差≤±0.2mm；
（3）空间位置概略表达的部件，如桥梁、停车场等，中误差≤±10.0m，在比例为1∶500地形图中误差≤±2.0mm。
目前东城区使用的多普达D600“城管通”手机，配置一块2.8英寸65K色的TFT屏幕，有效显示尺寸是4.5cm×6cm，分辨率为QVGA240×320。
在数据动态更新系统的程序设计中，要求监督员使用“城管通”手机采集数据时的视野控制在30〜50m之内进行。对城市部件、地址兴趣点参照物密集地区可放大到30m视野采集，稀疏地区可放大到50m视野内进行采集。此时“城管通”手机端屏幕显示的比例尺大致为1∶700〜1∶1100;以“城管通”手机中的“再现的普查图”作为基础，以显示的城市部件、地址兴趣点参照物作为依据，采集相应的变更信息，从理论上讲基本可以满足数据采集精度要求。
(三)监督员日常巡视发现变化的城市部件、地址兴趣点参照物，及时上报的可行性分析
一是由于目前在岗的监督员大多已从事过数据普查工作，对城市部（事）件分类较为清楚，加上每年例行的业务培训、业务练兵，监督员业务能力应该有了很大提高。
二是从2008年开始，每次大规模数据更新完成后，基于监督员责任区建立了城市部件、地址兴趣点参照物的数据档案。
两者完美结合，为监督员最终能够正确使用动态数据更新系统更新城市部件等数据提供了前提和条件。
（四）维护公司技术实力雄厚，技术力量能够满足用户提出的各项功能要求
自2008年底，东城区采用了无线多媒体信息采集系统（“城管通”）和信息化城市管理系统一体化的搭建方式对原有系统进行升级改造。目前东城区的“城管通”与信息化城市管理系统均由北京数字政通公司开发和维护。该公司拥有将基于无线技术的移动应用系统与政务管理系统有机结合的开发与实践经验，技术力量能够满足用户提出的各项功能要求。
综上所述，基于信息化城市管理系统和多普达D600“城管通”手机端开发基础数据动态更新系统的基础条件、技术力量均已具备。
二、信息化城市管理基础数据动态更新系统
（一）基础数据动态更新系统的架构
基础数据“动态更新”系统是基于多普达D600“城管通”手机中Windows Mobile5.0操作系统开发的功能模块，通过中国移动通信网上传到“城管通”系统服务器，再通过政务专网上传到信息化城管系统服务器中，系统管理员定期导出监督员通过动态更新系统上报的数据，转交专业测绘公司进行后期的数据制作。见图1。
运用动态数据更新系统上报更新信息是不需要信息化城市管理系统人工干预，也不会影响信息化城市管理系统的正常业务办理。
（二）基础数据动态更新系统采用的技术
1.采用适应网络发展的三层体系结构
数据层、业务逻辑层和表现层。
采用DNA体系三层结构，具有如下优点：
（1）实现了分布式数据处理，能完全利用平台的灵活性、Internet的优势和通讯能力；（2）在一个共享的中间层封装了商业规则；（3）使用标准的数据访问接口，跟所使用的数据库无关；（4）中间层的业务逻辑采用组件技术开发，灵活性大，易于移植，可以快速开发、部署应用程序，不需要对开发者进行重新培训，降低开发者必须写的代码；（5）各模块皆具有互操作能力，可以方便地向现有系统增加功能，符合开放的协议与标准，可以集成其他厂商的产品。
2.采用技术领先的J2EE框架
Java 2平台企业版（Java 2 Platform Enterprise Edition，J2EE）是一种利用Java 2平台来简化诸多与多级企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如“编写一次、到处运行”的特性，方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise Java Beans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。
3.采用面向对象的C#
C#作为微软自主开发的语言，除了继承了C与C++的所有优点特性，更具有在 Windows 操作系统下的高效性，它不但适用于各种操作系统，并且能与 Windows 紧密的结合在一起。
（三）系统使用方式、在多普达D600手机中实现方法及数据更新成果展示
1.监督员使用动态数据系统方式
监督员在平时巡视过程中，发现新增、删除、变更的城市部件、地址兴趣点参照物等情况，通过“城管通”中的“动态数据”更新系统将变更信息及时上报信息化城管系统即可。
2.动态更新系统在多普达D600手机中实现方法
在“城管通”手机开发动态更新系统时，充分考虑了监督员的工作习惯，数据更新系统上报模式与正常工作时的问题上报基本类似，操作简单、通俗易懂。
具体操作步骤：点击“动态更新”→选择类别（城市部件、地址兴趣点参照物）→选择操作内容（新增、变更、删除）→地图（位置）选择、照片选择、录音选择、问题描述→点击“发送”即可。
3.信息化城市管理系统中导出的数据更新成果展示
系统管理员定期从信息化城市管理系统中导出监督员上报的数据更新成果，主要内容有：
（1）动态更新成果明细（以城市部件为例），含：任务号、类别、变更类型、监督员、大类、小类、部件编码、X（Y）轴坐标、街道、社区、万米单元网格号、问题描述、上报时间。
（2）多媒体信息目录，内含全部监督员上报的任务号，每个任务号内含：上报问题的照片、一个录音文件、一张含有上报问题定位的地图。
三、基础数据动态更新系统测试情况分析
2009年7月底、11月底，我们先后两次组织监督员进行了基础数据动态更新系统现场测试，主要存在如下问题：一是监督员上报问题时的视野过大，影响定位的精度和数据的准确性；二是建议增加院落范围线和楼房范围线，为监督员上报问题定位时提供参照依据，进一步确保监督员上报问题时定位的精确性。
2009年12月底，针对两次测试情况，系统开发组从动态数据更新程序和基础数据制作两个方面对系统进行了优化和补充，改进了测试发现的问题。
2010年1月中旬，又组织监督员进行以上报新增、删除“监控电子眼”的测试，从测试结果来看，基本符合要求，达到了预期的效果。
四、基础数据动态更新系统前景分析
研发基础数据动态更新系统，这是东城区进行基础数据更新机制新的探索，是对传统数据更新方式有益的补充，对比常态的基础数据更新有明显的优点：
一是方便快捷；二是周期短，方式灵活，可以根据需要随时进行更新；三是省时省力，减轻了监督员的工作强度；四是克服了部分监督员由于业务不熟练，导致普查时城市部件分类错误问题的发生；五是可以用此功能对信息化城市管理系统拓展的项目（如：酒类经营场所、污染源等数据）进行实时的动态数据更新。
总之，动态数据更新系统有良好的发展前景。
五、基础数据动态更新系统存在的不足
由于基础数据动态更新系统是刚研发并正式投入运用的，其存在一些问题待今后加以改进。比如：
一是目前开发的动态数据更新系统对点状城市部件、地址兴趣点参照物定位毫无问题，但对线状、面状信息采集就有一定的局限性，待今后版本加以改进。
二是基础数据动态更新系统，对地形变化大（拆迁等）的地区有一定的局限性，需要用常规方法进行测量和外业调绘。
数据中心系统平台 篇4
一、数据中心系统平台在构建初期存在的问题及对策
广电宽带业务在发展的最初, 很少被社会接受和认可, 它的用户只有几千家, 为客户提供的产品类型也只有数据业务一种, 因其产品类型非常单一、网络拓扑简单, 因此, 初期的广电宽带数据中心系统平台没有很好的安全性, 也没有很强的拓展性, 并且存在着许多问题。
1.1硬件系统方面存在的问题
在广电宽带数据中心系统平台构建初期主要采用的是DHCP硬件系统, 它的优点是系统负载能力较好, 磁盘阵列较为优质。但是鉴于前端机房较多, 出于对网络IP的整体管理考虑, 也为了能够减少服务器的承载量, 人们架设了很多台DHCP服务器, 但是因为并没有相应的建立起有效地服务器系统的热冗余备份机制, 所以当一台DHCP服务器出现故障时, 也会致使其他所有的服务器也一同中断, 大大的降低了工作效率, 同时对服务器中心数据系统的安全也产生了严重的威胁, 造成了不小的安全隐患。
1.2软件系统方面存在的问题
在广电宽带数据中心系统构建初期服务器的软件一般采用Windows操作系统或者Linux操作系统, 但是Windows和Linux操作系统都没有相应的冗余备份机制, 因此不能很好的保障技术安全。并且因为它对用户承载数量的制约, 不能大规模的开展业务, 因此存在很多问题。
1.3广电宽带数据中心系统平台构建初期产品支撑方面存在的问题
广电宽带数据中心系统平台在构建初期, 并没有正规的宽带运营支撑系统, 因此不能做到多元化的产品业务, 而只能在某个业务流程环节中进行不同业务的纵向整合[1]。
二、对如何优化数据中心系统提出的几点建议
2.1努力建立起硬件服务器系统的冗余备份机制
要想解决数据中心系统平台存在的种种问题, 最为有效地方式是建立一个数据中心系统的冗余备份机制, 也就是说要有一台能够统管其下的主服务器, 在进行数据业务传输时通过主服务器向各个备份服务器发送指令, 从而达到就算有个别机器无法正常工作也不会影响到全体的目的。
2.2对软件系统进行优化和升级
软件系统在建设初期, 存在着承再能力过小, 不能很好的和广电宽带用户的大量增长进行应对的缺陷。因此对软件系统进行优化升级, 提高其对于用户数量大幅度上升的承载能力, 拓展其基本的能力, 并且完善和强化它的数据接口功能是非常必要的。只有这样, 才能在满足用户需求的同时提高数据中心系统平台的安全可靠性, 保证用户对广电宽带业务的信任[2]。
2.3构架优化的网络平台
在广电宽带的构建初期, 无论采用的是那种服务系统, 它们的结构都是单路的结构。这样的网络结构, 十分不利于网络正常的安全运作, 因为如果路由端口发生事故, 那么整个网络系统都会陷于瘫痪的境地[3]。
三、结束语
伴随着广电宽带网络用户数量的稳步增长, 广电宽带集团也逐步发展壮大, 成为了极具影响力的大品牌。广电宽带业务也为人们的提供了更加多样和人性化的服务, 便利了人们生活的同时也使得自身得到了长足的发展, 可谓一举两得。但是在这个竞争日益激烈的社会中要想保持稳定的发展, 广电运营商必须在现有基础上提升广电网络的安全性和可靠性, 建立起更为完善的数据中心系统平台。从而才能实现与电信运营商实力较量的胜利。
参考文献
[1]翁复川.梅洪涛.DHCP服务在宽带网络运营中的应用[J].电信科学, 2013, 12 (8) :22-43
[2]朱迅.杨丽波.利用DHCP中继代理实现多子网环境中的IP地址统一管理[J].网络安全技术与应用, 2009, 25 (13) :75-88
数据中心系统平台 篇5
大比例尺地形图交互式综合系统数据库平台的建立
在论述交互式综合环境研究的`重要意义及大比例尺地形图特点的基础上,采用人机协同的地图缩编方式,将复杂的地图综合过程分解,合理地进行人机分工,设计与实现了大比例尺地形图交互式综合系统的数据库管理平台.实践证明,利用该数据库平台建立的综合系统适用于人机协同的作业方式,可以顺利地、交互式地完成地图缩编工作,减轻了作业强度,提高了作业精度.
作 者：蔡忠亮 杜清运 毋河海 邬国锋 作者单位：武汉大学资源与环境科学学院,武汉市珞喻路129号,430079刊 名：武汉大学学报(信息科学版) ISTIC EI PKU英文刊名：GEOMATICS AND INFORMATION SCIENCE OF WUHAN UNIVERSITY年，卷(期)：27(3)分类号：P283.1 TP311.12 P283.7关键词：大比例尺地形图 交互式综合 数据库平台
数据平台也是关系平台 篇6
热闹背后，一个值得玩味的事实是，什么撬动了北京奥运会尚不能驱动的全民跑步热潮呢？如果细致分析一下跑步者的行为，也许可以发现其中真正变革的因素——今天的跑步已经从单纯的运动过程，变成了一次社会化内容的创造过程。跑步app、可穿戴设备的大量使用，让跑步过程可以被数据量化；移动互联网和社交媒体平台，让跑者可以随心所欲地发布自己的跑步体验，与其他跑者状态连接在一起，创造新的沟通体验，改变着跑步参与深度。这是一次属于跑步的科技革命，注定会改变体育品牌乃至更多领域的格局。
追溯这场运动体验科技革命的起源，体育用品行业统治者耐克在其中扮演着关键的角色。从Nike+iPod、Nike+系列app，到FuelBand，再到最新的Nike+ RunClub公众账号，Nike+不仅构建了相对完善的运动体验平台，同时也聚集了以千万计数的粉丝圈子群体，这个庞大的数字运动王国，正在成为互联网时代耐克真正的核心发展原动力。
但在竞争激烈的体育用品市场，耐克的领跑者地位并不那么巩固。miCoach就是老对手阿迪达斯正面迎击Nike+的产品，其一上市便以一如既往的严谨专业赢得了口碑。紧随其后，阿迪达斯推出基于miCoach的智能手表系列Smart Run Watch，引入腕部心率传感器，再将专业水平和使用便利性提升了一个等级，以后发先至的策略直指专业运动消费群体。
此外，国内的咕咚、跑步控，国际领域的runtastic、Endomondo Sports Tracker等众多运动品牌，也在寻求着自己在运动数字化时代的解决方案，寻求着自己在运动数字化时代的一席之地。从app开始，到推出专业领域的产品延展（例如运动手表）。“GPS+地图”，这种没有太多技术门槛的跑步app体系反而对用户体验的专注度提出了更高的要求。
Nike+的发展脉络，显示了耐克从曾经的科技创新一枝独秀，到产品同质化过程的“平庸化”趋势。其表明，建立并保持技术门槛的难度越来越高，希望单靠某种概念、技术形成长期优势变得日益困难，甚至可以预言，“一招鲜”在运动数字化时代已经没有机会，而要真正让Nike+获得市场，必须靠专注运动体验本身和聚合圈子双轮驱动。
从曾经消费者对于运动时音乐的需求，到更年轻一代消费者对于可视化数据体验和智能便携设备的广泛应用，Nike+每次的新产品都针对消费者核心需求，并将其做到极致。相对于更专业的产品，其实只需要一个足够打动消费者的产品利益点就解决问题了。
Nike+和追随者的另一个思考则在于这种平台是否有着达成业绩提升的驱动作用。从目前情况来看，与其说是通过运动数字化来促进产品销售，不如说其开创了运动数字化产品，进而改变了人们对于运动体验的方式。
幸运的是，和对手们相比，注册会员超过1800万的线上社区，营收贡献额超过篮球的跑鞋生意，还有无数消费者心中的第一购买选择，让Nike+在这场竞争中至少有一个身位的领先优势。同时，Nike+也已经不知不觉进入了一个更大的竞争领域——互联网。
只是正如前面所说，技术门槛的建立太难，而被填平的速度又足够快，所以不见得有最好、最极致的运动体验，但却可以存在让多数跑者共同分享甚至认同的运动体验。而恰巧移动互联网和社交媒体的圈子效应为其提供了最好的平台，基于大量的自我内容创造与分享，运动生活的数字化分享则成为这一切的核心。因此，也就有了Nike+各类产品上诸多旨在创造分享内容的积极拓展。
借力于引领科技潮流的这段短暂时间，Nike+所积累的不仅仅是关于产品业绩方面的成长，更为重要的是数以千万计的粉丝和不计其数的粉丝圈子，这种“强关系”所构建的壁垒足以让任何革命性科技在短期之内黯然失色。
[编辑 周云成]
故障信息系统中数据平台技术应用 篇7
本文分析了电网继电保护故障信息系统的数据特性, 基于电力系统中各故障信息管理系统数据多而复杂的现状, 围绕基础数据模型、实时数据模型、录波数据模型设计了基础数据平台, 实现了基础数据共享、快速提取有效数据、简化数据复杂程度、现有资源得以充分利用。
1 数据存储概述
(1) 现状。目前调度主站端存在众多功能复杂的系统, 如数据采集与监视控制 (SCADA) 系统、能量管理系统 (EMS) 等, 不但包含海量数据, 且系统间也没有直接联系, 增大了结构的复杂程度, 造成了设备资源的严重浪费。 (2) 方向。为提高电网继电保护装置的运行、管理及故障分析水平, 各电力调度部门广泛建设故障信息管理系统, 将装置的故障信息传送到调度中心, 提高了电网调度系统的信息化、智能化水平, 本文提出一种新的故障信息管理系统建设模式, 即在一个数据平台的基础上, 实现继电保护信息系统与其他系统之间数据信息的自由交换, 不但简化了系统的整体结构, 同时也节省了资源, 具有较高的实用价值。
2 数据平台设计
数据平台是故障信息系统中实时监测与分析系统的核心, 具有动态性、时效性、可用性。它采用分布式结构设计, 软件设计基于C++开发语言、实时库技术, 运行稳定可靠、易于维护。
2.1 故障信息系统基础模型
故障信息系统中的基础模型数据, 是故障系统分析故障的基础, 所有的分析必须基于基础模型数据, 因此必须保证该部分数据能从数据平台中方便、快速、准确的抽取。
由于各个系统中对于设备的命名差异严重, 因此有必要先对模型数据编码进行编码, 通过统筹考虑电网模型的统一管理和充分共享, 按照设备统一命名、分布存储、属性有效关联、信息充分共享、维护科学分工的原则, 实现电网模型的统一管理和充分共享, 并且提供模型维护功能, 包括模型的查询和抽取、模型的校验和比较和模型访问等功能。模型管理包括横向模型管理和纵向模型管理, 以满足系统间的交互需要。
电网运行时使用资源信息大致可分为电网设备及参数、电网运行数据、调度业务数据三个方面, 其中:a) 电网设备及参数包括:一、二次设备以及与设备相关技术参数, 设备模型数据是调度一体化运行智能系统标准代码的核心;b) 电网运行数据主要包括电网运行的量测、水情、煤情和脱硫监测等各类采集信息;c) 调度业务数据主要包括调度各专业的业务工作及管理信息, 如计划、检修等。运行数据和大多数业务数据通常与电网设备有关联。
通过对系统中各一、二次设备及其它相关参数进行统一编码, 方便系统中进行交互。
数据平台基础数据参数编码原则如图1所示。
编码完成后数据平台将该部分数据初始化进数据平台自身的实时库中, 通过数据平台提供的各种实时库访问接口, 各个应用能方便快捷的进行数据调取, 并且数据平台提供方便的模型更新服务实时更新实时库中的模型信息。
2.2 故障信息系统实时数据
在电网运行中, 由于外界环境的多变, 随时可能是会产生故障, 通过采集检测装置的信息, 能够实时获取到电力设备的运行数据, 该部分数据由于定时采集, 会多而且难以解析, 但故障的分析又必须通过电力设备运行时数据的采集才能分析出电力设备的运行状况, 为了满足这部分数据的需要, 在数据平台中专门设计存放最新数据的断面区域。
对于每一个时刻从所有装置中采集的数据被定义为信息断面, 在数据平台中通过预先配置好的断面矩阵, 数据平台进行初始化, 从装置采集上来的断面按照预先的设定刷新到实时数据断面相应的区域。
实时数据断面配置结构如图2所示。
2.3 故障信息系统录波数据
伴随这电网故障的产生, 各种电力一次设备监测装置都会对电力故障产生的故障录制波形, 通过对录波曲线的绘制能够直观表现出电力故障发生的一个完整的过程, 因此故障录波对于研究故障产生的过程非常重要, 数据平台首先要将所有的波形信息以索引的方式记录在索引库中, 包含装置的编号 (已编码) 、录波存放的物理路径、录波产生的时间等信息, 方便外界的调阅。
同时, 随着时间的推移, 故障录波数据在磁盘上存放越来越多, 但实际上有很多是无用的过期数据, 对于这些数据可能从没有被调阅或者很少被调阅, 数据平台对于该部分数据采取清理或压缩的逻辑 (可通过平台的设置界面进行设置) , 节省磁盘空间消耗, 充分利用有限的硬件资源。
3 结语
国内保护信息故障信息系统从2000年初开始建设, 到目前为止已经过去十年, 部分早期建设的系统受当时各种技术条件限制, 已经无法满足当前发展需要, 系统的升级换代也迫在眉睫。数据平台作为本系统研发设计和实际应用中的核心之一, 涉及许多不同应用间的交互的接口。在传统电网向智能电网过渡之际, 必须既要保证原有标准的可用性, 同时也要着眼未来的发展性。
本文给出的故障信息系统数据平台的设计与实现方式, 解决了目前存在的数据冗余、故障信息数据访问效率低下、应用各种操作系统、提高开发效率等关键技术问题, 能够满足过渡阶段的新一代故障信息系统数据快速采集、分析和系统间数据交互的功能要求。
摘要：本文指出电网继电保护装置产生的数据是电网继电保护故障信息系统的基本数据来源, 并对电力故障数据进行分析, 通过分析得出电力故障的发生点、发生时间、发生过程等信息, 为提高电网运行安全稳定运行提供有力的保障, 基于电力系统中各故障信息管理系统数据多而复杂的现状, 设计了基础数据平台, 实现了基础数据共享、快速提取有效数据、简化数据复杂程度、现有资源得以充分利用。
关键词：电力故障信息,故障信息系统,数据存储,数据平台
参考文献
[1]王梅义.电网继电保护应用[M].北京:中国电力出版社, 1999.
数据中心系统平台 篇8
“民以食为天, 食以安为先”。食品安全是人类生存和健康的第一屏障, 关系国计民生, 一直是备受社会关注的热点问题。近年来, 我国各级政府针对食品安全问题开展了大量工作, 取得了一定成效, 但是也应看到, 我国的食品安全事故屡屡发生, 有效地加强食品安全监管在当前已显得尤为紧迫。食品安全问题不仅关系到广大人民群众身体健康和生命安全, 关系到社会经济发展和社会的和谐稳定, 还关系到公民对社会和政府的信赖问题[1]。
食品安全监管系统是从城市食品安全综合协调和监督的高度出发, 配合食品的市场准入管理、日常检测、食品安全公示等相关制度和规范, 从食品准入备案、检测监管、案件管理、专项整治、联合执法、事件管理、投诉分流反馈、食品安全公示、统计分析等环节入手, 进行跨部门的信息整合、协同监管以及食品安全各类专题统计分析, 为领导决策提供各类业务数据和统计分析数据, 并为社会大众和企业提供食品安全相关服务。其中的关键需求就是要实现跨越各个监管部门 (卫生、食品药品监督、工商、质监、商务、农业、食安办等部门) 的食品安全数据交换和共享, 实现业务协同和全程监管。
1 食品安全监管系统概述
食品安全监管系统业务模型如图1所示, 主要包括以下3个方面的内容:
(1) 建立数据采集平台, 从食品检测、食品生产经营市场主体备案、食品安全标准以及检测车检测信息, 实现对各种检测信息、备案数据、法律法规等信息的录入和管理, 实现在线的业务受理和数据处理。
(2) 建立跨多个横向职能部门的协同监管平台。食品安全涉及到食品在商品流通领域的各个环节, 包括工商、卫生、质监、药监、农业、粮食、畜牧、城管等多个职能部门。而各个环节中的政府职能监管部门不同, 要加强对食品安全卫生的监督管理, 必须考虑与横向职能部门之间的信息联动, 获取和交换横向部门的食品检测信息和食品生产经营市场主体的监管信息, 实现食品安全监管数据的共享和整合, 实现跨部门的食品安全综合监督和协调以及食品安全业务联动。
(3) 建立食品安全公众服务平台。除提供新闻通告、政务公开、政策法规外, 更重要的是提供食品检测信息公示、黑名单公示、暂停销售食品公示、退出市场食品公示、名优食品公示、名优企业公示、食品和食品生产经营市场主体备案信息查询、网上投诉受理和反馈, 建立和食品消费者之间畅通的信息交流渠道。
由图1可见, 数据交换平台处于食品安全协同业务层和政府部门内部业务层面之间, 属于承上启下的重要节点, 也是系统成败的关键所在。
2 数据交换平台设计与实现
2.1 平台功能设计
数据交换平台采用基于东方通[2]可靠消息传输技术的消息中间件技术和具有集成适配器框架及组件库的集成中间件技术实现目录管理与服务、信息交换、安全管理、平台管理、基础构件管理等功能, 平台功能模块构成如图2所示。
(1) 目录管理与服务:主要包括元数据采集、注册、发布、查询等, 目录注册、发布、查询、维护、导航等功能。
(2) 信息交换:主要包括数据适配、交换规则配置、数据传输、交换过程监控等功能。
(3) 安全管理:主要包括用户管理、统一认证、分级授权、单点登录、数据加解密、数字签名等功能。
(4) 基础构件管理:主要包括用于支撑平台核心服务的基础构件, 以及平台工作对象能够直接复用的一些公用的基础功能构件, 如文件交换构件、数据库交换构件、导航树构件、单点登录构件等。
(5) 平台管理:通过平台配置管理、平台安全管理、平台部署管理、平台监控管理、平台运行状态管理等管理机制, 为用户提供各种配置与管理平台的功能, 确保平台的正常运行。
2.2 核心数据处理功能
核心数据处理功能主要实现基本的数据加工处理功能, 包括:采集、清洗、比对、增量、加载等。
2.2.1 数据采集
从各种数据源中抽取数据, 形成SDO[3]数据对象, 并写入缓冲。根据数据源的不同分成以下几类进行设计:
(1) 从文件中抽取。各职能部门将数据文件上报到前置机内, 程序从前置机内读取文件, 支持text文件与excel文件:①text文件一般是由业务数据库直接导出的, 要求文件内每行数据的每列之间以制表符分割, 用平台中的文件源组件FileSource可直接读取text文件形成SDO对象;②excel文件一般是由手工录入的, 数据内容的格式多变, 如有的文件第一行是大标题, 有的则是列名, 有的文件的多个“sheet”中有数据, 有的文件则只有一个“sheet”有数据, 也就是说需要抽取的数据有可能是从文件内的第X行的第X列开始, 也有可能只需要抽取文件中的某几列数据, 或来自文件内的不同的“sheet”。因为手工录入ex-cel文件内的数据格式存在一定的复杂性, 所以采用xml文件作为统一的读取excel文件内数据的接口, 先根据excel文件的内容配置一个xml文件, 再用平台中的文件源组件FileSource读取xml接口文件形成SDO数据对象, 然后再由excel解析组件从文件内抽取数据形成SDO数据对象。excel解析组件需要继承平台提供的组件扩展抽象类SimpleProcess编码实现。
(2) 从数据库中抽取。从部门生产库中抽取数据, 该方式分为两种情况:①前置机可以直接联到部门生产库, 并允许在部门生产库内建立触发器。这种情况下, 通过平台对生产库内需要抽取的表建立导出组件, 导出组件就是基于触发器来运作的, 在前置机内装上Oracle数据库, 并建立需要抽取的表的副本, 然后建立导入组件, 接收由导出组件抽取的部门生产库的所需数据到前置机的相同表内;②前置机不能直接联部门生产库, 只能通过网闸定时访问。这种情况下, 在前置机装上Oracle数据库, 并根据需要抽取的表建立物化视图与副本表, 在确定的某个时间段, 对物化视图进行查询, 得出全量的结果集A, 然后再查询对应的副本表得出全量结果集B, 再通过A-B与B-A找出增量更新对应的副本表。用平台对所有副本表建立导出组件, 抽取每次更新所产生的增量数据。
2.2.2 数据清洗转换
源数据被采集后就形成了SDO数据对象, 第二步即要将数据对象解析, 并对数据的某些关键字段进行筛选、过滤以及转换, 这些关键字段有身份证、组织机构代码、部门编号等, 还有一些需要根据部门的业务情况而定, 而有些部门并没有提供此类关键信息数据, 因此在程序处理时, 需要灵活的配置支持上述情况。所以组件需要继承中间件平台提供的组件扩展抽象类SimpleProcess编码实现。关键类中要求添加rulse这一属性来接收由清洗转换组件传递进来的一组用来标明关键信息的参数, 以达到需要对什么关键字段进行过滤、转换时, 在清洗转换组件中配置该字段的名称即可的目的。
2.2.3 数据比对
部门个人数据、企业数据与权威部门 (工商、质监、卫生) 数据进行比对, 个人数据需要对身份证进行比对, 而企业数据需要对组织机构代码或企业名称进行比对。此功能也是基于平台的自定义组件完成的。
关键类FindQualifiedData:首先根据tableName属性加载权威表数据到缓冲, 以HashMap容器存放, Map的键根据PK属性来确定, 然后根据busTableName属性将业务部门上报的数据也加载到缓冲, 以HashMap容器存放, Map的键根据attId属性来确定, 再通过Map的键进行比对。如果数据量大, 则可设置cutSize属性进行分页处理。组件需要实现以下属性的可设置:
2.2.4 增量查找
有些部门上报的数据是全量, 需要将本次上报的全量数据与上一次上报更新后的全量数据进行比对, 找出增量, 再更新中心数据库的对应数据。此功能也是基于中间件的自定义组件完成的。
关键类FindAddCapacityPro:首先根据tableName属性加载中心数据库中目标表的数据到缓冲, 以HashMap存放, Map主键根据pk属性来确定, 然后根据attId属性加载SDO对象数据到缓冲, 再根据两个Map的主键进行比对找出增量, 增量分为新增、修改和删除的[4]。
2.2.5 数据加载
消息中间件为系统提供数据传输的消息总线[5], 实现不同逻辑节点之间数据可靠、高效、安全传输。消息中间件接收之前处理完的合格数据, 利用平台的导入组件将数据更新到中心数据库对应的表, 触发导出组件将更新的增量数据导出到缓冲形成SDO对象, 再用平台实现xml接口文件生成组件生成xml接口文件。xml接口文件生成组件也是基于平台的自定义组件完成的。
关键类AddCapacityToXmlPro:首先初始化参数, 再根据参数控制调用WriteXMLTimer类与XMLUtils类, 组件需要实现以下属性的可设置具体如表2所示。
WriteXMLTimer类:由AddCapacityToXmlPro类调用, 负责启动和关闭定时器。
XMLUtils类:由AddCapacityToXmlPro类调用, 接收AddCapacityToXmlPro类传递的SDO数据对象, 生成xml文件。
2.3 数据交换流程设计
数据交换系统基于消息中间件和适配器技术实现中心与各个单位之间政务信息的交换。使用消息中间件可以实现数据集成和转换、业务过程协调、大范围信息传递等功能, 可以确保中心到各业务部门政务信息的同步实时交换和更新。各单位业务数据发送到交换前置机之后, 由交换中间件负责把交换数据发送到中心交换前置机, 中心交换前置机将信息通过中心数据交换管理系统整理后保存到共享数据库。数据交换处理流程如图3所示。
2.4 数据交换接入系统
数据交换平台为用户提供灵活的系统接入方式和接入实现机制, 各个接入节点 (委办局) 可以根据需要采用前置机共享数据库、前置机共享数据文件接入方式, 也可采用直接接入数据交换平台的接入方式。节点接入时, 可以通过配置使用平台提供的标准适配器, 或根据业务需要利用平台提供的模板开发所需的适配器, 还可以通过调用平台提供的API接口等机制接入到数据交换平台。数据交换平台可以为用户提供如下3种主要的数据交换接入方式。
2.4.1 方案一:前置机共享数据库
委办局负责将业务系统的数据送到委办局前置机的接口数据库中, 并对平台开放前置机上的数据库, 平台通过配置数据库适配器或文件适配器以及交换数据流程, 实现共享业务数据的接入。接入流程配置如图4所示。
2.4.2 方案二:前置机共享数据文件
(1) 前置机上不部署数据交换节点服务器软件。委办局负责将业务系统的数据打包成数据文件 (如XML文件) , 送到前置机某一文件目录下, 并对平台开放前置机文件目录。平台通过配置ftp文件适配器以及交换数据流程, 实现共享业务数据的接入。数据文件交换如图5 所示。
(2) 前置机上部署数据交换节点服务器软件。委办局负责将业务系统的数据打包成数据文件 (如XML文件) , 送到前置机某一文件目录下, 并对平台开放前置机文件目录, 平台通过配置FileReader和FileWriter文件适配器[6]以及交换数据流程, 实现共享业务数据的接入。数据文件交换如图6所示。
2.4.3 方案三:直接接入
委办局通过平台提供的节点服务器软件和各种适配器组件, 实现从业务系统抽出数据, 并可能人工加入其它数据发送到平台交换流程。这种方式直接从委办局业务系统抽取数据, 实施前需要双方进行充分沟通和协调。直接接入方式可以采用数据交换平台提供的适配器, 或者平台提供的API接口。
3 结语
数据交换平台是支撑各部门通过应用系统实现信用信息资源共享交换的基础设施, 在整个信用信息技术框架中具有非常关键的承上启下作用, 具有服务中心、基础数据汇集与服务中心、决策信息汇集与服务中心、信息交换基础支撑中心、通用功能组件服务中心等职能。利用平台提供的各类适配器组件整合各类应用系统, 可对已建应用系统进行最小程度的改造, 打破信息孤岛, 避免重复建设, 缩短信息化建设周期, 有效保护既往投资。食品生产和流通环节多, 对食品安全的监管横跨多个政府管理部门, 需要各级政府职能监管部门的参与, 进行多角度、全方位的监督和管理。要更大程度地发挥政府对食品消费的监管和引导作用, 必须在技术层面建立高效协同的数据交换和共享平台, 以加强对食品安全的全方位监管。数据交换平台将电子政务的基本需求、安全平台提供的安全机制、数据存储层与应用层的有效隔离有机地结合在一起, 使各部门食品安全应用与其底层的数据结构和存储方式无关。同时, 应实现各应用系统与数据共享交换平台相连, 通过信息共享交换平台来实现数据共享和路由。实践表明, 这种连接方式实现了数据的无缝交换和共享访问, 既保证了各业务系统的有效协同, 又能保持各应用系统的相互独立和低耦合性, 从整体上提高了系统运作效率和安全性, 形成了基于共享的新的应用体系, 能够有效地解决电子政务不同应用系统的互联互通问题。
参考文献
[1]胡颖廉.食品安全监管的框架分析与细节观察[J].改革, 2011 (10) :147-154.
[2]东方通.服务端TongLINKQ8.0系统开发手册_程序设计指南[EB/OL].http://www.tongtech.com/webs.
[3]兰青青, 周相兵, 杨小平.面向本体的SDO数据交换蚁群优化策略[J].计算机工程与应用, 2010, 46 (5) :126-139.
[4]CAREY M J, ONOSE N, PETROPOULOS M[C].Communications of ACM, 2012, 55 (6) :86-97.
[5]汤丹, 胡志刚, 匡晓红.基于消息队列的工作流引擎及其容错设计[J].计算机工程, 2008, 19 (26) :2673-2677.
数据中心系统平台 篇9
1 广域物流系统平台在物流企业信息集成中的定位
首先,平台的功能定位于数据交换。作为平台,它建立对外的标准服务,包括与源系统和目标系统数据交换的方式、原则和数据文件接口规范,与目标系统的数据映射规则、数据技术级转换规则和数据检核规则等。
其次,平台服务于数据交换。从数据交换的整个过程来看,这种服务包括数据获取、数据转换和数据分发,数据获取是指从源系统获取所需要的增量或全量数据,数据分发是指向目标系统的指定位置提供所需要的原子级数据或经技术性转换后的数据,而数据转换则是指技术性数据转换服务,平台作为技术性基础设施,不应该也不可能完全替代业务系统中与具体业务规则相关的数据转换。
最后,伴随着平台的建设,将建立起一整套满足批量数据交换的控制和管理流程。
2 广域物流系统平台的建设目标
具体地说,它将实现以下具体目标。
(1)为参与数据交换的应用系统提供所需要的数据交换服务,并屏蔽目标系统直接对源系统的批量数据需求。
(2)建立以满足数据交换为目标的内部的数据标准和数据组织原则,实现服务于数据交换的短期数据管理。
(3)完成数据的抽取、技术性转换和对数据的技术性合规检查。
(4)实现元数据驱动的技术性转换服务,实现基于工作流引擎的流程控制和管理。
(5)建立可配置的平台架构环境。
3 广域物流系统平台的设计原则
3.1 业务无关性原则
平台在实施交换和转换服务时,其转换规则不涉及应用系统自身的业务逻辑。
3.2 源系统“供应”数据的原则
源系统负责按平台汇总的目标系统数据需求提供源数据,其中既包括增量数据,也包括全量数据。平台作为广域物流系统平台,重点在于数据的交换和技术性转换,有数据才有可能进行交换。对于如何产生对源系统的数据要求,其工作方式应当是随着平台自身标准数据的不断完善,目标系统向平台而不是源系统提出数据要求。
3.3 平台的模块化原则
平台按模块化理念设计,遵循从源系统到目标系统的可配置原则。
3.4 平台数据处理的时限原则
由于外部目标系统(CRM,ERP,SCM等)对数据的时限要求,从源系统开始数据传递到目标系统对数据需求处理的时间底线之间作为平台处理的时间窗口,因此平台将最大限度以保障每口口常增量处理批处理窗口为目的,并将不需要在批处理窗口内的处理流程移到处理窗口外的时间段处理。
3.5 平台架构的可扩展原则
由于外部关联系统的接入具备不同的时间点,因此平台架构的设计要具备良好的可扩展性,以适应平台建设的生命周期和不同外部系统的不同接入时间点的要求。
4 广域物流系统平台架构
本文设计的广域物流系统平台是企业级的数据集成服务产品,为分析型数据应用(如基于数据仓库的分析、决策应用等)和操作型数据应用(如客户评估、内部部门考核等数据应用)提供数据集成应用服务、数据集成标准和集成策略,满足数据应用项目中对数据的可访问性、可用性、一致连贯性、可审计性、安全性等数据集成质量的要求。广域物流系统平台框架如图1所示。
广域物流系统平台,用于从企业已有的业务系统中集成数据,并给分析型应用或操作型应用提供数据,满足企业数据分析和数据应用的需要。广域物流系统平台主要包括广域物流系统平台服务和广域物流系统平台基础架构。
广域物流系统平台服务主要包括历史数据迁移、数据同步、数据合并、数据交换、数据仓库等服务。
(1)历史数据迁移:实现历史遗留数据的重用,将历史数据迁移到新的目标数据库中。
(2)数据同步:实现分布的数据库中数据的上传、下载,保证分布数据库中的数据的一致性。
(3)数据合并:实现不同应用的数据库中的个性化数据到统一结构的数据库中的数据的合并,包括清洗、转换等操作。
(4)数据交换:实现分布的数据库和集中的数据库之间的交互。包括数据集中、数据分发、格式转化等。
(5)数据仓库:实现将分散的数据集中到统一的数据仓库中,并建立统一的数据模型来存储。包括:数据的上传、转换、将处理后的结果装载到事实表中,结合维度表形成数据立方。供OLAP分析、报表、预测等BI应用使用。
(6)数据联邦:保存数据源的映射关系,数据仍在原系统中存储,主要满足数据的实时处理、统一结构视图等需要。
广域物流系统平台基础架构是各种数据集成服务的运行环境,各种数据集成服务作为插件“插入”到基础架构中,由架构实现对集成服务的查找激活、输入/输出参数生成、生命周期的管理、运行的监控、意外的处理等。该架构内置了工作流引擎、ETL、规则引擎、元数据管理等部件。
(1)工作流引擎:实现数据集成处理的流程自动化,基于流程自动化可以实现数据应用项目中“数据全程推送”。工作流引擎可以自动调用每个处理节点的数据服务,同时通过调用变量管理器给数据集成服务提供输入参数;工作流支持数据加工并行处理、串行处理、混合处理。
(2)ETL:提供对不同数据源的数据抽取、转换、清洗、装载功能,是数据从业务系统抽取转化到数据仓库的过程。
(3)规则引擎:通过提供规则服务将业务处理中所需的规则独立出来处理,满足业务规则预定义和运行时规则更改的需要。可以满足流程服务和服务对规则的使用需求,业务人员按需求定义业务规则,将规则及相关设定录入规则模型库中。
(4)元数据管理:实现对数据集成服务、流程处理、源数据库、目标数据库等模型的描述、配置、编辑等。给运行引擎提供运行元数据模型。
数据中心系统平台 篇10
电子政务 (e-Government affair) 是政府在其管理和服务职能中运用现代信息和通信技术, 实现政府组织结构和工程流程的重组优化, 超越时间、空间、和部门分割的制约, 全方位地向社会提供优质、规范、透明的服务, 是政府管理手段的变革。
随着电子政务建设的不断发展, 政府拥有越来越多的应用数据, 如何建立政府信息资源采集、处理、交换、共享、运营和服务的机制和规程, 实现分布在各类政府部门和各级政府机关的信息资源的有效采集、交换、共享和应用, 是电子政务建设的更高级的阶段和核心任务。
2. 电子政务系统数据交换平台网络安全需求
从技术层面讲, 除了传统的防病毒、防火墙等安全措施以外, 电子政务特殊的安全需求主要表现在以下几个方面。
2.1 内外网间安全的数据交换。
电子政务应用中势必存在内网与专网、外网间的信息交换需求, 然而基于内网数据保密性的考虑, 我们又不希望内网暴露在对外环境中。解决该问题的有效方式是设置安全岛, 通过安全岛来实现内外网间信息的过滤和两个网络间的物理隔离, 从而在内外网间实现安全的数据交换。以隔离网闸技术为核心, 通过添加VPN通信认证、加密、入侵检测和对数据的病毒扫描, 就可构成一个在物理隔离基础上实现安全数据交换的信息安全岛。
2.2 网络域的控制。
电子政务的网络应该处于严格的控制之下, 只有经过认证的设备可以访问网络, 并且能明确地限定其访问范围, 这对于电子政务的网络安全而言同样十分重要。
2.3 标准可信时间源的获取。
电子政务系统需要建立全系统可信、统一的时间源, 这是保证电子政务系统不致出现混乱的关键因素。
2.4 信息传递过程中的加密。
电子政务系统涉及到部门与部门之间、上下级之间、地区与地区间的公文流转, 在信息传递过程中, 必须采取适当的加密方法对信息进行加密。
2.5 操作系统的安全性考虑。
网络安全的重要基础之一是安全的操作系统, 因为所有的政务应用和安全措施 (包括防火墙、防病毒、入侵检测等) 都依赖操作系统提供底层支持。
2.6 数据备份与容灾。
在电子政务安全体系中必须包括数据的容灾与备份, 并且最好是异地备份。
3. 电子政务系统数据交换平台设计方案
根据电子政务系统网络安全的要求, 文章设计了六层数据共享交换平台, 其总体框架如下:
由上图可以看出, 数据共享交换平台交换体系共分为六个层次, 分别是安全和标准体系、网络基础设施、信息资源中心、共享交换平台、应用层和展示层。
(1) 展示层。通过建立综合信息集成门户系统为用户提供统一的用户界面, 信息和应用通过门户层实现统一的访问入口和集中展现。
(2) 应用层。应用层提供满足面向各类用户依据实际需求开展业务的需要。如支撑城市应急联动应用、辅助领导决策应用、城市管理应用、社会救助应用等。
(3) 共享交换平台层。共享交换平台层为城市数据共享交换平台所在位置, 连接各类应用和应用所需的信息资源, 组织和整合各类数据、组件和服务。数据共享交换平台层为实现应用层各种应用系统的搭建和运行提供支撑服务, 包括目录服务系统、交换服务系统、安全服务系统和平台管理系统等。交换平台还提供了资源目录管理体系。目录服务主要提供目录注册、目录发布、目录查询、目录维护等功能, 能够实现各类基础资源和共享资源目录信息的统一汇集和管理
(4) 资源层。资源层通过定义数据模型, 实现数据组织、存储和管理, 为平台层和应用层提供数据服务。主要包括元数据库、四大基础信息库、平台日志库、各类主题信息库以及其他数据库等。根据应用的深入和信息量的增加需要建设的共享信息库以及数据中心等, 都作为资源层为各类应用提供数据支撑。
(5) 网络基础设施层。基础设施层提供各类系统的承载网络、所需的系统软件和硬件设备及其运行环境。
(6) 安全、标准体系层。信息安全保障体系、法规与标准体系提供电子政务应用系统安全稳定运行的保障。标准规范建设是政务信息资源共享交换平台建设的基础性工作, 是接入城市平台的各个节点之间实现互联互通、信息共享、业务协同和安全可靠运行的前提条件
参考文献
数据中心系统平台 篇11
首都在线作为国内较早开展IDC业务的数据服务提供商，从2005年就开始致力于为用户提供基于互联网技术的各种服务，目前已跻身于行业领先地位。作为主流IDC业务服务商，首都在线拥有专业的机房、优秀的带宽品质，并提供专线接入、IT运维等全方位的增值服务。
从2009年开始，首都在线开始致力于云计算平台的研发和建设，在高端云计算方面为国内互联网企业提供了全新的运营思路，在与用户合作的过程中，与用户共同成长和壮大。
压力之下建起云平台
首都在线副总裁赵永志介绍说：“2009年之前，首都在线一直在专心做数据中心，但机房成本和人工成本的不断高涨，迫使我们必须进行创新。”于是，首都在线将目光瞄向了正在兴起的云计算，开始了解云计算、调研云计算。
从最初规划开始，首都在线的目标就很明确，将自己要做的云计算服务定位于高效安全的云计算平台，为首都在线的客户提供稳定的运营平台，为企业提供高负载的服务。
在首都在线的技术团队最初开始测试云计算平台、虚拟化软件，并调研需求的时候，还发生了一段中外合作的小插曲。据赵永志介绍，当时一个偶然的机会，他获悉自己熟识的一些朋友正在英国从事云计算方面的工作，于是他与这个英国的团队建立了密切的联系，每周开电话会议，开始了构建云平台的探讨。之后，英国团队甚至组成了一个由两个英国人和一个中国人参与的小组，远程配合首都在线云平台的搭建，并于2010年8月成功部署了第一期实验平台。“实验平台搭建好后，首先应用于当时急需解决问题的几个客户，并很快就见了成效，这无疑给了我们更大的信心。”赵永志说。
验证平台的成功还带来了另外一件意想不到的事情的发生，受到首都在线云计算项目的吸引，帮助首都在线构建云平台的那个英国团队义无反顾地加入到了首都在线，这使首都在线的技术团队如虎添翼，为此后云平台建设的顺利进行埋下了伏笔。
英国团队的加入，也带来了不少他们之前从事云计算建设方面的成功经验。赵永志分析说，“在首都在线云平台的构建上，我们采用了不少已经被之前英国团队证实了的成熟技术和架构，只是在交换和网络方面针对国内的情况进行了一些改进。我们平时的运营工作都是按照国际标准化组织的最新规定和要求来做的，所以对新平台的最大要求就是稳定，如果不能证明这个平台的稳定性，那我们是不会上线的。”
变提供机柜为提供服务
在构建云平台的过程中，首都在线参考了英国团队云平台采用的架构和设备。为此，首都在线特地选择了戴尔EqualLogic产品。“因为英国团队在英国的云计算建设中曾经部署过近几百台的这一类产品，同时，首都在线远程进行了测试，并对测试结果感到非常满意。”戴尔EqualLogic产品支持SSD固态硬盘和万兆以太网端口，具有高可靠性、高安全性、数据集中存储和高性价比的特点，对虚拟化高度支持，并能灵活容灾、易扩展。赵永志说，戴尔在售后服务方面对首都在线全力支持、及时响应，并与首都在线积极互动，使他们更好地把产品用好。此外，在首都在线的云平台中，为了提供高计算性能，服务器平台采用了基于英特尔至强5650处理器的戴尔刀片服务器。
在首都在线的客户中，有一些游戏公司，高性能、速度快是他们的基本要求。但是，按照传统的数据中心运营模式，这些公司也遇到了很多实际问题，但是新的云平台模式给他们带来了“福音”。
赵永志介绍说，过去，首都在线的数据中心提供机柜、电力和网络，客户的服务器放在数据中心托管。但现在不同了，数据中心有了存储、服务器，为客户提供的是服务。“首都在线采购了高端的服务器和存储，搭建好云平台后，可以将这些资源切块分给每个客户的应用使用，从而在采购成本上减轻了客户的财政压力。当然在专业技术人员的使用上也同样节省了开销。另外，对于一些在应用上高峰低谷相差较大的客户来说，这种方式也增加了灵活性，并降低了成本。”
赵永志举例说，曾经有一个网络游戏运营商客户，从首都在线租赁服务器并托管，但是半年后，该客户遇到了很大的难题，因为当他们旗下的某款游戏运营逐渐进入鼎盛时，他们对系统的性能要求不断增加，不得不大量增加服务器，但当该游戏“过气”后，新增的那些服务器就不得不闲置起来，不但耗电，而且占空间。当首都在线云平台开始服务后，该游戏客户马上进行测试，并且很快就在云平台上上了新的游戏。“这个客户反应，有了云平台就不会遇到之前那些令人头疼的问题。”
云平台建起来了，客户自然也来了，新的云平台模式已经为首都在线带来了近百个用户。在赵永志看来，现在自己做的这些事情，是他这些年来最满意的事情，不但为客户省钱了，业务也在不断扩大，公司的利润也在增长。
“云计算是一件大家都能从中受益的事情。”赵永志说。
编辑手记
“云计算是一件大家都能从中受益的事情”，这即是首都在线的切身体会，也是众多云计算服务提供者的心声。
近期记者在近期的云计算采访中发现，不管是建设公有云还是私有云，如何让服务提供商（或是IT系统管理者）和服务使用者都能从中获益，是大家都在讨论的话题。不过要想让大家都满意，需要从基础设施建设、服务规范等方面多管齐下。
不过单单从基础设施建设上来说，如果能够选对一款适用的服务器平台，也是能够达到事半功倍的效果。近期的云计算采访中，记者发现有不少用户像首都在线一样都选用了基于英特尔至强平台的服务器作为云计算的后台。在这些用户选择至强的时候，一方面，性能表现出众往往是大家首选的原因,新一代英特尔至强处理器提供了比上一代产品性能各自提升达60%（最高幅度）和3倍（平均幅度）的优异性能；其次就是基于至强平台在云计算相关的虚拟化、数据中心管理、节能降耗等方面的特性也打动了用户。
像首都在线的网络游戏用户对于资源需求随着在线玩家数量变化而变化的情况，就是喝多云计算应用中所面临的如何建设一个平衡高效的云计算平台的问题。面对这种情况其实可以利用
数据中心系统平台 篇12
一、仔细查找, 分析问题数据产生源头
系统是根据业务处室业务办理需要, 按照各业务处室的业务需求开发的, 而系统内数据是各相关业务处室在使用系统进行劳动保障业务办理、服务提供等工作过程的记载与反映, 它如实的记录了我市劳动保障业务的历史过程与业务办理结果, 是劳动保障业务和服务的电子化体现。我市现有的系统是由多个业务应用子系统通过信息共享机制构建的业务经办信息系统, 虽然初步实现了劳动保障业务信息化统一平台的要求, 但由于系统内根据各子系统的需要建立了多个独立的个人及业务数据库, 因此对于个人的信息及业务办理就形成了多个数据库都进行记载的情况, 而多重办理必然导致了问题数据的出现。
问题数据的产生不仅是个人信息记载的错误和缺失, 也是业务办理信息记载的错误和缺失。问题数据如果不进行及时的清理, 涉及的劳动者就有可能会存在着应该享受的待遇没有享受到, 或者不应该享受的待遇却享受了, 社会保障基金的冒领, 他人待遇的替换, 更可能导致个人在家庭困难、失业、看病等危急时刻得不到社会保障体系的应该给予的保障, 造成个人社会权利的缺失, 导致社会保障体系的不健全, 对建设稳定、和谐的社会局面造成冲击。
二、科学规划, 有序推进数据库整合
系统经过十几年的建设, 形成了18个个人信息表, 需要进行有效整合, 能既保证数据的准确性又不影响业务的正常办理。数据清理本身是一项复杂、长期的工作, 特别是面对我市覆盖面广、功能众多、数据量庞大, 并且具有很强的业务性和实时性要求的系统, 数据清理工作更为艰巨与困难。必须建立一套以个人信息清理为基础, 以业务数据整合为导向的数据清理机制。
我们在遵循金保工程对系统建设技术要求及数据指标要求的基础上, 结合我市劳动保障各项业务办理实际情况, 进行了详细的规划设计, 明确了资源数据库建设目标、原则以及资源数据库的数据范围、指标定义, 对各表情况进行分析比对, 明确了数据整理合并的步骤及各数据表的优先级。数据准备是指收集相关资料、数据;数据的规范化、标准化是指相关数据应符合统一资源库的规范要求, 通过开发专门的软件进行转换、清洗、梳理, 建立数据字段的映射关系、编码标准的映射关系, 并形成相应的电子数据, 在市本级及三区两县同步体现数据清理整合工作。在实施过程中, 严格按照规划方案, 会同协建单位、业务操作人员有序的进行数据的比对、合并、验证以及最后验证数据的迁移。
三、明确职责, 强化日常维护管理
数据清理整合的过程分为内部清理和外部核对两部分。内部清理是将业务管理系统原始数据库中的个人和单位信息提取、比较、核查、校正以后, 采用逻辑推理、经验判断、合理数值范围设置等方法, 进行包括数据命名、数据类型、数据长度、数据合法检查、代码过滤等方面的规范, 对数据进行审查和筛选, 滤出错误数据。
外部核对主要采用将需要整理或核对的数据信息提供给参保单位或参保人员确认。数据核对后, 对系统中的相关信息进行修正, 对缺失的数据项进行补充, 对一人多条的数据记录进行合并, 然后再分期分批提交, 使之达到规范统一的要求。
资源数据库完成整合建库是基础, 重要的工作是日常的管理和维护, 一方面按照数据唯一性及扎口管理要求, 明确了信息中心作为个人资源数据库的管理主部门, 为资源数据库的正常运转提供组织保证;同时为强化资源数据库的日常维护管理, 建立了市、区 (县) 、街道三级数据清理整合服务窗口, 形成了资源数据与业务数据实时清理、整合的长效工作机制, 确保了资源数据的质量和可用性。
通过资源数据库的统一管理, 将业务功能的处理与基础数据分离, 形成了以资源数据库为基础的树型互联关系, 以单位及个人状态变化驱动业务办理, 而在业务办理时将形成的人员状态反馈回资源数据库, 为其他业务模块提供实时、唯一的基础信息, 各业务功能模块则根据个人唯一的社会保障卡号进行准确的业务联动和信息共享, 保证了相关业务办理的一致性和准确性。