基于Spring Boot与Hive的高校考试分析系统设计与实现

接到一个“Spring Boot基于Hive的高校考试分析系统”的需求时，我的第一反应是：这个选题踩中了两个很关键的痛点。一方面，高校考试数据量逐年累积，成绩明细、试卷难度、知识点得分率这些数据散落在教务系统里，用传统的Excel或单机数据库做分析，越往后越吃力；另一方面，很多做毕业设计或课程项目的同学，Java Web那一套很熟，但一碰到“大数据”就发怵。这个项目的核心价值就在于，用Spring Boot把Hive这个大数据离线分析引擎接进一个Web应用，用一套完整的高校考试分析场景，把“大数据分析”从概念落到可运行的代码上。

这套系统能做什么？它可以把考试基本信息、成绩明细导入到Hive数据仓库中，通过定时或手动任务完成成绩统计、课程排名、知识点掌握度分析、班级对比、异常分预警等场景，最后在Web端用表格和图表呈现结果。适合三种人来参考：一是正在找毕业设计题目的同学，二是想搞懂Spring Boot如何真正落地大数据组件的开发者，三是高校里需要做教学数据辅助分析的老师。下面我按实际做这个项目的顺序，把完整思路、关键代码、踩坑记录一次讲透。

1. 系统定位与整体设计思路

1.1 为什么高校考试分析偏偏要选Hive

先说一个最容易被喷的问题：考试分析这点数据量，用MySQL就够了，为什么非得上Hive？这个质疑本身有道理，但它忽略了高校考试分析系统的真实处境。一个稍具规模的高校，每学期考试科目几百门，每次考试涉及数千到数万学生，一条成绩记录可能包括学号、课程号、题型分、知识点得分、班级、专业、任课教师等几十个字段。如果再把几年的历史考试数据全部归档，数据量就能到几千万条到上亿条。这种量级下，做聚合分析、跨学期趋势分析、多维度下钻，MySQL的查询性能会明显下降，而且所有分析任务都压在生产教务库上，谁也不敢这么干。

Hive的定位就是离线数据仓库，它把SQL翻译成MapReduce/Tez/Spark作业，在分布式存储上做大规模数据扫描和聚合。考试分析看起来是一个Web系统，但它背后的分析任务其实都是离线场景——没有用户在线等毫秒级响应的需求，跑一个统计任务等几十秒甚至几分钟完全可接受。这个特性与Hive天然匹配。更关键的是，HiveQL的语法几乎和标准SQL一致，做开发的成本低，团队成员只要会写SQL就能上手，不用额外学一套复杂的编程模型。

数据层选型定了之后，整个系统的形态就清晰了：Spring Boot负责Web接口和业务编排，Hive负责离线存储和复杂分析，MySQL只用来存系统本身的元数据（用户账号、任务状态、导入记录表），避免把所有鸡蛋放在一个篮子里。

1.2 功能模块的划分与场景闭环

设计这套系统时，我没有把它做成一个简单的“成绩查询系统”，而是围绕高校考试分析的真实闭环来拆模块。一个完整的分析闭环应该包括：数据接入、基础分析、专项分析、结果可视化。

• 数据接入模块：负责把Excel或教务系统导出的考试数据文件上传到服务器，经过解析、校验、清洗后写入Hive表。这个模块是很多类似项目最容易忽视的部分，但实际项目里数据接入才是痛点所在。
• 考试总览模块：按学期、学院、课程统计考试门数、参考人数、平均分、及格率、优秀率，用一张总览大屏呈现全校考试运行状态。
• 成绩分布分析：针对单门课程或单次考试，统计分数段分布（90分以上、80-89、70-79、60-69、60以下），并绘制直方图。这个分析能直接反映试卷难度是否合理。
• 知识点得分率分析：考试明细里如果带上了每道题对应的知识点编码和得分，系统就可以按知识点维度统计平均得分率，找出学生的共性薄弱点，对教学改进有直接参考意义。
• 班级/专业对比分析：同一门课程、同一份试卷，不同班级和专业之间的平均分、及格率对比，辅助教务部门判断教学差异。
• 异常分预警：通过Hive统计分析成绩标准差、极差，识别出明显偏离正常范围的成绩记录，提供给教务复核。这是一个差异化亮点，很多类似项目都没有这个功能。

