简介一套基于Spark的餐饮平台菜品智能分析推荐系统源码与数据库属于高分毕业设计项目评审得分98分。资源面向计算机、通信、人工智能、自动化等专业的学生、教师或从业者适用于课程设计、课程大作业、毕业设计以及个人进阶学习整体具有较高的借鉴与二次开发价值。包体共49个文件压缩包约2.05MB。其中以17个Java源码文件为核心配合8个XML配置、6个CSS样式、5个JavaScript脚本、3个JSP页面以及SQL数据库脚本、CSV评分数据和README说明等构成前后端完整项目结构便于按模块查阅和调试运行。代码已经过调试测试确保可直接运行。项目主要围绕菜品数据的智能分析与推荐展开可帮助学习者理解Spark数据处理、协同过滤推荐、用户评分建模等关键环节同时数据库与样例数据齐全能节省环境搭建与造数时间。目前已有254人学习下载适合想要快速上手完整项目并在此基础上修改扩展的读者。1. 基于Spark的菜品智能分析推荐先想清楚它到底解决什么问题餐饮平台的订单数据每天都在膨胀一个中等规模的城市餐饮连锁一天就能攒下几万条点餐记录周末直接翻倍。用单机Pandas做聚合和推荐跑一次全量计算能把电脑风扇转出直升机的声音。这个基于Spark的菜品智能分析推荐系统核心思路是把MySQL里的订单表、菜品表和评价表当成数据源由Spark做离线批处理一边产出菜品的热度、时段和口味特征一边基于历史订单训练协同过滤模型给每个用户生成Top-N菜品推荐。它适合正在做课程设计或毕业设计的同学也适合想快速把Spark完整链路跑通的数据从业者。读完这一篇你至少能把数据清洗、特征分析、推荐训练、离线评估这条线完整地独立搭建起来。2. 系统架构与数据链路订单、菜品和评价表如何落到Spark分析任务里2.1 Spark承担的职责离线批处理不是实时魔法很多第一次做推荐项目的同学以为上了Spark就能做到“用户刚点完菜下一秒就推荐”的实时效果这个预期必须先矫正。菜品推荐最常见的落地形态是T1离线计算每天凌晨Spark把前一天甚至过去三十天的全量订单重新跑一遍产出每个用户的候选推荐集合写回MySQL或缓存服务。用户端真正读取推荐结果时走的是普通接口查询不再经过Spark。这样设计最大的好处是逻辑好调试、模型好迭代出问题重跑当天任务就行不必维护一套复杂的流式计算链路这是做这类项目时最值得先定下来的架构决策。在这一套架构里Spark内部的三块能力各管一摊Spark SQL负责读MySQL、读JSON日志做聚合分析MLlib负责跑ALS协同过滤和FP-Growth关联规则DataFrame的write API负责把结果回写到MySQL。用哪个语言写无所谓常见做法是课程设计用Java Maven工程实现用PySpark下面所有示例代码按PySpark给出因为代码量短、新手照着敲不容易出错。集群环境建议直接按标准的spark集群搭建方式准备三台机器起一个standalone集群就够跑课程设计级别的数据量如果只是验证逻辑单机local模式也能跑通但要注意local模式跑通不等于集群模式能跑通后面避坑章节会专门讲这一点。Spark在菜品分析里的另一个重要优势是它把“抽样调查”变成了“全量计算”。单机Pandas处理千万级订单流水时要反复考虑能不能放进内存Spark不用它的DataFrame会把数据切成若干分区每个分区只占一部分内存跑完自动释放。这也是为什么业内做spark数据分析案例时面对订单流水、点击日志这类数据第一选择几乎都是Spark而不是传统的MySQL聚合——不是MySQL不能算而是在数据量上来之后Spark的横向扩展成本远低于数据库加索引和改SQL的成本。2.2 数据库表设计MySQL既是数据源也是结果回写目的地这类“源码数据库”的项目业务库一般就是MySQL而Spark任务需要从中读取两张以上的表做关联分析。先给一套典型的表结构设计表名关键字段说明usersuser_id, user_name, prefer_tags用户基础信息prefer_tags可以存“辣、清淡、甜品”等标签dishesdish_id, dish_name, category, price, spice_level菜品主数据category用于冷启动补位ordersorder_id, user_id, dish_id, order_time, quantity点餐流水全项目最大的数据源ratingsuser_id, dish_id, rating, create_time显式评分表可能为空需要做空值兜底orders表是整个分析的核心增长速度最快、行数最多order_time字段必须建索引而且建议按天做分区或者按月份做分表否则Spark全表扫的时候MySQL端会先被拖垮。quantity字段别看简单它是推荐权重的重要来源用户点了一份椒麻鸡和点了三份椒麻鸡偏好强度完全不一样。ratings表在真实业务里经常是空的因为大多数用户吃完不会主动打分所以推荐评分不能依赖这张表而要退回到订单数据里构造隐式反馈。Spark读MySQL的代码在本地环境和集群环境的写法稍有不同但核心连接参数是一致的下面这段是把orders表载入DataFrame的标准写法from pyspark.sql import SparkSession spark SparkSession.builder \ .appName(DishRecommendETL) \ .master(yarn) \ .config(spark.sql.shuffle.partitions, 8) \ .config(spark.executor.memory, 2g) \ .getOrCreate() orders_df spark.read.format(jdbc) \ .option(url, jdbc:mysql://192.168.1.10:3306/dish_db?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNull) \ .option(dbtable, orders) \ .option(user, spark_user) \ .option(password, your_password) \ .option(driver, com.mysql.cj.jdbc.Driver) \ .option(fetchsize, 1000) \ .load()这段代码有几个参数必须说清楚driver要写com.mysql.cj.jdbc.Driver而不是老版的com.mysql.jdbc.DriverMySQL 8.0以上用老驱动会直接报通信链接异常。url里的characterEncodingutf8决定了Spark拿到的中文不是乱码这个参数在3.x版本里和连接串里其他参数的位置无关但绝对不能省。fetchsize设为1000是让JDBC每次从MySQL拉取1000行而不是全部塞进内存对订单大表来说是常规做法。还有一个新手很容易忽略的问题上面这种写法Spark读MySQL默认只有一个分区也就是说数据量大时只有一个executor在干活并行度是假的。要真正并行读需要指定分区列和上下界orders_df spark.read.format(jdbc) \ .option(url, jdbc:mysql://192.168.1.10:3306/dish_db?...) \ .option(dbtable, orders) \ .option(user, spark_user) \ .option(password, your_password) \ .option(driver, com.mysql.cj.jdbc.Driver) \ .option(partitionColumn, id) \ .option(lowerBound, 1) \ .option(upperBound, 5000000) \ .option(numPartitions, 6) \ .load()partitionColumn必须是一个数值型的自增主键Spark会用WHERE id BETWEEN ? AND ?把查询拆成6段分给6个executor并行去MySQL拉数据。如果订单表的主键不是数字类型就需要在MySQL里先造一个自增序号列或者退而求其次接受单分区读取——课程设计数据量在百万行以下时单分区其实也能跑完只是慢一些。分析结果要写回MySQL也很简单把结果表按“先删后写”的方式输出result_df.write.format(jdbc) \ .option(url, jdbc:mysql://192.168.1.10:3306/dish_db?useUnicodetruecharacterEncodingutf8) \ .option(dbtable, recommend_result) \ .option(user, spark_user) \ .option(password, your_password) \ .option(driver, com.mysql.cj.jdbc.Driver) \ .mode(overwrite) \ .save()mode(overwrite)的本质是先drop整张表再写新数据相当于数据库里的删除加插入如果目标是增量更新应该用append模式但要注意append不会去重重复跑任务会累积出脏数据。项目里我一般把所有结果表都设计成“离线全量刷新”也就是每天overwrite一次逻辑最简单也最容易向评审老师解释清楚。3. 菜品特征分析从JSON日志到热度、时段和口味三个维度3.1 读取JSON订单流搞定schema推断、多行文本与中文编码餐饮平台除了关系型数据库里的订单还常有一路数据来自客户端埋点日志用户浏览了哪个菜品页面、在哪个页面停留了多久、最终下单了没有这些事件以JSON格式落盘。把JSON日志和MySQL订单结合起来分析才能得到完整的菜品热度而不只是“已下单”这个结果。要读JSON先用spark.read.json它支持自动推断schema听起来很省事但实际项目里JSON解析的坑大多藏在三个地方多行JSON、编码、时间字段类型推断。常见的埋点日志有两种组织方式一种是每行一条JSON叫单行JSON另一种是整文件是一个JSON数组或有嵌套大括号叫多行JSON。默认情况下spark.read.json只能处理单行JSON遇到多行JSON必须加上multiLineTrue否则整个文件读出来是几十万行全是null的脏数据。我见过不止一个同学在“spark中读取json”上翻车就是因为漏了这个参数跑出来的聚合结果全是0还以为是数据没采集到。处理这类日志时建议打开的开关和参数如下click_log spark.read.json( hdfs:///user/dish/logs/2025-06-01/*.json, multiLineTrue, encodingutf-8, inferSchemaTrue, samplingRatio1.0, dateFormatyyyy-MM-dd HH:mm:ss )samplingRatio这个参数新手容易忽略它默认是1.0也就是全量数据都用来推断字段类型。如果日志量特别大可以设成0.1让spark只抽样10%来推断schema加快读取速度但代价是某些字段可能被推断成string而不是timestamp后面做时间聚合时还要再cast。做课程设计级项目时我建议老老实实用1.0因为数据量还没大到需要采样推断的程度而且类型推断错了后面排查更浪费时间。JSON读取后要做一次数据质量检查这个习惯能帮你避开大量玄学问题。先看DataFrame的schema里有没有字段全为null的列再看user_id和dish_id有没有大量空值最后看中文内容是否出现乱码。中文乱码的典型表现是菜品名变成“è??±”这类不可读字符原因几乎都出在源文件的编码和读取时指定的encoding不一致上。日志文件如果是从Windows机器传上来的大概率是GBK编码直接用encodingutf-8读必然乱码。正确的做法是先看文件头或者用file命令确认编码读取时按实际编码指定。file /user/dish/logs/2025-06-01/part-00001.json如果输出里带ISO-8859或者Non-ISO extended-ASCII那基本可以确定是GBK或GB2312需要把读取参数改成encodinggbk。用Spark处理餐饮数据时中文编码问题算是最高频的踩坑点之一早检查早安心别等到聚合结果都出来了才发现菜品名是乱码那种返工最浪费时间。3.2 用Spark SQL做菜品热度与时段聚合三个必调参数菜品智能分析里最基础也最常被问到的产出物是三个维度热度榜、时段分布、口味偏好。热度榜不是简单count一下订单数就完事而是应该用sum(quantity)做加权因为一道菜被反复点说明它已经不是“尝鲜”而是“复购型”菜品权重理应更高。用Spark SQL写聚合非常直白orders_df.createOrReplaceTempView(orders) dish_df.createOrReplaceTempView(dishes) heat_sql SELECT d.dish_id, d.dish_name, d.category, COUNT(DISTINCT o.user_id) AS user_cnt, SUM(o.quantity) AS total_qty, ROUND(SUM(o.quantity) * 1.0 / COUNT(DISTINCT o.user_id), 2) AS qty_per_user FROM orders o JOIN dishes d ON o.dish_id d.dish_id WHERE o.order_time DATE_SUB(CURRENT_DATE, 30) GROUP BY d.dish_id, d.dish_name, d.category ORDER BY total_qty DESC LIMIT 50 heat_top50 spark.sql(heat_sql)这段SQL里qty_per_user是人均点餐份数它能区分“超多人点但每人只点一次”的尝鲜菜和“人数不多但反复点”的回头菜这个指标在后续做推荐过滤时非常有用。时段分布分析则要把order_time转换成小时再映射到就餐时段最方便的实现是CASE WHENtime_sql SELECT CASE WHEN HOUR(order_time) BETWEEN 6 AND 9 THEN breakfast WHEN HOUR(order_time) BETWEEN 10 AND 14 THEN lunch WHEN HOUR(order_time) BETWEEN 14 AND 17 THEN afternoon_tea WHEN HOUR(order_time) BETWEEN 17 AND 21 THEN dinner ELSE night_snack END AS time_bucket, dish_id, SUM(quantity) AS qty FROM orders WHERE order_time IS NOT NULL GROUP BY time_bucket, dish_id time_stats spark.sql(time_sql)做完聚合之后Spark任务里建议打开三个和shuffle相关的参数这三兄弟是保证聚合稳定不OOM的关键。spark.sql.shuffle.partitions决定shuffle时产生的分区数小数据集设8到16就够了默认200对小项目是浪费每个分区只分到几千行反而效率低。spark.sql.adaptive.enabled开启自适应查询执行Spark会运行时根据实际数据量自动合并过小的分区对课程设计这种数据量忽高忽低的任务非常友好。spark.sql.autoBroadcastJoinThreshold设置在join小表时自动做广播默认10MB如果菜品表很小建议设成52428800也就是50MB让菜品表直接广播到每个executor内存里orders和dishes的join就会从shuffle join自动变成map join速度能差出一个量级。口味偏好的分析要关联dishes表里的spice_level字段比如把辣度分成0到5档统计用户对不同辣度菜品的历史点餐占比。这个输出会直接用作推荐阶段的“口味过滤”假设某个用户80%的订单都是不辣菜品那么即使ALS模型推荐了某个辣度偏高的菜也应该在下游规则层把它过滤掉否则推荐结果就算“算法上正确”用户也会觉得不准。口味特征不一定要做得复杂一个用户维度的辣度均值加一个点餐次数就够了为后面过滤提供依据时简单特征比复杂特征更可解释。4. 推荐算法落地ALS协同过滤与FP-Growth组合拳4.1 构建用户-菜品评分矩阵把隐式反馈变成ALS能吃的格式菜品推荐的常规做法是先跑协同过滤再叠加关联规则。协同过滤用ALS算法它需要的输入是标准的(user_id, dish_id, rating)三元组。但真实餐饮场景里的问题在于ratings表几乎永远是空的用户不会像视频平台那样给菜打分。所以这里必须从订单数据构造“隐式反馈评分”用自己的逻辑告诉模型一个用户有多喜欢一道菜。我一般用三个信号叠加30天内的点餐次数、菜品单价、时间衰减。点餐次数是最核心的信号单价做一个对数压缩防止贵的菜天然占优时间衰减用来让最近两周的行为权重高于一个月前的行为。构造逻辑写成PySpark就是groupBy加聚合from pyspark.sql import functions as F train_df orders_df.filter( orders_df.order_time 2025-01-01 ).groupBy(user_id, dish_id).agg( F.count(*).alias(cnt), F.sum(quantity).alias(qty), F.max(order_time).alias(last_order_time) ).join( dishes_df.select(dish_id, price), ondish_id, howleft ) # 核心隐式反馈评分 log1p(点餐次数) log1p(单价) * 0.3 train_df train_df.withColumn( score, F.log1p(qty) F.log1p(price) * 0.3 ).select(user_id, dish_id, score)构造评分时有两个容易被忽略的细节。第一count(*)不如sum(quantity)合适因为一单点两份排骨和两单各点一份排骨前者代表更强的偏好用数量能区分开来。第二价格权重要不要加取决于你的推荐目标如果目标是提高客单价价格权重可以加大如果目标是提高点击转化率价格权重反而会干扰因为用户点不点一道菜和它贵不贵没有必然关系。课程设计里我建议保留0.3这个低权重同时把这段加权逻辑写进文档里答辩时老师问起来你能讲清楚“每个参数为什么存在”这就比只会调库的代码值钱得多。4.2 ALS训练与Top-N推荐rank、maxIter、regParam怎么设ALS在MLlib里的接口很简洁但参数不在代码量上而在你怎么设值。固定写法如下from pyspark.ml.recommendation import ALS als ALS( userColuser_id, itemColdish_id, ratingColscore, implicitPrefsTrue, alpha10.0, rank20, maxIter15, regParam0.1, coldStartStrategydrop ) model als.fit(train_df) # 给每个用户推荐10道菜 user_recs model.recommendForAllUsers(10)先说implicitPrefsTrue这个开关是专门给隐式反馈数据准备的因为隐式反馈的评分不是真正的打分而是“点过几次、点了多少份”这种统计量模型内部会把它当成置信度来处理。如果你构造的score是基于次数的这个开关必须打开否则模型会把score当成显式评分结果会严重偏向“评分高”的极少数用户。与之配套的是alpha它控制隐式反馈的置信度缩放默认1.0在电商场景下够用但餐饮点餐次数普遍偏小我通常调到5到15之间。rank控制用户和菜品特征向量的维度rank太小模型表达力不够太大在数据量不够时过拟合。maxIter是迭代次数15到20之间一般能收敛一味加大只会让训练时间变长精度提升很有限。regParam是正则化系数防止模型在稀疏矩阵上过拟合0.1是个稳妥的起点后面调优时在0.01到0.5之间试。训练好之后model.recommendForAllUsers(10)会返回一个DataFrame里面recs列是每个用户的推荐菜品数组。这里有一个隐藏问题推荐列表是算法原样输出没有做任何业务过滤。实际使用中我会把推荐结果展开成行再和上一章算出来的口味偏好做过滤把用户明确不吃的辣度档次直接剔除然后再和菜品热度榜做一个加权融合最终才写回结果表。推荐系统不能只靠算法模型规则层兜底往往才是用户体验的胜负手。4.3 FP-Growth挖掘套餐组合支持度与置信度怎么挑ALS解决的是“这个用户喜欢什么菜”FP-Growth解决的是“哪些菜经常一起被点”。后者直接产生套餐推荐用户下单时发现推荐组合里有一道他历史没点过的菜但和另一道他常点的菜强关联下单概率会明显提升。FP-Growth的输入不是三元组而是一个用户一个交易行这个交易行在餐饮场景里定义为“同一天同一个用户点的所有菜品集合”。from pyspark.ml.fpm import FPGrowth # 构造交易数据同一天同一个用户点的菜品列表 transactions orders_df.groupBy(user_id, F.to_date(order_time).alias(dt)) \ .agg(F.collect_set(dish_id).alias(items)) fp FPGrowth( itemsColitems, minSupport0.02, minConfidence0.2 ) fp_model fp.fit(transactions) # 查看频繁项集和关联规则 freq_itemsets fp_model.freqItemsets association_rules fp_model.associationRulesminSupport的含义是“一组菜品在所有交易中出现的最低比例”设太低会产出大量噪声规则设太高则挖掘不到东西。餐饮场景下如果总交易量在十万级0.02是一个合理的起点也就是一组菜品组合至少出现2000次才会被纳入候选。minConfidence表示在用户点了A的前提下去推荐B的可信度0.2听起来很低但在菜品组合里已经是有意义的水平因为餐饮不像零售点菜组合的重复率本身不高设到0.5以上几乎挖不出规则。训练完以后把所有规则装入一个Map广播出去结合当天订单实时决定展示哪个套餐这套逻辑非常经典。FP-Growth的结果要跟ALS结果做融合才能避免推荐列表全是“用户常吃的菜”。ALS倾向于推荐和用户历史偏好相似的东西FP-Growth倾向于推荐“和用户正在点的菜搭着卖”的东西两者结合覆盖了两类完全不同的推荐需求。我的经验是首页推荐列表按70% ALS加30%热度补位下单页套餐推荐直接走FP-Growth规则这个配比在多数餐饮项目里都比单模型效果好。5. 避坑章节Spark菜品分析全链路最常见的五个翻车现场5.1 MySQL驱动ClassNotFound驱动jar到底该放哪现象是代码在IDEA里跑得好好的打包成jar提交到集群就报ClassNotFoundException: com.mysql.cj.jdbc.Driver。原因很简单Spark集群的executor节点上根本没有MySQL驱动类而--jars参数如果加得不对驱动只在driver端生效executor端拉数据时依然找不到类。解决方法是提交任务时把driver和executor的classpath都配上spark-submit \ --master yarn \ --deploy-mode cluster \ --jars /opt/libs/mysql-connector-java-8.0.33.jar \ --driver-class-path /opt/libs/mysql-connector-java-8.0.33.jar \ --class com.dishrecommend.analysis.ETLJob \ dish-recommend-1.0.jar关键点在于--driver-class-path负责driver端--jars负责executor端两者都要。如果集群HDFS上已经有这个jar可以换成--jars hdfs:///libs/mysql-connector-java.jar这样每个节点从HDFS拉取不用手动拷到每台机器。驱动版本尽量和MySQL服务端版本大版本一致MySQL 8.0配8.0.x驱动避免连上了但握手协议报错。5.2 executor内存反复溢出分区数、序列化与offHeap现象是任务跑一半YARN界面上一排红色日志报java.lang.OutOfMemoryError: Java heap space或者GC overhead limit exceeded。原因通常是两个一是spark.sql.shuffle.partitions设置过大每个分区内的数据太少但task数量太多每个task都要启动一个JVM里的线程内存管理开销爆掉二是缓存了太多DataFrame后没有及时unpersist。解决先从分区数下手如果你只有2个executor、每个4G内存把shuffle分区数设在8到16之间不要用默认200。再用Kryo序列化替代Java序列化在SparkSession初始化时加上spark.conf.set(spark.serializer, org.apache.spark.serializer.KryoSerializer)序列化器对内存占用的影响往往被忽视Java序列化在数据量大时能吃掉比业务数据还多的内存。最后如果还觉得内存紧可以开offHeapspark.conf.set(spark.memory.offHeap.enabled, true) spark.conf.set(spark.memory.offHeap.size, 2g)注意offHeap内存不计入executor的heap它是独立的要确保每台物理机能给这么多额外内存。另外在缓存DataFrame后这个缓存一定要在任务结束前主动unpersist()否则长任务链里前一阶段的缓存一直占着内存后面的join和groupBy就没内存可用这是最常见的隐性问题。5.3 中文乱码与JSON解析失败编码、Schema与采样推断现象是JSON里把菜品名读出来是“三文é”或者某些日期字段读出来是一串时间戳数字。原因分两类文件本身不是UTF-8或者JSON文件是多行结构但忘了开multiLine。处理方式是先确认编码再读取读完立刻打印schema检查字段类型看看有没有哪个字符串字段被推断成binary。最容易翻车的是时间字段如果日志里时间格式是2025-06-01 12:30:00Spark推断出来的类型通常是timestamp没问题但如果某些行的时间戳格式变成2025-06-01整个字段会被推断成date后续做hour()函数直接报错。预防办法是读取时显式指定dateFormat或者在SQL里统一对时间字段做CAST(order_time AS TIMESTAMP)不要依赖推断结果。对于必要字段更好的做法是干脆在自己的代码里定义schema绕开推断比如json里嵌套了菜品列表属性时定义一个StructType能让你提前发现数据结构变化而不是等聚合结果全是null再排查。5.4 数据倾斜一个爆款菜拖垮整个reduce阶段现象是groupBy dish_id的时候其他任务几秒跑完唯独一个任务卡了十几分钟最后超时失败。原因是一个爆款菜品的数据量占了总量的30%shuffle时按照dish_id哈希落到了同一个分区这个分区的executor被活活压死这就是典型的数据倾斜。解决有两板斧。第一板斧是先做两阶段聚合解决键倾斜问题第一次按dish_id加一个随机前缀做部分聚合第二次去掉前缀再聚合一次这样热点key的数据被分散到多个分区先算一遍最后合并结果。第二板斧是针对join倾斜把热点dish的大表数据单独拆出来广播处理非热点的走正常join。用算式描述的话两阶段聚合是“先打散再聚合”广播join是“热点走内存非热点走shuffle”。如果任务确实只是课程设计数据量倾斜未必会触发但既然要做高分项目把这个优化写进设计文档能让答辩质量上一个档次。5.5 评分矩阵全1问题隐式反馈的“评分”不是评分现象是ALS训练完以后推荐给所有用户的菜品几乎完全一样全是热门菜。原因在于隐式反馈处理不当你构造的score如果要么是1要么是0比如直接用count(*)作为rating但没做任何归一化模型学到的信息量非常低所有有过点餐行为的“1”都长一个样模型只能学到流行度学不到个性化差异。解决的关键是把评分从“是否点过”变成“点过多少次、最近多频繁、对该菜品的偏好在全局中处于什么水平”。我用的是log1p(qty) 0.3 * log1p(price)再加上时间衰减系数让最近7天的行为权重是30天前行为的两倍。另一个关键是把implicitPrefsTrue打开并在alpha上做调整——这个配置组合才是隐式反馈真正生效的条件。如果你看完推荐结果发现还是偏热门检查一下是不是训练数据里存在极端不平衡大量用户只有一两条记录少数用户有几百条记录。这时要对用户侧做截断比如每个用户最多保留最近50条订单行为防止少数重度用户主导整个模型的向量空间。6. 从跑通到可信离线评估与参数寻优的实测路径模型训练出来、推荐结果写回数据库项目只能算跑通还不能算有效。要证明它真的有用得做离线评估。做法是把时间切成两段用过去30天数据训练用最近7天的实际点餐行为做验证。核心指标有两个命中率验证集里用户实际点的菜有多少出现在推荐Top-N里覆盖率推荐列表里覆盖了多少种不同菜品。命中率防止模型完全不准覆盖率防止模型退化成“只推爆款”的偷懒方案这两个指标要一起看只盯命中率会让推荐结果越来越窄。参数寻优不要靠感觉乱试用网格搜索加交叉验证更靠谱。ALS里最值得调的就是rank、regParam、alpha三件套固定maxIter为15rank在10、20、30里选regParam在0.01、0.1、0.5里选alpha在5、10、15里选用ParamGridBuilder配合TrainValidationSplit跑一轮基本能找到比默认参数好一截的组合。冷启动则是任何推荐系统都绕不开的硬骨头新用户没有历史行为直接用ALS推荐结果一定是空的我一般用三层兜底——按热门榜推荐、按用户注册时选择的偏好标签过滤、按地域菜品类别做多样性插入至少保证新用户看到的东西不突兀。做推荐系统最容易犯的错就是把它当成黑匣子不看指标直接调参。我自己吃过这个亏刚开始做菜品推荐时只盯着命中率调完参数命中率确实涨了但覆盖率掉到了惨不忍睹的10%整个推荐列表翻来覆去就是那几道热门菜业务方一看就说这功能没有价值。后来老老实实同时观察命中率和覆盖率发现真正的瓶颈不在模型参数而在数据预处理阶段的隐式评分构造。从那以后我养成了一个习惯任何推荐项目先跑通评估脚本再碰参数顺序不能反。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 10:52:47 · 阅读 1.2k 基于Spark的菜品智能分析推荐系统：从离线批处理到ALS协同过滤实践
简介一套基于Spark的餐饮平台菜品智能分析推荐系统源码与数据库属于高分毕业设计项目评审得分98分。资源面向计算机、通信、人工智能、自动化等专业的学生、教师或从业者适用于课程设计、课程大作业、毕业设计以及个人进阶学习整体具有较高的借鉴与二次开发价值。包体共49个文件压缩包约2.05MB。其中以17个Java源码文件为核心配合8个XML配置、6个CSS样式、5个JavaScript脚本、3个JSP页面以及SQL数据库脚本、CSV评分数据和README说明等构成前后端完整项目结构便于按模块查阅和调试运行。代码已经过调试测试确保可直接运行。项目主要围绕菜品数据的智能分析与推荐展开可帮助学习者理解Spark数据处理、协同过滤推荐、用户评分建模等关键环节同时数据库与样例数据齐全能节省环境搭建与造数时间。目前已有254人学习下载适合想要快速上手完整项目并在此基础上修改扩展的读者。1. 基于Spark的菜品智能分析推荐先想清楚它到底解决什么问题餐饮平台的订单数据每天都在膨胀一个中等规模的城市餐饮连锁一天就能攒下几万条点餐记录周末直接翻倍。用单机Pandas做聚合和推荐跑一次全量计算能把电脑风扇转出直升机的声音。这个基于Spark的菜品智能分析推荐系统核心思路是把MySQL里的订单表、菜品表和评价表当成数据源由Spark做离线批处理一边产出菜品的热度、时段和口味特征一边基于历史订单训练协同过滤模型给每个用户生成Top-N菜品推荐。它适合正在做课程设计或毕业设计的同学也适合想快速把Spark完整链路跑通的数据从业者。读完这一篇你至少能把数据清洗、特征分析、推荐训练、离线评估这条线完整地独立搭建起来。2. 系统架构与数据链路订单、菜品和评价表如何落到Spark分析任务里2.1 Spark承担的职责离线批处理不是实时魔法很多第一次做推荐项目的同学以为上了Spark就能做到“用户刚点完菜下一秒就推荐”的实时效果这个预期必须先矫正。菜品推荐最常见的落地形态是T1离线计算每天凌晨Spark把前一天甚至过去三十天的全量订单重新跑一遍产出每个用户的候选推荐集合写回MySQL或缓存服务。用户端真正读取推荐结果时走的是普通接口查询不再经过Spark。这样设计最大的好处是逻辑好调试、模型好迭代出问题重跑当天任务就行不必维护一套复杂的流式计算链路这是做这类项目时最值得先定下来的架构决策。在这一套架构里Spark内部的三块能力各管一摊Spark SQL负责读MySQL、读JSON日志做聚合分析MLlib负责跑ALS协同过滤和FP-Growth关联规则DataFrame的write API负责把结果回写到MySQL。用哪个语言写无所谓常见做法是课程设计用Java Maven工程实现用PySpark下面所有示例代码按PySpark给出因为代码量短、新手照着敲不容易出错。集群环境建议直接按标准的spark集群搭建方式准备三台机器起一个standalone集群就够跑课程设计级别的数据量如果只是验证逻辑单机local模式也能跑通但要注意local模式跑通不等于集群模式能跑通后面避坑章节会专门讲这一点。Spark在菜品分析里的另一个重要优势是它把“抽样调查”变成了“全量计算”。单机Pandas处理千万级订单流水时要反复考虑能不能放进内存Spark不用它的DataFrame会把数据切成若干分区每个分区只占一部分内存跑完自动释放。这也是为什么业内做spark数据分析案例时面对订单流水、点击日志这类数据第一选择几乎都是Spark而不是传统的MySQL聚合——不是MySQL不能算而是在数据量上来之后Spark的横向扩展成本远低于数据库加索引和改SQL的成本。2.2 数据库表设计MySQL既是数据源也是结果回写目的地这类“源码数据库”的项目业务库一般就是MySQL而Spark任务需要从中读取两张以上的表做关联分析。先给一套典型的表结构设计表名关键字段说明usersuser_id, user_name, prefer_tags用户基础信息prefer_tags可以存“辣、清淡、甜品”等标签dishesdish_id, dish_name, category, price, spice_level菜品主数据category用于冷启动补位ordersorder_id, user_id, dish_id, order_time, quantity点餐流水全项目最大的数据源ratingsuser_id, dish_id, rating, create_time显式评分表可能为空需要做空值兜底orders表是整个分析的核心增长速度最快、行数最多order_time字段必须建索引而且建议按天做分区或者按月份做分表否则Spark全表扫的时候MySQL端会先被拖垮。quantity字段别看简单它是推荐权重的重要来源用户点了一份椒麻鸡和点了三份椒麻鸡偏好强度完全不一样。ratings表在真实业务里经常是空的因为大多数用户吃完不会主动打分所以推荐评分不能依赖这张表而要退回到订单数据里构造隐式反馈。Spark读MySQL的代码在本地环境和集群环境的写法稍有不同但核心连接参数是一致的下面这段是把orders表载入DataFrame的标准写法from pyspark.sql import SparkSession spark SparkSession.builder \ .appName(DishRecommendETL) \ .master(yarn) \ .config(spark.sql.shuffle.partitions, 8) \ .config(spark.executor.memory, 2g) \ .getOrCreate() orders_df spark.read.format(jdbc) \ .option(url, jdbc:mysql://192.168.1.10:3306/dish_db?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNull) \ .option(dbtable, orders) \ .option(user, spark_user) \ .option(password, your_password) \ .option(driver, com.mysql.cj.jdbc.Driver) \ .option(fetchsize, 1000) \ .load()这段代码有几个参数必须说清楚driver要写com.mysql.cj.jdbc.Driver而不是老版的com.mysql.jdbc.DriverMySQL 8.0以上用老驱动会直接报通信链接异常。url里的characterEncodingutf8决定了Spark拿到的中文不是乱码这个参数在3.x版本里和连接串里其他参数的位置无关但绝对不能省。fetchsize设为1000是让JDBC每次从MySQL拉取1000行而不是全部塞进内存对订单大表来说是常规做法。还有一个新手很容易忽略的问题上面这种写法Spark读MySQL默认只有一个分区也就是说数据量大时只有一个executor在干活并行度是假的。要真正并行读需要指定分区列和上下界orders_df spark.read.format(jdbc) \ .option(url, jdbc:mysql://192.168.1.10:3306/dish_db?...) \ .option(dbtable, orders) \ .option(user, spark_user) \ .option(password, your_password) \ .option(driver, com.mysql.cj.jdbc.Driver) \ .option(partitionColumn, id) \ .option(lowerBound, 1) \ .option(upperBound, 5000000) \ .option(numPartitions, 6) \ .load()partitionColumn必须是一个数值型的自增主键Spark会用WHERE id BETWEEN ? AND ?把查询拆成6段分给6个executor并行去MySQL拉数据。如果订单表的主键不是数字类型就需要在MySQL里先造一个自增序号列或者退而求其次接受单分区读取——课程设计数据量在百万行以下时单分区其实也能跑完只是慢一些。分析结果要写回MySQL也很简单把结果表按“先删后写”的方式输出result_df.write.format(jdbc) \ .option(url, jdbc:mysql://192.168.1.10:3306/dish_db?useUnicodetruecharacterEncodingutf8) \ .option(dbtable, recommend_result) \ .option(user, spark_user) \ .option(password, your_password) \ .option(driver, com.mysql.cj.jdbc.Driver) \ .mode(overwrite) \ .save()mode(overwrite)的本质是先drop整张表再写新数据相当于数据库里的删除加插入如果目标是增量更新应该用append模式但要注意append不会去重重复跑任务会累积出脏数据。项目里我一般把所有结果表都设计成“离线全量刷新”也就是每天overwrite一次逻辑最简单也最容易向评审老师解释清楚。3. 菜品特征分析从JSON日志到热度、时段和口味三个维度3.1 读取JSON订单流搞定schema推断、多行文本与中文编码餐饮平台除了关系型数据库里的订单还常有一路数据来自客户端埋点日志用户浏览了哪个菜品页面、在哪个页面停留了多久、最终下单了没有这些事件以JSON格式落盘。把JSON日志和MySQL订单结合起来分析才能得到完整的菜品热度而不只是“已下单”这个结果。要读JSON先用spark.read.json它支持自动推断schema听起来很省事但实际项目里JSON解析的坑大多藏在三个地方多行JSON、编码、时间字段类型推断。常见的埋点日志有两种组织方式一种是每行一条JSON叫单行JSON另一种是整文件是一个JSON数组或有嵌套大括号叫多行JSON。默认情况下spark.read.json只能处理单行JSON遇到多行JSON必须加上multiLineTrue否则整个文件读出来是几十万行全是null的脏数据。我见过不止一个同学在“spark中读取json”上翻车就是因为漏了这个参数跑出来的聚合结果全是0还以为是数据没采集到。处理这类日志时建议打开的开关和参数如下click_log spark.read.json( hdfs:///user/dish/logs/2025-06-01/*.json, multiLineTrue, encodingutf-8, inferSchemaTrue, samplingRatio1.0, dateFormatyyyy-MM-dd HH:mm:ss )samplingRatio这个参数新手容易忽略它默认是1.0也就是全量数据都用来推断字段类型。如果日志量特别大可以设成0.1让spark只抽样10%来推断schema加快读取速度但代价是某些字段可能被推断成string而不是timestamp后面做时间聚合时还要再cast。做课程设计级项目时我建议老老实实用1.0因为数据量还没大到需要采样推断的程度而且类型推断错了后面排查更浪费时间。JSON读取后要做一次数据质量检查这个习惯能帮你避开大量玄学问题。先看DataFrame的schema里有没有字段全为null的列再看user_id和dish_id有没有大量空值最后看中文内容是否出现乱码。中文乱码的典型表现是菜品名变成“è??±”这类不可读字符原因几乎都出在源文件的编码和读取时指定的encoding不一致上。日志文件如果是从Windows机器传上来的大概率是GBK编码直接用encodingutf-8读必然乱码。正确的做法是先看文件头或者用file命令确认编码读取时按实际编码指定。file /user/dish/logs/2025-06-01/part-00001.json如果输出里带ISO-8859或者Non-ISO extended-ASCII那基本可以确定是GBK或GB2312需要把读取参数改成encodinggbk。用Spark处理餐饮数据时中文编码问题算是最高频的踩坑点之一早检查早安心别等到聚合结果都出来了才发现菜品名是乱码那种返工最浪费时间。3.2 用Spark SQL做菜品热度与时段聚合三个必调参数菜品智能分析里最基础也最常被问到的产出物是三个维度热度榜、时段分布、口味偏好。热度榜不是简单count一下订单数就完事而是应该用sum(quantity)做加权因为一道菜被反复点说明它已经不是“尝鲜”而是“复购型”菜品权重理应更高。用Spark SQL写聚合非常直白orders_df.createOrReplaceTempView(orders) dish_df.createOrReplaceTempView(dishes) heat_sql SELECT d.dish_id, d.dish_name, d.category, COUNT(DISTINCT o.user_id) AS user_cnt, SUM(o.quantity) AS total_qty, ROUND(SUM(o.quantity) * 1.0 / COUNT(DISTINCT o.user_id), 2) AS qty_per_user FROM orders o JOIN dishes d ON o.dish_id d.dish_id WHERE o.order_time DATE_SUB(CURRENT_DATE, 30) GROUP BY d.dish_id, d.dish_name, d.category ORDER BY total_qty DESC LIMIT 50 heat_top50 spark.sql(heat_sql)这段SQL里qty_per_user是人均点餐份数它能区分“超多人点但每人只点一次”的尝鲜菜和“人数不多但反复点”的回头菜这个指标在后续做推荐过滤时非常有用。时段分布分析则要把order_time转换成小时再映射到就餐时段最方便的实现是CASE WHENtime_sql SELECT CASE WHEN HOUR(order_time) BETWEEN 6 AND 9 THEN breakfast WHEN HOUR(order_time) BETWEEN 10 AND 14 THEN lunch WHEN HOUR(order_time) BETWEEN 14 AND 17 THEN afternoon_tea WHEN HOUR(order_time) BETWEEN 17 AND 21 THEN dinner ELSE night_snack END AS time_bucket, dish_id, SUM(quantity) AS qty FROM orders WHERE order_time IS NOT NULL GROUP BY time_bucket, dish_id time_stats spark.sql(time_sql)做完聚合之后Spark任务里建议打开三个和shuffle相关的参数这三兄弟是保证聚合稳定不OOM的关键。spark.sql.shuffle.partitions决定shuffle时产生的分区数小数据集设8到16就够了默认200对小项目是浪费每个分区只分到几千行反而效率低。spark.sql.adaptive.enabled开启自适应查询执行Spark会运行时根据实际数据量自动合并过小的分区对课程设计这种数据量忽高忽低的任务非常友好。spark.sql.autoBroadcastJoinThreshold设置在join小表时自动做广播默认10MB如果菜品表很小建议设成52428800也就是50MB让菜品表直接广播到每个executor内存里orders和dishes的join就会从shuffle join自动变成map join速度能差出一个量级。口味偏好的分析要关联dishes表里的spice_level字段比如把辣度分成0到5档统计用户对不同辣度菜品的历史点餐占比。这个输出会直接用作推荐阶段的“口味过滤”假设某个用户80%的订单都是不辣菜品那么即使ALS模型推荐了某个辣度偏高的菜也应该在下游规则层把它过滤掉否则推荐结果就算“算法上正确”用户也会觉得不准。口味特征不一定要做得复杂一个用户维度的辣度均值加一个点餐次数就够了为后面过滤提供依据时简单特征比复杂特征更可解释。4. 推荐算法落地ALS协同过滤与FP-Growth组合拳4.1 构建用户-菜品评分矩阵把隐式反馈变成ALS能吃的格式菜品推荐的常规做法是先跑协同过滤再叠加关联规则。协同过滤用ALS算法它需要的输入是标准的(user_id, dish_id, rating)三元组。但真实餐饮场景里的问题在于ratings表几乎永远是空的用户不会像视频平台那样给菜打分。所以这里必须从订单数据构造“隐式反馈评分”用自己的逻辑告诉模型一个用户有多喜欢一道菜。我一般用三个信号叠加30天内的点餐次数、菜品单价、时间衰减。点餐次数是最核心的信号单价做一个对数压缩防止贵的菜天然占优时间衰减用来让最近两周的行为权重高于一个月前的行为。构造逻辑写成PySpark就是groupBy加聚合from pyspark.sql import functions as F train_df orders_df.filter( orders_df.order_time 2025-01-01 ).groupBy(user_id, dish_id).agg( F.count(*).alias(cnt), F.sum(quantity).alias(qty), F.max(order_time).alias(last_order_time) ).join( dishes_df.select(dish_id, price), ondish_id, howleft ) # 核心隐式反馈评分 log1p(点餐次数) log1p(单价) * 0.3 train_df train_df.withColumn( score, F.log1p(qty) F.log1p(price) * 0.3 ).select(user_id, dish_id, score)构造评分时有两个容易被忽略的细节。第一count(*)不如sum(quantity)合适因为一单点两份排骨和两单各点一份排骨前者代表更强的偏好用数量能区分开来。第二价格权重要不要加取决于你的推荐目标如果目标是提高客单价价格权重可以加大如果目标是提高点击转化率价格权重反而会干扰因为用户点不点一道菜和它贵不贵没有必然关系。课程设计里我建议保留0.3这个低权重同时把这段加权逻辑写进文档里答辩时老师问起来你能讲清楚“每个参数为什么存在”这就比只会调库的代码值钱得多。4.2 ALS训练与Top-N推荐rank、maxIter、regParam怎么设ALS在MLlib里的接口很简洁但参数不在代码量上而在你怎么设值。固定写法如下from pyspark.ml.recommendation import ALS als ALS( userColuser_id, itemColdish_id, ratingColscore, implicitPrefsTrue, alpha10.0, rank20, maxIter15, regParam0.1, coldStartStrategydrop ) model als.fit(train_df) # 给每个用户推荐10道菜 user_recs model.recommendForAllUsers(10)先说implicitPrefsTrue这个开关是专门给隐式反馈数据准备的因为隐式反馈的评分不是真正的打分而是“点过几次、点了多少份”这种统计量模型内部会把它当成置信度来处理。如果你构造的score是基于次数的这个开关必须打开否则模型会把score当成显式评分结果会严重偏向“评分高”的极少数用户。与之配套的是alpha它控制隐式反馈的置信度缩放默认1.0在电商场景下够用但餐饮点餐次数普遍偏小我通常调到5到15之间。rank控制用户和菜品特征向量的维度rank太小模型表达力不够太大在数据量不够时过拟合。maxIter是迭代次数15到20之间一般能收敛一味加大只会让训练时间变长精度提升很有限。regParam是正则化系数防止模型在稀疏矩阵上过拟合0.1是个稳妥的起点后面调优时在0.01到0.5之间试。训练好之后model.recommendForAllUsers(10)会返回一个DataFrame里面recs列是每个用户的推荐菜品数组。这里有一个隐藏问题推荐列表是算法原样输出没有做任何业务过滤。实际使用中我会把推荐结果展开成行再和上一章算出来的口味偏好做过滤把用户明确不吃的辣度档次直接剔除然后再和菜品热度榜做一个加权融合最终才写回结果表。推荐系统不能只靠算法模型规则层兜底往往才是用户体验的胜负手。4.3 FP-Growth挖掘套餐组合支持度与置信度怎么挑ALS解决的是“这个用户喜欢什么菜”FP-Growth解决的是“哪些菜经常一起被点”。后者直接产生套餐推荐用户下单时发现推荐组合里有一道他历史没点过的菜但和另一道他常点的菜强关联下单概率会明显提升。FP-Growth的输入不是三元组而是一个用户一个交易行这个交易行在餐饮场景里定义为“同一天同一个用户点的所有菜品集合”。from pyspark.ml.fpm import FPGrowth # 构造交易数据同一天同一个用户点的菜品列表 transactions orders_df.groupBy(user_id, F.to_date(order_time).alias(dt)) \ .agg(F.collect_set(dish_id).alias(items)) fp FPGrowth( itemsColitems, minSupport0.02, minConfidence0.2 ) fp_model fp.fit(transactions) # 查看频繁项集和关联规则 freq_itemsets fp_model.freqItemsets association_rules fp_model.associationRulesminSupport的含义是“一组菜品在所有交易中出现的最低比例”设太低会产出大量噪声规则设太高则挖掘不到东西。餐饮场景下如果总交易量在十万级0.02是一个合理的起点也就是一组菜品组合至少出现2000次才会被纳入候选。minConfidence表示在用户点了A的前提下去推荐B的可信度0.2听起来很低但在菜品组合里已经是有意义的水平因为餐饮不像零售点菜组合的重复率本身不高设到0.5以上几乎挖不出规则。训练完以后把所有规则装入一个Map广播出去结合当天订单实时决定展示哪个套餐这套逻辑非常经典。FP-Growth的结果要跟ALS结果做融合才能避免推荐列表全是“用户常吃的菜”。ALS倾向于推荐和用户历史偏好相似的东西FP-Growth倾向于推荐“和用户正在点的菜搭着卖”的东西两者结合覆盖了两类完全不同的推荐需求。我的经验是首页推荐列表按70% ALS加30%热度补位下单页套餐推荐直接走FP-Growth规则这个配比在多数餐饮项目里都比单模型效果好。5. 避坑章节Spark菜品分析全链路最常见的五个翻车现场5.1 MySQL驱动ClassNotFound驱动jar到底该放哪现象是代码在IDEA里跑得好好的打包成jar提交到集群就报ClassNotFoundException: com.mysql.cj.jdbc.Driver。原因很简单Spark集群的executor节点上根本没有MySQL驱动类而--jars参数如果加得不对驱动只在driver端生效executor端拉数据时依然找不到类。解决方法是提交任务时把driver和executor的classpath都配上spark-submit \ --master yarn \ --deploy-mode cluster \ --jars /opt/libs/mysql-connector-java-8.0.33.jar \ --driver-class-path /opt/libs/mysql-connector-java-8.0.33.jar \ --class com.dishrecommend.analysis.ETLJob \ dish-recommend-1.0.jar关键点在于--driver-class-path负责driver端--jars负责executor端两者都要。如果集群HDFS上已经有这个jar可以换成--jars hdfs:///libs/mysql-connector-java.jar这样每个节点从HDFS拉取不用手动拷到每台机器。驱动版本尽量和MySQL服务端版本大版本一致MySQL 8.0配8.0.x驱动避免连上了但握手协议报错。5.2 executor内存反复溢出分区数、序列化与offHeap现象是任务跑一半YARN界面上一排红色日志报java.lang.OutOfMemoryError: Java heap space或者GC overhead limit exceeded。原因通常是两个一是spark.sql.shuffle.partitions设置过大每个分区内的数据太少但task数量太多每个task都要启动一个JVM里的线程内存管理开销爆掉二是缓存了太多DataFrame后没有及时unpersist。解决先从分区数下手如果你只有2个executor、每个4G内存把shuffle分区数设在8到16之间不要用默认200。再用Kryo序列化替代Java序列化在SparkSession初始化时加上spark.conf.set(spark.serializer, org.apache.spark.serializer.KryoSerializer)序列化器对内存占用的影响往往被忽视Java序列化在数据量大时能吃掉比业务数据还多的内存。最后如果还觉得内存紧可以开offHeapspark.conf.set(spark.memory.offHeap.enabled, true) spark.conf.set(spark.memory.offHeap.size, 2g)注意offHeap内存不计入executor的heap它是独立的要确保每台物理机能给这么多额外内存。另外在缓存DataFrame后这个缓存一定要在任务结束前主动unpersist()否则长任务链里前一阶段的缓存一直占着内存后面的join和groupBy就没内存可用这是最常见的隐性问题。5.3 中文乱码与JSON解析失败编码、Schema与采样推断现象是JSON里把菜品名读出来是“三文é”或者某些日期字段读出来是一串时间戳数字。原因分两类文件本身不是UTF-8或者JSON文件是多行结构但忘了开multiLine。处理方式是先确认编码再读取读完立刻打印schema检查字段类型看看有没有哪个字符串字段被推断成binary。最容易翻车的是时间字段如果日志里时间格式是2025-06-01 12:30:00Spark推断出来的类型通常是timestamp没问题但如果某些行的时间戳格式变成2025-06-01整个字段会被推断成date后续做hour()函数直接报错。预防办法是读取时显式指定dateFormat或者在SQL里统一对时间字段做CAST(order_time AS TIMESTAMP)不要依赖推断结果。对于必要字段更好的做法是干脆在自己的代码里定义schema绕开推断比如json里嵌套了菜品列表属性时定义一个StructType能让你提前发现数据结构变化而不是等聚合结果全是null再排查。5.4 数据倾斜一个爆款菜拖垮整个reduce阶段现象是groupBy dish_id的时候其他任务几秒跑完唯独一个任务卡了十几分钟最后超时失败。原因是一个爆款菜品的数据量占了总量的30%shuffle时按照dish_id哈希落到了同一个分区这个分区的executor被活活压死这就是典型的数据倾斜。解决有两板斧。第一板斧是先做两阶段聚合解决键倾斜问题第一次按dish_id加一个随机前缀做部分聚合第二次去掉前缀再聚合一次这样热点key的数据被分散到多个分区先算一遍最后合并结果。第二板斧是针对join倾斜把热点dish的大表数据单独拆出来广播处理非热点的走正常join。用算式描述的话两阶段聚合是“先打散再聚合”广播join是“热点走内存非热点走shuffle”。如果任务确实只是课程设计数据量倾斜未必会触发但既然要做高分项目把这个优化写进设计文档能让答辩质量上一个档次。5.5 评分矩阵全1问题隐式反馈的“评分”不是评分现象是ALS训练完以后推荐给所有用户的菜品几乎完全一样全是热门菜。原因在于隐式反馈处理不当你构造的score如果要么是1要么是0比如直接用count(*)作为rating但没做任何归一化模型学到的信息量非常低所有有过点餐行为的“1”都长一个样模型只能学到流行度学不到个性化差异。解决的关键是把评分从“是否点过”变成“点过多少次、最近多频繁、对该菜品的偏好在全局中处于什么水平”。我用的是log1p(qty) 0.3 * log1p(price)再加上时间衰减系数让最近7天的行为权重是30天前行为的两倍。另一个关键是把implicitPrefsTrue打开并在alpha上做调整——这个配置组合才是隐式反馈真正生效的条件。如果你看完推荐结果发现还是偏热门检查一下是不是训练数据里存在极端不平衡大量用户只有一两条记录少数用户有几百条记录。这时要对用户侧做截断比如每个用户最多保留最近50条订单行为防止少数重度用户主导整个模型的向量空间。6. 从跑通到可信离线评估与参数寻优的实测路径模型训练出来、推荐结果写回数据库项目只能算跑通还不能算有效。要证明它真的有用得做离线评估。做法是把时间切成两段用过去30天数据训练用最近7天的实际点餐行为做验证。核心指标有两个命中率验证集里用户实际点的菜有多少出现在推荐Top-N里覆盖率推荐列表里覆盖了多少种不同菜品。命中率防止模型完全不准覆盖率防止模型退化成“只推爆款”的偷懒方案这两个指标要一起看只盯命中率会让推荐结果越来越窄。参数寻优不要靠感觉乱试用网格搜索加交叉验证更靠谱。ALS里最值得调的就是rank、regParam、alpha三件套固定maxIter为15rank在10、20、30里选regParam在0.01、0.1、0.5里选alpha在5、10、15里选用ParamGridBuilder配合TrainValidationSplit跑一轮基本能找到比默认参数好一截的组合。冷启动则是任何推荐系统都绕不开的硬骨头新用户没有历史行为直接用ALS推荐结果一定是空的我一般用三层兜底——按热门榜推荐、按用户注册时选择的偏好标签过滤、按地域菜品类别做多样性插入至少保证新用户看到的东西不突兀。做推荐系统最容易犯的错就是把它当成黑匣子不看指标直接调参。我自己吃过这个亏刚开始做菜品推荐时只盯着命中率调完参数命中率确实涨了但覆盖率掉到了惨不忍睹的10%整个推荐列表翻来覆去就是那几道热门菜业务方一看就说这功能没有价值。后来老老实实同时观察命中率和覆盖率发现真正的瓶颈不在模型参数而在数据预处理阶段的隐式评分构造。从那以后我养成了一个习惯任何推荐项目先跑通评估脚本再碰参数顺序不能反。希望帮到你。本文还有配套的精品资源点击获取