大数据与LLM融合的农产品价格预测及推荐系统实战

前几年做毕业设计，大家还在纠结SSH框架还是Spring Boot，今年风向已经完全变了——别再只做一个CRUD管理系统了。如果你选了大数据方向，又想蹭上大模型的热度，这个选题值得认真看一下：Spark + Hadoop + Hive + LLM大模型 + Django的农产品价格预测/销量预测/推荐系统。我帮你把这个题目从头到尾拆透，给你一条能直接落地的技术路线，顺带把里面最容易踩的坑都标出来。

这个项目本质上是一个“数据中台 + 智能应用”的组合体。底层用Hadoop做分布式存储，Hive做数据仓库建模，Spark负责数据处理和模型训练，Django搭Web应用做可视化展示，LLM大模型承担智能交互和推荐解释。四个业务模型——价格预测、销量预测、农产品推荐、智能问答，全部围绕“智慧农业”这个真实业务场景展开。对这个题目有兴趣的同学，不管你是想做毕设还是想充实简历，这篇文章都值得你花10分钟读完。

1. 这个选题到底在做什么——整体方案与技术选型

1.1 技术栈组合的底层逻辑

先聊点实际的。很多同学看到Spark、Hadoop、Hive、LLM、Django这一长串名字就懵了——这么多东西凑在一起，到底谁负责干什么？我画个简单的分工你就清楚了。

Hadoop的核心是HDFS和YARN。HDFS解决的是“海量数据往哪里存”的问题，原始农产品数据、历史价格、销量记录、天气信息统统往里扔。YARN做资源调度，相当于大数据平台的“物业管家”。Hive是跑在Hadoop上的数据仓库工具，它最大的价值是把复杂的MapReduce计算变成SQL，你用类似MySQL的语法就能查几千万条数据。Spark则是一个更快的内存计算引擎，数据处理速度比MapReduce快几十倍到上百倍，同时它还自带机器学习库MLlib，可以直接跑推荐算法和时间序列预测模型。

Django是Python生态里最成熟的Web框架，负责把前面的数据成果变成可视化的界面——价格走势图、销量预测曲线、推荐列表，都是它在展示。LLM大模型就更直观了，用户可以直接在系统里问“今年3月山东黄瓜价格会涨吗”，大模型结合检索到的历史数据进行回答，这就把“被动看图表”升级成了“主动对话式分析”。

这个组合不是瞎堆技术。做毕业设计有个原则：技术栈要丰富，但每个技术必须承担明确的职责。评委问起来，你要能清楚说出每一个组件存在的理由，而不是“因为别人这么用所以我也用”。

1.2 系统架构与四个核心模块

完整的数据流向是这样的：数据采集层把农产品价格数据、销量数据、产地数据、天气数据采集进来，落到HDFS；Hive做ETL清洗，把脏数据、缺失值、异常值处理掉，生成结构化的宽表；Spark读取Hive表，一部分做特征工程和模型训练，把结果写回Hive或者MySQL；Django后端从MySQL或Hive读数据，通过ECharts渲染图表，同时调用LLM接口做问答服务；最终用户通过浏览器访问系统。

四个核心模块分别是：价格预测系统，基于历史价格数据预测未来一段时间的趋势，常用算法有ARIMA、Prophet和LSTM序列模型；销量预测系统，在价格预测基础上加入节假日、天气、促销活动等外部因素，用LightGBM或者XGBoost这类树模型效果往往更稳定；农产品推荐系统，基于协同过滤和用户行为做个性化推荐，比如根据用户常买的品类推荐组合商品；LLM智能问答，用大模型封装知识库和报表分析结果，支持自然语言查数据。

1.3 为什么这样选型：对比分析与取舍理由

先说说Django和Spring Boot的选择。如果你是纯Java技术栈，用Spring Boot确实顺滑，但问题是机器学习这块基本只能用Java重写，生态差太多。Python做数据处理和模型训练比Java方便太多，Django又是Python Web里生态最好的，自带Admin后台、ORM、认证体系，开发效率高，所以“Python + Django”是这一题的最佳方案。

