Hadoop+Spark+Django咖啡店销售数据分析系统：毕设全链路实战解析

开头

每年毕设季，最怕的不是工作量，而是“题目太虚”。像什么“基于大数据的电商平台分析”“基于深度学习的图像识别系统”，听起来挺唬人，真做起来要么没数据，要么算力不够，要么做到一半发现自己根本没那个基础。今天推荐的这套题目——“Hadoop+Spark+Django咖啡店销售数据分析系统”，属于典型的“技术栈完整、数据好造、可视化出彩、论文好写”的四好题目。它把Python的数据处理能力、Hadoop的分布式存储、Spark的分布式计算、Django的Web展示串成了一条完整的分析流水线，再加上一小段机器学习销量预测，覆盖了数据分析类毕设要求的几乎所有关键能力点。

这套系统整体来说，难度中等偏上一点点，但没有故意刁难人的成分。你不需要一台多么夸张的服务器，不需要几千几万条真实电商数据，更不需要手写底层分布式算法。它要的是你能把整个数据流转的链路跑通：生成模拟的咖啡店销售数据，存到HDFS里，用Spark做清洗和聚合分析，把分析结果写回MySQL，最后在Django页面上以图表方式呈现。一句话概括，就是一个“小型数据中台+业务可视化”的完整闭环。这篇文章我会把选题逻辑、模块拆解、落地步骤、踩坑记录和论文答辩准备全部掰开揉碎讲清楚，如果你正在为毕业设计选题发愁，这篇可以拿来做直接参考。

1. 这个题目到底在做什么：一座三层结构的“小型数据中台”

先别急着看代码，先把系统的整体架构想明白。这个项目表面上叫“咖啡店销售分析”，本质上它是把“数据采集、存储、计算、展示”四个环节全部走了一遍。很多毕设题目只能覆盖其中一环——比如纯Django写个增删改查，或者纯Spark做个离线统计——但这套系统的价值就在于全链路。先从三层结构说起。

1.1 Hadoop、Spark、Django 各自扮演什么角色

这套技术栈里，每个框架都有明确的“定位”，它们之间不是竞争关系，而是上下游关系。

第一层是Hadoop。它负责的是存储，更准确地说，是存储“原始数据”。咖啡店的每一笔订单、每一种商品、每个门店的销售记录，这些原始数据在进入后续分析之前，先要有一个地方能统一放起来。HDFS（Hadoop分布式文件系统）就是做这个事的。你可能觉得，放着MySQL不用，为什么要多此一举上Hadoop？这就是毕业设计题目的“深度”所在。真实企业里，数据量一旦大到单机MySQL扛不住，就必须靠分布式存储来承载。咖啡店虽然只是一个业务场景，但你的技术架构是面向“大数据量设计”的——这正是评审老师想看的东西。

第二层是Spark。它负责的是计算。原始数据躺在HDFS里是一堆“脏乱差”的CSV或者JSON，没法直接拿来做报表。Spark的作用就是把这些数据读进来，做清洗（去重、补空值、格式统一），做聚合（按天、按门店、按品类计算销售额），做分析（时段热度、单品销量TopN、顾客消费频次），然后把处理好的结果写出去。很多初学者会问：Spark能做的，Pandas也能做，为什么要用Spark？问这个问题很正常，但答案是“场景不同”。Pandas处理的是“能装进内存”的数据，Spark处理的是“单机装不下”的数据。后端这里你哪怕只用了一台机器，但Spark的分布式计算模型是真的在按分布式方式运行的，这个技术底层逻辑必须讲清楚，论文里才站得住脚。

第三层是Django。它负责的是展示。分析结果最终要给人看，需要有一个Web页面——销量趋势折线图、品类占比饼图、时段热力图、门店排行，还要有按日期范围筛选的交互功能。Django做这些事非常快，MTV模式天生适合“数据查出来、塞进模板、渲染成图表”这种套路。而且Django自带的Admin后台还能帮你管理数据表，省了不少时间。

