1. 項(xiàng)目整體思路為什么是HadoopSparkHive的組合先說(shuō)結(jié)論這套題目拿高分的關(guān)鍵不是把某個(gè)算法調(diào)到極致而是把從數(shù)據(jù)采集、存儲(chǔ)、數(shù)倉(cāng)到預(yù)測(cè)、展示的整條鏈路跑通。Hadoop負(fù)責(zé)分布式存儲(chǔ)和資源調(diào)度Spark負(fù)責(zé)大規(guī)模數(shù)據(jù)預(yù)處理和模型訓(xùn)練Hive負(fù)責(zé)把結(jié)構(gòu)化數(shù)據(jù)管理成一張張可查詢(xún)的表三者合在一起正好構(gòu)成一個(gè)完整的大數(shù)據(jù)離線處理閉環(huán)。業(yè)務(wù)背景也很好理解地鐵、公交、道路卡口每天都在產(chǎn)生海量客流記錄如果能把未來(lái)一小時(shí)某個(gè)站點(diǎn)的進(jìn)出站人數(shù)提前算出來(lái)運(yùn)管方就能提前安排列車(chē)班次、增加安檢通道這就是“智慧交通”的典型應(yīng)用。適合的人群非常明確計(jì)算機(jī)、大數(shù)據(jù)、軟件工程專(zhuān)業(yè)的本科或研究生想做一份技術(shù)覆蓋廣、答辯有內(nèi)容的畢設(shè)又不想陷入純算法或純前端兩難的這套題是最穩(wěn)妥的選項(xiàng)。很多學(xué)生選畢設(shè)題目時(shí)下意識(shí)會(huì)偏向“用Python寫(xiě)個(gè)LSTM預(yù)測(cè)客流”。但冷靜想想本科階段畢設(shè)的重點(diǎn)不是把一個(gè)模型做到99.9%準(zhǔn)確率而是證明你有能力獨(dú)立完成一個(gè)從數(shù)據(jù)到結(jié)果的工程系統(tǒng)。一個(gè)純粹的算法腳本哪怕效果再好在答辯時(shí)也難以撐起“大數(shù)據(jù)”這三個(gè)字反過(guò)來(lái)說(shuō)只做一個(gè)Hadoop環(huán)境搭建演示沒(méi)有業(yè)務(wù)結(jié)果又像在交系統(tǒng)管理課的作業(yè)。而HadoopSparkHive這套組合天然包含數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)倉(cāng)庫(kù)、分布式計(jì)算、機(jī)器學(xué)習(xí)、可視化多個(gè)模塊任何一個(gè)環(huán)節(jié)都能拿來(lái)做實(shí)驗(yàn)、出截圖、寫(xiě)論文。智慧交通客流量預(yù)測(cè)這個(gè)場(chǎng)景也很討巧。它不像推薦系統(tǒng)那樣需要大量用戶(hù)行為日志也不像圖像識(shí)別那樣需要GPU環(huán)境數(shù)據(jù)規(guī)律比較明顯早高峰、晚高峰明顯周周期性和節(jié)假日效應(yīng)突出站點(diǎn)之間有交互關(guān)系。這種數(shù)據(jù)特征非常適合在畢設(shè)里做可視化分析也方便講清楚預(yù)測(cè)結(jié)果為什么可信。比如早上8點(diǎn)的地鐵換乘站客流必然高于凌晨3點(diǎn)遇到節(jié)假日商業(yè)區(qū)的峰值會(huì)明顯后移。把這些規(guī)律通過(guò)Hive統(tǒng)計(jì)出來(lái)再用Spark做特征建模整個(gè)系統(tǒng)就有了“業(yè)務(wù)感”。整個(gè)系統(tǒng)的架構(gòu)可以分成四層存儲(chǔ)層用HDFS保存原始客流文件和清洗后的中間結(jié)果數(shù)倉(cāng)層用Hive管理結(jié)構(gòu)化表按日期做分區(qū)計(jì)算層用Spark SQL和Spark MLlib完成數(shù)據(jù)采樣、特征提取、模型訓(xùn)練與預(yù)測(cè)應(yīng)用層用SpringBoot提供接口前端用ECharts把預(yù)測(cè)結(jié)果變成折線圖和大屏。模塊之間不是分散的而是前后咬合的數(shù)據(jù)流水線。下面這張表是我后續(xù)講解時(shí)會(huì)反復(fù)用到的定位關(guān)系。模塊技術(shù)選型承擔(dān)的職責(zé)數(shù)據(jù)接入Python腳本、HDFS客戶(hù)端生成模擬客流數(shù)據(jù)并上傳數(shù)據(jù)倉(cāng)庫(kù)Hive MySQL元數(shù)據(jù)庫(kù)建表、分區(qū)、統(tǒng)計(jì)查詢(xún)數(shù)據(jù)處理Spark SQL、DataFrame清洗、去重、特征拼接機(jī)器學(xué)習(xí)Spark MLlib回歸模型訓(xùn)練與預(yù)測(cè)結(jié)果存儲(chǔ)MySQL保存預(yù)測(cè)結(jié)果供后端查詢(xún)可視化SpringBoot、ECharts展示真實(shí)與預(yù)測(cè)客流對(duì)比2. 環(huán)境搭建從零起步的大數(shù)據(jù)基礎(chǔ)平臺(tái)2.1 虛擬機(jī)、集群規(guī)劃與Hadoop部署策略環(huán)境搭建是畢設(shè)的第一道坎也是很多同學(xué)最先放棄的地方。我的建議是不要一上來(lái)就追求三臺(tái)物理服務(wù)器先用VMware或VirtualBox在本地虛擬出三臺(tái)CentOS 7虛擬機(jī)。內(nèi)存規(guī)劃比較關(guān)鍵如果筆記本是16G建議給三個(gè)節(jié)點(diǎn)分配4G、2G、2Gmaster節(jié)點(diǎn)跑NameNode和ResourceManager兩個(gè)worker節(jié)點(diǎn)跑DataNode和NodeManager。如果只有8G內(nèi)存就老實(shí)做單節(jié)點(diǎn)偽分布式Hadoop、Hive、Spark都裝在一臺(tái)機(jī)器上雖然規(guī)模小但該有的組件一個(gè)不少。唯一要注意的是Spar依賴(lài)內(nèi)存做計(jì)算單機(jī)偽分布式跑小體量數(shù)據(jù)例如幾萬(wàn)條記錄完全夠用但不要強(qiáng)行把數(shù)據(jù)量放大到百萬(wàn)級(jí)。集群規(guī)劃好了之后先做基礎(chǔ)配置關(guān)閉防火墻、配置hosts、設(shè)置SSH免密登錄、安裝JDK1.8并配置JAVA_HOME。Hadoop本身是Java寫(xiě)的JDK版本不匹配會(huì)冒出一堆莫名其妙的異常。接下來(lái)下載Hadoop 3.x的tar包解壓到指定目錄然后修改core-site.xml、hdfs-site.xml、yarn-site.xml。三份配置的核心含義分別是告訴Hadoop集群的NameNode在哪個(gè)節(jié)點(diǎn)、數(shù)據(jù)塊副本數(shù)設(shè)置多少、資源調(diào)度由哪個(gè)ResourceManager負(fù)責(zé)。不少教程會(huì)要求格式化NameNode很多人在這一步踩坑其實(shí)就是執(zhí)行hdfs namenode -format然后把dfs.namenode.name.dir指向的目錄清干凈再格式別嫌麻煩。有些同學(xué)想在這個(gè)畢設(shè)里體現(xiàn)HA高可用于是開(kāi)始折騰“Hadoop和Zookeeper整合實(shí)戰(zhàn)”。我的意見(jiàn)是如果時(shí)間充足可以做但不要讓它成為阻塞項(xiàng)。HA需要額外搭建ZooKeeper集群配置core-site.xml里的ha.zookeeper.quorum再把NameNode做成Active/Standby兩個(gè)節(jié)點(diǎn)。一旦ZooKeeper沒(méi)啟動(dòng)或者和NameNode心跳斷了整個(gè)集群長(zhǎng)期處于“兩個(gè)節(jié)點(diǎn)互相搶主”的故障狀態(tài)反而影響后面所有流程。如果不能確保在三天內(nèi)能穩(wěn)定跑通寧可先把數(shù)據(jù)流程做完HA作為論文里的“后期優(yōu)化方向”提一句。2.2 Hadoop安裝與啟動(dòng)的實(shí)操要點(diǎn)不少人在安裝Hadoop時(shí)卡在環(huán)境變量上。網(wǎng)上很多教程直接說(shuō)“配置hadoop_home環(huán)境變量”卻不說(shuō)清楚要配置哪些。實(shí)際至少需要四個(gè)HADOOP_HOME、HADOOP_CONF_DIR、YARN_CONF_DIR、PATH里加上hadoop的bin和sbin目錄。同時(shí)如果Windows下開(kāi)發(fā)還要本地放一份能用的Hadoop已編譯jar包否則后面用IDEA提交作業(yè)時(shí)會(huì)報(bào)缺少WinUtils異常。在Linux虛擬機(jī)上直接跑不需要這個(gè)但如果你打算在Windows上寫(xiě)Spark代碼再提交集群最好提前把hadoop.dll和winutils.exe放到系統(tǒng)目錄。啟動(dòng)順序也固定先執(zhí)行start-dfs.sh再執(zhí)行start-yarn.sh然后jps檢查進(jìn)程。jps輸出里必須能看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager這幾項(xiàng)。看到后不要急著用了先訪問(wèn)NameNode Web頁(yè)面確認(rèn)Live Nodes數(shù)量對(duì)得上。很多情況是HDFS文件系統(tǒng)損壞Node進(jìn)程雖然啟動(dòng)但頁(yè)面顯示0節(jié)點(diǎn)這時(shí)候要去hdfs-site.xml里檢查dfs.namenode.name.dir和dfs.datanode.data.dir的路徑是否存在、是否有權(quán)限。Hadoop默認(rèn)會(huì)把數(shù)據(jù)寫(xiě)到/tmp下操作系統(tǒng)一重啟就全沒(méi)了這種“隱藏坑”幾乎每個(gè)做畢設(shè)的人都會(huì)撞上最好的習(xí)慣是在配置里就把目錄改成固定的、非臨時(shí)目錄。啟動(dòng)完成后可以順手做兩件事一是用hdfs dfs -mkdir -p /warehouse創(chuàng)建后續(xù)要用的HDFS目錄二是用hdfs dfs -put上傳一小份測(cè)試文件驗(yàn)證寫(xiě)入讀取鏈路。HDFS是后面所有模塊的數(shù)據(jù)底座這一層不穩(wěn)Hive表建不出來(lái)Spark也讀不到數(shù)據(jù)。這里也順帶提一下hadoop distcp的用途畢設(shè)中期需要把HDFS里的數(shù)據(jù)備份到另一個(gè)目錄或者將某兩天分區(qū)數(shù)據(jù)拷貝出來(lái)單獨(dú)實(shí)驗(yàn)distcp就是最可靠的工具。常用的參數(shù)有-update增量覆蓋、-skipcrccheck跳過(guò)校驗(yàn)、-m設(shè)置并行度寫(xiě)成命令就是hadoop distcp -update -skipcrccheck /warehouse/traffic_flow /backup/traffic_flow比直接在Linux層cp靠譜多了。2.3 Hive 3.1.3安裝與MySQL元數(shù)據(jù)庫(kù)Hive在畢設(shè)里的定位是“數(shù)據(jù)倉(cāng)庫(kù)工具箱”。它不存儲(chǔ)數(shù)據(jù)數(shù)據(jù)還在HDFS上它只用一張“元數(shù)據(jù)表”來(lái)記錄哪個(gè)目錄對(duì)應(yīng)哪張表、有哪些分區(qū)、列名是什么。既然涉及元數(shù)據(jù)就存在兩種選擇Hive內(nèi)置的Derby或者外置MySQL。做畢設(shè)強(qiáng)烈建議用外置MySQL因?yàn)镈erby不支持多客戶(hù)端并發(fā)而且它的元數(shù)據(jù)庫(kù)是綁定當(dāng)前目錄的你換一個(gè)目錄啟動(dòng)hive會(huì)發(fā)現(xiàn)之前建的表全都不見(jiàn)了。這不是你操作錯(cuò)了是Derby的天然限制。Hive 3.1.3下載解壓后把mysql-connector-java的jar包丟到hive的lib目錄。這里有個(gè)非常典型的版本坑MySQL 5.x驅(qū)動(dòng)類(lèi)是com.mysql.jdbc.DriverMySQL 8.x驅(qū)動(dòng)類(lèi)是com.mysql.cj.jdbc.Driver如果你用MySQL 8卻配了舊驅(qū)動(dòng)Hive初始化時(shí)就會(huì)說(shuō)找不到Driver類(lèi)。配置好jdbc:mysql://localhost:3306/hive?useSSLfalseserverTimezoneAsia/Shanghai之后執(zhí)行schematool -initSchema -dbType mysql看到schemaTool completed就說(shuō)明元數(shù)據(jù)庫(kù)初始化成功了。然后執(zhí)行hive命令建一張測(cè)試表確認(rèn)能在MySQL的hive數(shù)據(jù)庫(kù)里看到對(duì)應(yīng)的元數(shù)據(jù)記錄。Hive建表時(shí)建議直接養(yǎng)成外部表的習(xí)慣。外部表和內(nèi)部表的區(qū)別在于內(nèi)部表刪除時(shí)連同HDFS數(shù)據(jù)一起刪外部表只刪表結(jié)構(gòu)數(shù)據(jù)文件仍然保留。畢設(shè)流程會(huì)反復(fù)重跑數(shù)據(jù)清洗用外部表能在出錯(cuò)時(shí)保護(hù)原始數(shù)據(jù)這個(gè)習(xí)慣在工業(yè)界也很重要。我通常會(huì)在建表語(yǔ)句里加上PARTITIONED BY (record_date string)和STORED AS ORC因?yàn)榘慈掌诜謪^(qū)可以避免查詢(xún)?nèi)鞳RC列式存儲(chǔ)則能大幅壓縮體積、提升掃描效率。后面Spark讀取時(shí)也會(huì)明顯感覺(jué)到性能差別。2.4 Spark集群搭建與內(nèi)存規(guī)劃Spark本身自帶Standalone模式但我更推薦讓Spark跑在YARN上。原因很簡(jiǎn)單Hadoop集群已經(jīng)裝了YARN如果Spark再單獨(dú)起一套Master和Worker等于同一批機(jī)器被兩套資源調(diào)度器管著容易出現(xiàn)Spark占滿(mǎn)了內(nèi)存HDFS的DataNode反而被擠掉的情況。配置“Spark ON YARN”時(shí)只需要下載spark-3.x-bin-hadoop3的包在spark-env.sh里設(shè)置JAVA_HOME、HADOOP_CONF_DIR然后提交任務(wù)時(shí)指定--master yarn即可。這樣YARN會(huì)把Spark任務(wù)當(dāng)成一個(gè)Application來(lái)分配資源。內(nèi)存規(guī)劃是Spark跑批最容易忽略但影響最大的一環(huán)。很多同學(xué)默認(rèn)配置跑Spark結(jié)果作業(yè)一提交就OOM排查了半天發(fā)現(xiàn)是executor memory太小或者spark.sql.shuffle.partitions太大。我的建議是機(jī)器內(nèi)存只有4G時(shí)executor-memory設(shè)為2gexecutor-cores設(shè)1driver-memory設(shè)1g數(shù)據(jù)量只有幾萬(wàn)條時(shí)把spark.sql.shuffle.partitions從默認(rèn)的200改成20或10。因?yàn)槟J(rèn)200是給海量數(shù)據(jù)準(zhǔn)備的小數(shù)據(jù)強(qiáng)行分成200個(gè)task每個(gè)task只處理幾十條記錄調(diào)度開(kāi)銷(xiāo)甚至比計(jì)算本身還大跑起來(lái)反而更慢。安裝后先用最簡(jiǎn)單的spark-submit --master yarn運(yùn)行一個(gè)sparkPi或讀取JSON文件的demo驗(yàn)證連通性再進(jìn)入正式的數(shù)據(jù)處理。這一步如果跑不通過(guò)后面所有代碼都不用寫(xiě)先把環(huán)境搞對(duì)。3. 數(shù)據(jù)設(shè)計(jì)與ETL實(shí)現(xiàn)3.1 怎么模擬一份像樣的客流量數(shù)據(jù)真實(shí)客流數(shù)據(jù)一般拿不到所以畢設(shè)里最合理的方式是寫(xiě)Python腳本生成模擬數(shù)據(jù)。模擬不是瞎編字段和規(guī)律要貼近真實(shí)場(chǎng)景。以地鐵客流為例一條記錄應(yīng)該包含站點(diǎn)編號(hào)、線路編號(hào)、日期、小時(shí)、進(jìn)站量、出站量、天氣類(lèi)型、溫度、是否節(jié)假日。時(shí)間范圍建議生成6個(gè)月到1年空間上覆蓋5到10個(gè)站點(diǎn)每個(gè)站點(diǎn)每天24個(gè)小時(shí)都有記錄。這樣數(shù)據(jù)量在20萬(wàn)到50萬(wàn)條左右不大不小既能體現(xiàn)Hadoop和Spark的價(jià)值又不會(huì)讓單機(jī)偽分布式跑崩潰。生成數(shù)據(jù)時(shí)要刻意加入周期性規(guī)律。比如工作日上午7點(diǎn)到9點(diǎn)進(jìn)站量大下午17點(diǎn)到19點(diǎn)出站量大周末客流峰值出現(xiàn)在10點(diǎn)到20點(diǎn)且相對(duì)平緩節(jié)假日期間商業(yè)中心站點(diǎn)的客流量明顯上升。還可以加入少量噪聲和異常值比如某天設(shè)備故障導(dǎo)致某小時(shí)流量為0或者個(gè)別記錄出現(xiàn)負(fù)值。這些異常在后續(xù)數(shù)據(jù)清洗階段能被合法地“發(fā)現(xiàn)”和處理論文的實(shí)驗(yàn)部分就有素材可寫(xiě)。數(shù)據(jù)生成完統(tǒng)一保存成CSV或JSON格式。如果接口端模擬可以生成JSONSpark讀取JSON文件用spark.read.json一條命令就能搞定省去手工解析的麻煩。3.2 Hive表設(shè)計(jì)外部表、分區(qū)、ORC存儲(chǔ)數(shù)據(jù)文件上傳到HDFS之后接下來(lái)在Hive中建立一張可查詢(xún)的表。推薦的建表語(yǔ)句是CREATE EXTERNAL TABLE traffic_flow ( record_id string, station_id string, line_id string, hour int, flow_in int, flow_out int, weather string, temp double, is_holiday int ) PARTITIONED BY (record_date string) STORED AS ORC LOCATION /warehouse/traffic_flow;這張表建好之后立刻執(zhí)行MSCK REPAIR TABLE traffic_flow;或者手動(dòng)ALTER TABLE traffic_flow ADD PARTITION (record_date2024-06-01);。因?yàn)橥獠勘淼姆謪^(qū)信息不會(huì)自動(dòng)同步到Hive元數(shù)據(jù)只有修復(fù)或手動(dòng)添加之后Hive才能查到數(shù)據(jù)。很多同學(xué)在這里栽跟頭明明文件上傳了建表語(yǔ)句也沒(méi)報(bào)錯(cuò)但SELECT出來(lái)卻是0行就是漏了這一步。ORC格式和TEXT格式的差別在實(shí)際查詢(xún)中非常明顯。TEXT文件每條記錄都要全列掃描ORC格式會(huì)按列進(jìn)行壓縮和剪枝查半天數(shù)據(jù)時(shí)快好幾倍而且文件體積能縮小到原來(lái)的三分之一。對(duì)于畢設(shè)來(lái)說(shuō)使用ORC格式也是一個(gè)很好的論文細(xì)節(jié)能在技術(shù)創(chuàng)新點(diǎn)上寫(xiě)“采用列式存儲(chǔ)與分區(qū)表優(yōu)化查詢(xún)性能”。3.3 Hive小文件問(wèn)題與窗口函數(shù)實(shí)戰(zhàn)小文件問(wèn)題是Hive使用中繞不過(guò)去的經(jīng)典話題。什么是小文件就是單個(gè)文件大小遠(yuǎn)小于HDFS默認(rèn)塊大小128M的文件。Spark在寫(xiě)數(shù)據(jù)時(shí)經(jīng)常默認(rèn)按照分區(qū)或并行度生成很多碎片文件幾十萬(wàn)條記錄被拆成幾百個(gè)幾百KB的小文件HDFS元數(shù)據(jù)的壓力、查詢(xún)時(shí)的任務(wù)數(shù)都會(huì)暴增。表現(xiàn)為明明數(shù)據(jù)量不大Map任務(wù)卻啟動(dòng)了幾百個(gè)集群直接跑得很慢。解決思路有兩個(gè)層面。寫(xiě)之前控制并行度寫(xiě)完以后可以手動(dòng)合并。例如Spark寫(xiě)Hive表之前執(zhí)行coalesce(5)將輸出文件控制在5個(gè)左右Hive側(cè)也可以設(shè)置hive.merge.mapfilestrue和hive.merge.size.per.task134217728讓Hive在查詢(xún)結(jié)束后自動(dòng)合并小文件。如果已經(jīng)有大量小文件出現(xiàn)最樸素的方式是把數(shù)據(jù)表重新寫(xiě)入一個(gè)中間表再覆蓋回來(lái)相當(dāng)于做一次壓縮。Hive窗口函數(shù)在客流數(shù)據(jù)處理里用途非常大也是很多企業(yè)面試題和“hive給每一行標(biāo)號(hào)”這類(lèi)熱詞背后的真實(shí)需求。比如要算“每個(gè)站點(diǎn)、每天、每個(gè)時(shí)段在過(guò)去7天同一點(diǎn)位的平均流量”用窗口函數(shù)寫(xiě)特別順手SELECT station_id, record_date, hour, flow_in, AVG(flow_in) OVER( PARTITION BY station_id, hour ORDER BY record_date ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING ) AS avg_flow_prev_7d FROM traffic_flow;窗口函數(shù)還可以用來(lái)給每行標(biāo)號(hào)ROW_NUMBER() OVER(PARTITION BY station_id, record_date ORDER BY hour DESC) AS rn做去重或篩選最新記錄都靠它。畢業(yè)生如果能在論文里寫(xiě)明白窗口函數(shù)的用法比堆砌一堆術(shù)語(yǔ)更讓老師信服。3.4 Spark SQL讀取與清洗細(xì)節(jié)Spark讀取Hive表需要把hive-site.xml復(fù)制到Spark的conf目錄并開(kāi)啟SparkSession的enableHiveSupport這樣Spark才能識(shí)別Hive表結(jié)構(gòu)。讀取代碼如下from pyspark.sql import SparkSession spark SparkSession.builder \ .appName(traffic_etl) \ .config(spark.sql.shuffle.partitions, 20) \ .enableHiveSupport() \ .getOrCreate() df spark.sql(SELECT * FROM traffic_flow WHERE record_date 2024-01-01)清洗流程我一般分四步第一步去重同一站點(diǎn)同一小時(shí)出現(xiàn)多條記錄時(shí)按規(guī)則保留一條第二步剔除缺失值比如weather為空的行直接丟棄第三步過(guò)濾異常值例如flow_in小于0或超過(guò)該站歷史最大值十倍的點(diǎn)第四步統(tǒng)一日期格式和站點(diǎn)編碼。清洗之后的DataFrame可以緩存起來(lái)spark.catalog.cacheTable(traffic_clean)后面做特征工程時(shí)反復(fù)讀取就不用再掃描HDFS。這里有一個(gè)很容易犯的錯(cuò)誤直接在原始表上做計(jì)算導(dǎo)致同一份數(shù)據(jù)被讀取幾十次。在數(shù)據(jù)量不大時(shí)看不到問(wèn)題一旦數(shù)據(jù)量擴(kuò)大每個(gè)算子都要重新讀盤(pán)整個(gè)任務(wù)執(zhí)行時(shí)間隨代碼行數(shù)線性膨脹。所以我在每次需要多輪迭代時(shí)都會(huì)緩存中間結(jié)果。4. 核心預(yù)測(cè)模型構(gòu)建4.1 算法選型為什么用Spark MLlib而不是深度學(xué)習(xí)客流預(yù)測(cè)可以用很復(fù)雜的模型但對(duì)于畢業(yè)設(shè)計(jì)Spark MLlib里的隨機(jī)森林回歸和梯度提升樹(shù)回歸是最合適的。首先它們是分布式實(shí)現(xiàn)能體現(xiàn)Spark的優(yōu)勢(shì)其次它們不像LSTM那樣需要長(zhǎng)時(shí)間訓(xùn)練和大量調(diào)參幾萬(wàn)條樣本幾分鐘就能跑完第三回歸結(jié)果可以直接解釋每個(gè)特征的重要性論文里畫(huà)一張?zhí)卣髦匾灾鶢顖D答辯時(shí)非常好講。當(dāng)然也可以在論文中把”深度學(xué)習(xí)LSTM“作為對(duì)比方案提出來(lái)說(shuō)明它的時(shí)序建模能力更強(qiáng)但訓(xùn)練成本高、調(diào)參難度大、不適合當(dāng)前小數(shù)據(jù)規(guī)模。這樣的對(duì)比能體現(xiàn)你思考過(guò)而不是只會(huì)套用某個(gè)模型。如果時(shí)間允許可以用Prophet做一個(gè)簡(jiǎn)單的基線進(jìn)一步佐證Spark模型的有效性。4.2 特征工程時(shí)間特征、滯后特征與節(jié)假日預(yù)測(cè)目標(biāo)一般定義成給定站點(diǎn)、日期、小時(shí)、環(huán)境特征預(yù)測(cè)該時(shí)段進(jìn)站量或出站量。模型輸入不能只有hour這個(gè)字段否則它學(xué)不到“周一早高峰”和“周六下午”的差異。我常用的特征列表如下hour一天中第幾個(gè)小時(shí)屬于周期特征建議轉(zhuǎn)換成sin/cos編碼day_of_week星期幾0到6is_holiday是否節(jié)假日0或1weather天氣類(lèi)型獨(dú)熱編碼或數(shù)值映射temp溫度f(wàn)low_in_same_hour_prev_day前一日同一時(shí)段流量avg_flow_last_7d過(guò)去7天同一時(shí)段平均流量flow_in_prev_hour前一小時(shí)流量其中滯后特征對(duì)客流預(yù)測(cè)的效果提升最明顯。道理很簡(jiǎn)單昨天早8點(diǎn)的客流和今天早8點(diǎn)的客流高度相關(guān)而普通線性模型無(wú)論如何都學(xué)不到這個(gè)規(guī)律。滯后特征可以在Hive里用LAG窗口函數(shù)計(jì)算也可以在Spark里用DataFrame的窗口操作生成。特征不是越多越好但要保證這些特征在預(yù)測(cè)時(shí)是已知的否則就會(huì)引入“未來(lái)數(shù)據(jù)泄露”。時(shí)間序列建模中訓(xùn)練集和測(cè)試集的劃分必須按時(shí)間順序切分而不是隨機(jī)打散。比如前80%的天數(shù)作為訓(xùn)練集最后20%的天數(shù)作為測(cè)試集。隨機(jī)劃分會(huì)讓模型在訓(xùn)練時(shí)碰到來(lái)測(cè)試集里的信息評(píng)估指標(biāo)虛高答辯時(shí)被問(wèn)到如何避免數(shù)據(jù)泄露答不出來(lái)就很尷尬。4.3 模型訓(xùn)練、評(píng)估與參數(shù)調(diào)優(yōu)Spark MLlib的建模流程比較固定用VectorAssembler把所有特征合并成一個(gè)向量放進(jìn)RandomForestRegressor再用RegressionEvaluator計(jì)算指標(biāo)。代碼如下from pyspark.ml.feature import VectorAssembler from pyspark.ml.regression import RandomForestRegressor from pyspark.ml.evaluation import RegressionEvaluator feature_cols [hour, day_of_week, is_holiday, temp, flow_in_prev_hour, avg_flow_last_7d] assembler VectorAssembler(inputColsfeature_cols, outputColfeatures) rf RandomForestRegressor(labelColflow_in, featuresColfeatures, numTrees50, maxDepth10) train_df, test_df df.randomSplit([0.8, 0.2], seed42) # 注意時(shí)間序列應(yīng)改用按時(shí)排序切分評(píng)估指標(biāo)通常用MAE平均絕對(duì)誤差、RMSE均方根誤差和MAPE平均絕對(duì)百分比誤差。MAPE對(duì)量級(jí)小的時(shí)間段很敏感例如夜間客流只有幾十人誤差10人就等于20%所以只看MAPE容易被誤導(dǎo)。我的做法是同時(shí)計(jì)算三個(gè)指標(biāo)重點(diǎn)關(guān)注白天活躍時(shí)段的誤差。一次典型實(shí)驗(yàn)結(jié)果如下模型MAERMSEMAPE線性回歸48266714.2%隨機(jī)森林默認(rèn)參數(shù)3655219.6%隨機(jī)森林調(diào)參后3154688.3%調(diào)參不需要暴力搜索幾十組參數(shù)我通常先固定numTrees在50到100之間再調(diào)maxDepth。maxDepth過(guò)大容易過(guò)擬合訓(xùn)練集效果好、測(cè)試集差很多過(guò)小又學(xué)不到非線性關(guān)系。做畢設(shè)時(shí)可以把多組參數(shù)的結(jié)果記錄下來(lái)整理成表格放在論文里這就是最扎實(shí)的實(shí)驗(yàn)材料。5. 系統(tǒng)可視化與結(jié)果展示5.1 前端展示方案選型預(yù)測(cè)模型訓(xùn)練完成后需要把結(jié)果展示出來(lái)給用戶(hù)或者答辯老師看。我推薦SpringBoot ECharts這個(gè)組合而不是簡(jiǎn)單把Python輸出結(jié)果打成一張圖片。原因有二一是SpringBoot是Java生態(tài)的主流框架寫(xiě)接口、聯(lián)調(diào)、部署都有標(biāo)準(zhǔn)路徑二是ECharts的交互性和展示效果好可以動(dòng)態(tài)切換站點(diǎn)、日期、查看各時(shí)段預(yù)測(cè)值。整個(gè)流程是Spark訓(xùn)練完成后把預(yù)測(cè)結(jié)果寫(xiě)入MySQL后端提供查詢(xún)接口前端調(diào)用接口繪制圖表。為了演示方便數(shù)據(jù)庫(kù)表結(jié)構(gòu)也不用復(fù)雜。一張prediction_result表字段包括station_id、record_date、hour、flow_in_pred、flow_in_real、model_name、update_time。保存時(shí)把預(yù)測(cè)值和真實(shí)值放在同一行前端就能直接畫(huà)對(duì)比折線圖。如果預(yù)測(cè)的時(shí)間段尚未發(fā)生flow_in_real留空折線圖只顯示預(yù)測(cè)部分。這樣的設(shè)計(jì)簡(jiǎn)單、直觀又能看出模型的預(yù)測(cè)效果。5.2 客流量預(yù)測(cè)大屏怎么做“數(shù)據(jù)大屏”是這幾年畢設(shè)中最容易出效果的部分。它本質(zhì)上不是復(fù)雜技術(shù)而是把多個(gè)圖表網(wǎng)格化排版在一個(gè)頁(yè)面上。常見(jiàn)的布局是頂部一行標(biāo)題欄和日期左側(cè)放站點(diǎn)客流排行Top5中間放全天客流趨勢(shì)折線圖右側(cè)放預(yù)測(cè)誤差分布柱狀圖底部放一張當(dāng)天的時(shí)段熱力圖。視覺(jué)上配合深色背景和大號(hào)字體就有一種指揮中心的感覺(jué)。ECharts實(shí)現(xiàn)大屏的細(xì)節(jié)有幾個(gè)一是坐標(biāo)系不要用默認(rèn)白底改成透明或漸變色否則大屏風(fēng)格出不來(lái)二是多個(gè)圖表的聯(lián)動(dòng)比如點(diǎn)擊左側(cè)某個(gè)站點(diǎn)中間折線圖切換為該站點(diǎn)的客流曲線這個(gè)可以通過(guò)綁定click事件實(shí)現(xiàn)難度不高三是數(shù)據(jù)的定時(shí)刷新用setInterval每30秒重新請(qǐng)求一次后端接口就比靜態(tài)頁(yè)面顯得專(zhuān)業(yè)。畢設(shè)答辯時(shí)大屏頁(yè)面一打開(kāi)老師的第一印象就會(huì)好很多。5.3 一個(gè)最小可用的后端接口示例后端Controller的核心邏輯很簡(jiǎn)單通過(guò)站點(diǎn)ID和日期查詢(xún)預(yù)測(cè)結(jié)果返回JSON。示例代碼如下RestController RequestMapping(/api/forecast) public class ForecastController { Autowired private ForecastService forecastService; GetMapping(/curve) public JsonResult curve(String stationId, String date) { ListPredictionModel list forecastService.getByStationAndDate(stationId, date); return JsonResult.success(list); } }前端用axios或fetch請(qǐng)求這個(gè)接口配好跨域處理后把返回?cái)?shù)組塞給ECharts的series即可。這里有一個(gè)常見(jiàn)的坑前端沒(méi)有設(shè)置請(qǐng)求超時(shí)和異常提示數(shù)據(jù)量一大接口響應(yīng)慢頁(yè)面就一直轉(zhuǎn)圈。最簡(jiǎn)單的做法是在后端接口里設(shè)置連接超時(shí)和SQL查詢(xún)超時(shí)并在前端統(tǒng)一捕獲異常把“數(shù)據(jù)加載失敗”顯示出來(lái)?？梢暬潜砻婀ぷ鞯珔s是答辯時(shí)最容易產(chǎn)生印象分的部分值得多花一晚上打磨。6. 畢業(yè)設(shè)計(jì)交付物源碼、論文、PPT和講解視頻6.1 源碼組織結(jié)構(gòu)與運(yùn)行順序標(biāo)題里提到的“源碼論文PPT講解視頻”是畢設(shè)的四個(gè)標(biāo)準(zhǔn)交付物源代碼的組織結(jié)構(gòu)直接決定老師愿不愿意看。常見(jiàn)問(wèn)題是把代碼一股腦丟進(jìn)一個(gè)文件夾連README都沒(méi)有。更好的結(jié)構(gòu)是分目錄放好├── data_gen/ # 數(shù)據(jù)生成Python腳本 ├── hive_sql/ # 建表、查詢(xún)、窗口函數(shù)SQL ├── spark_jobs/ # ETL、特征工程、模型訓(xùn)練代碼 ├── backend/ # SpringBoot后端項(xiàng)目 ├── frontend/ # ECharts可視化頁(yè)面 └── README.md # 環(huán)境版本、啟動(dòng)步驟、坑點(diǎn)記錄README是整個(gè)源碼的說(shuō)明書(shū)必須寫(xiě)清楚JDK版本、Hadoop版本、Spark版本、Hive版本、MySQL版本、每部分代碼的運(yùn)行順序、大概執(zhí)行時(shí)間。不要覺(jué)得這些信息無(wú)用畢業(yè)后重新打開(kāi)這個(gè)項(xiàng)目如果沒(méi)有README你自己都未必能還原環(huán)境。如果按照“生成數(shù)據(jù)→上傳HDFS→Hive建表→Spark訓(xùn)練→寫(xiě)入MySQL→啟動(dòng)后端→打開(kāi)前端”這樣的順序能完整跑通這份源碼就達(dá)到交付標(biāo)準(zhǔn)了。6.2 論文寫(xiě)作思路與創(chuàng)新點(diǎn)論文的標(biāo)準(zhǔn)章節(jié)一般包括摘要、緒論、相關(guān)技術(shù)、系統(tǒng)設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)、實(shí)驗(yàn)與分析、總結(jié)與展望。很多學(xué)生寫(xiě)出來(lái)的論文像軟件說(shuō)明書(shū)大量貼代碼和截圖卻沒(méi)有核心觀點(diǎn)。我建議把主線放在“大數(shù)據(jù)處理鏈路下的客流預(yù)測(cè)系統(tǒng)設(shè)計(jì)”這個(gè)主題上圍繞數(shù)據(jù)如何入湖、如何管理、如何計(jì)算、如何建模來(lái)展開(kāi)。關(guān)于創(chuàng)新點(diǎn)不需要硬編造?？梢詮娜齻€(gè)維度來(lái)提煉一是數(shù)據(jù)管理層面的優(yōu)化比如設(shè)計(jì)了分區(qū)Hive數(shù)倉(cāng)通過(guò)ORC存儲(chǔ)和窗口函數(shù)完成歷史特征計(jì)算二是預(yù)測(cè)模型層面將時(shí)間滯后特征、天氣和節(jié)假日特征統(tǒng)一編碼用Spark MLlib完成分布式訓(xùn)練三是系統(tǒng)集成層面打通從HDFS到數(shù)據(jù)庫(kù)再到Web前端的全鏈路實(shí)現(xiàn)真正可使用的預(yù)測(cè)系統(tǒng)。這些點(diǎn)單獨(dú)看都不算多大創(chuàng)新但組合在一起就是一個(gè)完整的工程創(chuàng)新。摘要寫(xiě)作也有技巧開(kāi)頭直接說(shuō)明“針對(duì)智慧交通中地鐵客流量波動(dòng)大、人工調(diào)度響應(yīng)慢的問(wèn)題設(shè)計(jì)并實(shí)現(xiàn)了基于Hadoop、Spark和Hive的客流量預(yù)測(cè)系統(tǒng)”然后概述整體架構(gòu)最后用一組實(shí)驗(yàn)結(jié)果數(shù)據(jù)收尾。避免套話直接讓讀者看到這篇論文做了什么事、得到什么結(jié)果。6.3 答辯PPT與講解視頻制作心得答辯PPT不要搞成代碼展示老師最關(guān)心的三個(gè)問(wèn)題是系統(tǒng)解決什么問(wèn)題技術(shù)架構(gòu)怎么設(shè)計(jì)實(shí)驗(yàn)結(jié)果是否可靠。建議制作四大部分背景意義、系統(tǒng)架構(gòu)、核心實(shí)現(xiàn)、實(shí)驗(yàn)展示。系統(tǒng)架構(gòu)用一張圖把Hadoop、Hive、Spark和可視化模塊串起來(lái)核心實(shí)現(xiàn)放兩到三個(gè)有代表性的代碼片段即可剩余頁(yè)面全部放截圖和大屏效果。講解視頻以10到15分鐘為最佳。錄制時(shí)先講背景和架構(gòu)再演示數(shù)據(jù)上傳HDFS的命令、Hive查詢(xún)結(jié)果、Spark訓(xùn)練日志、最后打開(kāi)大屏頁(yè)面展示預(yù)測(cè)曲線。注意錄制前把中間過(guò)程的登錄賬號(hào)、命令行工具準(zhǔn)備好不要出現(xiàn)“等一分鐘我先編譯”這種尷尬情況。最好事先寫(xiě)好講稿每頁(yè)P(yáng)PT配一段60到100字的逐字稿錄的時(shí)候照著講能有效減少口頭禪和停頓。7. 常見(jiàn)問(wèn)題排查與避坑實(shí)錄7.1 環(huán)境搭建階段最容易卡住的問(wèn)題現(xiàn)象常見(jiàn)原因解決方案NameNode啟動(dòng)即退出數(shù)據(jù)目錄不存在或已有舊元數(shù)據(jù)重新格式化或清理dfs.name.dir目錄HDFS頁(yè)面打不開(kāi)防火墻未關(guān)閉systemctl stop firewalldHive建表后查不到數(shù)據(jù)外部表分區(qū)未添加執(zhí)行MSCK REPAIR TABLEHive初始化報(bào)Driver錯(cuò)誤數(shù)據(jù)庫(kù)驅(qū)動(dòng)版本不對(duì)更換合適的mysql-connector-javaSpark任務(wù)一直ACCEPTEDYARN資源不足或無(wú)法解析主機(jī)名檢查hosts配置與執(zhí)行內(nèi)存申請(qǐng)環(huán)境問(wèn)題是排查時(shí)間占比最高的。實(shí)際上安裝步驟本身并不復(fù)雜復(fù)雜的是報(bào)錯(cuò)相互影響比如Hive初始化失敗會(huì)導(dǎo)致hive-site.xml里的連接串被誤改之后Spark讀Hive表時(shí)又連鎖報(bào)錯(cuò)。我的經(jīng)驗(yàn)是每完成一個(gè)組件就立即做一個(gè)小驗(yàn)證Hadoop裝完馬上上傳文件Hive裝完馬上建一張表查詢(xún)一次Spark裝完馬上跑一個(gè)demo。把問(wèn)題隔離在最小范圍內(nèi)不要等所有東西都裝完了才做測(cè)試否則根本不知道問(wèn)題出在哪個(gè)組件。7.2 Spark跑批時(shí)的內(nèi)存與并行度問(wèn)題Spark作業(yè)“看上去掛起”或者“突然OOM”是高頻問(wèn)題。出現(xiàn)OOM時(shí)先看日志里是driver還是executordriver OOM通常是結(jié)果集太大或被collect到本地executor OOM通常是shuffle階段數(shù)據(jù)溢出。解決方法不是一味加大內(nèi)存而是先減少無(wú)效數(shù)據(jù)盡量只select需要的列、過(guò)濾條件下推到Hive、能緩存就緩存。數(shù)據(jù)量幾萬(wàn)條時(shí)默認(rèn)的資源設(shè)置就會(huì)顯得過(guò)大所以一定記得把spark.sql.shuffle.partitions設(shè)小。寫(xiě)入Hive階段的小文件問(wèn)題也同樣會(huì)反噬查詢(xún)性能。我建議每次寫(xiě)Hive表之前都執(zhí)行一次coalesce并檢查輸出文件的數(shù)量和大小。如果數(shù)據(jù)量不到10萬(wàn)條輸出文件控制在3到5個(gè)以?xún)?nèi)。文件越少后續(xù)讀取啟動(dòng)的task越少整個(gè)流水線的時(shí)間就越穩(wěn)定。7.3 數(shù)據(jù)與模型層容易被忽略的坑日期類(lèi)型是最容易踩坑的地方。Hive分區(qū)字段如果是string格式必須統(tǒng)一Spark和Hive之間傳遞時(shí)不能一會(huì)兒寫(xiě)2024-06-01一會(huì)兒寫(xiě)2024/06/01。還有一點(diǎn)模擬數(shù)據(jù)里的時(shí)間字符串如果沒(méi)指定時(shí)區(qū)Spark會(huì)按運(yùn)行環(huán)境默認(rèn)時(shí)區(qū)解析偶爾出現(xiàn)日期偏移一小時(shí)的奇怪問(wèn)題。統(tǒng)一的規(guī)范是所有日期字段都用yyyy-MM-dd所有時(shí)間小時(shí)字段都用int類(lèi)型單獨(dú)存。模型訓(xùn)練時(shí)還要注意特征列與標(biāo)簽列不要包含漏下的字符串列。VectorAssembler只能處理數(shù)值類(lèi)型weather這類(lèi)文本特征必須先做獨(dú)熱編碼或映射。很多同學(xué)一運(yùn)行就報(bào)“Field weather is not numeric”其實(shí)是忘了這一步。編碼方式選擇上天氣類(lèi)別少直接用StringIndexer OneHotEncoder即可。最后分享一點(diǎn)個(gè)人的實(shí)操體會(huì)做這種綜合性畢設(shè)最值錢(qián)的反而不是代碼本身而是踩坑記錄。真正答辯時(shí)老師未必會(huì)深挖模型的數(shù)學(xué)原理但一定會(huì)問(wèn)你部署時(shí)遇到什么問(wèn)題、監(jiān)控里哪個(gè)指標(biāo)異常。所以從第一天起把終端日志、運(yùn)行截圖、報(bào)錯(cuò)信息按日期存好既能讓論文的實(shí)驗(yàn)部分有血有肉也是對(duì)你自學(xué)能力最有力的證明。技術(shù)棧永遠(yuǎn)在變但把一條數(shù)據(jù)鏈路從頭到尾跑通的本事是任何時(shí)候都用得上的。