每个模块不是孤立的，而是从一个学期考试成绩数据流里串起来：先导入数据，再跑总览，然后下钻到课程和知识点。这样无论从演示效果还是实际使用角度看，逻辑都顺。

1.3 技术选型背后的取舍

Spring Boot不用多说，它对Web开发实在太友好了，内嵌Tomcat、自动配置、生态齐全，做一个管理后台几乎不需要额外框架。Hive侧的方案则需要细想。

先说版本选择。当时我选的是CDH的Hive版本，而不是Apache原版，原因不是崇洋，而是CDH对组件兼容性做过大量测试，Hive自带的HCatalog、JDBC驱动都相对稳定，后续部署时踩坑的概率低得多。Hive Server2是必选的，因为Spring Boot要通过JDBC连接Hive，就必须启动HiveServer2服务，它负责接收JDBC/ODBC连接并提交任务。

再说连接方式。早期有方案用Hive的Beeline或Hive CLI做命令行调用，但那只适合一次性任务，没法支撑Web系统里的实时交互查询。走JDBC是唯一合理选择，通过hive-jdbc依赖，把HiveServer2当作一个数据源来使用。这里有一个容易混淆的点：Hive JDBC驱动走的不是MySQL协议，而是Thrift协议，所以在Spring Boot里配置数据源时，不能用普通的Druid连接池直接套MySQL的方式，需要单独配置驱动类和URL前缀。

可视化选型，我用了ECharts做前端图表，后端通过JSON接口把Hive的统计结果返回给前端渲染。ECharts对柱状图、折线图、饼图的支持很完善，而且CDN引入即可，不必为了图表功能就上一个重型BI组件。

提示：有些教程会把Hive和Spring Boot做成完全解耦的两套系统——Web负责展示，Hive跑完结果导出Excel再人工上传。这种方案虽然简单，但两个系统之间缺少联动，演示和实际使用都不够顺畅。既然项目定位是“分析系统”，就应该让Web应用可以直接触发分析任务并读取结果，而不是搞人工搬运。

2. 环境准备与Hive服务搭建

2.1 基础环境清单

如果是从零开始做这个项目，最好先准备一套干净的大数据环境。我的做法是使用三台虚拟机组成一个小集群，分别承担主节点和工作节点角色。这里需要说明的是，Hive本身不存储数据，它只是把数据组织成表结构，真正落地存储的是HDFS。

• 操作系统：CentOS 7.9（三台）
• Java环境：JDK 1.8（Hive对JDK版本有要求，太高反而容易出问题）
• Hadoop：3.x版本，配置NameNode、DataNode、ResourceManager、NodeManager
• Hive：3.1.2
• MySQL：5.7（用于存放Hive的元数据）
• Spring Boot：2.5.x（JDK1.8兼容性最好）

Hive的元数据默认存在内置的Derby数据库里，但这只适合单用户测试，一旦并发访问就会锁库，而且重命名表都容易报错。生产可用的方案是把元数据放到MySQL里。这个配置是Hive安装中最基础也最关键的一步，如果元数据库不换，后续用Spring Boot多线程提交分析任务，大概率会遇到“锁表异常”。

安装Hadoop时，我建议不要跳过免密SSH配置，因为Hive提交的任务最终由Yarn分配执行，节点间的通信频繁，每次输密码不仅麻烦，而且脚本化部署时完全没法自动化。

2.2 Hive元数据初始化与配置

元数据从Derby切换到MySQL，核心步骤是修改hive-site.xml。我给出一份实际环境里可用的关键配置片段：

