去年帮学弟看毕业设计，大数他选了个“基于大数据的据技计电商用户画像系统”。打开他的术毕开题报告，Hadoop、业设Spark、大数Hive、据技计Flink列了一长串，术毕我问他：“你数据从哪来？业设”他愣了一下，说：“网上找个数据集跑跑就行。大数”

这就是据技计多数大数据毕设的真实起点——技术栈堆得比天高，数据源却薄得像张纸。术毕导师看一眼架构图，业设觉得挺唬人，大数代码跑通了，据技计答辩也能糊弄过去。术毕可这东西跟“大数据”三个字的关系，大概只存在于PPT标题里。

数据不是越大越好，是越真越好

我见过一个做得挺有意思的毕设。那哥们爬了某二手交易平台三个月的手机品类数据，总共也就二十来万条。体量不大，但他把每条商品描述里的成色关键词、卖家信用、发布时间、砍价记录全拆出来，做了一套价格预测模型。答辩时老师问他为什么不用Spark，他说：“Pandas够用了，我这数据量上集群是浪费。”

这话说得实在。大数据技术的核心从来不是“大”，是“从乱糟糟的数据里捞出能用的东西”。你用一个公开的、已经被清洗得干干净净的CSV文件，跑个WordCount，那叫编程练习，不叫毕业设计。

技术选型要能自圆其说

另一个常见毛病是技术栈拼盘。Kafka接Flume，Flume灌HDFS，HDFS喂Hive，Hive出结果给ECharts。问为什么用Kafka，答“实时”。问数据延迟多少，答“批处理跑的”。这就不太说得过去。

我的建议是：选一条线，扎透。比如你要做实时日志分析，那就老老实实模拟一条日志流，Kafka的生产者消费者代码自己写，Flink的窗口函数调明白，最后结果写进MySQL供前端查询。中间每个环节的数据形态、延迟、容错，你都能说出个一二三。比堆五个组件但每个都只调过API强得多。

可视化不是画几张图就完事

很多毕设的可视化部分，就是拿ECharts默认模板改改数据。柱状图、饼图、折线图各来一张，完事。但可视化真正要回答的是：你的分析结果，让人一眼看出什么门道？

举个例子。有个做校园卡消费分析的，他没画那些常规的消费总额趋势图，而是做了个“贫困生识别”的散点图——横轴是月消费次数，纵轴是单次平均金额。低消费次数加低单次金额的点，集中在左下角。再叠加一个时间维度，看哪些学生连续三个月都在这个区域。这比单纯算个平均数有说服力得多。后来他真拿这个去找了辅导员，虽然数据是脱敏的，但思路得到了认可。

写代码的时间其实不多

整个毕设周期里，写核心代码的时间可能只占三成。剩下的时间花在哪？找数据、洗数据、调环境、写文档。尤其是洗数据，你从网上爬下来的东西，缺失值、异常值、格式不统一，能把人逼疯。但这个过程恰恰最能体现你的工程能力。答辩时老师问“你遇到最大的困难是什么”，你说“配环境配了两天”，那基本就凉了。你说“商品描述里的成色字段有十七种写法，我写了个规则引擎做归一化”，老师眼睛会亮一下。

别把“大数据”当遮羞布

说到底，本科毕设不指望你做出工业级系统。但至少，你得让看的人感觉到：你确实碰过真实的数据，踩过真实的坑，想过真实的解决办法。数据量小没关系，技术栈简单也没关系。怕的是从头到尾都在演示一个精心包装的玩具，自己都知道它经不起追问。

选题之前先问自己一句：这东西我做完，敢不敢让一个懂行的人随便挑个细节问？如果心里发虚，那就换个方向，或者把现有的东西再往下挖一层。挖到你能理直气壮地说“这块我试过，当时是这么想的”——那这个毕设就成了。