企业官网建设流程全解析

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 数据库模型与字段抽象

数据库设计是容易被新手忽略的环节。我当时想的是：一套房源数据除了基本信息，还得支持按城市、城区、价格、面积多维度筛选分析，因此字段必须拆得足够细。最终落地的房源表核心字段包括：

这个表设计做对了一件事：把展示信息和分析维度分开存。比如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.py

items.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 = f"https://xxx.{city}.example.com/ershoufang/pg{page}/" yield Request(url, callback=self.parse_list, dont_filter=True) 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), callback=self.parse_detail, meta={"city": response.meta.get("city") or "sh"}, ) # 翻页逻辑：解析下一页地址，注意某些城市反爬严格，需要降低翻页频率 next_page = response.css("div.page-box a[class='next']::attr(href)").get() if next_page: yield Request(response.urljoin(next_page), callback=self.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("span+span::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_filter=True要谨慎用，分页地址如果每次都去重，爬到后面会跳过部分页；二是解析字段时最好都做空值兜底，页面结构一变，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/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.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.py

models.py里建了一个HouseInfo模型，字段跟前面爬虫里设计的数据库表一一对应。Model定义好之后，用Django自带的Migration生成数据库表，这个流程省了很多事。

from django.db import models class HouseInfo(models.Model): city = models.CharField(max_length=32) district = models.CharField(max_length=64) community_name = models.CharField(max_length=128) title = models.CharField(max_length=255) area = models.DecimalField(max_digits=10, decimal_places=2, null=True) total_price = models.DecimalField(max_digits=10, decimal_places=2, null=True) unit_price = models.DecimalField(max_digits=10, decimal_places=2, null=True) bedroom = models.IntegerField(null=True) bathroom = models.IntegerField(null=True) livingroom = models.IntegerField(null=True) orientation = models.CharField(max_length=32) listing_time = models.DateTimeField(null=True) crawl_time = models.DateTimeField(auto_now_add=True) source_url = models.CharField(max_length=255, unique=True) update_status = models.IntegerField(default=1) 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(city="sh", bucket="unit_price"): queryset = ( HouseInfo.objects.filter(city=city, unit_price__isnull=False) .values("district") .annotate(avg_price=Round(Avg("unit_price"), 2)) .order_by("-avg_price") ) return queryset

ECharts拿到这种结构，直接配置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、bathroom
• orientation（做label encoding）
• floor_level（映射成1/2/3）
• house_age
• district（做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_size=0.2, random_state=42 ) model = RandomForestRegressor( n_estimators=200, max_depth=20, min_samples_leaf=2, n_jobs=-1, random_state=42, ) 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_), key=lambda x: x[1], reverse=True, ) return model, importance

实测下来的结果，MAE大致在3000到5000元/平米的量级，R2在0.6到0.75之间。别太追求极端精度，房价预测这种任务本身就有很多无法结构化表达的因素——楼层视野、装修情况、学区属性，这些都没有体现在数据里。能用随机森林得到一个合理的区间预测，已经能说明特征工程和数据质量是过关的了。

5.2 模型结果到可视化呈现的闭环

模型训练好以后，我把特征重要性排序结果输出成一个JSON，交给前端画一个“特征重要性Top5”的横向柱状图。同时，模型预测的价格区间可以在地图上叠加展示，比如某个小区预测均价和实际挂牌均价的差值，用颜色深浅标识“价格洼地”和“价格高估”。

这块做完，项目才算真正把机器学习和可视化打通了，而不只是“训练了一个模型然后就扔在那里”。

6. 系统部署与性能优化策略

6.1 数据库容量规划与查询性能调优

我爬了五个主要城市的数据，累计房源总量在50万到80万条之间。对于MySQL来说，这个量级其实很轻松，但如果查询写得不好，照样会卡。我做的优化主要有这几个：

1. 热门字段建立组合索引，比如(city, district, total_price)。因为可视化页面按城市、城区筛选的频率极高，这类查询走索引就能秒出。
2. 聚合查询避免全表扫描。统计城区均价时，先按city过滤，再做分组聚合。
3. 大结果集接口做分页，前端用dataZoom控制可视范围，后端返回LIMIT 500。
4. 定时跑数据快照，生成统计结果表。每天的均价、挂牌量变化都查快照表，不查原始大表。