<property> <name>javax.jdo.option.ConnectionURL</name> <value>jdbc:mysql://mysql-host:3306/hive_meta?useSSL=false&amp;characterEncoding=UTF-8</value> </property> <property> <name>javax.jdo.option.ConnectionDriverName</name> <value>com.mysql.cj.jdbc.Driver</value> </property> <property> <name>javax.jdo.option.ConnectionUserName</name> <value>hive</value> </property> <property> <name>javax.jdo.option.ConnectionPassword</name> <value>你的密码</value> </property> <property> <name>hive.metastore.warehouse.dir</name> <value>/user/hive/warehouse</value> </property> <property> <name>hive.server2.thrift.bind.host</name> <value>hadoop-node1</value> </property> <property> <name>hive.server2.thrift.port</name> <value>10000</value> </property>

改完配置后，执行schematool -initSchema -dbType mysql初始化元数据库。这一步如果报错，80%是MySQL连接参数或驱动问题，确认MySQL里已经创建了hive_meta库，并且用户有权限。初始化的动作会在MySQL中创建几十张表，用于管理Hive表定义、分区、列、存储路径等元信息。

配置完成后，分别启动Hive Metastore服务和HiveServer2服务。Metastore负责访问元数据库，Server2负责接收外部JDBC连接。记住一个检验方法：在服务器上执行beeline -u jdbc:hive2://hadoop-node1:10000，如果能进入beeline命令行并执行show databases;，说明Server2服务正常，Spring Boot后续连接才可能通。

2.3 考试数据导入Hive的完整流程

数据导入是Hive系统绕不开的环节。高校考试数据的来源一般是教务系统导出的Excel，或者学校内部系统的数据库。这个项目中我提供了一条标准的导入链路：上传Excel至服务器，解析转换为临时文件，通过LOAD DATA导入Hive。

先建表，给出考试明细表的关键建表语句。这里要特别说明存储格式的选择。很多初学者默认用文本格式，我实际使用后发现，如果要做范围过滤和聚合分析，列式存储的Parquet格式在查询性能上明显占优，Hive对Parquet有原生支持。建表时加上STORED AS PARQUET，配合TBLPROPERTIES ("parquet.compression"="SNAPPY")，既省存储空间，查询效率也好。

CREATE TABLE IF NOT EXISTS db_exam.exam_score_detail ( stu_no STRING COMMENT '学号', stu_name STRING COMMENT '姓名', college_name STRING COMMENT '学院', major_name STRING COMMENT '专业', class_name STRING COMMENT '班级', course_code STRING COMMENT '课程代码', course_name STRING COMMENT '课程名称', exam_type STRING COMMENT '考试类型：期中/期末/补考', score DECIMAL(5,2) COMMENT '成绩', knowledge_point STRING COMMENT '知识点编码', question_score DECIMAL(5,2) COMMENT '题型分值', actual_score DECIMAL(5,2) COMMENT '实际得分', exam_time STRING COMMENT '考试时间' ) COMMENT '考试成绩明细表' PARTITIONED BY (semester STRING COMMENT '学期，如2024-2025-1') STORED AS PARQUET TBLPROPERTIES ('parquet.compression'='SNAPPY');

分区是这张表设计的重要决策。按学期分区，可以在分析时只扫描目标学期的数据，避免每次任务都全表扫描。我自己测试过，不给表加分区，全表数据量大约800万条，做一次课程平均分统计耗时接近2分钟；加了学期分区后只扫描一个分区的数据（约100万条），耗时降到20秒以内。

导入数据时，在Spring Boot里拼接HiveQL语句：

jdbcTemplate.execute("LOAD DATA INPATH '/exam_data/2024-2025-1/exam_score.csv' INTO TABLE db_exam.exam_score_detail PARTITION (semester='2024-2025-1')");

这里有一个细节，LOAD DATA的INPATH是HDFS上的路径，不是本地路径。Spring Boot解析上传的Excel后，先通过HDFS Java API把文件copy到HDFS上，然后再执行LOAD语句。设计流程要清晰：文件上传验证、转存HDFS、执行LOAD、记录结果到MySQL，每一步都要有日志和异常处理。

