企业官网建设流程全解析

毕业设计选了大数据方向，又锁定“空气质量预测”这个题目，基本就把Hadoop、Spark、Hive、可视化这一整套大数据技术栈全串起来了。我当年做这个项目的时候，最大的感受是：网上关于单个组件（比如Hadoop怎么装、Spark怎么跑）的教程一大堆，但真正把“数据采集→存储→分析→预测→可视化”整条链路串起来讲透的太少。这篇就当成一个过来人给你捋一遍，从选题逻辑、平台搭建、预测算法到可视化大屏，再到答辩现场容易被问倒的坑，一次说清楚。

如果你正在做或者准备做这个题目，或者想拿大数据技术做一个能展示完整度的系统，这篇的核心价值在于：它不是一个Demo，而是一条能跑通全流程、能写进毕业论文、能应付答辩演示的完整方案。适合三类人看：第一类是本科毕业设计选了大数据方向的；第二类是研究生想快速搭一个数据分析系统做验证的；第三类是自学大数据想找实战项目练手的。

1. 毕业设计选题与技术选型思路

1.1 为什么选“空气质量预测”这个切入点

做毕业设计最怕什么？题目看着高大上，但数据搞不到、业务说不清、技术用不上。空气质量预测恰好把这三件事都解决了。

数据方面是真实存在且公开的。国内外有大量空气质量监测站点，历史数据覆盖几十年，字段丰富度很高——PM2.5、PM10、SO2、NO2、O3、CO、AQI指数，再加上气象要素（温度、湿度、气压、风速），无论是做统计分析还是训练预测模型，数据底子都够硬。就算你不想爬实时数据，也有很多开放数据集可以直接下载，这在毕业设计里非常重要——你不需要为“数据从哪里来”发愁，能把精力集中在技术上。

业务层面清晰易懂。空气质量的优劣直接关系每个人的健康，AQI指数、PM2.5浓度是大众都关心的指标。你做出来的可视化大屏不用解释背景知识，评委一眼就能看懂“这个城市的空气今天是什么水平”，这就比那些“基于大数据的某某系统”空泛题目强得多——需求是具体的，价值是直观的。

技术层面延展性极好。这个题目可以浅做，也可以深做。浅做就是统计历史浓度、按城市维度输出报表和图表；深做就是引入机器学习模型预测未来几小时的浓度变化。浅和深都在同一个框架内，你可以根据自己的编程能力和时间灵活控制，这恰好是毕业设计最需要的“可控复杂度”。

1.2 Hadoop、Spark、Hive三件套的组合逻辑

有同学问我，为什么不直接用Python + pandas把数据分析完，再用Flask画几个图表，非得上Hadoop、Spark、Hive这一整套，不就是给自己找麻烦吗？

这个问题如果答辩时被问到，回答不好会被认为“为了用技术而用技术”。我的理解是这样：

第一，这套系统本质上是“大数据”毕业设计，不是“Python脚本”毕业设计。你的题目里要体现大数据框架的应用，要体现海量数据的存储和分布式计算思路。Hadoop负责分布式存储（HDFS）和资源调度（YARN），Hive负责把结构化数据映射成数据仓库表，Spark负责分布式内存计算。三个组件各管一段，职责清晰，这是标准的离线大数据处理流水线，不是生搬硬套。

第二，空气质量的监测数据是典型的时序型数据。单个城市一天也就24条小时记录，看着不大，但如果扩展到全国几百个站点、积累了几年甚至十几年，数据量就会达到几千万条甚至上亿条。这个时候单机关系型数据库虽然也能查，但分布式存储的扩展性和你跑分析时的MapReduce/Spark模式就是另一种思路了——你需要用工具去处理，而不是靠人的耐心去等。

第三，Hive和Spark在功能上是有搭配的。Hive负责离线的数据仓库管理，把乱糟糟的原始日志整理成有一定层级结构的表（ODS层、DWD层、ADS层这种），供后续分析使用。Spark则干两件事：一是用Spark SQL做复杂统计分析，把Hive表里的历史数据聚合出“年平均浓度”“省份排名”“月度趋势”这些结果；二是用Spark MLlib做特征工程和模型训练。它们的角色有点像：Hive是仓库管理员，把货品分门别类摆好；Spark是数据分析师，把摆好的货再加工成报表和预测结果。

这个组合还有一个很现实的理由：写毕业论文时，“异构数据源管理”“数据仓库分层”“分布式内存计算”这些都是现成的章节标题，每个都能展开几千字，工作量很容易做扎实。

