企业官网建设流程全解析

去年帮几个读者做这类课题答辩前的技术评审时，我发现一个共性偏差：很多人把“springboot基于Hadoop平台的大学多媒体教学管理系统”做成了“挂名系统”——页面能登录、课程能管理，但Hadoop只是一个装饰品，数据根本没往HDFS上放，学习行为分析也完全没跑起来。我自己的看法是，这类题目的核心价值不在“CRUD复用代码”，而在把“多媒体文件存储”和“学习行为分析”两条真实链路跑通：Spring Boot负责业务编排，Hadoop负责字节存储与离线计算。这篇就按我带项目复盘的思路，从需求拆解、架构设计、核心实现到踩坑清单完整过一遍，适合正在做同类课设/毕设的人，也适合想理解“管理信息系统怎么跟大数据组件做配合”的初级开发者。

1. 一个教学管理系统，为什么非要绑上Hadoop

1.1 多媒体数据的真实形态：大文件与小文件的混合体

先别急着写代码，把数据形态想清楚。大学多媒体教学管理系统的资源主要有四类：

• 教学视频：一节45分钟的录课，H.264编码，分辨率1080p，大小在300MB到2GB之间；
• 课件文档：PPT、PDF、Word，大小从几百KB到几十MB不等，一门课可能累积上百个；
• 学生作业：部分课程要求学生提交视频或压缩包，单个作业在50MB到几百MB之间；
• 播放日志：每个学生每次观看都会产生一条记录，一学期下来单日日志可能几万条。

如果只用传统单体架构做，常见做法是“本地磁盘存文件，MySQL存路径”。但这套方案有三个硬伤：

1. 多台应用服务器各自有本地磁盘，学生请求被负载均衡到不同机器时，可能找不到文件；
2. 磁盘扩容麻烦，且没有副本机制，磁盘损坏课件直接丢；
3. 播放日志散落在数据库和日志文件里，想跨课程、跨学生做分析，根本没有统一的数据入口。

HDFS恰好能把这三点一起解决：它是一个分布式共享文件系统，所有业务服务器看到同一个命名空间；容量不够就加数据节点，不需要动业务代码；默认三副本机制，单节点故障不会丢数据；日志文件统一落进HDFS后，后续用MapReduce做离线分析非常自然。

1.2 异构存储设计：MySQL管事务，HDFS管字节

这里有个非常关键的判断：引入Hadoop不意味着抛弃MySQL。选课、登录、权限分配、角色管理这些操作强调强一致性和事务能力，HDFS的文件追加写模式天生不适合这种在线事务场景。所以最合理的架构是异构存储：

• MySQL保存结构化业务数据：用户、课程、选课关系、资源元数据、作业记录、统计结果；
• HDFS保存非结构化文件字节：视频、课件、作业压缩包、播放日志、分析中间结果。

一句话概括就是“元数据与字节分离”。这种设计的直接好处是：应用层想要展示文件列表时，查MySQL就是毫秒级；真正要读取文件内容时，才去HDFS拿流。系统热路径和冷路径互不干扰，这也符合互联网业务里常见的“冷热数据分离”思路。

1.3 这个课题真正的价值点：管理之外的行为分析

如果只是“上传视频、学生观看、教师删改”，那这类系统用Spring Boot加本地文件系统三天就能写完，不需要引入Hadoop。题目真正区别于普通管理系统的，是“学习行为分析”这一能力。

教师上传视频后，学生在线观看，前端播放器每隔30秒上报一条观看日志。这些日志沉淀下来，经Hadoop侧MapReduce作业处理，就能产出三类结论：每个学生的累计观看时长、每个视频的热度排行、全校活跃观看时段分布。普通管理系统只能告诉你“谁看了什么”，这套系统可以告诉你“谁看了多久、集中在什么时间、哪些内容最受欢迎”。

所以“基于Hadoop平台”不是噱头，它承担的是统一存储和离线分析两条核心职责。带着这个认知去设计，后面的模块划分才会清晰。

