1. 项目拆解与整体方案设计1.1 我为什么选择做这个项目这两年数据分析岗位的竞争越来越激烈简历上光写“我会Python”“我熟悉SQL”已经没什么说服力了。我当时的想法是要做就做一个有真实数据来源、有完整业务闭环、能展示工程能力的项目。房地产行业的数据量足够大二手房信息又高度结构化——价格、面积、户型、城区、朝向、楼龄这些字段天然适合做分析和可视化呈现。拿它做练手项目既能覆盖爬虫采集、数据清洗、数据库设计、后端接口开发、前端可视化这一整条链路又能讲出清晰的业务故事。这个项目做完以后我最大的感受是它不是一个“玩具”而是一个可以持续迭代的真实系统。从数据采集到最终的可视化展示每个环节都有不少坑踩完这些坑再回头去看招聘网站上那些“会爬虫”“熟悉Django”“了解ECharts”的要求你会发现自己已经能把这些关键词串成一条线了。1.2 方案选型背后的核心思路技术选型这件事我不太建议一上来就追求“高大上”。项目标题里定的是Django框架我评估了一下Django确实是最合适的——它自带Admin后台和ORM能快速把数据模型落库并管理起来模板系统配合Django REST Framework能直接提供API接口JWT认证、CORS跨域这些都有成熟的第三方库不需要自己造轮子。比Flask那种“轻量级”方案更省心的是Django把这些东西全都整合好了前后端联调的时候少了很多烦心事。采集方案我选了Scrapy理由很直接Scrapy的异步并发能力能显著减少请求等待时间而且它的Pipeline机制非常适合做数据清洗和去重。数据可视化用ECharts我承认Plotly和Pyecharts也不错但ECharts的交互效果、社区活跃度、中文文档质量都更好二手房这种地理分布数据的呈现地图散点图用ECharts几乎不需要额外写多少代码。数据量级上我先跑了两三个重点城市做验证采集到目标数据后再横向扩展到其他城市。为什么不一开始就全量跑因为反爬策略和数据结构在不同城市会略有差异先把单城市的链路跑通了后面只是“换参数、重新跑”的问题。1.3 数据库模型与字段抽象数据库设计是容易被新手忽略的环节。我当时想的是一套房源数据除了基本信息还得支持按城市、城区、价格、面积多维度筛选分析因此字段必须拆得足够细。最终落地的房源表核心字段包括字段类型说明id自增主键全库唯一标识cityvarchar城市名称districtvarchar城区locationvarchar小区/商圈titlevarchar标题摘要total_pricedecimal挂牌总价万元unit_pricedecimal挂牌单价元/㎡areadecimal建筑面积㎡bedroom/bathroom/livingroomint室/卫/厅数量orientationvarchar朝向floor_levelvarchar低中高楼层building_yearint建筑年份house_typevarchar塔楼/板楼等community_namevarchar小区名称listing_timedatetime挂牌时间crawl_timedatetime采集时间source_urlvarchar房源详情页链接update_statusint在售/下架标记这个表设计做对了一件事把展示信息和分析维度分开存。比如title存的是页面上的标题但真正做统计用的是district、unit_price这些结构化字段后续写SQL统计时不需要再看文字描述直接在字段级别聚合就行。采集到的原始数据里有不少脏数据比如部分价格字段带“万”字、面积带“平米”后缀清洗工作放在Scrapy的Pipeline里做入库时就已经是干净数据。2. 数据采集模块的实现细节2.1 Scrapy爬虫的工程结构与核心代码爬虫这部分我用的是Scrapy框架工程结构大致如下spider_project/ spiders/ house_spider.py items.py pipelines.py middlewares.py settings.py database/ db_operator.pyitems.py里定义了与数据库字段对应的Item结构pipelines.py里做数据清洗和入库。我觉得整个爬虫里最关键的是解析规则的稳定性这里直接贴一段核心解析逻辑用的方法是对页面结构做定位不依赖过长的样式名这样平台改版的时候改起来最快。import scrapy from scrapy.http import Request from spider_project.items import HouseItem class HouseSpider(scrapy.Spider): name house_spider def start_requests(self): city getattr(self, city, sh) for page in range(1, 101): url fhttps://xxx.{city}.example.com/ershoufang/pg{page}/ yield Request(url, callbackself.parse_list, dont_filterTrue) def parse_list(self, response): # 定位房源列表项不同城市页面结构略有差异这里统一按通用容器处理 list_items response.css(div.sellListContent li.clear) for item in list_items: detail_url item.css(a::attr(href)).get() if detail_url: yield Request( response.urljoin(detail_url), callbackself.parse_detail, meta{city: response.meta.get(city) or sh}, ) # 翻页逻辑解析下一页地址注意某些城市反爬严格需要降低翻页频率 next_page response.css(div.page-box a[classnext]::attr(href)).get() if next_page: yield Request(response.urljoin(next_page), callbackself.parse_list) def parse_detail(self, response): item HouseItem() # 信息提取字段可能因页面结构变化而失效必要场景下加异常兜底 title response.css(div.title h1::text).get() total_price response.css(div.overview span.total::text).get() unit_price response.css(div.unitPrice span::text).get() # 基本信息表里包含面积、户型、朝向、楼层等 info_items response.css(div.base ul li) for li in info_items: key li.css(span::text).get() value li.css(spanspan::text).get() if 面积 in key: item[area] value if 朝向 in key: item[orientation] value if 楼层 in key: item[floor_level] value item[title] title item[total_price] total_price item[unit_price] unit_price item[source_url] response.url yield item代码里有两个小细节值得注意一是dont_filterTrue要谨慎用分页地址如果每次都去重爬到后面会跳过部分页二是解析字段时最好都做空值兜底页面结构一变get()返回的是None如果后续直接做strip()就会报错。2.2 反爬应对与请求频率控制做爬虫绕不开反爬。链家系平台的反爬策略在业内算中等偏上我实践中总结下来主要有这几类手段User-Agent验证默认的Python UA基本会被识别。Cookie与登录态部分详情页需要带有效的Cookie。访问频率限制短时间高频请求会触发滑块或封禁。页面改版CSS样式和布局变化会导致解析规则失效。我的应对措施是第一中间件里随机切换真实设备UA池并开启ROBOTSTXT_OBEY False。注意这不是鼓励违反规则而是爬取公开数据时如果要遵循robots大部分平台都不会放行实际操作中需要在爬取频率上保持克制。第二请求间隔控制在2到5秒随机浮动开启DOWNLOAD_DELAY 3同时用并发数上限限制整体速率。单机单IP去爬一天控制在8000到10000个请求以内基本能稳定运行。第三最关键的一招设置自定义Headers模拟浏览器会话。很多反爬系统首先会识别Sec-Fetch、Referer这些请求头是否一致如果只带一个UA很容易被识破。我写了一个RandomHeader中间件每次请求时从列表里随机选一组完整Headers比只随机UA效果好得多。import random class RandomHeaderMiddleware: def process_request(self, request, spider): headers { User-Agent: random.choice(spider.settings[UA_LIST]), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Accept-Encoding: gzip, deflate, br, Referer: random.choice(spider.settings[REFERER_LIST]), } for key, value in headers.items(): request.headers.setdefault(key, value) return request有段时间我发现爬到某城市几万条之后请求开始跳验证码。排查下来确认是触发频率限制而不是代理被封。后来我调整策略单次采集任务控制在800页以内每200页暂停30到60秒同时随机抽取部分房源走另一套解析路径列表页直接解析价格信息不进详情页这样对详情页的请求量降低了至少三成整体又稳定跑了一段时间。2.3 增量采集与断点续爬二手房数据有一个业务特点房源会不定期上下架。如果你只做一次性全量采集那做分析的时候数据时效性就差很多。所以我的爬虫设计里专门加了增量采集模块每天定时抓取最新房源列表对比数据库中已有房源的状态挂掉的下架房源更新状态新出现的房源入库。这样数据库里的数据始终是动态的可视化分析里也能增加“近7天上新量”“降价房源”这些动态指标。断点续爬最简单可靠的方案不是搞复杂的断点状态管理而是把已成功入库的详情页URL存下来下一次采集前做URL去重。Scrapy自带的Request去重对碎片化请求意义不大因为列表页URL翻页后会变化真正的去重粒度应该落在详情页URL上。我在Pipeline里加了一个seen_url判断入库前查一下source_url是否已存在存在就丢弃不存在才写入。这样即使爬虫中途崩溃重启后也不会有重复数据。3. 数据清洗与预处理3.1 原始字段的标准化处理爬完原始数据千万别急着入库。我拿到的第一批数据里价格字段长这样565万、43000元/平、暂无面积字段长这样89.3平米、未知。如果不做清洗数据库里那些数值型字段全是字符串SQL聚合和可视化映射都没法直接做。我在pipelines.py里专门写了一个DataCleanPipeline处理逻辑分几步价格字符串去掉“万”“元/平”等后缀统一转成浮点数。缺失或“暂无”直接记为None不在这一步填充。面积字段去掉“平米”单位保留两位小数。朝向字段标准化比如“南北”和“南 北”统一成“南北”便于后续分组。楼层字段按数值判断映射为“低楼层/中楼层/高楼层”原始数据里如果有“底层”“顶层”这种描述做映射表转换。建筑年份转成整数如果年份字符串不合法直接置空不阻塞入库。清洗完成后我会在入库前做一次行级校验把面积小于5平米、总价小于1万的异常数据直接过滤掉。这些异常的采集错误留着只会污染分析结果。3.2 特征工程为机器学习准备新变量标题里带了机器学习那光有原始字段还不够。我在清洗之后额外构造了几个特征变量house_age当前年份减建筑年份用来分析房龄对价格的影响。price_per_floor楼层单价系数用总价除以所在楼层的参考均价反映楼层溢价。area_bucket面积分段标签比如“60平以下”“60-90平”“90-120平”“120平以上”可视化时按这个分组聚合。price_bucket价格分段用于热力分布图。decade按建筑年份归入年代区间如“90年代”“2000年代”“2010年代”。is_rare高单价且面积异常的标记分析时单独观察。做这些特征的目的在于后续做房价预测模型时可以直接用可视化也可以基于这些维度做下钻。特征工程这一步是数据分析和机器学习之间最关键的桥梁我建议每个做数据类项目的人都在这一块多花点心思。3.3 清洗规则与去重策略的落地去重这事不能只依赖URL。同一套房源可能会被不同经纪人重复发布只是标题细节不一样。我的方案是用“小区名面积朝向总价”四元组生成指纹如果指纹相同认为是重复房源只保留最新一条。这个方法实测去重率在15%左右效果明显。指纹计算很简单import hashlib def generate_fingerprint(record): raw f{record[community_name]}|{record[area]}|{record[orientation]}|{record[total_price]} return hashlib.md5(raw.encode(utf-8)).hexdigest()入库前查指纹库里有同指纹记录就跳过。这种方式比只按URL去重可靠得多尤其适合二手房租售平台这类容易出现重复挂牌的数据源。4. Django后端系统与可视化落地4.1 Django项目结构与数据模型实现后端用的是Django我建的工程结构如下django_house/ manage.py apps/ house_analysis/ models.py views.py serializers.py urls.py utils/ analyzers.py static/ templates/ config/ settings.py urls.pymodels.py里建了一个HouseInfo模型字段跟前面爬虫里设计的数据库表一一对应。Model定义好之后用Django自带的Migration生成数据库表这个流程省了很多事。from django.db import models class HouseInfo(models.Model): city models.CharField(max_length32) district models.CharField(max_length64) community_name models.CharField(max_length128) title models.CharField(max_length255) area models.DecimalField(max_digits10, decimal_places2, nullTrue) total_price models.DecimalField(max_digits10, decimal_places2, nullTrue) unit_price models.DecimalField(max_digits10, decimal_places2, nullTrue) bedroom models.IntegerField(nullTrue) bathroom models.IntegerField(nullTrue) livingroom models.IntegerField(nullTrue) orientation models.CharField(max_length32) listing_time models.DateTimeField(nullTrue) crawl_time models.DateTimeField(auto_now_addTrue) source_url models.CharField(max_length255, uniqueTrue) update_status models.IntegerField(default1) class Meta: db_table house_info indexes [ models.Index(fields[city, district]), models.Index(fields[total_price]), ]注意我给city district和total_price建了索引。数据分析系统里最常做的操作就是按城市和城区筛选再按总价区间排序这两个联合索引能把查询速度提升一个量级。4.2 聚合统计接口的设计思路可视化前端的数据来源是后端提供的JSON接口。我没有让前端直接查数据库而是为每个图表专门写聚合SQL。这样做的原因是Django ORM虽然方便但做分组统计时生成的SQL有时候不是最优的不如自己直接写聚合查询来得清楚。以“各城区平均单价排名”为例接口返回的数据结构是这样{ code: 0, data: { categories: [浦东, 徐汇, 静安], values: [52345.2, 61840.1, 59230.7] } }后端实现是from django.db.models.functions import Round def district_price_rank(citysh, bucketunit_price): queryset ( HouseInfo.objects.filter(citycity, unit_price__isnullFalse) .values(district) .annotate(avg_priceRound(Avg(unit_price), 2)) .order_by(-avg_price) ) return querysetECharts拿到这种结构直接配置xAxis和series就能出图联调成本非常低。接口设计的原则是后端做聚合前端只做展示不要让图表逻辑分散在前后端两端。4.3 ECharts可视化图表的完整配置这是整个项目里最直观的部分。下面直接给一个完整可用的ECharts散点图配置展示“单价与面积的关系”每个点代表一套房源颜色深浅代表总价高低鼠标悬浮时展示城区、小区、朝向等信息var myChart echarts.init(document.getElementById(chartContainer)); var option { title: { text: 单价/面积分布散点图, left: center, textStyle: { fontSize: 16 }, }, tooltip: { trigger: item, formatter: function (params) { var d params.data; return ( 小区 d.community br/ 面积 d.area ㎡br/ 总价 d.totalPrice 万br/ 单价 d.unitPrice 元/㎡br/ 朝向 d.orientation ); }, }, xAxis: { name: 面积㎡, type: value, scale: true, }, yAxis: { name: 单价元/㎡, type: value, scale: true, }, series: [ { name: 房源, type: scatter, data: scatterData, symbolSize: function (val) { return Math.min(20, val[0] / 10); }, itemStyle: { color: function (param) { var price param.data[2]; if (price 600) return #c23531; if (price 400) return #e6550d; if (price 200) return #fdae6b; return #c6dbef; }, }, }, ], }; myChart.setOption(option);scatterData由后端接口一次性返回格式是[area, unitPrice, totalPrice, community, orientation]的二维数组。如果数据量超过几千条前端渲染几千个点的散点图其实没问题但如果到几万条建议加一个dataZoom组件或者做服务端抽样否则交互会有卡顿感。4.4 全国数据的地图分布与前端模板整合全国范围的二手房分析要做地图可视化ECharts的地图模式需要提前注册GeoJSON数据。我用的是全国城市级GeoJSON配合geo坐标系来展示不同城市的平均房价。地图上的每个城市点鼠标悬浮时显示该城市库存量、平均单价、平均面积。var geoOption { geo: { map: china, roam: true, itemStyle: { areaColor: #e8e8e8, borderColor: #333, }, }, series: [ { type: effectScatter, coordinateSystem: geo, data: cityData, symbolSize: function (val) { return Math.max(6, Math.min(30, val[2] / 1000)); }, tooltip: { formatter: function (params) { return ( params.name br/在售房源 params.value[3] 套br/平均单价 params.value[2] 元/㎡ ); }, }, }, ], };数据和地图联动这步做好之后整个页面一下子就有“大数据分析系统”的样子了。前端模板我是用Django模板引擎直接渲染的没有前后端分离原因很简单这不是一个需要大量交互的复杂前端应用Django模板渲染一页直出反而省掉了一套Node环境。当然如果你要把这个项目扩展到更多交互页面那再引入Vue或React也不迟根据实际需求来决定别盲目上重架构。5. 机器学习算法在分析系统中的应用5.1 房价预测模型的特征选择与训练既然标题里有机器学习光做可视化显然不够。我用清洗后的数据训练了一个房价预测模型目标是根据房源特征预测挂牌单价。特征选了这样几个area建筑面积bedroom、livingroom、bathroomorientation做label encodingfloor_level映射成1/2/3house_agedistrict做one-hot编码模型我用的是Scikit-learn的RandomForestRegressor。选随机森林的理由是它不需要做特别复杂的特征缩放对异常值有一定的鲁棒性而且能输出特征重要性这正好可以补充到可视化页面上做一个“影响房价的关键因素排序”。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestRegressor from sklearn.metrics import mean_absolute_error, r2_score def train_model(df): feature_cols [ area, bedroom, livingroom, bathroom, orientation_enc, floor_level, house_age, district_sh, district_pd, district_xh, ] X df[feature_cols] y df[unit_price] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42 ) model RandomForestRegressor( n_estimators200, max_depth20, min_samples_leaf2, n_jobs-1, random_state42, ) model.fit(X_train, y_train) y_pred model.predict(X_test) print(MAE:, mean_absolute_error(y_test, y_pred)) print(R2:, r2_score(y_test, y_pred)) importance sorted( zip(feature_cols, model.feature_importances_), keylambda x: x[1], reverseTrue, ) return model, importance实测下来的结果MAE大致在3000到5000元/平米的量级R2在0.6到0.75之间。别太追求极端精度房价预测这种任务本身就有很多无法结构化表达的因素——楼层视野、装修情况、学区属性这些都没有体现在数据里。能用随机森林得到一个合理的区间预测已经能说明特征工程和数据质量是过关的了。5.2 模型结果到可视化呈现的闭环模型训练好以后我把特征重要性排序结果输出成一个JSON交给前端画一个“特征重要性Top5”的横向柱状图。同时模型预测的价格区间可以在地图上叠加展示比如某个小区预测均价和实际挂牌均价的差值用颜色深浅标识“价格洼地”和“价格高估”。这块做完项目才算真正把机器学习和可视化打通了而不只是“训练了一个模型然后就扔在那里”。6. 系统部署与性能优化策略6.1 数据库容量规划与查询性能调优我爬了五个主要城市的数据累计房源总量在50万到80万条之间。对于MySQL来说这个量级其实很轻松但如果查询写得不好照样会卡。我做的优化主要有这几个热门字段建立组合索引比如(city, district, total_price)。因为可视化页面按城市、城区筛选的频率极高这类查询走索引就能秒出。聚合查询避免全表扫描。统计城区均价时先按city过滤再做分组聚合。大结果集接口做分页前端用dataZoom控制可视范围后端返回LIMIT 500。定时跑数据快照生成统计结果表。每天的均价、挂牌量变化都查快照表不查原始大表。其中第4点效果最明显。有些页面要展示“近30天挂牌量走势”如果每次都去查50万行的原始表响应时间很难控制。但跑一个定时任务每天凌晨把前一天各城区的汇总指标写入一张daily_stats表前端查询走这张小表毫秒级响应。6.2 Django服务部署与静态资源处理部署方面我用的是常规的Nginx uWSGI Django组合。静态文件和媒体文件由Nginx直接提供Django只处理动态请求。数据库连接池用Django内置的CONN_MAX_AGE参数设置为60秒减少反复建立数据库连接的开销。另外有个容易忽略的坑Django的DEBUGFalse模式下静态文件服务需要单独处理如果你之前习惯用Django自带的runserver跑静态文件部署时会发现所有CSS样式都没了。需要先在项目里执行一次collectstatic把全部静态文件收集到一个统一目录然后让Nginx指向这个目录。6.3 定时调度与监控告警爬虫采集和统计任务都需要定时执行。我用了系统自带的crontab每天凌晨2点跑一次增量采集凌晨4点跑一次数据快照统计早上7点前所有数据刷新完毕用户白天访问到的就是前一天最新数据的分析结果。监控这块我是给采集任务加了一个简单的邮件告警如果单天采集量少于正常值的一定比例就发邮件提醒自己检查是不是平台反爬升级或者网络异常。这个细节看着不起眼但对长期运行的数据系统非常有用——数据源挂了你不一定第一时间知道等用户发现页面数据一直是旧的问题就大了。7. 常见问题与排查技巧实录7.1 采集端高频问题定位与解决我运行过程中遇到过几类典型问题整理成速查表供参考问题现象可能原因解决方案采集件数为0但无报错页面结构变化解析不到列表项打开网页对比div容器类名更新列表定位详情页返回验证码页面请求频率过高或Headers不完整降低DOWNLOAD_DELAY到8秒检查完整Headers数据入库但字段为空详情页字段名拿到的是空字符串打印整个li列表核对字段取值逻辑采集一段时间后请求全被拦截IP被临时限制暂停30分钟更换UA池减并数量有重复数据指纹去重未生效检查generate_fingerprint的字段顺序是否包含区分性字段这里最容易被忽视的是第二项——验证码页面不一定返回HTTP异常。有时状态码还是200只是页面内容变成了一段验证逻辑如果你的解析规则没做页面内容校验就会爬回来一堆无用数据而且不报错。我的处理办法是解析前先判断页面里是否包含目标容器类名没有就直接丢弃并打印日志。7.2 数据分析与可视化的常见陷阱可视化部分的踩坑记录也有价值我挑几个典型的散点图数据量过大导致卡顿。ECharts能承受的散点数量大约在5000个左右超过1万就会明显掉帧。解决办法是先按面积区间做聚合再画散点图或者加服务端抽样。地图坐标系数据对不上位置。这个问题多半是城市名称不匹配——Django后端存的是“上海”GeoJSON里的城市名可能是“上海市”。统一在数据接口层做一次城市名标准化映射别在前端做。价格字段类型混乱导致图表显示错乱。清洗时必须确保入库是浮点数如果原始字符串带上了“万”字画图时数字会直接错位。建议在清洗Pipeline里统一转换并做断言校验。统计口径不一致。同样是“平均单价”有的页面可能直接对所有房源求均值有的页面却按小区均价再平均两个数值差很多。全系统必须统一统计口径我在聚合工具类里统一封装了avg_unit_price所有页面都调同一个函数避免各写各的。7.3 让项目具备长期生命力的扩展方向这个项目做完之后我发现它完全可以继续扩展。想做文本分析的话可以把房源标题拿去做关键词提取找出买房人关注的卖点词频想做实时系统的话可以引入消息队列和流计算框架把每小时的新增房源做个实时下钻大屏想更深地玩机器学习的话可以拆一个“成交价预测”子模型出来再挂上户型图识别模型做视觉特征融合。我个人建议如果是为了找工作或简历展示项目做到现有程度已经足够体现全栈能力和数据分析功底。接下来可以按需补一两个亮点比如把预测模型的准确率优化过程整理成技术文章或者把部署过程写成文档同步在简历链接里。技术项目写到简历上重要的不只是结果还有你踩过坑、解决问题的过程那才是面试官真正感兴趣的东西。最后想说的话做完这个项目我最真实的体会是数据的价值不在于你爬了多少条而在于你能从多乱的数据里提炼出多清晰的信息。爬虫只是开始真正花时间的其实是清洗字段口径、调试接口、打磨前端细节这些不大起眼的部分。如果你也打算做一个类似的系统建议从单一城市开始先跑通全链路再横向扩展。每一步都记录下来踩过的坑就是你后面应对同类问题最大的底气。
1. 项目拆解与整体方案设计1.1 我为什么选择做这个项目这两年数据分析岗位的竞争越来越激烈简历上光写“我会Python”“我熟悉SQL”已经没什么说服力了。我当时的想法是要做就做一个有真实数据来源、有完整业务闭环、能展示工程能力的项目。房地产行业的数据量足够大二手房信息又高度结构化——价格、面积、户型、城区、朝向、楼龄这些字段天然适合做分析和可视化呈现。拿它做练手项目既能覆盖爬虫采集、数据清洗、数据库设计、后端接口开发、前端可视化这一整条链路又能讲出清晰的业务故事。这个项目做完以后我最大的感受是它不是一个“玩具”而是一个可以持续迭代的真实系统。从数据采集到最终的可视化展示每个环节都有不少坑踩完这些坑再回头去看招聘网站上那些“会爬虫”“熟悉Django”“了解ECharts”的要求你会发现自己已经能把这些关键词串成一条线了。1.2 方案选型背后的核心思路技术选型这件事我不太建议一上来就追求“高大上”。项目标题里定的是Django框架我评估了一下Django确实是最合适的——它自带Admin后台和ORM能快速把数据模型落库并管理起来模板系统配合Django REST Framework能直接提供API接口JWT认证、CORS跨域这些都有成熟的第三方库不需要自己造轮子。比Flask那种“轻量级”方案更省心的是Django把这些东西全都整合好了前后端联调的时候少了很多烦心事。采集方案我选了Scrapy理由很直接Scrapy的异步并发能力能显著减少请求等待时间而且它的Pipeline机制非常适合做数据清洗和去重。数据可视化用ECharts我承认Plotly和Pyecharts也不错但ECharts的交互效果、社区活跃度、中文文档质量都更好二手房这种地理分布数据的呈现地图散点图用ECharts几乎不需要额外写多少代码。数据量级上我先跑了两三个重点城市做验证采集到目标数据后再横向扩展到其他城市。为什么不一开始就全量跑因为反爬策略和数据结构在不同城市会略有差异先把单城市的链路跑通了后面只是“换参数、重新跑”的问题。1.3 数据库模型与字段抽象数据库设计是容易被新手忽略的环节。我当时想的是一套房源数据除了基本信息还得支持按城市、城区、价格、面积多维度筛选分析因此字段必须拆得足够细。最终落地的房源表核心字段包括字段类型说明id自增主键全库唯一标识cityvarchar城市名称districtvarchar城区locationvarchar小区/商圈titlevarchar标题摘要total_pricedecimal挂牌总价万元unit_pricedecimal挂牌单价元/㎡areadecimal建筑面积㎡bedroom/bathroom/livingroomint室/卫/厅数量orientationvarchar朝向floor_levelvarchar低中高楼层building_yearint建筑年份house_typevarchar塔楼/板楼等community_namevarchar小区名称listing_timedatetime挂牌时间crawl_timedatetime采集时间source_urlvarchar房源详情页链接update_statusint在售/下架标记这个表设计做对了一件事把展示信息和分析维度分开存。比如title存的是页面上的标题但真正做统计用的是district、unit_price这些结构化字段后续写SQL统计时不需要再看文字描述直接在字段级别聚合就行。采集到的原始数据里有不少脏数据比如部分价格字段带“万”字、面积带“平米”后缀清洗工作放在Scrapy的Pipeline里做入库时就已经是干净数据。2. 数据采集模块的实现细节2.1 Scrapy爬虫的工程结构与核心代码爬虫这部分我用的是Scrapy框架工程结构大致如下spider_project/ spiders/ house_spider.py items.py pipelines.py middlewares.py settings.py database/ db_operator.pyitems.py里定义了与数据库字段对应的Item结构pipelines.py里做数据清洗和入库。我觉得整个爬虫里最关键的是解析规则的稳定性这里直接贴一段核心解析逻辑用的方法是对页面结构做定位不依赖过长的样式名这样平台改版的时候改起来最快。import scrapy from scrapy.http import Request from spider_project.items import HouseItem class HouseSpider(scrapy.Spider): name house_spider def start_requests(self): city getattr(self, city, sh) for page in range(1, 101): url fhttps://xxx.{city}.example.com/ershoufang/pg{page}/ yield Request(url, callbackself.parse_list, dont_filterTrue) def parse_list(self, response): # 定位房源列表项不同城市页面结构略有差异这里统一按通用容器处理 list_items response.css(div.sellListContent li.clear) for item in list_items: detail_url item.css(a::attr(href)).get() if detail_url: yield Request( response.urljoin(detail_url), callbackself.parse_detail, meta{city: response.meta.get(city) or sh}, ) # 翻页逻辑解析下一页地址注意某些城市反爬严格需要降低翻页频率 next_page response.css(div.page-box a[classnext]::attr(href)).get() if next_page: yield Request(response.urljoin(next_page), callbackself.parse_list) def parse_detail(self, response): item HouseItem() # 信息提取字段可能因页面结构变化而失效必要场景下加异常兜底 title response.css(div.title h1::text).get() total_price response.css(div.overview span.total::text).get() unit_price response.css(div.unitPrice span::text).get() # 基本信息表里包含面积、户型、朝向、楼层等 info_items response.css(div.base ul li) for li in info_items: key li.css(span::text).get() value li.css(spanspan::text).get() if 面积 in key: item[area] value if 朝向 in key: item[orientation] value if 楼层 in key: item[floor_level] value item[title] title item[total_price] total_price item[unit_price] unit_price item[source_url] response.url yield item代码里有两个小细节值得注意一是dont_filterTrue要谨慎用分页地址如果每次都去重爬到后面会跳过部分页二是解析字段时最好都做空值兜底页面结构一变get()返回的是None如果后续直接做strip()就会报错。2.2 反爬应对与请求频率控制做爬虫绕不开反爬。链家系平台的反爬策略在业内算中等偏上我实践中总结下来主要有这几类手段User-Agent验证默认的Python UA基本会被识别。Cookie与登录态部分详情页需要带有效的Cookie。访问频率限制短时间高频请求会触发滑块或封禁。页面改版CSS样式和布局变化会导致解析规则失效。我的应对措施是第一中间件里随机切换真实设备UA池并开启ROBOTSTXT_OBEY False。注意这不是鼓励违反规则而是爬取公开数据时如果要遵循robots大部分平台都不会放行实际操作中需要在爬取频率上保持克制。第二请求间隔控制在2到5秒随机浮动开启DOWNLOAD_DELAY 3同时用并发数上限限制整体速率。单机单IP去爬一天控制在8000到10000个请求以内基本能稳定运行。第三最关键的一招设置自定义Headers模拟浏览器会话。很多反爬系统首先会识别Sec-Fetch、Referer这些请求头是否一致如果只带一个UA很容易被识破。我写了一个RandomHeader中间件每次请求时从列表里随机选一组完整Headers比只随机UA效果好得多。import random class RandomHeaderMiddleware: def process_request(self, request, spider): headers { User-Agent: random.choice(spider.settings[UA_LIST]), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Accept-Encoding: gzip, deflate, br, Referer: random.choice(spider.settings[REFERER_LIST]), } for key, value in headers.items(): request.headers.setdefault(key, value) return request有段时间我发现爬到某城市几万条之后请求开始跳验证码。排查下来确认是触发频率限制而不是代理被封。后来我调整策略单次采集任务控制在800页以内每200页暂停30到60秒同时随机抽取部分房源走另一套解析路径列表页直接解析价格信息不进详情页这样对详情页的请求量降低了至少三成整体又稳定跑了一段时间。2.3 增量采集与断点续爬二手房数据有一个业务特点房源会不定期上下架。如果你只做一次性全量采集那做分析的时候数据时效性就差很多。所以我的爬虫设计里专门加了增量采集模块每天定时抓取最新房源列表对比数据库中已有房源的状态挂掉的下架房源更新状态新出现的房源入库。这样数据库里的数据始终是动态的可视化分析里也能增加“近7天上新量”“降价房源”这些动态指标。断点续爬最简单可靠的方案不是搞复杂的断点状态管理而是把已成功入库的详情页URL存下来下一次采集前做URL去重。Scrapy自带的Request去重对碎片化请求意义不大因为列表页URL翻页后会变化真正的去重粒度应该落在详情页URL上。我在Pipeline里加了一个seen_url判断入库前查一下source_url是否已存在存在就丢弃不存在才写入。这样即使爬虫中途崩溃重启后也不会有重复数据。3. 数据清洗与预处理3.1 原始字段的标准化处理爬完原始数据千万别急着入库。我拿到的第一批数据里价格字段长这样565万、43000元/平、暂无面积字段长这样89.3平米、未知。如果不做清洗数据库里那些数值型字段全是字符串SQL聚合和可视化映射都没法直接做。我在pipelines.py里专门写了一个DataCleanPipeline处理逻辑分几步价格字符串去掉“万”“元/平”等后缀统一转成浮点数。缺失或“暂无”直接记为None不在这一步填充。面积字段去掉“平米”单位保留两位小数。朝向字段标准化比如“南北”和“南 北”统一成“南北”便于后续分组。楼层字段按数值判断映射为“低楼层/中楼层/高楼层”原始数据里如果有“底层”“顶层”这种描述做映射表转换。建筑年份转成整数如果年份字符串不合法直接置空不阻塞入库。清洗完成后我会在入库前做一次行级校验把面积小于5平米、总价小于1万的异常数据直接过滤掉。这些异常的采集错误留着只会污染分析结果。3.2 特征工程为机器学习准备新变量标题里带了机器学习那光有原始字段还不够。我在清洗之后额外构造了几个特征变量house_age当前年份减建筑年份用来分析房龄对价格的影响。price_per_floor楼层单价系数用总价除以所在楼层的参考均价反映楼层溢价。area_bucket面积分段标签比如“60平以下”“60-90平”“90-120平”“120平以上”可视化时按这个分组聚合。price_bucket价格分段用于热力分布图。decade按建筑年份归入年代区间如“90年代”“2000年代”“2010年代”。is_rare高单价且面积异常的标记分析时单独观察。做这些特征的目的在于后续做房价预测模型时可以直接用可视化也可以基于这些维度做下钻。特征工程这一步是数据分析和机器学习之间最关键的桥梁我建议每个做数据类项目的人都在这一块多花点心思。3.3 清洗规则与去重策略的落地去重这事不能只依赖URL。同一套房源可能会被不同经纪人重复发布只是标题细节不一样。我的方案是用“小区名面积朝向总价”四元组生成指纹如果指纹相同认为是重复房源只保留最新一条。这个方法实测去重率在15%左右效果明显。指纹计算很简单import hashlib def generate_fingerprint(record): raw f{record[community_name]}|{record[area]}|{record[orientation]}|{record[total_price]} return hashlib.md5(raw.encode(utf-8)).hexdigest()入库前查指纹库里有同指纹记录就跳过。这种方式比只按URL去重可靠得多尤其适合二手房租售平台这类容易出现重复挂牌的数据源。4. Django后端系统与可视化落地4.1 Django项目结构与数据模型实现后端用的是Django我建的工程结构如下django_house/ manage.py apps/ house_analysis/ models.py views.py serializers.py urls.py utils/ analyzers.py static/ templates/ config/ settings.py urls.pymodels.py里建了一个HouseInfo模型字段跟前面爬虫里设计的数据库表一一对应。Model定义好之后用Django自带的Migration生成数据库表这个流程省了很多事。from django.db import models class HouseInfo(models.Model): city models.CharField(max_length32) district models.CharField(max_length64) community_name models.CharField(max_length128) title models.CharField(max_length255) area models.DecimalField(max_digits10, decimal_places2, nullTrue) total_price models.DecimalField(max_digits10, decimal_places2, nullTrue) unit_price models.DecimalField(max_digits10, decimal_places2, nullTrue) bedroom models.IntegerField(nullTrue) bathroom models.IntegerField(nullTrue) livingroom models.IntegerField(nullTrue) orientation models.CharField(max_length32) listing_time models.DateTimeField(nullTrue) crawl_time models.DateTimeField(auto_now_addTrue) source_url models.CharField(max_length255, uniqueTrue) update_status models.IntegerField(default1) class Meta: db_table house_info indexes [ models.Index(fields[city, district]), models.Index(fields[total_price]), ]注意我给city district和total_price建了索引。数据分析系统里最常做的操作就是按城市和城区筛选再按总价区间排序这两个联合索引能把查询速度提升一个量级。4.2 聚合统计接口的设计思路可视化前端的数据来源是后端提供的JSON接口。我没有让前端直接查数据库而是为每个图表专门写聚合SQL。这样做的原因是Django ORM虽然方便但做分组统计时生成的SQL有时候不是最优的不如自己直接写聚合查询来得清楚。以“各城区平均单价排名”为例接口返回的数据结构是这样{ code: 0, data: { categories: [浦东, 徐汇, 静安], values: [52345.2, 61840.1, 59230.7] } }后端实现是from django.db.models.functions import Round def district_price_rank(citysh, bucketunit_price): queryset ( HouseInfo.objects.filter(citycity, unit_price__isnullFalse) .values(district) .annotate(avg_priceRound(Avg(unit_price), 2)) .order_by(-avg_price) ) return querysetECharts拿到这种结构直接配置xAxis和series就能出图联调成本非常低。接口设计的原则是后端做聚合前端只做展示不要让图表逻辑分散在前后端两端。4.3 ECharts可视化图表的完整配置这是整个项目里最直观的部分。下面直接给一个完整可用的ECharts散点图配置展示“单价与面积的关系”每个点代表一套房源颜色深浅代表总价高低鼠标悬浮时展示城区、小区、朝向等信息var myChart echarts.init(document.getElementById(chartContainer)); var option { title: { text: 单价/面积分布散点图, left: center, textStyle: { fontSize: 16 }, }, tooltip: { trigger: item, formatter: function (params) { var d params.data; return ( 小区 d.community br/ 面积 d.area ㎡br/ 总价 d.totalPrice 万br/ 单价 d.unitPrice 元/㎡br/ 朝向 d.orientation ); }, }, xAxis: { name: 面积㎡, type: value, scale: true, }, yAxis: { name: 单价元/㎡, type: value, scale: true, }, series: [ { name: 房源, type: scatter, data: scatterData, symbolSize: function (val) { return Math.min(20, val[0] / 10); }, itemStyle: { color: function (param) { var price param.data[2]; if (price 600) return #c23531; if (price 400) return #e6550d; if (price 200) return #fdae6b; return #c6dbef; }, }, }, ], }; myChart.setOption(option);scatterData由后端接口一次性返回格式是[area, unitPrice, totalPrice, community, orientation]的二维数组。如果数据量超过几千条前端渲染几千个点的散点图其实没问题但如果到几万条建议加一个dataZoom组件或者做服务端抽样否则交互会有卡顿感。4.4 全国数据的地图分布与前端模板整合全国范围的二手房分析要做地图可视化ECharts的地图模式需要提前注册GeoJSON数据。我用的是全国城市级GeoJSON配合geo坐标系来展示不同城市的平均房价。地图上的每个城市点鼠标悬浮时显示该城市库存量、平均单价、平均面积。var geoOption { geo: { map: china, roam: true, itemStyle: { areaColor: #e8e8e8, borderColor: #333, }, }, series: [ { type: effectScatter, coordinateSystem: geo, data: cityData, symbolSize: function (val) { return Math.max(6, Math.min(30, val[2] / 1000)); }, tooltip: { formatter: function (params) { return ( params.name br/在售房源 params.value[3] 套br/平均单价 params.value[2] 元/㎡ ); }, }, }, ], };数据和地图联动这步做好之后整个页面一下子就有“大数据分析系统”的样子了。前端模板我是用Django模板引擎直接渲染的没有前后端分离原因很简单这不是一个需要大量交互的复杂前端应用Django模板渲染一页直出反而省掉了一套Node环境。当然如果你要把这个项目扩展到更多交互页面那再引入Vue或React也不迟根据实际需求来决定别盲目上重架构。5. 机器学习算法在分析系统中的应用5.1 房价预测模型的特征选择与训练既然标题里有机器学习光做可视化显然不够。我用清洗后的数据训练了一个房价预测模型目标是根据房源特征预测挂牌单价。特征选了这样几个area建筑面积bedroom、livingroom、bathroomorientation做label encodingfloor_level映射成1/2/3house_agedistrict做one-hot编码模型我用的是Scikit-learn的RandomForestRegressor。选随机森林的理由是它不需要做特别复杂的特征缩放对异常值有一定的鲁棒性而且能输出特征重要性这正好可以补充到可视化页面上做一个“影响房价的关键因素排序”。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestRegressor from sklearn.metrics import mean_absolute_error, r2_score def train_model(df): feature_cols [ area, bedroom, livingroom, bathroom, orientation_enc, floor_level, house_age, district_sh, district_pd, district_xh, ] X df[feature_cols] y df[unit_price] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42 ) model RandomForestRegressor( n_estimators200, max_depth20, min_samples_leaf2, n_jobs-1, random_state42, ) model.fit(X_train, y_train) y_pred model.predict(X_test) print(MAE:, mean_absolute_error(y_test, y_pred)) print(R2:, r2_score(y_test, y_pred)) importance sorted( zip(feature_cols, model.feature_importances_), keylambda x: x[1], reverseTrue, ) return model, importance实测下来的结果MAE大致在3000到5000元/平米的量级R2在0.6到0.75之间。别太追求极端精度房价预测这种任务本身就有很多无法结构化表达的因素——楼层视野、装修情况、学区属性这些都没有体现在数据里。能用随机森林得到一个合理的区间预测已经能说明特征工程和数据质量是过关的了。5.2 模型结果到可视化呈现的闭环模型训练好以后我把特征重要性排序结果输出成一个JSON交给前端画一个“特征重要性Top5”的横向柱状图。同时模型预测的价格区间可以在地图上叠加展示比如某个小区预测均价和实际挂牌均价的差值用颜色深浅标识“价格洼地”和“价格高估”。这块做完项目才算真正把机器学习和可视化打通了而不只是“训练了一个模型然后就扔在那里”。6. 系统部署与性能优化策略6.1 数据库容量规划与查询性能调优我爬了五个主要城市的数据累计房源总量在50万到80万条之间。对于MySQL来说这个量级其实很轻松但如果查询写得不好照样会卡。我做的优化主要有这几个热门字段建立组合索引比如(city, district, total_price)。因为可视化页面按城市、城区筛选的频率极高这类查询走索引就能秒出。聚合查询避免全表扫描。统计城区均价时先按city过滤再做分组聚合。大结果集接口做分页前端用dataZoom控制可视范围后端返回LIMIT 500。定时跑数据快照生成统计结果表。每天的均价、挂牌量变化都查快照表不查原始大表。其中第4点效果最明显。有些页面要展示“近30天挂牌量走势”如果每次都去查50万行的原始表响应时间很难控制。但跑一个定时任务每天凌晨把前一天各城区的汇总指标写入一张daily_stats表前端查询走这张小表毫秒级响应。6.2 Django服务部署与静态资源处理部署方面我用的是常规的Nginx uWSGI Django组合。静态文件和媒体文件由Nginx直接提供Django只处理动态请求。数据库连接池用Django内置的CONN_MAX_AGE参数设置为60秒减少反复建立数据库连接的开销。另外有个容易忽略的坑Django的DEBUGFalse模式下静态文件服务需要单独处理如果你之前习惯用Django自带的runserver跑静态文件部署时会发现所有CSS样式都没了。需要先在项目里执行一次collectstatic把全部静态文件收集到一个统一目录然后让Nginx指向这个目录。6.3 定时调度与监控告警爬虫采集和统计任务都需要定时执行。我用了系统自带的crontab每天凌晨2点跑一次增量采集凌晨4点跑一次数据快照统计早上7点前所有数据刷新完毕用户白天访问到的就是前一天最新数据的分析结果。监控这块我是给采集任务加了一个简单的邮件告警如果单天采集量少于正常值的一定比例就发邮件提醒自己检查是不是平台反爬升级或者网络异常。这个细节看着不起眼但对长期运行的数据系统非常有用——数据源挂了你不一定第一时间知道等用户发现页面数据一直是旧的问题就大了。7. 常见问题与排查技巧实录7.1 采集端高频问题定位与解决我运行过程中遇到过几类典型问题整理成速查表供参考问题现象可能原因解决方案采集件数为0但无报错页面结构变化解析不到列表项打开网页对比div容器类名更新列表定位详情页返回验证码页面请求频率过高或Headers不完整降低DOWNLOAD_DELAY到8秒检查完整Headers数据入库但字段为空详情页字段名拿到的是空字符串打印整个li列表核对字段取值逻辑采集一段时间后请求全被拦截IP被临时限制暂停30分钟更换UA池减并数量有重复数据指纹去重未生效检查generate_fingerprint的字段顺序是否包含区分性字段这里最容易被忽视的是第二项——验证码页面不一定返回HTTP异常。有时状态码还是200只是页面内容变成了一段验证逻辑如果你的解析规则没做页面内容校验就会爬回来一堆无用数据而且不报错。我的处理办法是解析前先判断页面里是否包含目标容器类名没有就直接丢弃并打印日志。7.2 数据分析与可视化的常见陷阱可视化部分的踩坑记录也有价值我挑几个典型的散点图数据量过大导致卡顿。ECharts能承受的散点数量大约在5000个左右超过1万就会明显掉帧。解决办法是先按面积区间做聚合再画散点图或者加服务端抽样。地图坐标系数据对不上位置。这个问题多半是城市名称不匹配——Django后端存的是“上海”GeoJSON里的城市名可能是“上海市”。统一在数据接口层做一次城市名标准化映射别在前端做。价格字段类型混乱导致图表显示错乱。清洗时必须确保入库是浮点数如果原始字符串带上了“万”字画图时数字会直接错位。建议在清洗Pipeline里统一转换并做断言校验。统计口径不一致。同样是“平均单价”有的页面可能直接对所有房源求均值有的页面却按小区均价再平均两个数值差很多。全系统必须统一统计口径我在聚合工具类里统一封装了avg_unit_price所有页面都调同一个函数避免各写各的。7.3 让项目具备长期生命力的扩展方向这个项目做完之后我发现它完全可以继续扩展。想做文本分析的话可以把房源标题拿去做关键词提取找出买房人关注的卖点词频想做实时系统的话可以引入消息队列和流计算框架把每小时的新增房源做个实时下钻大屏想更深地玩机器学习的话可以拆一个“成交价预测”子模型出来再挂上户型图识别模型做视觉特征融合。我个人建议如果是为了找工作或简历展示项目做到现有程度已经足够体现全栈能力和数据分析功底。接下来可以按需补一两个亮点比如把预测模型的准确率优化过程整理成技术文章或者把部署过程写成文档同步在简历链接里。技术项目写到简历上重要的不只是结果还有你踩过坑、解决问题的过程那才是面试官真正感兴趣的东西。最后想说的话做完这个项目我最真实的体会是数据的价值不在于你爬了多少条而在于你能从多乱的数据里提炼出多清晰的信息。爬虫只是开始真正花时间的其实是清洗字段口径、调试接口、打磨前端细节这些不大起眼的部分。如果你也打算做一个类似的系统建议从单一城市开始先跑通全链路再横向扩展。每一步都记录下来踩过的坑就是你后面应对同类问题最大的底气。
