郑州轻工业学院校情统计分析平台的设计与实现
来源：郑州轻工业学院现代教育技术中心 作者：甘琤 李霞 李虎 发表于：2015.09.03 2102浏览
一、前言
郑州轻工业学院于1999年接入中国教育科研网，2004年开始进行数字化校园建设，学校历届领导高度重视信息化工作，认为信息化是促进学校跨越式发展、促进人才培养的重要手段。历经十几年的发展，学校校园网已完成所有区域的覆盖，拥有互联网带宽3.8G，峰值在线人数达22000人，占师生总人数92%。学校教务、科研、学生、后勤、设备管理、行政办公等业务领域均建设了信息系统，并在“数据统一、身份统一、门户统一”的数字化校园平台环境下实现了集成，较好的解决了信息系统孤岛问题。
通过系统的长期运行，各类信息系统均积累了一定规模的数据，涵盖各单位教学、科研投入产出，学生招生、培养、就业，学校行政运转、资产管理、后勤服务等方方面面。这些数据的有效利用与发掘，是学校信息化工作在今后一段时期内的重点。在此背景下，学校提出“校情统计分析平台”（以下简称校情平台）建设计划，希望在此平台下开展业务数据的统计、分析、挖掘工作，最大化的发挥数据价值，使之服务于学校的日常管理与决策。
平台于2013年开始调研，2014年8月开始建设，截至到目前已完成第一期建设。现就建设思路、平台架构、数据仓库构建过程、建设成果和展望简要介绍如下。
二、郑州轻院校情平台建设思路
统计学有信息、咨询、监督三种社会功能，对于高校管理和决策，我们以“信息综合查询”“数据咨询”“业务监督”三种职能作为校情统计分析平台的建设目标。根据学校实际应用水平，将“信息综合查询”作为一期建设重点，以图、表为主的在线报表方式进行描述性统计，实现初步的“咨询”和“监督”功能。
图 1 校情平台系统原型
图 1是根据总体发展要求设计的校情平台系统原型。功能方面以教务、科研、学工、财务、人事、设备、后勤等业务归口部门的年度报告和日常统计工作需求为基础，向用户提供在线报表、在线查询统计两种方式的功能。用户角色考虑三个层次，分别是学校层面、院系层面和师生个人层面，优先开展学校层面和师生个人层面的功能实现。
三、郑州轻院校情平台设计
1、平台规模控制与技术标准
学校各种管理系统数据虽有一定规模，但与金融、电信、互联网电子商务等行业相比，数据总量和领域范围相对较小，其数据产生于各种业务数据库，仅需考虑结构化数据对象，因此普通企业级关系型数据库或集群即可满足一期工程的存储和检索需求。
因为各种管理系统源自于不同的厂商，所以不同系统中数据差异较大，需在统一的数据标准基础上开展集成。
校情平台服务于不同管理阶层和管理目标，数据统计分析需求具有一定不确定性，在数据抽取、清洗工具上考虑可灵活部署、数据格式兼容性强、数据转换能力强大的企业级工具；在联机分析方面以OLAP技术为主，向用户提供所见即所得的在线工具，并对Excel、SPSS、SAS、STAT、R等统计分析软件提供数据接口服务。
根据学校应用系统建设标准，整个方案还需兼容JSR168标准和Open SSO单点身份认证标准，使得用户可通过学校门户系统访问到所需的查询、统计功能。
2、方案设计
基于上述建设思路，郑州轻院校情平台架构采用分层架构进行设计，共分为四层，分别是数据层、集成层、模型层、表现层，如图 2所示。
图 2 校情平台层次模型
数据层由各种管理信息系统的数据库或结构化数据文件构成。
集成层以数据抽取清洗工具为主，按照现行国家标准、行业标准，对不同业务系统中的公共信息进行统一编码、转义，统一存在标准数据库中，并在元数据库中提供标准数据的数据结构说明。
集成后的数据按ROLAP模型组织成事实、维度、指标存储在关系数据库中。对整个数据抽取集成的过程进行监控和日记记录，以备数据审计的需要。
一般情况下，联机分析引擎和报表引擎均需要提供相应的模型数据才能正确运行，因此关于主题数据库中的雪花模型和关系模型也必须详实、规范的录入引擎中。在Oracle BIEE中，这些信息登记在Physical Model、Business Model和View Model中；在SAP BO中，这些信息登记在Universe中。这些数据虽然来源于业务系统中的事务数据，但组织形式和使用目的已经发生了变化，因此统一归纳在模型层中。
应用层构建在模型层之上，主要是通过各种工具软件，根据用户的需要进行统计分析的图表的呈现，分为三类情况：一是向用户提供报表功能，满足非IT人员的直接获取报表和分析结果的需求；二是通过在线OLAP系统向业务专家提供查询、交叉表、图形的自定义分析功能；三是专业数据分析人员可以通过Excel、SPSS等工具，直接通过ODBC、JDBC接口访问主题数据库中的各类数据，进行更深层次的数据挖掘和分析工作。
3、软硬件架构实现
平台软件方面：（1）选用甲骨文公司所提供的解决方案构造整个服务平台，采用Oracle作为数据库引擎，采用BIEE作为OLAP引擎，采用ODI负责数据转换和清洗；（2）选用金智公司针对BIEE开发的JSR168插件，实现统一身份认证、单点登录和门户集成。
通过金智公司的插件可将BIEE中的Answers 封装成学校门户中的Portlet，再利用门户的站点（Site）、门户（Portal）、页面（Page）和Portlet配置功能，建立不同功能的数据服务站点，如图 3所示。
图3 校情平台软件架构及数据流
平台硬件方面：使用三台物理服务器组成ORACLE RAC集群，形成高可用、高性能中心数据库，从学校现有FC SAN存储中心划分6T存储空间，向中心数据库提供2x8Gbps数据带宽。采用四个虚拟服务器作为应用服务器，其中两台运行ODI，一台运行BIEE，另外一台作为开发工作站，见图 4 。
图 4 校情平台硬件架构
4、系统的扩展
校情平台是学校管理业务数据的查询、分析、统计中心，虽然需求趋势强烈，但未来的具体需求还不明朗，学校整个系统的设计立足于现状，所配备的软硬件资源均有限。考虑未来的发展需求，在平台设计和实施时已经考虑了未来在存储、查询和计算方面性能方面的扩展途径。
（1）存储和查询性能的扩展
校情平台中心库作为所有分析数据的存储和SQL查询提供者，存在潜在的容量和性能瓶颈。当容量不能满足需要时，可在存储系统中划分新的存储空间，以表空间的方式提供给数据库。当性能不能满足需要时，可增加RAC节点数量，从而得到更大的处理性能和吞吐率。
（2）计算性能的扩展
本系统采用ROLAP方案，BIEE应用服务器在运行时会在内存中进行交叉、汇总计算，在应用服务器端存在潜在的性能瓶颈。前期应用规模不大时，考虑一台虚拟服务器运行BIEE服务，应用增长到一定范围时，可直接增加服务器。由于JSR168封装插件存在，服务器间的访问差异性被屏蔽，整个系统仍然表现为一个整体。
四、基于OLAP数据服务的二次开发
平台中所选用的BIEE系统是整个数据服务的核心提供者，也是二次开发的重点内容。
图 5 Oracle BIEE 架构
如图 5 所示，BIEE系统是一个典型的三层架构，包括由各种外部数据源组成的Sources层、存储OLAP逻辑信息的资料库层（Reposi-tory，可通过OBI Admin工具访问）以及数据发布服务层（Presenta-tion Services）。其中资料库层和数据发布服务层均包含在BIEE系统内。
1、 BIEE环境下ROLAP的实现
数据库联机事务OLTP（On-line Transcation Process）是在数据库环境下根据应用业务事务（Transcation）所执行的一系列数据库操作。联机分析处理OLAP（On-line Analytical Processing）是在基于数据仓库多维模型的基础上，实现的面向分析的各类操作的集合。OLAP与OLTP的主要差别见表1。
表 1 数据库联机事务与联机分析对比表
|
数据处理类型
|
OLTP
|
OLAP
|
|
面向对象
|
业务开发人员
|
分析决策人员
|
|
功能实现
|
日常事务处理
|
面向分析决策
|
|
数据模型
|
关系模型
|
多维模型
|
|
数据量
|
几条或几十条记录
|
百万千万条记录
|
|
操作类型
|
查询、插入、更新、删除
|
查询为主
|
OLAP分为MOLAP、ROLAP、HOLAP等类型，其中ROLAP是一种将OLAP操作转换为数据库关系模型操作的OLAP实现技术，具有成本较低、性能较好的优点，因此选用BIEE-ROLAP方案。
OLAP操作包括钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot），建立在多维模型的理论基础上。
关系模型操作包括数据创建（Create）、获取（Retrieve）、更新（Update）、删除（Deletion），建立在关系理论的基础上。OLAP操作均是读取操作，被映射到关系模型获取操作的集合、投影、选择、聚合等操作上。
两个领域操作原语的转义由BIEE完成。Oracle BIEE将转义信息存储在Repository中，如图 6所示，BIEE Repository中的三种信息分别包括数据资源的物理结构（Physical）、面向多维分析的数据立方体信息以及面向业务的发布信息。
图 6 BIEE Repository中的三种信息
在物理层（Physical Layer）中，包括待分析数据的数据库位置、访问方式、各数据库中表结构及其关联关系，使得BIEE能够根据需要正确的执行相关关系操作。
面向多维分析的数据立方体信息被记录在业务逻辑层（Business Layer）中，包含多维模型的事实（Facts）、维度（Dimensions）信息与物理层各种数据表之间的映射关系。这些信息使得BIEE能够将OLAP操作正确的映射为关系操作。
开发人员根据业务和用户角色划分数据立方体的访问范围，在表现层(Presentation)建立视图模型（View Model）。视图模型是访问者访问数据立方体的“窗口”，用户可通过视图模型所访问到的是一个受限数据立方体的子集范围，也称为“主题”，如图7所示。
图 7 用户访问发布服务中提供的数据立方体
在BIEE环境下OLAP查询结果以图、表和叙事文本的形式给出，并可组织成丰富的图文展现形式。开发人员可将OLAP查询操作以Answers的形式保存在服务端，并提供更为通俗易懂的名称，如“教职工职称系列分布”，最终用户只需直接访问这些Answers就可得到相应的结果，见图8所示。
图 8 Answers查询结果
BIEE还提供和数据仪表盘（Dashboard）功能，访问者可在一个WEB页面中得到多个Answers的数据，获得更多的信息。但因Dashboard组织在BIEE自有门户系统中，无法直接集成到学校数字化校园门户系统中，因此未使用BIEE的Dashboard功能。
2、校情平台与学校门户系统的集成
金智公司提供BIEE Answers的JSR168封装插件，利用该插件以http代理的方式将Answers封装成一个Portlet。通过该插件，可在学校门户中实现校情门户站点，在该站点中，将各种预先制作好的Answers以Portlet的形式集成在站点页面中，形成图形化的菜单，具有更好的访问效果。图 9是我校门户系统的集成效果。
图 9 进行门户集成后的前台展示
五、建设成果与展望
学校于2014年8月开始建设校情平台，到目前为止的建设成果为：按照方案设计完成了软硬件系统的部署，并完成了数据集成、系统进程工作；完成了科研、教务、学生、设备、宿舍、一卡通、研究生等主要业务系统的数据集成，向学校各级管理层提供10个方面共98个查询。
校情平台建设成果初步显现。通过学生招生、培养、就业数据的联合分析，学校进行了2015年招生计划调整，将原有报考率高、就业形势明显更好的四个专业调整为一本专业招生，对一些专业进行了缩减、停招等调整；通过学生宿舍分配情况的统计分析，向学校提供下一学年各校区、宿舍区的新生容纳能力，为学校招生安排、后勤保障提供支撑；学校在校情平台的数据统计基础上开展学科点建设管理，对各学科学科点建设情况进行动态跟踪，对各种指标进行横向对比、团队内对比，全面监督各学科点建设任务推进情况。类似的工作还应用在就业工作领域，通过就业数据的实时分析，全面对比学校各专业的就业工作进展，促进各二级院系扎扎实实推进毕业生就业工作。通过一期校情系统的建设，学校各级管理部门初步感受到充分数据共享环境下，信息化对管理、决策带来的强力支撑。目前学校正在开展全员工作量考核管理系统建设，其中工作量核算、分析、调整等功能将在校情分析平台上实现。
在下一步工作中，我们将进一步丰富主题模型，适应更多的查询统计需求；结合学校管理需求和统计事件，开发更多的查询服务；开展挖掘分析工作；更重要的是通过这些服务工作让职能部门感受到信息化所带来的好处，促进各职能部门自觉、自主的开展信息化应用，使得信息化为高校发展、人才培养起到更大的促进作用。