三层结构串成一句话就是：数据存进去，算出来，展示出去。你的整个毕业设计，就是围绕这个闭环做工程落地。

1.2 数据流向：从咖啡小票到可视化大屏的完整链路

设计好技术选型之后，最关键的环节就是定义数据流向。到底数据从哪里来，每一步处理完去了哪里，中间用了哪些数据库和接口，这张图在论文里一定是要画出来的。虽然不能画mermaid图，但我可以给你一个清晰的文字描述版本：

数据生成 → 写入MySQL → 同步到HDFS → Spark清洗与聚合 → 结果写回MySQL → Django查询并展示

第一步，用Python脚本模拟生成咖啡店的销售数据。数据字段通常包括：订单号、门店ID、门店名称、商品名称、商品类别（咖啡、饮品、甜点、轻食）、单价、数量、订单金额、下单时间、顾客ID等。模拟数据的关键是“像真的”——有随机波动，有节假日高峰，有周末效应，有几款爆品也有几款长期卖得不好的产品。生成后用pandas清洗一遍，然后写进MySQL的订单表。

第二步，把MySQL里的订单数据导出成CSV或者JSON，上传到HDFS的指定目录下。这块其实有一个技术点值得在论文里展开：为什么不在线同步，而是离线批量导出？因为Spark主攻的是“离线批量计算”，离线模式能最大程度简化数据一致性问题，也符合真实企业里“T+1数据同步”的常见做法。你如果能把“为什么选离线而不是实时”这个问题说清楚，答辩时就能加很多分。

第三步，用Spark SQL读取HDFS上的原始数据文件，做数据清洗和质量分析，然后按业务需求聚合出结果表。比如：

• 按日期统计销售额、订单量、客单价；
• 按时段（早上7点到晚上10点）统计销售分布；
• 按商品类别统计销量占比；
• 按门店统计销售排名；
• 计算复购率、消费频次等顾客维度指标。

这些结果表统一写到MySQL数据库里，为Django页面查询做准备。

第四步，Django后端通过ORM从MySQL里读取结果表，前端用ECharts等图表库把数据渲染成可视化图表。这里再强调一次：Django不直接读HDFS，也不直接调Spark处理结果，所有展示数据都从MySQL来。这个设计能让系统解耦，也让开发难度直线下降——你不需要在Web层处理分布式集群连接，只用处理最简单的关系型数据查询就够了。

2. 为什么这套技术栈适合毕设：选型逻辑与加分点拆解

很多同学选毕设题目的时候，其实根本没搞清楚“为什么选这套技术”，只是看别人用了所以我也用。这非常危险，因为答辩时老师最爱问的就是“为什么”。这一章，我把我对这套技术栈的理解和选择理由全部讲透，你论文的技术选型章节可以直接参考这个逻辑来写。

2.1 Hadoop 是“纸老虎”：伪分布式就够用了

我接触过很多对Hadoop有恐惧感的同学，总觉得要搭建一个“真正的分布式集群”特别难，什么三台服务器、配置NameNode和DataNode、处理网络通信……其实这完全是认知偏差。毕业设计不需要三台真机器，也不追求真正意义上的多节点部署，一个**伪分布式模式（伪分布式，即所有节点进程都在一台机器上）**完全足够。所谓伪分布式，就是你的机器上同时运行着NameNode、DataNode、SecondaryNameNode等进程，资源管理器和单机存储都在这台机器里，但HDFS的文件系统逻辑、数据块复制机制、MapReduce计算流程都是真实存在的。这意味着什么？意味着你可以在单机上完整体验分布式系统的全部核心流程，又不被硬件资源卡死。

