企业官网建设流程全解析

1. 项目概述：一套打通全链路的大数据实战系统

做大数据方向课程设计或者毕业设计的同学，应该都有一种共同的体会：单学一个组件不难，难的是把这些组件串在一起。Hadoop刚能跑通WordCount，又来了Spark；Spark的RDD、DataFrame还没折腾明白，前面还等着一个Web框架把数据展示出来。如果题目写作“基于大数据的XX数据可视化系统”，那意味着你至少要在一套系统里完成数据采集、分布式存储、离线计算、Web后端、可视化大屏五个环节，任何一环掉链子，整个系统都交付不了。

这套基于“Hadoop + Spark + Django”的运城市二手房价格数据可视化系统，正是这样一个典型的全栈大数据项目。它不只是一个简单的“查房价”网站，而是一条完整的数据流水线：先用爬虫把运城市各城区的二手房挂牌数据抓下来，存到HDFS上做分布式存储；再用Spark做ETL清洗和聚合统计，算出各区域均价、总价分布、面积区间、户型结构这些指标；最后通过Django搭建Web服务，把Spark分析好的结果写到MySQL，再通过ECharts渲染成可视化大屏。

适合谁来参考？两类人：一是正在做大数据方向课程设计、毕业设计的在校学生，这套系统的技术选型和项目结构比单纯写一个“Spring Boot + MySQL”的CRUD系统要高一个档次，答辩时能撑住场面；二是想快速了解“大数据项目到底怎么落地”的开发者，这套系统把分布式存储、分布式计算、Web后端、前端可视化串成了一条完整链路，比零散看文档更能建立整体认知。

我在做这类项目时最深的体会是：技术栈本身并不神秘，难点在于组件之间的配合方式和数据流转的闭环。这篇就把整个系统的架构拆解、环境搭建、数据处理、后端设计、大屏可视化，以及我实际调试过程中踩过的坑，全部记录下来，给后面做类似项目的同学一条尽量平坦的路。我踩过的坑你就不用再踩了。

2. 整体架构设计与技术选型逻辑

2.1 为什么是Hadoop + Spark + Django这个组合

先回答一个很现实的问题：一个二手房价格可视化系统，数据量可能也就几万到几十万条，真的需要用到Hadoop和Spark吗？单纯从功能出发，MySQL加一个Flask就能搞定。但如果这是课程设计或毕业设计，技术选型需要考虑的不是“够不够用”，而是“能不能体现出大数据处理的能力和流程”。

Hadoop在这个项目里承担的是分布式存储角色。爬虫采集到的原始数据先落到HDFS上，这样做有两个好处：一是数据源和计算过程解耦，原始数据不会因为后续处理出错就丢失；二是在答辩时可以明确展示“HDFS分布式存储”这个环节，说明数据如何在DataNode上冗余存储。Hadoop本身的计算能力MapReduce在这个项目里不是主角，因为MapReduce写起来太繁琐，处理结构化数据也不如Spark方便，所以计算任务交给Spark来做。

Spark负责的是数据处理与分析环节。相比MapReduce，Spark基于内存计算，写起来更简洁，而且DataFrame API处理结构化数据非常顺手。在房价数据场景里，需要做的聚合计算——按区域求均价、按户型统计数量、按面积段分桶——用Spark SQL一条SQL就能搞定，代码量比MapReduce少一个数量级。这一点在文档和答辩PPT里都是一个重要的加分项，因为它说明你做的是“用合适的工具做合适的事”，而不是为了用技术而用技术。

Django负责的是Web服务与可视化展示层。选Django而不选Flask，主要原因是Django自带Admin后台、ORM、模板引擎和完整的项目结构，适合快速搭建一个带管理功能的数据展示系统。在这个项目里，Django需要做的活并不重：从MySQL读取Spark算好的聚合结果，通过JSON接口把数据吐给前端，再用ECharts渲染大屏。Django自带的ORM让“查MySQL”这一步变得很省事，而且它的模板系统和静态文件管理在部署调试时比Flask更省心。