1.3 系统功能模块与整体架构划分

我当时把系统分成五个模块：

数据采集模块：负责从公开接口抓取空气质量小时数据，同时生成补全数据（比如网络波动导致的缺测值），最终落盘到HDFS。

数据存储模块：HDFS原始目录 + Hive数据仓库。Hive里按业务需求建原始表、明细表、统计结果表，用日期做分区，防止单表数据膨胀。

数据计算模块：这一层是Spark的主战场。一部分任务是用Spark SQL算历史均值、最大最小值、超标天数、环比变化这类统计指标；另一部分是用Spark MLlib训练预测模型，得到未来24小时PM2.5浓度的预测结果，回写到结果表。

可视化模块：后端提供一个数据查询接口，从Hive/MySQL聚合结果表中取数，前端用ECharts画出实时地图、曲线图、柱状图、仪表盘。

系统管理模块：气象数据管理、站点信息管理、预测任务调度管理。这一块很多同学会忽略，但对毕业设计来说反而是加分项——它说明你有系统思维，不是一个孤零零的面板。

架构图如果画出来，就是经典的分层：数据源层 → 存储层（HDFS/Hive）→ 计算层（Spark）→ 服务层（后端+MySQL）→ 展示层（可视化大屏）。各层之间通过数据流转衔接，第1章的架构设计论文就好写多了。

2. Hadoop平台搭建与数据采集入库

2.1 从零开始搭建Hadoop伪分布式环境

毕业设计用真实集群还是伪分布式？我的建议很直接：没有现成多台服务器，就用伪分布式，千万别硬上。伪分布式是Hadoop官方支持的单机模式，在一台机器上同时跑NameNode、DataNode、ResourceManager、NodeManager这几个进程，可以完整体验HDFS和YARN的所有功能，对你的毕业设计演示完全够用。

搭建步骤我简单捋一遍，核心步骤一个都不能省：

首先要装好JDK（推荐JDK 8，稳定兼容），配置好JAVA_HOME环境变量。Hadoop 3.x版本，下载二进制包，解压到指定目录，然后改四个配置文件：

• hadoop-env.sh里指定JAVA_HOME路径；
• core-site.xml配置NameNode的地址和临时目录；
• hdfs-site.xml配置副本数，伪分布式只能配1；
• yarn-site.xml配置ResourceManager的地址和NodeManager的进程调度方式。

启动前要先格式化NameNode，命令是hdfs namenode -format。这里有个常见的坑：如果你再次执行格式化，会导致NameNode的namespaceID和DataNode不一致，DataNode起不来。网上很多“DataNode启动失败”的问题就是格式化太多次造成的。格式化后先把HDFS和YARN启动起来，用jps命令检查进程是否齐全——NameNode、DataNode、ResourceManager、NodeManager这四个必须都在。

注意一个细节：有的教程会让你额外装Zookeeper。Hadoop的NameNode高可用（HA）才需要Zookeeper，单机伪分布式根本不依赖它。你可以在文档里提一句“当集群规模扩展时，可引入Zookeeper机制保证主节点高可用”，但不要在伪分布式环境里硬加——那只会给自己增加无谓的运维负担。

2.2 空气质量数据获取与预处理

数据来源我推荐两个方向：

第一个是直接用公开数据集。搜索“空气质量历史数据csv”能找到很多整理好的数据包，时间跨度长，字段完整。用这种数据的优势是干净、方便，适合前期开发和测试。第二个是实时接口抓取。很多天气类平台有空气质量数据接口，你写一个Python爬虫周期性抓取，操作上的法律边界我要提醒一句：只抓公开的、非商业性的数据，控制请求频率，只用于个人学习和研究，不要大规模爬取，不要商用。毕业设计场景下，我建议用历史数据集做主体，再用爬虫补充少量实时数据证明“系统具备接入实时源的能力”。

抓下来的原始数据长什么样？大概就是：时间戳、城市名、站点ID、PM2.5、PM10、SO2、NO2、O3、CO、AQI、空气质量等级。

这个数据是不能直接丢进数据仓库的。要做的预处理包括：

• 清洗空值：小时数据里经常有缺失，直接用上一时刻的值填充，或者用前后均值插值。这个逻辑要写清楚，答辩时可能会问“你缺失值怎么处理的”。
• 剔除异常值：PM2.5浓度是-999、粉尘浓度突破10000这类明显不合理的记录，要按阈值过滤。
• 统一字段格式：时间戳统一成标准格格式，城市名统一成标准中文，保证Hive导入时不出现乱码。
• 格式转换：把CSV或者JSON转成Hive能高效读取的文本格式（比如分隔符清晰的标准格式）。