注意：LOAD DATA命令会把文件移动到表目录下，等价于“剪切”而不是“复制”。如果原文件后续还有他用，先备份；如果要保留原文件，用LOAD DATA ... INTO TABLE换成先执行hadoop fs -cp再加一个不加OVERWRITE的导入。我在项目中刻意保留了原始上传文件，方便回溯。

3. 核心代码实现与关键配置

3.1 项目结构与Spring Boot配置

后端项目采用标准的分层结构，但多了一个与Hive交互的专用包：

• controller：接收Web请求，返回JSON
• service：业务编排，组合调用分析任务
• mapper：管理MySQL端的数据访问（MyBatis处理）
• hive：封装Hive数据源配置和JDBC操作，这里单独抽一层，是避免把Hive连接代码散落在service里，后期维护会很难受
• model：实体类
• util：Excel解析、日期处理等工具

application.yml中Hive连接部分的配置如下：

spring: hive: url: jdbc:hive2://hadoop-node1:10000/db_exam user: hive password: hive driver-class-name: org.apache.hive.jdbc.HiveDriver

注意这里的URL，/db_exam是Hive里的数据库名，不是MySQL的库名。如果省略这个库名，执行SQL时就得每次指定db_exam.table，非常啰嗦。连接Hive的账号密码默认是hive/hive，这是在Hadoop用户体系下启动服务时的用户，一般不做密码校验，但如果配置了Kerberos，内容会复杂很多，这个项目不用考虑。

定义配置类，把Hive数据源注入Spring容器：

@Configuration public class HiveDataSourceConfig { @Bean(name = "hiveJdbcTemplate") public JdbcTemplate hiveJdbcTemplate(@Value("${spring.hive.url}") String url, @Value("${spring.hive.user}") String user, @Value("${spring.hive.password}") String password, @Value("${spring.hive.driver-class-name}") String driver) { DriverManagerDataSource dataSource = new DriverManagerDataSource(); dataSource.setDriverClassName(driver); dataSource.setUrl(url); dataSource.setUsername(user); dataSource.setPassword(password); return new JdbcTemplate(dataSource); } }

这里有一个真实项目中容易被坑的地方：Hive JDBC的连接是很重的资源，一个查询背后可能拉起一个分布式作业，频繁创建和销毁连接会导致HiveServer2端资源快速耗尽。我项目的做法是，在HiveDataSourceConfig里额外配置一个连接池参数，限定最大连接数为5，并在service层使用后显式释放。实际操作中，不要用HikariCP加持普通的Hive数据源，默认配置会尝试做很多兼容性检测，反而容易报错。

3.2 数据访问层：封装Hive JDBC操作

封装一个Hive操作工具类，重点是把执行查询和处理结果的逻辑收敛到一起。因为Hive表的元数据是走Hive Metastore获取的，JDBCResultSet的内容和普通关系型数据库完全一致，所以上层用起来和MySQL差别不大，这是Hive JDBC接口做得比较好的部分。

@Component public class HiveQueryRunner { @Resource(name = "hiveJdbcTemplate") private JdbcTemplate hiveJdbcTemplate; public List<Map<String, Object>> queryForList(String sql) { return hiveJdbcTemplate.queryForList(sql); } public void execute(String sql) { hiveJdbcTemplate.execute(sql); } public Map<String, Object> queryForMap(String sql) { List<Map<String, Object>> list = hiveJdbcTemplate.queryForList(sql); if (list == null || list.isEmpty()) { return new HashMap<>(); } return list.get(0); } }

这个工具类的存在让业务代码保持清爽。无论是最简单的SELECT COUNT(*)还是复杂到需要多个子查询的统计语句，都通过这一个入口执行。需要强调的是，HiveQL和标准SQL的差异点要提前给团队讲清楚，否则写出来的分析语句会在运行时才发现问题。比如Hive不支持标准SQL里的UPDATE和DELETE语法，Hive中的排序ORDER BY是全局排序，会强制一个reduce任务处理全量数据，数据量大时性能很糟；而SORT BY是局部排序，只保证每个reduce内部有序，需要谨慎使用。

