1. 选题背后的逻辑：岗位推荐系统为何必须上大数据平台

每年到了毕业设计季，我都看见不少同学为选题发愁：纯管理系统做腻了，纯算法题又担心工作量撑不起论文篇幅。这时候，把“Spring Boot 业务开发”和“Hadoop 分布式计算”组合在一起的岗位推荐系统，就成了一个很稳的选题方向。它既有传统 Web 系统的完整闭环，又有大数据处理环节，还能写出用户画像、协同过滤、离线计算这些听起来扎实的章节。

很多同学一开始会问：推荐系统在普通 MySQL 上也能做，为什么非要用 Hadoop？这个问题恰恰是答辩时最容易被问到的，也是整个选题的立足点。你可以在需求分析里明确写出来：岗位推荐涉及的是海量日志型数据，比如用户浏览职位记录、简历投递记录、职位关键词权重表。这些数据每小时都在增长，几十万条甚至上百万条的日志如果用单机数据库每天全量重算推荐结果，耗时太长，而且会影响在线接口的响应速度。用 Hadoop 的意义就是把这部分离线批量计算抽离出来：日志文件落到 HDFS，MapReduce 任务定期清洗和计算，产出推荐结果存入数据库，Spring Boot 在线应用只负责读取结果并向用户展示。这种“离线计算 + 在线展示”的架构，在工业界非常常见，也足够支撑一篇高分毕设。

这个选题适合什么基础的人？我的判断是：Java Web 基础过关、写过至少一个 Spring Boot 项目、能独立完成增删改查的人。Hadoop 部分不需要你从零造轮子，会用 Hadoop 生态里最基础的 HDFS 和 MapReduce 就够了，不涉及 Spark、Flink 这些更复杂的实时框架。如果学校选了阿里云或者腾讯云的服务器作为测试环境，部署一套 Hadoop 完全可行；本地机器配置一般的话，用伪分布式模式也完全够用。我在后面的章节里会按“能跑、能讲、能过答辩”的标准，把整个项目的设计与实现细节全部拆开讲。

2. 技术选型拆解：Spring Boot 负责在线，Hadoop 负责离线

2.1 系统整体架构与模块划分

先说架构层。这个系统不适合做成单体巨石应用，也不适合搞微服务那套复杂治理，推荐用前后端分离 + 离线计算中心的两层结构，代码量适中，结构层次又清楚。

前端我可以选 Vue 或 Element UI 写管理台页面，也可以直接用 Thymeleaf 做服务端渲染。考虑到毕设查重和答辩演示的方便性，我更倾向于 Vue 构建的独立前端，配合 Nginx 部署，这样项目可以分成前端、后端、大数据处理三个独立目录，每个目录都能单独讲解。后端就是 Spring Boot 标准工程，负责用户登录、职位管理、简历管理、推荐结果查询、后台数据统计等接口，数据库用 MySQL，缓存看情况加一层 Redis（不做硬性要求）。大数据层则包括 HDFS 上的日志文件、MapReduce 计算任务、以及任务调度脚本。

这里必须强调一个设计原则：在线业务层绝不直接访问 Hadoop 上的原始数据。Spring Boot 所有的推荐结果查询都必须走 MySQL 或 Redis 中的预计算结果。这样做的好处有三个：一是响应速度有保障，用户查询推荐岗位不会等到 MapReduce 跑完；二是避免在线应用和离线任务互相干扰，Hadoop 在跑全量计算时占用的资源不会拖垮 Web 服务；三是逻辑清晰，答辩的时候你可以明确讲出“离线计算与在线查询的分离”。

2.2 为什么选 Hadoop 生态里的这四件套

Hadoop 生态非常庞大，但作为毕设项目，我不建议把所有组件都塞进来。核心保留四样：HDFS、MapReduce、YARN、ZooKeeper（如果做高可用才需要 ZooKeeper；单节点伪分布式可以省掉）。选型依据如下：

有人会问：为什么不用 Hive 写 SQL 代替 MapReduce？Hive 在这个项目里确实也能完成一部分统计工作，比如按职位分类统计热门程度，用 HiveQL 一条语句就能搞定。但作为毕设，MapReduce 代码能让你的算法部分更有说服力。因为你需要展示自己“理解分布式计算过程”，而不只是调用工具。我在第四节会给出核心算法的实际代码框架，你完全可以直接拿来做基底。