其中第4点效果最明显。有些页面要展示“近30天挂牌量走势”，如果每次都去查50万行的原始表，响应时间很难控制。但跑一个定时任务，每天凌晨把前一天各城区的汇总指标写入一张daily_stats表，前端查询走这张小表，毫秒级响应。

6.2 Django服务部署与静态资源处理

部署方面，我用的是常规的Nginx + uWSGI + Django组合。静态文件和媒体文件由Nginx直接提供，Django只处理动态请求。数据库连接池用Django内置的CONN_MAX_AGE参数，设置为60秒，减少反复建立数据库连接的开销。

另外有个容易忽略的坑：Django的DEBUG=False模式下，静态文件服务需要单独处理，如果你之前习惯用Django自带的runserver跑静态文件，部署时会发现所有CSS样式都没了。需要先在项目里执行一次collectstatic，把全部静态文件收集到一个统一目录，然后让Nginx指向这个目录。

6.3 定时调度与监控告警

爬虫采集和统计任务都需要定时执行。我用了系统自带的crontab，每天凌晨2点跑一次增量采集，凌晨4点跑一次数据快照统计，早上7点前所有数据刷新完毕，用户白天访问到的就是前一天最新数据的分析结果。

监控这块，我是给采集任务加了一个简单的邮件告警：如果单天采集量少于正常值的一定比例，就发邮件提醒自己检查是不是平台反爬升级或者网络异常。这个细节看着不起眼，但对长期运行的数据系统非常有用——数据源挂了你不一定第一时间知道，等用户发现页面数据一直是旧的，问题就大了。

7. 常见问题与排查技巧实录

7.1 采集端高频问题定位与解决

我运行过程中遇到过几类典型问题，整理成速查表供参考：

这里最容易被忽视的是第二项——验证码页面不一定返回HTTP异常。有时状态码还是200，只是页面内容变成了一段验证逻辑，如果你的解析规则没做页面内容校验，就会爬回来一堆无用数据，而且不报错。我的处理办法是：解析前先判断页面里是否包含目标容器类名，没有就直接丢弃并打印日志。

7.2 数据分析与可视化的常见陷阱

可视化部分的踩坑记录也有价值，我挑几个典型的：

1. 散点图数据量过大导致卡顿。ECharts能承受的散点数量大约在5000个左右，超过1万就会明显掉帧。解决办法是先按面积区间做聚合，再画散点图，或者加服务端抽样。

2. 地图坐标系数据对不上位置。这个问题多半是城市名称不匹配——Django后端存的是“上海”，GeoJSON里的城市名可能是“上海市”。统一在数据接口层做一次城市名标准化映射，别在前端做。

3. 价格字段类型混乱导致图表显示错乱。清洗时必须确保入库是浮点数，如果原始字符串带上了“万”字，画图时数字会直接错位。建议在清洗Pipeline里统一转换并做断言校验。

4. 统计口径不一致。同样是“平均单价”，有的页面可能直接对所有房源求均值，有的页面却按小区均价再平均，两个数值差很多。全系统必须统一统计口径，我在聚合工具类里统一封装了avg_unit_price，所有页面都调同一个函数，避免各写各的。

7.3 让项目具备长期生命力的扩展方向

这个项目做完之后，我发现它完全可以继续扩展。想做文本分析的话，可以把房源标题拿去做关键词提取，找出买房人关注的卖点词频；想做实时系统的话，可以引入消息队列和流计算框架，把每小时的新增房源做个实时下钻大屏；想更深地玩机器学习的话，可以拆一个“成交价预测”子模型出来，再挂上户型图识别模型，做视觉特征融合。

我个人建议，如果是为了找工作或简历展示，项目做到现有程度已经足够体现全栈能力和数据分析功底。接下来可以按需补一两个亮点：比如把预测模型的准确率优化过程整理成技术文章，或者把部署过程写成文档同步在简历链接里。技术项目写到简历上，重要的不只是结果，还有你踩过坑、解决问题的过程，那才是面试官真正感兴趣的东西。

最后想说的话

做完这个项目，我最真实的体会是：数据的价值不在于你爬了多少条，而在于你能从多乱的数据里提炼出多清晰的信息。爬虫只是开始，真正花时间的其实是清洗字段口径、调试接口、打磨前端细节这些不大起眼的部分。如果你也打算做一个类似的系统，建议从单一城市开始，先跑通全链路，再横向扩展。每一步都记录下来，踩过的坑就是你后面应对同类问题最大的底气。