在论文里写Hadoop相关章节时，重点不是“我搭建了一个多牛的集群”，而是“我理解了HDFS的架构原理，并在伪分布式环境下完整运行了存储流程”。老师听到你能解释清楚数据块怎么切分、备份因子怎么生效、NameNode怎么管理元数据，就已经达到毕设考察目的了。不要为了“看起来高大上”强行租三台云服务器，那只会给自己找麻烦。如果你实在想搞多节点，最多两台虚拟机就够了，一台NameNode一台DataNode，配上一样的Hadoop版本和JDK版本，再把SSH免密登录配好，基本上半小时能搞定，性能也别指望太高，能跑通就行。

另外，Hadoop里的YARN也不是必须自己搭的。你完全可以只把HDFS跑起来，Spark用standalone模式（Spark自己的独立调度器）来运行，不走YARN。这样配置量少一半，出问题的概率也少一半。记住，毕业设计的第一原则永远是“能跑通”排在“够高级”前面。

2.2 核心分析引擎为什么选Spark，而不是纯Pandas

选Spark的核心理由有三点，这三点也是论文里的核心论据。

第一，从技术深度看，Spark顺应了当前大数据领域的主流趋势。你简历上写“熟练使用Spark处理海量数据”，招聘的人自然会觉得你有大数据基础。而一个只用Pandas处理几千行CSV的项目，是撑不起这个分量的。

第二，从运行效率看，Spark的分布式内存计算模型在数据量较大的场景下确实比Pandas有优势。虽然说咖啡店模拟数据量不大，但你可以把数据生成到几十万条甚至上百万条，让Spark真正感受到“有些吃力但依然能扛住”的体量。答辩被问到“数据量多大”的时候，你可以底气十足说“百万级订单记录”，这个数据量用Pandas分析已经有点卡了，但Spark的DataFrame API处理起来相当丝滑——这就是技术选型合理性的最好证明。

第三，从学习价值看，Spark涉及RDD、DataFrame、Spark SQL、Broadcast变量、spark-submit作业提交等内容，这些都是实打实的大数据技能。但Pandas即使你学得再熟练，也很难让你在面试时讲出“分布式计算”的调调。做毕设的本质是一次能力证明，而不是做一次普通的课程作业。

具体到代码实现层面，Spark的DataFrame API跟Pandas非常像，有pandas基础的人上手并不难。读CSV用spark.read.csv，做聚合用groupBy + agg，写回数据库用df.write.format("jdbc")，这套流程只要跑通了第一遍，后面全是熟练工的事。

2.3 Django 的价值不在于大，而在于出图快

有些同学觉得，Django是个重量级Web框架，我就做个数据展示页面，用Flask不是更轻快吗？这个想法没错，但放到毕设场景里，Django的优势反而更明显。

首先是生态和完善度。Django自带Admin后台、ORM、表单处理、用户认证、分页，这些功能看起来基础，但能省下大量重复劳动。比如你要管理“门店信息表”，用Flask你可能要自己写增删改查接口，用Django Admin后台可以一键生成管理界面。这不是偷懒，而是工程效率的体现。

其次是与数据分析场景的配合。Django的ORM能把MySQL查询结果快速转为Python对象，配合ECharts往模板里塞数据也干净利落。你只需要写几个视图函数，返回JSON给前端，前端JS渲染图表，半小时就能把一个数据看板页面做出来。我用Django做过的项目里，从零开始写一个完整的数据展示页面，通常在3到4天内就能从空项目跑通到出图。

最后是论文篇幅好凑。别笑，这真的对毕设很重要。Django的URL路由、视图层、模型层、模板层，每个部分都能单独开一节写，系统设计章节轻松就能写出两三千字。一套成熟的框架，意味着你可以把精力集中到“业务逻辑和数据结果”上，而不是每天为底层细节抠脑壳。

3. 五大核心模块与落地实操

理论聊清楚了，接下来是最关键的部分——模块如何拆解、每一块具体怎么实现。这部分我按“数据生成→存储归档→Spark分析→机器学习预测→Django可视化”的顺序，每个模块给你讲清楚实现思路和关键代码，你拿到之后可以照着一步步做。

