校园大数据平台搭建实录：实时数仓与数据服务的工程实现-编程实验室

校园大数据平台搭建实录：实时数仓与数据服务的工程实现

校园大数据平台的技术选型争议很多：要不要上 Hadoop？实时数仓怎么建？API 服务怎么做？本文从一个实际项目出发，详解校园大数据平台从数据采集到数据服务的全链路工程实现。

一、问题背景：一所万人院校的数据链路挑战

某职业院校在校生一万余人、教职工六百余人，业务系统 20 余个。平台上线前的典型困境：教务系统的学籍变更，学工系统三天后才能拿到；学生请假数据、宿舍门禁数据、图书馆借阅数据各自沉睡；领导想要"在校生异动周报"，信息中心要加班两天手工拼表。目标是建一套校园大数据平台，实现"数据一次采集、全校实时共享"。

二、技术架构分析：Lambda 简化版架构

考虑到院校数据规模（TB 级而非 PB 级），我们没有照搬互联网大厂的重型架构，采用简化版 Lambda 架构：

采集层：CDC(binlog) + ETL调度 + API上报 │ 存储层：ODS(原始) → DWD(标准明细) → DWS(主题汇总) → ADS(应用指标) │ 关系库 + 时序库 + 对象存储 计算层：批处理(Spark SQL) + 实时流(Flink-lite/规则引擎) │ 服务层：数据中台 API 网关（查询/订阅/推送） │ 应用层：画像系统 / 决策大屏 / AI数据分析平台

选型原则：够用就好。MySQL 生态的 CDC 工具成熟稳定，Spark 按需弹性，不盲目堆砌 Kafka+Flink 全家桶——院校信息中心的运维人力撑不起太重的架构。

三、核心功能实现

3.1 数据采集：CDC 为主的多模接入

# 采集任务配置示例 jobs: - name: student_cdc source: { type: canal, db: jwxt, tables: [xs_xjb, xs_xjyd] } target: { layer: ods, table: ods_edu_student } mode: realtime - name: consume_etl source: { type: jdbc, db: ykt, sql: "select * from xfjl where sj >= '${last_day}'" } schedule: "0 1 * * *" # 每日凌晨1点增量 target: { layer: ods, table: ods_consume_record }

教务、学工等核心库走 Canal 实时捕获 binlog，一卡通消费等流水表走夜间 ETL 增量，物联网数据走 MQTT 进时序库。

3.2 数据清洗与标准化：DWD 层的核心逻辑

ODS 到 DWD 的转换完成三件事：字段映射对齐数据标准、代码集转换（如专业代码转标准专业目录）、质量稽核打标。

-- DWD 层清洗示例：学生信息标准化 INSERT OVERWRITE TABLE dwd_student SELECT xh AS student_no, TRIM(xm) AS student_name, CASE xb WHEN '1' THEN '男' WHEN '2' THEN '女' ELSE '未知' END AS gender, zydm_std.code AS major_code, -- 代码集标准化映射 CASE WHEN sfzh RLIKE '^\d{17}[\dXx]$' THEN 1 ELSE 0 END AS id_valid_flag FROM ods_edu_student s LEFT JOIN dim_major_standard zydm_std ON s.zydm = zydm_std.raw_code;

3.3 数据服务：一个网关三种出口

数据中台对外的所有数据服务收敛到一个 API 网关：

// 数据服务注册示例 @DataService(path = "/api/data/student/{no}", auth = Role.DATA_CONSUMER) public StudentProfile getStudent(@PathVar String no, @CurrentUser ApiCaller caller) { audit.log(caller.getAppId(), "student", no); // 调用审计 return studentRepo.findStandard(no); // 读DWD标准层 }

实时查询：毫秒级，走 DWD 层索引；
自助订阅：部门在门户勾选数据集，变更通过消息中心自动推送；
批量推送：T+1 定时推送给不支持 API 的老系统。

3.4 学生画像：标签体系计算

画像标签分统计类（消费月均、借阅次数）、规则类（经济困难预警、学业预警）、模型类（就业倾向预测）。统计类每日批量预计算进结果表，规则类实时流处理触发预警推送，模型类按周更新。

四、性能优化

冷热分离：近三年数据在线可查，历史数据归档到对象存储，查询性能与成本平衡；
预聚合：大屏与报表常用指标进 ADS 层预聚合，大屏秒开；
CDC 峰值削峰：开学批量注册时 binlog 洪峰通过消息缓冲平滑，避免冲击下游。

五、部署方案

平台与学校数据中心同机房私有化部署：采集与计算服务 K8s 容器化，数据库主从+每日全备，API 网关双节点高可用。安全上按等保三级：敏感字段 AES 加密存储、API 调用全程审计、数据导出需审批水印。某高校按此架构运行后，跨系统数据同步时效从"三天"提升到"秒级"，信息中心的报表工时下降约七成。

六、总结与展望

校园大数据平台的工程要义是"克制"：克制技术选型的冲动，用成熟度换运维成本；克制架构的复杂度，让四五个人的团队也玩得转。当数据链路打通后，上层的数据应用——画像、大屏、AI 分析——都是水到渠成。下一步，随着 AI数据分析平台的接入，自然语言查数将成为常态，数据服务的最后一公里将被彻底打通。

关于汇锦科技

深圳汇锦科技股份有限公司深耕智慧校园信息化领域多年，致力于为中职、高职及高校院校提供从数字基座到智能应用的全方位解决方案。公司产品涵盖智慧校园数字基座、校园AI助手、智慧教务系统、统一身份认证、校友服务平台、工业机器人专业建设、无人机专业建设等，已服务全国数百所院校，助力院校实现教育数字化转型。

校园大数据平台搭建实录：实时数仓与数据服务的工程实现