基于Django+Spark的南昌房价数据分析系统实战解析

去年帮一位学弟完成《基于Django+Spark的南昌房价数据分析系统》这个毕业设计课题时，我在他身上看到了很多人的影子：Python基础还行，会写爬虫，也看过Django教程，但是要把Django和Spark这两套东西整合成一个完整系统，还要出源码、文档、跑通功能，心里完全没底。这个课题最吸引人的地方在于它不是一个单纯的Web开发题，也不是一个单纯的数据分析题，而是要求你把采集、清洗、计算、存储、展示、预测这一整条链路串起来。说白了，老师想看到的是一个“有数据价值”的系统，而不是一个只会在浏览器里打印“Hello World”的CRUD项目。

这篇文章我就以这个项目为蓝本，把从选题拆解、数据采集、Spark计算、Django展示，到远程调试和毕业论文写作的完整过程写出来。里面所有步骤都是实际操作过的，踩过的坑也会一并交代。给两类人看：一类是正在做类似毕业设计的学生，另一类是想用Django+Spark做点实际数据分析应用的开发者。看完之后你不仅知道代码怎么写，更重要的是知道每一步为什么这样选，遇到问题怎么排查。

1. 为什么要做南昌房价分析：选题背后的需求拆解

1.1 毕业设计选题的真实考量

很多人选课题时有一个误区：“我要选一个新技术，越酷越好”。实际上毕业设计的评分标准不是看技术名词多不多，而是看系统能不能自圆其说、逻辑通不通、工作量足不足。

我给他选“南昌房价数据分析”这个方向，主要有三个判断：

第一，房价数据是天然适合做数据分析的素材。每个房源都有区域、户型、面积、单价、总价、朝向、楼层等结构化字段，能支撑统计分析和建模预测，也方便做图表可视化。用户一看就懂，老师答辩时也容易理解你做的东西有什么价值。

第二，南昌是一个数据规模适中的城市。相比北京上海几十万套房源，南昌的挂牌房源量大概在一两万条左右。这个量级用Spark处理虽然不算“大数据”，但足以体现分布式计算框架的优势——数据加载、聚合统计、特征工程这些操作写起来比Pandas更规范，也更容易在论文中写出技术对比。如果数据量太小，Spark就杀鸡用牛刀了，答辩时会被问“你为什么不直接用Pandas”。

第三，Django负责Web端展示，Spark负责数据处理，两者天然形成一条清晰的技术链路。这让系统架构有了分层，论文里“系统设计”一章好写，图表展示也有了数据来源。

1.2 系统要解决的四个核心问题

在动手写代码前，我们先把需求拆成几个明确的模块，这样后面开发才有方向。这套系统需要解决的问题可以归纳为：

1. 数据从哪里来：南昌各区域的二手房房源数据需要采集，还要保证字段完整、格式统一。
2. 数据怎么处理：抓下来的数据存在缺失值、异常值、重复值，需要清洗并转换成适合分析的格式。
3. 分析什么指标：区域均价排行、价格分布区间、户型成交热度、面积与总价关系、价格趋势变化，这些是用户最关心的维度。
4. 怎么展示结果：用网页呈现图表和预测结果，用户可以选择区域、户型等条件进行筛选，直观看到南昌房价的整体情况。

把这四个问题落到系统功能上，就对应了数据采集模块、数据分析模块、可视化展示模块和价格预测模块。整个系统的开发就是围绕这四个模块展开的。

1.3 技术栈确定的思路：为什么是Django+Spark

确定技术栈时，学弟一开始提的是“用Flask行不行”，我说行，但Django更合适。理由很实际：Django自带ORM、Admin后台、用户认证、模板引擎，这些对于毕业设计来说都是省事的功能。尤其是Admin后台，可以直接用来管理爬取到的房源数据，演示时给老师看后台界面会很加分，这是Flask要额外写很多代码才能做到的。

Spark这边用的是PySpark。选PySpark而不是Java/Scala版，是因为整个项目都是Python写的，维护成本低。PySpark的DataFrame API和Pandas高度相似，熟悉Pandas的人学起来很快。同时Spark提供了MLlib机器学习库，房价预测模型可以直接用线性回归实现，不需要自己写梯度下降。

系统整体架构是这样的：爬虫采集南昌二手房数据，清洗后存为CSV文件；Spark读取CSV，完成数据分析和模型训练，将结果输出为JSON文件；Django读取这些JSON文件，通过接口返回给前端，前端用ECharts渲染图表。整个链路清晰、数据流可追踪，论文里画架构图也好画。