2.3 数据从哪里来：伪造日志与真实场景的平衡

岗位推荐系统最容易被卡住的一个点，就是“我手上没有真实用户行为数据”。这里我给的建议非常务实：自己生成模拟数据，但生成方式必须贴近真实场景。你可以写一个简单的数据生成器，模拟 500 个虚拟用户、1000 个岗位、每个用户浏览过 20~50 个岗位、对其中一部分投递了简历、收藏了一部分。行为类型可以包括：浏览、投递、收藏、浏览时长、搜索关键词。这些行为最终以日志形式写入文本文件，每个字段用制表符分隔，格式如下：

用户ID 岗位ID 行为类型 行为时间 停留时长(秒) U1001 J2034 VIEW 2024-06-12 14:23:01 85 U1001 J2077 DELIVER 2024-06-12 14:25:30 0 U1002 J3108 COLLECT 2024-06-12 15:01:12 0

为什么我会特意强调“用制表符分隔”？因为在 MapReduce 的 Map 阶段，用StringTokenizer或split("\t")解析最方便，而且如果日志里出现逗号、空格，很容易切错字段，这是初学者踩过最多的坑之一。生成的数据量建议控制在 30 万条以上，既能体现大数据处理的必要性，又不会让单机跑太久。我实测 30 万条日志在伪分布式模式下，一个 Complete 的推荐任务大约跑 3~5 分钟，演示节奏刚刚好。

3. 数据链路完整设计：从收集日志到产出推荐结果

3.1 六步流程，缺哪一步都不完整

整个推荐系统的数据链路，我认为必须分成六步：数据产生、数据采集、数据清洗、数据计算、结果存储、结果展示。第一步和第二步在用户端完成，用户在网页上点击查看职位详情时，前端通过接口把行为上报到后端，后端再把行为日志异步写入 HDFS。这里要注意的是：直接在 Controller 里写 HDFS 会阻塞网络请求，必须在 Service 层用异步线程池处理，或者先写入本地文件再由定时任务上传。

数据清洗的目的是去掉残缺日志、重复日志和无意义数据。比如用户只停留了 1 秒就关掉的浏览记录，很可能只是误触，这类记录要过滤掉。我在清洗阶段设置了三个规则：停留时长小于 3 秒的浏览行为删除；同一用户对同一岗位在 10 分钟内的重复浏览只保留一条；行为类型字段不属于枚举值的记录直接丢弃。这个清洗逻辑可以直接写在一个单独 MapReduce 任务里，输出结果到 HDFS 的/rec/clean/目录。

清洗之后才进入推荐计算的输入阶段。计算任务读入清洗后的行为数据，结合职位信息表，计算用户与岗位之间的偏好得分矩阵。这个矩阵输出格式为用户ID 岗位ID 偏好分数。然后系统再根据偏好矩阵，为每个用户生成 Top N 推荐列表，最终写回 MySQL 的recommend_result表。最后一步，Spring Boot 提供 RESTful 接口，前端页面拉取结果渲染成“为你推荐”栏目。

3.2 用户画像与职位画像：推荐系统里的两个实体

要让推荐结果“看起来合理”，你不能只做简单的“热门岗位推荐”，必须在论文和系统里体现出画像的概念。用户画像在这个项目里相对轻量，我用三张维度表来描述：基础信息维度（学历、专业、期望城市、期望薪资）、行为偏好维度（经常浏览的职位类别、投简历的高频关键词）、活跃度维度（近 7 天登录次数、平均浏览时长）。

职位画像则更简单，一张岗位表加上一张标签表。岗位表记录职位名称、公司名称、所属行业、城市、薪资范围、学历要求、经验要求；标签表则把岗位映射到若干个标签关键词，比如“Java 开发”映射到[后端开发, 编程, Java, Spring]，“UI 设计”映射到[设计, 视觉, Figma, 交互]。这些标签在对用户行为日志做关键词统计时会非常有用。我在实现时没有引入复杂的 NLP 分词，而是基于职位表里已有的标签做词频统计，既省事又能讲清楚逻辑。

3.3 冷启动问题怎么在毕设里交代清楚

只要讲到推荐系统，评委十有八九会问冷启动：“新用户没有行为数据，你推荐什么？”这个问题不需要你真正去实现复杂的解决方案，但你必须能给出合理的设计。我的做法是：当一个用户没有任何行为记录时，系统默认采用热门职位兜底策略。计算全站岗位的浏览量和投递量，加权得到热门分，排序后取前 20 条作为默认推荐。等用户产生了一定的行为记录，再切换到基于协同过滤的个性化推荐。