2. 系统架构与数据流转：两条存储线、三条业务链

2.1 总体分层与组件职责

整个系统按职责分成四块，互相之间的依赖关系很明确：

Spring Boot只依赖HDFS的客户端API，不依赖集群内部组件，因此业务服务可以部署在集群之外的独立服务器上。学生上传文件时，后端把流写入HDFS路径；学生播放时，后端打开HDFS流，以HTTP分块方式回传给浏览器；定时任务每天凌晨把MySQL里的播放日志批量导入HDFS，并触发MapReduce统计作业。

2.2 数据库表结构与HDFS目录规划

数据库里最重要的几张表是：

sys_user：id, username, password, role, real_name, create_time course：id, course_name, teacher_id, description, status course_enrollment：id, course_id, student_id, enroll_time resource：id, course_id, uploader_id, file_name, hdfs_path, file_size, file_type, play_count, create_time homework：id, course_id, student_id, hdfs_path, file_name, submit_time, score access_log：id, user_id, resource_id, start_time, duration, ip stats：id, course_id, metric, dimension, value, stat_date

HDFS目录按业务域划分，保持与MySQL表结构的隐式对应：

/multimedia/course/course_101/video/ /multimedia/course/course_101/doc/ /multimedia/homework/course_101/ /multimedia/logs/access/20240801.log /multimedia/logs/stats/20240801/

设计要点是路径可预测、可追踪。resource表中的hdfs_path字段永远存完整绝对路径，前端展示不需要关心它在集群里的物理位置，后端跨模块传递时也不会拼错路径。

2.3 三条核心链路：上传、播放、分析

链路一：上传。教师选择本地视频文件，后端接收MultipartFile，校验类型和大小，生成唯一的HDFS路径，先把字节写入HDFS，写入成功后再向MySQL的resource表插入一条元数据。

链路二：播放。学生点击视频，浏览器向/api/resource/stream/{resourceId}发起请求，后端根据resourceId查出hdfs_path，再打开HDFS文件流按Range分块输出。注意这里必须支持HTTP Range（分块请求），否则播放器无法拖拽进度条。

链路三：分析。播放过程产生的心跳日志先写MySQL的access_log，每天凌晨定时任务把昨天的日志拼成一行一行的文本，上传到HDFS指定目录，随后提交MapReduce作业做统计，结果写回stats表，教师端报表页面直接查MySQL展示。

这三条链路是系统的主干，后面所有代码和踩坑都围绕它们展开。

3. 核心功能实现：从文件上传到视频流播放

3.1 HDFS工具类与FileSystem实例管理

封装一个服用性高的HdfsUtil类，整个项目所有对HDFS的操作都走它。第一步是拿到正确的FileSystem实例：

