Python全流程租房数据智能分析平台：爬虫、K-means与Django实战

租房市场的核心矛盾，是信息极度分散且真假混杂。同一个城市，不同平台上同一套房的报价能差出 15%，同小区不同户型的租金构成逻辑也完全不一样。我做这个“Python 全流程租房数据智能分析平台”的初衷，就是想用一套自动化链路把“采集—清洗—存储—分析—展示”全部打通，让房源数据不再是死数字，而是能回答“这个区域合理租金是多少”“哪些片区被高估了”这些实际问题的依据。如果你正在准备计算机毕业设计，又恰好对爬虫、数据分析和 Web 开发都有兴趣，这个选题非常值得参考。它不是单点技术展示，而是一条完整的数据流水线，既有工程深度，也有算法落地，论文能写的东西多，答辩时也站得住。

1. 先把问题说清楚：这个平台到底在解决什么

1.1 房源数据的现状与核心痛点

做这个平台之前，我先去观察了几个主流房产信息平台的页面结构。租房和二手房数据有几个天然特点：更新频率快、字段杂、噪声大、平台之间口径不统一。比如租金，有的是“元/月”，有的是“元/平米/月”；面积有的是“建筑面积”有的是“使用面积”；楼层字段里混着“低/中/高楼层”和“共XX层”的复合信息，真要拿来建模，根本没法直接用。

另一个痛点是数据获取的连续性。房价分析最怕的是“一次性快照”，今天抓的数据和上个月的完全没法比。平台必须有增量更新的能力，这直接决定了后续 K-means 聚类和线性回归的可靠程度。很多毕业设计做到最后才发现，数据是别人给的 CSV，算法跑完也不知道数据怎么来的，整个项目的完整度就大打折扣。

1.2 平台功能边界：从采集到展示的四个环节

我最终把平台划分成四个环节。第一是数据采集层，用 Scrapy 抓取租房和二手房的列表页、详情页信息；第二是数据处理层，负责字段清洗、口径统一、特征工程；第三是分析建模层，用 K-means 对房源进行聚类分群，用线性回归预测租金或总价；第四是可视化展示层，基于 Django 搭建 Web 系统，把结果图表化呈现给用户。

整个流程是一条完整的“数据管道”。爬虫是入口，分析是核心，页面是出口。每个环节都独立成模块，但又被 Django 项目统一管理，这样的架构读起来特别清晰，也方便在论文里画系统架构图。

1.3 为什么适合做毕业设计选题

从毕业设计的评分角度，这个题目覆盖面广，难度梯度合理。Scrapy 能体现工程能力和反爬策略设计，K-means 和线性回归覆盖了机器学习的基本算法，Django 展示了 Web 全栈能力，最后还有可视化成果能拿出来演示。更关键的是，它不需要额外的实验设备或昂贵的算力，一台普通电脑就能跑通全流程。这套组合在“计算机科学与技术”“大数据”“软件工程”等方向都非常适用。

2. 技术选型的底层逻辑：Django、Scrapy 与算法为什么这么配

2.1 为什么是 Django 而非 Flask

很多同学会在 Django 和 Flask 之间纠结。我自己的结论是：做一个带后台管理、用户系统、数据模型和多页面展示的完整平台，Django 的开发效率明显更高。它自带 ORM、Admin 后台、表单校验和模板系统，不需要自己拼装组件。尤其是 Admin 后台，可以直接用来管理爬到的房源数据，省掉一整套后台开发工作。

有人担心 Django“重”，但在这个项目里“重”反而是优点。模型层可以同时定义房源、区域、聚类结果、预测结果等多张表，ORM 迁移机制能让你在开发过程中不断调整字段而不必手写 SQL。配合 Django 的中间件和 URL 路由，爬虫的管理命令、数据统计接口、图表页面全都能挂在一个项目下，整个系统非常紧凑。

2.2 Scrapy 在采集环节的优势