提示：这个架构里Spark不直接和Django通信，而是采用“先算好、再读取”的方式。对毕业设计来说，这样避免了两套服务互相等待的问题，也降低了集成复杂度。

2. 数据从哪里来：南昌房价数据的采集与预处理

2.1 房源数据源的选择与爬虫设计

房价数据的来源，当时考虑了以下几个：贝壳找房、房天下、安居客，还有一些房产中介网站。贝壳的数据质量最高，字段最规范，但反爬比较严格，房源信息是动态加载的，需要分析XHR接口，这对新手来说成本偏高。房天下的数据结构相对简单，静态HTML里就能拿到房源标题、价格、面积、楼层等关键字段，对毕业设计来说足够用。

考虑到学弟爬虫基础一般，我建议他用requests+BeautifulSoup写一个静态页面的爬虫，先保证数据量够用，不追求爬取速度。爬虫的目标是抓取南昌各区域的二手房挂牌信息，每个房源需要记录的字段有：小区名称、所在区域、具体板块、户型（几室几厅）、面积、总价、单价、朝向、装修情况、楼层、建筑年代、挂牌时间。

核心爬虫逻辑大概是这样的：

import time import requests from bs4 import BeautifulSoup headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/120.0.0.0 Safari/537.36" } base_url = "https://nanchang.xxx.com/ershoufang/pg{}/" house_list = [] for page in range(1, 101): url = base_url.format(page) resp = requests.get(url, headers=headers, timeout=15) if resp.status_code != 200: break soup = BeautifulSoup(resp.text, "html.parser") items = soup.select(".houseList li") # 选择器需要根据目标网站结构调整 for item in items: title = item.select_one(".title").get_text(strip=True) info = item.select_one(".address").get_text(" ", strip=True) total_price = item.select_one(".totalPrice").get_text(strip=True) unit_price = item.select_one(".unitPrice").get_text(strip=True) house_list.append({ "title": title, "info": info, "total_price": total_price, "unit_price": unit_price }) time.sleep(2) # 限速，避免被封IP print(f"共采集到 {len(house_list)} 条数据")

写爬虫时有一个经验要分享：结构化的正文数据往往伴随反爬策略，比如页面里故意嵌入一些隐藏字段干扰解析，或者IP访问频率过高直接封禁。解决方案一个是靠限速，另一个是做好异常捕获，单页解析失败不要中断整体流程，记录下来继续下一页。我让学弟在代码里加了一个try-except，出错时把页码写进日志，跑完统一排查，这是爬虫项目中很实用的处理方式。

2.2 清洗规则：字段补齐、异常过滤与统一口径

爬下来的原始数据一般不能直接用。以总价和单价为例，很多网站的单价写的是“12345元/平”，里面有中文单位，需要正则提取数字。再比如面积一栏偶尔出现“暂无数据”或者“别墅350平”这种带有干扰信息的文本。这些都要在清洗阶段统一处理。

我总结了一套清洗规则：

1. 去除重复：根据房源标题、小区、户型、面积组成的唯一标识去重，同一套房源若在多个页面重复出现，只保留一条。
2. 字段标准化：将总价、单价、面积中的文本统一为数值类型，行政区名称统一为规范名称（如“青山湖区”不能出现“青山湖”和“青山湖区”两种写法）。
3. 异常值过滤：单价低于2000元/平（多半是车位或录入错误）和高于50000元/平（多为豪宅或数据异常）直接剔除；面积小于20平或大于300平的也做过滤。
4. 缺失值处理：对于“建筑年代”“装修情况”等非核心字段的缺失，用“未知”填充；对于核心字段（单价、面积）缺失的，整条删除。

这一步看似不起眼，但它直接决定了后面Spark分析结果的质量。我当时给他举了个例子：如果没有做异常值过滤，某些特殊房源单价可能高达10万+/平，直接把区域均价拉高，图表上就会出现一个“尖刺”，答辩时数据一拿出来就被老师质疑。

2.3 数据落地格式：CSV还是数据库

清洗完的数据存成什么格式？这也是一个很容易纠结的点。数据库用MySQL的好处是数据管理规范，Django的ORM可以直接对接，但问题是Spark读取MySQL需要额外装JDBC驱动，配置起来多一步。考虑到毕业设计的数据量只有1~3万条，直接存CSV完全可以满足需求，而且Spark读取CSV非常方便，Django读取JSON结果也很简单，所以最终选择“CSV作为数据存储层”。