3.1 模块一：模拟数据生成与MySQL入库

没有数据，后面全部白搭。很多同学卡在第一步就是不知道怎么造出“像样”的数据。我的建议是：别自己手写随机数，用Faker库。

Faker可以生成各种逼真的假数据，比如门店名、商品名、顾客ID、地址等，你也可以自定义规则。模拟数据的字段建议这样设计：

生成逻辑里最重要的是时间规律。咖啡店的生意有明显的时段高峰——早上8点到10点左右是工作日的早高峰，下午2点到4点是下午茶时段，周末午后人流密集。你生成数据时要让这些时段的下单概率更高。实现方式很简单：先设定一个基础概率分布，时段不同乘上不同权重即可。比如工作日早上8点到10点权重为2.5，凌晨0点到5点权重可以为0.1。这样做出来的数据才经得起分析，做出来的时段热力图才能看出明显的“早高峰、下午茶”结构。

数据量方面，我建议生成3到6个月的数据，总共30万到60万条订单记录。数据量太少跑Spark没有体感，太多生成脚本太慢也费磁盘。生成完成后用pandas读一遍做简单质检，检查空值率和重复率，然后一次性写入MySQL的orders表。写库时建议用pandas的to_sql方法，它是用的批量写入，速度比一条条INSERT快很多。

3.2 模块二：数据归档与HDFS上传

MySQL里的数据是“业务库”，但进入大数据分析体系之前，我们需要把数据“归档”成文件格式，放到HDFS里。这一步很多人不理解：MySQL里已经有数据了，怎么还要导出来？答案很简单：分析系统要处理的原始数据，来源应该是数据湖（HDFS），而不是业务库（MySQL）。真实企业不会拿业务库直接给数据分析师跑大查询，那会影响在线交易性能。数据分析师从HDFS或数据仓库取数才是常态。你把这个流程复刻到毕设里，就是一种“业务意识”的体现。

实操步骤分三块：

第一步，从MySQL导出CSV。用pandas读MySQL，然后按门店或按月份拆分成几个CSV文件，压缩后存到本地。导出的文件字段可以比MySQL原始表多一些“加工后”的字段，比如“weekday”（周几）、“is_holiday”（是否节假日），这些字段在Spark分析时能直接用上。

第二步，启动HDFS并创建数据目录。命令大概是：

hdfs dfs -mkdir -p /data/coffee/raw hdfs dfs -put orders_2024.csv /data/coffee/raw/

第三步，验证文件是否上传成功：

hdfs dfs -ls /data/coffee/raw/

如果你有强迫症，还可以跑一个hdfs dfs -du -h /data/coffee/raw/看看文件实际大小和块数。

HDFS刚起步时经常报“NameNode不能启动”的错，多半是格式化问题或者是/tmp/hadoop-${user.name}目录权限不对。最快的解决方案：hdfs namenode -format重新格式化，然后重启集群。注意，格式化会清空所有元数据，仅限初始阶段使用。别在跑完Spark分析之后再回头格式化，否则你的数据就“消失”了。

3.3 模块三：Spark SQL 分析引擎的实现

数据分析的核心代码在Spark端。这里我推荐直接用Spark SQL风格，而不是苦哈哈地写RDD算子。为什么？因为Spark SQL的DataFrame API更接近SQL思维，中间结果也容易查看，代码量少，调试起来省时间。下面是几个最典型的分析逻辑示例。

示例一：按日期统计销售额和订单量