再说Spark Streaming和Flink，很多同学纠结要不要上Flink。我的观点是：毕业设计别给自己找麻烦。Flink虽然流处理更强，但学习曲线陡，部署复杂，而且你的数据源基本都是离线的。用Spark就够用了，还能把批处理和机器学习统一在一个生态里。Hive和MySQL的分工也要说清楚：Hive处理海量历史数据、存明细数据，MySQL存结果数据、支撑Web查询。Hive查询延迟高，但不丢数据、能存海量数据；MySQL查询快，但单表数据量大了就吃力。数据库和数仓各司其职，这个设计思路写在论文里是加分项。

2. 数据底座搭建——Hadoop+Hive实战要点

2.1 Hadoop环境方案：伪分布式还是集群

这是第一个决定成败的点。很多教程一上来就让你搭三台机器的集群，我说句实在话，如果你的电脑内存低于16G，老老实实先做伪分布式。伪分布式就是一台机器上同时跑NameNode、DataNode、ResourceManager、NodeManager，所有进程都在本机，看起来像一台小集群。这对学习完全够用，因为你跑数据量最多也就几千万条，单机伪分布式处理起来没问题。

我在实际操练中推荐你用Docker方案。网上有现成的Hadoop镜像，比如bde2020/hadoop-namenode和bde2020/hadoop-datanode，一条docker-compose命令就能拉起整个集群。好处是隔离性好，不会把你电脑的全局环境搞得乱七八糟，迁移也方便。如果你非要自己从零搭建，建议参考“从零开始Hadoop安装和配置”的经典教程，重点注意三点：JDK版本要和Hadoop版本匹配（比如Hadoop 3.3.x要求JDK 8或11）、SSH免密登录必须通、core-site.xml和hdfs-site.xml的路径配置不能错。

集群起不来大概率就是一个原因——配置文件的路径写错了，或者datanode的clusterID冲突了。踩坑记录里我会单独讲这个问题。

2.2 Hive数仓建模与ETL清洗实操

数据入库之前，先要设计Hive的表结构。农产品价格数据，我建议按照星型模型建模。事实表存交易记录（价格、成交量、日期、品类ID、产地ID），维度表存品类信息（品类名称、单位、等级）、产地信息（产地名称、省份、气候带）、时间维度（年、月、日、节气）。这样设计的好处是查询的时候关联少、速度快，后续做汇聚统计也方便。

建表要特别注意分区策略。按日期做分区是最常规的，因为大部分分析都是按时间维度走的。建表语句对应的DDL操作要规范，比如：