这个选择还有个隐藏好处：数据文件可以直接打进源码包交付，评阅老师拿到代码后不需要配置数据库就能跑起来。对于远程调试和部署来说，少一个环节就少一个出错的可能。

3. Spark在项目中真正负责的部分

3.1 评估需求后Spark的使用策略

谈到Spark，很多初学者会陷入一个误区：把Spark当Pandas用，写一堆循环处理数据。实际上Spark的优势主要体现在分布式计算和SQL式声明式操作上。在做这个项目前，我对学弟采用了一个比较务实的策略：Spark不负责爬虫，也不负责做Web页面，它只负责“从CSV读出数据，执行清洗与聚合分析，把结果写回JSON”，以及“用MLlib做房价预测模型”这两件事。

这样的划分让整个系统边界清晰：爬虫只是准备数据，Django只是展示数据，Spark才是分析数据的核心。论文里写“基于Spark的南昌房价数据分析”这个标题才立得住。

3.2 核心分析任务：读取CSV与区域聚合

Spark读取CSV时有一行代码的坑需要特别注意：Spark默认不会把第一行当表头，需要显式指定header=True；同时中文编码需要指定encoding="utf-8"。如果这两个参数不写，后续所有字段都会变成"_c0"这种默认列名，数据内容也会出现乱码。

读入之后，我们就可以用DataFrame API做各种聚合分析。最核心的一个任务就是统计南昌各区域的二手房均价：

from pyspark.sql import SparkSession from pyspark.sql import functions as F spark = SparkSession.builder.appName("nanchang_house_price").getOrCreate() df = spark.read.csv( "data/nanchang_house.csv", header=True, inferSchema=True, encoding="utf-8" ) # 数据清洗 df = df.dropDuplicates(["title", "area", "total_price"]) df = df.filter(df["unit_price"].between(2000, 50000)) df = df.dropna(subset=["region", "unit_price", "area"]) # 区域均价排行 region_price = df.groupBy("region").agg( F.round(F.avg("unit_price"), 2).alias("avg_price"), F.count("*").alias("house_count") ).orderBy(F.desc("avg_price")) region_price.show()

在MapReduce时代，groupBy+avg这样的操作需要自己设计shuffle逻辑，但在Spark里一个DataFrame API就完成了。对比着写论文会让“为什么选Spark”这个论点有支撑。

除了区域均价，我们还用Spark分析了几个不同维度的指标：

• 板块维度：南昌每个行政区下的具体板块均价，用于地图下钻展示。
• 户型维度：统计一室到五室以上各户型房源数量和平均面积，看出供应结构。
• 面积区间分布：把面积分段（60平以下、60-90平、90-120平、120-150平、150平以上），统计每一段的房源数和均价。
• 价格区间分布：按总价区间统计楼盘数量，帮助分析市场需求偏向。

这些聚合逻辑本质上都是“分组+聚合”，只是分组的维度不同、聚合的字段不同。把结果统一写成JSON文件后，Django直接读取，前端用不同的图表类型展示即可。

3.3 基于MLlib的房价预测模型

价格预测是这个项目的加分项。很多同类型毕业设计只做到“统计展示”，能结合机器学习做预测，工作量就有了明显的提升。PySpark的MLlib里提供了LinearRegression，用它来预测房源单价，实际效果可以接受，代码也不复杂。

建模思路如下：以面积、卧室数量、客厅数量、楼层序号、建筑年代作为特征，以单价作为标签。首先用VectorAssembler把特征组装成向量列：

from pyspark.ml.feature import VectorAssembler from pyspark.ml.regression import LinearRegression feature_cols = ["area", "bedrooms", "hall", "floor_index", "building_age"] assembler = VectorAssembler(inputCols=feature_cols, outputCol="features") df_feat = assembler.transform(df) train, test = df_feat.randomSplit([0.8, 0.2], seed=42) lr = LinearRegression(featureCol="features", labelCol="unit_price") model = lr.fit(train) pred = model.transform(test) pred.select("unit_price", "prediction").show()

注意，楼层和建筑年代这种字段最好对缺失值先填充再进模型，不然VectorAssembler会报空值错误。另外，线性回归对单位比较敏感，面积是“平米”单位数值较大，建筑年代是“1990”这种四位年份，数值差异大可能导致收敛慢。实践中我们用标准化器StandardScaler把特征标准化，效果会更好。