public class HdfsUtil { private static final Configuration CONF = new Configuration(); static { // 与集群core-site.xml中的fs.defaultFS保持一致 CONF.set("fs.defaultFS", "hdfs://node01:8020"); // 三副本适合重要课件，临时分析数据可选两副本 CONF.set("dfs.replication", "3"); // 如果本地要读压缩格式日志，打开codec CONF.set("io.compression.codecs", "org.apache.hadoop.io.compress.GzipCodec"); } public static FileSystem getFileSystem() throws IOException { return FileSystem.get(CONF); } }

有几个容易被新手忽略的细节：

1. FileSystem.get(conf)返回的是JVM级缓存实例，同一个进程多次调用不会重复创建连接，效率高。但如果目标想连不同的集群，必须改用FileSystem.newInstance(conf)。
2. 不要在每个方法里都new Configuration()，配置重合会浪费资源，也容易在集群切换时踩脏数据。
3. 如果客户端机器上的操作系统用户和集群HDFS超级用户不一致，访问会报Permission denied。最简单省心的办法是统一用hadoop用户启动应用服务，或者用UserGroupInformation.createRemoteUser("hadoop")包一层doAs执行操作。

上传文件的实现很短，短但关键：

public static void upload(InputStream in, String hdfsPath) throws IOException { FileSystem fs = getFileSystem(); Path path = new Path(hdfsPath); try (FSDataOutputStream out = fs.create(path, true)) { IOUtils.copyBytes(in, out, 4096, true); } }

IOUtils.copyBytes来自org.apache.hadoop.io.IOUtils，最后一个参数为true表示复制完成后关闭输入流。这个方法内部会反复调用write并flush，比手写循环要稳妥得多。上传视频这种几百MB的大文件时，注意不要一次读进内存再写，一定要用流式的方式边读边写，否则JVM内存会被瞬间打满。

3.2 上传接口：校验、路径生成、元数据落库

Controller层接收文件，校验放在Service里做，上传动作放在事务之外执行。核心代码：

@PostMapping("/api/resource/upload") public Result upload(@RequestParam("file") MultipartFile file, @RequestParam("courseId") Long courseId, @RequestParam("fileType") String fileType) { if (file.isEmpty()) { return Result.error("上传文件为空"); } String originalFilename = file.getOriginalFilename(); long size = file.getSize(); String ext = FilenameUtils.getExtension(originalFilename); if (!allowedType.contains(ext)) { return Result.error("不支持的文件类型"); } if (size > MAX_SIZE) { return Result.error("文件超过大小限制"); } // 路径设计：课程号 + 类型 + 时间戳 + 随机短ID + 扩展名 String hdfsDir = "/multimedia/course/course_" + courseId + "/" + fileType; String hdfsPath = hdfsDir + "/" + System.currentTimeMillis() + "_" + UUID.randomUUID().toString().substring(0, 8) + "." + ext; try { HdfsUtil.upload(file.getInputStream(), hdfsPath); } catch (IOException e) { log.error("HDFS写入失败", e); return Result.error("文件保存失败"); } // HDFS写入成功后再落库 ResourceEntity resource = new ResourceEntity(); resource.setCourseId(courseId); resource.setUploaderId(getCurrentUserId()); resource.setFileName(originalFilename); resource.setHdfsPath(hdfsPath); resource.setFileSize(size); resource.setFileType(fileType); resourceMapper.insert(resource); return Result.success(resource); }

这里有两个实际问题必须处理。

第一，Spring Boot和Tomcat默认单次上传上限只有1MB，不调配置的话超过1MB的视频直接报错。需要在application.properties里放开限制：

spring.servlet.multipart.max-file-size=1024MB spring.servlet.multipart.max-request-size=1280MB

如果服务前面挂了Nginx，还要记得把client_max_body_size一起调整，否则Nginx层就把大请求拦住了。

第二，HDFS写入一旦成功但MySQL插入失败，会出现“文件在、元数据不在”的孤儿文件。更稳的顺序是：把HDFS文件先写到临时路径，全部写入成功后rename到正式路径；MySQL插入失败时，再删除正式路径文件。课程设计阶段可以把逻辑简化为“先写正式路径，失败直接删”，但心里要清楚生产环境绝不能用这个简化版。

3.3 视频播放接口：Range请求才是真正的难点

文件上传做完后，很多人会卡在播放这一步。原因就是只知道把整个文件流吐给HTTP响应，没有实现HTTP Range。不实现Range，浏览器只能从头到尾下载完才能播放，拖进度条基本失灵。

Range的意思是浏览器可以请求文件的一部分，格式是Range: bytes=1024-2048。服务端读HDFS时先seek到指定位置，再输出对应长度的字节。由于HDFS的FSDataInputStream天然支持seek，这个需求可以优雅实现：

@GetMapping("/api/resource/stream/{resourceId}") public void stream(@PathVariable Long resourceId, HttpServletRequest request, HttpServletResponse response) throws Exception { ResourceEntity resource = resourceMapper.selectById(resourceId); if (resource == null) { response.setStatus(HttpServletResponse.SC_NOT_FOUND); return; } FileSystem fs = HdfsUtil.getFileSystem(); Path path = new Path(resource.getHdfsPath()); FileStatus fileStatus = fs.getFileStatus(path); long fileLength = fileStatus.getLen(); long start = 0; long end = fileLength - 1; String rangeHeader = request.getHeader("Range"); if (rangeHeader != null && rangeHeader.startsWith("bytes=")) { String range = rangeHeader.substring("bytes=".length()); String[] parts = range.split("-"); start = Long.parseLong(parts[0]); if (parts.length > 1 && !parts[1].isEmpty()) { end = Long.parseLong(parts[1]); } } if (start > end || start < 0 || end >= fileLength) { response.setStatus(HttpServletResponse.SC_REQUESTED_RANGE_NOT_SATISFIABLE); response.setHeader("Content-Range", "bytes */" + fileLength); return; } response.setStatus(rangeHeader != null ? HttpServletResponse.SC_PARTIAL_CONTENT : HttpServletResponse.SC_OK); response.setHeader("Content-Type", "video/mp4"); response.setHeader("Accept-Ranges", "bytes"); response.setHeader("Content-Range", "bytes " + start + "-" + end + "/" + fileLength); response.setHeader("Content-Length", String.valueOf(end - start + 1)); try (FSDataInputStream in = fs.open(path)) { in.seek(start); byte[] buffer = new byte[8192]; long remain = end - start + 1; while (remain > 0) { int len = in.read(buffer, 0, (int) Math.min(buffer.length, remain)); if (len == -1) { break; } response.getOutputStream().write(buffer, 0, len); remain -= len; } response.getOutputStream().flush(); } }

实操里最容易翻车的三个点：

• Content-Length必须是分段长度end - start + 1，不是整个文件长度。写错了播放器要么白屏要么一直转圈；
• FSDataInputStream读完文件后，不要手动关闭response.getOutputStream()，让Servlet容器统一管理，否则Spring容易报“response has already been committed”之类的异常；
• 返回码必须区分：有Range头返回206，没有Range头返回200。

3.4 删除与孤儿文件：元数据与物理存储的一致性

删除功能看起来简单，实际是这类系统里最容易被忽视的“数据一致性”雷区。如果教师删除一个课件时只删MySQL记录，不删HDFS文件，时间一长HDFS上堆满孤儿文件。每个文件在NameNode内存里都有元数据，几千个小文件的元数据就会给NameNode造成明显压力。

我的删除逻辑是四步：

1. 根据resourceId查出hdfs_path；
2. 执行fs.delete(path, true)删除HDFS物理文件；
3. 如果删除成功，删除MySQL记录；
4. 如果第2步失败，不删MySQL记录，而是把资源状态标记为“删除失败”，由夜里定时任务重试。

这里值得说明的是：HDFS删除文件是逻辑删除，文件会先进回收站，不会立刻释放磁盘空间。但至少在系统层面不会再被业务引用。如果集群配置了fs.trash.interval非零，NameNode会在保留期后自动清理。

4. 学习行为分析：让Hadoop真正跑起来

4.1 统计需求拆解与日志采集口径

分析模块的需求不能太飘，落地到三个可交付指标：

日志从哪来？前端播放器每30秒上报一次心跳，后端写一条access_log记录：userId, resourceId, startTime, duration。由于心跳间隔固定，30秒可以看作最小统计粒度。学生暂停、拖拽、关闭页面都不影响统计口径，只有播放器真正处于播放状态时才上报心跳。

4.2 定时导出日志到HDFS

access_log表越来越大，统计查询如果直接跑在MySQL上，既违背“基于Hadoop”的设计初衷，也会拖垮主业务库。我的做法是每天凌晨2点用Spring的@Scheduled注解做一次日志导出：

@Component public class AccessLogExportTask { @Autowired private AccessLogMapper accessLogMapper; @Scheduled(cron = "0 0 2 * * ?") public void exportYesterdayLogs() throws IOException { String date = LocalDate.now().minusDays(1) .format(DateTimeFormatter.BASIC_ISO_DATE); List<AccessLog> logs = accessLogMapper.selectByDate(date); if (logs.isEmpty()) { return; } StringBuilder sb = new StringBuilder(); for (AccessLog log : logs) { sb.append(log.getUserId()).append(',') .append(log.getResourceId()).append(',') .append(log.getStartTime().format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss"))) .append(',') .append(log.getDuration()).append('\n'); } String hdfsPath = "/multimedia/logs/access/" + date + ".log"; try (ByteArrayInputStream in = new ByteArrayInputStream(sb.toString().getBytes(StandardCharsets.UTF_8))) { HdfsUtil.upload(in, hdfsPath); } } }

这里故意选用yyyyMMddHHmmss格式的时间字符串，而不是带横杠和冒号的格式，是为了后续MapReduce解析时用substring切分小时字段，避免在工具类里处理一堆时间格式化逻辑。日志量大的话，可以先把字符串用Gzip压缩后再传HDFS，MapReduce框架能自动识别.gz后缀并解压读取。

4.3 编写MapReduce作业：按小时统计播放量

统计“一天24小时播放量分布”的MapReduce作业是整套分析逻辑里最简单也最典型的任务。Mapper负责从每行日志里提取小时字段并输出hour -> 1，Reducer负责把同一个小时的计数相加。

public class AccessHourlyMR { public static class HourMapper extends Mapper<Object, Text, Text, IntWritable> { private static final IntWritable ONE = new IntWritable(1); private Text hourKey = new Text(); @Override protected void map(Object key, Text value, Context context) throws IOException, InterruptedException { // 日志格式: userId,resourceId,startTime(yyyyMMddHHmmss),duration String[] fields = value.toString().split(","); if (fields.length < 3) { return; } String startTime = fields[2]; if (startTime.length() < 10) { return; } // yyyyMMddHHmmss 前10位是 yyyyMMddHH hourKey.set(startTime.substring(0, 10)); context.write(hourKey, ONE); } } public static class HourReducer extends Reducer<Text, IntWritable, Text, IntWritable> { private IntWritable result = new IntWritable(); @Override protected void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException { int sum = 0; for (IntWritable val : values) { sum += val.get(); } result.set(sum); context.write(key, result); } } public static void main(String[] args) throws Exception { Configuration conf = new Configuration(); Job job = Job.getInstance(conf, "access hourly stats"); job.setJarByClass(AccessHourlyMR.class); job.setMapperClass(HourMapper.class); job.setCombinerClass(HourReducer.class); job.setReducerClass(HourReducer.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(IntWritable.class); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } }

提交作业的命令：

hadoop jar access-log-job.jar AccessHourlyMR \ /multimedia/logs/access/20240801.log \ /multimedia/logs/stats/20240801

有一个细节值得注意：Mapper里如果只想提取小时，用substring(8, 10)；如果像这里一样想保留“日期+小时”维度做日报表，就用substring(0, 10)。分析维度不同，键的设计就不同，这决定了后面报表能看什么粒度。

4.4 结果回写MySQL与报表展示

MapReduce的默认输出是一系列part-r-00000文件，里面每行是“键 + Tab + 值”。分析结果直接让报表系统去读HDFS显然不现实，应当把统计结果导入MySQL的stats表。

读取结果并批量插入：

public void importStats(String statDate, String statsPath) throws IOException { FileSystem fs = HdfsUtil.getFileSystem(); Path path = new Path(statsPath + "/part-r-00000"); List<StatsEntity> batch = new ArrayList<>(); try (FSDataInputStream in = fs.open(path); BufferedReader reader = new BufferedReader(new InputStreamReader(in))) { String line; while ((line = reader.readLine()) != null) { String[] parts = line.split("\t"); if (parts.length < 2) { continue; } StatsEntity stats = new StatsEntity(); stats.setMetric("hourly_play_count"); stats.setDimension(parts[0]); stats.setValue(Integer.parseInt(parts[1])); stats.setStatDate(statDate); batch.add(stats); if (batch.size() >= 500) { statsMapper.batchInsert(batch); batch.clear(); } } } if (!batch.isEmpty()) { statsMapper.batchInsert(batch); } }

这里要解释为什么不用MapReduce自带DBOutputFormat直接把结果写MySQL：分布式环境下每个Reduce任务都往一个MySQL单点写，连接数多、事务不好控制，容易把主库拖挂。相对稳妥的做法始终是“HDFS出结果，Java批量导库”，中间人虽然多了一步，但可控性高得多。

4.5 为什么不建议在这个阶段引入Hive和Spark

很多同学做这类课题时喜欢“全家桶”，Hive、Spark、Flink一股脑全写进架构图。但一个以“大学多媒体教学管理”为业务核心的课设，分析需求就三维度，数据量下去最多百万级，MapReduce一个作业几分钟跑完已经足够。

引入Hive意味着要多部署MetaStore和HiveServer2，还要解决Spring Boot和Hive交互的驱动问题；引入Spark则要额外考虑YARN资源分配，本地开发环境也更容易出幺蛾子。这些工具的部署成本会反过来挤压你做核心业务的时间。比较聪明的做法是：主体实现用MapReduce，论文或答辩的“进阶展望”里写“后续可引入Hive降低维度建模门槛，或使用Spark提升实时性”，既满足课题要求，又显得有规划。

5. 开发调试与部署阶段必须避开的坑

5.1 版本选型与依赖冲突

这套系统我实测下来最稳的组合是：

Maven引入Hadoop客户端时要特别小心传递依赖冲突。最典型的是hadoop-client会带入旧版log4j和slf4j绑定，导致Spring Boot应用启动后日志不输出。我处理的方式是排除掉slf4j-log4j12：

<dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-client</artifactId> <version>3.3.4</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> </dependency>

5.2 本地连集群的排查链路

本地开发环境连远程Hadoop集群，最容易在“连不上”这件事上卡一整天。我的排查顺序是固定的：

1. 先确认集群core-site.xml里的fs.defaultFS，发现很多同学填错了端口或主机名；
2. 本地执行telnet node01 8020，判断NameNode RPC端口通不通；不通就检查防火墙和云安全组；
3. 如果通了，再写一个最小Java测试类，只做FileSystem.get(conf)和fs.mkdirs，排除业务代码干扰；
4. 使用域名而不是IP时，检查本地hosts解析；直接填IP虽然简单，但集群迁移后要改代码，不推荐。

本地跑起来后，Hadoop会打印一堆类似NativeCodeLoader的WARN，这是缺少本地原生库的提示。只要HDFS读写正常，可以忽略，不影响功能。

5.3 小文件问题的两条应对策略

HDFS擅长存大文件，不擅长存海量小文件，因为每个文件都对应NameNode里的一条元数据记录。课件PDF、Word这类资源恰恰是典型的小文件。我在实际项目里采用了两条策略：

• 视频这类大文件直接进HDFS，这是主要存储场景；
• 同课程的课件类小文件，用一个归档文件统一存放，数据库里记录的是归档文件内的偏移量和长度，前端要下载单个课件时再按偏移量seek读取。

归档策略的代码量会多个几十行，但对NameNode的压力是数量级下降。答辩时如果能主动提到“小文件合并策略”，基本可以把这道加分题拿住。

5.4 权限、失败补偿与不完整文件处理

权限问题的根源是客户端OS用户与HDFS用户不一致。统一把服务用hadoop用户启动是最省事的做法；如果坚持用当前用户启动，每次HDFS操作前都要用UserGroupInformation.createRemoteUser("hadoop")做身份切换，代码里到处是doAs包裹，可读性很差。

HDFS写一半失败会残留不完整文件，这是另一个高频坑。我处理大文件上传时加了“临时文件 + rename”机制：先写/multimedia/tmp/xxx.tmp，写完再fs.rename到正式目录。这个做法本质上跟数据库“写临时表再切换”是同一套思路，目的都是避免把半成品暴露给下游。

5.5 YARN资源不足时用本地模式验证

MapReduce作业提交到YARN后如果一直卡在ACCEPTED状态，多半是集群内存资源不足。此时不要反复重试，先在本地解决逻辑问题。在IDE里直接运行Job的main方法，如果不配置mapreduce.framework.name=local，默认不会提交到YARN，但注意输入输出路径要改成本地文件路径。等本地跑通后，再把参数替换成HDFS路径重新打包提交到集群。

本地模式还有一个好处：可以在Controller里直接调用MapReduce逻辑，做“上传日志 -> 触发统计 -> 回写MySQL”的一体化联调，不用频繁操作YARN。

6. 生产级重构方向与答辩加分建议

6.1 存储层：对象存储才是视频业务的最终形态

聊一个比较实在的问题：如果这个系统要做成生产级，HDFS其实不是媒体存储的最优解。对象存储（比如MinIO、云厂商的OSS）才是视频点播场景的主流，它们自带CDN分发、防盗链、分片上传、断点续传，对公网访问的友好度远超HDFS。

那为什么还建议用HDFS做课题？因为题目要求“基于Hadoop平台”，更因为论文里需要一条贯穿始终的大数据链路：存文件在HDFS、分析日志靠MapReduce。你完全可以做一个“业务层面向接口、存储层可替换”的设计：接口定义好putStream/getStream方法，底层可以切到HDFS实现，将来也可以切到MinIO实现。这种抽象思维比“我会用某个具体组件”更能体现设计能力。

6.2 分析层：从MapReduce向实时引擎演进

MapReduce的缺点是延迟高，一个作业从提交到出结果动辄几分钟，适合跑日报、周报这类离线任务。如果以后要支持“教师端实时热门视频榜”，应该引入Flink做流式计算，上游读Kafka里的播放心跳，下游秒级更新排行。

在论文里写这部分时，不要写“系统已经支持实时分析”，而是明确区分“当前系统是T+1离线分析，后续演进方向是实时分析”。诚实且有条理，比夸大技术范围更容易通过评审。

6.3 论文与答辩要说清楚的三个问题

我评审这类课题时，最在意三个问题能不能答清楚：

1. “为什么用Hadoop”：答“因为用了HDFS统一存储多媒体文件并支撑离线分析”，而不是“因为题目要求”；
2. “Hadoop在系统里到底做了什么”：举出上传、播放、日志分析三条链路里HDFS和MapReduce的具体参与方式；
3. “系统的瓶颈和演进方向”：说出小文件问题、离线延迟问题，以及对象存储和实时计算的替代方案。

这三条能讲明白，论文和答辩基本就稳了。

提示：做这类课题的最大忌讳是“为了用Hadoop而用Hadoop”。做一个只有增删改查的管理系统并不难，难的是把多媒体存储、行为日志与分析链路闭环跑通。设计时多追问自己“数据存哪里、怎么流转、怎样产生价值”，比多写十页代码更有用。

最后再说一点实际的体会。我在做这套系统的过程中，最耗费时间的环节并不是Spring Boot的CRUD，而是“视频流播放支持拖拽”和“HDFS权限与文件一致性”这两个点。前者需要你理解HTTP Range协议，后者需要你理解分布式文件系统的设计哲学。如果你目前卡在其中的某个环节，建议先放下代码，把底层原理读一遍再动手——这会比在搜索引擎里反复试错快得多。整个项目做完，你对“关系型库管业务、HDFS管文件、离线分析出报表”这条组合链路的理解，会跟着上一个台阶。