from pyspark.sql import SparkSession from pyspark.sql.functions import col, sum, count, avg spark = SparkSession.builder.appName("coffee-analysis").getOrCreate() df = spark.read.csv("hdfs://localhost:9000/data/coffee/raw/orders_2024.csv", header=True, inferSchema=True) # 清洗：去重和剔除空值 df = df.dropDuplicates(["order_id"]).na.drop() # 转换日期字段 df = df.withColumn("order_date", col("order_time").substr(1, 10)) # 按日聚合 daily_stats = df.groupBy("order_date").agg( sum("amount").alias("total_sales"), count("order_id").alias("order_cnt"), avg("amount").alias("avg_order_amount") ).orderBy("order_date") daily_stats.show(10) daily_stats.write.format("jdbc").option("url", "jdbc:mysql://localhost:3306/coffee_db").option("dbtable", "analysis_daily").option("user", "root").option("password", "your_password").mode("overwrite").save()

这里有个非常关键的细节：spark.read.csv时inferSchema=True是必需的，不加它，所有字段都会被读成字符串，后面sum("amount")算出来的就是“字符串拼接”而不是数值相加。你如果发现销售额结果异常大，十有八九是这个原因。

示例二：按时段统计销售分布

# 提取小时段 df = df.withColumn("hour", col("order_time").substr(12, 2)) # 定义时段 from pyspark.sql.functions import when df = df.withColumn("time_slot", when((col("hour") >= "07") & (col("hour") < "11"), "早高峰") .when((col("hour") >= "11") & (col("hour") < "14"), "午间") .when((col("hour") >= "14") & (col("hour") < "18"), "下午茶") .otherwise("晚间") ) slot_stats = df.groupBy("time_slot").agg( sum("amount").alias("total_sales"), count("order_id").alias("order_cnt") )

这个时段分析出来的图表，在答辩演示时视觉冲击力很强，一眼就能看出咖啡店的“赚钱时刻”在什么时候。也侧面证明了你模拟数据设计得有讲究。

示例三：商品维度Top10分析

top_products = df.groupBy("product_name").agg( sum("quantity").alias("total_quantity"), sum("amount").alias("total_sales") ).orderBy(col("total_quantity").desc()).limit(10)

这个结果表会在页面上以条形图展示，你还能顺便跑一句“畅销款贡献了多少营业额”的占比分析，答辩时拿出来讲很加分。

关于写回MySQL，上面的代码里用了write.format("jdbc")的方式，这种方式简单，但有一个隐患：大结果集先要拉回driver端再写入，可能有内存压力。如果你想加一点“性能优化”的戏码，可以改成df.write.mode("overwrite").jdbc(...)同样有这个问题、逻辑差不多。但如果结果集只有几千行，驱动端模式完全没问题，没必要为了优化而优化。

3.4 模块四：机器学习销量预测（小而精的加分项）

标题里带了“机器学习”，那一定要有机器学习模块。但我要提醒你：别贪多，别把什么XGBoost、LSTM全堆上去，一个大而空的黑盒模型，不如一个小而精的可解释模型。咖啡店场景里最能落地、也最好答辩的机器学习任务是：预测未来几天的总销量或某一门店的订单量。

经典做法是时间序列预测，用Prophet、ARIMA或LightGBM回归都能做。我更推荐用Prophet，它对节假日效应、周规律捕捉得最好，而且文档成熟、官方API友好，几行代码就能跑出预测图和趋势线。如果你的环境里装不了fbprophet，退而求其次用statsmodels的ARIMA模型也行，但效果一般。

另一种思路是把销量预测转化为回归任务：用历史销售数据构造特征集，比如“前一天销量”“前一周同一天销量”“是否周末”“是否节假日”“天气情况（模拟字段）”，用随机森林回归拟合预测。这种做法的好处是：特征工程能写出花样，模型比较透明，答辩时能展示特征重要性排序图。

我的建议是选一种方向做到完整闭环：数据准备→划分训练集测试集→训练模型→评估指标（RMSE、MAE）→可视化预测对比图。关键不是模型多强，而是流程是否完整，以及你是否能解释清楚每个环节的“为什么”。用随机森林回归的话，顺便输出特征重要性图，PPT就有素材了。

3.5 模块五：Django 可视化大屏

终于到出结果的环节。Django项目结构建议这样组织：