预处理建议用Python的Pandas完成，跑完输出成CSV再上传到HDFS。虽然理论上可以用Spark做ETL，但数据量不大时Python更灵活，别再绕弯子。

2.3 Hive建表与数据仓库分层设计

Hive表分内部表和外部表，这里有一个经验：原始数据用外部表，分析结果用内部表。

为什么要这么分？外部表删除时不会删掉HDFS上的实际数据文件。原始数据是无价资产，一旦误删还有机会恢复；而分析结果表是由程序反复生成的，删了可以重跑，用内部表更省心。

建表要符合数据仓库的分层思想。我建议至少分三层：

ODS层（原始数据层）：保持和源数据一致的结构，相当于原封不动地存一份在HDFS上。这里可以不做清洗，但要做好分区。比如按日期分区，dt=2025-01-01，这样每天的数据独立存放，查询时可以做到分区裁剪，不用全表扫描。

DWD层（明细数据层）：把ODS层的数据清洗后存入。空值补全、异常值剔除、字段规范化都在这个过程中完成。可以加一些衍生字段，比如把AQI等级映射成数字（优=1，良=2，轻度污染=3），方便Spark模型处理。

ADS层（应用数据层）：放统计分析结果，比如每个城市每月的平均PM2.5浓度、超标天数、预测结果等。可视化大屏直接查这一层就行，不用每次都去全量算一遍。

建表语句有一个值得写的点是分区表。比如：

