智慧校园陪伴支撑系统设计研究

摘要：为解决陪伴开展过程中日益个性化和精准化的需求，文章设计并实现了基于数据中台的陪伴支撑系统。在分析数据中台技术架构的基础上，设计了其与陪伴支撑系统的数据互动架构，并结合业务需求进一步细化了系统功能。系统充分利用了数据中台对数据存储、汇聚和分析等方面的能力，对学生相关数据进行分析，提升了数据的利用程度和业务支撑力度。同时，通过对学生综合信息的展示、预警信息、陪伴体系和陪伴过程的管理，实现了对学生工作队伍的数据赋能，有效支撑了个性化和精准化陪伴的顺利开展。

关键词：智慧校园；数据中台；大数据分析；陪伴支撑

数据日益成为智慧校园建设的核心资产，随着物联网和人工智能技术的日趋成熟，智慧校园中出现了越来越多的用于感知环境和人的终端设备，不断丰富着智慧校园中的数据类型和数量。同时，为进一步发挥数据价值，不少高校启动了数据中台建设。通过数据中台，不同方式产生的大量数据可以汇聚在一起，经过清洗、融合和分析后，助力高校在管理、教学、服务等方面实现高质量发展。学生工作管理对于学生成长成才有着重要的影响和作用，而对学生的陪伴则是学生工作管理中的基础工作内容。随着“00”后新生步入大学以及招生人数的不断增长，学生对陪伴的需求，也在逐步个性化和精准化。传统的学生工作管理系统在面对此需求时，则显得很吃力。主要因为，一是传统系统大多是将线下的流程搬到线上来开展，比如评奖评优、资助管理等，而对于开展线下业务的支撑方面则关注较少。二是传统系统虽然基于校内数据平台开展建设，但是受限于数据平台和系统本身对大数据存储、汇聚和分析的能力不够，导致对数据利用的程度不足，只能实现部分数据的互联互通，如学籍信息的同步等。面对此需求，需要新的方式和手段，在充分利用数据的基础上，支撑学生工作队伍开展个性化和精准化的线下陪伴活动。目前，文献[1]基于Hadoop生态，设计并实现了高校学生行为预警平台，重点介绍了行为预警模型。文献[2]基于大数据，设计了学生行为综合分析与服务平台，实现了对学生日常学习生活的动态监测。但是，以上两个平台并没有涉及预测和分析后的陪伴过程以及反馈信息的管理，且数据分析和业务实现在同一平台中，一定程度上影响了数据分析结果的共享和复用。目前，数据中台在数据分析、共享和复用方面具有较好的能力，文献[3-6]对数据中台的相关内容做了介绍，并分别从数据模型、可视化、应用研究等方面进行了探讨。本文基于以上的情况，设计并实现了基于数据中台的陪伴支撑系统，在对数据进行清洗和转换后，形成学生个人综合信息展示，全面体现学生在校期间的表现。同时，在对数据进行分析的基础上，围绕学业困难、家庭经济困难等类型，对学生进行预警，提醒学生工作队伍进行线下陪伴，并提供线下陪伴反馈功能，一方面可记录陪伴过程中发现的其他类型困难情况，如心理健康情况、身体健康情况等；另一方面也可对预警信息进行标注，对预警周期进行调整，有利于进一步改进预警方法。

1数据中台

1.1数据中台技术架构

数据中台旨在数据治理和数据集成的基础上，通过对各类数据的清洗转换和分析，并按一定的数据逻辑模型进行存储，形成随时可用的主题数据。同时，通过数据服务接口或数据推送的方式，进行数据下发，逐步构建“大中台、小前台”的发展模式，支撑和适应业务的快速发展。本文中使用的数据中台主要包括数据集成、数据存储与管理、数据治理、数据服务4个部分，其技术架构如图1所示。数据集成主要有服务于传统关系数据的ETL集成工具，服务于日志类集成的Flume组件以及服务于消息类集成的Kafka组件。数据存储与管理过程中，则使用HDFS分布式文件系统进行贴源数据存储，再通过Spark组件和数据开发组件进行数据处理，处理后的数据存储在MPP可高速并行处理的关系数据库中。数据治理是在数据存储和处理的过程中，通过数据治理组件进行数据血缘、数据质量等管理，提升数据可用性。数据服务是通过数据服务接口的开发以及ETL集成工具的推送，将数据中台的数据，提供给业务系统使用。

1.2数据处理过程

数据中台在对数据处理的过程中，采用了分层处理机制，分为贴源层、标准层、主题层和专题层。其中，贴源层主要存储从业务系统直接同步过来的原始数据；标准层则存储经过标准化转换和处理后的数据，此时数据依然按照业务系统进行分类存储；主题层存储的是按照数据逻辑模型，重新进行分类后的数据。如人员库中，主要有从人事、教务、研究生系统中经标准化处理后的教职工、本科生、研究生的人员数据。专题层则是按照数据的使用用途进行分类存储，如人事系统专题库、教务系统专题库。

2系统架构

2.1数据互动架构