coffee_analysis/ manage.py analysis/ settings.py urls.py dashboard/ views.py models.py urls.py templates/ dashboard.html charts_data.html static/ js/ echarts.min.js dashboard.js

主要的视图逻辑非常简单：从MySQL里读取分析结果表，转成JSON返回到模板。例如：

from django.shortcuts import render from django.http import JsonResponse from .models import AnalysisDaily def sales_trend(request): records = AnalysisDaily.objects.all().order_by("order_date") data = { "dates": [r.order_date.strftime("%Y-%m-%d") for r in records], "sales": [float(r.total_sales) for r in records], "orders": [r.order_cnt for r in records] } return JsonResponse(data) def dashboard(request): return render(request, "dashboard.html")

前端页面上放3到4个图表就够撑场面了：

1. 销售额趋势折线图（按天）；
2. 品类占比饼图（咖啡、饮品、甜点、轻食）；
3. 时段销售热力图或柱状图（早高峰、午间、下午茶、晚间）；
4. 门店销售排行条形图。

我强烈建议你用ECharts而不是其他图表库。它的社区文档极其丰富，任何图表类型都能找到现成示例，而且中文文档看着不累。为了演示时的酷炫感，你还可以加一个小屏展示“今日实时交易笔数”之类的指标卡，数据依然从MySQL拉，别真搞实时流计算，毕设不需要那个层次。

这个页面做完后，整条链路就通了：数据在MySQL生成，归档到HDFS，Spark分析完又写回MySQL，Django从MySQL读取并展示。一个闭环项目，功能完整，逻辑自洽。

4. 踩坑实录：十个新手必踩的坑与排查经验

我带过的学生做这套系统，几乎每个人都会在同一个几个地方卡壳。下面这些坑我按“出现频率+杀伤力”排了序，你务必提前避开。

4.1 环境变量与版本匹配是第一大坑

Hadoop要求JAVA_HOME和HADOOP_HOME都配好，Spark要求SPARK_HOME配好，同时Python环境和JDK的版本还有兼容关系。最常见的组合是：JDK 8 + Hadoop 3.3.x + Spark 3.1.x + Python 3.7/3.8。如果你用了JDK 11，老一点的Hadoop版本会报“IllegalArgumentException: Does not contain a valid host:port authority”之类的奇葩错误。建议直接按下方表格配置：

配置完环境变量之后，务必执行：

java -version hadoop version spark-shell --version python --version

四个命令全部正常再往下走，不然等你的将是漫长的黑人问号。

4.2 运行Spark任务的三种方式与推荐做法

很多同学一上来就写python3 analyze.py直接跑在IDE里，这对PySpark是不友好的。它会报“Python worker failed to connect back”之类的错，原因是你没有用Spark的提交框架。正规做法有两种：

第一种，用spark-submit提交Python脚本：

spark-submit --master local[4] analyze.py

这是最推荐的方式。注意local[4]表示本地模式开4个线程，如果你的电脑只有2核4线程，local[2]就行，没必要死撑大数字。

第二种，在Jupyter Notebook里写，findspark.init()初始化后再import pyspark，适合调试，但最终演示还是要用spark-submit跑一遍，显得更专业。

还有一个隐藏问题：如果你的Spark版本是3.x，而Python环境中同时装了pyspark和Java不匹配，会报“Unsupported class file major version”错误。解决方案就是前面说的，JDK 8配Spark 3.x大概率没问题，JDK 17配Spark 2.x基本必炸。

4.3 内存不足：Driver和Executor的平衡艺术

本地模式下跑PySpark最容易犯的错就是默认内存参数太小。大一点的DataFrame执行任务时直接OutOfMemory，或者GC超时挂掉。排查思路很简单：

spark-submit --master local[4] --driver-memory 2g --executor-memory 2g analyze.py