后端存储用了MySQL。这里需要说清楚一个分工：HDFS存的是原始数据，MySQL存的是Spark算好的结果数据。原始数据可能很大、很杂，不适合直接让Web服务去查；分析结果数据是结构化、轻量级的，放入MySQL后Django查询起来很快。这种“原始数据入分布式存储，计算结果入关系型数据库”的双层存储设计，在实际项目中非常常见，也是这套系统架构上最值得讲清楚的一点。

2.2 系统分层与数据流转设计

整套系统的分层结构，从上到下可以分成四层：

• 数据采集层：Python爬虫（Requests + BeautifulSoup或Scrapy）抓取运城市二手房挂牌数据，生成原始CSV/JSON文件
• 数据存储与计算层：原始文件上传到HDFS；Spark读取HDFS中的原始数据，做清洗和聚合分析，结果写入MySQL
• Web服务层：Django提供RESTful API接口和页面渲染，查询MySQL中的聚合结果
• 可视化展示层：前端页面基于ECharts实现数据可视化大屏，通过Ajax请求Django接口获取数据

数据流转的核心链路是：爬虫 → 原始数据文件 → HDFS → Spark清洗分析 → MySQL → Django API → ECharts可视化大屏。这套链路是闭环的，每一个环节的输入输出都是清晰的。

我在实际设计时，把Spark分析结果单独建了一张汇总表，而不是每查一次就实时跑一次Spark。原因很简单：Spark作业启动有固定开销，如果页面每次刷新都要触发一次Spark计算，性能会很差，而且Django和Spark的交互会变得很复杂。离线计算结果入库，Web层只做查询，这种“计算与展示分离”的模式，是这类数据可视化系统最稳妥的方案。

3. 环境搭建：Hadoop伪分布式与Spark部署实战

3.1 Hadoop伪分布式搭建的关键步骤

做课程设计或毕业设计时，很多同学的笔记本配置有限，不现实搭一个真正多节点的Hadoop集群。所以我推荐用Hadoop伪分布式模式（Pseudo-Distributed Mode），也就是在一台机器上模拟多个节点角色——NameNode、DataNode、SecondaryNameNode都跑在同一台机器上，配置文件上体现的是“每个节点都是localhost”。伪分布式模式在功能上覆盖了HDFS的存储、读取、写入、冗余机制等核心概念，用于课程设计完全够用。

具体配置时，需要修改Hadoop安装目录下的四个核心配置文件。core-site.xml中设置默认文件系统为HDFS地址，配置临时目录；hdfs-site.xml中设置副本数为1（伪分布式只有一个DataNode，副本设为1才能正常运行），并配置NameNode的HTTP访问端口；mapred-site.xml和yarn-site.xml分别是MapReduce框架和YARN资源调度的配置。

这些配置里面有一个关键的坑：JAVA_HOME路径。Hadoop启动脚本需要找到JDK路径，如果在hadoop-env.sh里没配好JAVA_HOME，启动时会报“JAVA_HOME is not set”的错误。我建议直接在hadoop-env.sh中硬编码JDK的绝对路径，不要用环境变量引用，因为某些版本的Hadoop脚本解析环境变量时会有兼容性问题。

配置完成后，需要先格式化NameNode（hdfs namenode -format），然后分别启动HDFS和YARN。格式化NameNode时要注意：这个操作会清空NameNode的数据目录，所以只能在第一次启动时执行，后面如果反复格式化，会导致DataNode的namespaceID和NameNode不一致，启动时会一直报错。这也是很多新手会踩的坑——启动报错了就去格式化一次，结果越格式化问题越多。

启动后用jps命令查看进程，正常情况下应该看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager这五个Java进程。这时可以在浏览器里访问50070端口（Hadoop 2.x）或9870端口（Hadoop 3.x）查看HDFS的Web界面，确认没有死节点。

