摘要

  随着信息化建设的深入,数据越来越成为学校的重要资源,为了实现对数据资源的有效管理和共享,不同学校采取了不同的架构和方式。  本文结合实际情况,分析和研究各种数据库架构和数据共享方法的优缺点,给出一种可在共享便利性、系统耦合度、数据实时性、运维工作量、单点故障方面都同时兼顾的数据共享中心系统的建设思路。...

  随着信息化建设的深入,数据越来越成为学校的重要资源,为了实现对数据资源的有效管理和共享,不同学校采取了不同的架构和方式。

  本文结合实际情况,分析和研究各种数据库架构和数据共享方法的优缺点,给出一种可在共享便利性、系统耦合度、数据实时性、运维工作量、单点故障方面都同时兼顾的数据共享中心系统的建设思路。

数据共享方式介绍

  1.几种基本的共享方式

  如下图所示,高校业务系统进行数据共享时,主要的三种方式,ETL方式、数据视图方式及WebService接口方式。

 src=
数据共享方式示意

  ETL是数据抽取、转换和装载(Extract,Transformation,Loading)的英文简称。

  数据抽取是从各种异构系统中抽取数据的过程,这些数据可以是结构化数据,也可以是半结构化数据。

  数据转换是对抽取来的数据进行一定的合并、汇总、过滤和转换等操作的过程。

  数据装载是把转换后的数据装载入目标数据库中的过程。

  ETL的实现通常需要借助一些ETL工具,比如Kettle、OracleODI等。采用ETL方式的高校,系统通常由各个业务部门自己建设,系统建设比较分散,各个系统有自己独立的数据库服务器。

  数据视图是数据库系统中的一种虚拟表,用于呈现一张或多张基本表中的数据。

  通过编写视图查询逻辑,可以自定义数据的呈现字段和格式,也可以对访问视图的数据库用户进行权限管理。

  采用数据视图方式的高校,通常在建设系统时进行了统一规划,建设了一个涵盖各个业务的统一综合系统,数据库通常在一台服务器上。数据视图共享方式一般存在于采用统一数据架构的高校。

  WebService就是Web服务,是一种跨平台、跨编程语言的远程调用技术。

  用户可以通过任何支持网络接口的编程语言,编写程序调用服务端的WebService接口,获取数据。目前,主要有两种WebService技术,分别是基于SOAP协议的和基于Restful风格的。

  采用WebService共享的高校,通常系统建设也相对分散,数据库分散在独立的服务器上,进行数据共享支持的技术部门或公司技术实力相对较强。

  2.共享方式对比

  ETL、数据视图和WebService是高校信息系统间进行数据共享的主要形式。三种方式各有特点。比如:

  就数据实时性来说:

  数据视图和WebService都可以做到数据的实时查询,源端业务系统数据发生变化,使用端系统马上能查询到变化。

  ETL方式是周期性地进行数据抓取,所以源端和使用端数据存在一定时间的延迟,无法做到实时。

  就系统耦合度来说:

  ETL形式最低,因为除了数据,数据源端和使用端的业务系统完全隔离。

  WebService耦合度中等,因为使用端需要调用源端的接口,如果源端系统服务不正常,可能会造成接口调用失败,进而影响使用端系统。

  数据视图方式耦合度较高,因为使用端系统读取的数据,直接来自于源端系统的表,如果源端系统的表结构或者视图结构发生变化,可能会造成视图错误,进而导致使用端系统读取数据错误。

高校数据共享架构演化研究

  1.共享架构演化过程

  美国管理信息系统专家诺兰通过研究提出了信息系统进化的诺兰阶段模型。诺兰模型分为初始阶段、扩展阶段、控制阶段、数据管理阶段和成熟阶段,高校信息化的建设也大致遵循诺兰模型。

 src=