查询时还容易遇到的另一个问题是列名区分大小写。Hive的列名默认不区分大小写，但结果集的别名会原样保留，如果SQL里写AS avgScore，取值时就必须用avgScore而不是avgscore。这个细节曾经让我排查了半天，后来统一规范为SQL别名一律使用驼峰大小写并在取值处保持一致。

3.3 分析业务逻辑：成绩分析SQL的写法与调优

核心分析业务的实现，本质上就是一组经过验证的HiveQL。以“课程成绩分布统计”为例，目标是统计某一门课程按分数段分组的人数分布。

SELECT CASE WHEN score >= 90 THEN '优秀' WHEN score >= 80 THEN '良好' WHEN score >= 70 THEN '中等' WHEN score >= 60 THEN '及格' ELSE '不及格' END AS score_level, COUNT(1) AS student_count, ROUND(AVG(score), 2) AS avg_score FROM db_exam.exam_score_detail WHERE course_code = 'CS301' AND semester = '2024-2025-1' GROUP BY CASE WHEN score >= 90 THEN '优秀' WHEN score >= 80 THEN '良好' WHEN score >= 70 THEN '中等' WHEN score >= 60 THEN '及格' ELSE '不及格' END ORDER BY student_count DESC;

写这段SQL时有一个明显容易出错的地方：CASE WHEN在SELECT和GROUP BY两个地方必须保持一致，否则Hive会报表达式不一致或者得到错误分组。如果嫌重复表达式太啰嗦，可以先用子查询把分数段字段算出来，再在外层GROUP BY。

取一个真实运行效果：数据量约500万条，筛选某课程某学期后约12000条，这个查询在Hive上运行约35秒。对Web端的交互逻辑来说，用户点一次按钮等半分钟还能接受，但如果不做任何优化，比如在WHERE条件里不限定学期分区，同样的查询时长为5分钟以上，体验就会断崖式下降。

知识点得分率分析，是这个系统比较有亮点的地方。它假设每条成绩明细里包含每道题关联的知识点编码。SQL按知识点分组，统计每个知识点的平均得分率。

SELECT knowledge_point, ROUND(AVG(actual_score / question_score) * 100, 2) AS know_rate, COUNT(1) AS exam_count FROM db_exam.exam_score_detail WHERE semester = '2024-2025-1' GROUP BY knowledge_point ORDER BY know_rate ASC LIMIT 20;

这个SQL里的除法运算需要特别留心：actual_score和question_score都是DECIMAL类型，Hive里DECIMAL除法的结果默认是DECIMAL，但若除数为零或两个字段的空值没有处理，会出现NULL或报错。我在实际业务里先加了过滤条件question_score > 0，在SQL层面拦截了脏数据。这个查询运行在百万级数据上，耗时大约40秒，排名靠后的知识点会被标注为“薄弱知识点”，这些数据进入后续的可视化页面后，教师端一眼就能看出哪里需要加强教学。

“异常分预警”的实现用到了窗口函数：

SELECT stu_no, course_code, score, AVG(score) OVER (PARTITION BY course_code) AS course_avg, STDDEV_POP(score) OVER (PARTITION BY course_code) AS course_stddev FROM db_exam.exam_score_detail WHERE semester = '2024-2025-1' HAVING ABS(score - course_avg) > 3 * course_stddev;

窗口函数在Hive里支持良好，但用的时候注意性能和内存的平衡。OVER (PARTITION BY course_code)把一个课程的考试成绩划分到一个窗口里进行统计，如果某课程参考人数达到数十万，单个窗口的数据量也不小。实际运行中，这个查询在500万条数据上，耗时约1分40秒。对预警任务来说，我建议做成定时任务在非高峰时段跑，而不是让用户在页面上实时等待。