3.2 Spark集群的部署模式选择

Spark的部署方式，在这个项目里建议用Local模式，也就是单机本地模式。很多同学会纠结“老师要求Spark集群怎么办”，但实际做项目时要分清：你需要的是“Spark能跑起来完成分析任务”，而不是“Spark跑在分布式集群上”这个形式。Local模式下，Spark会用本机的多线程模拟分布式执行，对课程设计来说，效果完全一样。

Spark安装相对Hadoop要简单一些。下载对应Hadoop版本的Spark安装包，解压后配置SPARK_HOME环境变量即可。如果Spark要读取HDFS上的文件，需要确保Spark的Hadoop版本和集群Hadoop版本匹配，具体方式是修改spark-env.sh中的SPARK_DIST_CLASSPATH，让它包含Hadoop的classpath。不配的话，Spark能启动，但读取HDFS文件时会报错。

这里有一个非常容易踩的版本匹配问题：Hadoop 2.x对应Spark 2.x一般没问题，但Hadoop 3.x和Spark 2.x组合时，直接用yarn模式或读取HDFS可能会遇到RPC协议不兼容的问题。我的建议是：如果用的Hadoop 3.x，就选Spark 3.x；如果用的Hadoop 2.x，Spark 2.4.x或Spark 3.x都可以，但优先选Spark 2.4.x，因为这套组合的文档最多，出问题也好查。

安装完后，用spark-shell验证一下能否读取HDFS上的文件。这一步非常关键，因为后面Spark分析的第一步就是从HDFS读取爬虫得到的原始数据文件。

3.3 Hadoop与Zookeeper整合的必要性

有些资料会提到Hadoop和Zookeeper整合，这个通常是在搭建HA高可用集群时才需要。如果是单节点伪分布式，完全不涉及Zookeeper。但有的课程题目或文档里会要求“Hadoop和Zookeeper整合”，这时候要理解它背后的场景：真实生产环境中，NameNode是单点故障，为了避免NameNode挂掉导致整个集群不可用，需要用Zookeeper来做NameNode的Active/Standby自动切换。

如果确实需要在项目里体现Zookeeper整合，可以单独部署一个Zookeeper集群（在单机上可以用伪分布式模式模拟三个Zookeeper节点），然后配置Hadoop的HA模式。但坦白说，这个配置复杂度高、调试难度大，如果题目没有硬性要求，建议不要主动给自己加这个负担。在答辩时能讲清楚“Zookeeper在Hadoop HA中负责分布式协调和故障自动切换”这个原理就够了，不一定要真的配一遍。

4. 数据采集与预处理：运城市二手房数据怎么做

4.1 爬虫方案设计与数据字段规划

做房价可视化系统的第一个关键问题：数据从哪来？常见渠道是爬取安居客、链家、贝壳找房这些平台的运城市二手房挂牌数据。这里要提示一点：爬虫行为需要遵守网站的Robots协议和《网络安全法》，控制爬取频率，不要对目标网站造成压力。课程设计场景下，数据量不需要很大，几千条到一两万条就足够支撑所有分析图表了。

我推荐用Requests + BeautifulSoup的组合，比Scrapy轻量，调试起来也更直观。爬取的典型字段包括：小区名称、所在区域（盐湖区、永济市、河津市、临猗县、万荣县等）、户型（几室几厅）、面积（平方米）、朝向、楼层、建造年份、挂牌总价（万元）和单价（元/平方米）。

这里要提前想清楚一个事：后续Spark分析时要按区域分组、按户型统计、按面积段分区间，所以字段设计必须提前预留好这些维度的粒度。比如“区域”字段不要存成“盐湖区人民路附近”这种带冗余信息的字符串，直接存标准的城区或县市名称，这样聚合计算时才不会因为字段取值混乱导致结果偏差。