共享架构演化示意

  如上图所示,在高校信息化建设的不同阶段,由于不同的建设需求、问题和特点,使得数据共享架构也随之演化,共享架构的演化过程按照数据共享架构的特点分成了分散结构阶段、网状共享架构阶段、星状共享架构阶段。

  在诺兰模型的初始阶段:

  计算机刚刚进入高校,只作为办公设备使用,这个阶段各个业务部门都还没有自己的信息系统,数据共享也就无从谈起。

  在诺兰模型的扩展阶段:

  使用信息系统提高管理和服务效率,成为大家的共识,高校信息化的主要需求是建设信息系统,实现业务的系统化。

  但是这个阶段缺乏统一的规划和设计,各个业务部门都是从本部门的角度出发,建设各自的业务系统,业务系统间的数据库都是独立的,架构上是分散的,没有实现技术上的数据共享,呈现出一个个信息孤岛。这个阶段的数据共享架构呈现分散结构。

  在诺兰模型的控制阶段:

  高校各个业务部门基本都实现了系统化,使用系统的手段代替了过去手工的管理和服务模式,信息化的需求也逐渐演变为如何提高不同系统间的数据共享程度,实现跨系统的业务协同。

  为了实现这个目标,在数据共享层面,不同的高校采用了不同的方案。

  一种方案是在现有的分散结构上,利用几种基本的数据共享方式,打通系统数据,实现技术上的数据共享;

  另外一种方案是把业务系统数据库都集中到一个统一的数据库里,或者推翻以前分散建立的系统,统一建设一个涵盖绝大多数业务的大平台,然后把大平台的数据放到统一的数据库里。

  这个阶段高校数据共享建设的特点是系统间实现了数据共享,能实现跨部门系统的业务协同,管理和服务效率得到提升。

  主要问题是由于对数据共享本身的建设缺乏规划和设计,造成了数据共享呈现网状结构,造成系统间的耦合度非常高,如果某个业务系统进行修改或者重建,会对其他系统造成影响。这个阶段的数据共享架构呈现网状架构特点。

  在诺兰模型的数据管理阶段:

  数据成为学校的重要资产,系统的业务功能重构和升级改造成为常态,这个阶段信息化建设在数据共享层面的需求变成了如何有效管理和共享数据,如何降低系统间的耦合度。

  各个高校数据共享的建设普遍采用星状化架构进行系统间的解耦,建设数据管理和共享平台,进行数据的管理和共享。星状化的架构使得业务系统只和共享数据库产生耦合,系统间的耦合关系被打散。

  数据库分散的高校,通过建设一个单独的共享数据库,所有共享数据通过共享数据库进行共享,化网状结构为星状结构。数据在统一库里的高校,也在统一库里,通过建设共享的数据访问区实现星状结构。这个阶段数据共享呈现星状共享特点。

  新阶段又出现了新问题:

  星状化的统一数据库架构和星状化的分散数据库架构各有优缺点。

  分散架构没有单点故障,但是运维压力比较大,需要维护多个系统数据库;统一架构只需要维护一个数据库,运维压力小,但是容易发生单点故障。

  当前阶段,作为信息系统底座的数据库的稳定运行已经是高校工作正常运转的必要条件,同时高校信息技术部门承担的任务也越来越重,如何在保证数据库稳定性的同时,降低信息技术人员的运维工作量也是需要考虑的问题。

  本文根据实践经验,提出了主备架构+统一数据库+星状共享的模式,可以同时解决运维压力和单点故障问题。使用数据库的主备架构消除了单一数据库的单点故障问题,提高数据库的可用性,统一数据库的形式又保留了运维压力小的优点。

  2.共享架构特点比较

 src=
共享架构特点比较

  上图列出了几种共享架构各自的特点,从图中我们可以看出,主备+统一数据库+星状的数据共享架构在各方面的优点都比较突出。

