簡(jiǎn)介這是一份基于Spark的電影推薦系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)的完整課題資料面向大數(shù)據(jù)、推薦系統(tǒng)方向的畢業(yè)設(shè)計(jì)與課程設(shè)計(jì)人員也可供對(duì)協(xié)同過濾、內(nèi)容推薦算法感興趣的開發(fā)者參考。文檔以論文形式系統(tǒng)梳理了課題背景、國(guó)內(nèi)外研究現(xiàn)狀、Spark與MongoDB等關(guān)鍵技術(shù)并重點(diǎn)介紹了基于人口統(tǒng)計(jì)學(xué)、基于內(nèi)容、基于協(xié)同過濾三類推薦算法的原理與設(shè)計(jì)思路。系統(tǒng)分析部分涵蓋可行性與功能需求設(shè)計(jì)部分細(xì)化各推薦算法流程實(shí)現(xiàn)部分展示用戶登錄注冊(cè)、個(gè)性化推薦、電影搜索、用戶評(píng)分等核心功能測(cè)試部分給出功能與性能驗(yàn)證結(jié)果目錄結(jié)構(gòu)從緒論到致謝完整清晰可直接作為相關(guān)課題的參考藍(lán)本。資源包內(nèi)僅含單個(gè)DOCX文檔大小約7.46MB內(nèi)容以論文正文為主共一個(gè)文件便于查閱和編輯。目前已有207人學(xué)習(xí)下載適合需要快速掌握電影推薦系統(tǒng)整體架構(gòu)與研究思路的學(xué)生或開發(fā)者。1. 這個(gè)項(xiàng)目不只是論文一套能從登錄跑到推薦的完整系統(tǒng)電影推薦系統(tǒng)這類課題網(wǎng)上源碼不少但多數(shù)是單機(jī)跑個(gè) Python 腳本調(diào)一下 surprise 庫就完事談不上“系統(tǒng)”。這份資源不一樣——它是一份帶完整論文的工程實(shí)現(xiàn)后端用 Spark 做分布式計(jì)算MongoDB 存業(yè)務(wù)數(shù)據(jù)Redis 做緩存Elasticsearch 參與搜索前端還有 AngularJS 頁面。換句話說它不是 toy demo而是一條能沿著“用戶登錄 → 評(píng)分 → 離線統(tǒng)計(jì) → 實(shí)時(shí)推薦 → 詳情頁相似推薦”跑通的完整鏈路。我拆這份項(xiàng)目時(shí)最大的感受是它的核心不在協(xié)同過濾那幾行 ALS 代碼而在“三種推薦算法怎么分工”。基于人口統(tǒng)計(jì)學(xué)的離線推薦管冷啟動(dòng)和熱門榜基于內(nèi)容的實(shí)時(shí)推薦管用戶當(dāng)下行為協(xié)同過濾管個(gè)性化。單一算法都有各自的坑混合起來才是個(gè)能用的推薦系統(tǒng)。這套設(shè)計(jì)思路比代碼本身更值得讀。適合讀這份資源的人有三類做大數(shù)據(jù)課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)的學(xué)生想把 Spark 推薦從“會(huì)調(diào) API”推進(jìn)到“能搭完整服務(wù)”的后端開發(fā)以及想找一個(gè)可復(fù)現(xiàn)的推薦系統(tǒng)基線工程、準(zhǔn)備加功能的算法工程師。下文我會(huì)把技術(shù)選型、模塊結(jié)構(gòu)、核心實(shí)現(xiàn)和運(yùn)行步驟一層層拆開最后給出我的改造建議。2. 整體架構(gòu)拆解Spark 計(jì)算、MongoDB 存儲(chǔ)、三套算法分工2.1 技術(shù)棧全景與數(shù)據(jù)流向這套系統(tǒng)的技術(shù)選型圍繞一個(gè)核心約束單機(jī)環(huán)境下模擬大數(shù)據(jù)處理流程同時(shí)保證每一層都有真實(shí)組件在跑。先看全景計(jì)算引擎Spark負(fù)責(zé)離線批量統(tǒng)計(jì)和實(shí)時(shí)流處理存儲(chǔ)層MongoDB 存用戶、評(píng)分、電影和推薦結(jié)果Redis 緩存熱點(diǎn)數(shù)據(jù)Elasticsearch 做電影搜索后端Spring Maven提供登錄、評(píng)分、推薦結(jié)果的 REST 接口前端AngularJS 2負(fù)責(zé)頁面渲染和交互集群形態(tài)偽分布式1 個(gè) Master 3 個(gè) Worker 用虛擬機(jī)模擬數(shù)據(jù)流向是這樣的用戶在前端頁面產(chǎn)生評(píng)分、點(diǎn)擊、搜索行為這些行為寫入 MongoDB 的業(yè)務(wù)表離線推薦任務(wù)用 Spark SQL 周期性從 MongoDB 讀取評(píng)分表跑統(tǒng)計(jì)和模型訓(xùn)練把結(jié)果寫回 MongoDB 的推薦結(jié)果表實(shí)時(shí)推薦則通過 Spark Streaming 消費(fèi)行為流結(jié)合用戶最近的評(píng)分記錄做基于內(nèi)容的相似推薦前端通過 Spring 后端接口讀取 MongoDB 里的推薦結(jié)果展示給用戶。這里有一個(gè)值得注意的設(shè)計(jì)決定MongoDB 同時(shí)承擔(dān)“業(yè)務(wù)數(shù)據(jù)庫”和“推薦結(jié)果數(shù)據(jù)庫”兩個(gè)角色。好的一面是技術(shù)棧干凈不用在 HBase 和 MySQL 之間做數(shù)據(jù)同步壞的一面是推薦結(jié)果表要按用戶維度設(shè)計(jì)好索引否則前端高頻讀取時(shí)會(huì)有性能壓力。實(shí)際工程里我會(huì)把推薦結(jié)果再拷一層到 Redis這個(gè)后面改造章節(jié)細(xì)說。2.2 離線推薦模塊基于人口統(tǒng)計(jì)學(xué)的四類統(tǒng)計(jì)任務(wù)離線推薦是這套系統(tǒng)的“底座”它解決的核心問題是冷啟動(dòng)新用戶沒有任何行為記錄時(shí)推薦什么答案是給所有人推一樣的榜單——?dú)v史熱門、近期熱門、高分電影、各類型 Top10。四個(gè)統(tǒng)計(jì)任務(wù)分別這樣設(shè)計(jì)歷史熱門影片的統(tǒng)計(jì)直接用 Spark SQL 從 MongoDB 的 ratings 表讀取評(píng)分記錄按電影 ID 分組統(tǒng)計(jì)評(píng)分人數(shù)取數(shù)量最多的前 N 部。這個(gè)邏輯簡(jiǎn)單粗暴但“評(píng)分人數(shù)多 熱門”這個(gè)假設(shè)在大多數(shù)場(chǎng)景下成立。近期熱門影片的統(tǒng)計(jì)在歷史熱門的基礎(chǔ)上加了時(shí)間窗口。實(shí)現(xiàn)方式是定義一個(gè) UDF把評(píng)分時(shí)間戳轉(zhuǎn)換成“是否在近一個(gè)月內(nèi)”的布爾標(biāo)記然后只統(tǒng)計(jì)窗口內(nèi)的評(píng)分。這個(gè) UDF 是理解 Spark SQL 自定義函數(shù)的好例子。電影平均評(píng)分的統(tǒng)計(jì)按電影 ID 聚合所有評(píng)分計(jì)算平均值寫入 AverageMovies 數(shù)據(jù)集。這個(gè)結(jié)果會(huì)用在詳情頁展示電影得分也會(huì)作為離線推薦的一個(gè)排序因子。各級(jí)別影片 Top10 的統(tǒng)計(jì)這是最復(fù)雜的一個(gè)。電影的 genres 字段是“動(dòng)作|冒險(xiǎn)|科幻”這種按豎線分隔的字符串需要先用 UDF 按|切分成數(shù)組再用explode展開成多行最后按每個(gè)類別分別計(jì)算評(píng)分 Top10。核心代碼見下一章。2.3 實(shí)時(shí)推薦與詳情頁推薦基于內(nèi)容的相似匹配實(shí)時(shí)推薦模塊用的是 Spark Streaming它接收用戶的行為流比如剛給某部電影打了高分然后做兩件事一是把行為寫入 MongoDB 作為后續(xù)離線訓(xùn)練的輸入二是立刻基于這部電影的內(nèi)容標(biāo)簽找相似電影推給用戶。這里的“相似”不是協(xié)同過濾算出來的用戶相似而是電影本身屬性類型、導(dǎo)演、主演的相似度用的是基于內(nèi)容的推薦算法。詳情頁推薦是實(shí)時(shí)推薦的“懶加載版本”用戶點(diǎn)進(jìn)某部電影詳情頁時(shí)后端才去計(jì)算這部電影的相似電影并返回。好處是不需要預(yù)先為每個(gè)用戶算好結(jié)果存儲(chǔ)開銷小壞處是首次訪問詳情頁會(huì)有計(jì)算延遲。在 Spark 環(huán)境下這個(gè)計(jì)算可以做成一次性的批處理任務(wù)把每部電影的相似 Top10 預(yù)先算好存起來而不是實(shí)時(shí)算。2.4 協(xié)同過濾模塊ALS 模型的定位論文里提到協(xié)同過濾算法也提到 Spark MLlib 里的 ALS。在這套系統(tǒng)里協(xié)同過濾不是唯一的推薦來源而是作為離線個(gè)性化推薦的補(bǔ)充。它的任務(wù)是從歷史的“用戶-電影-評(píng)分”矩陣中學(xué)習(xí)兩個(gè)隱因子矩陣——用戶特征矩陣和電影特征矩陣然后用矩陣乘法預(yù)測(cè)用戶對(duì)未看過電影的評(píng)分。但 ALS 有兩個(gè)天然痛點(diǎn)論文里也明確說了數(shù)據(jù)稀疏和冷啟動(dòng)。冷啟動(dòng)已經(jīng)靠人口統(tǒng)計(jì)學(xué)推薦兜底了數(shù)據(jù)稀疏則依賴我們輸入 ALS 的數(shù)據(jù)質(zhì)量。常見做法是把評(píng)分人數(shù)少于閾值的電影過濾掉再把評(píng)分矩陣做歸一化讓模型更容易收斂。這塊我在改造章節(jié)會(huì)給出具體參數(shù)建議。3. 核心實(shí)現(xiàn)逐段拆解從 MongoDB 讀取到推薦結(jié)果落地3.1 Spark SQL 讀取 MongoDB連接器與 DataFrame離線推薦的第一步是把 MongoDB 中的數(shù)據(jù)加載成 Spark DataFrame。項(xiàng)目里沒有用自定義讀取器而是直接用了官方 MongoDB Spark Connector。加載評(píng)分表和電影表的寫法如下import org.apache.spark.sql.SparkSession val spark SparkSession.builder() .appName(OfflineRecommender) .master(local[*]) // 偽分布式環(huán)境下這里也可以是 spark://hadoop102:7077 .config(spark.mongodb.input.uri, mongodb://hadoop102:27017/movie.ratings) .config(spark.mongodb.output.uri, mongodb://hadoop102:27017/movie.result) .getOrCreate() val ratingsDF spark.read.format(mongo) .option(uri, mongodb://hadoop102:27017/movie.ratings) .load() .select(uid, mid, score, timestamp) ratingsDF.show(5)注意select里只取了四個(gè)字段uid用戶 ID、mid電影 ID、score評(píng)分、timestamp評(píng)分時(shí)間戳。之所以要顯式限定字段是因?yàn)?MongoDB 的文檔結(jié)構(gòu)往往比關(guān)系表松散early 篩選能顯著減少 Spark 在 shuffle 階段的數(shù)據(jù)量。偽分布式環(huán)境下資源本來就緊張這個(gè)習(xí)慣能幫你少踩不少 OOM 的坑。3.2 UDF 實(shí)現(xiàn)電影類別切分與近期熱門統(tǒng)計(jì)基于人口統(tǒng)計(jì)學(xué)的推薦里兩個(gè)核心統(tǒng)計(jì)邏輯都需要自定義 UDF。第一個(gè)是把電影的 genres 字符串切分成數(shù)組第二個(gè)是判斷評(píng)分時(shí)間是否落在近一個(gè)月窗口內(nèi)。這段代碼集中展示 UDF 的注冊(cè)和用法import org.apache.spark.sql.functions._ import org.apache.spark.sql.expressions.UserDefinedFunction // 按 | 切分電影類別如 Action|Adventure|Sci-Fi - [Action, Adventure, Sci-Fi] val splitGenres: UserDefinedFunction udf((genres: String) { if (genres null || genres.trim.isEmpty) Array.empty[String] else genres.split(\\|).map(_.trim) }) // 判斷評(píng)分時(shí)間是否在近30天內(nèi) val isRecent: UserDefinedFunction udf((ts: Long) { val thirtyDaysAgo System.currentTimeMillis() - 30L * 24 * 3600 * 1000 ts thirtyDaysAgo }) // 各類型電影 Top10 統(tǒng)計(jì) val genreTopMovies ratingsDF .join(moviesDF, ratingsDF(mid) moviesDF(mid)) .withColumn(genre, explode(splitGenres(moviesDF(genres)))) .groupBy(genre, mid) .agg(avg(score).as(avg_score), count(mid).as(score_count)) .withColumn(rank, row_number().over(Window.partitionBy(genre).orderBy(desc(avg_score), desc(score_count)))) .filter(col(rank) 10) .drop(rank)genreTopMovies這段邏輯的關(guān)鍵點(diǎn)在explode它把“一部電影屬于三個(gè)類別”這一行數(shù)據(jù)展開成三行每個(gè)類別一行這樣后續(xù) groupBy 才能按類別獨(dú)立排序。窗口函數(shù)row_number() over partitionBy負(fù)責(zé)在每個(gè)類別內(nèi)部取評(píng)分最高的 10 部。如果你的數(shù)據(jù)里有一些只有一兩人評(píng)分的電影建議在agg之后加一個(gè)過濾條件只保留score_count 10的影片否則“平均分第一名”容易被單條高分評(píng)價(jià)刷上去。近期熱門統(tǒng)計(jì)更簡(jiǎn)單對(duì) ratings 表用 UDF 過濾近一個(gè)月的評(píng)分然后按 mid 聚合計(jì)數(shù)取 Top N 寫入 RateMoreRecentlyMovies 集合。3.3 ALS 協(xié)同過濾訓(xùn)練與個(gè)性化推薦ALS 是 Spark MLlib 里最成熟的協(xié)同過濾實(shí)現(xiàn)。代碼不長(zhǎng)但調(diào)參直接影響推薦質(zhì)量import org.apache.spark.ml.recommendation.ALS import org.apache.spark.ml.evaluation.RegressionEvaluator // 劃分訓(xùn)練集和測(cè)試集測(cè)試集用于評(píng)估模型誤差 val Array(training, test) ratingsDF.randomSplit(Array(0.8, 0.2)) val als new ALS() .setRank(20) // 隱因子數(shù)量越大表達(dá)能力越強(qiáng)但過擬合風(fēng)險(xiǎn)也越高 .setMaxIter(10) // 迭代次數(shù)日志里會(huì)顯示每次迭代的 loss .setRegParam(0.1) // 正則化參數(shù)控制過擬合 .setUserCol(uid) .setItemCol(mid) .setRatingCol(score) .setColdStartStrategy(drop) // 預(yù)測(cè)時(shí)遇到未見過的用戶/電影直接丟棄而非報(bào)錯(cuò) val model als.fit(training) // 為每個(gè)用戶生成 Top20 推薦 val userRecs model.recommendForAllUsers(20) userRecs.write.mode(overwrite).format(mongo) .option(uri, mongodb://hadoop102:27017/movie.UserRecs) .save()setColdStartStrategy(drop)是必須強(qiáng)調(diào)的一個(gè)配置。ALS 模型在預(yù)測(cè)時(shí)如果遇到訓(xùn)練集里沒出現(xiàn)過的用戶或電影默認(rèn)會(huì)拋異常。線上系統(tǒng)里每天都有新用戶新電影所以必須設(shè)置成drop或nan丟棄無法預(yù)測(cè)的條目而不是讓整個(gè)批次失敗。rank 參數(shù)常見取值范圍是 10 到 50regParam 是 0.01 到 0.1調(diào)參時(shí)優(yōu)先觀察測(cè)試集上的 RMSE均方根誤差。3.4 基于內(nèi)容的相似度計(jì)算標(biāo)簽向量與余弦相似度基于內(nèi)容的推薦核心是把電影轉(zhuǎn)成向量然后算向量相似度。這里用的是最簡(jiǎn)單的標(biāo)簽映射法把電影的 genres、主演、導(dǎo)演拼接成文本分詞后映射成 TF-IDF 向量再算兩兩之間的余弦相似度。import org.apache.spark.ml.feature.{HashingTF, IDF, Tokenizer} import org.apache.spark.ml.linalg.SparseVector // 構(gòu)造電影內(nèi)容描述列 val movieContent moviesDF .withColumn(content, concat_ws( , col(genres), col(actors), col(directors))) // 分詞 TF-IDF得到每部電影的特征向量 val tokenizer new Tokenizer().setInputCol(content).setOutputCol(words) val hashingTF new HashingTF().setInputCol(words).setOutputCol(rawFeatures).setNumFeatures(1000) val idf new IDF().setInputCol(rawFeatures).setOutputCol(features) val pipeline new Pipeline().setStages(Array(tokenizer, hashingTF, idf)) val featureModel pipeline.fit(movieContent) val movieFeatures featureModel.transform(movieContent) movieFeatures.select(mid, features).show(5)這里使用了HashingTF而不是CountVectorizer主要考慮是 HashingTF 不需要預(yù)先構(gòu)建詞典適合跑批任務(wù)缺點(diǎn)是哈希碰撞會(huì)引入噪聲setNumFeatures設(shè)得越大碰撞概率越低。算相似度時(shí)對(duì)每個(gè)電影向量和其余所有向量做點(diǎn)積并歸一化就能得到余弦相似度。如果電影數(shù)量很大更聰明的做法是先用 ALS 電影因子向量代替 TF-IDF 向量因?yàn)?ALS 訓(xùn)練出的隱因子已經(jīng)隱含了“同類型電影向量接近”的特性。3.5 后端接口與前端調(diào)用的銜接推薦結(jié)果算完后展示層還需要后端接口。Spring 后端提供了四類核心接口登錄注冊(cè)、獲取首頁推薦、詳情頁相似推薦、提交評(píng)分。前端 AngularJS 通過 HTTP 調(diào)用這些接口渲染推薦列表RestController RequestMapping(/api/recommend) public class RecommendController { Autowired private MongoTemplate mongoTemplate; // 首頁推薦讀取離線推薦表按用戶返回混合結(jié)果 GetMapping(/home/{uid}) public ListRecommendation home(PathVariable String uid) { Query query new Query(Criteria.where(uid).is(uid)); ListUserRecs userRecs mongoTemplate.find(query, UserRecs.class, UserRecs); return userRecs.stream() .flatMap(rec - rec.getRecs().stream()) .sorted((a, b) - b.getScore().compareTo(a.getScore())) .limit(20) .collect(Collectors.toList()); } // 提交評(píng)分寫入 MongoDB同時(shí)作為實(shí)時(shí)推薦的觸發(fā)信號(hào) PostMapping(/rate) public Result rate(RequestBody RatingRequest request) { mongoTemplate.save(request, ratings); return Result.success(); } }前端接到recommendations數(shù)組后按分?jǐn)?shù)從高到低渲染成卡片列表。這個(gè)接口的寫法比較直白但它把分層關(guān)系講清楚了前端只認(rèn) userId不關(guān)心推薦結(jié)果的來源是離線統(tǒng)計(jì)還是協(xié)同過濾后端通過對(duì)UserRecs聚合實(shí)現(xiàn)多路推薦融合。如果你想加一路“熱門兜底”在接口里把GenresTopMovies也讀出來混進(jìn)去就行。4. 環(huán)境搭建與程序運(yùn)行偽分布式 Spark 集群怎么跑起來4.1 虛擬機(jī)模擬四節(jié)點(diǎn) Spark 集群論文的實(shí)際運(yùn)行環(huán)境是單機(jī)偽分布式一臺(tái)物理機(jī)上用 VMware 開三臺(tái) CentOS 虛擬機(jī)搭一個(gè)四節(jié)點(diǎn) Spark 集群1 Master 3 Worker三臺(tái)機(jī)器的主機(jī)名分別設(shè)計(jì)為 hadoop102、hadoop103、hadoop104。之所以從 hadoop102 開始編號(hào)是為了給 Namenode 留出 101 的位置如果是生產(chǎn)環(huán)境你還會(huì)加一個(gè) 105 做備用 Master。搭建步驟如下在三臺(tái)虛擬機(jī)上分別安裝 JDK 并配置JAVA_HOME配置 SSH 免密登錄三臺(tái)機(jī)器兩兩互信修改/etc/hosts把三個(gè)主機(jī)名映射到固定 IP在 Spark 的conf/slaves文件里填寫三個(gè) Worker 主機(jī)名修改spark-env.sh指定SPARK_MASTER_HOSThadoop102、SPARK_MASTER_PORT7077完成后在 Master 節(jié)點(diǎn)執(zhí)行start-all.sh瀏覽器訪問hadoop102:8080Worker 列表里能看到三個(gè)節(jié)點(diǎn)說明集群搭好了。4.2 MongoDB 集合設(shè)計(jì)與啟動(dòng)MongoDB 在 Windows 本機(jī)運(yùn)行負(fù)責(zé)存業(yè)務(wù)表和推薦結(jié)果表。數(shù)據(jù)庫里設(shè)計(jì)了兩類集合一類是原始數(shù)據(jù)——User用戶、Ratings評(píng)分、Movies電影另一類是推薦結(jié)果——AverageMovies、GenresTopMovies、RateMoreMovies、RateMoreRecentlyMovies、UserRecs。啟動(dòng)方式最簡(jiǎn)單命令行直接跑mongod --dbpath /data/db --port 27017 --bind_ip 0.0.0.0要注意的是--bind_ip 0.0.0.0否則虛擬機(jī)里的 Spark 應(yīng)用連不上 Windows 宿主機(jī)上的 MongoDB。這是偽分布式環(huán)境里的常見坑后面避坑章節(jié)還會(huì)細(xì)說。業(yè)務(wù)表創(chuàng)建之后用mongoimport把 ratings.dat 和 movies.dat 導(dǎo)入即可。4.3 Redis 與 Elasticsearch 配置Redis 在 Linux 虛擬機(jī)里運(yùn)行主要給實(shí)時(shí)推薦模塊做緩存緩存用戶最近評(píng)分記錄和熱門推薦結(jié)果。配置項(xiàng)只需要改兩處bind 0.0.0.0允許遠(yuǎn)程訪問maxmemory設(shè)一個(gè)合理上限如 2GB避免緩存無限增長(zhǎng)把內(nèi)存吃光。Elasticsearch 的作用是搜索。電影搜索功能沒有走 MongoDB 的模糊查詢而是把電影標(biāo)題、類別、主演信息同步到 ES用 ES 的倒排索引做全文檢索。配置上需要注意 ES 的network.host要改成虛擬機(jī)能訪問的 IPdiscovery.type設(shè)為single-node否則單機(jī)模式會(huì)因組播發(fā)現(xiàn)失敗而啟動(dòng)異常。4.4 系統(tǒng)啟動(dòng)順序與驗(yàn)證整個(gè)系統(tǒng)啟動(dòng)依賴順序很關(guān)鍵錯(cuò)了會(huì)出現(xiàn)“Spark 任務(wù)提交成功但讀寫數(shù)據(jù)失敗”的怪問題# 1. 啟動(dòng) MongoDBWindows 宿主機(jī) mongod --dbpath /data/db --port 27017 --bind_ip 0.0.0.0 # 2. 啟動(dòng) Redishadoop103 redis-server /etc/redis/redis.conf # 3. 啟動(dòng) Elasticsearchhadoop104 elasticsearch -d # 4. 啟動(dòng) Spark 集群hadoop102 Master start-all.sh # 5. 啟動(dòng)后端 Spring 服務(wù)WindowsIDEA 里直接 Run mvn spring-boot:run # 6. 前端 AngularJS 通過 Nginx 或開發(fā)服務(wù)器訪問 localhost:8088啟動(dòng)完成后驗(yàn)證路徑瀏覽器訪問localhost:8088能看到登錄頁登錄后首頁能看到“熱門推薦”“近期熱門”“高分電影”三個(gè)榜單點(diǎn)進(jìn)任何一部電影詳情頁能看到相似電影給任意電影打 5 分后隔幾秒刷新首頁實(shí)時(shí)推薦區(qū)應(yīng)該出現(xiàn)與剛評(píng)分電影類型相近的影片。這四條驗(yàn)證過了系統(tǒng)鏈路就算通了。4.5 推薦任務(wù)的手動(dòng)觸發(fā)離線推薦任務(wù)如果用spark-submit提交可以做成 jar 單獨(dú)跑spark-submit \ --class com.movie.recommender.OfflineRecommender \ --master spark://hadoop102:7077 \ --executor-memory 1G \ movie-recommender-1.0.jar--executor-memory在偽分布式環(huán)境下不要超過 2G。三臺(tái)虛擬機(jī)共享一臺(tái)物理機(jī)的內(nèi)存給多了反而會(huì)因?yàn)槲锢韮?nèi)存不足引起整機(jī) swapSpark 任務(wù)會(huì)越跑越慢最后表現(xiàn)為 Web UI 上任務(wù)卡在 SCHEDULED 狀態(tài)不動(dòng)。5. 常見問題避坑偽分布式環(huán)境下的血淚經(jīng)驗(yàn)5.1 Spark 任務(wù)報(bào)錯(cuò)找不到 MongoDB 驅(qū)動(dòng)類現(xiàn)象提交離線推薦任務(wù)后任務(wù)在讀取 MongoDB 階段拋出ClassNotFoundException: com.mongodb.MongoClient或類似驅(qū)動(dòng)類缺失錯(cuò)誤。原因Spark 集群的 Executor 節(jié)點(diǎn)沒有加載 MongoDB Connector 的依賴 jar。本地 IDEA 運(yùn)行時(shí)依賴在 classpath 里沒問題但spark-submit提交到集群后Executor 的 classpath 是獨(dú)立的。解決打包時(shí)把依賴打進(jìn) fat jar或者提交任務(wù)時(shí)用--packages org.mongodb.spark:mongo-spark-connector_2.11指定依賴。從那以后我每次提交 Spark 任務(wù)都強(qiáng)制檢查一遍--packages列表和代碼里 import 的包一一對(duì)應(yīng)。5.2 Executor 頻繁 OOM任務(wù)卡死在 SCHEDULED 狀態(tài)現(xiàn)象離線統(tǒng)計(jì)任務(wù)在跑大表聚合時(shí)報(bào) Executor OOM日志里有java.lang.OutOfMemoryError, Web UI 里看到多個(gè) Executor 處于 FAILED 狀態(tài)。原因偽分布式集群的內(nèi)存總量有限三臺(tái) Worker 共享物理內(nèi)存。默認(rèn)配置下 Spark 會(huì)為每個(gè) Executor 分配物理內(nèi)存的很大比例多個(gè) Executor 疊加直接吃滿內(nèi)存。另外讀取 MongoDB 時(shí)如果沒有提前 select 字段DataFrame 會(huì)帶著大量冗余字段參加 shuffle內(nèi)存壓力更大。解決第一spark-env.sh里把SPARK_WORKER_MEMORY降到 2G提交任務(wù)時(shí)--executor-memory 1G第二所有 Spark SQL 讀取后的第一步就是select精簡(jiǎn)字段第三對(duì)特別大的 ratings 表先按 uid 做一次repartition再聚合。這條優(yōu)化在真實(shí)集群同樣適用只是真實(shí)集群閾值可以放寬。5.3 UDF 在集群模式下拋序列化異常現(xiàn)象本地跑沒問題spark-submit提交到集群后報(bào)Task not serializable或org.apache.spark.SparkException: Task not serializable錯(cuò)誤棧指向代碼里定義的 UDF。原因如果 UDF 內(nèi)部引用了外部對(duì)象比如配置類實(shí)例、SparkSession 以外的全局變量這個(gè)外部對(duì)象必須可序列化否則閉包無法在 Executor 間傳輸。本地模式下 Driver 和 Executor 在同一 JVM問題不會(huì)暴露。解決UDF 內(nèi)部不要引用外部非序列化對(duì)象把所有依賴封裝成Serializable案例類或者在 UDF 內(nèi)部直接創(chuàng)建所需對(duì)象。我的習(xí)慣是任何 UDF 先問自己“如果它在另一臺(tái)機(jī)器上執(zhí)行需要帶什么東西”只帶字符串和基本類型就是最安全的。5.4 Elasticsearch 啟動(dòng)后外部無法訪問現(xiàn)象ES 在本機(jī)啟動(dòng)正常curl localhost:9200有響應(yīng)但在另一臺(tái)機(jī)器上訪問hadoop104:9200超時(shí)或拒絕連接。原因Elasticsearch 默認(rèn)只綁定127.0.0.1虛擬機(jī)上的 Spark 應(yīng)用當(dāng)然訪問不到。解決修改elasticsearch.yml設(shè)置network.host: 0.0.0.0同時(shí)設(shè)置discovery.type: single-node否則單節(jié)點(diǎn)會(huì)因?yàn)?bootstrap checks 拒絕啟動(dòng)。改完重啟 ES 后用curl http://hadoop104:9200驗(yàn)證。5.5 前端頁面能打開但登錄后一直跳回登錄頁現(xiàn)象localhost:8088 的頁面加載正常輸入用戶名密碼后接口也能返回成功但頁面刷新后又回到登錄頁。原因AngularJS 前端把登錄狀態(tài)存到了瀏覽器 localStorage但后端接口跨域或 Cookie 配置了Secure屬性導(dǎo)致 Cookie 沒寫進(jìn)去。Spring 后端返回登錄態(tài)時(shí)如果沒有正確配置跨域頭瀏覽器會(huì)攔截寫入。解決后端在 WebMvcConfigurer 里配置 CorsRegistry允許前端域名跨域請(qǐng)求帶上 Cookie同時(shí)確認(rèn)登錄接口的響應(yīng)頭包含Access-Control-Allow-Credentials: true。如果用了 Nginx 代理前端還要檢查代理配置是否把 Cookie 頭透?jìng)髁恕?. 二次開發(fā)改造思路把“能跑的推薦”變成“好用的推薦”讀完源碼、跑通鏈路之后真正的價(jià)值在于改造成符合自己場(chǎng)景的系統(tǒng)。我會(huì)從四個(gè)層面動(dòng)刀按投入產(chǎn)出比排序。第一層推薦結(jié)果的加權(quán)融合。當(dāng)前首頁接口直接合并 UserRecs 排序本質(zhì)上還是單一算法輸出輪流展示。更穩(wěn)的做法是給每路推薦打分ALS 結(jié)果乘 0.5基于內(nèi)容的結(jié)果乘 0.3熱門榜乘 0.2做加權(quán)取 TopN。這幾個(gè)權(quán)重可以先用固定值跑一周看各路的點(diǎn)擊轉(zhuǎn)化率再調(diào)。代碼改動(dòng)只在 RecommendController 里加一個(gè)融合函數(shù)不動(dòng)底層。第二層給 ALS 加一個(gè)數(shù)據(jù)預(yù)處理。當(dāng)前 ratings 表是原始評(píng)分直接進(jìn)模型數(shù)據(jù)稀疏時(shí)會(huì)訓(xùn)練出大量零向量。建議訓(xùn)練前過濾掉評(píng)分人數(shù)少于 20 的電影對(duì) score 做標(biāo)準(zhǔn)化到 0-1 區(qū)間。能明顯提升收斂速度和推薦精度。第三層實(shí)時(shí)推薦的觸發(fā)源擴(kuò)展。當(dāng)前實(shí)時(shí)推薦只響應(yīng)“評(píng)分”事件。改造方向是把“點(diǎn)擊詳情頁”“搜索電影”也作為行為流輸入對(duì)點(diǎn)擊行為降權(quán)即可。改動(dòng)工作量集中在行為日志接入和權(quán)重映射。第四層把熱點(diǎn)數(shù)據(jù)推進(jìn) Redis。詳情頁相似推薦和首頁熱門榜都可以做成定時(shí)任務(wù)預(yù)熱進(jìn) Redis前端接口只讀緩存降低 MongoDB 讀壓力。改造點(diǎn)是在離線任務(wù)結(jié)束后加一步寫 Redis 的操作。驗(yàn)證改造效果的方法不需要上線 A/B準(zhǔn)備兩組用戶一組走老邏輯一組走新邏輯各推 50 部電影比較兩組用戶的點(diǎn)擊率和評(píng)分?jǐn)?shù)量。這個(gè)比較可以在 MongoDB 里直接用聚合查詢完成不用額外搭數(shù)據(jù)平臺(tái)。這套工程我前前后后拆過兩次每次都被同一個(gè)問題卡住偽分布式環(huán)境下只要集群一重啟MongoDB 里的推薦結(jié)果表和 Redis 緩存就不同步。從那以后我每次改完離線任務(wù)都強(qiáng)制走一遍“清空結(jié)果表 → 重跑離線批 → 刷新 Redis 預(yù)熱”的流程確認(rèn)三份數(shù)據(jù)一致才交給前端驗(yàn)收。做推薦系統(tǒng)數(shù)據(jù)一致性和算法效果一樣影響體驗(yàn)——希望這篇拆解能幫你少走我來回折騰的那幾步路。本文還有配套的精品資源點(diǎn)擊獲取