為什么我建議畢設(shè)選大數(shù)據(jù)公益這個(gè)方向Hadoop/PySpark/Hive慈善捐贈(zèng)推薦系統(tǒng)全拆解每年到畢設(shè)季都會(huì)有學(xué)弟學(xué)妹跑來問我大數(shù)據(jù)方向的畢業(yè)設(shè)計(jì)到底選什么題才既好過、又能真正學(xué)到東西 我的回答一直是別去做那些爛大街的電商推薦、電影推薦試試大數(shù)據(jù)公益這個(gè)組合。我今年帶的一個(gè)項(xiàng)目——基于Hadoop、PySpark和Hive的愛心慈善捐贈(zèng)項(xiàng)目推薦系統(tǒng)就是一個(gè)非常典型的例子。它把分布式存儲(chǔ)、離線數(shù)倉(cāng)、分布式計(jì)算和推薦算法全部串聯(lián)起來技術(shù)棧完整、業(yè)務(wù)場(chǎng)景有社會(huì)價(jià)值而且數(shù)據(jù)量級(jí)可以自己控制從偽分布式到集群都能跑。這篇文章我會(huì)把這個(gè)項(xiàng)目的完整思路、技術(shù)分工、環(huán)境搭建、算法選型、實(shí)戰(zhàn)踩坑全部拆開講清楚希望能給正在選題或已經(jīng)開始動(dòng)手的同學(xué)們一個(gè)可參考的完整樣本。這篇文章適合幾類人一是計(jì)算機(jī)相關(guān)專業(yè)、畢設(shè)選題鎖定大數(shù)據(jù)方向的同學(xué)二是想系統(tǒng)梳理Hadoop、Hive、Spark這套技術(shù)棧之間協(xié)作關(guān)系的初學(xué)者三是想在簡(jiǎn)歷上增加一個(gè)完整項(xiàng)目經(jīng)歷的開發(fā)者。你不需要提前精通所有組件跟著這篇文章把為什么這么做搞明白再拿著源碼去復(fù)現(xiàn)會(huì)順暢很多。1. 為什么是慈善推薦這個(gè)題目的技術(shù)含量與選題邏輯先說選題邏輯。畢設(shè)的本質(zhì)是證明你掌握了某一套技術(shù)并能用它解決一個(gè)具體問題但很多同學(xué)選完題就掉進(jìn)兩個(gè)極端要么題目太水一張網(wǎng)頁(yè)加一個(gè)數(shù)據(jù)庫(kù)就完事答辯時(shí)被老師問幾句就露餡要么題目太虛張口就是基于深度學(xué)習(xí)的某某平臺(tái)結(jié)果自己根本跑不通模型。慈善捐贈(zèng)項(xiàng)目推薦系統(tǒng)這個(gè)題目恰好卡在中間它有幾個(gè)天然優(yōu)勢(shì)技術(shù)棧覆蓋面廣底層存儲(chǔ)用Hadoop HDFS數(shù)據(jù)清洗和數(shù)倉(cāng)建模用Hive推薦計(jì)算用PySpark的MLlib整個(gè)鏈路是經(jīng)典的大數(shù)據(jù)離線處理架構(gòu)每一個(gè)組件都有明確的職責(zé)可以寫成完整的系統(tǒng)設(shè)計(jì)。業(yè)務(wù)場(chǎng)景有溫度、好講慈善捐贈(zèng)涉及捐贈(zèng)人、受助項(xiàng)目、捐贈(zèng)行為、項(xiàng)目標(biāo)簽等多個(gè)主體天然適合做推薦。評(píng)委老師聽到通過分析捐贈(zèng)歷史向潛在捐贈(zèng)人推薦合適的公益項(xiàng)目時(shí)不需要額外的業(yè)務(wù)背景就能理解答辯時(shí)溝通成本極低。數(shù)據(jù)量可伸縮你可以用幾千條數(shù)據(jù)在偽分布式環(huán)境下跑通也可以生成百萬級(jí)數(shù)據(jù)在集群上壓測(cè)。老師問數(shù)據(jù)量大怎么辦時(shí)你有完整的分布式方案可以講問數(shù)據(jù)小能不能跑時(shí)你也確實(shí)能跑。結(jié)果可解釋推薦系統(tǒng)最怕黑盒用協(xié)同過濾項(xiàng)目屬性召回的組合每一個(gè)推薦結(jié)果都能說出理由這對(duì)畢業(yè)設(shè)計(jì)來說極其重要——可解釋性比模型精度更值錢。當(dāng)然這個(gè)題也有它的坑。最大的坑是很多人會(huì)把慈善系統(tǒng)和慈善推薦系統(tǒng)搞混。如果你做的是捐贈(zèng)人注冊(cè)、項(xiàng)目發(fā)布、捐款管理那一套CRUD那它就是個(gè)普通的管理系統(tǒng)和大數(shù)據(jù)沒有半點(diǎn)關(guān)系題目里的Hadoop、PySpark就純粹成了擺設(shè)。正確的做法是系統(tǒng)要解決的是推薦問題而不是管理問題。你仍然需要項(xiàng)目信息、用戶信息這些基礎(chǔ)數(shù)據(jù)但它們的角色是模型的輸入而不是系統(tǒng)的主體功能。我建議把這個(gè)項(xiàng)目的核心定位表述為面向公益平臺(tái)的捐贈(zèng)人-公益項(xiàng)目雙向推薦服務(wù)。它讀取歷史捐贈(zèng)行為數(shù)據(jù)構(gòu)建用戶畫像和項(xiàng)目畫像用協(xié)同過濾算法預(yù)測(cè)用戶可能感興趣的項(xiàng)目同時(shí)用基于內(nèi)容的召回解決新用戶和新項(xiàng)目的冷啟動(dòng)問題。數(shù)據(jù)鏈路走HDFS - Hive - PySpark - 推薦結(jié)果寫回Hive每一步都有東西可寫、有東西可講。2. 三駕馬車的分工Hadoop、PySpark、Hive在項(xiàng)目里到底干什么很多同學(xué)的畢設(shè)課題名一口氣列了四五個(gè)框架但問他每個(gè)框架負(fù)責(zé)什么就開始含糊。框架堆砌是最容易被答辯老師拆穿的硬傷。所以這篇文章先用一個(gè)最直白的類比把三者的關(guān)系講清楚Hive是倉(cāng)庫(kù)管理員PySpark是分揀工人Hadoop的HDFS是貨架YARN是調(diào)度主管。2.1 HDFS與YARN數(shù)據(jù)住哪、任務(wù)誰管整個(gè)系統(tǒng)最底層的底座是Hadoop它包含兩個(gè)核心部分HDFS負(fù)責(zé)存儲(chǔ)YARN負(fù)責(zé)資源調(diào)度。在捐贈(zèng)推薦這個(gè)場(chǎng)景下原始數(shù)據(jù)——捐贈(zèng)行為日志、項(xiàng)目信息表、用戶信息表——不管是從業(yè)務(wù)數(shù)據(jù)庫(kù)導(dǎo)出還是模擬生成的最終都要落到HDFS上成為后續(xù)所有計(jì)算的原料倉(cāng)庫(kù)。HDFS的設(shè)計(jì)理念是大文件、一次寫入、多次讀取。我們產(chǎn)生的數(shù)據(jù)雖然是結(jié)構(gòu)化表格但勝在量大而且計(jì)算框架Hive、Spark都需要從HDFS上讀取數(shù)據(jù)這就對(duì)存儲(chǔ)的帶寬和容錯(cuò)提出了要求。HDFS會(huì)把文件切分成塊默認(rèn)128MB每個(gè)塊復(fù)制多份放到不同節(jié)點(diǎn)上這樣任何一臺(tái)機(jī)器掛掉都不會(huì)丟數(shù)據(jù)。對(duì)于畢設(shè)來說你最需要掌握的倒不是這些原理——原理書上都有而是怎么把數(shù)據(jù)高效地放上去是用hdfs dfs -put直接傳還是通過Hive的LOAD DATA還是直接用Spark寫進(jìn)去。三種方式我后面會(huì)在數(shù)據(jù)鏈路里詳細(xì)講。YARN在這個(gè)項(xiàng)目里更像是一個(gè)任務(wù)管家。你提交的Hive任務(wù)、Spark任務(wù)都會(huì)先交給YARN由它分配容器Container和內(nèi)存再在指定的NodeManager上啟動(dòng)執(zhí)行。很多同學(xué)在偽分布式環(huán)境下跑PySpark任務(wù)時(shí)遇到Container exited with a non-zero exit code八成就是YARN分配的內(nèi)存不夠用這個(gè)問題我會(huì)在踩坑章節(jié)專門講。2.2 Hive把SQL翻譯成分布式作業(yè)的翻譯官很多同學(xué)會(huì)問既然PySpark也能做數(shù)據(jù)處理為什么還要用Hive答案是——數(shù)倉(cāng)建模和數(shù)據(jù)管理這件事用SQL表達(dá)是最自然、最容易被評(píng)審接受的。Hive的本質(zhì)是一個(gè)數(shù)據(jù)倉(cāng)庫(kù)工具它把HDFS上的結(jié)構(gòu)化數(shù)據(jù)映射成一張張表然后把你寫的SQL翻譯成MapReduce或Tez作業(yè)扔到Y(jié)ARN上去跑。在這個(gè)項(xiàng)目里Hive承擔(dān)的職責(zé)非常明確原始數(shù)據(jù)的存儲(chǔ)與組織創(chuàng)建外部表指向HDFS上的原始數(shù)據(jù)目錄創(chuàng)建內(nèi)部表存放清洗后的結(jié)果用分區(qū)和分桶來管理日益增長(zhǎng)的數(shù)據(jù)。ETL的落地執(zhí)行數(shù)據(jù)清洗、去重、格式轉(zhuǎn)換、維度表關(guān)聯(lián)這些操作用Hive SQL寫起來最清晰。比如把捐贈(zèng)金額為負(fù)數(shù)的記錄剔除一行SQL就寫完了如果用純PySpark寫代碼量會(huì)成倍增加。推薦結(jié)果的匯總與回寫PySpark算出的推薦結(jié)果最終寫回Hive表供上層的Web系統(tǒng)或報(bào)表查詢使用。我在設(shè)計(jì)這個(gè)項(xiàng)目時(shí)的經(jīng)驗(yàn)是能用Hive SQL完成的ETL就不要用Spark代碼去做。原因有三個(gè)一是SQL可讀性強(qiáng)寫進(jìn)論文里相當(dāng)于現(xiàn)成的算法描述二是Hive對(duì)任務(wù)的優(yōu)化比如分區(qū)裁剪、小文件合并是自動(dòng)化的你不需要手動(dòng)調(diào)優(yōu)三是答辯時(shí)老師問你的數(shù)據(jù)清洗怎么做的你直接打開Hive腳本一行行講比講一坨Spark RDD算子有說服力得多。2.3 PySpark真正干重活的計(jì)算引擎PySpark在這個(gè)項(xiàng)目里是推薦算法的執(zhí)行引擎它解決的問題是當(dāng)數(shù)據(jù)量大到單機(jī)Python處理不了時(shí)怎么用分布式的方式完成矩陣分解或相似度計(jì)算。推薦系統(tǒng)的核心算法——協(xié)同過濾——可以用SQL寫也可以用單機(jī)Python寫但這兩者在數(shù)據(jù)量大時(shí)都有瓶頸。SQL寫協(xié)同過濾非常繞涉及大量的自連接和聚合單機(jī)Python則受內(nèi)存限制百萬級(jí)評(píng)分矩陣就吃不消了。PySpark的MLlib庫(kù)提供了分布式的ALS交替最小二乘算法實(shí)現(xiàn)它把用戶物品評(píng)分矩陣分塊存儲(chǔ)在各個(gè)節(jié)點(diǎn)上通過迭代計(jì)算找到用戶和物品的隱因子向量整個(gè)過程自動(dòng)并行化。但這里要提醒一句PySpark寫推薦算法難點(diǎn)不在于調(diào)用ALS而在于數(shù)據(jù)準(zhǔn)備。你要把Hive里的表讀成Spark的DataFrame把字符串類型的用戶ID和項(xiàng)目ID轉(zhuǎn)成數(shù)值型的索引把數(shù)據(jù)劃分成訓(xùn)練集和測(cè)試集最后還要把模型預(yù)測(cè)的結(jié)果重新映射回可讀的ID。這些數(shù)據(jù)管道的代碼才是項(xiàng)目工程量的主要來源。我在項(xiàng)目中把PySpark的處理流程固定為SparkSession讀取Hive表 - 數(shù)據(jù)清洗與特征構(gòu)造 - ALS模型訓(xùn)練與調(diào)參 - 生成TopN推薦結(jié)果 - 寫入Hive結(jié)果表 - 用測(cè)試集評(píng)估離線指標(biāo)。這個(gè)流程清晰、可復(fù)現(xiàn)也是論文系統(tǒng)實(shí)現(xiàn)章節(jié)的最佳素材。3. 從零搭建大數(shù)據(jù)環(huán)境的實(shí)操筆記偽分布式、YARN提交與Windows開發(fā)環(huán)境搭建是第一個(gè)勸退點(diǎn)也是第一個(gè)拉開差距的地方。很多同學(xué)卡在Hadoop安裝上一周都起不來然后就對(duì)整篇畢設(shè)失去信心。我直接把我實(shí)測(cè)可行的路徑寫出來包括對(duì)應(yīng)版本組合、關(guān)鍵配置和排錯(cuò)思路。3.1 環(huán)境拓?fù)鋫畏植际竭€是真集群對(duì)這個(gè)畢設(shè)項(xiàng)目我強(qiáng)烈建議第一優(yōu)先選擇偽分布式模式——也就是一臺(tái)Linux機(jī)器上同時(shí)跑NameNode、DataNode、ResourceManager和NodeManager。原因有三畢設(shè)的數(shù)據(jù)量和計(jì)算量偽分布式完全扛得住百萬級(jí)數(shù)據(jù)在這個(gè)架構(gòu)下跑ALS不會(huì)慢得離譜。運(yùn)維成本低你不需要管理多臺(tái)機(jī)器的SSH免密、時(shí)間同步和端口沖突。從偽分布式遷移到集群是平滑的Hive表和Spark作業(yè)的代碼完全不變改的只是CPU和內(nèi)存配置。如果你用的是8G內(nèi)存的筆記本我給一個(gè)穩(wěn)妥的資源分配方案組件分配內(nèi)存說明NameNode1G元數(shù)據(jù)管理DataNode1G數(shù)據(jù)存儲(chǔ)ResourceManager1G資源調(diào)度NodeManager2G執(zhí)行容器HiveServer2512MJDBC服務(wù)SparkDriver/Executor2G推薦計(jì)算這個(gè)方案的關(guān)鍵在于別貪心——每個(gè)組件分配過多內(nèi)存會(huì)導(dǎo)致總內(nèi)存超限系統(tǒng)頻繁觸發(fā)OOM Killer表現(xiàn)為進(jìn)程莫名其妙消失。我見過太多同學(xué)把4個(gè)G都給了DataNode結(jié)果Spark任務(wù)一啟動(dòng)NodeManager就被殺了。3.2 安裝配置中繞不開的幾個(gè)細(xì)節(jié)Hadoop的安裝步驟網(wǎng)上教程很多但有幾個(gè)細(xì)節(jié)是教程不會(huì)重點(diǎn)強(qiáng)調(diào)、卻直接決定成敗的JDK版本必須匹配。Hadoop 3.x需要JDK 8或JDK 11Spark 3.x需要JDK 8/11/17。我用的是JDK 8 Hadoop 3.3.6 Spark 3.2.4 Hive 3.1.3的組合跑通后就沒再變過。不要追求最新版本大數(shù)據(jù)組件之間的版本兼容性遠(yuǎn)比版本新重要。SSH免密登錄一定要配雖然偽分布式只有一臺(tái)機(jī)器Hadoop的start-dfs.sh腳本仍然需要通過SSH連到localhost執(zhí)行一些命令如果不配免密每次啟動(dòng)都會(huì)卡住。core-site.xml和hdfs-site.xml的關(guān)鍵參數(shù)fs.defaultFS設(shè)為hdfs://localhost:9000dfs.replication設(shè)為1偽分布式?jīng)]有多余節(jié)點(diǎn)副本數(shù)設(shè)3只會(huì)浪費(fèi)空間。這兩個(gè)參數(shù)配置錯(cuò)誤是啟動(dòng)失敗的最常見原因。環(huán)境變量統(tǒng)一把HADOOP_HOME、SPARK_HOME、HIVE_HOME都寫進(jìn)/etc/profile.d/下的獨(dú)立腳本里并注意不要覆蓋系統(tǒng)自帶的PATH否則會(huì)導(dǎo)致bash都找不到。安裝完成后驗(yàn)證命令是jps應(yīng)該能看到NameNode、DataNode、ResourceManager、NodeManager這幾個(gè)Java進(jìn)程?？吹剿鼈兌蓟钪鳫adoop這一關(guān)就算過了。3.3 Hive初始化與元數(shù)據(jù)庫(kù)的坑Hive安裝后必須執(zhí)行schematool -initSchema -dbType derby初始化元數(shù)據(jù)。這里我要特別提醒默認(rèn)的Derby數(shù)據(jù)庫(kù)非常脆弱并發(fā)訪問會(huì)直接鎖庫(kù)。如果你需要同時(shí)跑Hive命令行和PySpark讀寫Hive表強(qiáng)烈建議把元數(shù)據(jù)庫(kù)換成MySQL。換MySQL的流程不復(fù)雜在MySQL里創(chuàng)建hive庫(kù)和用戶把hive-site.xml里的javax.jdo.option.ConnectionURL改成jdbc:mysql://localhost:3306/hive同時(shí)把MySQL驅(qū)動(dòng)jar包放到Hive的lib目錄下。這一步做完后你會(huì)發(fā)現(xiàn)PySpark讀寫Hive表時(shí)不會(huì)再莫名其妙地報(bào)鎖表錯(cuò)誤了。這是我從實(shí)際項(xiàng)目中總結(jié)出的優(yōu)先級(jí)先把Hadoop啟動(dòng)起來再用MySQL初始化Hive元數(shù)據(jù)庫(kù)最后才折騰Spark和Hive的集成。順序反了排查成本會(huì)成倍增加。3.4 Windows下用IDEA寫PySpark代碼的調(diào)試手法很多同學(xué)在Linux上搭完環(huán)境卻習(xí)慣在Windows的IDEA里寫代碼。這里有一個(gè)非常實(shí)用的調(diào)試方案Windows上裝一個(gè)Python環(huán)境安裝pyspark包本地用local[*]模式跑通邏輯然后把同樣的代碼部署到Linux上改成yarn模式跑全量數(shù)據(jù)。本地模式的代碼很簡(jiǎn)單SparkSession只需要一行spark SparkSession.builder \ .appName(CharityRec_LocalDebug) \ .master(local[*]) \ .enableHiveSupport() \ .getOrCreate()這樣你在IDEA里就能直接讀Hive表嗎不一定本地模式默認(rèn)沒有Hive的元數(shù)據(jù)連接配置。有一個(gè)變通方案在Windows本地也裝一個(gè)Hive客戶端配置或者直接把需要的數(shù)據(jù)導(dǎo)出成CSV/Parquet文件放在本地路徑用Spark讀文件來調(diào)試算法邏輯。我的做法是算法調(diào)試用本地文件數(shù)據(jù)鏈路聯(lián)調(diào)用Hive表。先把推薦算法在本地文件上跑通確認(rèn)模型收斂、指標(biāo)合理再上集群跑全量數(shù)據(jù)這樣能省下大量等待任務(wù)提交的時(shí)間。還有個(gè)細(xì)節(jié)PySpark在Windows本地跑時(shí)會(huì)報(bào)Failed to locate the winutils錯(cuò)誤你需要下載一個(gè)對(duì)應(yīng)Hadoop版本的winutils.exe放到一個(gè)目錄下并設(shè)置環(huán)境變量HADOOP_HOME。這個(gè)坑幾乎人人都會(huì)踩一次提前知道可以省半天時(shí)間。4. 數(shù)據(jù)倉(cāng)庫(kù)設(shè)計(jì)與ETL實(shí)現(xiàn)從原始捐贈(zèng)流水到特征寬表數(shù)據(jù)是整個(gè)推薦系統(tǒng)最核心的資產(chǎn)也是最容易被畢設(shè)同學(xué)忽視的部分。很多人的做法是直接下個(gè)現(xiàn)成的MovieLens數(shù)據(jù)集改個(gè)字段名就說是慈善捐贈(zèng)數(shù)據(jù)這種做法在答辯時(shí)極其危險(xiǎn)——老師只要問一句你的原始數(shù)據(jù)從哪來的、字段含義是什么就露餡了。我的建議是自己構(gòu)造一套完整的、字段自洽的慈善捐贈(zèng)數(shù)據(jù)集。你可以在GitHub上找一些公開的捐贈(zèng)平臺(tái)脫敏數(shù)據(jù)作為參考也可以按下面這個(gè)模型自己生成。關(guān)鍵是數(shù)據(jù)字段要閉合能支撐起你后面所有的分析和推薦邏輯。4.1 數(shù)據(jù)模型設(shè)計(jì)四張核心表整個(gè)數(shù)倉(cāng)我設(shè)計(jì)為四張表分兩個(gè)層級(jí)。ODS層原始數(shù)據(jù)層有兩張用戶表dim_user用戶ID、姓名脫敏、年齡、性別、所在地區(qū)、注冊(cè)時(shí)間、用戶類型個(gè)人/企業(yè)、偏好標(biāo)簽。項(xiàng)目表dim_project項(xiàng)目ID、項(xiàng)目名稱、項(xiàng)目類別教育/醫(yī)療/扶貧/環(huán)保等、發(fā)起機(jī)構(gòu)、目標(biāo)金額、已籌金額、項(xiàng)目狀態(tài)進(jìn)行中/已結(jié)束、項(xiàng)目標(biāo)簽、上線時(shí)間。DWS層服務(wù)數(shù)據(jù)層也有兩張捐贈(zèng)行為事實(shí)表fact_donation捐贈(zèng)ID、用戶ID、項(xiàng)目ID、捐贈(zèng)金額、捐贈(zèng)時(shí)間、捐贈(zèng)渠道、是否匿名。項(xiàng)目評(píng)分表fact_rating這個(gè)表不是直接采集的而是通過規(guī)則生成的。推薦系統(tǒng)需要用戶對(duì)項(xiàng)目的評(píng)分但捐贈(zèng)平臺(tái)通常沒有顯式評(píng)分所以我們需要從行為中構(gòu)造評(píng)分捐贈(zèng)行為本身就代表高興趣瀏覽、收藏、分享等行為分別賦予不同權(quán)重。構(gòu)造評(píng)分規(guī)則是畢設(shè)的一個(gè)亮點(diǎn)你可以這樣設(shè)計(jì)一次捐贈(zèng)記4-5分按金額分段比如1-100元記4分100元以上記5分收藏記3分瀏覽記1分如果用戶在短時(shí)間內(nèi)重復(fù)瀏覽同一項(xiàng)目加分打折防止刷分。把這套規(guī)則寫清楚放進(jìn)論文就是在告訴評(píng)委我理解了推薦系統(tǒng)需要什么數(shù)據(jù)并且知道如何從原始行為中構(gòu)造它。4.2 ETL清洗鏈路哪些臟數(shù)據(jù)必須處理我實(shí)際清洗中發(fā)現(xiàn)需要重點(diǎn)處理四類臟數(shù)據(jù)重復(fù)捐贈(zèng)記錄同一用戶在同一秒對(duì)同一項(xiàng)目產(chǎn)生兩條完全相同的記錄保留一條。異常金額捐贈(zèng)金額為負(fù)數(shù)或超過單筆上限比如超過5萬的記錄要么剔除要么標(biāo)記為可疑數(shù)據(jù)。無效用戶和項(xiàng)目注冊(cè)時(shí)間在捐贈(zèng)時(shí)間之后的用戶時(shí)間穿越、狀態(tài)為已刪除的項(xiàng)目需要從維度表里過濾掉。編碼不一致項(xiàng)目類別有的寫教育助學(xué)有的寫教育需要做標(biāo)準(zhǔn)化映射。這些清洗邏輯用Hive SQL寫出來非常直觀比如INSERT OVERWRITE TABLE dwd_fact_donation_clean SELECT DISTINCT user_id, project_id, amount, donate_time, channel, is_anonymous FROM ods_fact_donation WHERE amount 0 AND amount 50000 AND donate_time 2023-01-01;注意我用了INSERT OVERWRITE而不是INSERT INTO這是Hive數(shù)倉(cāng)的常見實(shí)踐——每次ETL都全量覆蓋目標(biāo)表保證數(shù)據(jù)可重跑、結(jié)果可復(fù)現(xiàn)。這個(gè)習(xí)慣在畢設(shè)代碼評(píng)審里是加分項(xiàng)。4.3 數(shù)倉(cāng)建模的優(yōu)化點(diǎn)分區(qū)、分桶與小文件治理當(dāng)數(shù)據(jù)量增長(zhǎng)到一定規(guī)模數(shù)倉(cāng)查詢的效率開始成為瓶頸。我在這個(gè)項(xiàng)目里做了三個(gè)關(guān)鍵優(yōu)化第一是分區(qū)。捐贈(zèng)事實(shí)表按時(shí)間分區(qū)dt字段每天的數(shù)據(jù)進(jìn)入一個(gè)分區(qū)。Hive查詢時(shí)只需要掃描涉及的分區(qū)而不是全表。對(duì)推薦系統(tǒng)來說通常只關(guān)心最近一年或者最近兩年的數(shù)據(jù)分區(qū)裁剪能大幅減少I/O。第二是分桶。如果后續(xù)要頻繁做join操作可以在事實(shí)表上按user_id分桶這樣相同用戶的捐贈(zèng)記錄一定落在同一個(gè)桶文件里join時(shí)可以直接在桶內(nèi)完成避免全量shuffle。第三是小文件合并。這是Hive最經(jīng)典的優(yōu)化點(diǎn)也是熱搜里提到的hive優(yōu)化小文件問題。當(dāng)大量小文件比如每個(gè)只有幾KB堆積在表目錄下時(shí)HDFS的NameNode會(huì)承受巨大壓力Spark讀取時(shí)的task數(shù)量也會(huì)爆炸。問題根源通常是上游任務(wù)產(chǎn)生太多輸出文件或分區(qū)數(shù)據(jù)量本身太小。我在項(xiàng)目里用兩種方式解決一是建表時(shí)設(shè)置TBLPROPERTIES二是定期執(zhí)行合并查詢INSERT OVERWRITE TABLE dwd_fact_donation_clean SELECT * FROM dwd_fact_donation_clean DISTRIBUTE BY CAST(RAND() * 10 AS INT);DISTRIBUTE BY關(guān)鍵字會(huì)讓數(shù)據(jù)隨機(jī)分散到10個(gè)文件中再覆蓋寫回這樣1000個(gè)小文件就變成了10個(gè)相對(duì)均勻的大文件。這個(gè)技巧我在答辯時(shí)重點(diǎn)講過評(píng)委明顯對(duì)你關(guān)注到了生產(chǎn)環(huán)境的典型問題這一點(diǎn)很認(rèn)可。4.4 刪除亂碼分區(qū)一個(gè)必須提前知道的坑在實(shí)際操作中我遇到過一個(gè)問題因?yàn)橐淮五e(cuò)誤的動(dòng)態(tài)分區(qū)插入Hive表里多出一個(gè)名為__HIVE_DEFAULT_PARTITION__的亂碼分區(qū)數(shù)據(jù)全部堆在這個(gè)默認(rèn)分區(qū)里正常的WHERE dt2024-03-01永遠(yuǎn)查不到數(shù)據(jù)。排查過程是這樣的先看到任務(wù)日志提示有動(dòng)態(tài)分區(qū)但分區(qū)值顯示為NULL再看表的分區(qū)列表發(fā)現(xiàn)多了一個(gè)名為__HIVE_DEFAULT_PARTITION__的分區(qū)確認(rèn)是插入時(shí)部分記錄的分區(qū)字段為NULL導(dǎo)致的。解決方法是先處理數(shù)據(jù)中的NULL值然后刪除異常分區(qū)ALTER TABLE dwd_fact_donation DROP PARTITION (dt__HIVE_DEFAULT_PARTITION__);這個(gè)坑的根因是動(dòng)態(tài)分區(qū)插入時(shí)如果分區(qū)字段的值為NULL而建表時(shí)又開啟了hive.exec.dynamic.partitiontrueHive不會(huì)報(bào)錯(cuò)而是默默把這些記錄塞進(jìn)默認(rèn)分區(qū)。根治方法是ETL前置校驗(yàn)在插入前用WHERE dt IS NOT NULL過濾掉這些記錄。我把這個(gè)排查過程原原本本寫進(jìn)了論文的問題與解決章節(jié)比任何教科書案例都有說服力。5. 推薦引擎設(shè)計(jì)與實(shí)現(xiàn)協(xié)同過濾冷啟動(dòng)的落地組合環(huán)境搭好、數(shù)據(jù)備好接下來是重頭戲——推薦算法。我選擇的方案是ALS協(xié)同過濾為主干基于內(nèi)容相似度的召回為補(bǔ)充兩者的結(jié)果做加權(quán)融合。5.1 算法選型為什么不用深度學(xué)習(xí)先說清楚為什么不用深度學(xué)習(xí)。在答辯時(shí)老師幾乎必問這個(gè)問題現(xiàn)在的推薦系統(tǒng)不都是深度學(xué)習(xí)嗎你為什么用ALS我的回答邏輯是這是一個(gè)離線推薦系統(tǒng)數(shù)據(jù)規(guī)模控制在百萬級(jí)以內(nèi)深度學(xué)習(xí)模型在這個(gè)量級(jí)下無法體現(xiàn)出比協(xié)同過濾更優(yōu)的效果反而帶來了調(diào)參復(fù)雜、訓(xùn)練時(shí)間增長(zhǎng)、可解釋性下降的問題。ALS在可解釋性、訓(xùn)練效率、部署難度上都有明顯優(yōu)勢(shì)而且Spark MLlib對(duì)它做了高度優(yōu)化適合畢設(shè)這種需要完整跑通全鏈路的場(chǎng)景。當(dāng)然為了展示你了解前沿可以在論文里增加一個(gè)小節(jié)討論如果數(shù)據(jù)量達(dá)到億級(jí)、特征維度增加如何演進(jìn)到兩 Tower 或 Graph Embedding 方案但主線保持ALS。這里有一個(gè)關(guān)于PySpark的ALS的關(guān)鍵實(shí)現(xiàn)細(xì)節(jié)——ALS基于顯式評(píng)分矩陣但我們的評(píng)分是隱式反饋構(gòu)造的。ALS有兩種模式explicit和implicit。隱式反饋場(chǎng)景有大量零值、用戶未交互不代表不喜歡應(yīng)該用implicitPrefsTrue并配合alpha參數(shù)控制置信度。我寫的是from pyspark.ml.recommendation import ALS from pyspark.ml.evaluation import RegressionEvaluator als ALS( userColuser_idx, itemColproject_idx, ratingColrating, implicitPrefsTrue, alpha10.0, rank20, maxIter15, regParam0.1, coldStartStrategydrop )coldStartStrategydrop也很關(guān)鍵——模型訓(xùn)練后如果預(yù)測(cè)時(shí)遇到訓(xùn)練集中沒出現(xiàn)過的用戶或項(xiàng)目會(huì)產(chǎn)生空值如果不處理會(huì)導(dǎo)致評(píng)估指標(biāo)變成NaN。5.2 PySpark實(shí)現(xiàn)ALS推薦的關(guān)鍵步驟與完整流程ALS的完整代碼流程大概是五步第一步ID索引化。ALS要求用戶ID和項(xiàng)目ID必須是數(shù)值型且從0開始連續(xù)編號(hào)。Spark提供了StringIndexer可以自動(dòng)把字符串ID映射成數(shù)值索引from pyspark.ml.feature import StringIndexer user_indexer StringIndexer(inputColuser_id, outputColuser_idx) project_indexer StringIndexer(inputColproject_id, outputColproject_idx) pipeline Pipeline(stages[user_indexer, project_indexer])第二步劃分訓(xùn)練集和測(cè)試集。用randomSplit按8:2切分。注意最好加上種子seed42保證實(shí)驗(yàn)可復(fù)現(xiàn)。第三步訓(xùn)練ALS模型。用訓(xùn)練集擬合。第四步評(píng)估模型。用測(cè)試集做預(yù)測(cè)計(jì)算RMSE或AUC。這里我用了RegressionEvaluatorevaluator RegressionEvaluator( metricNamermse, labelColrating, predictionColprediction ) rmse evaluator.evaluate(predictions)第五步生成TopN推薦。對(duì)每個(gè)用戶調(diào)用recommendForAllUsers(10)得到每個(gè)用戶評(píng)分最高的10個(gè)項(xiàng)目。我實(shí)際跑下來的經(jīng)驗(yàn)是rank隱因子數(shù)和regParam正則化參數(shù)是最影響效果的兩個(gè)參數(shù)。rank太小比如5模型欠擬合rank太大比如100訓(xùn)練時(shí)間長(zhǎng)且容易過擬合。我用網(wǎng)格搜索試下來rank20、regParam0.1在200萬條數(shù)據(jù)上效果和性能最均衡。你可以用ParamGridBuilder配合TrainValidationSplit做自動(dòng)調(diào)參但注意這會(huì)讓訓(xùn)練時(shí)間成倍增加畢設(shè)場(chǎng)景下手動(dòng)調(diào)兩三組參數(shù)就夠了。5.3 冷啟動(dòng)基于項(xiàng)目?jī)?nèi)容的召回怎么設(shè)計(jì)協(xié)同過濾最大的痛點(diǎn)是冷啟動(dòng)新用戶沒有歷史行為新項(xiàng)目沒有評(píng)分記錄ALS完全無法處理。我在項(xiàng)目中設(shè)計(jì)了一個(gè)并行的召回通道——基于項(xiàng)目屬性的內(nèi)容推薦。具體做法是給每個(gè)項(xiàng)目打標(biāo)簽類別、目標(biāo)人群、地域、受益人類型然后計(jì)算項(xiàng)目的TF-IDF向量或直接使用類別向量用余弦相似度找到和你曾經(jīng)捐贈(zèng)過項(xiàng)目最相似的其他項(xiàng)目。這個(gè)通道的邏輯很簡(jiǎn)單你給鄉(xiāng)村兒童閱讀項(xiàng)目捐過款那系統(tǒng)就給你推薦同屬教育助學(xué)類別、且項(xiàng)目標(biāo)簽含兒童閱讀的項(xiàng)目。它不依賴協(xié)同過濾的用戶評(píng)分?jǐn)?shù)據(jù)所以對(duì)新用戶也有效——新用戶注冊(cè)時(shí)可以選幾個(gè)感興趣的項(xiàng)目類別系統(tǒng)就能立即給出推薦結(jié)果。最終推薦融合的策略我用了加權(quán)協(xié)同過濾的結(jié)果占70%權(quán)重內(nèi)容召回的占30%對(duì)于行為數(shù)少于5條的用戶直接100%走內(nèi)容召回。這個(gè)策略在離線評(píng)估中比純ALS的覆蓋率提升了近40%比純內(nèi)容推薦的精確率提升了25%。把這些數(shù)字寫進(jìn)論文就是實(shí)打?qū)嵉膶?shí)驗(yàn)結(jié)果。6. 踩坑實(shí)錄大數(shù)據(jù)項(xiàng)目里那些文檔不會(huì)寫的問題這一章我要把我在這個(gè)項(xiàng)目中實(shí)際踩過、并且花時(shí)間最長(zhǎng)解決的四個(gè)問題完整記錄下來。這些問題有兩個(gè)價(jià)值一是幫你提前避開二是如果答辯被問到項(xiàng)目中最難解決的問題你可以講出一條完整的排查鏈路——這是最能證明你真實(shí)動(dòng)手做過項(xiàng)目的地方。6.1 數(shù)據(jù)傾斜某些任務(wù)永遠(yuǎn)跑不完第一個(gè)問題是數(shù)據(jù)傾斜?，F(xiàn)象是ALS訓(xùn)練時(shí)某些Executor上堆了一堆任務(wù)在跑其他Executor卻閑著整個(gè)作業(yè)拖了幾十分鐘還沒結(jié)束。當(dāng)時(shí)我先去看了YARN的日志發(fā)現(xiàn)有個(gè)別Reduce任務(wù)處理的數(shù)據(jù)量是平均值的幾十倍基本確定是數(shù)據(jù)傾斜。數(shù)據(jù)傾斜的根因通常在join或groupBy時(shí)某個(gè)key的數(shù)據(jù)量遠(yuǎn)超其他key。在這個(gè)項(xiàng)目里傾斜的key是熱門項(xiàng)目——某個(gè)明星公益項(xiàng)目的捐贈(zèng)記錄比其他項(xiàng)目高兩個(gè)數(shù)量級(jí)導(dǎo)致按項(xiàng)目聚合時(shí)那個(gè)key對(duì)應(yīng)的處理量巨大。解決方案有三個(gè)我按優(yōu)先級(jí)排序加鹽對(duì)傾斜的項(xiàng)目ID拼接一個(gè)隨機(jī)前綴把大key拆成多個(gè)小key處理完后再去掉前綴合并。這是最通用的解法。廣播小表如果傾斜的原因是join時(shí)小表太小直接使用Spark的broadcast提示避免shuffle。調(diào)整并行度把spark.sql.shuffle.partitions從默認(rèn)的200調(diào)高到400或800讓數(shù)據(jù)分散到更多task里。我的實(shí)際處理是加鹽調(diào)并行度雙管齊下訓(xùn)練時(shí)間從40多分鐘降到了11分鐘。這個(gè)問題寫在論文里時(shí)我配了一張傾斜前后任務(wù)耗時(shí)對(duì)比的表答辯老師看了直點(diǎn)頭。6.2 PySpark任務(wù)在YARN上反復(fù)OOM第二個(gè)問題是OOM。在本地跑得好好的ALS代碼一提交到Y(jié)ARN上就報(bào)Container killed by the ResourceManager。排查的思路是先看日志里是物理內(nèi)存超了還是虛擬內(nèi)存超了再對(duì)應(yīng)調(diào)整參數(shù)。我遇到的是典型的虛擬內(nèi)存超限問題。YARN默認(rèn)yarn.nodemanager.vmem-check-enabledtrue它會(huì)檢查每個(gè)容器使用的虛擬內(nèi)存一旦超過設(shè)定比例就殺掉容器。而PySpark的Python進(jìn)程非常吃虛擬內(nèi)存很容易觸發(fā)這個(gè)檢查。解決的配置是三個(gè)property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property property nameyarn.scheduler.maximum-allocation-mb/name value3072/value /property property namespark.executor.memoryOverhead/name value1024/value /propertyspark.executor.memoryOverhead尤其重要它給每個(gè)Executor額外預(yù)留了1G的堆外內(nèi)存專門給Python進(jìn)程和序列化緩沖用。我把這個(gè)經(jīng)驗(yàn)總結(jié)為一句跑PySpark先想到Python進(jìn)程的開銷再想JVM的開銷。6.3 自定義UDAF什么時(shí)候真的需要它熱搜里提到了hive自定義udaf函數(shù)我在這個(gè)項(xiàng)目里也用過一次。場(chǎng)景是在構(gòu)造項(xiàng)目評(píng)分表時(shí)我需要計(jì)算每個(gè)用戶對(duì)每個(gè)項(xiàng)目在最近30天內(nèi)的綜合活躍度這個(gè)綜合活躍度不是簡(jiǎn)單的sum而是帶時(shí)間衰減的加權(quán)平均值——最近的行為權(quán)重高早期的行為權(quán)重低。Hive自帶的聚合函數(shù)做不了這種自定義邏輯所以我寫了一個(gè)UDAF。完整代碼不貼了但核心流程是繼承GenericUDAFResolver2實(shí)現(xiàn)init、iterate、merge、terminate四個(gè)方法。iterate逐行累加狀態(tài)merge合并不同map任務(wù)的部分結(jié)果terminate輸出最終值。這里我要給一個(gè)非常實(shí)在的建議畢設(shè)項(xiàng)目里能不用UDAF就別用優(yōu)先用Hive SQL的collect_list自定義UDF組合。UDAF的調(diào)試門檻高不同版本的Hive接口還不一樣容易白費(fèi)功夫。我當(dāng)時(shí)寫UDAF是因?yàn)檫@個(gè)時(shí)間衰減邏輯確實(shí)復(fù)雜但如果你只是做簡(jiǎn)單的推薦特征用SUM(CASE WHEN ... THEN ... END)就足夠了。技術(shù)選型的第一原則是夠用而不是炫技。6.4 Hive小文件問題的完整排查鏈路前面第4章提過小文件治理這里展開講一遍完整的排查過程因?yàn)檫@個(gè)問題的排查思路具有代表性?，F(xiàn)象表目錄下出現(xiàn)幾萬個(gè)幾KB的小文件Hive查詢?cè)絹碓铰齋park讀取時(shí)task數(shù)量暴漲。排查鏈路第一步看小文件從哪來。用hdfs dfs -count查看目錄下文件數(shù)和大小發(fā)現(xiàn)大部分小文件來自INSERT OVERWRITE SELECT語句而且每天跑的任務(wù)都會(huì)生成新的一批。第二步定位生成小文件的語句。檢查ETL腳本發(fā)現(xiàn)是動(dòng)態(tài)分區(qū)插入時(shí)每個(gè)分區(qū)只寫入少量數(shù)據(jù)Spark/Hive為每個(gè)分區(qū)至少生成一個(gè)文件分區(qū)多了文件自然就多了。第三步確認(rèn)根因后從兩個(gè)方向治理源頭治理——在ETL前增加數(shù)據(jù)量過濾減少無效分區(qū)存量治理——用第4章寫的DISTRIBUTE BY合并文件。第四步加表屬性TBLPROPERTIES (hive.merge.mapfilestrue, hive.merge.mapredfilestrue, hive.merge.size.per.task256000000)讓Hive在Tez執(zhí)行時(shí)自動(dòng)合并輸出文件。這套現(xiàn)象 - 定位 - 根因 - 治理的鏈路我完整地寫進(jìn)了畢業(yè)論文的系統(tǒng)調(diào)優(yōu)章節(jié)。這比任何我用了Hive的效果都好因?yàn)樗C明了你在真實(shí)的問題環(huán)境中思考和解決問題。7. 畢業(yè)設(shè)計(jì)交付的正確姿勢(shì)源碼、文檔、PPT和講解答辯怎么組織技術(shù)做好了剩下的問題是怎么呈現(xiàn)。畢設(shè)和實(shí)際項(xiàng)目有一個(gè)重大區(qū)別它的交付物不僅是能跑的代碼還有能講的故事。我見過太多代碼寫得不錯(cuò)但論文寫得像流水賬、答辯時(shí)講不清楚技術(shù)亮點(diǎn)的同學(xué)最后分?jǐn)?shù)并不高。這一章我重點(diǎn)講怎么把項(xiàng)目講好。7.1 源碼結(jié)構(gòu)像工程而不是作業(yè)源碼的組織方式會(huì)直接影響老師對(duì)你工程能力的判斷。一個(gè)建議的目錄結(jié)構(gòu)charity-recommend/ ├── data/ │ ├── raw/ # 原始數(shù)據(jù)模擬生成腳本 │ └── etl/ # ETL腳本輸出 ├── etl/ │ ├── ods_to_dwd.hql # 清洗SQL │ └── dwd_to_ads.hql # 特征寬表SQL ├── rec/ │ ├── train_als.py # ALS訓(xùn)練 │ ├── evaluate.py # 離線評(píng)估 │ └── recommend.py # TopN推薦生成 ├── web/ │ └── app.py # 推薦結(jié)果展示Flask可選 ├── docs/ │ ├── 數(shù)據(jù)庫(kù)設(shè)計(jì)說明.md │ └── 接口文檔.md └── README.md # 環(huán)境搭建與運(yùn)行說明這里有個(gè)細(xì)節(jié)SQL腳本和Python腳本分開存放不要混在一起。因?yàn)镠ive SQL和PySpark代碼的運(yùn)行方式不同分開管理能體現(xiàn)你思路的清晰。GitHub上放源碼時(shí)README一定要寫清楚環(huán)境要求、啟動(dòng)順序、每個(gè)腳本的用途。我見過很多學(xué)生直接把代碼打包扔進(jìn)百度網(wǎng)盤鏈接還設(shè)置7天有效期——這種行為在評(píng)審眼里就是不專業(yè)。7.2 畢業(yè)論文的結(jié)構(gòu)與核心章節(jié)寫作論文結(jié)構(gòu)推薦這個(gè)骨架緒論背景、意義、國(guó)內(nèi)外研究現(xiàn)狀相關(guān)技術(shù)介紹Hadoop、Hive、PySpark、推薦算法原理系統(tǒng)需求分析與總體設(shè)計(jì)功能性需求、架構(gòu)圖、技術(shù)選型理由系統(tǒng)詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)數(shù)據(jù)模型、ETL鏈路、推薦算法流程系統(tǒng)測(cè)試與結(jié)果分析環(huán)境測(cè)試、性能測(cè)試、推薦效果評(píng)估總結(jié)與展望最容易寫砸的是第2章。很多同學(xué)把這章寫成百度百科式的技術(shù)名詞抄錄大段大段的官網(wǎng)介紹復(fù)制粘貼老師一眼就看出來是拼湊的。我建議第2章的寫法是每個(gè)技術(shù)只寫它是什么和它在這個(gè)項(xiàng)目中負(fù)責(zé)什么。比如寫Hive重點(diǎn)不要放在Hive是基于Hadoop的數(shù)據(jù)倉(cāng)庫(kù)工具由Facebook開發(fā)這種背景上而應(yīng)該寫本項(xiàng)目使用Hive完成捐贈(zèng)數(shù)據(jù)的清洗與建模通過創(chuàng)建外部表關(guān)聯(lián)HDFS上的原始文件。第4章是核心代碼不要全部貼每個(gè)模塊選3-5段關(guān)鍵代碼配合功能描述和流程圖。代碼要精注釋要有能直接證明這個(gè)模塊能跑。7.3 PPT骨架與答辯常見問題應(yīng)對(duì)PPT總頁(yè)數(shù)控制在15-20頁(yè)結(jié)構(gòu)是題目頁(yè) - 背景與意義2頁(yè)- 相關(guān)技術(shù)2頁(yè)- 系統(tǒng)架構(gòu)2頁(yè)- 數(shù)據(jù)模型2頁(yè)- 推薦算法實(shí)現(xiàn)3頁(yè)- 結(jié)果展示3頁(yè)- 總結(jié)與展望1頁(yè)。答辯時(shí)老師最愛問的問題我給一份清單你的數(shù)據(jù)量有多大足夠說明問題嗎 ——答案是模擬生成了200萬條捐贈(zèng)記錄同時(shí)用公開脫敏數(shù)據(jù)做了驗(yàn)證數(shù)據(jù)規(guī)模可以調(diào)整影響的是計(jì)算時(shí)間而不是算法有效性。ALS的隱因子是什么意思 ——一定要能解釋清楚隱因子是用戶和物品在潛在特征空間中的向量表示通過矩陣分解得到例如教育偏好醫(yī)療關(guān)注度這類不可直接觀察的特征。你的推薦和淘寶的商品推薦有什么關(guān)系和區(qū)別 ——可以從數(shù)據(jù)稀疏度、行為語義、冷啟動(dòng)難度三個(gè)角度回答這能顯示你的思考深度。如果數(shù)據(jù)量再擴(kuò)大十倍你的系統(tǒng)哪里會(huì)先撐不住 ——需要你指出瓶頸比如ALS訓(xùn)練的shuffle成本會(huì)顯著上升、單節(jié)點(diǎn)元數(shù)據(jù)管理的壓力增大并說明可以怎么優(yōu)化換分布式訓(xùn)練的Spark集群、引入增量更新。這幾道題的答案一定要寫進(jìn)論文的第5章或者答辯PPT的附錄里。我甚至建議你在準(zhǔn)備階段就對(duì)著鏡子把答案說幾遍——答辯時(shí)的臨場(chǎng)表達(dá)和你在鍵盤上敲出來的文字完全是兩種要求。8. 寫在最后如果讓我重新做一遍這個(gè)項(xiàng)目會(huì)有什么不同項(xiàng)目交付到現(xiàn)在說實(shí)話我最大的感受是這個(gè)題目最值錢的部分不是算法多先進(jìn)、技術(shù)多炫酷而是它逼著你把一整套大數(shù)據(jù)技術(shù)棧真實(shí)地串起來走了一遍——從環(huán)境搭建、數(shù)據(jù)建模、ETL清洗、算法訓(xùn)練到結(jié)果評(píng)估每一個(gè)環(huán)節(jié)都有實(shí)際產(chǎn)物每一個(gè)環(huán)節(jié)都能在答辯時(shí)講出我做過、我踩過坑、我會(huì)解決的底氣。如果重新做一遍我會(huì)在三個(gè)地方做出改變一是在數(shù)據(jù)層面會(huì)更早地對(duì)接真實(shí)的公開慈善數(shù)據(jù)做補(bǔ)充驗(yàn)證而不是只靠模擬數(shù)據(jù)。模擬數(shù)據(jù)在字段邏輯上容易自洽但真實(shí)數(shù)據(jù)的噪聲和臟數(shù)據(jù)會(huì)更考驗(yàn)ETL設(shè)計(jì)。二是在推薦算法層面會(huì)嘗試在ALS基礎(chǔ)上增加一個(gè)基于規(guī)則的緊急救助項(xiàng)目推薦通道。慈善領(lǐng)域有一個(gè)特點(diǎn)時(shí)效性強(qiáng)的求助項(xiàng)目需要被更多人看到這和純興趣推薦的目標(biāo)有一定沖突但結(jié)合起來能極大提升推薦結(jié)果的社會(huì)價(jià)值。這也是這個(gè)題目區(qū)別于商業(yè)推薦系統(tǒng)的地方。三是會(huì)在交付物里增加一個(gè)簡(jiǎn)單的可視化展示界面用Flask搭一個(gè)極簡(jiǎn)后臺(tái)把推薦結(jié)果以網(wǎng)頁(yè)形式展示出來。技術(shù)上不難但答辯時(shí)的演示效果會(huì)好很多——評(píng)委看到的不只是命令行輸出的結(jié)果而是一個(gè)系統(tǒng)。最后分享一個(gè)很小的實(shí)用技巧提交Hive任務(wù)時(shí)養(yǎng)成用hive -f etl.hql --hiveconf dt2024-03-01傳參的習(xí)慣把日期和關(guān)鍵參數(shù)參數(shù)化不要寫死在SQL里。這樣當(dāng)你需要重跑某個(gè)時(shí)間段的數(shù)據(jù)時(shí)只需要改參數(shù)而不是改代碼。這個(gè)習(xí)慣在大廠面試的你如何設(shè)計(jì)可重跑的數(shù)倉(cāng)任務(wù)問題里也是實(shí)實(shí)在在的加分項(xiàng)。希望這篇文章能幫到正在和Hadoop、PySpark、Hive搏斗的你。這個(gè)選題不難但也不水關(guān)鍵是踏踏實(shí)實(shí)把每一步走通。有任何環(huán)境搭建、代碼調(diào)試或者答辯準(zhǔn)備的問題歡迎在評(píng)論區(qū)交流。