数据共享中心平台建设思路

  1.数据共享中心平台建设背景

  随着数据共享建设的深入,系统间都通过各种方式(WebService、视图等)建立了共享,但是由于缺乏管理机制和工具,这些数据共享如同在一个灰箱里,随着时间推移,没有人知道谁创建了它们,没有人知道它们可不可以删除。

  由于系统间的数据共享越来越多,各个系统间存在大量的耦合关系,千丝万缕,学校的各种信息系统就像被一张暗网缠住,牵一发而动全身。

  过去数据共享流程,没有规范化、流程化的管理,通常就是口头交流,纸本函件的粗略描述,整个数据共享的过程就像笼罩在一层白雾之中,模糊而不清晰。

  数据共享的这四方面问题可以形象地归结为接口灰箱、人力黑洞、系统暗网和过程白雾。解决这些问题是数据共享中心平台系统建设需要实现的主要目标。

  2.物理架构规划

  为了保障数据安全,我们将整个学校的网络划分为了校园网、服务器子网和数据库子网,三个网络之间是相互隔离的。

  校园网用户访问业务系统需要经过F5负载均衡设备,业务系统服务器需要访问数据库,需要配置有数据库子网的网卡才能进行访问,数据库子网不直接面向校园网环境。

  数据库的部署上面采用两台Oracle公司的ODA数据库一体机,分别作为主库和备库。主库和备库分别部署在不同的机房里,实现异地灾备,二者之间采用ADG技术实现数据的实时同步。当主库发生故障时,可以把对数据库的访问切换到备库,实现故障转移,确保学校业务不间断。

  3.软件系统功能设计

  数据共享中心平台以标准的数据子集和标准的代码作为支撑:

  标准数据子集参考教育部高等学校管理信息标准,分为学生、教职工、教学、科研、资产等13个子集,每个子集包含若干张和本子集业务相关的信息表;

  标准代码包含国家标准、行业标准、教育部标准及学校标准四部分的代码。

  通过建设数据共享中心平台系统,以可视化的方式提供各种数据共享管理功能,解决了高校数据共享管理上的灰箱问题。

  在数据共享流程上,建设一个包含数据申请,数据审批,共享生成的全过程的系统化管理机制,实现对数据共享过程的流程化管理,解决数据共享工作中的过程白雾问题。

  在接口创建上,支持自动化的生成视图接口或者WebService接口,把高校信息中心老师从重复性的劳动中解放出来,释放了人力资源,解决数据共享工作中的人力黑洞问题。

  4.内部逻辑层次设计

  在统一数据库环境下,业务系统的数据以数据库用户的形式存在于一个数据库实例下。

  数据共享中心平台在数据库内的逻辑层次分为数据层、标准层和共享层。

  数据层主要是各个业务系统的数据库用户,用于提供各种源数据。

  标准层是提取和保存标准数据的地方,由于业务系统的数据是在同一个数据库实例下,可以使用数据视图,按照数据标准的定义创建标准视图,用视图的形式呈现标准数据。

  再通过ETL的方式,把标准视图的数据传输到对应的实体表里,形成一份标准的实际数据。

  共享层主要用来创建共享视图,所有的数据共享都要经过共享层,使得数据共享呈现星状化特点,数据使用端系统只依赖于数据共享层,数据源系统的变动不会直接影响数据使用端系统,实现了系统间的解耦,进而解决了数据共享工作的系统暗网问题。

应用案例

  中国人民大学信息化建设前期建设了统一的、涵盖大多数业务的综合业务系统,采用统一数据库架构。

  起初优势很明显,在数据共享方面,数据都在一个数据库里,不同的系统通过建设视图的方式,能很快进行数据共享,而且基于视图的数据共享都是实时的;在运维层面,信息中心可以对数据进行统一的维护和管理,各部门只需要专注自己的业务,而不用为系统配备专门的数据库管理人员,节约了人力资源。

  但是随着信息化建设的深入,旧的系统不能满足学校管理和服务业务的需求,各部门重新规划建设自己的系统。

  由于缺乏管理和规划,前期数据共享工作形成了大量网状化的共享视图,系统重建时,它对外共享了哪些数据,获取了哪些数据,都处于灰箱状态,技术部门在解耦网状化共享视图的工作上,投入了大量的精力,尽管如此,还是发生了多次因为系统重建和升级造成数据共享的出错事件。

  同时前期的统一数据库,没有使用主备架构,数据库每次运维调整或出现问题需要停机时,都会影响全校的信息系统工作,给各部门和师生造成了很多不便,信息中心面临很大压力。

  为了解决上述的问题,中国人民大学在架构上采用了上文提出的主备+统一数据库+星状的数据共享架构。

  在硬件层面,引入了数据库的主备架构,把主库和备库分散到两个物理上不同的机房,如果主库出现问题,随时可以切换到备库承载业务,提高了系统的可用性。主备架构上线至今,从未出现因数据库问题造成全校业务系统停摆的严重事件。

  在软件层面,信息中心规划建设了专门的数据共享中心平台,实现数据共享的系统化管理、数据共享的自动化生成和数据共享的星状化结构,解决了数据共享中存在的四方面问题。

  同时数据共享中心平台中还规划建设了数据标准管理功能,建立了中国人民大学数据标准,使用系统化的方式对数据标准进行管理,在统一数据库下对标准数据的集成也创新地提出了基于标准视图的数据集成方式。

  对于集成的标准数据,数据共享中心平台还配有专门的数据质量工具,对数据进行数据质量监测,通过把数据质量报告提供到业务部门,形成数据质量改善闭环,不断提高数据共享中心平台中标准数据的质量。

  本文通过研究高校数据共享几种基本方式的优缺点,以及高校数据共享架构的演化过程和存在的问题,结合中国人民大学的实际情况,提出了一种数据共享中心平台的建设思路。经过笔者所在高校的实践证明,本文提出的统一数据库下的高校数据共享中心建设思路具有实际的可行性。

  作者:钱红兵、李艳丽 (中国人民大学信息技术中心)
  来源:《中国教育网络》杂志(11月刊)
  责编:朴艺娜

  投稿、转载或合作,请联系:media@cutech.edu.cn

华人教育信息订阅号二维码