预测模型的评估指标我们选择了RMSE（均方根误差）。最终模型在测试集上的表现大概是：每平米的误差在两三千元以内，作为毕业设计已经算是不错的结果。

3.4 开发环境的Spark配置心得

Spark在Windows笔记本上跑起来，最容易让人崩溃的是环境配置。我们第一次在Windows上运行PySpark时，报了一个找不到winutils.exe的错误。这个是Windows平台特有的问题，Spark底层某些文件操作需要模拟Hadoop的Windows环境。

解决办法很简单：下载对应版本的winutils.exe，放到一个目录下，然后设置环境变量HADOOP_HOME指向该目录。另外Java版本也要注意，Spark 3.x要求Java 8或Java 11，如果本机装的是Java 17，会有兼容性问题。我当时让学弟检查了一下，发现他装的是Java 17，换成Java 11之后问题立刻消失了。

4. Django Web端的设计与实现

4.1 项目结构怎么组织

Django项目创建后，默认会生成一个外层配置目录和manage.py入口文件。很多毕业设计的Web端代码就是在这个基础上随便堆几个app，导致代码混乱。因为我们这个系统的展示功能比较集中，我只建了一个核心app，名字叫analysis，负责所有页面渲染和接口返回。

项目结构调整后大致长这样：

house_analysis/ ├── manage.py ├── config/ # 项目配置（settings.py） └── analysis/ # 核心业务app ├── views.py # 页面视图 ├── urls.py # 路由配置 ├── templates/ # HTML模板 ├── static/ # 前端静态资源 └── data/ # Spark输出的JSON结果

这样一个结构在论文里画系统模块图时非常直观。数据文件放在app内部的data目录下，views.py读取时就写相对路径，部署时不会因为路径出错找不到文件。

4.2 路由、视图与模板的配合方式

Django的MVT模式中，一次请求的处理流程是：URL路由到视图函数，视图函数读取数据并渲染模板，或者返回JSON数据。本系统的页面有首页、区域分析页、趋势分析页、预测页等几个主要界面，每个页面对应一个视图函数。

比如说区域分析页的视图函数：

import json from django.shortcuts import render from django.http import JsonResponse from django.conf import settings BASE_DIR = settings.BASE_DIR DATA_PATH = BASE_DIR / "analysis" / "data" def region_page(request): return render(request, "analysis/region.html") def region_api(request): with open(DATA_PATH / "region_price.json", "r", encoding="utf-8") as f: data = json.load(f) return JsonResponse({"status": 0, "data": data})

这里有一个设计思路值得说明：页面路由和接口路由是分开的。region_page只负责返回HTML页面，页面中通过AJAX请求region_api获取数据。这样做的优势是：前端ECharts可以直接用接口的数据更新图表，刷新页面时不需要整页加载，交互体验比模板渲染填充数据好得多，也便于后续扩展新的图表。

4.3 图表可视化方案：选择ECharts而不是Highcharts

图表库的选择上，最终决定了ECharts。原因很简单：ECharts是百度开源的项目，中文文档完善，案例丰富，对地图的支持也很好。南昌的区域分布图可以直接用ECharts的map类型配合GeoJSON数据实现，不需要自己画地图。

前端核心代码大致是这样，用了一个简单的AJAX请求获取接口数据：

$.getJSON("/analysis/region_api/", function (res) { var chart = echarts.init(document.getElementById("regionChart")); chart.setOption({ tooltip: { trigger: "axis" }, xAxis: { data: res.data.map(d => d.region) }, yAxis: { name: "均价（元/平）" }, series: [{ type: "bar", data: res.data.map(d => d.avg_price) }] }); });

地图展示稍微复杂一点，需要提前引入南昌各区划的GeoJSON文件。当时为了省事，我用的是一种简化方案：不是真正的地图，而是用柱状图加区域名字展示，“地图下钻”这种复杂交互在毕业设计里不是必须的，老师更关注的是你有没有分析逻辑。

4.4 前端页面的布局与交互

页面整体风格走“数据看板”路线。顶部是系统标题和导航栏，左侧一个筛选区域，中间主体是图表区域。筛选条件包括行政区和户型，选择后图表刷新。这块逻辑不复杂，就是给图表接口加查询参数，Django视图根据参数读取不同的JSON结果返回。

为了演示效果好，我给学弟加了一个对比功能：选中两个行政区可以同时显示两个区的均价柱状图，这样在答辩时可以说“系统支持多区域对比分析”。这个小功能虽然代码量不大，但体现出来的“分析能力”不一样。