数据清洗这一步虽然不起眼，但直接决定分析结果质量。真实爬取的数据大概率存在以下问题：面积字段里有“暂无数据”、价格字段有“面议”、同一个小区名称写成“运城恒大绿洲”和“恒大绿洲（运城）”两种写法。这些脏数据不处理，Spark算出来的均价一定是错的。

4.2 清洗规则的几个关键细节

我用Spark做清洗时，核心规则有这么几条：

• 价格字段（总价和单价）必须能转换为数值类型，转换失败的记录直接丢弃或置为空值
• 面积字段必须为正数且小于合理阈值（比如500平方米），超出范围的视为异常
• 区域字段必须属于预先定义的城市区域名单，不在名单中的归类为“其他”
• 户型字段格式统一为“X室X厅”，解析失败归为“未知户型”

这里有个细节要特别注意：在分布式计算里处理“脏数据”和单机处理不一样。Spark的算子是按分区分批处理的，你没法在一行数据里参照全局的统计值做过滤，所以要先把“需要全局参照的规则”拆成两步——第一步先做基础格式清洗，第二步基于第一步的结果做统计过滤。这个思路在后面对抗“为什么清洗结果和本地Python跑出来不一样”的困惑时很重要。

清洗完成后，把干净数据写回HDFS的另一个目录，同时用Spark SQL注册成临时视图，接下来就可以直接做聚合分析了。

5. Spark房价分析的核心逻辑与实现

5.1 指标体系设计与SQL实现

可视化大屏上放什么图表，取决于你能分析出什么指标。我设计的指标体系是这样考虑的：既有面向普通用户看房需求的指标（均价、总价分布），也有面向数据分析维度的指标（环比变化、区域对比），这样大屏的信息层次才丰富。

具体指标和对应SQL逻辑如下：

• 各区域二手房均价排行：按区域分组，求每平方米单价的平均值，降序排列
• 总价区间分布：把总价分桶，比如50万以下、50-80万、80-100万、100-150万、150万以上，统计每个桶里的房源数量
• 面积段与总价的关系：按面积分桶（90平以下、90-120平、120-144平、144平以上），求每个面积段的平均总价和平均单价
• 户型结构统计：按“几室”维度分组，统计各户型的房源数量和平均面积
• 各区总价中位数：中位数比均值更能反映真实价格水平，因为均值容易被极端值拉高

在Spark里用Spark SQL实现这些逻辑非常直观，本质就是标准SQL的GROUP BY和聚合函数组合。比如各区域均价这个指标，核心SQL是：

SELECT region, ROUND(AVG(unit_price), 2) AS avg_price FROM house_clean GROUP BY region ORDER BY avg_price DESC

总价区间分布需要用到CASE WHEN做分桶：

SELECT CASE WHEN total_price < 50 THEN '50万以下' WHEN total_price >= 50 AND total_price < 80 THEN '50-80万' WHEN total_price >= 80 AND total_price < 100 THEN '80-100万' WHEN total_price >= 100 AND total_price < 150 THEN '100-150万' ELSE '150万以上' END AS price_bucket, COUNT(*) AS cnt FROM house_clean GROUP BY price_bucket ORDER BY cnt DESC

这些SQL跑完后，把结果DataFrame通过JDBC写入MySQL的表里。写之前要注意MySQL建表时字段类型的设计：价格字段用DECIMAL，数量字段用INT，区域字段用VARCHAR并加索引，这样Django查询时效率才有保障。

5.2 从HDFS到MySQL的数据落库步骤

Spark计算结果写MySQL，我用的是Spark SQL的JDBC写入方式，代码套路如下：

result_df.write.mode("overwrite").jdbc( url="jdbc:mysql://localhost:3306/yc_house", table="region_avg_price", properties={"user": "root", "password": "123456"} )

