本文还有配套的精品资源点击获取简介这个资源包提供了一套端到端可运行的电影推荐系统实践方案。数据源头是Windows 11环境下编写的Python爬虫自动抓取豆瓣等平台的电影基础信息与用户评分数据经清洗后批量写入Ubuntu 20.04系统中的MySQL 5.7数据库核心推荐逻辑运行在本地VMware虚拟机搭建的Spark伪分布式集群上依赖Hadoop HDFS作为底层存储支持ALS协同过滤算法训练与实时推荐生成前端由Django框架驱动包含用户登录、电影浏览、个性化推荐列表及评分反馈功能界面采用Bootstrap实现适配PC与移动端的响应式布局整个工程按模块划分清晰——Spider_data负责数据采集、Spark_Recommend封装推荐计算流程、webapp和adminapp分别支撑前台展示与后台管理所有代码在PyCharm中开发调试配套文档含系统实现.docx、README.md详细说明了Ubuntu环境配置、Hadoop/Spark/MySQL/Django各组件安装步骤、数据流向图、关键接口定义及单机伪分布式部署方法也预留了向真实YARN集群迁移的配置接口适合用于高校课程设计、大数据实训或SparkPython全栈推荐系统入门学习。1. 这不是Demo是能跑通的电影推荐流水线从豆瓣爬到Django首页展示你有没有试过在本地搭一个“看起来像生产环境”的推荐系统不是Jupyter里跑个ALS模型就叫推荐系统而是真正从网页上把数据抓下来、存进数据库、用Spark集群算出结果、再通过Web界面让用户点开就能看到“猜你喜欢”的完整闭环。这个项目就是干这个的——它不追求算法有多前沿但每一步都踩在工程落地的实操节点上Windows下写的爬虫能稳定采集豆瓣电影的片名、导演、类型、用户评分和评论数Ubuntu虚拟机里MySQL 5.7不是只装个服务而是建了movies、users、ratings三张表字段设计考虑了后续Spark读取时的类型对齐比如rating存为DECIMAL(3,2)避免float精度漂移Spark不是单机local模式硬扛而是在VMware里配了Hadoop 3.2.1伪分布式NameNode DataNode同机让Spark SQL能真正走HDFS路径读写中间特征Django也不是只写个views.py返回JSON而是做了用户会话管理、评分提交异步落库、推荐结果缓存策略连Bootstrap的栅格系统都按移动端优先重写了响应式卡片布局。关键词里的Spark推荐、Python爬虫、Django Web、MySQL存储不是并列的四个技术名词而是数据在这四者之间真实流动的轨道爬虫吐出CSV → MySQL入库 → Spark从MySQL抽特征训练模型 → 模型预测结果写回MySQL → Django定时查表渲染首页。我第一次把这套流程在自己笔记本上跑通时特意关掉PyCharm的调试器只留终端黑窗和浏览器看着“用户ID 123”点击“刷新推荐”后页面3秒内刷出5部他没看过但相似用户打分超8.5的冷门佳作——那一刻才明白什么叫“端到端可运行”。它适合谁不是冲着发论文去的算法研究员而是正在准备大数据课程设计的学生、想补全Python全栈能力的后端新人、或者需要给客户演示“我们真能做推荐”的解决方案工程师。它不教你SVD或LightGCN但它会告诉你为什么爬虫要加随机User-Agent和请求间隔、为什么Spark读MySQL必须显式指定partitionColumn、为什么Django的select_related()比两次query快3倍——这些细节才是文档里不会写、但上线第一天就会卡住你的地方。2. 全流程架构设计与模块职责拆解为什么这样切分而不是其他方式2.1 四大模块不是随意命名而是按数据生命周期严格划分整个系统被划分为Spider_data、Spark_Recommend、webapp、adminapp四个独立目录表面看是代码组织习惯实则是对数据流阶段的精准切割。我最初也试过把爬虫逻辑塞进Django的management commands里结果调试时发现爬虫失败会导致Web服务重启而Spark训练又依赖爬虫产出的最新数据——三个环节耦合在一起改一行代码就得全量测试。后来彻底拆开每个模块只专注一件事Spider_data纯数据获取层。它不碰数据库连接池配置不处理缺失值填充逻辑只做最原始的HTTP请求、HTML解析、字段提取。输出是干净的movies.csv、ratings.csv两个文件字段名与MySQL目标表完全一致如movie_id,user_id,rating,timestamp。这里的关键设计是状态隔离爬虫每次运行前先清空临时目录成功后才移动文件到data/raw/失败则保留日志供人工排查。这种“原子性”保证了下游模块永远拿到的是完整批次数据避免Spark读到半截CSV。Spark_Recommend计算核心层。它不关心数据从哪来、到哪去只接收两个参数--input-path hdfs://localhost:9000/data/ratings/和--output-path hdfs://localhost:9000/output/recommends/。所有与MySQL交互的逻辑如从ratings表抽取训练集被封装成独立的JDBCReader工具类且强制要求传入numPartitions4——这是根据我的虚拟机4核CPU反推的分区数太少Spark任务无法并行太多则小文件过多拖慢HDFS。模型训练完预测结果不是直接存HDFS而是通过DataFrameWriter的mode(overwrite)写回MySQL的recommendations表但写入前会先执行TRUNCATE TABLE recommendations确保旧推荐不会残留。这种“计算即服务”的设计让Spark作业可以脱离Django单独调度比如用crontab每天凌晨跑一次。webapp用户交互层。它只做三件事渲染首页含登录态判断、接收用户评分POST请求、查询recommendations表返回JSON。所有业务逻辑都在views.py里没有调用Spark API也没有直连HDFS。当用户点击“给这部电影打分”视图函数只做两件事1校验用户是否已登录Django自带session2将user_id,movie_id,rating插入MySQL的ratings表。至于这个新评分要不要触发模型重训不归它管——那是运维脚本的事。adminapp后台支撑层。它不提供前端页面只暴露两个关键接口/admin/update-model/手动触发Spark训练和/admin/clear-cache/清空Django的Redis缓存。这两个接口都加了staff_member_required装饰器确保只有管理员能访问。特别注意update-model接口的实现它不是直接os.system(spark-submit ...)而是启动一个子进程并实时捕获stdout写入Django日志这样在Admin后台就能看到Spark任务的进度条如INFO DAGScheduler: Job 0 finished: count at ALS.scala:XXX。这种模块划分的根本逻辑是让每个环节的失败域可控。爬虫挂了不影响Web展示推荐结果还是昨天的Spark训练卡死不会导致用户无法登录Django模板报错也不会让MySQL数据损坏。我在VMware里故意模拟过各种故障拔掉网线让爬虫超时、杀掉DataNode进程让Spark读HDFS失败、删掉Django的db.sqlite3文件——每次都能准确定位到哪个模块出了问题而不是面对一整坨代码无从下手。2.2 为什么选伪分布式HadoopSpark而不是直接用MySQL做计算很多人看到“推荐系统”第一反应是“既然数据都在MySQL里为啥不直接用SQL写协同过滤”比如用窗口函数算用户平均分再关联电影表求余弦相似度。这在百万级数据下确实可行但这个项目坚持用HadoopSpark理由很实际数据规模预判豆瓣公开数据约20万部电影、5000万用户评分。本地MySQL单表存5000万行没问题但执行SELECT u1.user_id, u2.user_id, COUNT(*) FROM ratings u1 JOIN ratings u2 ON u1.movie_id u2.movie_id WHERE u1.user_id ! u2.user_id GROUP BY u1.user_id, u2.user_id HAVING COUNT(*) 20这种用户相似度计算MySQL会爆内存我试过8GB内存的虚拟机直接OOM。而Spark的RDD.cartesian()虽然也耗资源但可以通过repartition(100)把大任务切碎让4核CPU轮流处理。算法扩展性ALS交替最小二乘法是Spark MLlib原生支持的只需几行代码就能调参。如果未来要换DeepFM或Graph Neural NetworkSpark生态有现成的spark-deep-learning或graphframes库而纯SQL方案得重写整个计算引擎。存储与计算分离HDFS作为底层存储让Spark可以随时切换计算引擎。比如某天发现ALS训练太慢想试试Flink的Gelly图计算库只要保持HDFS路径不变数据不用动。而MySQL既是存储又是计算换引擎就得导出导入数据。当然伪分布式不是银弹。我在配置Hadoop时踩过最大的坑是VMware虚拟机默认的/etc/hosts里把127.0.0.1映射到localhost但Hadoop要求core-site.xml里的fs.defaultFS必须指向一个可被所有节点解析的主机名。我最初写hdfs://localhost:9000结果Spark任务总报Connection refused。解决方法是在/etc/hosts里加一行127.0.0.1 mycluster然后core-site.xml里写hdfs://mycluster:9000同时hdfs-site.xml里的dfs.namenode.http-address也改成mycluster:9870。这个细节文档里很少提但不改就永远起不来NameNode。2.3 Django为何不直接调用Spark而选择“计算结果落库Web查库”模式这是整个架构里最常被质疑的设计。有人会说“Django里直接from pyspark.sql import SparkSession不就行了吗何必多此一举写回MySQL”答案是工程稳定性压倒开发便利性。首先SparkContext是重量级对象初始化要10秒以上尤其在虚拟机里。如果每个用户请求都新建一个SparkSessionDjango的WSGI服务器我用的是uWSGI会瞬间被占满线程用户看到的就是504 Gateway Timeout。其次Spark的Driver进程内存占用大我设了--driver-memory 2g而Django通常部署在内存有限的Web服务器上两者抢内存必然崩溃。更关键的是错误隔离。假设Spark训练时遇到脏数据比如某条评分是NULL它会抛出AnalysisException。如果这个异常发生在Django视图里整个Web请求就失败了用户看到白屏。而当前模式下Spark作业是独立进程异常只影响本次训练Django依然能正常返回缓存的旧推荐结果。我在Spark_Recommend的主脚本里加了完整的try-catchtry: model ALS( rank10, maxIter10, regParam0.01, userColuser_id, itemColmovie_id, ratingColrating ).fit(training_df) predictions model.recommendForAllUsers(5) # 每个用户推荐5部 predictions.write \ .format(jdbc) \ .option(url, jdbc:mysql://localhost:3306/movie_db) \ .option(dbtable, recommendations) \ .option(user, root) \ .option(password, 123456) \ .mode(overwrite) \ .save() except Exception as e: logger.error(fSpark training failed: {str(e)}) # 不抛出异常确保Django不受影响最后这种模式天然支持A/B测试。比如我想对比ALS和基于内容的推荐效果只需在MySQL里建两张表recommendations_als和recommendations_contentDjango的视图函数根据URL参数动态切换查询表名完全不用动Spark代码。这种灵活性是紧耦合方案永远做不到的。3. 核心模块实操详解从爬虫防封到Spark参数调优的硬核细节3.1 Python爬虫模块Spider_data如何让豆瓣不把你当机器人封IP豆瓣的反爬机制在2023年升级后相当严格没有Referer的请求直接返回403高频请求会触发验证码甚至同一IP连续访问100次就限流。Spider_data模块不是简单用requests.get()而是构建了一套轻量级反爬策略User-Agent轮换池不只设一个UA而是维护一个列表python USER_AGENTS [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Safari/605.1.15, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 ]每次请求随机选一个避免被识别为固定脚本。Referer强制携带豆瓣要求访问电影详情页必须从搜索页跳转。所以爬虫先GET搜索页https://movie.douban.com/subject_search?search_text科幻cat1002解析出前20个电影的subject_id如1292052再拼接详情页URLhttps://movie.douban.com/subject/1292052/并在headers里带上Referer: https://movie.douban.com/subject_search?search_text科幻cat1002。请求间隔动态化不是固定time.sleep(1)而是用指数退避python import random base_delay 1.5 jitter random.uniform(0.5, 1.5) delay base_delay * (2 ** attempt) * jitter # 第一次1.5s第二次3s第三次6s... time.sleep(delay)当遇到429 Too Many Requests时attempt自增下次延迟翻倍避免被永久拉黑。数据清洗前置爬到的rating字段常是“8.6”或“暂无评分”爬虫脚本里直接处理python def clean_rating(raw_str): if 暂无评分 in raw_str: return None try: return float(raw_str.strip()) except ValueError: return None这样写入MySQL时rating列直接是NULLSpark读取时用na.drop()就能干净过滤不用在计算层再做类型转换。最关键的实战技巧永远先爬小数据集验证逻辑。我第一次写爬虫时直接设了爬1000部电影结果跑了2小时发现豆瓣返回的HTML结构变了新版加了script动态渲染所有解析都失效。后来改成先爬https://movie.douban.com/subject/1292052/《阿凡达》这一页用BeautifulSoup打印出所有span propertyv:average标签确认XPath路径//strong[propertyv:average]/text()有效再扩展到批量。这个习惯让我少踩了80%的结构性错误。3.2 Spark推荐模块Spark_RecommendALS算法参数怎么调不是靠猜ALS是协同过滤的经典算法但它的三个核心参数rank、maxIter、regParam没有标准答案必须结合数据分布实测。我的训练集是豆瓣2023年公开的100万条评分ratings.csv用户数约20万电影数约5万。调参过程如下rank隐语义向量维度理论值在10-200之间。我测试了rank5,10,20,50rank5训练快2分钟但RMSE1.23推荐结果过于泛化总推热门片rank10RMSE0.98训练时间4分钟推荐多样性好rank20RMSE0.95但训练时间跳到12分钟边际收益递减rank50RMSE0.94但内存溢出java.lang.OutOfMemoryError: Java heap space。最终选rank10平衡精度与资源消耗。maxIter迭代次数ALS是迭代优化maxIter太少模型欠拟合。我监控了每次迭代的损失函数Iteration 1: RMSE1.45 Iteration 2: RMSE1.12 Iteration 5: RMSE1.01 Iteration 10: RMSE0.98 ← 停止再迭代下降不到0.01所以maxIter10足够设更高只是浪费CPU。regParam正则化系数防止过拟合。测试0.001, 0.01, 0.10.001RMSE0.92但预测结果方差大同一用户对不同电影的预测分差达3分0.01RMSE0.98方差合理分差1.5分0.1RMSE1.15过度平滑所有预测分都挤在7.0-7.5。选regParam0.01。实操中还有一个致命细节Spark读MySQL必须指定分区列。否则默认单任务读全表大数据量时卡死。我的ratings表有主键id但id是自增整数分布不均新数据id大老数据id小。更好的选择是user_id因为用户评分相对均匀。所以读取代码是ratings_df spark.read \ .format(jdbc) \ .option(url, jdbc:mysql://localhost:3306/movie_db) \ .option(dbtable, ratings) \ .option(user, root) \ .option(password, 123456) \ .option(partitionColumn, user_id) \ .option(lowerBound, 1) \ .option(upperBound, 200000) \ .option(numPartitions, 4) \ .load()lowerBound和upperBound必须手动查MySQL得到SELECT MIN(user_id), MAX(user_id) FROM ratings;。漏掉这一步Spark会报IllegalArgumentException: Partition column user_id has null values。3.3 Django Web模块webapp如何让推荐结果秒开而不是等Spark计算用户最不能忍的就是点“刷新推荐”后转圈10秒。webapp的优化核心是缓存异步降级Redis缓存推荐结果Django默认用数据库缓存但MySQL读写慢。我配了Redispython CACHES { default: { BACKEND: django_redis.cache.RedisCache, LOCATION: redis://127.0.0.1:6379/1, OPTIONS: { CLIENT_CLASS: django_redis.client.DefaultClient, } } }在views.py里python def get_recommendations(request): user_id request.session.get(user_id) cache_key frec_{user_id} recommendations cache.get(cache_key) if not recommendations: # 从MySQL查recommendations表 recommendations list(Recommendation.objects.filter(user_iduser_id).values()) cache.set(cache_key, recommendations, 300) # 缓存5分钟 return JsonResponse({data: recommendations})异步评分提交用户打分时不等写入MySQL完成就返回成功pythonfrom django_rq import jobjobdef save_rating_async(user_id, movie_id, rating):Rating.objects.create(user_iduser_id, movie_idmovie_id, ratingrating)def submit_rating(request):if request.method ‘POST’:user_id request.session.get(‘user_id’)movie_id request.POST.get(‘movie_id’)rating request.POST.get(‘rating’)save_rating_async.delay(user_id, movie_id, rating) # 异步执行return JsonResponse({‘status’: ‘success’})降级策略当Redis宕机或MySQL查询超时返回兜底推荐如按豆瓣评分排序的Top 10python try: recommendations cache.get(cache_key) if not recommendations: recommendations get_from_mysql(user_id) except Exception as e: logger.warning(fCache/DB error, fallback to hot movies: {e}) recommendations Movie.objects.order_by(-douban_rating)[:10]这些优化让首页加载时间从8秒降到300毫秒以内。我在Chrome DevTools里对比过未优化前Network面板显示get-recommendations耗时7.8s优化后稳定在280ms左右且TTFBTime to First Byte小于50ms。3.4 MySQL存储设计为什么字段类型和索引这样选数据库不是随便建表就行。movie_db的三张核心表设计直指Spark和Django的性能痛点movies表sql CREATE TABLE movies ( id INT PRIMARY KEY AUTO_INCREMENT, douban_id VARCHAR(20) NOT NULL UNIQUE, -- 豆瓣ID字符串因含字母 title VARCHAR(255) NOT NULL, director VARCHAR(100), genres VARCHAR(255), -- 存逗号分隔如剧情,爱情,同性 douban_rating DECIMAL(3,2), -- 精确到0.01避免float误差 year YEAR, INDEX idx_genre (genres(50)) -- 前缀索引加速LIKE查询 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;ratings表Spark训练主力sql CREATE TABLE ratings ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, movie_id INT NOT NULL, rating DECIMAL(3,2) NOT NULL, -- 同movies表保证Spark读取类型一致 timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_movie (user_id, movie_id), -- 联合索引加速Spark的JOIN INDEX idx_movie (movie_id) -- 加速按电影查所有评分 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;recommendations表Django查询主力sql CREATE TABLE recommendations ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, movie_id INT NOT NULL, predicted_rating DECIMAL(3,2) NOT NULL, rank TINYINT NOT NULL, -- 推荐序号1-5 UNIQUE KEY uk_user_rank (user_id, rank), -- 确保每人每序号唯一 INDEX idx_user (user_id) -- 加速Django按用户查 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;关键设计点-rating字段统一用DECIMAL(3,2)Spark读MySQL时如果MySQL是FLOATSpark会转成DoubleType但计算时可能有精度丢失如0.10.2≠0.3。DECIMAL能保证数值精确。-ratings表的联合索引idx_user_movieSpark执行training_df.join(movie_df, movie_id)时MySQL能用此索引快速定位避免全表扫描。-recommendations表的UNIQUE KEY uk_user_rank确保Spark写入时不会重复INSERT IGNORE或ON DUPLICATE KEY UPDATEDjango查时Recommendation.objects.filter(user_id123).order_by(rank)能走索引。我在MySQL里执行过对比测试没建idx_user_movie时Spark读ratings表耗时23秒建了之后降到3.2秒。这就是索引的价值——不是锦上添花而是性能生死线。4. 全流程部署与排障实录从VMware网络配置到Django静态文件4044.1 VMware虚拟机网络配置为什么桥接模式比NAT更可靠很多新手在VMware里配Ubuntu时选NAT模式结果Spark任务连不上HDFS。根本原因是NAT模式下虚拟机对外是一个IP但Hadoop的core-site.xml里fs.defaultFS配置的是hdfs://mycluster:9000而mycluster在宿主机Windows的C:\Windows\System32\drivers\etc\hosts里必须解析到虚拟机IP。NAT模式下虚拟机IP是192.168.x.x但宿主机无法直接ping通这个IPNAT是单向翻译。解决方案是桥接模式Bridged在VMware设置里虚拟机网络适配器选“桥接模式”复制物理网络连接。Ubuntu启动后用ip a查到IP是192.168.1.105假设。在Windows的hosts文件里加192.168.1.105 mycluster。在Ubuntu的/etc/hosts里也加192.168.1.105 mycluster。这样无论是Windows上的PyCharm调试Django还是Ubuntu里的Spark都能通过mycluster解析到正确IP。我试过NAT模式下强行配/etc/hosts结果Spark报java.net.UnknownHostException: mycluster因为Hadoop的RPC通信需要双向解析。4.2 Django静态文件404为什么collectstatic后CSS还是不生效Django开发时用DEBUGTrue静态文件由开发服务器自动处理。但部署到生产环境DEBUGFalse后必须用python manage.py collectstatic把所有App的static/文件合并到STATIC_ROOT。常见错误忘记在settings.py里配置STATIC_ROOTpython STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] # 开发时找static目录 STATIC_ROOT BASE_DIR / staticfiles # 部署时collectstatic的目标如果漏了STATIC_ROOTcollectstatic会报错You have not set the STATIC_ROOT setting yet.Nginx没配静态文件路由Django不直接服务静态文件需Nginx代理。我的nginx.conf片段nginx location /static/ { alias /home/ubuntu/Movie_Recommendation_Spark_Django/staticfiles/; expires 1y; add_header Cache-Control public, immutable; }注意alias末尾的/必须有否则路径拼接错误。Bootstrap CSS路径写错Django模板里必须用{% load static %}然后link href{% static css/bootstrap.min.css %} relstylesheet。如果写成link href/static/css/bootstrap.min.css在非根路径部署时如https://example.com/movie/会404。我踩过的最深的坑是collectstatic后staticfiles/目录权限不对。Ubuntu下Nginx用户是www-data但collectstatic生成的文件属主是ubuntu导致Nginx读不了。解决命令sudo chown -R www-data:www-data /home/ubuntu/Movie_Recommendation_Spark_Django/staticfiles/ sudo chmod -R 755 /home/ubuntu/Movie_Recommendation_Spark_Django/staticfiles/4.3 Spark任务提交失败ClassNotFoundException的终极排查法Spark-submit时报java.lang.ClassNotFoundException: org.apache.spark.sql.DataFrameReader这是典型的依赖冲突。原因和解法现象在PyCharm里跑spark-submit命令成功但在Ubuntu终端里失败。原因PyCharm的Python解释器里装了pyspark包pip install pyspark它自带Spark JAR而终端里用的是系统Python没装pyspark所以找不到类。解法统一用Spark自带的pyspark。在Spark_Recommend目录下不运行python main.py而是bash # 进入Spark安装目录 cd /opt/spark # 用Spark自带的Python执行 ./bin/spark-submit \ --master local[*] \ --jars /opt/mysql-connector-java-8.0.33.jar \ /home/ubuntu/Movie_Recommendation_Spark_Django/Spark_Recommend/main.py \ --input-path hdfs://mycluster:9000/data/ratings/ \ --output-path hdfs://mycluster:9000/output/recommends/关键是--jars参数指定MySQL驱动否则Spark找不到JDBC类。另一个坑Hadoop和Spark版本不匹配。我最初装Hadoop 3.3.6Spark 3.2.1结果spark-submit报java.lang.NoClassDefFoundError: org/apache/hadoop/fs/FileSystem。降级Hadoop到3.2.1后解决。版本兼容表官网有但新手常忽略。4.4 常见问题速查表按发生频率排序的TOP5故障问题现象根本原因快速定位命令解决方案爬虫被豆瓣封IP请求头缺失或频率过高curl -I https://movie.douban.com/查响应头检查User-Agent、Referer是否设置增加time.sleep()换代理IP注本项目不涉及代理仅用合法反爬Spark读MySQL报“Access denied”MySQL用户权限不足mysql -u root -p -e SELECT User,Host FROM mysql.user;GRANT ALL PRIVILEGES ON movie_db.* TO root% IDENTIFIED BY 123456; FLUSH PRIVILEGES;Django Admin后台空白静态文件未收集或Nginx未代理ls -l /home/ubuntu/.../staticfiles/运行python manage.py collectstatic检查Nginx配置中alias路径HDFS启动后NameNode不工作/etc/hosts解析失败ping mycluster确保/etc/hosts和Windowshosts都配了192.168.x.x mycluster推荐结果全是NULLSpark写MySQL时字段类型不匹配SELECT * FROM recommendations LIMIT 5;检查Spark DataFrame的schemapredictions.printSchema()确保predicted_rating是DecimalType(3,2)提示所有问题排查的第一步永远是看日志。Spark日志在/opt/spark/logs/Django日志在/home/ubuntu/Movie_Recommendation_Spark_Django/logs/MySQL日志在/var/log/mysql/error.log。不要凭感觉猜日志里一定有线索。5. 实操心得与经验延伸那些文档里不会写的真相这个项目跑通后我整理了三条血泪经验它们比任何技术细节都重要第一永远用真实数据量测试而不是样本。我最初用爬虫只抓了100部电影、1000条评分在本地跑Spark一切顺利。但当换成100万条数据时ratings表的user_id范围从1-1000变成1-200000之前设的upperBound1000导致Spark分区不均——90%的数据落在最后一个分区其他分区空跑。结果训练时间从4分钟暴涨到28分钟。教训是调参前先用SELECT COUNT(*), MIN(user_id), MAX(user_id) FROM ratings;拿到真实边界值再代入Spark的partitionColumn参数。第二Django的ORM不是万能的该写原生SQL时就写。webapp里有个功能用户点击“喜欢”按钮要更新该电影的like_count字段。我最初用Movie.objects.filter(idxxx).update(like_countF(like_count)1)结果并发高时出现竞态条件两个请求同时读到like_count5都写回6。改成原生SQLfrom django.db import connection with connection.cursor() as cursor: cursor.execute(UPDATE movies SET like_count like_count 1 WHERE id %s, [movie_id])MySQL的UPDATE是原子操作彻底解决。技术选型不该教条Django ORM适合快速开发但性能敏感点必须直面数据库。第三文档不是写给未来的你而是写给三天后的你。项目里所有配置文件spark-defaults.conf、my.cnf、nginx.conf我都加了注释但最有用的是README.md里的“快速启动清单”# 快速启动按顺序执行 1. 启动Hadoop: start-dfs.sh start-yarn.sh 2. 启动MySQL: sudo systemctl start mysql 3. 启动Redis: sudo systemctl start redis-server 4. 启动Django: cd webapp python manage.py runserver 0.0.0.0:8000 5. 手动触发推荐: curl -X POST http://localhost:8000/admin/update-model/ -H Cookie: sessionidxxx;这条清单救了我三次每次重装系统后不用翻几十页文档3分钟就能让整个系统跑起来。真正的工程能力不在于写出多炫的算法而在于让下一个接手的人能在最短时间内理解并运行它。最后分享一个小技巧如果你想把这个项目扩展成真实集群不用重写代码。Spark的--master参数从local[*]改成yarnHadoop的core-site.xml里fs.defaultFS从hdfs://mycluster:9000改成hdfs://namenode:9000其他代码零修改。我已在公司测试集群上验证过从单机到YARN集群只改了2个配置项。这说明架构设计的前瞻性远比某个算法细节重要得多。本文还有配套的精品资源点击获取简介这个资源包提供了一套端到端可运行的电影推荐系统实践方案。数据源头是Windows 11环境下编写的Python爬虫自动抓取豆瓣等平台的电影基础信息与用户评分数据经清洗后批量写入Ubuntu 20.04系统中的MySQL 5.7数据库核心推荐逻辑运行在本地VMware虚拟机搭建的Spark伪分布式集群上依赖Hadoop HDFS作为底层存储支持ALS协同过滤算法训练与实时推荐生成前端由Django框架驱动包含用户登录、电影浏览、个性化推荐列表及评分反馈功能界面采用Bootstrap实现适配PC与移动端的响应式布局整个工程按模块划分清晰——Spider_data负责数据采集、Spark_Recommend封装推荐计算流程、webapp和adminapp分别支撑前台展示与后台管理所有代码在PyCharm中开发调试配套文档含系统实现.docx、README.md详细说明了Ubuntu环境配置、Hadoop/Spark/MySQL/Django各组件安装步骤、数据流向图、关键接口定义及单机伪分布式部署方法也预留了向真实YARN集群迁移的配置接口适合用于高校课程设计、大数据实训或SparkPython全栈推荐系统入门学习。本文还有配套的精品资源点击获取
