教育行业信息化工作已经实施多年,南京秦淮区教委在这方面走在前列,并进行了大量尝试。
2018年4月教育部颁布了《教育信息化2.0行动计划》,随着AI人工智能,大数据,移动互联网兴起,在之前教育信息化实施的基础上,秦淮教委根据南京市创建智慧校园的要求,率先进行智慧教育的尝试,释放教育系统的生产力,并为教育创新提供了巨大的空间。
秦淮教委在逐步推进智慧校园的时候,无可避免地遇到了一些挑战,而Tapdata的数据中台解决方案,及时而恰当地帮助他们克服困难,解决了实施中的基础数据问题,并推动智慧校园能够实时、快捷、灵活地落地实践。
那么,
智慧教育实施过程中的痛点和挑战是什么?
Tapdata数据中台是什么?如何解决上述问题?
秦淮区教师发展中心是区智慧校园的整体架构和推动者,承担设计、组织和管理工作。依照南京市智慧校园的创建标准,秦淮区的智慧校园架构如下图
从上面的架构图中,可以看到设计者的思路:
覆盖宽广,包含区级、校级和个人层面的教育对象、资源、环境、工具和管理等统一认证和识别;
高度整合,各个应用之间虽然相对独立,但又相互关联;
开放生态,校级可以自行发起新应用,并在区全局推广,各应用互为补充,自由增、删、组合,形成生态系统;
方便快捷,快速部署和落地新应用,为教育创新提供支持。
一方面,架构反应出智慧校园创建中,一些非常贴合实际的诉求。另一方面,通过多年积累,秦淮教委有着自己的基础特征。
1. 扎实的基础设施和人员应用能力
有线无线,高速宽带遍布各个校园;
教师,学生、家长在电脑和移动终端的普及应用;
2. 大量的基础数据积累
学籍管理系统包含了大量的学生信息;
校园各自建立的OA办公系统积累许多学校管理信息;
各种FTP服务器沉积了各类Excel、CSV等教学教研信息。
3. 众多应用随之而生
区教育系统平台一览表
至此,从上述分析中我们可以看到,基于当前教育信息化的现状和特点,要实现智慧校园的底层要求,秦淮教委在这一轮智慧教育的实践中,无可避免地遇到一些痛点和挑战。
应用繁多,各类应用平台自成一体,有着各自的用户管理系统和数据库。
数据孤岛,各个应用在教育业务层面上相关,但数据各自独立, 很难使这些数据联合起来发挥作用。
整合能力弱,应用开发商整合能力弱,原来的数据结构无法适应教育发展的新需求。
数据再利用,历史数据并入智慧校园架构困难,有的已经无法找到原供应商提供支持。
规模效应,辖区内各个学校早期独立使用的应用,在数据上无法形成规模效应。
上述情况,举两个例子说明。
一是基础数据的集合和统一。区属教师的基础信息在科大讯飞的教育信息系统中。在微研的教师发展平台系统中也包含有部分字段的教师基础信息,同时还有辅导、论文和课题等信息。人脸识别一卡通数据又在腾讯的企业号系统中。这样产生了一个让人头疼的问题,就是在维护基础信息的时候,需要在多个应用中不停地切换,更新多个库的信息,非常的困难,效率低下。
二是各类数据的联合应用。2018年秦淮教委开始了一个”AI智慧课堂”的项目,通过在课堂架设录像设备,采集教师和学生上课时的行为并进行分析。例如通过采集学生在上课时,趴桌子、看手机、听讲、书写、发言、阅读,以及教师的板书、互动等行为,并分析得到每个学生上课时的专注度指数。半年多实施后,通过与班主任的交流发现多数学生情况还是符合的,但是也出现有学生专注度指数高,但考试成绩不理想,以及学生专注度指数很低,但考试成绩很好的两类特殊情况。而”AI智慧课堂”的应用如果能和每个学生的作业数据、考试数据、阅读习惯数据、社团数据、社交数据等等联合、碰撞从而产生新的数据,那么无疑能极大推动教育的创新。
从上述的痛点挑战,以及事例中可以发现,在秦淮教委创建智慧校园中,有着以下的数据处理和应用的需求。
汇聚各个独立应用的数据,打通数据孤岛;在众多应用之上集合数据,形成统计类型的数据大屏,方便实时地掌握各类信息。
适应未来教育发展,个性和多样的非结构化数据;教师和学生这类关于人的描述数据,会越来越全方位、多样化和个性化,需要底层的数据结构能够灵活的适应教育发展的需要。
通过汇聚海量数据,联合应用,提供教育洞察;学习行为分析系统,与学生成绩系统、操行评价系统等整合,可以为教研提供的数据依据和判断。
为系统中的各类对象和角色,快速提供灵活多样的信息;学生、教师、家长、学校、教研、行业、管理部门等等各类角色,可以在实时地、有权限地获得各类数据。
让教育行业的工作者、研究者和专家释放生产力,专注于业务领域的应用,而不必关注和受限于底层的数据管理。汇聚全方位数据,为教学教研、教育心理、营养健康、运动、组织行为等研究提供数据服务。
自建方案;教育系统自行建设,费时费力,需要大量IT和数据处理及应用的专业人士。
单项应用招标;为各类业务需求,单独招标采购,产生了大量账号、统计口径和数据孤岛。
大数据平台;类似于Hadoop,的确是数据分析的能手,但是反应慢,信息滞后,同时耗用大量硬件资源。
数据中台;保护原有投入,打通所有相关数据库,真正的实时信息,兼容全类型开发数据,无限地扩充应用。
Tapdata数据中台简单来说是一个数据处理和应用的服务,即DaaS,( Data as a Service ),包含了从数据汇聚,到数据治理和编目,最后数据服务的三个层面。对应用了从数据输入,到数据整理,最后数据输出的三个过程。
在智慧校园创建中,后台(或者说是底部)有着各类应用形成的丰富数据资源,而这些数据资源却不能统一、快捷、实时地支持前台(或者说是上部)的使用,很大地限制了这一轮智慧教育的设计和需求的实现。
根据Gartner提出的 Pace-Layered Application Strategy理论,如果智慧校园是一台引擎,那么它的后台基础数据资源和前台应用这两个齿轮的速率是不一样的。后台基础应用慢而长,需要稳定可靠,而前台业务应用快而短,需要快速响应。这种齿轮速率的”匹配失衡”最终拖累引擎的表现。
而Tapdata数据中台就象是一个变速齿轮,在其中很好地协调前后台,让基础数据资源顺畅地流向用户,同时更好地服务于前台应用的创新,恰当地解决了创建智慧校园的痛点。
Tapdata DaaS 数据中台架构图
通过Tapdata数据中台的采集模块,打通智慧校园系统中的各类数据孤岛,把所有数据汇聚到数据库。Tapdata DaaS 是采用MongoDB数据库来进行存储。MongoDB的海量和并发两大特性非常方便地为智慧校园系统提供横向扩展,也就是说,她可以随着智慧校园系统的发展不断成长。
各类应用孤岛中的数据被采集后,并不是简单地存储。首先数据编目是元数据管理,例如对所有的应用打上标签,包括数据是从哪个应用的哪个数据库来的,数据类型是什么,业务是什么,后面对接的应用是什么。一旦上层的应用发现数据有错误,可以通过数据编目来进行数据溯源,或者血缘分析,可以追溯到表级别、记录级别甚至是字段级别。其次是数据治理,针对在数据采集或者同步过程中,一些不符合规则和要求的脏数据,进一步进行处理。
数据服务是向外数据分发。传统的开发模式是DB在后台写数据查询和SQL分析,增加或修改一个查询接口要用到一周时间,费时费力。而Tapdata数据中台的API服务是遵从RestFul标准,并且只要通过在界面上的配置,5分钟可以完成一个API的分发。
TB/PB级的数据量
基于NewSQL分布式数据库
使用日志及流的实时数据采集
毫秒级数据响应能力
目前Tapdata先将各个应用,比如OA办公系统、教师发展平台、视频直播平台等,其中的数据全部采集到MongoDB数据库中,经过数据治理和编目后,将数据发布出来。数据分发至多个应用,比如Dashboard,包含有数据大屏,以及不同颗料度大小的统计报表;也同时可以满足其他开发商的应用需要;并且也提供给辖区内各个学校。
在这里Tapdata为智慧校园部署了一个企业级的应用系统。其中包括MongoDB的分布式数据库,Tapdata的各个产品,以及备份措施。TapManagement是一个管理服务,通过Nginx作为UI界面,TapReplicator是一个数据采集模块,通过TapManagement配置和管理,把采集来的数据放入MongoDB数据库。同时TapManagement还具有数据治理和编目的功能。最终通过TapAPI服务将数据进行发布。
在数据采集TapReplicator模块中,支持的源端数据是非常多,包括Oracle、SQLserver、MySQL等各类数据库,也包括Kafka、MQTT、Log、Socket等各类流数据,还包括Excel、CSV、XML、Binary等各类文件数据。同时支持断点续传、同步校验、故障自动转移等各种功能。