基于数据中台的高校数据服务体系及快速应用构建研究

陆剑江

(苏州大学 计算机科学与技术学院，江苏 苏州 215006)

0 引言

随着信息化的不断深入，各种业务的数字化产生了前所未有的数据量，也生成了各种各样的数据类型，这些给数据的共享和利用带来了新的挑战，尤其是在一些互联网平台上，每天产生的数据对业务提出了更高的要求，此时，需要有更加灵活的、能力更强的平台来负责大量的数据处理[1]。传统模式下，每个业务模块仅会处理各自庞杂的数据，这样不仅效率不高，还会产生很多重复的工作，由于每个业务模块都是一个独立的数据孤岛，因此后续的数据交换和数据同步无法应对灵活多变的业务需求，而这种多样性的业务对数据的要求更高，数据本身的复杂性、对海量数据处理的要求、数据处理的实时性等都需要有能力更强的数据平台来应对[2]。

高校的信息化发展已经进入了数字化和智能化的时代，各种业务基本完成了数字化改造，目前最大的问题是存在各种数据孤岛，数据不能完全共享，各业务系统数据不能很好地为跨部门流程服务，无法处理非结构化数据，无法很好地支撑实时数据等[3]。为了解决上述问题，很多企业如阿里、腾讯和华为等，采用了数据中台(Data Platform，DP)的解决方案，将各业务模块中的数据处理模块进行整合，增加数据治理和数据服务能力，使其不仅具备传统数据仓库的功能，还具备对大数据处理的能力。通过数据建模、数据分析和数据服务，能够对各类数据应用提供更好的支持[4]。所以，高校可以借鉴企业的中台解决方案，在数据采集、数据加工和数据服务等方面进行全面改造和升级，从而让高校在大数据处理能力方面有很好的提升。通过构建数据中台，结合各类业务平台，则基于大中台、微服务的方式可以对原有系统进行解构，重新根据不同业务逻辑进行模块化组装，这势必将会逐步改变业务系统的建设模式。

1 高校数据中台架构

数据一般都依赖于各类业务系统在业务进行过程中产生，不同的业务系统由于没有统一的数据标准，生成的数据会出现各种不一致的情况，当需要把这些数据聚集在一起使用时，就会遇到各种问题。目前，解决这类问题的办法主要是通过数据的集成、加工处理成统一标准形式后，再进行共享的方式。通过建设共享数据平台可以在数据量不大、数据形式不多的情况下解决问题，但随着大数据的出现，以及对各种数据类型和数据实时性要求的提高，传统的数据平台已经无法满足要求，数据中台的概念应运而生。

数据中台是布署在底层网络计算存储资源之上、顶层各类应用之下的中间层。南向有各类的数据输入，即数据汇集；北向有各类的数据输出，即数据服务，数据中台负责对各类数据进行汇集、加工、处理和开发，最终将原始数据提供给各种具体的系统和应用[5]。高校数据中台的架构如图1所示。

图1 高校数据中台架构图

从图1的架构图可以看出，高校的数据中台主要包括数据采集(Data Collection，DC)、数据集成(Data Integration，DI)、数据治理(Data Governance，DG)和数据服务(Data Service，DS)等功能模块，各个模块负责数据流中各个过程的数据处理工作，存在DP={DC，DI，DG，DS}，可见，数据中台其实是各类技术的集合体，在上述基础上，还可以纳入更多技术，比如数据分析等。

从图1的数据流图来看，数据中台的整个工作流程如下：

(1)作为南向的数据输入，对各个异构的数据源进行实时或定时数据抽取，这些数据直接进入中台的数据湖(Data Lake，DL)，DL中存放各类数据源数据库的原始镜像数据。

(2)对照数据标准，对DL中的数据进行清洗、过滤等DG操作，经过处理的标准化数据根据各自的属性或类别，如教学、科研或财务，以及所属的具体应用，分别进入到对应的主题数据库或者专题数据库中，这个过程由DI模块负责。

(3)作为中台北向的数据服务和共享模块，中台还将生成各种数据接口，数据最终以数据服务的形式提供给各类应用。

上述几个步骤分别完成了DC、DI、DG和DS的过程，用户可以通过各类数据应用，从门户、APP和小程序等访问DP提供的这些数据。通常，中台还可以提供基于其中各层的数据，按照特定的指标进行数据分析的能力。

2 数据分层架构设计

数据来源于不同的数据源，为了对所有数据进行各类处理，需要把原始数据引入到数据湖中，中台对引入湖中的数据进行各类操作，不会对数据源有任何影响。数据湖支持任意数据源、任意格式、任意位置和任意复杂网络环境下的高效数据采集和传输，支持全量数据集成，支持数据开发、图形化、可视化实时监控[6]，支持各种类型的数据，包括结构化、半结构化和非结构化，实时的和非实时的数据。