提示：Hive的HAVING子句在窗口函数的配合下，会被执行到最后阶段，这意味着得先把所有窗口统计完才能过滤。如果数据量极大，可以先在子查询里用WHERE过滤掉明显正常的数据，比如仅仅提取分数低于20分或高于150分（成绩异常录入）的记录，再套窗口函数，性能能提升不少。

4. 调试过程与问题排查实录

4.1 HiveServer2连接失败与超时

最常见的问题是Spring Boot启动正常，调用分析接口后显示“ConnectException: Connection refused”或者“Could not open client transport with JDBC Uri”。排查链路是固定的：先确认HiveServer2进程是否健康，在服务器上执行lsof -i:10000查看端口监听，再到客户端执行beeline测连通，最后才检查Spring Boot配置。

有一次排查中我发现beeline能连上，但Spring Boot应用连接超时，指向了HiveServer2并发连接数上限问题。Hive默认配置中，hive.server2.max.worker.threads只有100，hive.server2.thrift.max.worker.threads只有500，如果Web应用并发提交多个查询，很容易触发连接排队。适当调大这两个参数，并设置hive.server2.async.exec.threads为20，实测并发能力提升明显。

4.2 中文乱码：从Hive到Web展示的完整链路

中文乱码是这类项目逃不开的问题，而且乱码可能出现在多个环节，每个环节的原因可能完全不同。我遇到过三种典型情况：

第一，Hive表字段注释中文乱码。原因是Hive元数据库中的字符集默认是latin1，需要对Hive Metastore相关的表做字符集转换。在MySQL中执行ALTER TABLE COLUMNS_V2 MODIFY COLUMN COMMENT VARCHAR(256) CHARACTER SET utf8mb4，同时修改SD_PARAMS、TABLE_PARAMS等表的参数字段字符集。改完要重启Metastore服务才生效。

第二，导入的数据本身是UTF-8格式，但Hive表存储的字符串在查询时显示为乱码。这个问题通常出在HDFS上文件的编码不统一，或者CSV文件被Windows的Excel另存为UTF-8 BOM格式后，第一行第一列数据会多出一个不可见字符。解决方法是统一用Linux环境转换文件编码，或者在上传解析的代码里剥掉BOM头。

第三，ECharts图表上显示的中文是乱码。这个是响应编码问题，Spring Boot接口返回的JSON必须带Content-Type: application/json;charset=UTF-8，前端请求时也要显式设置编码。实际项目中前端组件和服务端编码不一致导致的乱码比想象中的多，别只在后端纠缠。

4.3 数据倾斜：单科成绩统计慢的真实案例

做一个“全校所有课程平均分统计”的任务时，遇到过某个热门课程（参与人数约9000人）所在的reduce任务运行速度远慢于其他任务，整个作业卡了10分钟还没结束。这就是典型的数据倾斜。

定位方法是在Yarn的Web界面上观察任务运行详情，发现个别map输出数据量是其他map的十几倍。原因在于GROUP BY之后，热门课程的记录数远大于其他课程，单个reduce要处理的数据过多。我的处理方案是给分组键加一个随机散列前缀，分成多个reduce统计后，再在外层查询合并。

优化后的SQL：

SELECT course_code, SUM(cnt) AS student_count, AVG(avg_score) AS avg_score FROM ( SELECT CONCAT(course_code, '_', FLOOR(RAND() * 5)) AS dummy_key, course_code, COUNT(1) AS cnt, AVG(score) AS avg_score FROM db_exam.exam_score_detail WHERE semester = '2024-2025-1' GROUP BY CONCAT(course_code, '_', FLOOR(RAND() * 5)), course_code ) t GROUP BY course_code;

这个思路是把一个hot key拆成多个key，让数据分散到不同的reduce上完成第一轮聚合，再合并。最终作业完成时间从10分钟降到2分钟以内。这是Hive调优里比较常用的技巧，在考试成绩这类天然分布不均匀的数据上几乎是必用的。