Scrapy 相较于 Request + BeautifulSoup 的组合，最大的优势在于异步调度和中间件机制。它能并发发起请求，控制 crawl 深度，自动处理重试和异常。写租房爬虫时最常遇到的翻页、详情页跳转、去重问题，Scrapy 都提供了现成的组件。比如内置的去重过滤器会基于 URL 生成指纹，避免重复爬取；Downloader Middleware 可以挂代理、轮换 User-Agent、控制下载延迟，反爬应对方案都可以集中在中间件里维护。

2.3 K-means 和线性回归各自回答什么问题

K-means 在这里做的是“无监督分群”。把房源按“位置、面积、价格、户型”等特征分成若干簇，每簇代表一种典型房源类型——比如“核心区小面积高租金”“远郊大面积低单价”。这种分群结果用于地图上的色块渲染非常直观。线性回归则负责“有监督预测”，用面积、户型、楼层、所在区域等特征预测租金，得到一个可解释的定价公式。

选这两个算法组合是有讲究的。K-means 帮你看懂数据结构，线性回归帮你验证特征与价格的关系。两者都不属于玄学深度学习，结果透明可解释，答辩时你能清楚地告诉评委每个参数的含义，这是选算法的核心理由。

3. 数据采集实战：Scrapy 爬虫的结构设计与反爬经验

3.1 爬虫项目的目录结构与核心组件

我用的是 Scrapy 的标准项目结构，一个独立的 scrapy 应用放在 Django 项目根目录下。

spider_project/ ├── scrapy.cfg └── spider_project/ ├── items.py ├── middlewares.py ├── pipelines.py ├── settings.py └── spiders/ ├── zufang_spider.py └── ershoufang_spider.py

items.py 里定义房源字段，如 title、district、biz_circle、price、area、floor、layout、toward、decoration、publish_time、source_url，字段类型用 scrapy.Field() 声明。pipelines.py 里做数据校验和入库，重点是两点：把字符串价格转成数值，把面积里的“㎡”去掉；以及用 source_url 做唯一性校验，防止重复写入。

3.2 列表页与详情页的解析策略

列表页解析的重点是提取每个房源的详情链接。以常见的搜索列表页为例，每个房源卡片下有一个 a 标签，它的 href 指向详情页。用 Scrapy 的 Selector 很容易提取：

def parse(self, response): links = response.css('a.title[href*="/zufang/"]::attr(href)').getall() for link in links: yield scrapy.Request( url=response.urljoin(link), callback=self.parse_detail ) next_page = response.css('a.next::attr(href)').get() if next_page: yield response.follow(next_page, self.parse)

这里要注意 response.follow 和 urljoin 的区别。response.follow 会自动处理相对路径和 query 参数，比手动拼接保险得多。我实际踩过坑：直接用 response.urljoin 拼接 next_page 时，如果 URL 里已经带了页码参数，拼接出来会重复。换 response.follow 后问题就消失了。

3.3 反爬机制与应对策略

租房平台的反爬通常有三层：基础校验（User-Agent、Referer）、频率控制（IP 限流、验证码）、数据加密（部分字段是动态加载的）。我的处理策略是按照安全与合规的原则，只做合理频率的公开信息采集，不绕行任何加密或验证机制。

在实际工程配置上，最有效的一套做法是：随机 UA 池加下载延迟。给每类请求配置 2 到 3 秒的随机延迟，并把并发量调低，既能稳定抓取数据，也不给目标服务器造成压力。Cookie 只在登录场景下才需要，针对公开列表页，不携带任何自定义 Cookie 反而更像正常访问。

3.4 去重、断点续爬与调度策略

Scrapy 的去重是基于 Request 指纹的，默认对同一 URL 只发一次请求。但如果详情页 URL 有跟踪参数（比如 ?utm_source=xxx），同一个房源会生成两条不同 URL，这就要在 pipeline 里再用 source_url 去一次重。我用的方法是对 URL 做规范化处理，去掉所有 query 参数之后再作为唯一标识。

