高校数据治理技术框架研究

文/邵炤昭 王壮

高等教育行业的快速发展，暴露出传统线下办事流程时效低、体验差等弊端，在一定程度上影响在校师生学习和生活的正常开展。不少高校通过开展数据治理工作，来解决线上服务中因数据交换困难而造成的弊端。

高校数据治理困境

不少学者分析国内高校通用业务，总结出数据治理中的核心问题，主要体现在以下六个方面[1，2]:

第一，数据共享困难。首先是信息系统相互之间协调困难，出现信息化“烟囱”现象。同时，数据接口的多样化，比如有的系统接口是数据库视图，有的则是数据文件，有的是采用Web Service 返回非标准的字符串等。另外，因数据共享机制，业务部门对自己管理的数据存在权利担忧。最后，相关部门担忧数据共享会反映自己业务管理存在瑕疵。

第二，数据质量参差不齐。在信息化建设过程中，建设单位或部门，主要围绕自身业务进行需求的确认和开发，在系统开发过程中，对于不影响自己业务的数据缺乏基础校验，或者校验不足。这会导致在其他业务系统需要相关数据时，系统无法提供准确信息。同时，不少系统管理人员没有专业的数据维护意识，在共享数据时，发现数据错误后，仅在下游系统进行手动修正，却不提醒数据源头维护好相关信息。

第三，数据权限管理混乱。国内高校普遍缺乏数据管理权限体系。在业务场景中，最直接体现出来的问题就是一数多源。当下游业务系统无法确定数据源头时，就自行开发数据收集界面，进一步加剧数据管理的混乱状况。对于用户而言，就会出现反复填写信息的情况，体验较差。与此同时，下游业务系统开发人员和系统管理员可能没有相关资质和培训，无法确保数据的机密性，进一步削弱数据安全体系。

第四，数据生命周期缺失。在实际业务中，业务系统对于数据的注销和存档相对不够重视，在现实场景中最直接的问题体现就是僵尸账号和数据垃圾，用户在系统中完成核心业务流程后，用户数据没有执行注销、删除和保存。此外，系统监管存在空白，相关人员离校后，系统依然对外开放，给校内系统留下后门漏洞。

第五，数据应用监管空白。目前，随着《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》相继出台，数据隐私管理开始有法可依，但如何兼顾用户个人数据隐私和数据共享，还待进一步研究。

第六，数据创新应用不足。主要体现在数据治理的成效对于数据源头管理单位贡献不大，或目前存在的数据问题不是长期或严重的问题,对于数据需求系统的提升有限。

高校数据治理方案

针对数据治理面临的困境，不少业内专家提出卓有成效的解决方案，并在任职机构取得积极反馈[3，4]。这些方案主要是从以下三个层面进行改革和突破:

首先，完善学校顶层信息化建设规划。依据学校未来5年或者长期目标，对学校业务和数据流向进行分析，依据分析结果，成立数据核心管理层和数据指导团队。该团队主要负责制定数据治理的蓝图和收益方向、平衡数据治理中各方的责任、风险和成效，以及梳理数据治理中组织结构关系，监控数据治理的成效。总的来说，该团队负责数据治理的最终方向。

其次，搭建数据协调团队。数据协调团队是协调数据的责任主体，主要负责制定数据的技术标准，确保上游业务系统能提供符合技术规范的高质量数据。在数据治理期间，因为数据源头可能存在技术或者业务困难，协调团队会通过持续更新数据的采集和分发策略，来确保数据平台能够按照预期标准进行采集。

最后，组建技术团队。技术团队主要责任是搭建数据平台、维护数据接口、保护数据隐私以及保障数据安全。团队主要任务包括日常数据收集，数据转换，数据标准化，确保数据存储安全；适当进行数据接口的开发和定制；保护数据平台中数据的隐私，对关键信息，例如手机号和证件号，进行去隐私和加密处理；保障监控平台数据的完整性，对数据写入和读取进行审计。

尽管在数据治理的体系方面有很多参考资源，但在技术层面的文献和探讨相对缺乏。部分学者推荐参照企业治理中的SOA架构来重构业务流程，然而市场上相关厂商则宣扬用大数据来进行数据治理。由此可见，技术平台选择的多样化，让很多高校的信息部门或者数据治理小组难以做出决策。

数据交换平台技术架构及治理案例