这一策略的代码量很少，但它在论文里的价值很高，因为它证明你真的考虑过推荐系统实际落地时的边界情况。我强烈建议把冷启动处理逻辑画进流程图里——从判断用户是否有行为记录开始，分成两个分支，一条是热门兜底，一条是协同过滤个性化推荐，然后各自走到结果存储。答辩时用这张图讲两分钟，整个项目逻辑就通了。

4. 推荐引擎核心：基于物品协同过滤的 MapReduce 实现

4.1 算法思路：为什么选物品协同过滤而不是用户协同过滤

在推荐算法选型上，我做的是基于物品的协同过滤（Item-based Collaborative Filtering），而不是基于用户的版本。原因很实际：岗位数据量远小于用户行为数据量，岗位更新频率低，计算岗位之间的相似度矩阵比较稳定，而且解释性好——你可以直接跟评委说：因为“A 用户浏览了 Java 后端岗位，又经常浏览数据库相关岗位，所以系统认为这两个岗位相似，于是给浏览过后端岗位的 B 用户推荐数据库岗位”。这个解释通俗易懂，面评时不至于陷入复杂公式推导的泥潭。

算法分成三大步：第一，建立“用户-行为”评分矩阵；第二，计算岗位与岗位之间的相似度；第三，结合用户的历史行为，为每个用户生成未浏览岗位的预测分数，取 Top N。其中第二步是计算量最大的部分，也是最适合放到 Hadoop 上跑的部分。

4.2 Mapper 阶段：把行为日志重新组合成同现向量

我直接给出关键代码框架，你可以依托这个改写成自己的实现。假设清洗后的数据存放在 HDFS 的/rec/clean/behavior.txt，内容包含用户ID 岗位ID 行为权重，权重规则是：浏览记 1 分，收藏记 3 分，投递记 5 分。那么 Mapper 端要做的，是把每个用户的岗位行为列表组合成一个向量，输出 Key 是用户 ID，Value 是该用户行为过的所有岗位列表。

public class CoOccurrenceMapper extends Mapper<LongWritable, Text, Text, Text> { @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String[] fields = value.toString().split("\t"); if (fields.length != 3) return; String userId = fields[0].trim(); String jobId = fields[1].trim(); String weight = fields[2].trim(); context.write(new Text(userId), new Text(jobId + ":" + weight)); } }

这一步没有任何复杂逻辑，就是为下一步的Reducer打基础。为什么不在 Mapper 里直接做同现统计？因为同一个用户的行为日志会被分散到不同的 Map 分片中，Mapper 无法一次性看到某个用户的全部行为向量，必须交给 Reducer 做分组。这是理解 MapReduce 流程的关键点：Shuffle 阶段自动把相同 Key 的数据聚合到一起。

4.3 Reducer 阶段：统计岗位共现次数与相似度

Reducer 接收的数据格式是用户ID [(岗位1:权重1), (岗位2:权重2), ...]。对于每个用户，其行为过的岗位两两之间构成一个“共现对”，比如用户浏览过岗位 A 和岗位 B，那么 A-B 这对组合就多了一次共现。最终共现次数越高的岗位对，说明它们越经常同时出现在用户的兴趣范围里，也就越相似。