写库时有几个细节值得注意。mode选择“overwrite”表示每次跑完分析都覆盖旧结果，这样数据同步逻辑简单；如果选“append”则每次会在表里追加一份新数据，大屏上的数字会变得很奇怪——同一区域会出现好几条均价记录。

另一个关键点是MySQL的时区设置。Spark JDBC连接MySQL时，如果MySQL的时区（serverTimezone）和Spark的时区不一致，可能会报“Could not parse as timestamp”之类的错，连接串里显式加上serverTimezone=Asia/Shanghai可以解决这个问题。

写完MySQL后，整个离线计算链路就打通了：HDFS里的原始数据，经过Spark清洗和聚合，最终变成了MySQL里几张结构清晰的结果表。接下来的工作重心，就从大数据处理转向Web应用开发了。

6. Django后端开发与API设计

6.1 Django项目结构与模型设计

Django在系统里的角色是Web后端，它不需要直接操作HDFS或Spark，只管读MySQL的结果表，然后用接口把数据给前端。我用Django创建了一个名为“house_analysis”的App，项目结构上重点管理两个东西：models.py中的ORM模型和views.py中的API视图函数。

因为MySQL中的表是Spark写入的，使用Django的inspectdb命令可以让Django自动生成对应的ORM模型：

python manage.py inspectdb > models.py

这一步非常省事，不用手写模型字段，生成的模型直接映射已有的表结构。但有个坑：Spark JDBC写入MySQL时，表名和字段名如果是全小写，inspectdb生成模型类时需要手动给每个类指定db_table名称，否则Django默认会在表名后面加“s”（因为ORM模型默认用复数表名），导致查询时找不到表。

模型设计方面，我的做法是保持轻量。每个表一个模型类，模型中不定义任何外键关系，因为分析师独立的统计结果集，不需要关联查询。Django ORM在这个场景里就是简单的“SELECT * FROM table”转换成对象列表，不需要复杂的关联映射。

数据库连接配置在settings.py的DATABASES中，只需要把ENGINE设为django.db.backends.mysql，然后填上数据库名、用户名、密码、HOST、PORT即可。

6.2 API接口设计与JSON返回格式规划

大屏前端用Ajax请求数据，接口返回格式统一用JSON。每个图表对应一个接口，这样做的好处是前后端职责清晰：后端只负责查数据转JSON，前端只负责把JSON渲染成图表。

我设计了这样几个接口：

• /api/region_avg_price：返回各区域均价列表，用于地图和柱状图
• /api/price_distribution：返回总价区间分布，用于饼图
• /api/area_price_relation：返回面积段与价格关系，用于散点图或条形图
• /api/house_type_stats：返回户型统计，用于饼图或玫瑰图
• /api/price_trend：返回按建造年份的价格趋势，用于折线图
• /api/overview_summary：返回总房源数、平均单价、最高总价等核心数字，用于大屏顶部数字卡片

接口实现上，用Django的JsonResponse直接返回字典或列表。为了减少前端解析的麻烦，返回格式统一设计为：

{ "code": 200, "data": [ {"region": "盐湖区", "avg_price": 6532.5}, {"region": "永济市", "avg_price": 5210.8} ] }

前端拿data字段里的数组直接就能塞给ECharts的series.data，不需要二次处理。这里有一个我在实际开发中反复调整的点：接口返回的字段名要和前端约定好，否则前端写死字段名后，后端一改字段名，图表全挂。建议把接口字段文档写清楚，或者直接在项目README中列出每个接口的返回示例。

6.3 Django Admin后台的配置技巧

Django自带Admin后台，在这个项目里可以用来管理MySQL结果表中的数据，方便调试时检查Spark计算结果是否正确。在admin.py中注册模型后，后台默认的列表显示不够友好，可以通过list_display配置要在列表中展示的字段：

@admin.register(RegionAvgPrice) class RegionAvgPriceAdmin(admin.ModelAdmin): list_display = ("region", "avg_price", "house_count")

