去年帮一位学弟完成《基于DjangoSpark的南昌房价数据分析系统》这个毕业设计课题时我在他身上看到了很多人的影子Python基础还行会写爬虫也看过Django教程但是要把Django和Spark这两套东西整合成一个完整系统还要出源码、文档、跑通功能心里完全没底。这个课题最吸引人的地方在于它不是一个单纯的Web开发题也不是一个单纯的数据分析题而是要求你把采集、清洗、计算、存储、展示、预测这一整条链路串起来。说白了老师想看到的是一个“有数据价值”的系统而不是一个只会在浏览器里打印“Hello World”的CRUD项目。这篇文章我就以这个项目为蓝本把从选题拆解、数据采集、Spark计算、Django展示到远程调试和毕业论文写作的完整过程写出来。里面所有步骤都是实际操作过的踩过的坑也会一并交代。给两类人看一类是正在做类似毕业设计的学生另一类是想用DjangoSpark做点实际数据分析应用的开发者。看完之后你不仅知道代码怎么写更重要的是知道每一步为什么这样选遇到问题怎么排查。1. 为什么要做南昌房价分析选题背后的需求拆解1.1 毕业设计选题的真实考量很多人选课题时有一个误区“我要选一个新技术越酷越好”。实际上毕业设计的评分标准不是看技术名词多不多而是看系统能不能自圆其说、逻辑通不通、工作量足不足。我给他选“南昌房价数据分析”这个方向主要有三个判断第一房价数据是天然适合做数据分析的素材。每个房源都有区域、户型、面积、单价、总价、朝向、楼层等结构化字段能支撑统计分析和建模预测也方便做图表可视化。用户一看就懂老师答辩时也容易理解你做的东西有什么价值。第二南昌是一个数据规模适中的城市。相比北京上海几十万套房源南昌的挂牌房源量大概在一两万条左右。这个量级用Spark处理虽然不算“大数据”但足以体现分布式计算框架的优势——数据加载、聚合统计、特征工程这些操作写起来比Pandas更规范也更容易在论文中写出技术对比。如果数据量太小Spark就杀鸡用牛刀了答辩时会被问“你为什么不直接用Pandas”。第三Django负责Web端展示Spark负责数据处理两者天然形成一条清晰的技术链路。这让系统架构有了分层论文里“系统设计”一章好写图表展示也有了数据来源。1.2 系统要解决的四个核心问题在动手写代码前我们先把需求拆成几个明确的模块这样后面开发才有方向。这套系统需要解决的问题可以归纳为数据从哪里来南昌各区域的二手房房源数据需要采集还要保证字段完整、格式统一。数据怎么处理抓下来的数据存在缺失值、异常值、重复值需要清洗并转换成适合分析的格式。分析什么指标区域均价排行、价格分布区间、户型成交热度、面积与总价关系、价格趋势变化这些是用户最关心的维度。怎么展示结果用网页呈现图表和预测结果用户可以选择区域、户型等条件进行筛选直观看到南昌房价的整体情况。把这四个问题落到系统功能上就对应了数据采集模块、数据分析模块、可视化展示模块和价格预测模块。整个系统的开发就是围绕这四个模块展开的。1.3 技术栈确定的思路为什么是DjangoSpark确定技术栈时学弟一开始提的是“用Flask行不行”我说行但Django更合适。理由很实际Django自带ORM、Admin后台、用户认证、模板引擎这些对于毕业设计来说都是省事的功能。尤其是Admin后台可以直接用来管理爬取到的房源数据演示时给老师看后台界面会很加分这是Flask要额外写很多代码才能做到的。Spark这边用的是PySpark。选PySpark而不是Java/Scala版是因为整个项目都是Python写的维护成本低。PySpark的DataFrame API和Pandas高度相似熟悉Pandas的人学起来很快。同时Spark提供了MLlib机器学习库房价预测模型可以直接用线性回归实现不需要自己写梯度下降。系统整体架构是这样的爬虫采集南昌二手房数据清洗后存为CSV文件Spark读取CSV完成数据分析和模型训练将结果输出为JSON文件Django读取这些JSON文件通过接口返回给前端前端用ECharts渲染图表。整个链路清晰、数据流可追踪论文里画架构图也好画。提示这个架构里Spark不直接和Django通信而是采用“先算好、再读取”的方式。对毕业设计来说这样避免了两套服务互相等待的问题也降低了集成复杂度。2. 数据从哪里来南昌房价数据的采集与预处理2.1 房源数据源的选择与爬虫设计房价数据的来源当时考虑了以下几个贝壳找房、房天下、安居客还有一些房产中介网站。贝壳的数据质量最高字段最规范但反爬比较严格房源信息是动态加载的需要分析XHR接口这对新手来说成本偏高。房天下的数据结构相对简单静态HTML里就能拿到房源标题、价格、面积、楼层等关键字段对毕业设计来说足够用。考虑到学弟爬虫基础一般我建议他用requestsBeautifulSoup写一个静态页面的爬虫先保证数据量够用不追求爬取速度。爬虫的目标是抓取南昌各区域的二手房挂牌信息每个房源需要记录的字段有小区名称、所在区域、具体板块、户型几室几厅、面积、总价、单价、朝向、装修情况、楼层、建筑年代、挂牌时间。核心爬虫逻辑大概是这样的import time import requests from bs4 import BeautifulSoup headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 } base_url https://nanchang.xxx.com/ershoufang/pg{}/ house_list [] for page in range(1, 101): url base_url.format(page) resp requests.get(url, headersheaders, timeout15) if resp.status_code ! 200: break soup BeautifulSoup(resp.text, html.parser) items soup.select(.houseList li) # 选择器需要根据目标网站结构调整 for item in items: title item.select_one(.title).get_text(stripTrue) info item.select_one(.address).get_text( , stripTrue) total_price item.select_one(.totalPrice).get_text(stripTrue) unit_price item.select_one(.unitPrice).get_text(stripTrue) house_list.append({ title: title, info: info, total_price: total_price, unit_price: unit_price }) time.sleep(2) # 限速避免被封IP print(f共采集到 {len(house_list)} 条数据)写爬虫时有一个经验要分享结构化的正文数据往往伴随反爬策略比如页面里故意嵌入一些隐藏字段干扰解析或者IP访问频率过高直接封禁。解决方案一个是靠限速另一个是做好异常捕获单页解析失败不要中断整体流程记录下来继续下一页。我让学弟在代码里加了一个try-except出错时把页码写进日志跑完统一排查这是爬虫项目中很实用的处理方式。2.2 清洗规则字段补齐、异常过滤与统一口径爬下来的原始数据一般不能直接用。以总价和单价为例很多网站的单价写的是“12345元/平”里面有中文单位需要正则提取数字。再比如面积一栏偶尔出现“暂无数据”或者“别墅350平”这种带有干扰信息的文本。这些都要在清洗阶段统一处理。我总结了一套清洗规则去除重复根据房源标题、小区、户型、面积组成的唯一标识去重同一套房源若在多个页面重复出现只保留一条。字段标准化将总价、单价、面积中的文本统一为数值类型行政区名称统一为规范名称如“青山湖区”不能出现“青山湖”和“青山湖区”两种写法。异常值过滤单价低于2000元/平多半是车位或录入错误和高于50000元/平多为豪宅或数据异常直接剔除面积小于20平或大于300平的也做过滤。缺失值处理对于“建筑年代”“装修情况”等非核心字段的缺失用“未知”填充对于核心字段单价、面积缺失的整条删除。这一步看似不起眼但它直接决定了后面Spark分析结果的质量。我当时给他举了个例子如果没有做异常值过滤某些特殊房源单价可能高达10万/平直接把区域均价拉高图表上就会出现一个“尖刺”答辩时数据一拿出来就被老师质疑。2.3 数据落地格式CSV还是数据库清洗完的数据存成什么格式这也是一个很容易纠结的点。数据库用MySQL的好处是数据管理规范Django的ORM可以直接对接但问题是Spark读取MySQL需要额外装JDBC驱动配置起来多一步。考虑到毕业设计的数据量只有1~3万条直接存CSV完全可以满足需求而且Spark读取CSV非常方便Django读取JSON结果也很简单所以最终选择“CSV作为数据存储层”。这个选择还有个隐藏好处数据文件可以直接打进源码包交付评阅老师拿到代码后不需要配置数据库就能跑起来。对于远程调试和部署来说少一个环节就少一个出错的可能。3. Spark在项目中真正负责的部分3.1 评估需求后Spark的使用策略谈到Spark很多初学者会陷入一个误区把Spark当Pandas用写一堆循环处理数据。实际上Spark的优势主要体现在分布式计算和SQL式声明式操作上。在做这个项目前我对学弟采用了一个比较务实的策略Spark不负责爬虫也不负责做Web页面它只负责“从CSV读出数据执行清洗与聚合分析把结果写回JSON”以及“用MLlib做房价预测模型”这两件事。这样的划分让整个系统边界清晰爬虫只是准备数据Django只是展示数据Spark才是分析数据的核心。论文里写“基于Spark的南昌房价数据分析”这个标题才立得住。3.2 核心分析任务读取CSV与区域聚合Spark读取CSV时有一行代码的坑需要特别注意Spark默认不会把第一行当表头需要显式指定headerTrue同时中文编码需要指定encodingutf-8。如果这两个参数不写后续所有字段都会变成_c0这种默认列名数据内容也会出现乱码。读入之后我们就可以用DataFrame API做各种聚合分析。最核心的一个任务就是统计南昌各区域的二手房均价from pyspark.sql import SparkSession from pyspark.sql import functions as F spark SparkSession.builder.appName(nanchang_house_price).getOrCreate() df spark.read.csv( data/nanchang_house.csv, headerTrue, inferSchemaTrue, encodingutf-8 ) # 数据清洗 df df.dropDuplicates([title, area, total_price]) df df.filter(df[unit_price].between(2000, 50000)) df df.dropna(subset[region, unit_price, area]) # 区域均价排行 region_price df.groupBy(region).agg( F.round(F.avg(unit_price), 2).alias(avg_price), F.count(*).alias(house_count) ).orderBy(F.desc(avg_price)) region_price.show()在MapReduce时代groupByavg这样的操作需要自己设计shuffle逻辑但在Spark里一个DataFrame API就完成了。对比着写论文会让“为什么选Spark”这个论点有支撑。除了区域均价我们还用Spark分析了几个不同维度的指标板块维度南昌每个行政区下的具体板块均价用于地图下钻展示。户型维度统计一室到五室以上各户型房源数量和平均面积看出供应结构。面积区间分布把面积分段60平以下、60-90平、90-120平、120-150平、150平以上统计每一段的房源数和均价。价格区间分布按总价区间统计楼盘数量帮助分析市场需求偏向。这些聚合逻辑本质上都是“分组聚合”只是分组的维度不同、聚合的字段不同。把结果统一写成JSON文件后Django直接读取前端用不同的图表类型展示即可。3.3 基于MLlib的房价预测模型价格预测是这个项目的加分项。很多同类型毕业设计只做到“统计展示”能结合机器学习做预测工作量就有了明显的提升。PySpark的MLlib里提供了LinearRegression用它来预测房源单价实际效果可以接受代码也不复杂。建模思路如下以面积、卧室数量、客厅数量、楼层序号、建筑年代作为特征以单价作为标签。首先用VectorAssembler把特征组装成向量列from pyspark.ml.feature import VectorAssembler from pyspark.ml.regression import LinearRegression feature_cols [area, bedrooms, hall, floor_index, building_age] assembler VectorAssembler(inputColsfeature_cols, outputColfeatures) df_feat assembler.transform(df) train, test df_feat.randomSplit([0.8, 0.2], seed42) lr LinearRegression(featureColfeatures, labelColunit_price) model lr.fit(train) pred model.transform(test) pred.select(unit_price, prediction).show()注意楼层和建筑年代这种字段最好对缺失值先填充再进模型不然VectorAssembler会报空值错误。另外线性回归对单位比较敏感面积是“平米”单位数值较大建筑年代是“1990”这种四位年份数值差异大可能导致收敛慢。实践中我们用标准化器StandardScaler把特征标准化效果会更好。预测模型的评估指标我们选择了RMSE均方根误差。最终模型在测试集上的表现大概是每平米的误差在两三千元以内作为毕业设计已经算是不错的结果。3.4 开发环境的Spark配置心得Spark在Windows笔记本上跑起来最容易让人崩溃的是环境配置。我们第一次在Windows上运行PySpark时报了一个找不到winutils.exe的错误。这个是Windows平台特有的问题Spark底层某些文件操作需要模拟Hadoop的Windows环境。解决办法很简单下载对应版本的winutils.exe放到一个目录下然后设置环境变量HADOOP_HOME指向该目录。另外Java版本也要注意Spark 3.x要求Java 8或Java 11如果本机装的是Java 17会有兼容性问题。我当时让学弟检查了一下发现他装的是Java 17换成Java 11之后问题立刻消失了。4. Django Web端的设计与实现4.1 项目结构怎么组织Django项目创建后默认会生成一个外层配置目录和manage.py入口文件。很多毕业设计的Web端代码就是在这个基础上随便堆几个app导致代码混乱。因为我们这个系统的展示功能比较集中我只建了一个核心app名字叫analysis负责所有页面渲染和接口返回。项目结构调整后大致长这样house_analysis/ ├── manage.py ├── config/ # 项目配置settings.py └── analysis/ # 核心业务app ├── views.py # 页面视图 ├── urls.py # 路由配置 ├── templates/ # HTML模板 ├── static/ # 前端静态资源 └── data/ # Spark输出的JSON结果这样一个结构在论文里画系统模块图时非常直观。数据文件放在app内部的data目录下views.py读取时就写相对路径部署时不会因为路径出错找不到文件。4.2 路由、视图与模板的配合方式Django的MVT模式中一次请求的处理流程是URL路由到视图函数视图函数读取数据并渲染模板或者返回JSON数据。本系统的页面有首页、区域分析页、趋势分析页、预测页等几个主要界面每个页面对应一个视图函数。比如说区域分析页的视图函数import json from django.shortcuts import render from django.http import JsonResponse from django.conf import settings BASE_DIR settings.BASE_DIR DATA_PATH BASE_DIR / analysis / data def region_page(request): return render(request, analysis/region.html) def region_api(request): with open(DATA_PATH / region_price.json, r, encodingutf-8) as f: data json.load(f) return JsonResponse({status: 0, data: data})这里有一个设计思路值得说明页面路由和接口路由是分开的。region_page只负责返回HTML页面页面中通过AJAX请求region_api获取数据。这样做的优势是前端ECharts可以直接用接口的数据更新图表刷新页面时不需要整页加载交互体验比模板渲染填充数据好得多也便于后续扩展新的图表。4.3 图表可视化方案选择ECharts而不是Highcharts图表库的选择上最终决定了ECharts。原因很简单ECharts是百度开源的项目中文文档完善案例丰富对地图的支持也很好。南昌的区域分布图可以直接用ECharts的map类型配合GeoJSON数据实现不需要自己画地图。前端核心代码大致是这样用了一个简单的AJAX请求获取接口数据$.getJSON(/analysis/region_api/, function (res) { var chart echarts.init(document.getElementById(regionChart)); chart.setOption({ tooltip: { trigger: axis }, xAxis: { data: res.data.map(d d.region) }, yAxis: { name: 均价元/平 }, series: [{ type: bar, data: res.data.map(d d.avg_price) }] }); });地图展示稍微复杂一点需要提前引入南昌各区划的GeoJSON文件。当时为了省事我用的是一种简化方案不是真正的地图而是用柱状图加区域名字展示“地图下钻”这种复杂交互在毕业设计里不是必须的老师更关注的是你有没有分析逻辑。4.4 前端页面的布局与交互页面整体风格走“数据看板”路线。顶部是系统标题和导航栏左侧一个筛选区域中间主体是图表区域。筛选条件包括行政区和户型选择后图表刷新。这块逻辑不复杂就是给图表接口加查询参数Django视图根据参数读取不同的JSON结果返回。为了演示效果好我给学弟加了一个对比功能选中两个行政区可以同时显示两个区的均价柱状图这样在答辩时可以说“系统支持多区域对比分析”。这个小功能虽然代码量不大但体现出来的“分析能力”不一样。5. 开发过程中踩过的坑和解决办法5.1 Spark本地运行的三大环境问题第一个坑就是前面提到的winutils.exe问题。跳过这一步系统会直接报SparkException。排查这个问题的思路要记住先看异常栈的Caused bySpark的报错信息非常长真正的根因往往在最后几行。第二个坑是Windows PowerShell下运行PySpark时控制台输出会出现大量重复日志这是Info级别日志刷屏。解决办法是在代码开头设置日志级别spark.sparkContext.setLogLevel(ERROR)第三个坑是SparkSession不要到处创建。PySpark在Windows上每次创建SparkSession都要重新初始化JVM环境耗时几秒到几十秒不等。如果Django的每个请求都创建一次系统响应会非常慢。我们的处理方式是Spark分析的结果全部落盘成JSONWeb端不直接调Spark这样Django运行期间完全不需要SparkSession存在。这是最稳妥的方案。5.2 中文编码与字段类型问题Spark读取CSV时如果文件中含有中文且未指定encodingutf-8默认会按UTF-8处理但一旦文件保存时是UTF-8-BOM格式第一列字段名就会出现一个前缀\ufeff。这个坑很隐蔽因为控制台打印数据看起来没太大问题但调用df.select(区域)时会报找不到列“区域”实际列名变成了“\ufeff区域”。排查方式也很经典打印df.columns一看到第一列名有特殊前缀就明白了。解决办法是保存CSV时统一用UTF-8无BOM格式或者在Spark读取时指定encodingutf-8并让爬虫保存文件时使用utf-8-sig编码进行兼容。我最终选择了后者因为某些Windows编辑器保存文件默认会加BOM统一转成无BOM反而多一步操作。字段类型的问题主要出在inferSchema上。Spark自动推断类型对基本数字没问题但像“总价”字段如果原始数据里有“暂无”这样的文本推断出来的字段类型会变成字符串后续做数值计算时就会报错。解决办法是在清洗阶段就把这些脏数据剔除保证进入Spark的数据要么是合法数字、要么是空值由dropna处理。5.3 ECharts图表数据格式与接口返回不匹配前端图表不显示是另一个高频率问题。最常见的原因是ECharts要求的数据格式是数组而Django JsonResponse返回的是字典套字典的结构。比如我的接口返回的是{status: 0, data: [{region: 青山湖区, avg_price: 13250}]}而代码里写的是res.data.region_name应该写res.data.map(d d.region)。这类问题本质上是对数据结构不熟悉。解决办法是在浏览器开发者工具的Network面板查看接口返回的原始JSON然后照着实际格式写前端取值逻辑。我在帮学弟调试时这一幕出现过三四次最后我让他养成一个习惯拿到接口先用浏览器直接访问一次看到JSON格式再写前端代码。5.4 响应速度优化与缓存策略系统刚做完时页面加载有延迟因为每次打开页面后端都要读取几个JSON文件再做处理。JSON文件每个可能有几百KB解析也需要时间。优化方案有两个第一把一些不会经常变化的数据接口改成读取Python的pickle序列化文件或者直接用Django的cache框架缓存到内存中。比如区域均价排行这种结果是Spark一次算好的完全可以放在缓存里第一次访问时读取并缓存后续请求直接命中缓存。第二前端图表数据一次性加载减少AJAX请求数量。原本区域分析和板块分析是两个接口后来合并为一个接口返回所有结果前端根据用户筛选条件切换显示不同的series交互响应明显快了很多。对于毕业设计这个数据量来说其实前端的渲染速度不会有太大瓶颈真正的瓶颈在于后端读取多个文件、解码JSON以及可能的多次请求。把所有相关数据合并到一个响应里是最简单有效的优化手段。6. 远程调试、部署交付与答辩准备6.1 远程调试的具体操作步骤这个课题交付时需要提供“远程调试”服务。实际操作中远程调试的最常用方式就是把项目部署到一台可以远程访问的服务器上然后老师和学生通过浏览器访问系统页面。我用的方案是买一台云服务器装好项目和依赖然后开启runserver监听。具体步骤服务器上安装Python 3.9、MySQL虽然数据存CSV但为了Doc文档展示系统能力还是装一下、JDK 11。使用pip安装项目依赖推荐用requirements.txt统一管理版本。将源码上传到服务器进入项目目录运行python manage.py migrate初始化数据库。运行python manage.py runserver 0.0.0.0:8000然后在云平台的安全组里放行8000端口。这样对方就能通过http://服务器IP:8000访问系统了。如果还需要改代码调试就用VS Code的Remote-SSH插件远程打开服务器上的源码目录。配置方法很直观安装Remote-SSH插件后添加新的SSH Host填入服务器IP、用户名和密码连接后左下角显示绿色对勾就能像本地开发一样写代码、运行和打断点。这里有一个经验远程调试时一定要先确认服务器上的Python环境和项目依赖一致否则会出现本地跑得好好的远程一跑就报ModuleNotFoundError的情况。最好在服务器上创建虚拟环境激活环境后安装依赖而不是直接用系统Python。6.2 两种部署方式与各自适用场景毕业设计交付时部署方式一般有测试部署和生产部署两种。测试部署就是上面说的runserver 0.0.0.0:8000简单直接适合演示和远程调试。但这种方式的缺陷是DEBUG模式下性能较差并且runserver是单进程的如果多人同时访问页面加载会变得很慢。更正式的部署是用uWSGInginx组合。uWSGI作为Django的应用服务器nginx作为反向代理处理静态文件并转发动态请求。这个过程稍微复杂一些但部署完成后访问体验和稳定性都好很多。如果时间来得及建议在论文的“系统部署”章节写一下这个方案显得更专业。我当时给学弟的建议是先搞定runserver模式的远程调试保证核心功能流畅演示然后再抽时间把nginxuWSGI部署方案写进文档但不要因为部署方式折腾太久毕业设计的核心还是系统功能本身的完整性。6.3 文档结构与答辩高频问题源码、文档和演示这三样东西里文档是最容易出问题的。很多学生把代码写完了论文最有一周才动笔结果写出来的文档和系统完全对不上。我建议的论文结构是摘要与关键词绪论背景、意义、国内外研究现状相关技术介绍Django、Spark、数据采集技术、ECharts系统需求分析功能性需求和非功能性需求系统设计总体架构、功能模块设计、数据库设计、数据流设计系统实现每个模块的截图和核心代码讲解系统测试功能测试与结果分析总结与展望答辩环节老师问的最多的几个问题整理后如下常见问题建议回答思路为什么用Spark而不用Pandas强调Spark的分布式计算能力、DataFrame API统一处理流程、MLlib对机器学习任务的集成支持同时说明当前数据量小主要用于走通大数据技术栈。RDD和DataFrame有什么区别DataFrame有Schema信息和查询优化器Catalyst执行效率更高RDD是底层数据抽象适合非结构化数据。房价预测模型的准确率评估用RMSE指标强调预测误差的绝对值和相对值承认模型局限性提出后续可用随机森林或XGBoost优化。数据是怎么获取的说明爬虫来源、采集字段、清洗规则、数据量规模强调遵守网站robots协议且数据仅用于学习研究。系统可扩展性怎么考虑数据量增大时可接入Spark集群和HDFSWeb端可扩展数据库存储等。6.4 交付前的最后检查远程调试服务交付前我们按照清单走了一遍检查流程功能模块是否都能正常访问、图表是否都能渲染、页面切换是否流畅、源码中的路径是否为相对路径、requirements.txt依赖是否完整、文档中的截图是否与当前系统界面一致。这一轮检查很值得做因为本地环境跑通了不代表交付到别的电脑上还能跑。依赖缺失、路径写死、端口冲突这些问题不亲自动手部署一遍根本发现不了。另外一个小技巧源码包里一定要附一个README或者部署说明文档写清楚Python版本、JDK版本、依赖安装命令、启动方式。这不仅是评分的要求也是对使用你源码的人负责。很多学生忽略了这一步结果老师拿到源码不知道怎么跑起来最终分数大受影响。7. 最后分享几点关于这个项目的实际体会整个项目做下来最让我意外的是SparkDjango这个组合并不难整合真正的难点在于“数据链路的完整性”。爬虫爬数据、清洗数据、分析建模、Web展示每一步单独拿出来都不难但串起来以后所有的环节都可能是坑编码错了、数据类型不对、接口格式不匹配、路径找不到。调试过程中80%的时间都花在这些看似琐碎的地方但解决一个坑学到的东西往往比照着教程敲一遍代码要多得多。如果你正在做类似的毕业设计课题我给一个务实的建议不要把注意力全放在技术栈炫不炫上先花时间把数据管道跑通也就是“数据从采集到图表能显示出来”这个最小闭环。一旦这个闭环跑通了后面加预测、加筛选、加对比都是很自然的增量。反之如果一上来就折腾模型调参、Spark集群配置很容易陷入环境问题里项目进展缓慢。数据闭环通了剩下的都是加分项。
基于Django+Spark的南昌房价数据分析系统实战解析
去年帮一位学弟完成《基于DjangoSpark的南昌房价数据分析系统》这个毕业设计课题时我在他身上看到了很多人的影子Python基础还行会写爬虫也看过Django教程但是要把Django和Spark这两套东西整合成一个完整系统还要出源码、文档、跑通功能心里完全没底。这个课题最吸引人的地方在于它不是一个单纯的Web开发题也不是一个单纯的数据分析题而是要求你把采集、清洗、计算、存储、展示、预测这一整条链路串起来。说白了老师想看到的是一个“有数据价值”的系统而不是一个只会在浏览器里打印“Hello World”的CRUD项目。这篇文章我就以这个项目为蓝本把从选题拆解、数据采集、Spark计算、Django展示到远程调试和毕业论文写作的完整过程写出来。里面所有步骤都是实际操作过的踩过的坑也会一并交代。给两类人看一类是正在做类似毕业设计的学生另一类是想用DjangoSpark做点实际数据分析应用的开发者。看完之后你不仅知道代码怎么写更重要的是知道每一步为什么这样选遇到问题怎么排查。1. 为什么要做南昌房价分析选题背后的需求拆解1.1 毕业设计选题的真实考量很多人选课题时有一个误区“我要选一个新技术越酷越好”。实际上毕业设计的评分标准不是看技术名词多不多而是看系统能不能自圆其说、逻辑通不通、工作量足不足。我给他选“南昌房价数据分析”这个方向主要有三个判断第一房价数据是天然适合做数据分析的素材。每个房源都有区域、户型、面积、单价、总价、朝向、楼层等结构化字段能支撑统计分析和建模预测也方便做图表可视化。用户一看就懂老师答辩时也容易理解你做的东西有什么价值。第二南昌是一个数据规模适中的城市。相比北京上海几十万套房源南昌的挂牌房源量大概在一两万条左右。这个量级用Spark处理虽然不算“大数据”但足以体现分布式计算框架的优势——数据加载、聚合统计、特征工程这些操作写起来比Pandas更规范也更容易在论文中写出技术对比。如果数据量太小Spark就杀鸡用牛刀了答辩时会被问“你为什么不直接用Pandas”。第三Django负责Web端展示Spark负责数据处理两者天然形成一条清晰的技术链路。这让系统架构有了分层论文里“系统设计”一章好写图表展示也有了数据来源。1.2 系统要解决的四个核心问题在动手写代码前我们先把需求拆成几个明确的模块这样后面开发才有方向。这套系统需要解决的问题可以归纳为数据从哪里来南昌各区域的二手房房源数据需要采集还要保证字段完整、格式统一。数据怎么处理抓下来的数据存在缺失值、异常值、重复值需要清洗并转换成适合分析的格式。分析什么指标区域均价排行、价格分布区间、户型成交热度、面积与总价关系、价格趋势变化这些是用户最关心的维度。怎么展示结果用网页呈现图表和预测结果用户可以选择区域、户型等条件进行筛选直观看到南昌房价的整体情况。把这四个问题落到系统功能上就对应了数据采集模块、数据分析模块、可视化展示模块和价格预测模块。整个系统的开发就是围绕这四个模块展开的。1.3 技术栈确定的思路为什么是DjangoSpark确定技术栈时学弟一开始提的是“用Flask行不行”我说行但Django更合适。理由很实际Django自带ORM、Admin后台、用户认证、模板引擎这些对于毕业设计来说都是省事的功能。尤其是Admin后台可以直接用来管理爬取到的房源数据演示时给老师看后台界面会很加分这是Flask要额外写很多代码才能做到的。Spark这边用的是PySpark。选PySpark而不是Java/Scala版是因为整个项目都是Python写的维护成本低。PySpark的DataFrame API和Pandas高度相似熟悉Pandas的人学起来很快。同时Spark提供了MLlib机器学习库房价预测模型可以直接用线性回归实现不需要自己写梯度下降。系统整体架构是这样的爬虫采集南昌二手房数据清洗后存为CSV文件Spark读取CSV完成数据分析和模型训练将结果输出为JSON文件Django读取这些JSON文件通过接口返回给前端前端用ECharts渲染图表。整个链路清晰、数据流可追踪论文里画架构图也好画。提示这个架构里Spark不直接和Django通信而是采用“先算好、再读取”的方式。对毕业设计来说这样避免了两套服务互相等待的问题也降低了集成复杂度。2. 数据从哪里来南昌房价数据的采集与预处理2.1 房源数据源的选择与爬虫设计房价数据的来源当时考虑了以下几个贝壳找房、房天下、安居客还有一些房产中介网站。贝壳的数据质量最高字段最规范但反爬比较严格房源信息是动态加载的需要分析XHR接口这对新手来说成本偏高。房天下的数据结构相对简单静态HTML里就能拿到房源标题、价格、面积、楼层等关键字段对毕业设计来说足够用。考虑到学弟爬虫基础一般我建议他用requestsBeautifulSoup写一个静态页面的爬虫先保证数据量够用不追求爬取速度。爬虫的目标是抓取南昌各区域的二手房挂牌信息每个房源需要记录的字段有小区名称、所在区域、具体板块、户型几室几厅、面积、总价、单价、朝向、装修情况、楼层、建筑年代、挂牌时间。核心爬虫逻辑大概是这样的import time import requests from bs4 import BeautifulSoup headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 } base_url https://nanchang.xxx.com/ershoufang/pg{}/ house_list [] for page in range(1, 101): url base_url.format(page) resp requests.get(url, headersheaders, timeout15) if resp.status_code ! 200: break soup BeautifulSoup(resp.text, html.parser) items soup.select(.houseList li) # 选择器需要根据目标网站结构调整 for item in items: title item.select_one(.title).get_text(stripTrue) info item.select_one(.address).get_text( , stripTrue) total_price item.select_one(.totalPrice).get_text(stripTrue) unit_price item.select_one(.unitPrice).get_text(stripTrue) house_list.append({ title: title, info: info, total_price: total_price, unit_price: unit_price }) time.sleep(2) # 限速避免被封IP print(f共采集到 {len(house_list)} 条数据)写爬虫时有一个经验要分享结构化的正文数据往往伴随反爬策略比如页面里故意嵌入一些隐藏字段干扰解析或者IP访问频率过高直接封禁。解决方案一个是靠限速另一个是做好异常捕获单页解析失败不要中断整体流程记录下来继续下一页。我让学弟在代码里加了一个try-except出错时把页码写进日志跑完统一排查这是爬虫项目中很实用的处理方式。2.2 清洗规则字段补齐、异常过滤与统一口径爬下来的原始数据一般不能直接用。以总价和单价为例很多网站的单价写的是“12345元/平”里面有中文单位需要正则提取数字。再比如面积一栏偶尔出现“暂无数据”或者“别墅350平”这种带有干扰信息的文本。这些都要在清洗阶段统一处理。我总结了一套清洗规则去除重复根据房源标题、小区、户型、面积组成的唯一标识去重同一套房源若在多个页面重复出现只保留一条。字段标准化将总价、单价、面积中的文本统一为数值类型行政区名称统一为规范名称如“青山湖区”不能出现“青山湖”和“青山湖区”两种写法。异常值过滤单价低于2000元/平多半是车位或录入错误和高于50000元/平多为豪宅或数据异常直接剔除面积小于20平或大于300平的也做过滤。缺失值处理对于“建筑年代”“装修情况”等非核心字段的缺失用“未知”填充对于核心字段单价、面积缺失的整条删除。这一步看似不起眼但它直接决定了后面Spark分析结果的质量。我当时给他举了个例子如果没有做异常值过滤某些特殊房源单价可能高达10万/平直接把区域均价拉高图表上就会出现一个“尖刺”答辩时数据一拿出来就被老师质疑。2.3 数据落地格式CSV还是数据库清洗完的数据存成什么格式这也是一个很容易纠结的点。数据库用MySQL的好处是数据管理规范Django的ORM可以直接对接但问题是Spark读取MySQL需要额外装JDBC驱动配置起来多一步。考虑到毕业设计的数据量只有1~3万条直接存CSV完全可以满足需求而且Spark读取CSV非常方便Django读取JSON结果也很简单所以最终选择“CSV作为数据存储层”。这个选择还有个隐藏好处数据文件可以直接打进源码包交付评阅老师拿到代码后不需要配置数据库就能跑起来。对于远程调试和部署来说少一个环节就少一个出错的可能。3. Spark在项目中真正负责的部分3.1 评估需求后Spark的使用策略谈到Spark很多初学者会陷入一个误区把Spark当Pandas用写一堆循环处理数据。实际上Spark的优势主要体现在分布式计算和SQL式声明式操作上。在做这个项目前我对学弟采用了一个比较务实的策略Spark不负责爬虫也不负责做Web页面它只负责“从CSV读出数据执行清洗与聚合分析把结果写回JSON”以及“用MLlib做房价预测模型”这两件事。这样的划分让整个系统边界清晰爬虫只是准备数据Django只是展示数据Spark才是分析数据的核心。论文里写“基于Spark的南昌房价数据分析”这个标题才立得住。3.2 核心分析任务读取CSV与区域聚合Spark读取CSV时有一行代码的坑需要特别注意Spark默认不会把第一行当表头需要显式指定headerTrue同时中文编码需要指定encodingutf-8。如果这两个参数不写后续所有字段都会变成_c0这种默认列名数据内容也会出现乱码。读入之后我们就可以用DataFrame API做各种聚合分析。最核心的一个任务就是统计南昌各区域的二手房均价from pyspark.sql import SparkSession from pyspark.sql import functions as F spark SparkSession.builder.appName(nanchang_house_price).getOrCreate() df spark.read.csv( data/nanchang_house.csv, headerTrue, inferSchemaTrue, encodingutf-8 ) # 数据清洗 df df.dropDuplicates([title, area, total_price]) df df.filter(df[unit_price].between(2000, 50000)) df df.dropna(subset[region, unit_price, area]) # 区域均价排行 region_price df.groupBy(region).agg( F.round(F.avg(unit_price), 2).alias(avg_price), F.count(*).alias(house_count) ).orderBy(F.desc(avg_price)) region_price.show()在MapReduce时代groupByavg这样的操作需要自己设计shuffle逻辑但在Spark里一个DataFrame API就完成了。对比着写论文会让“为什么选Spark”这个论点有支撑。除了区域均价我们还用Spark分析了几个不同维度的指标板块维度南昌每个行政区下的具体板块均价用于地图下钻展示。户型维度统计一室到五室以上各户型房源数量和平均面积看出供应结构。面积区间分布把面积分段60平以下、60-90平、90-120平、120-150平、150平以上统计每一段的房源数和均价。价格区间分布按总价区间统计楼盘数量帮助分析市场需求偏向。这些聚合逻辑本质上都是“分组聚合”只是分组的维度不同、聚合的字段不同。把结果统一写成JSON文件后Django直接读取前端用不同的图表类型展示即可。3.3 基于MLlib的房价预测模型价格预测是这个项目的加分项。很多同类型毕业设计只做到“统计展示”能结合机器学习做预测工作量就有了明显的提升。PySpark的MLlib里提供了LinearRegression用它来预测房源单价实际效果可以接受代码也不复杂。建模思路如下以面积、卧室数量、客厅数量、楼层序号、建筑年代作为特征以单价作为标签。首先用VectorAssembler把特征组装成向量列from pyspark.ml.feature import VectorAssembler from pyspark.ml.regression import LinearRegression feature_cols [area, bedrooms, hall, floor_index, building_age] assembler VectorAssembler(inputColsfeature_cols, outputColfeatures) df_feat assembler.transform(df) train, test df_feat.randomSplit([0.8, 0.2], seed42) lr LinearRegression(featureColfeatures, labelColunit_price) model lr.fit(train) pred model.transform(test) pred.select(unit_price, prediction).show()注意楼层和建筑年代这种字段最好对缺失值先填充再进模型不然VectorAssembler会报空值错误。另外线性回归对单位比较敏感面积是“平米”单位数值较大建筑年代是“1990”这种四位年份数值差异大可能导致收敛慢。实践中我们用标准化器StandardScaler把特征标准化效果会更好。预测模型的评估指标我们选择了RMSE均方根误差。最终模型在测试集上的表现大概是每平米的误差在两三千元以内作为毕业设计已经算是不错的结果。3.4 开发环境的Spark配置心得Spark在Windows笔记本上跑起来最容易让人崩溃的是环境配置。我们第一次在Windows上运行PySpark时报了一个找不到winutils.exe的错误。这个是Windows平台特有的问题Spark底层某些文件操作需要模拟Hadoop的Windows环境。解决办法很简单下载对应版本的winutils.exe放到一个目录下然后设置环境变量HADOOP_HOME指向该目录。另外Java版本也要注意Spark 3.x要求Java 8或Java 11如果本机装的是Java 17会有兼容性问题。我当时让学弟检查了一下发现他装的是Java 17换成Java 11之后问题立刻消失了。4. Django Web端的设计与实现4.1 项目结构怎么组织Django项目创建后默认会生成一个外层配置目录和manage.py入口文件。很多毕业设计的Web端代码就是在这个基础上随便堆几个app导致代码混乱。因为我们这个系统的展示功能比较集中我只建了一个核心app名字叫analysis负责所有页面渲染和接口返回。项目结构调整后大致长这样house_analysis/ ├── manage.py ├── config/ # 项目配置settings.py └── analysis/ # 核心业务app ├── views.py # 页面视图 ├── urls.py # 路由配置 ├── templates/ # HTML模板 ├── static/ # 前端静态资源 └── data/ # Spark输出的JSON结果这样一个结构在论文里画系统模块图时非常直观。数据文件放在app内部的data目录下views.py读取时就写相对路径部署时不会因为路径出错找不到文件。4.2 路由、视图与模板的配合方式Django的MVT模式中一次请求的处理流程是URL路由到视图函数视图函数读取数据并渲染模板或者返回JSON数据。本系统的页面有首页、区域分析页、趋势分析页、预测页等几个主要界面每个页面对应一个视图函数。比如说区域分析页的视图函数import json from django.shortcuts import render from django.http import JsonResponse from django.conf import settings BASE_DIR settings.BASE_DIR DATA_PATH BASE_DIR / analysis / data def region_page(request): return render(request, analysis/region.html) def region_api(request): with open(DATA_PATH / region_price.json, r, encodingutf-8) as f: data json.load(f) return JsonResponse({status: 0, data: data})这里有一个设计思路值得说明页面路由和接口路由是分开的。region_page只负责返回HTML页面页面中通过AJAX请求region_api获取数据。这样做的优势是前端ECharts可以直接用接口的数据更新图表刷新页面时不需要整页加载交互体验比模板渲染填充数据好得多也便于后续扩展新的图表。4.3 图表可视化方案选择ECharts而不是Highcharts图表库的选择上最终决定了ECharts。原因很简单ECharts是百度开源的项目中文文档完善案例丰富对地图的支持也很好。南昌的区域分布图可以直接用ECharts的map类型配合GeoJSON数据实现不需要自己画地图。前端核心代码大致是这样用了一个简单的AJAX请求获取接口数据$.getJSON(/analysis/region_api/, function (res) { var chart echarts.init(document.getElementById(regionChart)); chart.setOption({ tooltip: { trigger: axis }, xAxis: { data: res.data.map(d d.region) }, yAxis: { name: 均价元/平 }, series: [{ type: bar, data: res.data.map(d d.avg_price) }] }); });地图展示稍微复杂一点需要提前引入南昌各区划的GeoJSON文件。当时为了省事我用的是一种简化方案不是真正的地图而是用柱状图加区域名字展示“地图下钻”这种复杂交互在毕业设计里不是必须的老师更关注的是你有没有分析逻辑。4.4 前端页面的布局与交互页面整体风格走“数据看板”路线。顶部是系统标题和导航栏左侧一个筛选区域中间主体是图表区域。筛选条件包括行政区和户型选择后图表刷新。这块逻辑不复杂就是给图表接口加查询参数Django视图根据参数读取不同的JSON结果返回。为了演示效果好我给学弟加了一个对比功能选中两个行政区可以同时显示两个区的均价柱状图这样在答辩时可以说“系统支持多区域对比分析”。这个小功能虽然代码量不大但体现出来的“分析能力”不一样。5. 开发过程中踩过的坑和解决办法5.1 Spark本地运行的三大环境问题第一个坑就是前面提到的winutils.exe问题。跳过这一步系统会直接报SparkException。排查这个问题的思路要记住先看异常栈的Caused bySpark的报错信息非常长真正的根因往往在最后几行。第二个坑是Windows PowerShell下运行PySpark时控制台输出会出现大量重复日志这是Info级别日志刷屏。解决办法是在代码开头设置日志级别spark.sparkContext.setLogLevel(ERROR)第三个坑是SparkSession不要到处创建。PySpark在Windows上每次创建SparkSession都要重新初始化JVM环境耗时几秒到几十秒不等。如果Django的每个请求都创建一次系统响应会非常慢。我们的处理方式是Spark分析的结果全部落盘成JSONWeb端不直接调Spark这样Django运行期间完全不需要SparkSession存在。这是最稳妥的方案。5.2 中文编码与字段类型问题Spark读取CSV时如果文件中含有中文且未指定encodingutf-8默认会按UTF-8处理但一旦文件保存时是UTF-8-BOM格式第一列字段名就会出现一个前缀\ufeff。这个坑很隐蔽因为控制台打印数据看起来没太大问题但调用df.select(区域)时会报找不到列“区域”实际列名变成了“\ufeff区域”。排查方式也很经典打印df.columns一看到第一列名有特殊前缀就明白了。解决办法是保存CSV时统一用UTF-8无BOM格式或者在Spark读取时指定encodingutf-8并让爬虫保存文件时使用utf-8-sig编码进行兼容。我最终选择了后者因为某些Windows编辑器保存文件默认会加BOM统一转成无BOM反而多一步操作。字段类型的问题主要出在inferSchema上。Spark自动推断类型对基本数字没问题但像“总价”字段如果原始数据里有“暂无”这样的文本推断出来的字段类型会变成字符串后续做数值计算时就会报错。解决办法是在清洗阶段就把这些脏数据剔除保证进入Spark的数据要么是合法数字、要么是空值由dropna处理。5.3 ECharts图表数据格式与接口返回不匹配前端图表不显示是另一个高频率问题。最常见的原因是ECharts要求的数据格式是数组而Django JsonResponse返回的是字典套字典的结构。比如我的接口返回的是{status: 0, data: [{region: 青山湖区, avg_price: 13250}]}而代码里写的是res.data.region_name应该写res.data.map(d d.region)。这类问题本质上是对数据结构不熟悉。解决办法是在浏览器开发者工具的Network面板查看接口返回的原始JSON然后照着实际格式写前端取值逻辑。我在帮学弟调试时这一幕出现过三四次最后我让他养成一个习惯拿到接口先用浏览器直接访问一次看到JSON格式再写前端代码。5.4 响应速度优化与缓存策略系统刚做完时页面加载有延迟因为每次打开页面后端都要读取几个JSON文件再做处理。JSON文件每个可能有几百KB解析也需要时间。优化方案有两个第一把一些不会经常变化的数据接口改成读取Python的pickle序列化文件或者直接用Django的cache框架缓存到内存中。比如区域均价排行这种结果是Spark一次算好的完全可以放在缓存里第一次访问时读取并缓存后续请求直接命中缓存。第二前端图表数据一次性加载减少AJAX请求数量。原本区域分析和板块分析是两个接口后来合并为一个接口返回所有结果前端根据用户筛选条件切换显示不同的series交互响应明显快了很多。对于毕业设计这个数据量来说其实前端的渲染速度不会有太大瓶颈真正的瓶颈在于后端读取多个文件、解码JSON以及可能的多次请求。把所有相关数据合并到一个响应里是最简单有效的优化手段。6. 远程调试、部署交付与答辩准备6.1 远程调试的具体操作步骤这个课题交付时需要提供“远程调试”服务。实际操作中远程调试的最常用方式就是把项目部署到一台可以远程访问的服务器上然后老师和学生通过浏览器访问系统页面。我用的方案是买一台云服务器装好项目和依赖然后开启runserver监听。具体步骤服务器上安装Python 3.9、MySQL虽然数据存CSV但为了Doc文档展示系统能力还是装一下、JDK 11。使用pip安装项目依赖推荐用requirements.txt统一管理版本。将源码上传到服务器进入项目目录运行python manage.py migrate初始化数据库。运行python manage.py runserver 0.0.0.0:8000然后在云平台的安全组里放行8000端口。这样对方就能通过http://服务器IP:8000访问系统了。如果还需要改代码调试就用VS Code的Remote-SSH插件远程打开服务器上的源码目录。配置方法很直观安装Remote-SSH插件后添加新的SSH Host填入服务器IP、用户名和密码连接后左下角显示绿色对勾就能像本地开发一样写代码、运行和打断点。这里有一个经验远程调试时一定要先确认服务器上的Python环境和项目依赖一致否则会出现本地跑得好好的远程一跑就报ModuleNotFoundError的情况。最好在服务器上创建虚拟环境激活环境后安装依赖而不是直接用系统Python。6.2 两种部署方式与各自适用场景毕业设计交付时部署方式一般有测试部署和生产部署两种。测试部署就是上面说的runserver 0.0.0.0:8000简单直接适合演示和远程调试。但这种方式的缺陷是DEBUG模式下性能较差并且runserver是单进程的如果多人同时访问页面加载会变得很慢。更正式的部署是用uWSGInginx组合。uWSGI作为Django的应用服务器nginx作为反向代理处理静态文件并转发动态请求。这个过程稍微复杂一些但部署完成后访问体验和稳定性都好很多。如果时间来得及建议在论文的“系统部署”章节写一下这个方案显得更专业。我当时给学弟的建议是先搞定runserver模式的远程调试保证核心功能流畅演示然后再抽时间把nginxuWSGI部署方案写进文档但不要因为部署方式折腾太久毕业设计的核心还是系统功能本身的完整性。6.3 文档结构与答辩高频问题源码、文档和演示这三样东西里文档是最容易出问题的。很多学生把代码写完了论文最有一周才动笔结果写出来的文档和系统完全对不上。我建议的论文结构是摘要与关键词绪论背景、意义、国内外研究现状相关技术介绍Django、Spark、数据采集技术、ECharts系统需求分析功能性需求和非功能性需求系统设计总体架构、功能模块设计、数据库设计、数据流设计系统实现每个模块的截图和核心代码讲解系统测试功能测试与结果分析总结与展望答辩环节老师问的最多的几个问题整理后如下常见问题建议回答思路为什么用Spark而不用Pandas强调Spark的分布式计算能力、DataFrame API统一处理流程、MLlib对机器学习任务的集成支持同时说明当前数据量小主要用于走通大数据技术栈。RDD和DataFrame有什么区别DataFrame有Schema信息和查询优化器Catalyst执行效率更高RDD是底层数据抽象适合非结构化数据。房价预测模型的准确率评估用RMSE指标强调预测误差的绝对值和相对值承认模型局限性提出后续可用随机森林或XGBoost优化。数据是怎么获取的说明爬虫来源、采集字段、清洗规则、数据量规模强调遵守网站robots协议且数据仅用于学习研究。系统可扩展性怎么考虑数据量增大时可接入Spark集群和HDFSWeb端可扩展数据库存储等。6.4 交付前的最后检查远程调试服务交付前我们按照清单走了一遍检查流程功能模块是否都能正常访问、图表是否都能渲染、页面切换是否流畅、源码中的路径是否为相对路径、requirements.txt依赖是否完整、文档中的截图是否与当前系统界面一致。这一轮检查很值得做因为本地环境跑通了不代表交付到别的电脑上还能跑。依赖缺失、路径写死、端口冲突这些问题不亲自动手部署一遍根本发现不了。另外一个小技巧源码包里一定要附一个README或者部署说明文档写清楚Python版本、JDK版本、依赖安装命令、启动方式。这不仅是评分的要求也是对使用你源码的人负责。很多学生忽略了这一步结果老师拿到源码不知道怎么跑起来最终分数大受影响。7. 最后分享几点关于这个项目的实际体会整个项目做下来最让我意外的是SparkDjango这个组合并不难整合真正的难点在于“数据链路的完整性”。爬虫爬数据、清洗数据、分析建模、Web展示每一步单独拿出来都不难但串起来以后所有的环节都可能是坑编码错了、数据类型不对、接口格式不匹配、路径找不到。调试过程中80%的时间都花在这些看似琐碎的地方但解决一个坑学到的东西往往比照着教程敲一遍代码要多得多。如果你正在做类似的毕业设计课题我给一个务实的建议不要把注意力全放在技术栈炫不炫上先花时间把数据管道跑通也就是“数据从采集到图表能显示出来”这个最小闭环。一旦这个闭环跑通了后面加预测、加筛选、加对比都是很自然的增量。反之如果一上来就折腾模型调参、Spark集群配置很容易陷入环境问题里项目进展缓慢。数据闭环通了剩下的都是加分项。