数据从数据源到数据中台后，将对数据进行清洗、过滤等数据治理操作，经过一系列的加工处理，从而确保数据的质量。在构建数据中台的过程中，需要预先根据学校的业务对数据进行全面建模，建立各种主题数据库，如教工主题库、学生主题库等，这些主题库的结构、数据类型等即构成了各种主题域模型。如果有具体的应用需求，可以在主题库的基础上构建各类支撑特定应用的专题数据库，这些专题数据就形成了各种数据的聚合。经过治理后的数据，会根据所属的主题域模型，进入到不同的主题数据库中。可见，经过一系列数据操作，数据在逻辑上被划分为各个不同的层次。

如果用SL、BL、TL和ZL分别表示贴源层、标准层、主题层和专题层，则存在DP={SL，BL，TL，ZL}，根据不同层之间的逻辑关系，数据的具体流向为：SL→BL→TL→ZL，各层的历史数据定期在历史库中归档，各个层都是存储数据集的逻辑区域。可见，数据中台不仅是各种技术的集合体，同时也是各种数据逻辑层的集合体，各层之间的逻辑关系和数据流向如图2所示。

图2 总体逻辑信息架构和数据流图

从图2中可以看出，数据首先从内部或外部的各种数据源进入到贴源层中，此过程可能会有必要的数据类型转换操作，该层保存了全量的原始数据，所有数据表的库表结构及数据内容与数据源保持一致。随后，数据会进入到标准层，该层对数据进行标准代码转换、清洗过滤等操作，为后续的数据抽取做准备，这里保存了数据表在做标准转换之后和数据整合之前的状态。经过标准化处理后的数据，可以进入到主题层中，但在所有数据进入相关主题域之前，需要根据其存储的数据内容，判断其属于哪个主题域并存放在各自的主题域下，该层包含有最细粒度的原子数据，也包含经过简单计算和汇总的数据。为了服务于特定的应用，主题库的数据可以进一步生成特定的专题库，对应存放在中台的专题层中，有时为满足时效性等需求，专题层的数据可直接取自于贴源层，该层主要存放面向最终应用的数据，应用对数据进行的一系列操作也在该层中完成。

所有数据层的数据最终都会通过定期抽取存储到历史数据库中，这样可以减小各数据层的大小，提高数据读写效率，同时能满足对离线历史数据查询的需求，避免对源数据的重复抽取。

3 基于数据模型的数据服务体系

在数据中台的主题层中，可以根据业务场景，通过归纳、抽象，建立相应的主题域模型[7]。参考国标高校数据集，对于高校的业务活动，可以建立组织、人员、教学、科研、资产、财务和服务等主题域模型。首先对高校进行全域的逻辑模型设计，给出若干逻辑实体，然后设计相应的物理模型，即主题库和物理实体表，并为每一张表开发数据抽取、转换和加载(Extract-Transform-Load，ETL)的映射关系，同时根据表的数据特征，制定不同的ETL策略。

在专题层中，针对高校的具体应用场景，可以在主题域的基础上，就某个特定的具体应用，建立单独的专题域模型，如迎新、离校等专题域模型。

可见，数据中台的数据模型包含主题域模型和专题域模型。用D来表示数据，L表示数据项，M表示数据模型，S表示数据服务，假设存在n个数据项，则所有的数据项可以用一个向量来表示为：。每个数据项又包含不同的数据，则对于某个数据项li而言，存在﹛li，﹜，表示某个数据项所包含的所有数据。

类似地，存在﹛mi，﹜，表示某个模型所包含的所有数据项；{si，}，表示某个服务所包含的所有模型集合。

可见，S、M、L和D共同构成了一个树形结构，表明与特定服务相关的所有模型、数据项和数据的集合，存在DS={D，L，M，S}，构建了从数据→数据项→模型→服务的层次体系结构，其逻辑结构如图3所示。

图3 数据服务体系层次结构图

从图3可以看出，数据中台不再直接提供数据，而是提供接口服务，接口不属于某个特定的数据应用，而是部署在统一的数据服务中，而且接口可以在不同的数据应用之间进行共享。可见，数据服务打通了数据和应用之间的访问链路，建立了从数据应用到数据中台的全链路数据血缘关系，从而构建了基于(D，L，M，S)层次结构的，包含了服务封装、服务发布和服务授权的数据服务体系。通过该数据服务体系，可以在数据模型的基础上，为新系统的构建快速提供基础数据，协助新系统更快上线。

另外，在数据中台中，通过建立主题域模型，基于元数据和规范定义进行建模，构建主题逻辑表，提供主题式的数据服务，通过统一的数据接入层，屏蔽多种异构数据源，可以实现跨源数据服务[8]。经过封装的数据服务，可以由不同应用系统调用，实现灵活的数据共享，减少重复开发，满足不同应用数据在时效性、开发成本等方面的要求，还可以提供一站式数据查询和分析等服务。