CREATE EXTERNAL TABLE ods_air_quality ( city STRING, station_id STRING, pm25 DOUBLE, pm10 DOUBLE, so2 DOUBLE, no2 DOUBLE, o3 DOUBLE, co DOUBLE, aqi DOUBLE, level STRING ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE LOCATION '/data/air/ods';

注意一个问题：字段值里有中文（比如等级“良”），用TEXTFILE存储时容易出现乱码。解决办法是统一数据源的编码格式为UTF-8，如果是从Windows导出的CSV，要看一下是不是GBK编码，转成UTF-8后再上传。这个坑很常见，我后面专门再讲一次。

把CSV导入Hive也很直接：先上传到HDFS对应分区目录，再用ALTER TABLE ADD PARTITION挂载。或者用LOAD DATA INPATH直接加载。两种都可以，但你要清楚它们做了什么——LOAD相当于把HDFS上文件移动到表目录下。

3. Spark核心：数据分析与空气质量预测实现

3.1 基于Spark SQL的统计分析

数据准备好以后，统计分析是第一步。这一步的价值在于验证数据质量和打通链路：你的Spark能跑起来，能出正确结果，说明前面Hadoop和Hive都没问题。

你需要算的统计指标可以从这几个维度展开：

• 时间维度：每小时的平均AQI、每日的峰值浓度、每月的优良天数占比、每年的空气质量变化趋势。
• 地理维度：各城市的年均PM2.5浓度排名、污染重灾区的季度分布。
• 指标维度：PM2.5/PM10比值分析（判断是扬尘还是二次颗粒物污染）、O3和NO2的协同变化关系。

这些统计用Spark SQL写起来和写MySQL差不多，比如计算城市月均浓度：

val sql = """ SELECT city, substr(dt, 1, 7) AS month, AVG(pm25) AS avg_pm25 FROM dwd_air_quality WHERE dt >= '2023-01-01' GROUP BY city, substr(dt, 1, 7) """

这里有个技术细节值得一提：千万、亿级数据的聚合用Spark SQL和用MySQL最大的区别在于，Spark会先把数据切分到多个Executor上并行算，每个Executor算一部分，然后shuffle合并中间结果。理论上你不需要给数据建索引，因为它是全量扫描，扫描的速度靠分布式并行来保证——这就是“用算力换索引”。

有些同学在这里容易“画蛇添足”：明明几百万条数据单机也能算，非得用Spark。但换个角度想，毕业设计的核心是体现技术栈，如果用Spark跑了几分钟才出一条结果，答辩时反而尴尬。所以建议在数据集里故意多保留一些历史数据（比如十年的全国站点数据），量级到千万条以上，Spark的优势才能真正显现。

3.2 预测模型的选择与Spark MLlib实现

统计只是过去，预测才是这个项目的灵魂。我用的方案是：Spark MLlib里的RandomForestRegressor（随机森林回归），预测未来24小时的PM2.5浓度。

为什么选随机森林而不是LSTM或者ARIMA？主要原因是数据集规模和答辩友好的解释性。

LSTM这类深度学习模型在数据量不够大时容易过拟合，而且训练配置复杂，容易给你自己挖坑；ARIMA适合单序列时间预测，但没法融合气象变量；随机森林的优势是能同时吃进数值型特征，对非线性关系有较好的拟合能力，训练速度快，调参空间清晰，答辩时你能说清楚“决策树是怎么分裂的、重要性是怎么算的”——这个很重要，评委听得懂，你也讲得明白。

特征工程怎么设计？我当时构造了这么几个特征：

• 历史浓度特征：当前时刻前1小时、前3小时、前24小时的PM2.5浓度（用窗口滑动）。
• 气象特征：温度、湿度、风速、风向（如果有气象数据的话）、是否降水。
• 时间特征：小时数（刻画早晚高峰）、月份数（刻画季节差异）、星期几（刻画工作日与周末差异）。
• 空间特征：城市ID、站点所在区域（如果有的话）。

写一个模拟的核心代码片段，帮助理解RandomForestRegressor怎么在Spark里训练：

import org.apache.spark.ml.feature.VectorAssembler import org.apache.spark.ml.regression.RandomForestRegressor import org.apache.spark.ml.evaluation.RegressionEvaluator // 1. 组装特征列 val featureCols = Array("hour", "month", "pm25_lag1", "pm25_lag3", "pm25_lag24", "temperature", "humidity", "wind_speed") val assembler = new VectorAssembler() .setInputCols(featureCols) .setOutputCol("features") val data = assembler.transform(df) // 2. 划分训练集和测试集 val Array(train, test) = data.randomSplit(Array(0.8, 0.2), seed = 42) // 3. 实例化随机森林回归模型 val rf = new RandomForestRegressor() .setLabelCol("pm25_target") .setFeaturesCol("features") .setNumTrees(100) .setMaxDepth(10) .setMaxBins(64) // 4. 训练预测 val model = rf.fit(train) val predictions = model.transform(test) // 5. 用RMSE评估 val evaluator = new RegressionEvaluator() .setLabelCol("pm25_target") .setPredictionCol("prediction") .setMetricName("rmse") val rmse = evaluator.evaluate(predictions)

3.3 模型评估与参数调优的实操笔记

模型跑通不难，难的是效果达标。评估指标我用的是RMSE（均方根误差）和R²（决定系数）。RMSE的意思你可以理解成“平均预测偏差了多少微克/立方米”，一般控制在15以内，肉眼就挺准了。

但预测任务比想象中更容易踩坑，我说几个关键点：

第一，特征滞后值构造要小心。我早期犯过一个错：把“未来24小时”的数据也当成特征去训练，发现测试集效果特别好，后来才意识到是信息泄露——你预测未来时根本没用到未来数据，但训练时未来特征混进来了。特征构造必须严格保证只使用当前时刻及之前的变量。

第二，随机森林的两个重要参数：numTrees（树的数量）和maxDepth（树深度）。树太少会欠拟合，树太多训练耗时变长收益趋缓。maxDepth太深容易过拟合，在噪声大、数据不干净的空气质量数据里表现得尤其明显。一个稳妥的做法是用交叉验证找参数，不过考虑到毕业设计的篇幅，可以固定一组经验值，然后在论文里写“经过网格搜索，最终确定...”，把调参过程写清楚即可。

第三，模型评价要有参照系。光说“RMSE是12”还不够，你要算一个基线，比如“如果我们用昨天的值直接预测今天，误差是多少”。随机森林的RMSE必须比基线低，才有说服力。这也是答辩时比较加分的对比方式。

时间上继续扩，还可以做每个城市分别训练一个模型，而不是一个模型吃全量数据。因为不同城市的污染来源和气象条件差异大，分开训练效果可能更好，这个结论也可以作为论文里的一个实验对比。我当时做了“全局模型 vs 城市独立模型”的对比，效果很有意思——大多数城市独立模型更优。

4. 可视化大屏：从ECharts到大屏落地

4.1 可视化大屏的设计思路与布局

代码写到这里，后端已经把统计结果和预测结果都准备好了，最后一步是让数据“看得见”。

可视化大屏的核心逻辑是：总览优先。一个人站在大屏前，三秒钟之内要知道这个系统在展示什么。所以屏幕布局不是随便拼的，要遵循“中间突出、四周为辅”的原则。

我当时用了这套布局：

• 中间主屏：中国地图，用散点图展示各城市AQI分布，颜色从绿到红渐变，看到红色就知道这个城市当前污染严重。这是整个大屏的视觉焦点。
• 左侧上：全国空气质量总览指标卡（优良天数比例、PM2.5均值、超标城市数等），用大号数字展示，一眼能读出关键数据。
• 左侧下：城市排名条形图，展示污染最重TOP10城市，方便横向对比。
• 右侧上：折线图展示某城市近24小时PM2.5浓度变化趋势，同时叠加预测值曲线，用来展示“预测”功能。
• 右侧下：仪表盘展示当前AQI实时值，配上等级说明文字。
• 底部：滚动时间轴，展示历史上重大污染事件的记录。

布局图没必要画得多精美，但在论文里一定要给一张线框图，标清楚每个模块对应的数据来源和刷新频率，这是评委认可你“有设计能力”的最直接证据。

4.2 核心图表的实现要点

ECharts是我推荐的首选，它文档全、图表花样多、社区案例丰富，和Vue/React/原生JS都能良好配合。我挑几个关键图表说说实现细节。

地图散点图是大屏重头戏。数据格式很简单：每个城市一个对象，包含经纬度和AQI值。用scatter系列加visualMap组件，数值大小决定圆点大小，数值范围决定颜色深浅。有一个容易忽略的细节：地图JSON数据文件需要你自己引入China地图的GeoJSON（新版ECharts不再内置地图数据），要在项目里单独引入。如果地图不显示，十有八九是这里漏了。

折线图用来展示变化趋势。注意预测线和真实值线要用两条颜色区分，预测线用虚线，并且要在图例中注明。要用graphic组件或者markArea把“当前时刻”之后标成预测区域，让读者明白哪些是真实观测、哪些是模型输出。

仪表盘用来展示AQI等级。AQI等级划分有国家标准：0-50优，51-100良，101-150轻度污染，151-200中度污染，201-300重度污染，300以上严重污染。这个阈值可以写死在界面上，也可以从后端接口返回，我建议从后端返回，这样论文里能说“业务规则配置化”。

动态刷新也是大屏体验很重要的一个点。定时器配合AJAX请求，每30秒拉一次最新数据。但要注意：大屏上很多指标是小时级的，没必要每秒钟刷新，否则后端接口压力大增，页面也会闪烁。合理做法是一分钟一次，同时更新节奏错开，不要让所有请求同时打过去。

4.3 后端数据接口与多表数据串联

有时候你辛辛苦苦把统计分析结果放在Hive表里，但如果每次都让前端直接查Hive，性能扛不住（Hive查询延迟秒级起步）。更常见的做法是：每天跑批任务用Spark把需要展示的数据聚合结果写入MySQL，后端提供REST接口从MySQL查数据。

这个方案的好处在于：MySQL的查询响应是毫秒级，能支撑大屏的实时刷新；批计算和在线查询分开，架构清晰。

后端接口设计可以按功能拆：

• /api/overview：返回全国总体指标。
• /api/city/map：返回城市AQI分布列表。
• /api/trend?city=beijing&hours=24：返回指定城市的历史与预测曲线。
• /api/rank：返回污染城市排名。

还需要考虑一个问题：当预测模型跑完，结果需要写到MySQL里。这里可以用Sqoop也可以直接写JDBC，但Spark里最方便的方式就是Dataset的write方法配合JDBC驱动。给你一个参考：

predictions.select("city", "dt", "hour", "pm25_actual", "pm25_predict") .write .mode("overwrite") .jdbc(mysqlUrl, "t_predict_result", props)

一个批次把一天的结果写完，覆盖写入即可。前端界面简单用Spring Boot或者Flask写都行，自己熟悉哪个用哪个。前后端联调时注意看下返回的JSON字段和图表需要的字段名是否一致，这种小事浪费过不少调试时间。

5. 踩坑实录与排查经验总结

5.1 Hadoop与Spark环境常见故障

这一部分值得每个做大数据毕设的人收藏。我按概率排序，把最常遇到的坑讲一遍。

NameNode启动失败：jps查不到NameNode，日志里报Incompatible clusterID。原因基本是你反复执行了hdfs namenode -format，导致NameNode和DataNode的集群ID不一致。解决方法是：停掉所有服务，清除HDFS的临时目录（/tmp/hadoop-*），重新格式化再启动。生产环境千万别这么干（数据会丢），但本地开发数据无所谓。

Spark任务内存溢出：报错典型的是java.lang.OutOfMemoryError: Java heap space或者Container killed by YARN for exceeding memory limits。前者通常是Executor内存设置过小，后者是给Executor的内存加上overhead超出了Container的最大限制。关键是配置时预留好spark.executor.memoryOverhead。建议本地跑的时候用--conf spark.executor.memory=2g --conf spark.executor.memoryOverhead=512m起步。

资源调度不动：YARN的调度器配置不当可能让你提交的任务排队等到天荒地老。伪分布式只有一个节点，务必把yarn.nodemanager.resource.memory-mb配大一点，至少留出4GB以上，否则Spark Executor启动直接被干掉。

Hive表中文乱码：行业标准的解决办法是修改Hive的元数据库连接参数：characterEncoding=UTF-8，并在建表时用ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' COLLECTION ITEMS TERMINATED BY '\002' MAP KEYS TERMINATED BY '\003'这类方式统一分隔符。但更简单的方式是确保写入文件编码为UTF-8，而且Hive表结构里注释最好不要用中文，你在文档里可以用英文注解，省去元数据库配置的麻烦。

5.2 Hive小文件问题与治理方案

跑了一天任务，Hive表目录下生成了一堆几个KB的小文件，这是大数据开发里特典型的问题。小文件太多会让下一次读数据的任务数量爆炸，元数据压力也增大。

产生小文件的原因很多：Spark写数据时动态分区过多、每次写少量数据、Reduce数量设太大，都会造成这个问题。治理手段看两个场景：

• 如果你用Hive做批处理，可以在写入后执行ALTER TABLE ... CONCATENATE合并小文件；
• 如果你用Spark写Hive表，可以设置spark.sql.shuffle.partitions不要太大，一般和数据量匹配即可，同时开启coalesce或repartition控制输出的文件数。

有一种更简单的套路：用INSERT OVERWRITE方式让Hive重写表的目标分区，这个操作本身就会把表内已存在的小文件和大文件合并成相对统一的块大小。就是把重复数据重写一遍，但结果文件整齐很多。

答辩时你如果主动讲一句“我用过动态分区小文件合并，优化过文件数”，绝对能拉开和其他同学的差距。

5.3 答辩经验与论文写作建议

最后聊点软的：毕设写完了怎么展示，怎么应对评委。

演示要提前排练。大屏系统最怕的几件事：浏览器缓存了旧数据、接口没启动、数据库没连上。我建议答辩前准备一个“演示用例清单”：每个按钮点下去，预期看到什么结果，逐一核对。特别是地图加载可能因为GeoJSON文件路径问题或者浏览器缓存导致空白，答辩现场翻车极为尴尬。

预测效果对答辩的影响很大。如果现场随机预测某一天的数据，结果偏差很大，宁可别展示这项，而是多说思路和实现；如果模型效果稳定，一定要现场跑一遍预测再给出结果。这个项目里最能讲深浅的就是模型部分，你把特征工程、数据集划分、评价标准讲明白，这一个问题就值很多分了。

论文写作上，重点突出“为什么”。很多同学的论文把大篇幅花在“怎么装Hadoop”上，这是评分不高的原因。评委想看的是：你对这个系统的设计思路是什么？为什么选这个方案？数据量上来以后瓶颈在哪里？把这几个问题写清楚，论文深度自然就有了。安装教程写进附录就够了。

关于原始文档的三件套：LW文档（即论文正文）务必要跟系统实现对应上，图要真实可信，代码片断简洁，别大段贴没有注释的源码；PPT控制在15页以内，每页聚焦一个功能点；讲解视频注意突出实操演示，别花太多时间讲理论。这套组合拳打下来，拿个优秀不是什么难事。

写在最后的一个私货建议

如果你时间充裕，在完成了这套离线架构之后还有余力，我强烈建议你尝试增加一个Spark Streaming的实时预测小模块——哪怕就是用模拟数据以5秒间隔推给你，实时计算出当前时刻的污染等级并推送到大屏。这个扩展能让你的系统从“T+1离线分析”升级为“具备实时处理能力”，这个点在毕设答辩的含金量上完全是质的飞跃，而且它不需要改动现有架构，新增一层即可。我当年就是靠着“离线分析+实时预警”双链路的设计，在评委提问环节拿到了非常高的评价。做一个真正能跑通全流程、能把每个环节讲清楚的大数据系统，远比堆砌一堆你并不熟悉的高深名词更有价值。