--driver-memory 2g是指定driver端可用2GB内存，--executor-memory 2g是指定executor端。单机模式local的话，executor memory和driver memory会共享你的物理内存，所以一般设置成1g到2g之间就够了。如果内存爆了别急着加参数，先检查是不是代码里用了大量collect()把整个DataFrame拉到本地了。能不用collect就不用，把结果写进数据库比拉回本地再写，省内存且更稳。这个原则掌握了，你的Spark代码就成功了一半。

4.4 Django与Spark的“隔离原则”

最常见的设计错误是：在Django视图里直接调用SparkSession，试图让Web请求触发Spark任务。这种写法能跑通，但非常不稳定，因为每次请求都要初始化SparkContext，耗时几十秒到几分钟不等，而且资源争用严重，页面会卡成PPT。我把这个坑叫“隔离原则缺失”。

正确做法是：Spark任务独立运行（手动触发或定时跑），分析结果落MySQL，Django只负责从MySQL查已经算好的结果。这个方案的核心思想是离线计算与在线展示解耦。毕设阶段你甚至可以用一个简单的Shell脚本来管理：先执行Spark分析，再启动Django服务，中间不产生任何直接依赖。

4.5 MySQL 连接与中文编码问题

Spark写回MySQL时，如果数据里有中文，“URL地址没加字符集参数”就会乱码。解决方案就是JDBC连接串加一句话：

"url": "jdbc:mysql://localhost:3306/coffee_db?useUnicode=true&characterEncoding=utf8&useSSL=false"

这个细节在展示阶段尤其重要——你总不能答辩的时候展示一屏乱码吧。

5. 毕设论文框架与答辩准备

技术代码做得再好，论文写得差也会被批；论文写得条理清晰，哪怕代码有小瑕疵，老师们也能体谅。论文框架，我建议用下面这个九章结构。

5.1 论文结构与每一章的写法建议

论文写作时有几个“得分细节”：第一，数据库设计往每张表加ER图，ER图可以简化，但必须有；第二，系统实现章节最好放真实运行截图，而不是只贴代码；第三，性能测试要有一个“数据量取多次跑的平均耗时”表格，这能证明你的系统经过了量化评估。

5.2 答辩演示与高频提问应答

演示环境建议全套本地跑通，并做成“一键启动”的脚本。至少准备一个启动脚本，把Hadoop启动、Spark任务提交、Django服务启动串成一条命令：sh run_all.sh。这样答辩现场不用手忙脚乱打一堆命令，演示流程也能顺滑很多。

答辩时老师大概率会问这几个问题，提前想好答案就不慌：

• “你这系统是分布式吗？”答：核心存储和计算使用了Hadoop和Spark的分布式框架，但当前部署在单机伪分布式环境，通过伪分布式模式完整实现了分布式计算的运行机制；如果需要扩展，部署到多节点集群只需修改配置即可。
• “Spark在这里到底有什么优势？”答：相比Pandas，Spark使用分布式内存计算模型，支撑百万级数据量的处理和分析；同时Spark SQL提供声明式查询接口，极大提高分析效率。
• “数据是哪里来的？真实吗？”答：基于业务特征模拟生成，符合咖啡店销售的时段分布规律，经过数据质检和清洗后进入系统。如果需要真实数据，可通过系统预留的数据导入接口扩展。
• “机器学习部分有什么意义？”答：预测未来销量，辅助门店进行库存准备和人员排班，是数据驱动决策的直接体现。

如果老师连续追问，千万别硬扛，承认局限也很正常：“当前模型在单变量场景下效果稳定，后续可引入天气、活动等因素提升预测精度。”这种回答比强撑着说自己完美要稳妥得多。

最后再分享一个小技巧：所有展示结果表里，务必保证Spark分析和Django展示是同一份数据源。演示的时候，如果老师提出“改一个参数看效果”，你最好手动重跑一遍Spark作业而不是只改前端数据。这套系统的本质是一套完整的数据工程，而不是一个三分钟短视频。你把这个逻辑讲透了，分数基本就稳了。