4 基于数据中台的快速应用构建

数据中台汇聚了各类业务系统的数据，经过数据治理和数据加工，形成了各类主题数据和专题数据，尤其是专题数据，可以为某个特定应用场景提供数据支撑服务。如数据中台支撑数字迎新系统的构建和运行就是一个典型的案例。数字迎新流程涉及学校的多个业务部门，需要使用各个部门的数据来共同完成迎新过程，在这样的场景中，传统的、功能单一的共享数据平台已经无法满足要求，而汇集了数据集成、数据处理和数据服务功能的数据中台可以轻松完成任务[9]。

一般而言，迎新的业务流程是新生在各个部门办理各种报到手续的过程，与此同时，新生的各种数据也同步在各个部门之间进行流转，这便形成了迎新的数据流。从招生、教务、宿管、人武部、信息中心、财务、学工到学院等，各个环节都会分享和生成相关数据。在迎新办理现场，新生的实时报到数据还会在相应环节进行实时交互，这些数据来自于诸多不同的业务系统，这些系统的数据在结构、形式等方面并不统一，无法完成数据的直接交互处理。如果采用基于数据中台的模式来构建迎新系统，可以在统一数据标准和数据服务的前提下，模块化地搭建迎新系统的各个功能，采用大中台、小应用的模式，快速构建各个阶段的数据处理任务[10]。

基于数据中台的迎新系统架构如图4所示，可见数据的流向为各个数据源→数据中台→各业务平台→各迎新应用，参照数据中台的作用，这里的各类业务平台共同组成了业务中台，可以理解为，迎新所涉及的各类应用是在数据中台和业务中台的基础上快速构建起来的。比如站群平台可以构建PC端和移动端的迎新网站，消息平台可以构建迎新系统中各种消息推送，身份认证可以用于迎新系统中人员的身份登录授权，缴费平台可以用于迎新中各类缴费业务，流程平台可以用于迎新中各种跨部门的流程应用，业务中台的所有数据都来源于数据中台，所以，迎新系统各个功能模块的构建可以从这些大的已有平台中直接生成，这样不仅能减少重复开发，还能实现应用的快速灵活构建。

图4 迎新系统架构图

从数据中台的角度看，构建类似迎新这类跨部门流程的系统可以按如下步骤进行：

(1)将迎新所涉及的各业务系统的数据通过数据采集模块集成到数据湖中。

(2)根据数据中台的数据标准对这些数据进行清洗和过滤等操作，形成统一的标准化数据。

(3)依据不同的类别，将这些数据分别归属到不同的主题域中。

(4)生成迎新专题库，后续所有和迎新相关的数据操作都将在该专题库中完成。

(5)在专题库的基础上，定制相应的数据服务接口，用于外部程序访问数据中台的数据。

(6)利用现有各类公共平台的能力，构建迎新业务的通用功能模块，如身份认证等。

(7)利用门户的集成能力，整合上述各类功能模块，为用户提供个性化的、统一的服务入口。

通过上述步骤，可以在数据中台结合各类业务平台的能力，快速拼装式地构建一个迎新系统，结合数据中台的大数据分析能力，为迎新提供实时的数据处理和分析能力，同时由于各个模块之间是松耦合的关系，后续在统一数据中台的支撑下，可以随意升级各模块的功能，不会影响整体的迎新服务。

5 结束语

数据越来越多，也越来越重要，这一切都为中台孕育了很好的土壤，尤其在高校里，业务部门众多，业务系统繁杂，对于数据的采集和治理都是一个不小的挑战。随着图像、视频等应用的增多，对于非结构化数据的处理要求也越来越高，另外各类大数据分析以及实时的数据交互等都是不小的挑战，对于这些而言，数据中台都可以轻松化解。但是高校数据中台的建设不能一蹴而就，应该是一个循序渐进的过程，属于技术和管理结合的综合范畴。从技术上讲，需要有数据库、数据抽取工具、数据治理平台、数据接口平台和数据分析平台等；从管理上讲，需要协调各业务部门配合提供数据，合理使用数据，数据流的每个环节都在中台里扮演着重要的角色。作为学校的数据中枢和数据加工工厂，中台将汇集所有的数据，这些数据经过一系列标准化处理之后，再分享到学校日常活动的各个环节。

高校的数据孤岛现象可以在数据中台的驱动下逐步得到改善，高校的信息化建设模式也可以在中台的影响下逐步发生改变，大中台、小应用的模式将来会逐步取代如今各个庞大臃肿的系统，换来系统的快速迭代和需求的快速响应。中台的成熟应用，将会使得高校的数字化转型进入到一个加速车道，高校的信息化建设也将进入到一个飞速发展时期，逐步向更高阶段跨越。