智慧校园中，传统的业务系统与数据平台的互动一般包含两个部分：一是数据平台将其他业务数据采集并清洗后，通过ETL工具下发到业务系统，剩余的数据使用过程交由业务系统自行处理。二是业务系统将自身产生的数据共享出来，通过ETL工具同步到数据平台，供其他业务系统使用。相比于传统的互动方式，基于数据中台构建的陪伴支撑系统，需要使用数据中台对数据存储、汇聚、分析等方面的能力，与数据中台之间的互动更加的紧密，其互动架构如图2所示。（1）数据中台将传统的基础数据，如部门、人员基础信息等下发到业务系统；（2）业务系统将数据分析过程中，需要使用到的参数信息，共享到数据中台；（3）数据中台将分析后得到的分析结果，通过数据同步或数据接口的形式，下发到陪伴支撑系统；（4）系统将分析结果的反馈信息，共享到数据中台，以便进一步优化分析过程和方法；（5）系统将沉淀的业务数据共享到数据中台，以便清洗转换后，供其他业务系统使用。以上互动内容，在满足陪伴支撑系统需求的同时，也使得数据分析过程和结果沉淀在数据中台。这样，一方面当系统因业务需求进行功能调整时，数据分析部分可以复用。另一方面，已完成的数据分析结果也可共享到其他业务系统。

2.2系统架构

基于数据中台，系统架构如图3所示。主要包含行为指标项管理、预警管理、陪伴体系管理、陪伴内容管理、结果库管理和行为与陪伴总览。其中，行为指标项管理和预警管理，主要是进行参数配置和调整，以支撑数据中台进行数据分析；其他四个模块则是基于预警数据开展陪伴的业务支撑模块。行为指标项管理主要用于定义学生行为并进行分类，同时指定该指标项对应的数据源头信息，如食堂就餐次数、快递收件次数、志愿服务时长等。预警管理则是在指标项的基础上，配置预警的具体信息。其中，预警类型定义了需要预警的学生类型，如家庭经济困难类型、学业困难类型等；预警级别管理则配置各类型对应的预警级别和相应的显示颜色，同时用于匹配相应的陪伴体系；预警条件管理则具体实现预警内容，挂接指标项、指标字段、默认预警阈值、归属预警类型、归属预警级别等。归属预警类型和预警级别允许为空，当为空时，此预警条件一般用于构建组合型预警条件；预警组合管理支持将不同的预警条件进行合并形成新的预警条件，如一周不在食堂就餐并且一周没有门禁刷卡记录，可组合后形成疑似不在校预警条件；预警阈值管理主要是向各个学院开放默认阈值的配置，不同学院可以针对学院特点配置不同的阈值；预警周期管理则是用于配置预警条件的计算周期和同步周期，比如学生志愿服务时长预警是按学期为单位计算且按学期同步的、疑似不在校预警则是按周为单位计算并按天同步的。陪伴体系管理主要用于构建服务于不同类型和不同级别预警的陪伴内容，如家庭经济困难三级预警和学业困难二级预警，就对应了不同的陪伴体系和方法。其中，陪伴来源管理主要是配置每个陪伴项的数据支撑方式，对于已有系统采集的一般选择系统同步方式，没有系统采集的则选择手工录入的方式。如陪伴项中的给予经济资助数据，来源于资助系统；进行感恩诚信教育，则来自辅导员录入。陪伴内容管理是结合预警信息和对应陪伴体系开展线下陪伴的主要支撑模块。一般情况下，辅导员发现预警信息后，结合对应陪伴体系开展工作并录入陪伴情况。过程中，对于个别较为特殊的情况，可针对性的调整预警周期，如学生一周后参加比赛，最近需要晚回宿舍，就可以将对应的晚归预警暂停一周；对于需要重点帮扶和陪伴的学生，可推荐进入结果库，方便给予更大的常规化的陪伴支持。结果库管理包含在库学生的信息查询、各类统计以及取消管理。依据不同类型，结果库的学生数据会被共享到不同的系统中，如家庭经济困难数据会共享到资助系统，学业困难数据会共享到教务系统，以便形成陪伴合力，助力学生成长。

3系统实现

3.1流式数据处理

在陪伴支撑系统的设计和实现过程中，除了需要传统的校内业务系统产生的关系数据外，还需要其他类型的数据支撑。比如上网行为、人脸识别等流式数据。这些数据需要依靠数据中台来完成采集和处理。对于上网行为数据，主要使用Flume组件进行采集和处理。对于人脸识别数据的处理，主要使用Kafka组件。当人脸识别系统获取到人员信息后，调用Kafka接口，将识别信息送入指定的Topic通道。同时，通过数据开发，将数据从消息通道中读取出来，读取的过程通过实时调度的方式运行。这样，人脸识别的数据就可以实时的进入数据中台关系数据库。识别后的数据主要包含学号、识别位置、识别时间等。陪伴支撑系统可通过对位置信息的定义和引用，形成不同的指标项。比如：出现在操场附近信息，对应于体育锻炼次数。由于网络日志信息和人脸识别信息数据量较大且涉及个人隐私较多，加之陪伴支撑系统中对于此类分析指标项主要使用统计数据。所以，除历史数据存储外，在数据中台中另外建立了只存储7天信息的数据表（即，当天数据进入后，删除7天前的数据），具体的数据处理从此表中读取，以天为处理周期统计学生行为信息。