浙江大学国际联合学院在2019年启动数据交换平台项目来开展数据治理。在建设实施前，采用传统的结构化数据库进行数据的存放和管理，项目开展后，引入SOA技术框架，对业务系统中交换频繁的核心数据进行模型重构，对SOA在数据治理中遇到的问题进行了分析，积累了大量的项目实施经验。同时，对大数据平台的功能也做了深度调研，对部分业务数据量较大的场景进行实验，总结出一套SOA技术架构和大数据平台整合的经验。技术平台架构如图1所示，主要包括以下几个核心组件:

图1 数据治理阶段各组件功能示意

ETL工具：ETL工具使用开源的Kettle，针对单次数据增加和更新小于10万条目的格式化数据集合，通过开源工具Kettle对数据进行采集。对于日志格式类型等大容量数据，例如超过千万条记录，首先通过Sqoop将数据采集到临时数据库，再通过Impala进行初步过滤和加工，将加工后的数据写入到主数据平台。

Hadoop文件存储系统：将采集过的原始数据写入到Hadoop文件系统进行永久性存储，Hadoop本身的文件系统在集群环境下自动实现数据的多备份，从而实现数据的可靠性，并且可以通过增加节点快速扩展存储空间。

主数据平台：将采集和清洗后的数据写入主数据平台。之所以选择主数据平台，不选择数据仓库，主要原因是主数据具有高精准、唯一识别性和高扩展性等特性。高精准体现在每一条记录都可以追溯最后更新时间、数据源头、转化规则以及和其他数据集合的关联关系；唯一识别性体现在每一条记录都有一个唯一的主键和唯一的检索名，避免出现冗余数据；高扩展性是指数据属性纬度的高度可扩展性，例如对于人员属性和性别，可以针对不同语言、不同别名进行创建，而不会破坏现有数据存储结构。在本案例中，采用商业产品Stibo主数据平台进行数据的处理。

数据监控平台：对数据的质量进行可视化的预览，通过Power BI，业务单位可以随时查看自己的业务数据质量，对有质量问题的数据进行修改。

API管理网关：在学校信息化建设过程中，第三方业务系统数量会随着学校业务发展快速增加，随之带来了愈发严重的用户权限问题和数据共享安全问题。API管理平台可以把关数据权限和数据获取的历史进行记录，从而保证数据的安全性。

消息队列和内存数据库：在数据获取过程中，个别业务系统对数据的响应延时提出了更高要求。主数据平台加上API管理虽然能提供可靠、安全的数据请求管理，但这套组合在目前主流技术架构下，无法提供低延时的请求。解决方案是，通过消息队列和内存数据库组合的方式实现低延时的请求响应。消息队列存储数据更新的时间戳，内存数据库存放时间戳对应的数据。当消息队列中相关时间戳被消耗后，对应的数据从内存数据库释放，从而实现高性能的数据发布。同时，消息队列也可以用来解耦系统的关联性，实现业务系统数据的异步、削峰、解耦。当然，系统维护的复杂性和不稳定性也会因此增加，需要结合场景去考虑。

基于SOA的主数据改造

数据治理从传统的角度可以简化为以下生命周期：数据的获取，数据的转换和清洗，数据的标准化和模型化，数据的发布和归档。在项目开展之前，采用传统结构化的SQL模型进行数据的存储和管理。但是在实际运行中，因业务需求发生变更，导致数据的存储结构频繁调整，在调整过程中，对应的数据收集和数据分发接口产生重构，因此导致时效低、稳定性差的弊端。在参考相关文献建议后[5，6]，引入SOA技术架构的重组和改造。SOA的改造基本遵循上述流程。

但在实际场景中发现，数据标准化和数据建模更多依赖于数据发布的格式。因此，通过数据交换出去的格式，来反推数据的存储模式和字段，持续更迭模型之间的逻辑关系。具体来说，从数据的流程管理进行分析，先分析数据会被哪些业务系统使用，得出数据的建模方向。

在数据建模方面，基于NoSQL的主数据模型可以很好地处理因业务需求变更而带来的数据模型变更。基于NoSQL的主数据模型以主键作为对象的唯一标识，主键不一定限制于学号或者工号，任何一个能唯一标识一个对象的都可以作为主键。以课表为例，在课表标识上，采用教学班代码加学期代码作为唯一标识符，通过该唯一标识符构建属性组，例如上课地点、人员、课表等。得益于NoSQL的数据模型，数据对象属性的变更或者调整，对于数据接口中的抽取和发布影响较小。

系统在确定好数据模型后，开始数据清洗规则的配置，包括数据的转换规则，数据的筛选规则；在数据的清洗和抽取的过程中，采用主数据平台自带的数据标准转化功能，进行数据标准化；对数据进行追踪溯源，每一个数据字段都能追踪到最后一次的变更日期和操作者信息，从而得到可以直接交付给业务系统的黄金数据，即完整、准确、可追溯的数据。