public class CoOccurrenceReducer extends Reducer<Text, Text, Text, Text> { @Override protected void reduce(Text key, Iterable<Text> values, Context context) throws IOException, InterruptedException { List<String> jobWeightList = new ArrayList<>(); for (Text value : values) { jobWeightList.add(value.toString()); } // 两两组合，输出 岗位A:岗位B 的共现计数 for (int i = 0; i < jobWeightList.size(); i++) { String jobIdA = jobWeightList.get(i).split(":")[0]; for (int j = i + 1; j < jobWeightList.size(); j++) { String jobIdB = jobWeightList.get(j).split(":")[0]; context.write(new Text(jobIdA + ":" + jobIdB), new Text("1")); } } } }

这里为了演示方便省略了去重和权重累加逻辑，实际项目中更常见的做法是输出岗位A:岗位B 共现次数，然后跑第二个 MapReduce 任务，读入共现次数表与岗位自身热度值，计算相似度矩阵。第二个任务的输出格式为岗位A 岗位B 相似度分值。相似度公式我直接采用共现次数 / sqrt(岗位A出现次数 * 岗位B出现次数)，这也是经典的归一化方式，数值范围在 0 到 1 之间，便于排序。

4.4 生成 Top N：第三个 MapReduce 任务还是干脆用 SQL？

生成最终推荐列表时，我建议停止使用 MapReduce，把相似度矩阵和用户历史行为导入 MySQL 后，用一条 SQL 或者 Spring Boot 内存计算搞定。原因是：到了最后一步，数据量已经被压缩到很小，比如一万个岗位对，一张 Redis 哈希表或 MySQL 表就能存下，再用 MapReduce 有点杀鸡用牛刀。推荐列表的生成逻辑是：找到用户行为历史里的岗位，取出每个岗位的相似岗位列表，按加权分数排序，过滤掉用户已经投递或已经明确不感兴趣的岗位，取前 20 条写入结果表。

这一步的取舍很重要，答辩时你要主动提一句：“考虑到最后阶段数据量较小，为了避免不必要的网络和磁盘开销，我选择用传统数据库完成最终排序，这也体现了架构上对‘不同规模数据处理策略’的思考。”这句主动补充，能让评委认为你对整个系统进行了全局权衡，而不是只会套框架。

5. Spring Boot 服务层模块化设计：从 Reducer 输出到在线接口

5.1 后端代码结构的目录组织方式

后台工程我按controller / service / mapper / domain / config / common分包，每个包承担明确职责。这种分法对大家来说已经是常识了，但我想重点提醒两件事：第一，不要把 Hadoop 相关代码写进 Web 模块，大数据处理任务应该单独放在独立模块或独立目录，比如job-recommend-engine/；第二，在 Spring Boot 工程里加一个engine-status字段，记录上一次离线推荐任务是否执行完成、结果文件时间戳是什么时候。这个字段能帮你在调试时快速判断：用户看到的推荐结果到底是不是最新计算的。

推荐相关接口我按职责拆分，大约四个：

refresh接口是最有“大数据味”的一个，它的实现逻辑是用 Java 调用 Shell 命令提交 Hadoop JAR 包，代码大致如下：

@Service public class HadoopTaskService { public void triggerRecommendTask() { String cmd = "hadoop jar /opt/jobRec/job-recommend-engine.jar com.campus.jobrecommend.mapreduce.CoOccurrenceDriver"; ProcessBuilder pb = new ProcessBuilder("/bin/sh", "-c", cmd); // 配置日志输出、错误流、超时处理... } }

注意ProcessBuilder必须在 Linux 环境的后台执行，不能直接放在定时任务里同步等待，否则很容易因为 Hadoop 任务跑太久导致 Web 请求超时。我这里采用的是异步提交，把Process对象交给线程池，再通过日志文件观察执行结果。

5.2 数据表设计：四张核心表足够撑起整个系统

数据库层面我主要设计四张核心表：

• user_profile：用户基础信息、学历、期望城市、薪资范围、行为统计字段。
• job_info：职位信息、公司信息、薪资、学历要求、岗位标签。
• user_behavior_log：用户行为明细，同步自 HDFS 清洗结果。
• recommend_result：最终推荐结果，字段包括user_id, job_id, score, rank, create_time。

这里我特别想强调recommend_result表的设计：必须加 rank 字段和 create_time 字段。rank 表示推荐顺序权重，前端直接按 rank 排序；create_time 用于区分计算批次，出现异常时可以根据时间回溯是哪一轮任务产生的结果。很多系统死在“结果表里没有批次字段”，以至于数据更新后旧数据还在页面上残留，调试时完全没法定位。

Redis 在这个项目里是可选项。我建议把热门岗位列表和用户短期推荐结果放缓存，缓存过期时间设置为 12 小时，和离线计算周期保持一致。这样在线接口的响应时间基本能做到 50 毫秒以内，演示时流畅度会明显更好。

5.3 前端页面怎么呈现才有“推荐”感觉

前任前端页面如果只是表格，那答辩观感会差很多。我给两个具体的页面建议：首页“职位推荐”栏目，做成卡片式瀑布流，卡片上同时展示“为你推荐”和推荐理由标签，理由字段先从后端返回，比如“因为你看过 Java 后端岗位”，这个解释其实是基于相似岗位的标签交集生成的；后台管理页也别忘了做图表，用 ECharts 展示用户行为分布、热门岗位排行、各行业岗位数量占比。图表这种元素在答辩演示时很容易加分，因为它直接可视化地表现了整个数据链路的价值。

别小看推荐理由字段，它的代码量很小，但对说服评委“系统是智能的”起着关键作用。实现逻辑是：生成推荐结果时，把推荐岗位与用户最近浏览的岗位做标签交集，取最高重合度的标签作为推荐理由。“因为你关注了 Java 开发，所以为你推荐中高级后端工程师”——这比单纯一个推荐列表可信得多。

6. 部署调试实战：从伪分布式到远程服务器，一套完整的验证流程

6.1 本地环境的必要配置与验证顺序

在我带过的多个项目经验里，最影响效率的坑是环境版本不一致。推荐一套比较稳妥的版本组合：JDK 1.8（或 Java 8 兼容版本）、Hadoop 3.2.x、Spring Boot 2.3.x、MySQL 5.7。Hadoop 3.x 在 JDK 8 下的兼容性最好，Spring Boot 2.3.x 对 JDK 8 也维护得最稳定，不建议盲目上 JDK 17 + Hadoop 3.3 的组合，因为 Hadoop 某些脚本在更高版本 JDK 下会出现模块访问警告，虽然不影响运行，但会干扰你排查其他报错。

整个项目拿到手里后的验证顺序，我建议严格按四步走：

1. 单机 Web 功能验证：不启动 Hadoop，先让 Spring Boot 跑起来，用初始化 SQL 导入测试数据，检查用户登录、岗位管理、页面展示是否正常。此时推荐接口会因为没有数据而返回空列表，这是正常的。
2. HDFS 与日志上传验证：手动把模拟行为日志放入 HDFS，用命令hdfs dfs -put behavior.log /rec/clean/确认文件可见。
3. 离线任务验证：提交推荐计算 JAR，观察 YARN 日志，确认 Map 和 Reduce 的进度条都能跑满 100%，并检查结果文件是否生成。
4. 在线链路验证：数据库刷新推荐结果表，重启 Web 服务，访问推荐接口查看是否有数据。

每一层通过后再进入下一层，不要在第一步没通过的情况下直接去跑大数据任务，否则日志一多，很难判断错误到底出在哪个环节。

6.2 远程调试的常见问题：改完代码如何快速生效

这个项目天然涉及“本地开发 + 远程服务器部署”的场景，所以远程调试的问题几乎一定会碰到。我有几条心得：

第一，Hadoop 集群上的结果文件和代码之间要建立“版本感”。每次修改 MapReduce 代码并重新打包后，记得删除 HDFS 上的输出目录，比如/rec/result，否则 Hadoop 会直接报org.apache.hadoop.mapred.FileAlreadyExistsException，这个错误在开发初期特别容易遇到。删除命令我只用hdfs dfs -rm -r，别用-skipTrash，方便误删恢复。

第二，远程服务器上推荐保留两套启动脚本，一套是 Web 服务的启动停止脚本，一套是 Hadoop 任务的提交脚本。脚本里加上日志重定向，比如nohup hadoop jar xxx.jar > /opt/jobRec/logs/engine.log 2>&1 &。我在实际调试时遇到过同伴为了看控制台输出把任务放在前台执行，一个终端占了半小时，后面其他操作全部卡死。日志文件的设置不是形式主义，是真正能救命的。

第三，如果远程服务器没有可视化监控环境，我建议把 MapReduce 任务的关键指标写入本地日志文件，比如输出“共处理 X 条日志，生成 Y 个共现对，耗时 Z 秒”。这些日志不仅能用来排查问题，还能直接作为论文里“性能测试”数据来源。我常对学员说：调试时积累的运行日志，就是你论文性能分析章节最真实的数据，比现编数据可信一百倍。

6.3 性能优化中最值得做的三件事

大数据项目的性能不能等跑挂了再优化，应该在设计初期就避免几个低效操作。最值得做的优化有三项：

合并小文件：日志文件如果被切得特别碎，HDFS 上每个小文件都会占用一个 NameNode 对 象，影响读写速度。上传大量日志前，先在本地用cat合并成几个大文件，再执行put操作。

控制 Reducer 数量：MapReduce 任务的 Reducer 数量默认是 1，数据量大时容易成为瓶颈。可以在 Driver 类里显式指定,job.setNumReduceTasks(4)。在伪分布式单节点上，Reducer 数量设成 CPU 核数即可，不会过度压榨资源。

合理设置压缩格式：中间结果使用压缩可以大幅降低磁盘 IO。但要注意，如果结果量不大，建议直接输出纯文本，方便直接查看推荐结果是否符合预期。等系统稳定了再开启压缩做进一步优化。

这些优化并不复杂，每项代码量都很小，但它们可以在论文里凑成一个小节：“系统性能优化策略”。而且每一句都能落到具体操作上，评委如果追问，你也回答得上来，不会陷入“我百度到的”这种尴尬。

7. 能让你顺利答辩的四个加分细节与定制方向

7.1 答辩演示时，千万不要跳过“等待计算”的现场感

我在线下听过多次答辩，发现一个普遍问题：很多同学演示推荐系统时，只展示页面点击效果，一路点得非常顺滑，反而被评委质疑“你这一步是不是没有跑过 MapReduce”。我建议你在演示时放慢节奏，主动展示一次任务触发的全过程：在后台点击“刷新推荐”，然后打开 YARN 日志界面，看着任务提交、执行、完成，再回到业务页面刷新结果。这个过程虽然耗时几分钟，但它的说服力极强，它向评委证明系统是真的可以运行的大数据闭环。

提前把数据量提前到 40 万条左右，单机 MapReduce 任务大约 6 分钟完成。演示时在等待期间讲解系统架构，时间刚好够用。

7.2 可定制扩展的四个方向，选一个就够差异化

这个项目的定制扩展空间很大，但我不建议贪多。以下四个方向里挑一个做，就能让你的项目明显区别于同组其他作品：

• 增加基于内容的推荐作为混合策略：在协同过滤结果旁边，额外根据用户的简历关键词直接匹配岗位标签，两路结果按比例融合。
• 接入简单可视化大屏：做一个数据大屏页面，展示实时行为日志量、岗位供需比、各城市薪资分布，技术含量不高但视觉效果非常好。
• 增加用户反馈闭环：在推荐列表中加入“不感兴趣”按钮，用户点击后把这些负反馈写入日志表，下次计算时降低对应岗位权重。
• 将推荐系统改成实时半在线模式：在 Spring Boot 里对用户最近 1 小时的行为做即时重算，每天凌晨再由 Hadoop 做全量重算。这个扩展需要引入消息队列，但可以让“实时推荐”这个词语理直气壮地出现在标题里。

这些方向都是在原有数据链路基础上做增量，不会推翻核心架构，加代码量从几百行到两千行不等，可以根据自己的时间安排选。

7.3 文档和论文撰写的核心技巧

毕设不只是代码，文档也是大头。我在辅导过程中反复强调三条经验：第一，画图比文字重要得多。系统架构图、数据链路图、算法流程图各一张，用清晰的可视化语言展示整体逻辑，比任何冗长的文字描述都更有效。画图时请注意统一元素格式，避免网上下载的图标风格混乱。

第二，性能测试的数据必须来自实际日志。例如记录“模拟用户量 1000，岗位量 2000，行为日志 35 万条，完整推荐任务耗时 317 秒，Web 接口平均响应 42ms”，这些数据如果是从真实运行环境中收集的，导师和评委一眼就能看出其可信度。造假数据在面评环节很容易露馅，任何一个逻辑推敲就能发现矛盾。

第三，论文正文与系统实现要一一对应。你写了“系统采用离线与在线分离架构”，那么项目里必须真实存在两个模块；你写了“基于物品协同过滤算法”，那么算法类代码必须可以直接运行。否则评委现场跑一个异常，前期的所有讲解都会被怀疑。宁可论文里少写一个功能，也不要写一个实现不了的功能。

最后再分享一点个人感受

岗位推荐这个题目，真正的价值不在“用了 Hadoop”这个标签，而在于它强迫你完整走一遍“数据采集—数据清洗—分布式计算—结果存储—在线服务”的全链路。这个链路将来无论是在数据开发、后端开发还是算法工程岗位的工作里都会反复出现。做项目时树立“链路完整，自圆其说”的意识，远比堆砌技术名词重要得多。如果遇到运行上的问题，一定要学会看日志、查日志、保留日志，这种排查习惯才是这个项目带给你最长期的价值。