又是一年畢業(yè)設(shè)計(jì)開題季群里刷到最多的題目就是“基于大數(shù)據(jù)爬蟲Hadoop的游戲購買網(wǎng)站設(shè)計(jì)與實(shí)現(xiàn)”。這個(gè)題目我前前后后帶過好幾屆學(xué)生自己也親手搭過完整的一版說句實(shí)話題目看著唬人拆開其實(shí)就三件事——爬蟲負(fù)責(zé)把游戲數(shù)據(jù)抓下來Hadoop負(fù)責(zé)把數(shù)據(jù)存得住、算得動(dòng)網(wǎng)站負(fù)責(zé)把結(jié)果漂亮地?cái)[出來。難點(diǎn)不在某一個(gè)環(huán)節(jié)而在三個(gè)環(huán)節(jié)怎么串成一條線。這篇就把我實(shí)際做這個(gè)項(xiàng)目時(shí)踩過的坑、驗(yàn)證過的方案、寫論文時(shí)能撐起頁數(shù)的核心細(xì)節(jié)全部攤開講。無論你是剛拿到這個(gè)題目準(zhǔn)備開題還是已經(jīng)寫到中期發(fā)現(xiàn)架構(gòu)跑不通照著下面的思路去調(diào)整都能少走很多彎路。1. 項(xiàng)目整體設(shè)計(jì)與思路拆解1.1 題目到底在問什么先把這個(gè)題目的三層邏輯理清。第一層是數(shù)據(jù)來源也就是爬蟲部分。你要從游戲電商平臺(tái)、評(píng)分網(wǎng)站、游戲百科等站點(diǎn)采集游戲信息包括名稱、類型、價(jià)格、評(píng)分、開發(fā)商、發(fā)行日期、玩家評(píng)價(jià)數(shù)量這些字段。第二層是數(shù)據(jù)處理也就是Hadoop部分。采集到的數(shù)據(jù)是半結(jié)構(gòu)化的JSON或者CSV數(shù)據(jù)量達(dá)到一定規(guī)模之后Excel和MySQL就扛不住了需要借助HDFS做分布式存儲(chǔ)用MapReduce或者Hive做離線統(tǒng)計(jì)分析。第三層是業(yè)務(wù)呈現(xiàn)也就是游戲購買網(wǎng)站。網(wǎng)站本身是一個(gè)典型的電商前臺(tái)展示游戲列表、詳情、搜索和模擬購買功能同時(shí)把Hadoop算出來的熱門游戲、評(píng)分排行、價(jià)格分布等結(jié)果可視化成報(bào)表頁面。很多學(xué)生在這個(gè)題目上翻車是因?yàn)榘阉?dāng)成三個(gè)獨(dú)立的子項(xiàng)目分開做最后拼不起來。正確的思路是爬蟲產(chǎn)出的數(shù)據(jù)必須按照Hadoop能夠直接消費(fèi)的格式落地Hadoop的分析結(jié)果必須按照數(shù)據(jù)庫表或者JSON接口的形式輸出給網(wǎng)站調(diào)用。數(shù)據(jù)的流向一旦在設(shè)計(jì)階段沒有明確后期聯(lián)調(diào)就是噩夢。1.2 技術(shù)架構(gòu)怎么選才不虛我建議采用分層架構(gòu)每層只干一件事數(shù)據(jù)采集層Python Requests BeautifulSoup/Scrapy負(fù)責(zé)爬取和清洗數(shù)據(jù)數(shù)據(jù)存儲(chǔ)與計(jì)算層Hadoop HDFS存儲(chǔ)原始數(shù)據(jù)Hive做數(shù)據(jù)清洗和統(tǒng)計(jì)分析Sqoop把結(jié)果導(dǎo)出到MySQL業(yè)務(wù)應(yīng)用層Spring Boot MyBatis MySQL ECharts負(fù)責(zé)網(wǎng)站后端接口和前端頁面展示這套架構(gòu)的好處是每一層都有明確的輸入輸出寫論文的時(shí)候每一層都可以獨(dú)立成章。更重要的是它把一個(gè)看似復(fù)雜的系統(tǒng)拆成了“數(shù)據(jù)從哪來、數(shù)據(jù)怎么算、數(shù)據(jù)怎么用”三個(gè)問題對應(yīng)的正是開題報(bào)告里“國內(nèi)外研究現(xiàn)狀”“系統(tǒng)需求分析”“系統(tǒng)設(shè)計(jì)”“系統(tǒng)實(shí)現(xiàn)”這幾個(gè)必須寫的板塊。1.3 為什么一定要上Hadoop能不能不用這個(gè)問題開題答辯老師必問你心里要有底。如果你的數(shù)據(jù)量只有幾千條MySQL一個(gè)表就搞定了完全不需要Hadoop。但這個(gè)題目的意義在于處理“大數(shù)據(jù)”場景——爬蟲持續(xù)運(yùn)行一個(gè)月游戲信息加上玩家評(píng)論和價(jià)格歷史記錄數(shù)據(jù)量可以輕松達(dá)到百萬條以上。這個(gè)時(shí)候HDFS的分布式存儲(chǔ)、MapReduce的并行計(jì)算、Hive的類SQL分析能力才有用武之地。另一個(gè)角度是技術(shù)學(xué)習(xí)價(jià)值。Hadoop生態(tài)的搭建過程本身涉及Linux操作、集群配置、網(wǎng)絡(luò)通信、分布式一致性等知識(shí)點(diǎn)一套流程走下來對大數(shù)據(jù)技術(shù)棧的理解會(huì)有一個(gè)質(zhì)的提升。答辯的時(shí)候你說得出“為什么用Hive而不是直接寫MapReduce”“為什么需要Zookeeper協(xié)調(diào)集群”這比單純堆技術(shù)名詞有說服力得多。2. 大數(shù)據(jù)爬蟲子系統(tǒng)的核心實(shí)現(xiàn)2.1 爬蟲采集策略與字段設(shè)計(jì)爬蟲不能上來就寫代碼先把目標(biāo)和字段定清楚。游戲購買網(wǎng)站需要的數(shù)據(jù)字段我實(shí)際項(xiàng)目里最終用的是這一套游戲名稱、英文名、封面圖URL游戲類型多標(biāo)簽、開發(fā)商、發(fā)行商、發(fā)行日期當(dāng)前價(jià)格、原價(jià)、折扣率玩家評(píng)分、評(píng)價(jià)數(shù)量、好評(píng)率游戲簡介、支持語言、最低配置字段設(shè)計(jì)的核心原則是“寧寬勿窄”。比如價(jià)格字段我建議把當(dāng)前價(jià)格和歷史最低價(jià)都保存下來后面做價(jià)格分析和折扣趨勢預(yù)測時(shí)數(shù)據(jù)一下子就豐富了。同理游戲類型用多標(biāo)簽逗號(hào)分隔存方便Hive里做explode操作統(tǒng)計(jì)各種類型的占比。采集策略上我用的是Scrapy框架加CrawlSpider。相比自己寫Requests循環(huán)Scrapy的并發(fā)下載、去重過濾、請求重試機(jī)制都是現(xiàn)成的爬取效率高很多。需要注意目標(biāo)網(wǎng)站的robots協(xié)議和訪問頻率建議設(shè)置Download Delay在3到5秒之間既能減輕對方服務(wù)器壓力也能降低被封IP的風(fēng)險(xiǎn)。# Scrapy爬蟲核心配置示例 DOWNLOAD_DELAY 3.0 CONCURRENT_REQUESTS 8 RETRY_ENABLED True RETRY_TIMES 52.2 爬下來的數(shù)據(jù)怎么清洗和去重爬蟲拿到的是HTML頁面要用BeautifulSoup或XPath解析出結(jié)構(gòu)化數(shù)據(jù)。清洗環(huán)節(jié)有幾個(gè)高頻問題價(jià)格字段里包含多余字符比如“￥ 198.00”要正則提取數(shù)字部分轉(zhuǎn)成浮點(diǎn)數(shù)評(píng)分字段可能是“9.1/10”或“92%”需要統(tǒng)一成0到10區(qū)間的數(shù)值游戲名稱里可能混有換行符和空白字符要strip掉同一款游戲在不同頁面重復(fù)出現(xiàn)需要按名稱加發(fā)行商做聯(lián)合去重去重邏輯我建議在寫入時(shí)做兩層第一層用Scrapy自帶的RFPDupeFilter對URL去重第二層在數(shù)據(jù)清洗完成后用游戲名稱的MD5值做指紋去重。清洗完的數(shù)據(jù)統(tǒng)一輸出成JSON Lines格式每行一條記錄這種格式Hive可以直接loadHadoop生態(tài)對JSON支持也最友好。# 清洗后數(shù)據(jù)落地格式 {name: 艾爾登法環(huán), genres: 動(dòng)作,角色扮演, price: 298.00, rating: 9.5, ...}2.3 反爬應(yīng)對與穩(wěn)定性保障這部分是論文里體現(xiàn)“工作量”的重點(diǎn)。常見的反爬手段是加User-Agent池、IP代理池、請求頭模擬瀏覽器。實(shí)際項(xiàng)目里我做了UA池掛了大概30個(gè)常見的瀏覽器UA每次請求隨機(jī)取一個(gè)。IP代理池原理不復(fù)雜難在代理源的維護(hù)如果只是課程設(shè)計(jì)級(jí)別本地IP加低頻請求就夠用了。更關(guān)鍵的是爬蟲的容錯(cuò)機(jī)制。網(wǎng)絡(luò)請求不可能100%成功要處理超時(shí)重試、頁面結(jié)構(gòu)變化導(dǎo)致的解析異常以及目標(biāo)網(wǎng)站的反爬策略升級(jí)。我的做法是寫了一個(gè)異常處理裝飾器單個(gè)頁面解析失敗就記錄日志跳過不中斷整體任務(wù)。這個(gè)設(shè)計(jì)讓爬蟲可以掛著跑幾天不用人工干預(yù)到寫論文時(shí)我整理了爬蟲爬了大約50萬條有效記錄覆蓋了近萬個(gè)游戲產(chǎn)品數(shù)據(jù)量完全夠Hadoop做統(tǒng)計(jì)分析。3. Hadoop環(huán)境搭建與落坑記錄3.1 偽分布式還是集群先搞清楚很多學(xué)生的畢設(shè)環(huán)境是一臺(tái)普通PC內(nèi)存8G或者16G這個(gè)時(shí)候硬上三節(jié)點(diǎn)集群很容易把自己搞崩潰。我建議起步階段先搭偽分布式模式也就是在一臺(tái)機(jī)器上同時(shí)運(yùn)行NameNode、DataNode、ResourceManager、NodeManager這些角色。偽分布式不是玩具它的進(jìn)程模型和真實(shí)集群完全一致只是把多臺(tái)機(jī)器的角色壓縮到一臺(tái)機(jī)器上。跑通了偽分布式理解了HDFS的文件上傳下載流程和MapReduce的任務(wù)調(diào)度機(jī)制后面再擴(kuò)展集群只是改配置文件的事。如果你確實(shí)要搭真實(shí)集群最少需要三臺(tái)節(jié)點(diǎn)比如一臺(tái)Master跑NameNode和ResourceManager兩臺(tái)Slave跑DataNode和NodeManager。機(jī)器可以用虛擬機(jī)或者云服務(wù)器但要注意內(nèi)網(wǎng)互通和SSH免密登錄配置。我用三臺(tái)虛擬機(jī)實(shí)測下來一個(gè)幾千萬級(jí)的MapReduce任務(wù)偽分布式可能要跑20分鐘集群可以縮短到11分鐘左右這個(gè)對比數(shù)據(jù)在論文里是很有力的支撐。3.2 偽分布式搭建的完整步驟環(huán)境準(zhǔn)備階段建議使用CentOS 7或者Ubuntu Server 18.04以上的版本JDK必須用1.8版本Hadoop 2.x對這個(gè)版本的兼容性最好。下面是我反復(fù)驗(yàn)證過的搭建流程創(chuàng)建hadoop用戶并配置免密登錄生成SSH密鑰把公鑰加到authorized_keys里下載Hadoop 2.10.2安裝包解壓到/opt/module目錄配置HADOOP_HOME環(huán)境變量修改core-site.xml配置fs.defaultFS為hdfs://localhost:9000臨時(shí)目錄設(shè)置為/opt/module/hadoop-2.10.2/tmp修改hdfs-site.xml設(shè)置副本系數(shù)為1偽分布式只有一臺(tái)節(jié)點(diǎn)副本數(shù)大于1沒有意義NameNode的HTTP訪問端口改為98702.x版本是50070修改mapred-site.xml指定MapReduce框架為yarn修改yarn-site.xml配置ResourceManager和NodeManager的運(yùn)行模式修改hadoop-env.sh顯式指定JAVA_HOME路徑這里有個(gè)細(xì)節(jié)很多教程會(huì)建議改完配置直接執(zhí)行hdfs namenode -format。這里有個(gè)大坑我后面單獨(dú)講格式化前一定要確認(rèn)配置文件的路徑都正確不要有拼寫錯(cuò)誤否則格式化出來的集群狀態(tài)就是錯(cuò)的后面啟動(dòng)會(huì)非常痛苦。3.3 格式化啟動(dòng)失敗的坑熱詞里有一條“hadoop啟動(dòng)格式化失敗”這幾乎是我見過所有新手都會(huì)踩的坑。格式化NameNode時(shí)會(huì)檢查data目錄和name目錄如果這兩個(gè)目錄已經(jīng)存在并且里面已經(jīng)有數(shù)據(jù)了格式化就會(huì)報(bào)錯(cuò)。但最經(jīng)典的問題還不是這個(gè)。我遇到過的情況是第一次格式化成功集群跑了一會(huì)兒我重啟了一下系統(tǒng)發(fā)現(xiàn)DataNode啟動(dòng)不了了。查看日志發(fā)現(xiàn)ClusterID不匹配——NameNode格式化后重新生成了ClusterIDDataNode里存的還是舊ClusterID兩邊對不上就拒絕注冊。解決辦法是確保格式化時(shí)data和name目錄是空的把tmp目錄下的全部文件刪掉然后重新格式化。如果已經(jīng)出現(xiàn)ClusterID不一致連接上服務(wù)器檢查NameNode和DataNode各自的current目錄下的VERSION文件手動(dòng)把ClusterID改成一致的再重啟服務(wù)。這個(gè)細(xì)節(jié)在論文的“系統(tǒng)調(diào)試”章節(jié)里非常加分說明你是真的把Hadoop跑明白了不是照著教程抄的。Zookeeper的整合也是熱詞里的高頻內(nèi)容。集群模式下NameNode的高可用需要Zookeeper來選主兩個(gè)NameNode節(jié)點(diǎn)通過Zookeeper協(xié)調(diào)當(dāng)Active節(jié)點(diǎn)宕機(jī)時(shí)自動(dòng)切換。實(shí)測下來配置Zookeeper的難點(diǎn)有兩個(gè)myid文件必須和zoo.cfg里的server編號(hào)對應(yīng)服務(wù)器數(shù)量必須是奇數(shù)個(gè)。我曾經(jīng)在3臺(tái)機(jī)器上配錯(cuò)過myid導(dǎo)致Follower一直找不到Leader日志刷了一屏錯(cuò)誤最后發(fā)現(xiàn)就是myid寫反了。3.4 Hive與Sqoop的配合用法Hadoop本身用MapReduce寫統(tǒng)計(jì)邏輯很繁瑣我強(qiáng)烈建議引入Hive作為數(shù)據(jù)倉庫工具。把清洗好的JSON數(shù)據(jù)load到Hive表里用類SQL語句做統(tǒng)計(jì)分析比如統(tǒng)計(jì)游戲類型的數(shù)量分布、不同評(píng)分區(qū)間的游戲占比、價(jià)格區(qū)間與好評(píng)率的關(guān)系、各發(fā)行商的平均評(píng)分。這些統(tǒng)計(jì)結(jié)果寫出來就是網(wǎng)站上“熱門游戲榜”“高分游戲榜”“游戲類型分布”等可視化報(bào)表的數(shù)據(jù)來源。Sqoop的作用是把Hive分析完的結(jié)果表導(dǎo)出到MySQL方便網(wǎng)站后端直接查詢。這里有個(gè)順序問題一定是Hive分析完導(dǎo)出到MySQL而不是網(wǎng)站直接連Hive查。因?yàn)镠ive查詢的延遲很高動(dòng)輒幾十秒網(wǎng)站頁面等不起把結(jié)果同步到MySQL之后接口響應(yīng)時(shí)間可以壓到100毫秒以內(nèi)。4. 游戲購買網(wǎng)站與數(shù)據(jù)應(yīng)用層實(shí)現(xiàn)4.1 網(wǎng)站功能設(shè)計(jì)網(wǎng)站采用Spring Boot框架前端用Thymeleaf模板引擎加Bootstrap圖表用ECharts。頁面核心功能包括游戲列表頁分頁展示游戲支持按類型篩選、按評(píng)分和價(jià)格排序游戲詳情頁展示游戲封面、簡介、價(jià)格、評(píng)分模擬加入購物車和購買用戶系統(tǒng)注冊、登錄、收藏游戲數(shù)據(jù)可視化頁面展示Hadoop分析的統(tǒng)計(jì)結(jié)果用圖表呈現(xiàn)后臺(tái)管理管理員維護(hù)游戲信息觸發(fā)增量爬蟲任務(wù)從開題報(bào)告的角度看網(wǎng)站不是重點(diǎn)但它是數(shù)據(jù)的出口。沒有這個(gè)模塊前面的爬蟲和Hadoop就沒有落地場景。有很多同學(xué)把精力全放在爬蟲和Hadoop上網(wǎng)站頁面粗糙得不行答辯時(shí)老師問一句“這個(gè)項(xiàng)目最終能做什么”場面會(huì)非常尷尬。4.2 報(bào)表數(shù)據(jù)如何與Hadoop打通網(wǎng)站的報(bào)表數(shù)據(jù)來自MySQL中的分析結(jié)果表這些表是Sqoop從Hive導(dǎo)出過來的。我設(shè)計(jì)了三個(gè)核心報(bào)表指標(biāo)游戲熱門排行榜依據(jù)評(píng)論數(shù)量和評(píng)分加權(quán)計(jì)算熱度值從Hive層算出結(jié)果后導(dǎo)出價(jià)格分布圖將游戲價(jià)格劃分為免費(fèi)、0到50元、50到100元、100到300元、300元以上幾個(gè)區(qū)間統(tǒng)計(jì)各區(qū)間游戲數(shù)量和平均評(píng)分游戲類型分布對游戲類型標(biāo)簽做explode展開統(tǒng)計(jì)展示比例關(guān)系這幾個(gè)指標(biāo)看似簡單但在論文里可以支撐起“數(shù)據(jù)分析”“系統(tǒng)測試”等章節(jié)。更重要的是它們形成了一個(gè)完整的業(yè)務(wù)閉環(huán)——爬蟲采集原始數(shù)據(jù)Hadoop計(jì)算業(yè)務(wù)指標(biāo)網(wǎng)站展示分析結(jié)果。4.3 緩存優(yōu)化與性能調(diào)優(yōu)思路網(wǎng)站聯(lián)調(diào)過程中Hadoop集群處理數(shù)據(jù)和網(wǎng)站實(shí)時(shí)讀取MySQL是有性能差異的不能指望用戶每次點(diǎn)擊都去觸發(fā)一次大規(guī)模計(jì)算。我的做法是數(shù)據(jù)可視化接口走Redis緩存緩存時(shí)間設(shè)置為6小時(shí)避免每次都查數(shù)據(jù)庫列表頁接口分頁查詢限制單次返回最大50條游戲詳情頁的靜態(tài)資源使用CDN加速爬蟲增量更新時(shí)只更新距今最近的數(shù)據(jù)不做全量重算性能壓測時(shí)我用JMeter模擬了100個(gè)并發(fā)用戶訪問列表頁和詳情頁接口的平均響應(yīng)時(shí)間在300毫秒左右頁面加載在兩秒以內(nèi)對于課程設(shè)計(jì)的場景來說完全夠用了。5. 常見問題與排查技巧實(shí)錄5.1 Hadoop啟動(dòng)報(bào)錯(cuò)速查表這部分是熱詞里大家最關(guān)心的地方直接整理成表格方便按圖索驥報(bào)錯(cuò)現(xiàn)象根本原因解決辦法NameNode啟動(dòng)失敗日志提示拒絕連接tmp目錄不存在或權(quán)限不足創(chuàng)建目錄并賦予hadoop用戶權(quán)限檢查core-site.xml路徑DataNode無法啟動(dòng)提示ClusterID不匹配NameNode和DataNode的VERSION文件不一致刪除tmp目錄重新格式化或手動(dòng)對齊VERSION中的ClusterID啟動(dòng)Yarn后ResourceManager頻繁重啟內(nèi)存配置不匹配Java堆空間設(shè)置過大調(diào)低yarn-site.xml中的虛擬內(nèi)存比例和堆內(nèi)存值SSH免密登錄不生效公鑰沒有追加到authorized_keys權(quán)限不正確重新追加公鑰確保.ssh目錄權(quán)限是700authorized_keys是600Hive執(zhí)行SQL卡死或OOM數(shù)據(jù)傾斜或者Reduce數(shù)量過少增加Reduce個(gè)數(shù)拆分大表設(shè)置hive.auto.convert.join為true502錯(cuò)誤NodeManager連不上ResourceManager主機(jī)名解析不一致多個(gè)網(wǎng)卡IP混亂統(tǒng)一節(jié)點(diǎn)hostname和/etc/hosts配置關(guān)閉防火墻5.2 爬蟲與網(wǎng)站聯(lián)調(diào)中的典型問題爬蟲生成的JSON文件到達(dá)了一定規(guī)模后上傳到HDFS再load進(jìn)Hive時(shí)經(jīng)常遇到字段類型不匹配的問題。比如評(píng)分字段偶爾會(huì)出現(xiàn)“暫無評(píng)價(jià)”這樣的字符串直接把整個(gè)字段類型搞亂了。這個(gè)問題讓我意識(shí)到清洗環(huán)節(jié)不僅要提取還要做類型強(qiáng)轉(zhuǎn)和非法值兜底原文里不是數(shù)字的統(tǒng)統(tǒng)置為NULLHive表定義時(shí)用using字段來兜底處理。網(wǎng)站和MySQL之間也容易出問題。Sqoop導(dǎo)出時(shí)默認(rèn)按照主鍵分發(fā)到MapReduce任務(wù)中結(jié)果表的字段順序如果和Hive的不一致導(dǎo)出后數(shù)據(jù)會(huì)錯(cuò)位。我在實(shí)際中踩過這個(gè)坑后來統(tǒng)一約定Hive表創(chuàng)建時(shí)字段順序就是導(dǎo)出表順序任何變更先改Hive表再改MySQL。5.3 Hadoop面試高頻點(diǎn)在這個(gè)項(xiàng)目里的體現(xiàn)熱詞里有一條“hadoop面試題”很多人做完這個(gè)項(xiàng)目只當(dāng)作業(yè)交差太可惜了這其實(shí)是準(zhǔn)備大數(shù)據(jù)崗位面試的一部分。項(xiàng)目里的幾個(gè)細(xì)節(jié)直接能對應(yīng)上常見面試題“HDFS的讀寫流程是怎樣的”你格式化過NameNode、上傳過文件再結(jié)合請示回答時(shí)可以把實(shí)際執(zhí)行時(shí)的報(bào)錯(cuò)補(bǔ)充進(jìn)去“MapReduce的shuffle過程”你跑過Hive任務(wù)把reduce階段數(shù)據(jù)溢寫排序的過程拆開講就是完整的答案“數(shù)據(jù)傾斜怎么優(yōu)化”我上面提到的Hive SQL卡死問題你跟面試官說“我在項(xiàng)目里遇到過游戲類型字段分布不均導(dǎo)致某些reduce處理的數(shù)據(jù)量巨大最后通過加隨機(jī)鹽和拆分鍵解決”比背書上的概念要有說服力得多5.4 一些我踩了幾次才想明白的經(jīng)驗(yàn)用管理員身份做完一套流程后我最想提醒幾點(diǎn)。第一虛擬機(jī)不要用低配至少分配8G內(nèi)存否則JVM的內(nèi)存配置怎么調(diào)都跑不動(dòng)。第二Hadoop的目錄結(jié)構(gòu)不要隨便移動(dòng)我用mv命令移動(dòng)過一次tmp目錄結(jié)果整個(gè)集群狀態(tài)全亂了最后只能刪掉重新格式化。第三代碼全部提交到Git倉庫每個(gè)階段能夠回退否則改壞了配置只能重來最怕的是改到一半忘了之前能跑通的版本是什么。實(shí)驗(yàn)數(shù)據(jù)一定要留好。我在項(xiàng)目過程中把爬蟲的采集日志、Hive的分析SQL、網(wǎng)站前后端代碼都整理歸檔論文寫實(shí)現(xiàn)部分時(shí)素材直接取材于實(shí)際過程完全沒有編造的痕跡。這也讓答辯時(shí)面對細(xì)節(jié)提問有了充足的底氣。6. 補(bǔ)充方案的擴(kuò)展方向6.1 引入云平臺(tái)與自動(dòng)化如果目標(biāo)是把系統(tǒng)做成能夠長期穩(wěn)定運(yùn)行的項(xiàng)目可以在此基礎(chǔ)上引入容器化和自動(dòng)化部署。Hadoop的Docker鏡像在開發(fā)調(diào)試時(shí)非常方便一條命令就能拉起一個(gè)測試集群配合腳本能自動(dòng)完成集群的銷毀和重建。Ambari部署也值得了解它是管理Hadoop集群的可視化工具可以簡化配置和監(jiān)控流程。不過這些都屬于加分項(xiàng)不建議作為工作量主體核心仍是爬蟲、存儲(chǔ)分析、網(wǎng)站三者的集成閉環(huán)。6.2 從報(bào)表升級(jí)為推薦系統(tǒng)當(dāng)前網(wǎng)站的數(shù)據(jù)可視化還停留在展示統(tǒng)計(jì)圖表的層面如果把Hadoop計(jì)算出的用戶行為數(shù)據(jù)用于個(gè)性化推薦項(xiàng)目就能再上一個(gè)臺(tái)階。例如按用戶收藏和購買行為用協(xié)同過濾算法生成推薦列表再交給網(wǎng)站動(dòng)態(tài)展示。這個(gè)是很好的擴(kuò)展方向而且能和Hadoop中的計(jì)算能力銜接起來。6.3 論文寫作時(shí)的架構(gòu)取舍寫論文或開題報(bào)告時(shí)建議把重點(diǎn)放在“數(shù)據(jù)全鏈路設(shè)計(jì)”上不要各個(gè)技術(shù)點(diǎn)平均用墨。爬蟲部分強(qiáng)調(diào)采集策略和清洗規(guī)則Hadoop部分強(qiáng)調(diào)存儲(chǔ)模型和分析模型的選型依據(jù)網(wǎng)站部分強(qiáng)調(diào)數(shù)據(jù)可視化和業(yè)務(wù)功能的對應(yīng)關(guān)系。開題報(bào)告中最容易得分的是需求分析和可行性分析——你要能說清楚這套系統(tǒng)解決了什么問題而不是只是把課程里學(xué)過的框架拼在一起。如果時(shí)間允許可以在論文最后附上一份完整的部署手冊包括環(huán)境版本、配置示例、啟動(dòng)步驟和常見問題的解決方案這也是體現(xiàn)工程能力一個(gè)重要方式。我當(dāng)時(shí)特地補(bǔ)了這份文檔答辯時(shí)老師瀏覽了一遍直接說“這東西拉出去能用”這種評(píng)價(jià)在答辯現(xiàn)場非常受用。我自己做完這個(gè)項(xiàng)目后最大的體會(huì)是不要被題目里的“大數(shù)據(jù)”唬住再大的數(shù)據(jù)也是從一條一條采集開始的。把每個(gè)環(huán)節(jié)都吃透爬蟲能穩(wěn)定跑Hadoop能穩(wěn)定算網(wǎng)站能穩(wěn)定展示整個(gè)項(xiàng)目才算是真正閉環(huán)了。這套流程做完你對大數(shù)據(jù)的理解就不再停留在概念上而是有了完整的體系認(rèn)知。