后台还有一个实用的功能：直接查看SQL语句。Django的DEBUG模式下，每执行一次查询，页面底部会显示对应的SQL，这在排查“为什么接口查出来的数据和MySQL里查出来的不一样”这个问题时特别好用。

7. 可视化大屏设计与ECharts落地实现

7.1 大屏布局与视觉设计

可视化大屏的布局，我采用的是一种非常经典的管理驾驶舱布局：顶部一行放标题和核心KPI数字卡片；左侧一整列放区域均价柱状图和户型分布饼图；中间最显眼的位置放地图或核心区域均价图；右侧一整列放总价分布饼图和面积价格关系图；底部放价格趋势折线图。

大屏的视觉设计有几个关键细节。配色上不要用默认的ECharts蓝色，建议用深色背景加亮色数据的方案——大屏展示时深色背景更专业，亮色数据对比度高，视觉冲击力强。背景色用深蓝灰色系（#0f1c2e），图表主色用浅蓝和橙色系，这样的配色方案在做答辩演示时效果很好。

大屏页面的技术实现不用Vue或React这些重框架，直接用HTML + CSS + ECharts CDN引入即可。原因很简单：这个页面只需要加载若干图表，数据通过Ajax获取后填充，没有复杂的前端交互，引入框架反而拖慢加载。用静态HTML页面，Django只需要提供一个视图函数渲染模板，静态文件直接放Django的static目录，逻辑最简。

7.2 ECharts图表的适配与数据对接

每个图表初始化EChats实例的核心步骤是：先DOM容器初始化实例，再通过Ajax请求后端接口拿到数据，最后用setOption配置和填充数据。以区域均价地图为例，核心代码如下：

$.ajax({ url: "/api/region_avg_price", type: "GET", dataType: "json", success: function(res) { var chart = echarts.init(document.getElementById("regionChart")); chart.setOption({ tooltip: { trigger: "item" }, series: [{ type: "map", map: "yuncheng", data: res.data.map(function(item) { return { name: item.region, value: item.avg_price }; }) }] }); } });

这里有一个地图特殊处理的坑：运城市的行政区划地图，ECharts官方地图包里没有直接内置的“运城”地图GeoJSON。解决方式有两种：一是用ECharts的registerMap注册自定义GeoJSON地图数据，从网上下载运城市各区县GeoJSON后注册；二是放弃地图，用柱状图展示各区域均价，横向比较效果也很好。如果时间紧张，推荐方案二——地图注册和GeoJSON适配往往要花不少时间，而柱状图在一张大屏上完全够用。

ECharts图表自适应问题也需要提前处理。大屏的尺寸和普通网页不同，有可能在1920x1080的屏幕上展示，也有可能在1366x768的笔记本上调式。浏览器窗口大小变化后，图表不会自动跟着变，需要监听window.resize事件并调用每个图表的resize方法。但要注意一个问题：页面上的图表实例是各自独立的，resize时必须遍历所有图表实例逐一调用，否则部分图表会留下空白区域。

7.3 数据刷新的实时性设计

严格来说，这套系统是一个离线批处理架构，不是实时系统。Spark的计算结果是周期性更新的，比如每天跑一次或每周跑一次，MySQL里的数据不会秒级变化。但大屏页面上可以设计一个前端定时刷新机制，通过setInterval每60秒重新拉取一次接口数据，实现“准实时”的效果。

我在实际实现时这样处理的：把接口数据请求封装在一个初始化函数里，页面加载时调用一次，然后setInterval定时调用。每次请求拿到新数据后，用chart.setOption的第二个参数设置notMerge为true，这样ECharts会完全替换数据而不是合并旧数据，避免出现图表中残留上次数据的问题。

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

8.1 跨组件联调中的典型问题

整套系统涉及Hadoop、Spark、MySQL、Django四个组件，联调时问题最多的地方是数据流转边界。我把实际调试中遇到的典型问题整理成了一张速查表：

