做毕业设计那阵子我最怕的就是选题太“水”。后来我把目标锁定在“Python租房数据智能分析平台”上——这个名字一听就包含了好几层硬核技术Python、Django框架、Requests爬虫、数据可视化、大数据分析整套做完论文有得写演示有得看答辩也有得聊。这篇内容不吹不黑把我从数据采集、数据库设计、可视化大屏到大模型接线的完整路径拆开讲源码结构也梳理给你正在做毕设或者想练手数据分析全流程的朋友可以直接照着抄思路。1. 选题与架构设计租房数据平台为什么值得做1.1 数据源公开且字段丰富毕设最怕“没数据”我见过太多选题死在“没数据”上。做企业级项目需要商业数据做算法类需要大规模标注集而租房数据恰恰是互联网上最容易获取、结构相对规整、分析维度极其丰富的公开数据。一个房源详情里就绑定了户型、朝向、楼层、面积、价格、位置、区域、商圈、地铁距离、挂牌时间、小区名等二十几个字段天然就是一份干净的教学级数据集。更关键的是租房数据有真实的时间维度和空间维度。我一共抓了大约两万多条样本放在MySQL里也就几十MB完全不挑机器普通笔记本就能跑。可你要是把它改成“全国二手房交易分析”或者“股票数据分析”数据源合规性和采集难度都会上一个台阶毕设周期根本兜不住。所以我给身边人的建议一直是一句话毕设选题先问自己三个问题——数据能不能合法拿到技术栈覆盖面够不够广演示效果能不能一眼看懂租房数据平台三条全中。1.2 技术栈选型的取舍逻辑Django Requests ECharts这题的核心不是“哪个框架最强”而是“哪个组合最合适”。我最终定下来的是Django框架 Requests库 ECharts可视化外加后期接一个大模型API做智能分析理由很实在Django提供完整的ORM、Admin后台和模板引擎。我不需要额外写前端框架Django的template里直接嵌HTML和ECharts就能把页面撑起来省去前后端分离的部署复杂度。Requests是Python最经典的HTTP客户端库。相比ScrapyRequests的代码更直观每一行都在明明白白告诉评委“我发出了一个HTTP请求、拿到了返回内容、解析了什么字段”。毕设答辩时老师问“你的爬虫原理是什么”你可以很从容地把HTTP请求过程从头讲到尾。ECharts的图表种类丰富柱状图、折线图、饼图、散点图、地图都有现成模板。最重要的是它在浏览器端渲染对服务器压力小做动态交互也方便。选型阶段我没用前后端分离Vue DRF Nginx那套主要原因有两个一是毕设周期有限二是技术栈越多联调阶段出Bug的概率越大。先跑通“爬虫→入库→查询→渲染”这条最短链路再考虑要不要扩展成前后端分离架构这才是稳妥节奏。1.3 整体业务链路从爬虫到大模型的四层结构平台整体上分四层我画在论文架构图里就是典型的“数据采集层 → 数据存储层 → 业务分析层 → 展示交互层”。数据采集层用Requests抓取租房平台的列表页和详情页拿到JSON或HTML之后做字段解析和清洗最后落库。存储层初期用SQLite等数据量超过两万条后我换成了MySQL避免并发写入时出现数据库锁问题。业务分析层这一层全部写在Django的app里对外暴露一组JSON接口比如按区域求均价、按户型统计数量、按面积段分布等。展示层就是ECharts画的大屏页面包含首页总览、区域价格地图、户型占比、价格走势等模块。大模型的接入放在分析层的上层负责房源描述生成和简单问答。这套链路最大的优点是“每一层都有干货”论文每一章都有实际代码支撑不是空谈框架。2. Requests爬虫房源数据采集的实操细节与反爬应对2.1 先搞清楚目标站点的页面规律再写代码写爬虫最忌讳一上来就敲代码。我第一天通宵写了个脚本结果发现目标站点的列表页是动态加载的直接用Requests拿不到房源列表白白浪费了半宿。第二天老老实实打开浏览器开发者工具把网络请求逐个看了一遍才找到真实的接口地址。实际操作套路是这样的打开目标租房网站的列表页按F12进入开发者工具切到Network选项卡刷新页面重点看XHR请求找到返回JSON数据的那个接口地址观察接口的参数规律比如页码参数、城市参数、租金范围参数用Requests模拟该接口请求带上必要的请求头验证能否拿到数据如果接口有加密参数就退而求其次直接抓列表页HTML用正则或解析库提取字段。我抓的那批数据就是用接口方式拿的返回的是JSON字段直接可用省去了HTML解析的各种坑。但你要注意不同站点的接口风格差别很大有的需要带签名参数有的要携带Cookie。这种场景下我的兜底方案是先抓列表页的静态HTML解析每个房源的详情页链接再逐个请求详情页。速度慢一些但稳定性好适合毕设这种对实时性要求不高的场景。2.2 请求头伪装与请求频率控制反爬的正面应对我的Requests写法分三块请求头设置、Session保活、频率控制。请求头里面最关键的是User-Agent和Referer很多站点对缺少这两个字段的请求直接返回403。下面这个是我当时的基础模板import requests import time import random HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36, Referer: https://www.example.com/zufang/, Accept: application/json, text/plain, */*, Accept-Language: zh-CN,zh;q0.9, } session requests.Session() session.headers.update(HEADERS) def fetch_list(page): url https://www.example.com/zufang/pg{}/.format(page) resp session.get(url, timeout10) if resp.status_code 200: return resp.json() else: print(请求失败状态码, resp.status_code) return None关于频率控制我的策略是每次请求之间随机sleep 1到3秒不要用固定间隔否则很容易被识别为脚本。数据量不大时单线程就够了完全不用上多线程或者异步。如果你打算抓几万条数据再考虑线程池但毕设场景建议控制在一万条以内既够分析又不用处理太复杂的反爬问题。另外有一件事必须强调爬虫一定要遵守目标网站的Robots协议控制请求频率不要影响网站正常运行数据仅用于学习研究。论文里最好专门写一节“数据采集的合规性说明”答辩时老师很可能会问。2.3 字段清洗脏数据永远比你想的多抓下来的原始数据不能直接入库我统计了一下原始数据里大约有15%的字段存在问题。常见情况包括价格字段里有“元/月”这种单位后缀面积字段有“平米”文字朝向有的是“南北”有的是“南 北”带空格楼层字段格式五花八门部分房源缺经纬度坐标。我写了一个统一的清洗脚本核心逻辑是正则匹配加类型转换import re def clean_price(raw): num re.search(r\d, str(raw)) return int(num.group()) if num else 0 def clean_area(raw): num re.findall(r\d\.?\d*, str(raw)) return float(num[0]) if num else 0.0 def clean_orientation(raw): if not raw: return 未知 return raw.replace( , ).strip()清洗脚本跑完再统一做一次去重以“小区名户型面积价格”作为唯一键删掉重复数据。最终落库时字段类型要规范化比如价格用INTEGER、面积用FLOAT、经纬度用DECIMAL。很多人拿到爬下来的数据直接往数据库里塞后期做统计时会发现各种类型报错这一步别偷懒。3. Django后端与数据建模从爬虫数据到业务字段3.1 项目初始化与模型设计Django部分我建议用虚拟环境安装避免污染系统Python环境。完成环境隔离之后创建项目和应用然后重点设计数据模型。我的RentHouse模型是这样设计的from django.db import models class RentHouse(models.Model): title models.CharField(max_length200, verbose_name标题) district models.CharField(max_length50, verbose_name区域) bizcircle models.CharField(max_length100, verbose_name商圈, blankTrue) community models.CharField(max_length100, verbose_name小区) house_type models.CharField(max_length50, verbose_name户型) area models.FloatField(verbose_name面积) price models.IntegerField(verbose_name租金) orientation models.CharField(max_length20, verbose_name朝向) floor models.CharField(max_length50, verbose_name楼层) publish_date models.DateField(nullTrue, verbose_name挂牌日期) source_url models.URLField(uniqueTrue, verbose_name来源链接) created_at models.DateTimeField(auto_now_addTrue, verbose_name入库时间) def __str__(self): return self.title有几个设计细节值得说source_url设置成unique是为了防止同一房源被重复抓取和重复入库publish_date允许为空因为有部分房源详情页不公开挂牌日期area和price单独设成数值类型是为了后续ORM聚合计算方便。你要是把价格存成VARCHAR后面做均价统计就要先转换一趟纯属给自己加工作量。3.2 批量导入用bulk_create代替逐条循环数据清洗完成后导入数据库时千万不要用for循环逐条save十万条数据你能等到怀疑人生。正确做法是用Django ORM的bulk_create批量导入我实测一万条数据导入时间从分钟级降到秒级from sync_data.models import RentHouse def import_house_list(clean_rows): objs [ RentHouse( titlerow[title], districtrow[district], communityrow[community], house_typerow[house_type], arearow[area], pricerow[price], orientationrow[orientation], floorrow[floor], publish_daterow.get(publish_date), source_urlrow[source_url] ) for row in clean_rows ] RentHouse.objects.bulk_create(objs, batch_size500) print(f本次导入 {len(objs)} 条数据)如果你是从CSV文件导入还可以用pandas的read_csv先读进来转成字典列表后再调上面的函数。我当时就是写了一个management command放在Django应用里的management/commands/import_data.py这样可以用python manage.py import_data --filexxx.csv一键完成导入论文里写“实现了命令行数据导入工具”也算一个小亮点。3.3 聚合查询接口给前端提供干净的JSON可视化页面需要的数据不能靠模板里直接查数据库那样代码太乱。我的做法是写一个只读API视图用Django的ORM聚合函数处理数据后返回JSON。这块是Django最值钱的地方聚合统计代码非常简洁。from django.db.models import Avg, Count, Max, Min from django.http import JsonResponse from sync_data.models import RentHouse def district_stats(request): stats RentHouse.objects.values(district).annotate( avg_priceAvg(price), max_priceMax(price), min_priceMin(price), totalCount(id) ).order_by(avg_price) data { categories: [item[district] for item in stats], avg_prices: [round(item[avg_price], 2) for item in stats], total_counts: [item[total] for item in stats], } return JsonResponse(data)同理户型占比、面积段分布、价格分布这几类统计都可以用类似方式写。把所有接口集中在urls.py里统一配置前端直接fetch这些JSON接口渲染图表职责清晰答辩时也好讲解。这里我不推荐用Django REST Framework因为毕设只需要只读接口自带JsonResponse完全够用少装一个依赖就少一个报错源。4. 可视化大屏与数据分析维度把数据变成人话4.1 先定分析问题再选图表做可视化最怕“为画图而画图”。你在论文里写“我用了柱状图、折线图、饼图、散点图”老师一句“这些图表分别说明什么问题”就能把你问住。所以我在做页面之前先列了五个分析问题哪些区域的平均租金最高区域均价Top10用横向柱状图租金价格分布呈现什么形态价格区间频次分布用直方图或者柱状图户型与价格之间是什么关系不同户型的平均租金用箱线图或柱状图面积和总价之间是否存在相关性用散点图各区域挂牌房源数量如何用地图或饼图每个问题对应一张图每张图在页面上都有标题和图例说明评委扫一眼就能看懂你的分析逻辑。4.2 大屏页面布局与ECharts实战大屏页面我直接用Django模板渲染整体用CSS Grid布局分成上中下三行顶部展示平台名称和核心指标卡片房源总数、平均租金、最高租金、覆盖区域数中部左边是区域均价柱状图中间是价格分布图右边是户型占比饼图底部放面积-价格散点图和区域房源数量排行。页面加载后统一fetch接口再初始化ECharts。ECharts接入很流畅只需要在base模板里引入echarts.min.js然后在页面里声明容器和脚本。以区域均价柱状图为例div iddistrictChart stylewidth:100%;height:400px;/div script fetch(/api/district_stats/) .then(response response.json()) .then(data { var chart echarts.init(document.getElementById(districtChart)); chart.setOption({ title: { text: 区域平均租金排行(元/月) }, tooltip: { trigger: axis }, grid: { left: 3%, right: 4%, bottom: 3%, containLabel: true }, xAxis: { type: value, name: 元/月 }, yAxis: { type: category, data: data.categories.reverse() }, series: [{ type: bar, data: data.avg_prices.reverse(), itemStyle: { color: #409EFF } }] }); }); /script这种横向柱状图在区域名称较长时效果最好比纵向图看着舒服。我自己测试下来ECharts渲染几千个点完全无压力唯一要注意的是图表容器必须在DOM渲染完成后初始化所以脚本要放到页面底部或者用window.onload包裹。4.3 数据分析结论图表下面一定要有解读可视化页面不是终点论文里要写“基于可视化图表得出的分析结论”。我根据实际抓到的数据得出了几条很有价值的信息租金与面积整体呈现正相关但单价与面积负相关大面积房源存在明显的“面积溢价折价”现象地铁沿线房源价格明显高于非沿线同样户型的平均租金差距在20%到30%一居室和两居室的单位面积租金最高三居室以上的单位面积租金逐步下降热门商圈房源量集中但价格离散程度极大存在明显的长尾效应。每条结论我都在大屏配了对应的图表答辩时把这套“结论图表”讲下来老师基本不会再追问“分析和可视化在哪”。还有个加分项我会在页面下方放一个数据说明卡片注明数据采集时间和数据条数虽然不起眼但能体现你的严谨性。5. 大模型融合房源描述生成与价格趋势预判5.1 毕设里怎么切大模型最加分大模型现在确实是热点但如果只是简单调API聊天评委只会觉得你是“蹭热点”。我调研了一圈给平台设计了大模型的两个落地场景第一个是智能房源摘要生成。爬虫拿到的是结构化字段普通用户看一串字段信息不直观大模型可以根据区域、户型、价格、面积、朝向、楼层这些字段生成一段自然、口语化的房源推荐语。第二个是租房问答助手。用户提出“XX小区附近一居室月租大概多少”“预算3000在A区能租到什么房子”这类问题平台先从数据库里检索匹配数据再让大模型组织成自然语言回答。这一步的关键是“先检索后生成”也就是RAG的思路而不是让模型瞎编数据。毕设环节做好第一个场景基本就够惊艳了第二个可以做效果展示。5.2 提示词模板字段转文案的工程化写法大模型结果质量高不高70%取决于提示词设计。我试过的提示词模板可以直接参考你是一个专业的房屋租赁文案编辑。请根据以下结构化字段生成一段60字以内、 符合中文表达习惯的房源推荐语突出性价比和适合人群。 字段信息 区域{district} 小区{community} 户型{house_type} 面积{area}平米 月租{price}元 朝向{orientation} 楼层{floor} 要求 1. 不要出现“优质”“绝佳”等空泛形容词 2. 适当强调房源的实际优势比如价格低于同区域均值或面积较大 3. 结尾给出适合人群建议实际调用时我先从数据库里取Top10的房源记录拼成上面模板再请求大模型接口。实测下来不同模型生成的描述质量差距挺大但做毕设够用了。要注意的是调用大模型API的代码不要写在Django视图中同步执行因为一次请求可能要几秒钟页面会卡住。我的方案是写一个Celery定时任务每天晚上批量生成房源描述存入一个独立的description字段里页面直接读库展示。5.3 部署细节与成本控制别让API费用吃穷你大模型API按token计费毕设阶段一定要控制成本。我的经验是先用小模型做测试调通提示词后再考虑更高级的模型单次生成限制输出长度比如max_tokens设置为200对同一房源只生成一次用字段是否为空判断是否跳过。整个项目大概生成了3000条房源描述控制在几十块钱以内属于完全可以接受的范围。代码层面的调用建议封装成独立模块不要散落在视图里def generate_house_description(house): prompt build_prompt(house) try: response llm_client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是一名严谨的租房数据分析助手。}, {role: user, content: prompt} ], max_tokens200, temperature0.7 ) return response.choices[0].message.content.strip() except Exception as e: print(大模型调用失败, e) return 如果用国内大模型服务就在他们的控制台创建API Key用国外模型也是同样的HTTP请求逻辑核心就是模型名、API Key、消息上下文这三个参数。安全方面API Key千万不要写死在代码里我用的是环境变量方式加载并且把.env文件加入了.gitignore避免上传到代码仓库泄露。6. 部署落地与服务器联调从本地跑通到外网可访问6.1 本地联调最容易忽略的两个点静态文件和ALLOWED_HOSTS本地开发时用Django自带开发服务器一切正常但准备部署上服务器时会遇到两个经典问题。第一个是静态文件404因为Django生产模式下默认不提供静态文件服务需要收集静态文件并交给Nginx托管或者用WhiteNoise这个中间件。第二个是访问IP地址时报DisallowedHost错误需要在settings.py里配置ALLOWED_HOSTS把服务器IP和域名加进去。我在本地联调时采用的方法是开发阶段直接在settings.py里写ALLOWED_HOSTS [*]方便自己用局域网IP测试手机端效果准备部署时再改成具体域名或IP保证安全性。静态文件方面为了省事我用了WhiteNoise一行配置解决这样就不用单独配Nginx静态路径了对于毕设演示足够。6.2 Gunicorn Nginx的经典部署组合我部署方案用的是Gunicorn作为Django的WSGI服务器Nginx做反向代理这套组合最稳。先安装并启动Gunicornpip install gunicorn gunicorn -w 4 -b 0.0.0.0:8000 config.wsgi:application这里-w 4表示4个worker进程小内存云服务器建议改2个否则容易OOM。Nginx配置里把/路径代理到8000端口同时处理静态文件。整套配置跑通后用systemctl管理Gunicorn服务确保重启服务器后自动拉起应用。6.3 数据更新策略别手动跑爬虫了数据有时效性论文里最好写“实现了定时自动更新”。我用的是最简单的crontab方案每天凌晨两点执行爬虫脚本先抓新数据再清洗入库最后更新大屏数据0 2 * * * cd /home/ubuntu/rent_analysis /home/ubuntu/venv/bin/python manage.py crawl_update logs/crawler.log 21这个crontab命令解释一下每天凌晨2点进入项目目录用虚拟环境里的Python执行自定义管理命令。这里我写了一个crawl_update命令内部逻辑是抓取数据 → 清洗 → 去重 → 增量入库 → 更新描述生成。上线之后我每天检查一次日志只要log文件里没有异常就说明系统在健康运行。比起手动执行这种自动化方案在答辩时能给你加分不少。7. 踩坑总结与毕设答辩我走过的弯路你可以绕开7.1 三个典型坑的完整排查过程第一个坑是SQLite数据库锁问题。我最初图省事用SQLite结果爬虫批量写入和前端聚合查询同时发生时经常报database is locked。排查过程比较曲折我一开始以为是代码问题单步调试了很久才发现是并发写锁。后来把数据库切成MySQL用INSERT IGNORE配合唯一索引做去重写入问题彻底解决。所以数据量超过一万条别犹豫直接上MySQL。第二个坑是ECharts图表初始化时容器宽度为0。当时图表怎么都不显示打开浏览器开发者工具才发现容器是display:none初始宽度为0。解决方案是把初始化代码放到窗口load事件之后执行或者等tab切换完成再初始化图表。第三个坑是大模型API调用超时。一次生成3000条房源描述如果逐条同步请求几个小时都跑不完而且中途还经常断连。我的解决方案是加retry机制每次超时3秒则重试3次同时用批量并发限制比如同时最多10个请求实测速度提升了近10倍。这块在论文“系统优化”章节里是一个很好的篇幅点。7.2 答辩高频问题与应对思路毕设答辩老师一般会围绕三个方向提问技术选型、代码真实性、业务理解。技术选型方面最常被问的是“为什么用Requests不用Scrapy”。我的回答思路是毕设数据量在万级规模Requests单线程加控制延迟完全够用且代码的可读性和可控性更高Scrapy更适合大规模分布式采集但需要额外引入Twisted异步框架对于这个项目来说属于过度设计。如果你回答的时候再补一句“数据量过万时我也对比过Scrapy的采集效率”效果会更好。代码真实性方面老师会看有没有业务逻辑漏洞。比如数据一致性问题、异常处理机制、API密钥安全等。我在代码里故意设计了两处亮点一处是在批量导入前用transaction.atomic()包裹事务保证部分失败时数据不残留另一处是把所有外部调用的异常都封装到统一的日志体系里。这两点虽然代码量不大但体现了工程思维。业务理解方面的高频问题是“你的分析结果能说明什么真实租房问题”。这里一定要把大数据演化的几个关键结论背熟配合平台页面上的可视化结果进行呼应。比如“地铁对租金的溢价影响”这种结论就要能现场解释清楚从哪个图表看出来的。做完整套平台再回头看这个项目的技术含量并不在于用了多少高大上的算法而是把一条“数据采集-存储-分析-展示-智能应用”的全链路走通了。我在实际操作中最深的体会是文档写得再多都不如自己把爬虫脚本跑一遍、把数据库表建一遍、把可视化页面调通一遍踩过的坑才是真正长在自己身上的能力。接下来你可以从爬虫模块开始动手跑通一遍数据采集再逐步往Django后端迁移。这套思路不光适用于租房数据换成二手房、招聘、商品评论这些同样公开的数据源整个框架几乎可以平移到新的领域。