断点续爬主要依赖持久化队列，Scrapy 的 JOBDIR 参数可以在指定目录保留爬取状态：

scrapy crawl zufang_spider -s JOBDIR=crawls/zufang

这样哪怕是爬了一半程序崩了，重启后也会从断点继续，而不是从头再来。对需要多天增量更新的毕业设计项目来说，这一条非常实用。

4. 数据清洗与特征工程：分析能不能出结果，一半看这里

4.1 真实房源数据比想象中脏得多

我把第一次抓到的 8000 条数据做了个初步统计，问题多到出乎意料。价格字段里混着“面议”、面积写“暂无数据”、楼层字段有“低楼层/共6层”，还有不少房源缺少朝向或装修信息。如果直接拿去建模，K-means 聚类结果一定会被异常值带偏。

真实项目的推进逻辑是：先明确哪些字段是分析必需的，再针对每个字段制定清洗规则。对于价格，必须转成 float，并剔除明显不合理的记录，比如月租金低于 200 元或面积小于 8 平米的；对于面积，只保留数值部分，单位统一成平米。

4.2 统一口径：价格、面积、楼层等字段的处理

最需要统一口径的是租金和单价。很多房源页面会同时展示“月租”和“每平米租金”，但这两个字段并非总是同时存在。我的做法是保存一份原始字段，同时计算一份派生字段：若原页面有“元/平米/月”，直接保留；若只有月租，则用月租除以面积得到单价。二手房则是“总价/面积=单价”。这样后续做区域对比时，把所有房源放在同一坐标系下。

楼层字段我拆成一栋楼的总楼层和房源相对楼层两个特征。比如“低楼层/共6层”，会被解析成 floor_level=1（低）、total_floors=6。这个拆分非常有用，因为“低楼层”在不同总楼层下的价值完全不同，6 层的低楼层和 30 层的低楼层没有可比性。

4.3 构造衍生特征：区域、环线、楼龄等

仅仅靠原始字段做线性回归，效果往往一般。我添加了几个衍生特征：

• per_price：每平米单价（元/平米）或月租金单价。
• district_index：对行政区或商圈进行编码，让模型能感知地理位置的影响。
• floor_ratio：房源所在楼层与总楼层的比值，量化采光与噪音影响。
• age_group：如果页面有建筑年代，则转换为楼龄分组。
• has_metro：用关键词匹配过滤距离地铁一公里内的描述，生成布尔特征。

这些特征显著提升了线性回归的 R²，在论文里也可以作为一个分析亮点：特征工程对模型效果的提升幅度。

5. 存储设计：数据量变大之后，数据库怎么撑住

5.1 表结构设计要点

这个平台表结构我设计了以下核心表：

house_info 的 source_url 字段加唯一索引，保证数据不重复；district 和 biz_circle 联合加普通索引，因为后续统计和可视化会频繁按区域查询。

5.2 ORM 与批量写入的取舍

用 Django ORM 的好处是开发方便，但批量写入时要注意效率。逐条 save() 在大数据量下慢到无法接受，一定改成 bulk_create。我测试过，8000 条数据用 bulk_create 一次写入不到 2 秒，逐条 save 则要将近 1 分钟。爬虫 pipeline 里通常每攒满 200 条做一次批量提交，同时在内存中用 source_url 集合做去重。

5.3 查询优化与统计聚合

平台首页展示“各区域平均租金”的柱状图，如果用 ORM 对全表循环统计，数据量到 3 万条以上时页面会明显卡顿。我的应对方案是：在爬虫入库或每日更新后，预先计算 area_stats 表，页面直接查统计表。这样大数据量的实时聚合变成了预计算结果，查询时间从秒级降到毫秒级。

此外，给 house_info 的 price 和 area 建了联合索引，用于筛选异常值；给 publish_time 建索引，用于按时间增量更新数据。数据库这块的核心思想很简单：尽量把计算逻辑前置，页面只负责读。

