经过多年的实践和探索，随着数据治理工作的不断深化，高校数据管理体系逐渐成形。高校同时也面临着数据治理的落地问题、管理问题和运维问题。本文以西安电子科技大学数据治理工作六年的实践探索为例，介绍首次提出的“基于厚中台的高校数据管理体系”，尝试回答高校数据治理中遇到的问题和挑战：　　如何构建高校数据管理体系和管理规范？如何支撑系统建设、业务管理、个人填报、统计填报中的用数需求？如何实现高校数据管理体系的自主运维？高校数据管理体系　　构建高校数据管理体系，首先我们需要将数据作为一种资产考虑，不同于其他的资产，数据资产的价值可能会随着时间的推移变化，但数据本身是持久的，不会磨损。数据是黄金、是石油，也是数字经济的基础；但是如果没有管理，数据不可能成为黄金，甚至还有可能会成为巨大的风险。数据管理是为了交付，控制，保护并提升数据和信息资产的价值，是在整个生命周期中对规划、策略、程序和实践进行的开发、执行和监督活动。根据国际数据管理协会（Data Management Association，又名DAMA International，以下简称DAMA）提出的数据管理框架，数据治理处在数据管理的核心位置，见图1。为了真正体现数据的价值，数据必须以一种科学的方式被管理起来，本文不讨论详细的数据管理技术，仅从管理视角探讨高校数据管理体系。图1 DMBOK2数据管理框架DAMA车轮　　数据管理范围　　高校能否将数据作为资产管理起来，管理起来的数据是否有标准，数据质量的好坏，都最终决定了智慧校园建设的高度。要构建数据管理体系，首先要明确数据管理的范围。在西安电子科技大学（以下简称学校）的数据管理体系中，数据分为以下三类：物联数据、业务数据、日志数据。其中业务数据又分为线上数据和线下数据。线上数据根据采集方式的不同分为库表数据和接口数据，如图2。图2 高校数据管理范围　　物联数据：智慧校园建设的物联网设备，包括人脸识别设备、智能锁、热成像仪、各类传感器等等，这些智能设备产生的数据我们称为物联数据。物联设备协议模型主要描述感知设备是什么、能做什么、可以提供什么样的感知数据、能够产生的事件信息等。物联数据的管理、存储和使用方式都跟业务数据和日志数据有很大不同，所以物联数据需要与其他数据分开考虑。　　业务数据：业务数据是指高校各个行政管理部门和学院在管理工作过程中产生的结构化数据，例如人员基本数据、学生成绩数据、科研项目数据等。通过信息系统生产、管理、消费的业务数据，我们称之为线上数据。线上数据又因为交换方式的不同，分为库表数据和接口数据。业务系统通过ETL（Extract-Transform-Load）方式交换给数据中台的数据称为库表数据。业务系统通过API(Application Programming Interface)方式交换给数据中台的数据称为接口数据。接口数据对接的技术成本较高，其管理也需单独考虑。另外还未建设信息系统的部门，或信息系统未纳管的业务产生的数据，一般存储于Excel、Word表格中，这样的数据我们称为线下数据。线下数据往往是数据消费中很重要的一环，我们必须在数据汇聚环节就统筹考虑这部分数据的采集方案。　　日志数据：日志数据指IT系统产生的过程性事件记录数据，包括系统日志、网络日志、设备日志等等。日志数据大多为半结构化数据，需要进行结构化转换后才可交换给下游使用。　　数据管理体系架构　　学校数据管理体系从业务视角看自顶向下依次是应用展示层、应用中台层、数据中台层（厚中台）、数据接入层。　　数据接入层：通过统一数据集成管道、日志平台、物联中台集成工具、数据补录平台，将业务数据、日志数据、物联数据、线下数据接入相应的数据中台数据湖中实现数据汇聚。　　数据中台层：不同于一般意义上的数据中台，学校在传统数据中台的基础上提出了“厚中台”的概念。传统的数据治理仅限于业务数据，重治理，轻管理。但随着物联网的发展，物联网设备开始在高校教学科研管理工作中发挥重要作用，同时移动互联网的普及和各类传感器的应用，也让数据采集的成本降低，规模扩大。学校提出的厚中台模式，将物联数据、业务数据以及其他一些汇聚成本高的接口数据和日志数据统筹管理，同时向上延伸，将数据的管理运营工作碎片化到数据全生命周期的各个阶段。其中，物联数据中台负责物联数据的接入、治理和开放。业务数据中台管理业务数据的接入、治理、标准建设、数据开放和日志数据的接入、结构化。厚中台厚在：向下扩展了数据管理的范围，向上拓宽了数据开放的方式和途径，向内完善了数据管理的规范，向外增强了数据服务的能力。　　应用中台层：应用中台层是数据中台和应用之间的过渡层，根据学校信息化的顶层设计思路，为了充分发挥信息化工具的能力，最大限度地向师生提供服务，避免校内应用分散，消息不畅，流程不通等问题，学校要求系统上线运行前需要与统一身份认证、一网通办、统一流程平台、统一通讯平台、统一移动平台、统一支付平台等校内统一支撑平台对接，对有相关功能的系统提供统一的业务支撑。　　应用展示层：应用展示层是校内各类应用对数据的使用层。业务数据中台管理体系　　业务数据中台主要管理业务数据的汇聚、治理、标准建设、质量检测、数据开放。本节主要讨论业务数据的全生命周期管理流程。从图3可以看出，学校业务数据中台在传统数据治理的模式之上完善了数据集成的范围，拓宽了数据开放的维度，实现了全异构数据集成和多维度数据开放。图3 业务数据中台管理体系　　全异构数据集成-厚集成　　传统数据集成，大部分都只集成业务系统产生的结构化数据，但这样很多高利用率的线下数据和日志数据在采集之初就被忽略了，更无法交换利用。业务部门信息系统在建设之初大多只考虑本部门的核心业务，那些没有被系统管理起来的业务所产生的数据往往都与师生的个人填表类业务相关，比如精品课程、获奖数据、课外活动、教学改革论文等数据。学校基于实际需求提出数据采集应包括线上数据、线下数据、日志数据、接口数据四类，称为厚集成。学校通过统一集成管道（ETL工具）、数据补录工具、日志采集工具、接口集成工具完成了线上数据入库、线下数据的线上化、日志数据的结构化以及接口数据的入库工作。采集后的数据通过平台完善数据语义和标准，发布成接口供下游调用。学校从而打通了线下数据和日志数据的全链路使用。　　线下数据接入：线下数据使用“数据补录工具”接入，实现线下数据的线上化。线下数据接入必须重视和建立完整的数据接入规范。业务部门提供的线下数据表格与可使用的库表数据中间相差甚远，需要对线下数据表格进行治理。治理分两个层面：　　系统层面：数据补录类系统在接入数据的时候必须设计严格的数据校验规则，校验代码，增加主键，对冲突编码进行映射，增加日期、身份证号码、电话号码等特殊字段的格式校验规则，设计数据去重等功能。　　管理层面：负责数据补录的管理人员必须对业务部门提供的原始表格数据进行转换和编码。要求业务部门增加主键，增加代码表，备注业务含义，将原始的Excel表格转化成相对规整的入库数据，有时也需要解决线下数据标准和现存标准冲突的问题。严格执行脏数据不入库原则。这样也能在一定程度上指导数据产生过程的规范化，从源头提高数据质量。　　线上数据接入：线上数据使用统一数据集成管道接入。区别于一般的数据对接方案，学校数据对接有以下几个规则：　　规则1全量接入：对业务系统产生的结果数据全量接入。全量接入有几个优点：数据一次性对接入湖避免反复对接；业务系统方无对接工作量不产生费用；对接后按需治理灵活取用。　　规则2三人审定制度：线上数据对接的核心问题是，如何保证对接的数据的完整和规范。为了解决数据对接过程中经常出现的漏数据、无标准、业务含义不清晰等问题，学校制定了数据对接三人审定制度。系统方需要开通一个高权限的测试账号（账号最好是统一认证对接期间提供给系统的认证测试账号），主对接数据人开始数据对接工作后需要与其他两名数据对接人员一起进行系统功能解读，通过系统模块确认系统所产生的业务数据集范围，同时与系统方开发确认模块对应的库表数据结构，确认库表数据的关联关系以及业务含义。同时将数据对接人、数据审定人、字段释义、表关联关系、业务含义等信息维护至数据中台的业务元数据模块中。这样数据作为接口共享出去，才能保证数据消费方充分理解数据含义，同时也可保证数据对接过程中管理问题溯源。　　接口数据接入：有的系统由于各种原因无法提供数据库访问链接，提供了API文档。API是软件库提供的一组可访问的接口，软件库通过API向外提供服务，开发人员通过使用API实现代码复用，提高生产效率。API文档数据对接需要定制开发对接接口，对高校管理教师来说有一定的技术门槛，学校使用接口集成工具解决这个问题。利用内置的常见接口对接模板配置对接方案，使用FDI（Fast Data Integration）模块实现接口数据向库表数据的同步。　　日志数据接入：通过日志采集工具接入日志数据。定义采集任务将原始日志数据采集至数据中台的HDFS（Hadoop Distribute File System）环境中。日志数据由于是非结构化数据，所以需要先使用工具进行结构化，在结构化的过程中需要提前定好命名规则和采集模板，这样能减少后期的运维成本。　　多维度数据开放-厚开放　　不同类型的数据接入汇聚后，在数据湖层面做数据治理，再将治理后的数据接入数据仓，在数据仓库层面做历史数据的存档和数据标准的建设。然而经过治理的数据如果不能交换使用起来，那永远只能停留在数据治理的理论阶段。应用和业务部门不充分使用数据，只能治理出数据结构上的错误，而不知道数据逻辑是否正确，所以要让数据充分地使用起来。很多高校做到这一步就遇到了瓶颈，不断地治理，不断地产生新的脏数据，而治理后的数据还是支撑不了决策需求和填表需求。这是因为数据治理完成之后，还需要使用不同的开放模块来满足不同的应用需求。学校建设了多维度数据开放体系，包含统一数据开放模块、数据资源目录模块、一张表模块、指标计算模块，用来支撑不同的用数需求，称为“厚开放”。　　统一数据开放模块。针对新信息系统的建设，使用数据中台的统一数据开放平台模块提供数据共享服务。开放四类数据集，包括标准数据集、应用数据集、主题数据集、指标数据集。新建业务系统可以在数据中台申请使用数据接口。通过对接口的审核，可以控制接口的开放时间和接口调用次数。通过字段级别的控制，可以将数据开放以最小粒度精准地下发，保障数据开放的准确性。通过对字段脱敏或者加密，保障数据使用的安全性和保密性。　　系统建设场景下的数据共享，需要考虑数据如何按需精准下发。学校通过细化数据对接申请流程、数据需求审定两个方式保证数据的良性使用。　　一是数据对接申请流程。需要建设新系统的业务部门负责老师在“一网通办”门户中发起数据对接申请，在线同意数据保密协议，部门负责人审核后交由数据中心领导审核，数据中心领导确认后交由数据中心技术人员进行数据对接工作。为了避免系统使用后期企业人员变动和维保到期导致数据接口无人更新维护，系统无人运维等问题，学校采取系统建设单位担保申请、系统建设方责任人制，同时监测接口数据使用情况，定期清除僵尸应用，定期更新系统运维信息。　　二是数据对接需求审定。根据系统建设方提供的数据需求字段，信息部门数据对接人员需要组成需求审定小组，对数据对接的需求进行拆解，帮助系统建设方对应至具体的数据接口，提升数据对接的准确率和系统建设效率。数据下发规则：按照数据分级分类以最小子集下发。　　数据资源目录。针对校内各个职能部门和学院，也就是数据的产生方和管理方，学校通过数据资源目录盘点校内数据资源，并将数据盘点情况开放，让各部门可以全方位了解本部门的数据情况和学校数据治理的进展。我们将高校数据以资产的形式进行线上管理，从学校、部门、科室三个维度展示了数据地图、数据模型、数据资源、采集清单、数据交换情况和数据质量报告。　　数据资源目录作为厚中台体系中数据与用户见面的门户，全方位多角度展示了学校数据资源情况、数据交换情况、数据质量情况、数据管理情况。这是我们做数据分级分类管控和精准下发的基础。学校的数据资源目录可以管控到字段级别的交换情况和质量情况，这归功于学校厚中台体系中，对数据交换过程的全链路配置和监测。　　“一张表”模块。高校还有一类个人数据填报类需求，例如职称评审或年终考核，即使高校完成数据治理，建设了数据标准，数据中台的数据依然很难满足这类需求的用数要求。这可能是多种原因造成的：数据源头（数据管理单位）未产生相应数据或者相应字段；填报所需数据未被管理（存在于线下）；业务系统初始设计模块未覆盖本单位全业务；系统中数据不全等等。这就要求我们在数据中台和填报类业务中间必须构建一套个人数据纠错补录的平台，我们称之为一张表系统。一张表系统将中台数据重新组织，以个人维度展示给校内师生，教师经过补充勘误后形成一份新的数据，我们将这样的数据开放给各种填报类业务，如图4。图4 一张表工作流程　　指标计算模块。除了以上数据使用和管理需求，高校还有一类统计填报类需求，例如高基报表、“双一流”指标填报、学科评估指标填报等。这类统计数据具有数据涉及范围广、数据统计量大、涉及部门多等特点。而我们前期数据治理，治理的都是基础数据表，数据中台不负责计算具体统计指标。为了解决这类用数需求，我们建设了指标计算模块来进一步将基础数据计算为统计指标，然后将指标发布出去供各类统计填报类需求应用调用，这样可以在一定程度上解决指标数据统计口径不一致和多部门填报难度大的问题。　　以上四类数据开放入口共同构成了学校的数据开放体系，完成了系统建设、业务管理、个人填报、统计填报四个维度的用数需求。　　通过数据接入、数据治理、数据开放，学校数据管理体系实现了数据从采集、转换、治理、开放、使用的全生命周期管理。传统方式的数据治理，大多数工作都是线下开展，治理的结果无法通过平台监测，也无法及时反馈回业务系统，源头数据改变或者标准改变，信息部门无法及时掌握，导致数据质量无法实质性提升。校内师生和业务部门的管理老师无法对数据真正感知，也不清楚自己部门和科室所管理的数据情况。应该以元数据为起点，将数据以资源目录的方式展示给业务部门。从采集、汇聚、交换、数据质量四个维度全面展示本部门视角下的数据情况，全链路监测数据的变化情况，提升数据质量。对信息部门来说，实现了数据监管过程中全流程告警和线上处理，全局贯彻数据标准和数据质量。对接了学校企业号，实现了移动端数据审核和接口告警提示，实现了全自主运维数据接口体系。高校数据管理自主运维体系-厚运维　　数据治理工作要真正落地，高校必须要有自己的运维团队。学校从2016年开始到现在已经建成了9人的运维团队，涵盖了从数据采集到数据对接再到数据监测的全生命周期数据运维，不止负责安全全面地将数据接入数据中台，而且负责精准高效地将数据开放给用户，称为“厚运维”。　　上游数据对接组：针对新建业务系统数据接入数据中台的需求，由用户单位在一网通办发起申请，数据中心领导指定对接组负责人负责本次需求对接。负责人组建三人对接小组进行需求审定，对接过程需要请系统建设单位负责人、厂商的主开发、厂商产品参与，根据系统功能和数据字典，确定数据对接标准、范围、更新频率等，开发数据接口。需求审定小组的作用是防止数据遗漏，防止接入脏数据。而了解每个系统的功能，才能更好理解数据之间的关联关系，为将来下发数据、分析数据夯实基础。对接原则：规范标准，应接尽接。　　数据标准审定组：对新增数据，我们要进行分级分类、数据确权、标准更新、元数据注册、主数据完善和开启历史数据备份等工作。数据对接组对接完成后，将对接阶段的资料交给数据标准审定组组长，由组长组建三人小组进行数据治理工作。首先根据《西安电子科技大学数据分级分类办法》对数据定级分类，注册元数据后审定当前数据是否是新增标准，如果是，则更新数据标准，对重要数据需要开启历史存档和备份，最后发布数据接口到正确的分类集下供下游调用。审定原则：合法合理，分级分类。　　标准数据集：经过与校内各业务单位确权的标准数据集。比如人事管理数据集。　　非标准数据集：使用标准数据产生的二次加工数据集。　　主题数据集：为某类主题需求定制开发的应用集。比如统一身份认证数据集。　　应用数据集：为某个应用定制开发的数据集。　　指标数据集：由指标平台加工的指标数据集。　　下游数据对接组：用户需要使用数据中台的数据时，在一网通办提起申请，由数据中心领导分配给对接组组长，对接组组长分配给目前较为空闲的对接人员，配合用户进行数据工作，并按照数据分级分类和下发规则审核接口。如果对接需求是简单的数据接口调用，则对接完成后由组长复核。如果对接的是数据分析类需求，也就是需要进行数据加工和数据处理，则由组长按照需求组成数据处理组，分配后开发数据接口，发布后通知用户调用。数据对接人员也将负责接口整个调用期内的业务问题。对接原则：按需下发，用户至上。　　数据接口运维组：数据接口运维组负责保障所有数据接口的平稳运行。运维组全员参与，按照上下游和业务类型分配运维接口，配置运维告警通知，及时监测接口状态。同时负责处理接口故障和问题。运维原则：按时巡检，及时处理。　　数据质量监测组：数据同步至资源目录后，数据质量监测组负责数据质量检测，每年为各部门出具数据质量报告，同时负责已有标准的维护、映射和代码变更。监测原则：科学全面，客观准确。　　基金项目：2020年中央改善基本办学条件-统一支撑平台与网络安全服务（一期）（编号：20201200001）　　来源：《中国教育网络》2023年10月刊　　作者：马倩雯、郭涛、吴琳、马蓁（西安电子科技大学信息网络技术中心）　　责编：余秀 网址:www.tianqi114.cc