基于数据可视化的质量控制

完成建模和数据清洗、标准化后，通过可视化工具进行数据质量的监控。可视化工具采用的是传统的报表工具。在业务逻辑上，传统的用户报表业务一般都定位于数据流程末端的展示层。但是在数据治理中，数据质量的监控和用户报表业务有明显区分。在监控层面，报表工具主要集中在空值、异常值，以及非标准值的监控。然而在用户报表业务，报表主要集中在用户关注的特定维度。以国家字段为例，在用户展示层面，更加关注国家数据，比如说外国留学生来源国家前十排名，以及海外留学生国家总数统计；在数据监控层面，报表更加关注国家字段中的空值、异常值，以及非标准数值，例如国家名称，有的写中国，有的写中华人民共和国。

基于消息队列的数据服务发布

在数据发布层面，针对不同场景，提供不同的技术发布模式。对于数据量小，并且更新相对不频繁的业务，采用Web Service的方式进行数据发布。针对数据量大，并且响应延时低的业务，采用消息队列以及内存数据库的混合模式，进行分发和管理。例如，对于浙江大学国际联合学院的门户网站黄页接口数据而言，数据包含照片等非文本文件，数据量超过20M，但要求内网门户在调用该接口的时候，响应延时不高于3秒。针对这样的场景，采用消息队列加内存数据库的模式进行数据分发。

具体而言，消息队列中存放数据变化的时间戳，该时间戳为前面提到的数据最后一次的更新时间。内存数据库中存放时间戳对应的数据。通过自行开发调度程序，定时将主数据平台中的相关数据最后更新时间戳推送到消息队列平台中。下游业务系统获取消息队列中时间戳信息，将该时间戳和内存数据库中时间戳主键进行对比，如果时间戳有变化，就从主数据平台更新最新数据，并且将该数据写入内存数据库用于缓存。如果无变化，直接读取内存数据中缓存数据。

本案例中，生产系统配置参数见表1，性能见表2。在未加载内存数据库缓存数据时，单个请求分别从主数据平台和无缓存的内存服务器读取，数据的平均响应时间分别为6.1秒和7.1秒，用户体验较差。将数据放入内存数据库后，响应时间下降到0.6秒，用户体验明显改善。在使用多线程模拟并发压力测试的情况下，内存数据库的延迟比例明显低于其他两种场景。

表1 生产系统配置

表2 接口响应时间 单位：ms

随着业务扩展，消息队列的数据量也会水涨船高，因此，也需要对对应硬件做相关的预估和规划。对此，应先统计现有的业务产生的消息队列数据，从表3可知，短期内现有硬件资源能满足业务的需求。值得注意的是，消息队列数据量的增长，并非线性增长，其原因有两点：首先，个别业务系统对于消息队列的数据需求，明显高于其他业务系统；其次，下游系统从消息队列获取数据，轮询时间隔较长，导致数据在消息队列停留时间较长。针对相关问题，下游业务系统可以依据业务场景和性能进行调整，避免后期可能出现的拥塞。长期来看，业务增长应属于缓慢增长，现有硬件资源可以满足后期业务开展。

表3 消息队列中数据条目及其对应资源消耗 单位：条

基于日志类型的数据分析

在项目实施后期，业务需求进一步提升。在日志型数据中，关键信息的抽取和交换需求开始浮现，传统的SOA架构已经无法满足日志型文件的存放，针对该问题，采用Hadoop生态群中的类SQL组件进行数据的抽取和加工。在分析Hive、Spark SQL，以及Impala后发现，Spark SQL性能最优，但是技术文档和稳定性有待提升，Hive和Impala文献比较充足，并且稳定性相对较高，在性能上Impala略胜一筹。因此，采用Impala进行数据的加工和关键信息的抽取，抽取后的结果数据会写入主数据平台。对需要存储的过程性数据，可存放在Hadoop的HDFS文件系统中，供后期调用。

浙江大学国际联合学院 数据治理成效

经过数据改造后，目前浙江大学国际联合学院交换平台核心数据质量从原来的77%准确性，上升到91%，其中人员核心数据的可靠性上升到99.9%。数据业务范围从人员数据扩展到课表数据、教室多媒体数据、会议室数据、住宿数据。日志类型数据每天实现300M以上的增量同步。接入应用系统从7个上升到21个。核心业务系统数据实效性从平均1天下降到20分钟。

从本次项目实施成效来看，SOA在传统的结构化数据治理方面确实有更好的扩展性；在日志类型的大数据层面，基于Hadoop的分布式系统更加具有优势。