6. 分析与建模：K-means 如何分区，线性回归如何定价

6.1 建模前的数据准备与标准化

建模之前要先把数据从数据库加载成 DataFrame。只保留已经过清洗的字段，剔除缺失关键特征的记录。这里有个细节：K-means 对特征的尺度非常敏感，面积和总价数值级别相差巨大，必须做标准化。我用 StandardScaler 对特征做 z-score 归一化，这样每个维度都是均值 0 方差 1，距离计算才能合理。

6.2 K-means 聚类：K 值怎么定，聚类结果怎么解读

确定 K 值的标准方法是用肘部法则加轮廓系数双重验证。我按 K 从 2 到 10 分别计算簇内误差平方和（SSE），并观察拐点。租房数据一般 K 在 4 或 5 时效果最好。

聚类代码核心逻辑如下：

from sklearn.cluster import KMeans from sklearn.preprocessing import StandardScaler features = ['area', 'unit_price', 'total_floors', 'floor_ratio', 'district_index'] X = df[features] X_scaled = StandardScaler().fit_transform(X) kmeans = KMeans(n_clusters=5, random_state=42, n_init=10) df['cluster_label'] = kmeans.fit_predict(X_scaled)

聚类结果建议做两个层面的解读。第一层是看每个簇的质心，比如某个簇的特征是“面积 80 平米、单价 1.3 万元/平米、总楼层 18”，就可以把它定义为“次新高层改善房”。第二层是结合行政区字段，统计每个簇在不同区域的分布比例。我最后生成了一张“簇-区域交叉表”，它能直接说明某片区的房源结构偏向刚需还是改善。

6.3 线性回归模型：特征选择、评估与结果解释

线性回归预测租金时，特征选择非常关键。我最初把朝向、装修这类文本特征直接做 One-Hot，结果模型参数过多，R² 反而下降。后来只保留面积、楼层比值、区域编码、楼龄、是否近地铁这五个数值特征，模型简洁且更稳定。

建模与评估的代码如下：

from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.metrics import r2_score, mean_absolute_error X = df[['area', 'floor_ratio', 'district_index', 'age', 'has_metro']] y = df['unit_price'] X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=42 ) model = LinearRegression() model.fit(X_train, y_train) y_pred = model.predict(X_test) print('R2:', r2_score(y_test, y_pred)) print('MAE:', mean_absolute_error(y_test, y_pred))

我实测的 R2 在 0.62 到 0.72 之间，这个成绩对于真实房源价格预测已经算不错。因为房价本身受很多文本难以量化的因素影响，追求 0.9 以上反而不现实。答辩时与其被质疑准确率不高，不如主动解释：线性回归的价值在于可解释的变量系数，而不是纯预测精度。

6.4 建模过程中的典型坑

整个建模过程里我遇到三个坑，值得单独说。

第一个坑是异常值干扰。清洗后仍有一批“豪宅”房源，面积 300 平米、总价上亿，把线性回归的系数学偏了。解决办法是先用分位数裁剪，去掉单价超过 99 分位数的记录。

第二个坑是多重共线性。面积和总价高度相关，如果同时进入回归模型，系数会出现正负翻转的奇怪现象。所以我做租金预测时用“单价”作为目标变量，面积作为特征，而不是直接预测总价；做二手房总价预测时则去掉单价特征。

第三个坑是 K-means 聚类结果不稳定。初始点选择不同会导致簇标签变化。解决办法是固定 random_state，同时设置 n_init=10，让算法从多个初始点中选最优结果。论文里写聚类时记得说明这个稳定化处理。

7. Web 可视化与系统集成：数据最后如何呈现

7.1 可视化方案选型对比

可视化方案我比较过三种：直接用 ECharts 手写 JS、用 Pyecharts、用 Plotly。最终选了 Pyecharts，原因是它基于 Python 生成配置，能直接在 Django 视图里返回图表渲染结果，不需要单独维护前端代码。如果是团队协作或需要高度定制交互，可能会选 ECharts，但单人毕业设计用 Pyecharts 效率最高。