8.2 Spark任务调优的三个实用经验

第一个经验是控制初始分区数。Spark读取HDFS文件时，分区数取决于HDFS的Block数，伪分布式模式下Block大小通常设为128MB，一个几十MB的小文件只会产生1到2个分区，Spark并行度很低。这时用repartition或textFile的第二个参数显式指定分区数，比如6到8个分区，能让Spark更快跑完。

第二个经验是尽早做列裁剪。如果原始CSV有20个字段，而分析只需要其中5个，不要一上来就用整个DataFrame做groupBy。先用select选出需要的列，再进入聚合阶段。减少数据在网络和内存中的占用，对Spark作业的加速非常明显。这在写分析代码时是最容易实践的一招。

第三个经验与Spark UI监控有关。Spark自带Web UI（默认4040端口），里面可以看到每个Stage的耗时、Shuffle读写量、Executor的内存使用情况。排查某些分析为什么慢时，一定要学会看这个UI。很多同学跑完Spark任务从不看一眼监控页面，等于放弃了最重要的性能定位工具。

8.3 Django调试时被忽略的细节

Django开发环境默认开启DEBUG，这对调试很方便，但也带来一个坑：DEBUG模式下Django会捕获所有异常并显示详细错误页，但有些错误只有关闭DEBUG才能暴露出来。比如静态文件找不到、接口路径写错这类问题，在DEBUG模式下有时会出现“页面显示正常但控制台报404”的情况，容易被忽略。

还有CORS跨域问题。如果大屏前端是独立部署的（比如直接用Vite开发服务器访问Django接口），就需要在Django里配置跨域，安装django-cors-headers并加到MIDDLEWARE中。如果前端放在Django自己的static目录下，则不存在跨域问题。

另一个实用细节是Django的时区设置。settings.py中TIME_ZONE如果默认是UTC，而MySQL里的数据类型是DATETIME，查询返回的时间会比北京时间慢8小时。这个项目虽然主要展示聚合统计值，不怎么涉及具体时间字段，但如果后面要展示“近一个月价格变化趋势”，这个时区问题会直接影响折线图的数据正确性。建议建项目时就把TIME_ZONE设为Asia/Shanghai，USE_TZ设为False，省得后面踩坑。

9. 扩展思路：这套系统还能怎么升级

如果做完基础版本之后还有余力，或者想在答辩时展示更多亮点，可以把这套系统的几个方向做扩展。最值得做的是接入实时流数据处理：用Flume或Kafka持续接收新增的二手房挂牌数据，Spark Streaming或Structured Streaming做微批次实时计算，更新到大屏上的“最新房源动态”模块。这样系统的技术栈就从离线批处理扩展到实时流处理，层次又高了一层。

另一个扩展方向是预测分析。用Spark MLlib的线性回归或决策树，基于面积、户型、楼层、建造年份等特征训练房价预测模型，然后在系统中增加一个“估价工具”的交互模块：用户输入房源基本信息，系统调用训练好的模型输出预测价格。这会给系统增加一个非常出彩的“机器学习应用”亮点。

我自己在实际做类似项目时，还养成了一个习惯：把整个数据流水线封装成一个Shell脚本，从爬虫启动、数据上传HDFS、Spark提交作业、到最后刷新MySQL，一条命令全跑通。这在反复调试和最终答辩演示时特别省心——不用每次手动在四个终端窗口之间来回切换。把这套脚本写到项目的README文档里，也是文档质量的一个加分项。

最后我想说的是，做这类全栈大数据项目，技术难点并不是某一个组件有多深，而是组件之间协作时暴露出来的各种细节问题。把这些问题一个个记录下来，不仅是给自己的调试留个底，也能让后来的人少走很多弯路。这套系统做完之后，从Hadoop到Spark，从SQL到ECharts，全链路跑通的成就感，远不是写一个普通管理系统能比的。