3.2预警信息计算

在获取到系统配置信息后，在数据中台建立了陪伴支撑系统专题库。在专题库中一般按照如下的过程进行计算：第一步，按照指标项配置信息，分项计算每个学生的数据情况；第二步，依据预警周期配置，形成需要计算的预警条件列表；第三步，按照预警条件配置信息，按学院计算非组合型预警条件产生的预警信息，预警信息一般包括预警编号、预警学号、预警信息、预警时间等；第四步，依据预警组合逻辑，按学院计算组合型预警条件的预警信息；第五步，去除掉归属预警类型和归属预警级别为空的预警条件对应的预警信息；第六步，依据预警暂停信息，去除掉对应的预警信息；第七步，依据各预警类型对应的预警条件和指标项信息，去除掉已在结果库中的学生对应的预警信息。预警数据在经过调度同步到陪伴支撑系统后，也将同步到预警历史信息库中，结合预警反馈信息，为进一步优化指标项和预警条件提供依据。

3.3学生综合信息查询

学生综合信息查询对于陪伴过程的开展具有重要的支撑价值。在实现过程中，系统汇聚了250多个字段，并将学生信息分成信息总览和10个明细信息，如图4所示。在数据总览中，主要体现学生的学籍信息以及如GPA信息、欠费信息、困难类型、健康状况和基本描述等重点信息。在明细信息中主要有家庭信息、第一课堂、第二课堂、录取信息、目标总结和规划、奖惩信息、人际交往、生活行为等。学生综合信息查询有利于学生工作队伍快速地对学生有个初步的了解。尤其是当需要引入其他陪伴人员开展线下陪伴的时候，如创业导师进行创业辅导时，通过此功能将有效提升陪伴质量。图4学生综合信息查询

3.4陪伴过程管理

在陪伴过程管理的实现过程中，依据陪伴发起的源头不同，分为预警驱动和线下陪伴驱动两种方式。预警驱动，是指依据预警信息，有针对性地进行陪伴，并反馈预警结果和陪伴内容。线下陪伴驱动则是在线下陪伴先发生后，依据线下陪伴过程，再线上关联陪伴体系，反馈陪伴内容。在预警驱动的实现过程中，首先依据预警信息，关联其归属预警类型和归属预警级别；然后关联此预警类型下的其他预警信息；接着通过预警类型和级别配置信息，关联到对应的陪伴体系；最后在陪伴体系下，搜索对应学生的陪伴记录，实现的效果如图5所示。图5预警驱动陪伴管理这样，用户在查看一条预警信息的同时，还可查询到该同学同类型其他预警信息、以及需要提供哪些陪伴内容、其他陪伴人员已提供了哪些内容、陪伴结果如何等。这样，方便反馈预警结果、陪伴内容和结论的同时，也有利于后续有针对性地开展线下陪伴。在线下陪伴驱动的实现过程中，用户可直接选择陪伴的学生，然后选择陪伴体系和陪伴项，录入陪伴内容和结论。考虑到一次线下陪伴会涉及多个类型的陪伴内容，因此在实现过程中，陪伴体系和陪伴项都支持多选，系统自动分拆成多条记录，存储在不同的陪伴体系中。

4结语

随着智慧校园建设的不断深入和数据中台的逐步优化完善，在基于数据中台构建的陪伴支撑系统中，数据赋能的效用将会不断显现，同时预警的反馈信息也将不断提高预警准确性，数据的良性循环将更加有效的支撑个性化、精准化陪伴的开展，更好的助力学生成长成才。同时，这也为智慧校园中其他需要数据分析和大数据支撑的业务系统建设，提供了一定的参考和借鉴。

参考文献：

[1]钱红兵,赵文广,李艳丽,等.基于Hadoop生态的高校学生行为预警平台设计与实现[J].电子设计工程,2020(5):66-70.

[2]安洋,李军怀,王怀军,等.基于大数据的学生行为综合分析与服务平台设计与实现[J].四川职业技术学院学报,2021(4):153-157.

[3]马晓玲,朱丽娟,吴永和,等.教育数据中台系统模型及其应用研究[J].现代教育技术,2021(11):63-71.

[4]汪争贤,吴建琳,陈胡嵘,等．基于数据中台的财务大数据可视化分析的实现[J]．经济研究导刊,2021(20):128-130.

[5]胡翰林,沈书生.基于中台技术的教育大数据应用研究[J].现代教育技术,2021(9):78-86.

[6]李巍巍.数据中台技术在业务系统中的应用研究[J].现代信息科技,2019(21):108-110.

[7]秦道祥,路阳,张荠月,等.基于Spark技术的日志分析平台设计与应用[J].中国教育信息化,2021(19):50-54.

作者：王刚 张鹏 赵永杰