CREATE TABLE IF NOT EXISTS agri_db.fact_price ( product_id BIGINT, origin_id BIGINT, price DECIMAL(8,2), volume BIGINT, dt STRING ) PARTITIONED BY (year STRING, month STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE;

ETL清洗这一步别急着写SQL，先做源数据分析。一个是缺失值处理，价格字段为空的话，用前一天同品类均价填充，千万不能直接删行，农产品价格有很强的时序连续性，删了行后面训练模型时会断档。另一个是异常值处理，价格不可能为负，也不可能突然从3块钱跳到30块，这类明显异常的数据要么剔除，要么用前后三天的均值平滑掉。Hive窗口函数在这里非常好用，像LAG、AVG配合PARTITION BY，一条SQL就能算出滑动均值。

2.3 数据处理的几个关键细节

在数据处理这层，有几个实操细节我想单独拿出来提。Hive里处理NULL和空字符串很容易混，空字符串长度是0但值不是NULL，查的时候要同时过滤。日期类型Hive默认是STRING，如果直接拿来和DATE类型比较会出问题，建议统一用DATE_FORMAT转换。DECIMAL类型在Hive 2.0以上版本才支持，旧版本用的是DOUBLE，精度会有问题，计价模型对精度很敏感，这点要注意。

还有分区字段的顺序。你在INSERT OVERWRITE的时候，分区字段值的顺序必须和建表语句一致，否则数据会进错分区。我当时就因为这个把3月份的数据写到了4月分区里，跑出来的预测曲线整整偏了一个月。

3. Spark核心：数据处理、特征工程与模型训练

3.1 Spark读取Hive数据的正确姿势

Spark和Hive的集成是重头戏，也是很多教程写得含糊的地方。先说结论：Spark读Hive表，本质上是通过访问Hive的元数据服务（Metastore）拿到表结构，然后去HDFS上读数据文件。所以配置的关键是把Hive的hive-site.xml拷到Spark的conf目录，并且在spark-env.sh里指定HADOOP_HOME和HIVE_HOME。

写代码的时候有个明显的坑。生产环境用Spark SQL读几千万条数据没问题，但你在本地做毕设，最好加个limit或者使用过滤条件，先看看数据结构再全量读。推荐用SparkSession的enableHiveSupport来初始化：

from pyspark.sql import SparkSession spark = SparkSession.builder \ .appName("AgriPricePredict") \ .config("spark.sql.warehouse.dir", "hdfs://localhost:9000/user/hive/warehouse") \ .enableHiveSupport() \ .getOrCreate() df = spark.sql("SELECT * FROM agri_db.fact_price WHERE year='2024'")

跑不起来基本就是三个原因：hive-site.xml不在Spark的classpath里、metastore服务没启动、spark.sql.warehouse.dir和Hive的默认路径不一致。排查顺序也按这个来。

3.2 特征工程：农产品价格预测的关键一环

读入数据之后，先别急着训练模型。做时间序列预测，特征工程决定上限。我总结了一套适合农产品业务场景的特征集，给你参考：

• 滞后特征：t-1天、t-3天、t-7天的价格，分别对应短期惯性、中期波动和周期性
• 滑动统计特征：过去7天、30天的均价、标准差、最高最低价，刻画价格波动幅度
• 日历特征：星期几、是否月初、是否月末、农历节气、节假日标记
• 外部特征：产地天气（温度、降雨量）、市场供应量、成交活跃度

冷季蔬菜和应季水果的特征权重差异很大，比如反季节蔬菜价格受天气影响就比应季水果大得多。做特征工程时，可以在业务层面解释清楚这些差异。

Spark MLlib的VectorAssembler把所有特征合并成一个向量：

from pyspark.ml.feature import VectorAssembler from pyspark.ml.regression import RandomForestRegressor feature_cols = ["lag_1", "lag_3", "lag_7", "rolling_avg_7", "rolling_std_7", "weekday", "is_holiday"] assembler = VectorAssembler(inputCols=feature_cols, outputCol="features") data = assembler.transform(df) rf = RandomForestRegressor(featuresCol="features", labelCol="price", numTrees=100) model = rf.fit(data)

3.3 时序预测模型选择与训练细节

价格预测这块，我建议你不要只做一个模型，而是构建一个对比实验。用ARIMA做传统时间序列基线，用Prophet做趋势分解基线，再用LSTM做深度学习方法，最后用哪个效果好用哪个。写论文的时候这个对比实验就是很大的亮点，“本研究对比了三种模型的预测效果，LSTM在RMSE上优于ARIMA约X%”这种结论非常打动评委。

具体到LSTM的实现，PyTorch或者TensorFlow都可以，但我更推荐PyTorch，因为动态图调试方便。训练的时候注意几点：数据归一化用MinMaxScaler，避免LSTM因为输入尺度问题收敛慢；时间步长设成7天，预测未来3天，不要一上来就预测30天，误差会大到没法看；用滑动窗口构造样本，样本量越大越好；验证集要用最后的20%数据，模拟真实的“用历史预测未来”的场景，不能用随机切分，否则会有数据泄漏。

销量预测的模型选型不太一样。销量往往不是平滑的时间序列，它受节假日、促销活动的冲击很大，LSTM在突刺型数据上效果反而不好。我的建议是用LightGBM做监督学习，把天气、节假日、促销标记、品类、月份全部做成特征，预测未来7天的销量。LightGBM对特征交互的捕捉能力很强，而且支持类别特征，训练速度也快。

4. Django应用层：系统落地与可视化展示

4.1 Django项目结构与数据流设计

后端这部分，Django的项目结构规划很重要。我建议分四个app：prices_pred（价格预测模块）、sales_pred（销量预测模块）、recommend（推荐模块）、chatbot（智能问答模块），再加上系统自带的auth做用户管理。

数据流是这样的：Spark训练好的模型保存到云存储或服务器路径，预测脚本定时运行，把结果写入MySQL中的predict_result表。Django后端通过ORM读MySQL，不需要直接访问Hive，因为Hive的延迟太高了，不适合实时Web请求。

关键就是ORM建模。一张价格预测结果表，一张销量预测结果表，一张推荐记录表，一张用户行为表。注意在预测结果表里加一个created_at字段，因为模型可能每天更新一次，前端要展示的是最新一次的预测结果。

4.2 预测结果可视化：用ECharts讲好数据故事

可视化是毕设答辩时的门面。推荐用ECharts，因为它的中文文档很全，图表类型丰富，而且支持异步加载数据。

价格预测页面做一张双折线图：历史实际价格和未来预测价格用不同颜色标识，中间用一个垂直标记线分隔，让评委一眼就能看出哪里是“已知的过去”，哪里是“预测的未来”。销量预测页面做成柱状图加热力图组合，按品类分组展示。推荐模块做一张力导向图，展现用户、农产品、品类之间的关联关系，视觉冲击力很强。

ECharts的数据直接从Django的API接口返回JSON，注意用DRF（Django REST Framework）做序列化和接口管理。接口设计遵循查询参数驱动，前端传品类ID和时间范围，后端返回对应的图数据。这样前后端联调的时候也省心。

4.3 推荐系统的工程实现细节

推荐模块在毕设里属于“锦上添花”但工作量不小的部分。我的建议是做一个混合推荐方案：基于用户的协同过滤作为主体，基于内容的推荐做补充。

具体实现步骤如下：

1. 用户行为埋点，记录用户点击、收藏、购买记录，存入Django的ORM表
2. 构建“用户-农产品”评分矩阵，点击1分、收藏2分、购买3分
3. 用Spark的ALS算法做矩阵分解，生成topN推荐列表
4. 当用户行为数据太少（冷启动）时，切换为基于内容的推荐——根据用户注册时选择的偏好品类，推荐同类目下价格区间相近的农产品

ALS训练代码在Spark MLlib里很简洁：

from pyspark.ml.recommendation import ALS als = ALS(userCol="user_id", itemCol="product_id", ratingCol="rating", coldStartStrategy="drop") model = als.fit(interactions) recommendations = model.recommendForAllUsers(10)

注意ALS冷启动策略要设为drop，否则预测时遇到没见过的用户或商品，会产生NaN值，MySQL写入的时候会报错，这个坑我踩过一次。

5. LLM大模型：让智慧农业真正“智能”

5.1 LLM接入方案对比

2025年了，LLM早就不是什么遥不可及的东西。做毕设有两条路线可以选：一是调用国内大模型API，比如智谱、百度千帆、阿里通义千问都有开放平台，注册后送免费额度，够你做实验用；二是本地部署开源模型，比如Qwen系列或者ChatGLM系列，通过Ollama之类的一键工具启动。

我建议毕设优先走API路线，省事、稳定，而且响应质量比本地小模型高很多。你只需要写一个统一的接口封装，把请求参数和返回结果处理好就够了。本地部署适合的是你后续想写“基于私有化部署的农业大模型”这种亮点。评委问起来“你这个大模型是怎么部署的”，你就能理直气壮地说“基于Ollama私有化部署Qwen模型，数据不出内网，保障数据安全”——这句话在论文里就是加分项。

5.2 智能农业问答：从“被动图表”到“主动分析”

LLM在你的系统里承担两件事。第一件是智能问答，第二件是推荐解说。先讲智能问答。你把农产品数据通过提示词工程封装成模板，让LLM成为一个农业数据分析助手。比如用户问“今年大蒜价格走势如何”，系统先从数据库里检索过去一年的大蒜价格统计数据，然后拼装成提示词发给大模型，这样大模型给出的回答就是有数据支撑的，而不是凭空瞎编。

大致流程是这样：

1. Django接收用户问题
2. 意图识别，判断是不是农业相关问题（可以做个简单的关键词匹配或者用LLM做分类）
3. 如果与农业相关，查询数据库取出对应农产品的统计数据
4. 拼装结构化提示词，调用LLM生成回答

这个方法也被叫做“检索增强生成”，核心思想是：LLM本身就是个嘴强王者，你得给它喂真实数据，它才能说出有价值的话。简历上写一个RAG项目，含金量远超普通的调用API。

5.3 推荐解说：给“推荐结果”一个让人信服的理由

推荐系统只返回一个列表，评委容易觉得“这不就是SQL查了一下吗”。加上LLM解说就不一样了。比如你推荐用户购买“山东红富士苹果”，LLM可以生成这样一段话：“根据您的购买偏好，您过去一个月常买水果类生鲜。近期红富士苹果价格指数稳定在7.2元/公斤，较上周下降3.6%，性价比处于近30天的高位。建议关注产地烟台的优质批次。”这种产品级的推荐文案，直接把你的系统逼格拉满。

实现上也不复杂，把推荐列表、商品价格、历史趋势作为模板变量传给LLM，用一段高质量的Prompt让模型生成推荐理由。

6. 全流程实操记录：从零启动到端到端联调

6.1 项目启动级步骤规划

所有准备就绪之后，给你一条完整的时间线，照着做一周内能跑通第一版。

第1天：搭Hadoop伪分布式环境（或者用Docker镜像拉起来）装好Hive，验证Hive能正常建表查数据。重点测试hdfs dfs -ls命令和hive命令是否正常。第2天：采集数据。推荐一个可靠渠道，去公开的农业数据平台抓历史价格数据，也可以自己构造模拟数据。关键是字段要尽量贴近真实场景，包括日期、品类、规格、价格、交易量、产地。数据量建议100万条以上，太少的话后面Hadoop和Spark的存在意义就体现不出来。第3天：Hive建库建表，写ETL脚本，把原始数据清洗后导入分区表。第4天：配置Spark和Hive集成，用Spark SQL跑通查询。然后开始写特征工程脚本，生成训练集。第5天：训练价格预测模型和销量预测模型，保存模型文件，跑一遍预测脚本，把结果写MySQL。第6天：搭Django工程，建四个app，配置DRF接口，连上MySQL读预测结果。写ECharts可视化页面。第7天：集成LLM API，写智能问答接口和推荐解说接口。联调前后端，把所有功能穿起来走一遍。

6.2 端到端联调的关键触点

整个流程里最容易出问题的触点，我把它们列出来，到时候逐个确认：

第一个触点是Hive表数据与Spark读取的一致性。Spark读Hive表时有自己的元数据缓存，Hive里改了表结构之后，Spark任务最好重启一下，或者用spark.sql("REFRESH TABLE xxx")刷新缓存，否则容易报找不到字段。

第二个触点是Spark模型保存与Django读取的路径问题。把模型保存到统一的models目录，Django侧用相对路径调用模型加载，不要写死绝对路径。我当时就是写死了一个本地路径，结果部署到服务器上全乱了。

第三个触点是MySQL与Hive的数据类型兼容。Hive里的DECIMAL，在MySQL里最好用DECIMAL映射，避免精度丢失。日期字段Hive用STRING，MySQL用DATE，在Django里做一次strptime转换。

7. 踩坑实录与常见问题排查方法

7.1 Hadoop和Hive的经典问题速查表

我把自己实操中遇到的典型问题和解决方案整理成了一张速查表，你可以直接收藏备用。

7.2 Django和接口联调的常见坑

Django这层的问题相对温和，但也不容小觑。第一个坑是CORS跨域。前端页面如果用Vue暴露在8080端口，Django在8000端口，跨域请求会被拦，需要用django-cors-headers配置。第二个坑是ORM查询性能。预测结果是几万条量级的话，用ORM没问题，但如果前端要求一次拉全年日粒度数据，建议接口里做聚合，用extra或者RawSQL走group by。第三个坑是时区问题。Django的settings里设置USE_TZ = True后，如果你往MySQL写的是带时区的时间而表字段是DATETIME，会隐式转换导致时间偏了8小时。

还有个容易被忽略的坑是静态文件的处理。ECharts的js库和自定义图表js，开发环境直接放在static目录没问题，如果后续要部署，务必用collectstatic命令收集一次，否则页面样式全丢。

7.3 LLM接口调用的注意事项

LLM接口这块，我提醒几个实用点。第一个是超时设置。大模型API的响应时间通常1到5秒，接口的HTTP请求一定要设超时，否则用户等太久容易心态爆炸。推荐用流式输出，前端就能打字机一样显示答案，体验大幅提升。第二个是Token成本控制。毕设虽然用量不大，但要注意提示词不要太长，每次调用前把数据裁剪一下，比如只查最近7天的数据。第三个是返回结果解析。大模型偶尔会输出格式错误，比如JSON里夹带解释文字，建议在做JSON解析时加一个异常兜底，让系统返回“抱歉，我暂时无法理解这个问题”。

8. 答辩亮点设计与后续扩展方向

8.1 如何把项目讲出深度

这套系统做完，答辩的基本盘已经很强了，但怎么把它讲出彩是门学问。我建议按“问题—解决方案—创新点”的叙事逻辑来组织陈述，别一上来就讲技术栈。先讲“农产品价格波动大、信息不对称严重、农户缺乏决策工具”，再讲“基于大数据的多源汇聚与智能分析可以解决问题”，然后落到你的系统怎么实现。

创新点是评委关注的重头，以下三点你可以展开：

第一，大数据与深度学习的结合。不是简单地把数据存到Hadoop里就完了，而是真正利用Hive做数据治理，Spark做特征工程，LSTM捕捉时序特征，这才是有深度的技术链路。

第二，LLM与传统系统的融合。传统推荐系统只给结果，你结合LLM生成带有数据依据的推荐解说，这是产品层面的创新。

第三，从“看数据”到“用数据”的跨越。系统不只是展示图表，还能回答问题、提供决策建议，这才是智慧农业的理想形态。

8.2 后续扩展建议

如果你做完毕设还有余力，或者想给简历再添一份亮点，可以扩展这几个方向：

实时数据接入。用Flume或者Kafka对接农产品交易市场的实时数据流，再通过Spark Streaming做短周期预测。技术宽度立刻上一个档次。模型服务化。把训练好的模型封装成MLflow或者ONNX格式，部署成独立的模型服务，Django通过gRPC调用。微服务化改造。把大数据模块、推荐模块、LLM模块拆成独立的服务。App端支持。写一个小程序端，让用户可以随时随地查菜价、收推荐。

我在做这套系统的时候感触很深。大数据和AI的交叉地带恰恰是产出价值最明显的地方，你不需要成为某一个方向的顶尖高手，但你要能把它们组合起来解决一个真实的问题。农产品价格预测、销量预测、推荐系统，每一个模块都是可以独立拿出来讲一整天的话题，但当它们组合在一个系统里的时候，评委看到的已经不是一个学生作业，而是一个有产品思维的作品。

最后分享一个小技巧：答辩前的演示环境一定要准备三台设备——主力笔记本跑Web页面，另一台备用机开好后端服务，第三台手机开热点防止现场网络出幺蛾子。我见过太多人倒在现场演示环节，本地环境好好的，一到答辩教室就连不上数据或者模型加载超时。预演时把所有服务都提前启动，把最常见的问题都预想一遍，你就能稳稳发挥出这套系统的真实水平。