5. 开发过程中踩过的坑和解决办法

5.1 Spark本地运行的三大环境问题

第一个坑就是前面提到的winutils.exe问题。跳过这一步，系统会直接报SparkException。排查这个问题的思路要记住：先看异常栈的Caused by，Spark的报错信息非常长，真正的根因往往在最后几行。

第二个坑是Windows PowerShell下运行PySpark时，控制台输出会出现大量重复日志，这是Info级别日志刷屏。解决办法是在代码开头设置日志级别：

spark.sparkContext.setLogLevel("ERROR")

第三个坑是SparkSession不要到处创建。PySpark在Windows上每次创建SparkSession都要重新初始化JVM环境，耗时几秒到几十秒不等。如果Django的每个请求都创建一次，系统响应会非常慢。我们的处理方式是Spark分析的结果全部落盘成JSON，Web端不直接调Spark，这样Django运行期间完全不需要SparkSession存在。这是最稳妥的方案。

5.2 中文编码与字段类型问题

Spark读取CSV时，如果文件中含有中文且未指定encoding="utf-8"，默认会按UTF-8处理，但一旦文件保存时是UTF-8-BOM格式，第一列字段名就会出现一个前缀\ufeff。这个坑很隐蔽，因为控制台打印数据看起来没太大问题，但调用df.select("区域")时会报找不到列“区域”，实际列名变成了“\ufeff区域”。

排查方式也很经典：打印df.columns，一看到第一列名有特殊前缀就明白了。解决办法是保存CSV时统一用UTF-8无BOM格式，或者在Spark读取时指定encoding="utf-8"并让爬虫保存文件时使用utf-8-sig编码进行兼容。我最终选择了后者，因为某些Windows编辑器保存文件默认会加BOM，统一转成无BOM反而多一步操作。

字段类型的问题主要出在inferSchema上。Spark自动推断类型对基本数字没问题，但像“总价”字段如果原始数据里有“暂无”这样的文本，推断出来的字段类型会变成字符串，后续做数值计算时就会报错。解决办法是在清洗阶段就把这些脏数据剔除，保证进入Spark的数据要么是合法数字、要么是空值，由dropna处理。

5.3 ECharts图表数据格式与接口返回不匹配

前端图表不显示是另一个高频率问题。最常见的原因是ECharts要求的数据格式是数组，而Django JsonResponse返回的是字典套字典的结构。比如我的接口返回的是：

{"status": 0, "data": [{"region": "青山湖区", "avg_price": 13250}]}

而代码里写的是res.data.region_name，应该写res.data.map(d => d.region)。这类问题本质上是对数据结构不熟悉。解决办法是在浏览器开发者工具的Network面板查看接口返回的原始JSON，然后照着实际格式写前端取值逻辑。我在帮学弟调试时，这一幕出现过三四次，最后我让他养成一个习惯：拿到接口先用浏览器直接访问一次，看到JSON格式再写前端代码。

5.4 响应速度优化与缓存策略

系统刚做完时，页面加载有延迟，因为每次打开页面后端都要读取几个JSON文件再做处理。JSON文件每个可能有几百KB，解析也需要时间。优化方案有两个：

第一，把一些不会经常变化的数据接口改成读取Python的pickle序列化文件，或者直接用Django的cache框架缓存到内存中。比如区域均价排行，这种结果是Spark一次算好的，完全可以放在缓存里，第一次访问时读取并缓存，后续请求直接命中缓存。

第二，前端图表数据一次性加载，减少AJAX请求数量。原本区域分析和板块分析是两个接口，后来合并为一个接口返回所有结果，前端根据用户筛选条件切换显示不同的series，交互响应明显快了很多。

对于毕业设计这个数据量来说，其实前端的渲染速度不会有太大瓶颈，真正的瓶颈在于后端读取多个文件、解码JSON以及可能的多次请求。把所有相关数据合并到一个响应里，是最简单有效的优化手段。

6. 远程调试、部署交付与答辩准备

6.1 远程调试的具体操作步骤

这个课题交付时需要提供“远程调试”服务。实际操作中，远程调试的最常用方式就是把项目部署到一台可以远程访问的服务器上，然后老师和学生通过浏览器访问系统页面。我用的方案是买一台云服务器，装好项目和依赖，然后开启runserver监听。

具体步骤：