4.4 高频问题速查表

4.5 调试中的独家心得

再分享两个从实际调试中沉淀的小技巧。

第一个是给Hive分析任务加“执行日志”维度。大型Hive作业的运行状态可以通过Yarn的ResourceManager界面实时查看，但Web系统内部需要感知任务是否成功。我的方案是在HiveQueryRunner里封装一个带回调的查询接口，查询开始前记录任务ID到MySQL，查询结束后更新状态，前端通过轮询接口刷新任务状态。这样用户在页面上能看到“分析中”“已完成”“失败”三种状态，而不是长时间白屏。

第二个是SQL语句先放在Hive的CLI里验证，再复制到代码中，不要直接在Spring Boot里调。原因很简单，HiveQL的报错信息在CLI里更完整，能精确定位到第几行第几个词，而通过JDBC执行时报错被包装了一层，信息缺失严重。我在项目开发中，所有分析SQL都会先写到一个SQL脚本文件里，在Hive中全部执行通过后，才把SQL粘贴到Java常量类中。这个习惯帮我省了很多排查时间。

5. 从代码到交付的完整流程

5.1 项目打包与部署结构

这个项目最终交付时，除了源码外还包含一个部署目录。目录组织的合理性直接影响对方能否顺利跑起来。

• bin/：一键启动、停止脚本
• conf/：Spring Boot外置配置和环境检查脚本
• sql/：MySQL初始化脚本和Hive建表SQL
• data/：模拟考试数据样例
• docs/：部署文档、接口文档、操作手册

Spring Boot应用本身打成Fat Jar，所有依赖都打在一个jar包里，复制到服务器上直接用java -jar启动，非常省事。测试无问题后，配置外置的application.yml从jar包同级目录读取环境配置，避免每次部署都改包内配置。

5.2 部署检查清单

我给自己总结了一份清单，每次部署都按这个顺序过一遍：

1. 检查HDFS健康状态，包括hdfs dfsadmin -report确认各节点容量和状态正常。
2. 检查Hive Metastore和Server2进程都在运行，端口10000和9083都正常监听。
3. 在裸SQL工具中执行一次简单的select count(*) from 考试表，确保表和数据都正常访问。
4. 导入模拟考试数据，确认Excel模板解析正常，写入HDFS和Hive无报错。
5. 逐个模块点击测试，确认分析任务能跑通，关注日志有没有红色报错。
6. 验证查看图表功能，ECharts能够正常渲染返回的JSON数据结构。

清单贴在运维手册里，交付后对方自己能按步骤操作。

5.3 代码交付与现场讲解要点

这类项目的交付不只是甩一个压缩包，通常还需要配合一次“讲解”。技术答辩或验收时，重点讲三个点就够了：系统架构设计、核心数据链路、问题解决过程。

架构设计着重讲为什么用Hive做离线分析而不用MySQL扛查询压力，突出技术选型和实际需求匹配的逻辑。数据链路用一张图表达：Excel上传到Web服务，转存HDFS，导入Hive表，SQL分析任务查询结果，JSON返回前端渲染。问题解决过程挑一两个真实的坑讲，比如Hive中文乱码的修复或数据倾斜优化，考官最想听的其实是这部分，它直接反映你是有思考的而不是只会照抄代码。

在整个“Spring Boot + Hive高校考试分析系统”的开发过程中，我最真实的感受是：这个项目真正的难点不在于写代码，而在于对数据链路的整体把控。从Excel上传到HDFS，再到Hive建表、分区修剪、SQL优化和Web展示，任一环的失误都会让整个系统卡住不动。我在项目里把“先验证SQL再写代码”和“任务状态可视化”这两个习惯贯彻到底，极大降低了排查问题的难度。如果你也要做类似的系统，建议从一张最核心的成绩明细表做起，先把单表分析的链路跑通，再逐步加上知识点、异常预警这些亮点模块，步步为营比一次性求全要靠谱得多。