7.2 Django 如何承载分析结果与图表

Django 侧的核心是用视图函数读取数据库中的统计结果，再传给模板。Pyecharts 在这个场景有个经典用法：在视图函数里生成 chart 对象，然后利用它的 render_embed() 方法输出 HTML 片段，直接嵌进模板。

比如全局租金热力图的视图逻辑：

from pyecharts.charts import Bar, Map, Scatter from pyecharts import options as opts from django.shortcuts import render from .models import AreaStats def area_chart(request): records = AreaStats.objects.filter(stat_date=latest_date)\ .order_by('-avg_price')[:15] areas = [r.biz_circle for r in records] prices = [r.avg_price for r in records] bar = ( Bar() .add_xaxis(areas) .add_yaxis('平均租金(元/月)', prices) .set_global_opts(title_opts=opts.TitleOpts( title='热门区域平均租金排名')) ) html = bar.render_embed() return render(request, 'analysis/dashboard.html', {'chart_html': html})

核心思路是：模型训练和聚类计算不放在 Web 请求里做，而是通过 Django 的 management command 定时执行，结果写入数据库，页面只负责查表和渲染。这样平台响应速度不会因为算法计算而卡顿。

7.3 页面布局与核心图表设计

平台页面我设计成三个功能区。首页是总览面板，包含房源总量、平均租金、最高单价等指标，以及区域均价柱状图。第二个是聚类分析页，展示散点图和区域交叉表，用户可以观察不同聚类簇的房源特征。第三个是价格预测页，提供一个表单，输入面积、区域、楼层等信息，后端调用训练好的模型返回预测价格。

散点图是整站最有信息量的一张图。横轴是面积，纵轴是单价，点颜色是聚类标签，这样每一个点都能看出来属于哪个簇。它会非常直观地展现“高单价小面积”和“低单价大面积”两个极端簇的分界。

8. 写在最后：答辩准备与后续扩展的几个建议

8.1 答辩时常被问到的问题

做这个项目的过程中，我预演过不少答辩场景，有四个问题几乎必被问。第一问是“数据量到底有多大，算不算大数据”。这是个软肋，如果只有几千条数据，一定要诚实回答：当前是轻量级实现，但平台设计上预留了分布式爬虫和数据分表的能力，3 万到 10 万条记录可以平稳支撑；真正的大数据需要引入消息队列和 Spark 等组件，那是框架层面的事，不是核心创新点。

第二问是“你的聚类结果怎么验证”。这个问题不能只答“画图看”，要说用了轮廓系数评估簇内紧密度，并对比了不同 K 值的 SSE 拐点，选最好的参数组合。第三问是“线性回归为什么不预测总价而是单价”，这正好是多 重共线性问题的展示机会。第四问是“有没有想过用更好的模型”，这个问题回答的关键是：项目定位是可解释的智能分析，而不是精度竞赛；如果换成随机森林或 XGBoost 精度确实更高，但黑箱特性不利于房产定价场景的解释。

8.2 这个项目还能怎么扩展

如果时间充裕，有几个扩展方向性价比很高。第一是给爬虫加增量更新计划，用 Django 的管理命令加定时任务，每天抓取新发布的房源，让平台变成持续更新的数据服务。第二是引入地理编码，把文字地址转成经纬度，然后用地图热力图做租金分布可视化，效果会直接提升一个档次。第三是把线性回归换成带训练过程的模型文件持久化，训练脚本单独放，页面只加载模型，为后面的模型迭代留出空间。

作为一个过来人，我最后的建议是：毕业设计不要求技术上“大而全”，但一定要“通”。爬、存、析、显四个环节只要有一条线从头到尾能顺畅跑起来，就已经超过了绝大多数只停留在 Demo 层面的项目。数据流动起来后，你会看到很多单独看数据时看不到的结论，那种感觉才是做这个平台最有价值的回报。