1. 服务器上安装Python 3.9、MySQL（虽然数据存CSV，但为了Doc文档展示系统能力，还是装一下）、JDK 11。
2. 使用pip安装项目依赖，推荐用requirements.txt统一管理版本。
3. 将源码上传到服务器，进入项目目录运行python manage.py migrate初始化数据库。
4. 运行python manage.py runserver 0.0.0.0:8000，然后在云平台的安全组里放行8000端口。

这样对方就能通过http://服务器IP:8000访问系统了。如果还需要改代码调试，就用VS Code的Remote-SSH插件远程打开服务器上的源码目录。配置方法很直观：安装Remote-SSH插件后，添加新的SSH Host，填入服务器IP、用户名和密码，连接后左下角显示绿色对勾，就能像本地开发一样写代码、运行和打断点。

这里有一个经验：远程调试时一定要先确认服务器上的Python环境和项目依赖一致，否则会出现本地跑得好好的，远程一跑就报ModuleNotFoundError的情况。最好在服务器上创建虚拟环境，激活环境后安装依赖，而不是直接用系统Python。

6.2 两种部署方式与各自适用场景

毕业设计交付时，部署方式一般有测试部署和生产部署两种。测试部署就是上面说的runserver 0.0.0.0:8000，简单直接，适合演示和远程调试。但这种方式的缺陷是DEBUG模式下性能较差，并且runserver是单进程的，如果多人同时访问，页面加载会变得很慢。

更正式的部署是用uWSGI+nginx组合。uWSGI作为Django的应用服务器，nginx作为反向代理处理静态文件并转发动态请求。这个过程稍微复杂一些，但部署完成后，访问体验和稳定性都好很多。如果时间来得及，建议在论文的“系统部署”章节写一下这个方案，显得更专业。

我当时给学弟的建议是：先搞定runserver模式的远程调试，保证核心功能流畅演示，然后再抽时间把nginx+uWSGI部署方案写进文档，但不要因为部署方式折腾太久，毕业设计的核心还是系统功能本身的完整性。

6.3 文档结构与答辩高频问题

源码、文档和演示这三样东西里，文档是最容易出问题的。很多学生把代码写完了，论文最有一周才动笔，结果写出来的文档和系统完全对不上。我建议的论文结构是：

• 摘要与关键词
• 绪论：背景、意义、国内外研究现状
• 相关技术介绍：Django、Spark、数据采集技术、ECharts
• 系统需求分析：功能性需求和非功能性需求
• 系统设计：总体架构、功能模块设计、数据库设计、数据流设计
• 系统实现：每个模块的截图和核心代码讲解
• 系统测试：功能测试与结果分析
• 总结与展望

答辩环节老师问的最多的几个问题，整理后如下：

6.4 交付前的最后检查

远程调试服务交付前，我们按照清单走了一遍检查流程：功能模块是否都能正常访问、图表是否都能渲染、页面切换是否流畅、源码中的路径是否为相对路径、requirements.txt依赖是否完整、文档中的截图是否与当前系统界面一致。这一轮检查很值得做，因为本地环境跑通了不代表交付到别的电脑上还能跑。依赖缺失、路径写死、端口冲突这些问题不亲自动手部署一遍根本发现不了。

另外一个小技巧：源码包里一定要附一个README或者部署说明文档，写清楚Python版本、JDK版本、依赖安装命令、启动方式。这不仅是评分的要求，也是对使用你源码的人负责。很多学生忽略了这一步，结果老师拿到源码不知道怎么跑起来，最终分数大受影响。

7. 最后分享几点关于这个项目的实际体会

整个项目做下来，最让我意外的是Spark+Django这个组合并不难整合，真正的难点在于“数据链路的完整性”。爬虫爬数据、清洗数据、分析建模、Web展示，每一步单独拿出来都不难，但串起来以后，所有的环节都可能是坑：编码错了、数据类型不对、接口格式不匹配、路径找不到。调试过程中80%的时间都花在这些看似琐碎的地方，但解决一个坑学到的东西，往往比照着教程敲一遍代码要多得多。

如果你正在做类似的毕业设计课题，我给一个务实的建议：不要把注意力全放在技术栈炫不炫上，先花时间把数据管道跑通，也就是“数据从采集到图表能显示出来”这个最小闭环。一旦这个闭环跑通了，后面加预测、加筛选、加对比，都是很自然的增量。反之，如果一上来就折腾模型调参、Spark集群配置，很容易陷入环境问题里，项目进展缓慢。数据闭环通了，剩下的都是加分项。