盟陣容分析平臺(tái)實(shí)戰(zhàn))
很多同學(xué)拿到大數(shù)據(jù)相關(guān)的課程設(shè)計(jì)題目會(huì)慌尤其是那種把 Hadoop、Spark、Python 串起來(lái)的綜合項(xiàng)目。這個(gè)hadoopSpark基于Python的英雄聯(lián)盟排位賽陣容分析平臺(tái)就是我做過(guò)的一個(gè)典型題目——聽起來(lái)是三個(gè)技術(shù)棧疊在一起實(shí)際上拆開看每個(gè)組件干的事情非常清晰。這篇文章就圍繞這個(gè)項(xiàng)目把從需求拆解、架構(gòu)設(shè)計(jì)、環(huán)境搭建、代碼實(shí)現(xiàn)到可視化大屏的經(jīng)驗(yàn)完整寫出來(lái)給正在做同類型題目的朋友一個(gè)能直接參考的完整流程。先交代背景這個(gè)平臺(tái)解決的核心問題是從海量《英雄聯(lián)盟》排位賽對(duì)局?jǐn)?shù)據(jù)里挖掘陣容層面的規(guī)律——比如哪些英雄在當(dāng)前版本勝率最高、哪些組合同時(shí)出場(chǎng)時(shí)勝率明顯偏高、不同位置的英雄優(yōu)先級(jí)怎么排。數(shù)據(jù)量達(dá)到幾十萬(wàn)場(chǎng)以上的對(duì)局記錄時(shí)單機(jī) Excel 和 Pandas 已經(jīng)跑不動(dòng)了這時(shí)候 Hadoop 負(fù)責(zé)存儲(chǔ)、Spark 負(fù)責(zé)分布式計(jì)算、Python 負(fù)責(zé)采集和最終的分析邏輯最后將聚合結(jié)果投到可視化大屏上展示。這套流程恰好覆蓋了大數(shù)據(jù)的經(jīng)典鏈路也是很多院校課程設(shè)計(jì)和畢業(yè)設(shè)計(jì)偏好的選題方向。如果你對(duì)大數(shù)據(jù)分析、游戲數(shù)據(jù)洞察、數(shù)據(jù)可視化感興趣或者正在找類似的完整項(xiàng)目參考這篇文章應(yīng)該能幫上你。1. 項(xiàng)目整體設(shè)計(jì)與思路1.1 需求拆解陣營(yíng)分析到底要算什么指標(biāo)拿到題目后第一步不是急著裝環(huán)境而是把陣容分析這四個(gè)字拆成可執(zhí)行的計(jì)算指標(biāo)。我在做這個(gè)項(xiàng)目時(shí)參考了常見游戲數(shù)據(jù)分析平臺(tái)的做法把指標(biāo)分成四個(gè)維度。第一類是英雄基礎(chǔ)數(shù)據(jù)出場(chǎng)率、勝率、禁用率。這三個(gè)指標(biāo)能快速反映出當(dāng)前版本的強(qiáng)勢(shì)英雄。第二類是位置維度因?yàn)?LOL 的排位賽有上單、打野、中單、ADC、輔助五個(gè)位置不同位置的英雄池差異很大單純看全局勝率會(huì)掩蓋位置特征所以必須按位置拆分統(tǒng)計(jì)。第三類是英雄搭配組合分析也就是經(jīng)常說(shuō)的陣容羈絆——某些英雄同時(shí)出場(chǎng)時(shí)會(huì)產(chǎn)生體系效應(yīng)比如雙核發(fā)育體系強(qiáng)開團(tuán)陣容韓國(guó)式運(yùn)營(yíng)體系等這類分析需要統(tǒng)計(jì)英雄之間的共現(xiàn)頻次以及組合勝率。第四類是分段過(guò)濾不同段位的對(duì)局策略差異很大黑鐵局和大師局的陣容邏輯完全不同所以在計(jì)算指標(biāo)時(shí)必須能夠按段位區(qū)間做過(guò)濾。把這四個(gè)維度落到技術(shù)層面對(duì)應(yīng)的就是一系列分組聚合、排序、TopN 截取和關(guān)聯(lián)規(guī)則的批量計(jì)算。整個(gè)項(xiàng)目的數(shù)據(jù)規(guī)模如果采集 20 萬(wàn)場(chǎng)以上的對(duì)局記錄每場(chǎng)對(duì)局包含雙方十個(gè)英雄的選人信息、段位、位置、勝負(fù)等 18 個(gè)左右的核心字段展開成明細(xì)行之后數(shù)據(jù)量在百萬(wàn)級(jí)別。單機(jī)處理這種量級(jí)的多次聚合不是不行但速度很慢而且頻繁的內(nèi)存排序容易把筆記本卡死。這正是引入 Spark 的充分理由把明細(xì)數(shù)據(jù)分布式存儲(chǔ)到 HDFS用 Spark 的 DataFrame API 快速完成多輪聚合。1.2 為什么技術(shù)上選了 Hadoop Spark Python 這套組合這個(gè)技術(shù)選型首先要考慮的是題目的教學(xué)意義。Hadoop 生態(tài)中的 HDFS 提供了分布式文件系統(tǒng)的概念NameNode 和 DataNode 的角色分工、數(shù)據(jù)塊的副本機(jī)制這些都是大數(shù)據(jù)入門躲不開的基礎(chǔ)知識(shí)。Spark 則是目前業(yè)界最主流的分布式計(jì)算引擎它用內(nèi)存計(jì)算替代了 MapReduce 反復(fù)落盤的機(jī)制在迭代計(jì)算場(chǎng)景下性能優(yōu)勢(shì)明顯。Python 則是用來(lái)做數(shù)據(jù)采集、清洗和統(tǒng)計(jì)分析的主力語(yǔ)言生態(tài)成熟編寫效率高。很多同學(xué)會(huì)問為什么不用純 Python 加 Pandas 直接分析答案是可以但這違背了題目想要考察的技術(shù)點(diǎn)。課程設(shè)計(jì)和畢業(yè)設(shè)計(jì)本質(zhì)上要展示你對(duì)整套大數(shù)據(jù)處理流程的掌握程度而不僅僅是一個(gè)分析結(jié)果。HDFS 上的原始數(shù)據(jù)落盤、Spark 任務(wù)的提交和監(jiān)控、YARN 對(duì)資源的調(diào)度這些過(guò)程本身就是加分項(xiàng)。另外一個(gè)很現(xiàn)實(shí)的原因是容錯(cuò)率。Hadoop 和 Spark 都是成熟的分布式框架本地用偽分布式模式跑批量計(jì)算非常穩(wěn)定不會(huì)因?yàn)閿?shù)據(jù)量大一點(diǎn)就 OOM。相比之下單機(jī) Pandas 在內(nèi)存吃緊的時(shí)候處理幾個(gè) G 的數(shù)據(jù)經(jīng)常直接崩潰尤其是做笛卡爾積類操作的時(shí)候。我在這類項(xiàng)目里有一條經(jīng)驗(yàn)數(shù)據(jù)量上了百萬(wàn)行以后凡是涉及多輪 groupBy 和 join 的活兒優(yōu)先交給 Spark凡是數(shù)據(jù)量不大但對(duì)靈活性要求高的活兒留在 Python 里處理。1.3 系統(tǒng)整體架構(gòu)從數(shù)據(jù)采集到可視化大屏的完整鏈路整個(gè)平臺(tái)的數(shù)據(jù)鏈路可以分成四層。采集層負(fù)責(zé)從 Riot 開發(fā)者平臺(tái)或公開數(shù)據(jù)集拉取排位賽對(duì)局?jǐn)?shù)據(jù)解析成結(jié)構(gòu)化 JSON 存入本地存儲(chǔ)層用 Hadoop HDFS 構(gòu)建偽分布式文件系統(tǒng)把原始 JSON 按天或按大區(qū)劃分成數(shù)據(jù)文件計(jì)算層交給 Spark讀取 HDFS 上的數(shù)據(jù)清洗后轉(zhuǎn)成 DataFrame執(zhí)行勝率計(jì)算、搭配挖掘、分位置聚合等任務(wù)結(jié)果寫成分析結(jié)果表和 Top 榜單展示層由 Python 的 Flask 框架提供數(shù)據(jù)查詢接口前端頁(yè)面通過(guò) ECharts 渲染大屏可視化。這里有一個(gè)架構(gòu)上的取舍值得說(shuō)清楚為什么計(jì)算結(jié)果不直接 feed 給前端頁(yè)面而是要通過(guò) Flask 再做一層接口原因是為了解耦。Spark 分析任務(wù)是批處理模式可能跑幾分鐘甚至更久而大屏展示是實(shí)時(shí)頁(yè)面請(qǐng)求不能等 Spark 跑完才響應(yīng)。把分析結(jié)果預(yù)先落地成 MySQL 表或者 JSON 文件前端只做展示查詢響應(yīng)速度能達(dá)到毫秒級(jí)。這其實(shí)也模擬了真實(shí)企業(yè)里離線計(jì)算 線上查詢的分層思路。2. Hadoop 和 Spark 在項(xiàng)目中的分工與協(xié)作2.1 HDFS 存儲(chǔ)層設(shè)計(jì)數(shù)據(jù)文件應(yīng)該怎么規(guī)劃HDFS 的核心思想是把大文件切成小塊分散存儲(chǔ)在多個(gè)節(jié)點(diǎn)上并對(duì)每個(gè)塊做冗余備份。本項(xiàng)目的偽分布式模式就相當(dāng)于只有一個(gè) DataNode 節(jié)點(diǎn)運(yùn)行在本機(jī)所以副本數(shù)一般設(shè)為 1 就夠。實(shí)際規(guī)劃 HDFS 目錄時(shí)我建議把原始數(shù)據(jù)、清洗后數(shù)據(jù)和計(jì)算結(jié)果分別存放在不同路徑下避免后續(xù)任務(wù)讀錯(cuò)文件。推薦的目錄規(guī)劃是/lol/raw/存放從 API 拉下來(lái)的 JSON 原始文件/lol/clean/存放經(jīng)過(guò)清洗之后的 Parquet 或 CSV/lol/result/存放分析結(jié)果集。這樣做的好處很明顯——Spark 作業(yè)可以只讀取指定層的數(shù)據(jù)也方便出錯(cuò)時(shí)單獨(dú)重算某一層。相比之下如果所有數(shù)據(jù)都堆在一個(gè)目錄里排查問題和任務(wù)失敗重跑的成本都會(huì)翻倍。HDFS 寫入時(shí)我習(xí)慣用-put命令上傳本地文件也可以用 Python 的hdfs庫(kù)直接對(duì)接 WebHDFS 接口。在 20 萬(wàn)場(chǎng)對(duì)局的規(guī)模下原始 JSON 文件總量一般在 5-10GB 左右HDFS 的默認(rèn)塊大小 128MB 對(duì)這個(gè)場(chǎng)景很合適。有一點(diǎn)需要特別注意HDFS 對(duì)小文件非常不友好如果采集程序把每場(chǎng)比賽單獨(dú)存成一個(gè) JSON一會(huì)兒就在目錄里產(chǎn)生幾萬(wàn)個(gè)小文件NameNode 內(nèi)存壓力很大后續(xù) Spark 讀取也會(huì)因?yàn)槲募斜磉^(guò)長(zhǎng)而變慢。我的做法是采集端每收集 5000 場(chǎng)對(duì)局就合并寫成一個(gè)文件Spark 讀取時(shí)的效率會(huì)明顯好很多。2.2 Spark 計(jì)算引擎為什么在這么多選型里選它Spark 在項(xiàng)目中的定位是計(jì)算引擎它從 HDFS 上讀數(shù)據(jù)然后做分布式計(jì)算。Spark Core 提供了彈性分布式數(shù)據(jù)集 RDD 的抽象Spark SQL 提供了更高層的 DataFrame/Dataset 接口后者有 Catalyst 優(yōu)化器對(duì)寫 SQL 和聚合類操作極其友好。在本項(xiàng)目里我用得最多的就是 Spark SQL。為什么 Spark 跑這批聚合任務(wù)比傳統(tǒng)方式快核心原因在于它的內(nèi)存計(jì)算模型。MapReduce 在每一輪任務(wù)結(jié)束后會(huì)把中間結(jié)果寫入磁盤下一輪任務(wù)再重新讀入在需要多次迭代的統(tǒng)計(jì)分析例如逐層計(jì)算組合勝率里磁盤 IO 開銷非常大。Spark 則盡量把中間結(jié)果留在內(nèi)存里跨越多個(gè) stage 時(shí)不需要反復(fù)落盤。用生活化的類比來(lái)解釋MapReduce 像是一個(gè)來(lái)回跑倉(cāng)庫(kù)搬運(yùn)貨物的工人每搬一趟都要把貨先存進(jìn)倉(cāng)庫(kù)再取出來(lái)Spark 像是直接在貨物旁邊搭了個(gè)臨時(shí)貨架同一批數(shù)據(jù)在多輪計(jì)算中都能快速訪問。本項(xiàng)目的核心計(jì)算模式是先做寬泛聚合再做精細(xì)挑選。先用一個(gè) SQL 查詢把所有明細(xì)數(shù)據(jù)按英雄和位置分組計(jì)算出場(chǎng)次數(shù)和勝場(chǎng)數(shù)然后基于結(jié)果集再做一輪 join算出英雄共現(xiàn)組合的勝率。這類多輪 join 和聚合在 Spark 里跑得很快實(shí)測(cè) 50 萬(wàn)行明細(xì)數(shù)據(jù)完成全部指標(biāo)計(jì)算不到 3 分鐘這比單機(jī) Pandas 滾動(dòng)計(jì)算要可靠得多。2.3 Python 在鏈路里的三個(gè)角色采集、粘合、展示Python 在這個(gè)項(xiàng)目里不是替代 Spark 的而是和 Spark 各司其職。首先數(shù)據(jù)采集腳本通常用 Python 寫因?yàn)?Riot API 返回的是 JSONPython 的requests加json庫(kù)處理起來(lái)最順手。采集腳本要處理限流、重試、斷點(diǎn)續(xù)采等問題這些用 Python 寫非常簡(jiǎn)單。其次Python 是連接各組件的主力。這里有一個(gè)容易被忽略的細(xì)節(jié)Spark 官方雖然提供了 Scala 和 Java 接口但是通過(guò) PySpark你可以直接用 Python 寫 DataFrame 操作并提交到 Spark 執(zhí)行。PySpark 只是在 Python 進(jìn)程和 JVM 之間加了一層通信橋真正執(zhí)行的還是 Spark 底層的分布式計(jì)算邏輯。所以項(xiàng)目的核心分析代碼可以用純 Python 風(fēng)格寫同時(shí)享受 Spark 的分布式能力。第三Flask 后端和可視化大屏的前端頁(yè)面也歸 Python 管。Flask 啟動(dòng)一個(gè)輕量 Web 服務(wù)定義幾個(gè)返回 JSON 的接口前端 AJAX 拉數(shù)據(jù)ECharts 渲染圖表。整個(gè)項(xiàng)目從數(shù)據(jù)采集、指標(biāo)計(jì)算到頁(yè)面展示全部統(tǒng)一在 Python 技術(shù)棧里代碼交付和維護(hù)都很順暢。3. 從零搭建 Hadoop 偽分布式與 Spark 的完整實(shí)操3.1 Hadoop 安裝配置偽分布式模式的關(guān)鍵步驟Hadoop 的安裝在整個(gè)項(xiàng)目里看似基礎(chǔ)但確實(shí)是新手耗時(shí)最多的環(huán)節(jié)。我在做這個(gè)項(xiàng)目時(shí)用的是 Hadoop 3.3 版本部署在 CentOS 7 虛擬機(jī)里本機(jī)開發(fā)環(huán)境是 Windows。下面梳理一下完整流程和我在配置過(guò)程中做的關(guān)鍵調(diào)整。第一步是安裝 JDK。Hadoop 3.x 要求 JDK 8 以上推薦 JDK8。記得配好JAVA_HOME和PATH環(huán)境變量后在終端里執(zhí)行java -version驗(yàn)證。第二步是配置 SSH 免密登錄這一項(xiàng)非常關(guān)鍵因?yàn)?Hadoop 的啟動(dòng)腳本需要通過(guò) SSH 連接到 localhost 啟動(dòng)各個(gè)守護(hù)進(jìn)程。我踩過(guò)的一個(gè)典型坑是ssh localhost都通了但啟動(dòng)集群后 DataNode 進(jìn)程不斷退出最后發(fā)現(xiàn)是免密配置不完整導(dǎo)致的。第三步是編輯三個(gè)核心配置文件。core-site.xml里設(shè)置默認(rèn)文件系統(tǒng)為hdfs://localhost:9000hdfs-site.xml里設(shè)置副本數(shù)為 1并配置 NameNode 的存儲(chǔ)目錄yarn-site.xml里配置資源調(diào)度相關(guān)參數(shù)。我習(xí)慣把這兩段配置直接寫在配置文件里就像下面這樣!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property /configuration!-- hdfs-site.xml -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/home/hadoop/data/name/value /property property namedfs.datanode.data.dir/name value/home/hadoop/data/data/value /property /configuration第四步是執(zhí)行格式化操作hdfs namenode -format。這一步我特別提醒一下格式化會(huì)把 NameNode 元數(shù)據(jù)清空如果集群里已經(jīng)有數(shù)據(jù)千萬(wàn)不要反復(fù)格式化。第五步就是啟動(dòng)集群start-dfs.sh和start-yarn.sh。啟動(dòng)后用jps命令檢查進(jìn)程看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager這五個(gè)進(jìn)程都在說(shuō)明偽分布式模式起來(lái)了。3.2 Spark 部署local 模式和 yarn 模式怎么選Spark 的安裝比 Hadoop 簡(jiǎn)單。它不依賴 Hadoop 的配置只需要下載編譯好的 tar 包解壓后改一個(gè)環(huán)境變量就行。但有一個(gè)容易踩的坑Spark 默認(rèn)會(huì)用系統(tǒng)里的JAVA_HOME如果你的 JDK 版本和 Hadoop 不匹配Spark 作業(yè)會(huì)報(bào)各種詭異的 JVM 錯(cuò)誤。Spark 有本地模式、獨(dú)立集群模式和 YARN 模式三種運(yùn)行方式。課程設(shè)計(jì)階段我建議先用本地模式跑通邏輯也就是local[*]參數(shù)它表示用本機(jī)所有 CPU 核心作為并行度不依賴 YARN 調(diào)度。這種方式調(diào)試速度快報(bào)錯(cuò)也直觀。項(xiàng)目收尾或演示階段再切到 YARN 模式提交展示 Spark 作業(yè)在 ResourceManager 里被調(diào)度執(zhí)行的過(guò)程這種演示效果會(huì)給答辯加分不少。實(shí)際啟動(dòng)時(shí)我習(xí)慣這樣配置環(huán)境變量export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export HADOOP_HOME/home/hadoop/hadoop-3.3.6 export SPARK_HOME/home/hadoop/spark-3.5.0-bin-hadoop3 export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$SPARK_HOME/bin export PYSPARK_PYTHON/usr/bin/python3其中PYSPARK_PYTHON用來(lái)指定 PySpark 驅(qū)動(dòng)使用的 Python 解釋器路徑。如果這個(gè)變量沒設(shè)置正確提交作業(yè)時(shí)會(huì)出現(xiàn) Python 解釋器不匹配的情況網(wǎng)上有大量同學(xué)在這個(gè)問題上卡住。3.3 Python 環(huán)境準(zhǔn)備依賴包和版本兼容Python 部分的準(zhǔn)備工作核心是版本對(duì)齊。我用的 Python 3.8安裝了pyspark、requests、pandas、flask和hdfs庫(kù)。這里需要特別注意pyspark版本要和你的 Spark 版本一致否則 API 會(huì)變。我的 Spark 是 3.5.0對(duì)應(yīng)的 PySpark 就用 3.5.0直接用 pip 安裝即可pip install pyspark3.5.0 pip install flask pandas requests在 Windows 本機(jī)開發(fā)時(shí)在命令行里寫 PySpark 代碼可以通過(guò)spark-submit提交到遠(yuǎn)程服務(wù)器也可以直接用pyspark交互式環(huán)境調(diào)試。我一般先在本地把 DataFrame 操作寫順了再整段搬到服務(wù)器上執(zhí)行這個(gè)開發(fā)節(jié)奏比較穩(wěn)。4. 數(shù)據(jù)采集與預(yù)處理分析結(jié)果的源頭保障4.1 數(shù)據(jù)從哪來(lái)API 采集與公開數(shù)據(jù)集的取舍做游戲數(shù)據(jù)分析的第一步永遠(yuǎn)是確認(rèn)數(shù)據(jù)來(lái)源。最規(guī)范的做法是使用 Riot 開發(fā)者平臺(tái)的官方 API 拉取比賽記錄但注冊(cè)開發(fā)者密鑰和調(diào)用限流比較繁瑣。另一種方式是使用公開的數(shù)據(jù)集比如 Kaggle 上有不少 LOL 排位賽對(duì)局?jǐn)?shù)據(jù)集包含比賽編號(hào)、召喚師信息、英雄 ID、位置、勝負(fù)等字段直接下載即可。我的做法是以公開數(shù)據(jù)集為主API 采集腳本為輔這樣既保證了數(shù)據(jù)量夠用也展示了數(shù)據(jù)采集能力。這里提醒一點(diǎn)如果從 API 采集一定要看接口文檔里rate limit的說(shuō)明單位時(shí)間的請(qǐng)求次數(shù)是受限的。我在采集腳本里加入了重試和限速邏輯控制請(qǐng)求頻率在每秒 5 次以內(nèi)避免觸發(fā)封禁。另外不要只采排位賽數(shù)據(jù)也不要只采一個(gè)分段的要考慮覆蓋面足夠代表性。4.2 核心字段說(shuō)明一場(chǎng)對(duì)局里能抽出哪些特征每場(chǎng)排位賽對(duì)局的數(shù)據(jù)結(jié)構(gòu)是嵌套 JSON。大致包含比賽時(shí)間戳、對(duì)局類型、游戲版本號(hào)、勝利方陣營(yíng)、失敗方陣營(yíng)每個(gè)陣營(yíng)下又有五個(gè)位置的信息。展開成結(jié)構(gòu)化表單后核心字段大概是這些字段名含義處理說(shuō)明game_id對(duì)局ID作為去重主鍵game_time比賽時(shí)間需從時(shí)間戳轉(zhuǎn)為日期格式tier段位區(qū)間如黃金、鉑金、鉆石用于分組position位置TOP、JUNGLE、MID、BOT、SUPPORTchampion_id英雄ID需關(guān)聯(lián)英雄名字映射表team_side陣營(yíng)藍(lán)方或紅方win是否獲勝1 表示勝 0 表示負(fù)英雄 ID 映射表是很容易遺漏的準(zhǔn)備工作。API 返回和大部分?jǐn)?shù)據(jù)集里存的都是數(shù)字 ID比如某英雄 ID 對(duì)應(yīng)暗裔劍魔、另一個(gè)對(duì)應(yīng)九尾妖狐如果前端要顯示英雄名必須在分析鏈路里提前把 ID 映射成中文名或英文名。我用一個(gè)靜態(tài)映射 JSON 文件來(lái)管理這個(gè)對(duì)應(yīng)關(guān)系這樣分析結(jié)果導(dǎo)出后可以直接用于展示。4.3 清洗規(guī)則與臟數(shù)據(jù)處理對(duì)局?jǐn)?shù)據(jù)雖然來(lái)源正規(guī)但依然存在不少臟數(shù)據(jù)。我在項(xiàng)目里總結(jié)的清洗規(guī)則主要有這幾條第一按game_id去重因?yàn)?API 重試可能導(dǎo)致同一場(chǎng)對(duì)局被拉取多次。第二處理缺失值有些棄權(quán)局在英雄字段上是空值直接過(guò)濾掉。第三段位信息統(tǒng)一歸一化比如韓服鉑金和大師30星這類不同表述統(tǒng)一映射到標(biāo)準(zhǔn)段位級(jí)別。第四時(shí)間戳轉(zhuǎn)成日期后按周聚合可以觀察版本更新前后的英雄勝率變化這一點(diǎn)對(duì)分析非常有價(jià)值。清洗完成的數(shù)據(jù)落盤到 HDFS 的/lol/clean/目錄以分區(qū)目錄存成 Parquet 格式。Parquet 是一種列式存儲(chǔ)格式它相比 JSON 和 CSV 有兩個(gè)優(yōu)勢(shì)壓縮比高、按列讀取快在 Spark 后續(xù)處理時(shí)能大幅減少 IO 開銷。5. 用 Spark 實(shí)現(xiàn)陣容分析的完整代碼過(guò)程5.1 讀取 HDFS 數(shù)據(jù)并構(gòu)建分析視圖PySpark 讀取 Parquet 數(shù)據(jù)非常直接。要注意的是如果你的 PySpark 代碼跑在本地模式spark.read.parquet(hdfs://localhost:9000/lol/clean/match.parquet)這種帶完整 HDFS URL 的寫法最穩(wěn)妥不會(huì)因?yàn)槟J(rèn)文件系統(tǒng)配置問題而讀錯(cuò)路徑。我通常這樣啟動(dòng) SparkSessionfrom pyspark.sql import SparkSession spark SparkSession.builder \ .appName(LoLMatchAnalysis) \ .master(local[*]) \ .config(spark.sql.shuffle.partitions, 50) \ .getOrCreate() df spark.read.parquet(hdfs://localhost:9000/lol/clean/match.parquet)spark.sql.shuffle.partitions這個(gè)參數(shù)在實(shí)際項(xiàng)目中特別重要。它控制聚合運(yùn)算時(shí)的分區(qū)數(shù)默認(rèn)值是 200意味著每個(gè)聚合操作都會(huì)產(chǎn)生 200 個(gè)分區(qū)。如果你的數(shù)據(jù)量只有幾十萬(wàn)行200 個(gè)分區(qū)反而會(huì)加劇任務(wù)調(diào)度開銷。調(diào)整為 50 之后小數(shù)據(jù)量下的運(yùn)行速度能快不少。5.2 核心分析一英雄勝率與出場(chǎng)率排名英雄基礎(chǔ)指標(biāo)是統(tǒng)計(jì)分析的起點(diǎn)。用 Spark SQL 或者 DataFrame 的groupBy操作一條語(yǔ)句就能完成勝率和出場(chǎng)率統(tǒng)計(jì)top_champion df.filter(df[position] ! ) \ .groupBy(champion_id, champion_name) \ .agg( func.count(champion_id).alias(play_count), func.round(func.sum(win) / func.count(champion_id), 3).alias(win_rate) ) \ .filter(func.col(play_count) 200) \ .orderBy(func.desc(win_rate)) top_champion.show(20)過(guò)濾play_count 200是統(tǒng)計(jì)分析里的常見手段它的目的是排除那些出場(chǎng)次數(shù)太少、樣本量不足的英雄這類英雄的勝率波動(dòng)大參考價(jià)值很低。比如一個(gè)英雄總共出場(chǎng) 3 場(chǎng)勝 3 場(chǎng)勝率 100%但其實(shí)說(shuō)明不了任何問題。樣本量閾值建議按照總數(shù)據(jù)量來(lái)調(diào)我 20 萬(wàn)場(chǎng)的數(shù)據(jù)里設(shè)為 200 比較合適。5.3 核心分析二位置維度的英雄優(yōu)先級(jí)位置維度的分析和整體分析邏輯幾乎一樣只是多了position分組條件。但它在業(yè)務(wù)上意義很大同一個(gè)英雄在不同位置的勝率表現(xiàn)差別可能非常大典型例子是某些戰(zhàn)士英雄打上單和打野是兩種打法整體勝率被平均后就沒有參考價(jià)值了。按位置統(tǒng)計(jì)后可以為每個(gè)位置生成一份優(yōu)先推薦英雄榜單這也是陣容推薦功能的基礎(chǔ)。pos_stats df.groupBy(position, champion_name) \ .agg( func.count(champion_name).alias(pick_count), func.round(func.avg(win), 3).alias(win_rate) ) \ .withColumn(rank, func.row_number().over( Window.partitionBy(position).orderBy(func.desc(win_rate)) )) \ .filter(func.col(pick_count) 100) pos_stats.filter(func.col(rank) 5).show()窗口函數(shù)row_number()在這里派上了大用場(chǎng)。它按位置分組后從勝率最高的英雄開始編號(hào)取前 5 名就是該位置的 Top 5。這種寫法比先按位置分開查、再手動(dòng)排序要簡(jiǎn)潔得多。5.4 核心分析三英雄搭配組合挖掘英雄搭配組合是本項(xiàng)目最有看點(diǎn)的分析。思路是找到同一陣營(yíng)內(nèi)部?jī)蓛捎⑿鄣慕M合統(tǒng)計(jì)組合出現(xiàn)的場(chǎng)次和勝率勝率高的組合就是值得關(guān)注的強(qiáng)勢(shì)體系。實(shí)現(xiàn)的核心是自連接也就是 DataFrame 自己 join 自己。我把一場(chǎng)比賽的五個(gè)人拆成長(zhǎng)表每個(gè)英雄一條行然后alias成兩份按game_id和team_side關(guān)聯(lián)起來(lái)并排除champion_name相同的組合就拿到了所有共現(xiàn)對(duì)兒detail df.select(game_id, team_side, win, champion_name, position) pair_df detail.alias(a) \ .join(detail.alias(b), (func.col(a.game_id) func.col(b.game_id)) (func.col(a.team_side) func.col(b.team_side)) (func.col(a.champion_name) func.col(b.champion_name)) ) \ .select( func.col(a.champion_name).alias(champ_a), func.col(b.champion_name).alias(champ_b), func.col(a.win).alias(win) ) \ .groupBy(champ_a, champ_b) \ .agg( func.count(champ_a).alias(pair_count), func.round(func.sum(win) / func.count(champ_a), 3).alias(pair_win_rate) ) \ .filter(func.col(pair_count) 50) \ .orderBy(func.desc(pair_win_rate))這里用func.col(a.champion_name) func.col(b.champion_name)做 join 條件是一個(gè)避免重復(fù)組合的技巧。如果不加這個(gè)條件組合盲僧亞索和亞索盲僧會(huì)分別統(tǒng)計(jì)成兩條記錄后續(xù)展示時(shí)會(huì)混亂。按字符串大小比較之后每一對(duì)英雄只會(huì)出現(xiàn)一次。執(zhí)行效率方面這種自連接在 Spark 中會(huì)觸發(fā)一次 shuffle但在這個(gè)量級(jí)完全可以接受。5.5 計(jì)算結(jié)果的落地導(dǎo)出為報(bào)表數(shù)據(jù)所有分析結(jié)果最終要導(dǎo)出到后端可讀取的位置。我的做法是寫到 MySQL 數(shù)據(jù)庫(kù)中用 PySpark 的jdbc連接器直接寫入也可以用toPandas()轉(zhuǎn)成 Pandas DataFrame 再通過(guò) SQLAlchemy 寫入。前者適合大數(shù)據(jù)量后者簡(jiǎn)單直接。課程設(shè)計(jì)場(chǎng)景下數(shù)據(jù)量不大toPandas()方案更省事top_champion_df top_champion.toPandas() top_champion_df.to_csv(/home/lol/result/top_champion.csv, indexFalse)MySQL 表結(jié)構(gòu)按照分析維度設(shè)計(jì)champion_rank表存英雄總榜position_rank表存分位置榜單pair_rank表存組合榜單。每個(gè)表帶上update_time字段方便大屏展示時(shí)標(biāo)記數(shù)據(jù)更新時(shí)間。6. 可視化大屏從數(shù)據(jù)到可讀性強(qiáng)的展示6.1 大屏布局設(shè)計(jì)信息層次決定觀看體驗(yàn)可視化大屏的布局會(huì)直接影響評(píng)委的觀看體驗(yàn)。我采用的是經(jīng)典的三欄式布局頂部是整體數(shù)據(jù)概覽中間是英雄勝率 TOP 榜單左右兩側(cè)分別放位置推薦和組合分析。整體配色用深色背景配合藍(lán)紫漸變的高亮圖表視覺效果偏向科技感。大屏頁(yè)面的數(shù)據(jù)全部來(lái)自 Flask 接口。Flask 讀取 MySQL 或者 CSV 文件后返回 JSON前端 ECharts 通過(guò)fetch拉取。這里要注意一個(gè)前后端聯(lián)調(diào)問題Flask 默認(rèn)開啟的CORS不支持跨域請(qǐng)求如果前端頁(yè)面和 Flask 端口不一致瀏覽器會(huì)攔截接口返回。我在 Flask 里設(shè)置了一個(gè)全局響應(yīng)頭允許所有來(lái)源的跨域請(qǐng)求。app.after_request def add_cors_headers(resp): resp.headers[Access-Control-Allow-Origin] * return resp6.2 核心圖表類型選擇什么場(chǎng)景配什么圖大屏的圖表選型是我覺得最能體現(xiàn)項(xiàng)目完成度的地方。英雄勝率排行用橫向條形圖最直觀一目了然地看出勝負(fù)率高低的優(yōu)劣差距注意條形圖的英雄名稱過(guò)長(zhǎng)時(shí)要啟用豎排標(biāo)簽。組合分析適合用帶權(quán)重的關(guān)系圖兩個(gè)英雄之間連線越粗代表出場(chǎng)次數(shù)越多連線顏色偏向暖色代表勝率越高這樣玩家一眼就能看出哪些體系勝率高。分位置的推薦榜單我用了雷達(dá)圖或者分組柱狀圖橫軸是五個(gè)位置縱軸是勝率同一位置內(nèi)多個(gè)英雄用不同顏色區(qū)分。頂部概覽區(qū)域放三個(gè)指標(biāo)卡累計(jì)分析對(duì)局?jǐn)?shù)、平均對(duì)局時(shí)長(zhǎng)、版本強(qiáng)勢(shì)英雄數(shù)量。6.3 大屏數(shù)據(jù)刷新的聯(lián)動(dòng)機(jī)制大屏不能做成靜態(tài)頁(yè)面。我加了一個(gè)定時(shí)刷新機(jī)制前端每隔 60 秒請(qǐng)求一次接口檢查數(shù)據(jù)的update_time是否有變化有新數(shù)據(jù)就無(wú)感刷新圖表。這個(gè)功能雖然簡(jiǎn)單但在答辯演示時(shí)很加分因?yàn)榭梢袁F(xiàn)場(chǎng)跑一次 Spark 任務(wù)看到大屏數(shù)據(jù)實(shí)時(shí)變化整個(gè)項(xiàng)目的完整閉環(huán)感一下子就出來(lái)了。7. 開發(fā)過(guò)程中遇到的經(jīng)典問題與排查經(jīng)驗(yàn)7.1 Hadoop 啟動(dòng)相關(guān)的坑DataNode進(jìn)程一直啟動(dòng)不起來(lái)的排查思路必須清楚。首先用jps看進(jìn)程在不在不在的話直接查看logs/hadoop-hadoop-datanode-主機(jī)名.log日志文件。常見原因是dfs.datanode.data.dir目錄沒有創(chuàng)建成功或者目錄權(quán)限不對(duì)。另一個(gè)高頻問題是NameNode格式化之后DataNode 的注冊(cè)信息不一致啟動(dòng)時(shí)也會(huì)被拒絕。解決辦法非常簡(jiǎn)單但容易忘把 Hadoop 的臨時(shí)目錄和數(shù)據(jù)目錄整個(gè)刪除重新格式化后啟動(dòng)。我在實(shí)際開發(fā)中遇到過(guò)一個(gè)更隱蔽的問題虛擬機(jī)的內(nèi)存只有 2GB啟動(dòng) Hadoop 加 Spark 后內(nèi)存吃滿NameNode被系統(tǒng)殺掉日志里能看到明顯的 OOM 記錄。后來(lái)給虛擬機(jī)漲到 4GB并在hadoop-env.sh里限制每個(gè)進(jìn)程的 JVM 堆大小這個(gè)問題就再?zèng)]出現(xiàn)過(guò)。7.2 Spark 作業(yè)報(bào)錯(cuò)和性能問題PySpark 最常見的報(bào)錯(cuò)是Python in worker has different version這是PYSPARK_PYTHON環(huán)境變量沒有正確指向服務(wù)器上的 Python 解釋器導(dǎo)致的。另外Executor lost和Job aborted due to stage failure這類錯(cuò)誤很多時(shí)候不是代碼邏輯有問題而是內(nèi)存配置不足。在提交任務(wù)時(shí)加--executor-memory 4g --driver-memory 2g參數(shù)大部分情況下能解決。性能調(diào)優(yōu)方面的一個(gè)心得是盡量避免collect()拉取大數(shù)據(jù)量到本地。有同學(xué)習(xí)慣在 PySpark 里用.collect()把所有結(jié)果變成 Python 列表再做剩余處理數(shù)據(jù)量一大內(nèi)存就爆了。正確的做法是讓 Spark 完成盡可能多的計(jì)算最后只用show()或toPandas()導(dǎo)出小體量的聚合結(jié)果。7.3 可視化展示中的問題大屏頁(yè)面顯示空白百分之八十是因?yàn)?ECharts 圖表寬度和高度沒有初始化。這個(gè)問題說(shuō)大不大但調(diào)試起來(lái)很煩。還有中文亂碼問題Flask 返回 JSON 時(shí)需要確保數(shù)據(jù)源文件用 UTF-8 編碼讀取 CSV 時(shí)顯式指定encodingutf-8。前端展示中文英雄名時(shí)如果接口里已經(jīng)亂碼改前端沒有意義必須回到數(shù)據(jù)分析階段解決編碼問題。我把這些高頻問題整理成一個(gè)排查速查表方便遇到同類情況時(shí)快速對(duì)照現(xiàn)象可能原因解決辦法DataNode 啟動(dòng)后立即退出數(shù)據(jù)目錄權(quán)限不對(duì)檢查并創(chuàng)建 hdfs-site 配置的目錄權(quán)限NameNode 無(wú)法啟動(dòng)格式化元數(shù)據(jù)損壞清除臨時(shí)目錄重新格式化Spark 作業(yè) Python 環(huán)境崩潰PYSPARK_PYTHON 路徑錯(cuò)誤在 spark-env.sh 中顯式指定 Python 路徑Spark 作業(yè)內(nèi)存溢出默認(rèn)內(nèi)存配置不足提交時(shí)加內(nèi)存參數(shù)調(diào)低分區(qū)數(shù)大屏圖表不顯示前后端跨域問題Flask 添加 CORS 響應(yīng)頭中文顯示為亂碼文件編碼不一致統(tǒng)一讀寫時(shí)使用 UTF-8 編碼8. 項(xiàng)目實(shí)操的額外收獲與心得整個(gè)項(xiàng)目完整做下來(lái)我投入的時(shí)間大約是三周加一個(gè)周末的集中開發(fā)。第一周用來(lái)搭建 Hadoop 和 Spark 環(huán)境、跑通數(shù)據(jù)采集第二周集中寫 Spark 分析代碼此時(shí)是最容易焦慮的階段因?yàn)榄h(huán)境問題、版本問題會(huì)同時(shí)冒出來(lái)第三周做可視化大屏和整體調(diào)試這個(gè)階段其實(shí)成就感最強(qiáng)因?yàn)閿?shù)據(jù)開始變成看得見的圖表。我個(gè)人做這類大數(shù)據(jù)綜合項(xiàng)目最深的體會(huì)是不要試圖一步到位把環(huán)境搭完美再寫代碼而是先打通最簡(jiǎn)路徑。比如先不管 YARN用 Spark 本地模式直接讀本地 CSV 把分析代碼跑通再逐步接入 HDFS、切換到 YARN 模式。循序漸進(jìn)的好處在于整個(gè)項(xiàng)目有多個(gè) checkpoint每一次成功都會(huì)給你往前推進(jìn)的信心。數(shù)據(jù)平臺(tái)項(xiàng)目最大的敵人不是某一個(gè)復(fù)雜的技術(shù)點(diǎn)而是多組件協(xié)作時(shí)那種哪個(gè)環(huán)節(jié)都不確定哪里出了問題的失控感。如果你也準(zhǔn)備做同類型的題目建議在規(guī)劃時(shí)就把源碼、文檔、調(diào)試記錄三樣產(chǎn)物同步整理。光有能跑的代碼不夠文檔里要把每一步操作命令、每個(gè)核心算法的設(shè)計(jì)思路寫清楚調(diào)試記錄里留下真實(shí)遇到問題和解決方式的截圖或日志。這不僅是答辯時(shí)的加分項(xiàng)也是對(duì)整個(gè)項(xiàng)目過(guò)程最好的復(fù)盤。我自己做完這個(gè)項(xiàng)目后再回看最初的版本最大的改變是學(xué)會(huì)了用分層的眼光看待一個(gè)完整系統(tǒng)——采集、存儲(chǔ)、計(jì)算、展示各管一段每個(gè)模塊都可以被單獨(dú)替換和優(yōu)化這和大數(shù)據(jù)生態(tài)本身的設(shè)計(jì)哲學(xué)是一致的。 基于Hadoop、Spark與Python的英雄聯(lián)盟陣容分析平臺(tái)實(shí)戰(zhàn)
很多同學(xué)拿到大數(shù)據(jù)相關(guān)的課程設(shè)計(jì)題目會(huì)慌尤其是那種把 Hadoop、Spark、Python 串起來(lái)的綜合項(xiàng)目。這個(gè)hadoopSpark基于Python的英雄聯(lián)盟排位賽陣容分析平臺(tái)就是我做過(guò)的一個(gè)典型題目——聽起來(lái)是三個(gè)技術(shù)棧疊在一起實(shí)際上拆開看每個(gè)組件干的事情非常清晰。這篇文章就圍繞這個(gè)項(xiàng)目把從需求拆解、架構(gòu)設(shè)計(jì)、環(huán)境搭建、代碼實(shí)現(xiàn)到可視化大屏的經(jīng)驗(yàn)完整寫出來(lái)給正在做同類型題目的朋友一個(gè)能直接參考的完整流程。先交代背景這個(gè)平臺(tái)解決的核心問題是從海量《英雄聯(lián)盟》排位賽對(duì)局?jǐn)?shù)據(jù)里挖掘陣容層面的規(guī)律——比如哪些英雄在當(dāng)前版本勝率最高、哪些組合同時(shí)出場(chǎng)時(shí)勝率明顯偏高、不同位置的英雄優(yōu)先級(jí)怎么排。數(shù)據(jù)量達(dá)到幾十萬(wàn)場(chǎng)以上的對(duì)局記錄時(shí)單機(jī) Excel 和 Pandas 已經(jīng)跑不動(dòng)了這時(shí)候 Hadoop 負(fù)責(zé)存儲(chǔ)、Spark 負(fù)責(zé)分布式計(jì)算、Python 負(fù)責(zé)采集和最終的分析邏輯最后將聚合結(jié)果投到可視化大屏上展示。這套流程恰好覆蓋了大數(shù)據(jù)的經(jīng)典鏈路也是很多院校課程設(shè)計(jì)和畢業(yè)設(shè)計(jì)偏好的選題方向。如果你對(duì)大數(shù)據(jù)分析、游戲數(shù)據(jù)洞察、數(shù)據(jù)可視化感興趣或者正在找類似的完整項(xiàng)目參考這篇文章應(yīng)該能幫上你。1. 項(xiàng)目整體設(shè)計(jì)與思路1.1 需求拆解陣營(yíng)分析到底要算什么指標(biāo)拿到題目后第一步不是急著裝環(huán)境而是把陣容分析這四個(gè)字拆成可執(zhí)行的計(jì)算指標(biāo)。我在做這個(gè)項(xiàng)目時(shí)參考了常見游戲數(shù)據(jù)分析平臺(tái)的做法把指標(biāo)分成四個(gè)維度。第一類是英雄基礎(chǔ)數(shù)據(jù)出場(chǎng)率、勝率、禁用率。這三個(gè)指標(biāo)能快速反映出當(dāng)前版本的強(qiáng)勢(shì)英雄。第二類是位置維度因?yàn)?LOL 的排位賽有上單、打野、中單、ADC、輔助五個(gè)位置不同位置的英雄池差異很大單純看全局勝率會(huì)掩蓋位置特征所以必須按位置拆分統(tǒng)計(jì)。第三類是英雄搭配組合分析也就是經(jīng)常說(shuō)的陣容羈絆——某些英雄同時(shí)出場(chǎng)時(shí)會(huì)產(chǎn)生體系效應(yīng)比如雙核發(fā)育體系強(qiáng)開團(tuán)陣容韓國(guó)式運(yùn)營(yíng)體系等這類分析需要統(tǒng)計(jì)英雄之間的共現(xiàn)頻次以及組合勝率。第四類是分段過(guò)濾不同段位的對(duì)局策略差異很大黑鐵局和大師局的陣容邏輯完全不同所以在計(jì)算指標(biāo)時(shí)必須能夠按段位區(qū)間做過(guò)濾。把這四個(gè)維度落到技術(shù)層面對(duì)應(yīng)的就是一系列分組聚合、排序、TopN 截取和關(guān)聯(lián)規(guī)則的批量計(jì)算。整個(gè)項(xiàng)目的數(shù)據(jù)規(guī)模如果采集 20 萬(wàn)場(chǎng)以上的對(duì)局記錄每場(chǎng)對(duì)局包含雙方十個(gè)英雄的選人信息、段位、位置、勝負(fù)等 18 個(gè)左右的核心字段展開成明細(xì)行之后數(shù)據(jù)量在百萬(wàn)級(jí)別。單機(jī)處理這種量級(jí)的多次聚合不是不行但速度很慢而且頻繁的內(nèi)存排序容易把筆記本卡死。這正是引入 Spark 的充分理由把明細(xì)數(shù)據(jù)分布式存儲(chǔ)到 HDFS用 Spark 的 DataFrame API 快速完成多輪聚合。1.2 為什么技術(shù)上選了 Hadoop Spark Python 這套組合這個(gè)技術(shù)選型首先要考慮的是題目的教學(xué)意義。Hadoop 生態(tài)中的 HDFS 提供了分布式文件系統(tǒng)的概念NameNode 和 DataNode 的角色分工、數(shù)據(jù)塊的副本機(jī)制這些都是大數(shù)據(jù)入門躲不開的基礎(chǔ)知識(shí)。Spark 則是目前業(yè)界最主流的分布式計(jì)算引擎它用內(nèi)存計(jì)算替代了 MapReduce 反復(fù)落盤的機(jī)制在迭代計(jì)算場(chǎng)景下性能優(yōu)勢(shì)明顯。Python 則是用來(lái)做數(shù)據(jù)采集、清洗和統(tǒng)計(jì)分析的主力語(yǔ)言生態(tài)成熟編寫效率高。很多同學(xué)會(huì)問為什么不用純 Python 加 Pandas 直接分析答案是可以但這違背了題目想要考察的技術(shù)點(diǎn)。課程設(shè)計(jì)和畢業(yè)設(shè)計(jì)本質(zhì)上要展示你對(duì)整套大數(shù)據(jù)處理流程的掌握程度而不僅僅是一個(gè)分析結(jié)果。HDFS 上的原始數(shù)據(jù)落盤、Spark 任務(wù)的提交和監(jiān)控、YARN 對(duì)資源的調(diào)度這些過(guò)程本身就是加分項(xiàng)。另外一個(gè)很現(xiàn)實(shí)的原因是容錯(cuò)率。Hadoop 和 Spark 都是成熟的分布式框架本地用偽分布式模式跑批量計(jì)算非常穩(wěn)定不會(huì)因?yàn)閿?shù)據(jù)量大一點(diǎn)就 OOM。相比之下單機(jī) Pandas 在內(nèi)存吃緊的時(shí)候處理幾個(gè) G 的數(shù)據(jù)經(jīng)常直接崩潰尤其是做笛卡爾積類操作的時(shí)候。我在這類項(xiàng)目里有一條經(jīng)驗(yàn)數(shù)據(jù)量上了百萬(wàn)行以后凡是涉及多輪 groupBy 和 join 的活兒優(yōu)先交給 Spark凡是數(shù)據(jù)量不大但對(duì)靈活性要求高的活兒留在 Python 里處理。1.3 系統(tǒng)整體架構(gòu)從數(shù)據(jù)采集到可視化大屏的完整鏈路整個(gè)平臺(tái)的數(shù)據(jù)鏈路可以分成四層。采集層負(fù)責(zé)從 Riot 開發(fā)者平臺(tái)或公開數(shù)據(jù)集拉取排位賽對(duì)局?jǐn)?shù)據(jù)解析成結(jié)構(gòu)化 JSON 存入本地存儲(chǔ)層用 Hadoop HDFS 構(gòu)建偽分布式文件系統(tǒng)把原始 JSON 按天或按大區(qū)劃分成數(shù)據(jù)文件計(jì)算層交給 Spark讀取 HDFS 上的數(shù)據(jù)清洗后轉(zhuǎn)成 DataFrame執(zhí)行勝率計(jì)算、搭配挖掘、分位置聚合等任務(wù)結(jié)果寫成分析結(jié)果表和 Top 榜單展示層由 Python 的 Flask 框架提供數(shù)據(jù)查詢接口前端頁(yè)面通過(guò) ECharts 渲染大屏可視化。這里有一個(gè)架構(gòu)上的取舍值得說(shuō)清楚為什么計(jì)算結(jié)果不直接 feed 給前端頁(yè)面而是要通過(guò) Flask 再做一層接口原因是為了解耦。Spark 分析任務(wù)是批處理模式可能跑幾分鐘甚至更久而大屏展示是實(shí)時(shí)頁(yè)面請(qǐng)求不能等 Spark 跑完才響應(yīng)。把分析結(jié)果預(yù)先落地成 MySQL 表或者 JSON 文件前端只做展示查詢響應(yīng)速度能達(dá)到毫秒級(jí)。這其實(shí)也模擬了真實(shí)企業(yè)里離線計(jì)算 線上查詢的分層思路。2. Hadoop 和 Spark 在項(xiàng)目中的分工與協(xié)作2.1 HDFS 存儲(chǔ)層設(shè)計(jì)數(shù)據(jù)文件應(yīng)該怎么規(guī)劃HDFS 的核心思想是把大文件切成小塊分散存儲(chǔ)在多個(gè)節(jié)點(diǎn)上并對(duì)每個(gè)塊做冗余備份。本項(xiàng)目的偽分布式模式就相當(dāng)于只有一個(gè) DataNode 節(jié)點(diǎn)運(yùn)行在本機(jī)所以副本數(shù)一般設(shè)為 1 就夠。實(shí)際規(guī)劃 HDFS 目錄時(shí)我建議把原始數(shù)據(jù)、清洗后數(shù)據(jù)和計(jì)算結(jié)果分別存放在不同路徑下避免后續(xù)任務(wù)讀錯(cuò)文件。推薦的目錄規(guī)劃是/lol/raw/存放從 API 拉下來(lái)的 JSON 原始文件/lol/clean/存放經(jīng)過(guò)清洗之后的 Parquet 或 CSV/lol/result/存放分析結(jié)果集。這樣做的好處很明顯——Spark 作業(yè)可以只讀取指定層的數(shù)據(jù)也方便出錯(cuò)時(shí)單獨(dú)重算某一層。相比之下如果所有數(shù)據(jù)都堆在一個(gè)目錄里排查問題和任務(wù)失敗重跑的成本都會(huì)翻倍。HDFS 寫入時(shí)我習(xí)慣用-put命令上傳本地文件也可以用 Python 的hdfs庫(kù)直接對(duì)接 WebHDFS 接口。在 20 萬(wàn)場(chǎng)對(duì)局的規(guī)模下原始 JSON 文件總量一般在 5-10GB 左右HDFS 的默認(rèn)塊大小 128MB 對(duì)這個(gè)場(chǎng)景很合適。有一點(diǎn)需要特別注意HDFS 對(duì)小文件非常不友好如果采集程序把每場(chǎng)比賽單獨(dú)存成一個(gè) JSON一會(huì)兒就在目錄里產(chǎn)生幾萬(wàn)個(gè)小文件NameNode 內(nèi)存壓力很大后續(xù) Spark 讀取也會(huì)因?yàn)槲募斜磉^(guò)長(zhǎng)而變慢。我的做法是采集端每收集 5000 場(chǎng)對(duì)局就合并寫成一個(gè)文件Spark 讀取時(shí)的效率會(huì)明顯好很多。2.2 Spark 計(jì)算引擎為什么在這么多選型里選它Spark 在項(xiàng)目中的定位是計(jì)算引擎它從 HDFS 上讀數(shù)據(jù)然后做分布式計(jì)算。Spark Core 提供了彈性分布式數(shù)據(jù)集 RDD 的抽象Spark SQL 提供了更高層的 DataFrame/Dataset 接口后者有 Catalyst 優(yōu)化器對(duì)寫 SQL 和聚合類操作極其友好。在本項(xiàng)目里我用得最多的就是 Spark SQL。為什么 Spark 跑這批聚合任務(wù)比傳統(tǒng)方式快核心原因在于它的內(nèi)存計(jì)算模型。MapReduce 在每一輪任務(wù)結(jié)束后會(huì)把中間結(jié)果寫入磁盤下一輪任務(wù)再重新讀入在需要多次迭代的統(tǒng)計(jì)分析例如逐層計(jì)算組合勝率里磁盤 IO 開銷非常大。Spark 則盡量把中間結(jié)果留在內(nèi)存里跨越多個(gè) stage 時(shí)不需要反復(fù)落盤。用生活化的類比來(lái)解釋MapReduce 像是一個(gè)來(lái)回跑倉(cāng)庫(kù)搬運(yùn)貨物的工人每搬一趟都要把貨先存進(jìn)倉(cāng)庫(kù)再取出來(lái)Spark 像是直接在貨物旁邊搭了個(gè)臨時(shí)貨架同一批數(shù)據(jù)在多輪計(jì)算中都能快速訪問。本項(xiàng)目的核心計(jì)算模式是先做寬泛聚合再做精細(xì)挑選。先用一個(gè) SQL 查詢把所有明細(xì)數(shù)據(jù)按英雄和位置分組計(jì)算出場(chǎng)次數(shù)和勝場(chǎng)數(shù)然后基于結(jié)果集再做一輪 join算出英雄共現(xiàn)組合的勝率。這類多輪 join 和聚合在 Spark 里跑得很快實(shí)測(cè) 50 萬(wàn)行明細(xì)數(shù)據(jù)完成全部指標(biāo)計(jì)算不到 3 分鐘這比單機(jī) Pandas 滾動(dòng)計(jì)算要可靠得多。2.3 Python 在鏈路里的三個(gè)角色采集、粘合、展示Python 在這個(gè)項(xiàng)目里不是替代 Spark 的而是和 Spark 各司其職。首先數(shù)據(jù)采集腳本通常用 Python 寫因?yàn)?Riot API 返回的是 JSONPython 的requests加json庫(kù)處理起來(lái)最順手。采集腳本要處理限流、重試、斷點(diǎn)續(xù)采等問題這些用 Python 寫非常簡(jiǎn)單。其次Python 是連接各組件的主力。這里有一個(gè)容易被忽略的細(xì)節(jié)Spark 官方雖然提供了 Scala 和 Java 接口但是通過(guò) PySpark你可以直接用 Python 寫 DataFrame 操作并提交到 Spark 執(zhí)行。PySpark 只是在 Python 進(jìn)程和 JVM 之間加了一層通信橋真正執(zhí)行的還是 Spark 底層的分布式計(jì)算邏輯。所以項(xiàng)目的核心分析代碼可以用純 Python 風(fēng)格寫同時(shí)享受 Spark 的分布式能力。第三Flask 后端和可視化大屏的前端頁(yè)面也歸 Python 管。Flask 啟動(dòng)一個(gè)輕量 Web 服務(wù)定義幾個(gè)返回 JSON 的接口前端 AJAX 拉數(shù)據(jù)ECharts 渲染圖表。整個(gè)項(xiàng)目從數(shù)據(jù)采集、指標(biāo)計(jì)算到頁(yè)面展示全部統(tǒng)一在 Python 技術(shù)棧里代碼交付和維護(hù)都很順暢。3. 從零搭建 Hadoop 偽分布式與 Spark 的完整實(shí)操3.1 Hadoop 安裝配置偽分布式模式的關(guān)鍵步驟Hadoop 的安裝在整個(gè)項(xiàng)目里看似基礎(chǔ)但確實(shí)是新手耗時(shí)最多的環(huán)節(jié)。我在做這個(gè)項(xiàng)目時(shí)用的是 Hadoop 3.3 版本部署在 CentOS 7 虛擬機(jī)里本機(jī)開發(fā)環(huán)境是 Windows。下面梳理一下完整流程和我在配置過(guò)程中做的關(guān)鍵調(diào)整。第一步是安裝 JDK。Hadoop 3.x 要求 JDK 8 以上推薦 JDK8。記得配好JAVA_HOME和PATH環(huán)境變量后在終端里執(zhí)行java -version驗(yàn)證。第二步是配置 SSH 免密登錄這一項(xiàng)非常關(guān)鍵因?yàn)?Hadoop 的啟動(dòng)腳本需要通過(guò) SSH 連接到 localhost 啟動(dòng)各個(gè)守護(hù)進(jìn)程。我踩過(guò)的一個(gè)典型坑是ssh localhost都通了但啟動(dòng)集群后 DataNode 進(jìn)程不斷退出最后發(fā)現(xiàn)是免密配置不完整導(dǎo)致的。第三步是編輯三個(gè)核心配置文件。core-site.xml里設(shè)置默認(rèn)文件系統(tǒng)為hdfs://localhost:9000hdfs-site.xml里設(shè)置副本數(shù)為 1并配置 NameNode 的存儲(chǔ)目錄yarn-site.xml里配置資源調(diào)度相關(guān)參數(shù)。我習(xí)慣把這兩段配置直接寫在配置文件里就像下面這樣!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property /configuration!-- hdfs-site.xml -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/home/hadoop/data/name/value /property property namedfs.datanode.data.dir/name value/home/hadoop/data/data/value /property /configuration第四步是執(zhí)行格式化操作hdfs namenode -format。這一步我特別提醒一下格式化會(huì)把 NameNode 元數(shù)據(jù)清空如果集群里已經(jīng)有數(shù)據(jù)千萬(wàn)不要反復(fù)格式化。第五步就是啟動(dòng)集群start-dfs.sh和start-yarn.sh。啟動(dòng)后用jps命令檢查進(jìn)程看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager這五個(gè)進(jìn)程都在說(shuō)明偽分布式模式起來(lái)了。3.2 Spark 部署local 模式和 yarn 模式怎么選Spark 的安裝比 Hadoop 簡(jiǎn)單。它不依賴 Hadoop 的配置只需要下載編譯好的 tar 包解壓后改一個(gè)環(huán)境變量就行。但有一個(gè)容易踩的坑Spark 默認(rèn)會(huì)用系統(tǒng)里的JAVA_HOME如果你的 JDK 版本和 Hadoop 不匹配Spark 作業(yè)會(huì)報(bào)各種詭異的 JVM 錯(cuò)誤。Spark 有本地模式、獨(dú)立集群模式和 YARN 模式三種運(yùn)行方式。課程設(shè)計(jì)階段我建議先用本地模式跑通邏輯也就是local[*]參數(shù)它表示用本機(jī)所有 CPU 核心作為并行度不依賴 YARN 調(diào)度。這種方式調(diào)試速度快報(bào)錯(cuò)也直觀。項(xiàng)目收尾或演示階段再切到 YARN 模式提交展示 Spark 作業(yè)在 ResourceManager 里被調(diào)度執(zhí)行的過(guò)程這種演示效果會(huì)給答辯加分不少。實(shí)際啟動(dòng)時(shí)我習(xí)慣這樣配置環(huán)境變量export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export HADOOP_HOME/home/hadoop/hadoop-3.3.6 export SPARK_HOME/home/hadoop/spark-3.5.0-bin-hadoop3 export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$SPARK_HOME/bin export PYSPARK_PYTHON/usr/bin/python3其中PYSPARK_PYTHON用來(lái)指定 PySpark 驅(qū)動(dòng)使用的 Python 解釋器路徑。如果這個(gè)變量沒設(shè)置正確提交作業(yè)時(shí)會(huì)出現(xiàn) Python 解釋器不匹配的情況網(wǎng)上有大量同學(xué)在這個(gè)問題上卡住。3.3 Python 環(huán)境準(zhǔn)備依賴包和版本兼容Python 部分的準(zhǔn)備工作核心是版本對(duì)齊。我用的 Python 3.8安裝了pyspark、requests、pandas、flask和hdfs庫(kù)。這里需要特別注意pyspark版本要和你的 Spark 版本一致否則 API 會(huì)變。我的 Spark 是 3.5.0對(duì)應(yīng)的 PySpark 就用 3.5.0直接用 pip 安裝即可pip install pyspark3.5.0 pip install flask pandas requests在 Windows 本機(jī)開發(fā)時(shí)在命令行里寫 PySpark 代碼可以通過(guò)spark-submit提交到遠(yuǎn)程服務(wù)器也可以直接用pyspark交互式環(huán)境調(diào)試。我一般先在本地把 DataFrame 操作寫順了再整段搬到服務(wù)器上執(zhí)行這個(gè)開發(fā)節(jié)奏比較穩(wěn)。4. 數(shù)據(jù)采集與預(yù)處理分析結(jié)果的源頭保障4.1 數(shù)據(jù)從哪來(lái)API 采集與公開數(shù)據(jù)集的取舍做游戲數(shù)據(jù)分析的第一步永遠(yuǎn)是確認(rèn)數(shù)據(jù)來(lái)源。最規(guī)范的做法是使用 Riot 開發(fā)者平臺(tái)的官方 API 拉取比賽記錄但注冊(cè)開發(fā)者密鑰和調(diào)用限流比較繁瑣。另一種方式是使用公開的數(shù)據(jù)集比如 Kaggle 上有不少 LOL 排位賽對(duì)局?jǐn)?shù)據(jù)集包含比賽編號(hào)、召喚師信息、英雄 ID、位置、勝負(fù)等字段直接下載即可。我的做法是以公開數(shù)據(jù)集為主API 采集腳本為輔這樣既保證了數(shù)據(jù)量夠用也展示了數(shù)據(jù)采集能力。這里提醒一點(diǎn)如果從 API 采集一定要看接口文檔里rate limit的說(shuō)明單位時(shí)間的請(qǐng)求次數(shù)是受限的。我在采集腳本里加入了重試和限速邏輯控制請(qǐng)求頻率在每秒 5 次以內(nèi)避免觸發(fā)封禁。另外不要只采排位賽數(shù)據(jù)也不要只采一個(gè)分段的要考慮覆蓋面足夠代表性。4.2 核心字段說(shuō)明一場(chǎng)對(duì)局里能抽出哪些特征每場(chǎng)排位賽對(duì)局的數(shù)據(jù)結(jié)構(gòu)是嵌套 JSON。大致包含比賽時(shí)間戳、對(duì)局類型、游戲版本號(hào)、勝利方陣營(yíng)、失敗方陣營(yíng)每個(gè)陣營(yíng)下又有五個(gè)位置的信息。展開成結(jié)構(gòu)化表單后核心字段大概是這些字段名含義處理說(shuō)明game_id對(duì)局ID作為去重主鍵game_time比賽時(shí)間需從時(shí)間戳轉(zhuǎn)為日期格式tier段位區(qū)間如黃金、鉑金、鉆石用于分組position位置TOP、JUNGLE、MID、BOT、SUPPORTchampion_id英雄ID需關(guān)聯(lián)英雄名字映射表team_side陣營(yíng)藍(lán)方或紅方win是否獲勝1 表示勝 0 表示負(fù)英雄 ID 映射表是很容易遺漏的準(zhǔn)備工作。API 返回和大部分?jǐn)?shù)據(jù)集里存的都是數(shù)字 ID比如某英雄 ID 對(duì)應(yīng)暗裔劍魔、另一個(gè)對(duì)應(yīng)九尾妖狐如果前端要顯示英雄名必須在分析鏈路里提前把 ID 映射成中文名或英文名。我用一個(gè)靜態(tài)映射 JSON 文件來(lái)管理這個(gè)對(duì)應(yīng)關(guān)系這樣分析結(jié)果導(dǎo)出后可以直接用于展示。4.3 清洗規(guī)則與臟數(shù)據(jù)處理對(duì)局?jǐn)?shù)據(jù)雖然來(lái)源正規(guī)但依然存在不少臟數(shù)據(jù)。我在項(xiàng)目里總結(jié)的清洗規(guī)則主要有這幾條第一按game_id去重因?yàn)?API 重試可能導(dǎo)致同一場(chǎng)對(duì)局被拉取多次。第二處理缺失值有些棄權(quán)局在英雄字段上是空值直接過(guò)濾掉。第三段位信息統(tǒng)一歸一化比如韓服鉑金和大師30星這類不同表述統(tǒng)一映射到標(biāo)準(zhǔn)段位級(jí)別。第四時(shí)間戳轉(zhuǎn)成日期后按周聚合可以觀察版本更新前后的英雄勝率變化這一點(diǎn)對(duì)分析非常有價(jià)值。清洗完成的數(shù)據(jù)落盤到 HDFS 的/lol/clean/目錄以分區(qū)目錄存成 Parquet 格式。Parquet 是一種列式存儲(chǔ)格式它相比 JSON 和 CSV 有兩個(gè)優(yōu)勢(shì)壓縮比高、按列讀取快在 Spark 后續(xù)處理時(shí)能大幅減少 IO 開銷。5. 用 Spark 實(shí)現(xiàn)陣容分析的完整代碼過(guò)程5.1 讀取 HDFS 數(shù)據(jù)并構(gòu)建分析視圖PySpark 讀取 Parquet 數(shù)據(jù)非常直接。要注意的是如果你的 PySpark 代碼跑在本地模式spark.read.parquet(hdfs://localhost:9000/lol/clean/match.parquet)這種帶完整 HDFS URL 的寫法最穩(wěn)妥不會(huì)因?yàn)槟J(rèn)文件系統(tǒng)配置問題而讀錯(cuò)路徑。我通常這樣啟動(dòng) SparkSessionfrom pyspark.sql import SparkSession spark SparkSession.builder \ .appName(LoLMatchAnalysis) \ .master(local[*]) \ .config(spark.sql.shuffle.partitions, 50) \ .getOrCreate() df spark.read.parquet(hdfs://localhost:9000/lol/clean/match.parquet)spark.sql.shuffle.partitions這個(gè)參數(shù)在實(shí)際項(xiàng)目中特別重要。它控制聚合運(yùn)算時(shí)的分區(qū)數(shù)默認(rèn)值是 200意味著每個(gè)聚合操作都會(huì)產(chǎn)生 200 個(gè)分區(qū)。如果你的數(shù)據(jù)量只有幾十萬(wàn)行200 個(gè)分區(qū)反而會(huì)加劇任務(wù)調(diào)度開銷。調(diào)整為 50 之后小數(shù)據(jù)量下的運(yùn)行速度能快不少。5.2 核心分析一英雄勝率與出場(chǎng)率排名英雄基礎(chǔ)指標(biāo)是統(tǒng)計(jì)分析的起點(diǎn)。用 Spark SQL 或者 DataFrame 的groupBy操作一條語(yǔ)句就能完成勝率和出場(chǎng)率統(tǒng)計(jì)top_champion df.filter(df[position] ! ) \ .groupBy(champion_id, champion_name) \ .agg( func.count(champion_id).alias(play_count), func.round(func.sum(win) / func.count(champion_id), 3).alias(win_rate) ) \ .filter(func.col(play_count) 200) \ .orderBy(func.desc(win_rate)) top_champion.show(20)過(guò)濾play_count 200是統(tǒng)計(jì)分析里的常見手段它的目的是排除那些出場(chǎng)次數(shù)太少、樣本量不足的英雄這類英雄的勝率波動(dòng)大參考價(jià)值很低。比如一個(gè)英雄總共出場(chǎng) 3 場(chǎng)勝 3 場(chǎng)勝率 100%但其實(shí)說(shuō)明不了任何問題。樣本量閾值建議按照總數(shù)據(jù)量來(lái)調(diào)我 20 萬(wàn)場(chǎng)的數(shù)據(jù)里設(shè)為 200 比較合適。5.3 核心分析二位置維度的英雄優(yōu)先級(jí)位置維度的分析和整體分析邏輯幾乎一樣只是多了position分組條件。但它在業(yè)務(wù)上意義很大同一個(gè)英雄在不同位置的勝率表現(xiàn)差別可能非常大典型例子是某些戰(zhàn)士英雄打上單和打野是兩種打法整體勝率被平均后就沒有參考價(jià)值了。按位置統(tǒng)計(jì)后可以為每個(gè)位置生成一份優(yōu)先推薦英雄榜單這也是陣容推薦功能的基礎(chǔ)。pos_stats df.groupBy(position, champion_name) \ .agg( func.count(champion_name).alias(pick_count), func.round(func.avg(win), 3).alias(win_rate) ) \ .withColumn(rank, func.row_number().over( Window.partitionBy(position).orderBy(func.desc(win_rate)) )) \ .filter(func.col(pick_count) 100) pos_stats.filter(func.col(rank) 5).show()窗口函數(shù)row_number()在這里派上了大用場(chǎng)。它按位置分組后從勝率最高的英雄開始編號(hào)取前 5 名就是該位置的 Top 5。這種寫法比先按位置分開查、再手動(dòng)排序要簡(jiǎn)潔得多。5.4 核心分析三英雄搭配組合挖掘英雄搭配組合是本項(xiàng)目最有看點(diǎn)的分析。思路是找到同一陣營(yíng)內(nèi)部?jī)蓛捎⑿鄣慕M合統(tǒng)計(jì)組合出現(xiàn)的場(chǎng)次和勝率勝率高的組合就是值得關(guān)注的強(qiáng)勢(shì)體系。實(shí)現(xiàn)的核心是自連接也就是 DataFrame 自己 join 自己。我把一場(chǎng)比賽的五個(gè)人拆成長(zhǎng)表每個(gè)英雄一條行然后alias成兩份按game_id和team_side關(guān)聯(lián)起來(lái)并排除champion_name相同的組合就拿到了所有共現(xiàn)對(duì)兒detail df.select(game_id, team_side, win, champion_name, position) pair_df detail.alias(a) \ .join(detail.alias(b), (func.col(a.game_id) func.col(b.game_id)) (func.col(a.team_side) func.col(b.team_side)) (func.col(a.champion_name) func.col(b.champion_name)) ) \ .select( func.col(a.champion_name).alias(champ_a), func.col(b.champion_name).alias(champ_b), func.col(a.win).alias(win) ) \ .groupBy(champ_a, champ_b) \ .agg( func.count(champ_a).alias(pair_count), func.round(func.sum(win) / func.count(champ_a), 3).alias(pair_win_rate) ) \ .filter(func.col(pair_count) 50) \ .orderBy(func.desc(pair_win_rate))這里用func.col(a.champion_name) func.col(b.champion_name)做 join 條件是一個(gè)避免重復(fù)組合的技巧。如果不加這個(gè)條件組合盲僧亞索和亞索盲僧會(huì)分別統(tǒng)計(jì)成兩條記錄后續(xù)展示時(shí)會(huì)混亂。按字符串大小比較之后每一對(duì)英雄只會(huì)出現(xiàn)一次。執(zhí)行效率方面這種自連接在 Spark 中會(huì)觸發(fā)一次 shuffle但在這個(gè)量級(jí)完全可以接受。5.5 計(jì)算結(jié)果的落地導(dǎo)出為報(bào)表數(shù)據(jù)所有分析結(jié)果最終要導(dǎo)出到后端可讀取的位置。我的做法是寫到 MySQL 數(shù)據(jù)庫(kù)中用 PySpark 的jdbc連接器直接寫入也可以用toPandas()轉(zhuǎn)成 Pandas DataFrame 再通過(guò) SQLAlchemy 寫入。前者適合大數(shù)據(jù)量后者簡(jiǎn)單直接。課程設(shè)計(jì)場(chǎng)景下數(shù)據(jù)量不大toPandas()方案更省事top_champion_df top_champion.toPandas() top_champion_df.to_csv(/home/lol/result/top_champion.csv, indexFalse)MySQL 表結(jié)構(gòu)按照分析維度設(shè)計(jì)champion_rank表存英雄總榜position_rank表存分位置榜單pair_rank表存組合榜單。每個(gè)表帶上update_time字段方便大屏展示時(shí)標(biāo)記數(shù)據(jù)更新時(shí)間。6. 可視化大屏從數(shù)據(jù)到可讀性強(qiáng)的展示6.1 大屏布局設(shè)計(jì)信息層次決定觀看體驗(yàn)可視化大屏的布局會(huì)直接影響評(píng)委的觀看體驗(yàn)。我采用的是經(jīng)典的三欄式布局頂部是整體數(shù)據(jù)概覽中間是英雄勝率 TOP 榜單左右兩側(cè)分別放位置推薦和組合分析。整體配色用深色背景配合藍(lán)紫漸變的高亮圖表視覺效果偏向科技感。大屏頁(yè)面的數(shù)據(jù)全部來(lái)自 Flask 接口。Flask 讀取 MySQL 或者 CSV 文件后返回 JSON前端 ECharts 通過(guò)fetch拉取。這里要注意一個(gè)前后端聯(lián)調(diào)問題Flask 默認(rèn)開啟的CORS不支持跨域請(qǐng)求如果前端頁(yè)面和 Flask 端口不一致瀏覽器會(huì)攔截接口返回。我在 Flask 里設(shè)置了一個(gè)全局響應(yīng)頭允許所有來(lái)源的跨域請(qǐng)求。app.after_request def add_cors_headers(resp): resp.headers[Access-Control-Allow-Origin] * return resp6.2 核心圖表類型選擇什么場(chǎng)景配什么圖大屏的圖表選型是我覺得最能體現(xiàn)項(xiàng)目完成度的地方。英雄勝率排行用橫向條形圖最直觀一目了然地看出勝負(fù)率高低的優(yōu)劣差距注意條形圖的英雄名稱過(guò)長(zhǎng)時(shí)要啟用豎排標(biāo)簽。組合分析適合用帶權(quán)重的關(guān)系圖兩個(gè)英雄之間連線越粗代表出場(chǎng)次數(shù)越多連線顏色偏向暖色代表勝率越高這樣玩家一眼就能看出哪些體系勝率高。分位置的推薦榜單我用了雷達(dá)圖或者分組柱狀圖橫軸是五個(gè)位置縱軸是勝率同一位置內(nèi)多個(gè)英雄用不同顏色區(qū)分。頂部概覽區(qū)域放三個(gè)指標(biāo)卡累計(jì)分析對(duì)局?jǐn)?shù)、平均對(duì)局時(shí)長(zhǎng)、版本強(qiáng)勢(shì)英雄數(shù)量。6.3 大屏數(shù)據(jù)刷新的聯(lián)動(dòng)機(jī)制大屏不能做成靜態(tài)頁(yè)面。我加了一個(gè)定時(shí)刷新機(jī)制前端每隔 60 秒請(qǐng)求一次接口檢查數(shù)據(jù)的update_time是否有變化有新數(shù)據(jù)就無(wú)感刷新圖表。這個(gè)功能雖然簡(jiǎn)單但在答辯演示時(shí)很加分因?yàn)榭梢袁F(xiàn)場(chǎng)跑一次 Spark 任務(wù)看到大屏數(shù)據(jù)實(shí)時(shí)變化整個(gè)項(xiàng)目的完整閉環(huán)感一下子就出來(lái)了。7. 開發(fā)過(guò)程中遇到的經(jīng)典問題與排查經(jīng)驗(yàn)7.1 Hadoop 啟動(dòng)相關(guān)的坑DataNode進(jìn)程一直啟動(dòng)不起來(lái)的排查思路必須清楚。首先用jps看進(jìn)程在不在不在的話直接查看logs/hadoop-hadoop-datanode-主機(jī)名.log日志文件。常見原因是dfs.datanode.data.dir目錄沒有創(chuàng)建成功或者目錄權(quán)限不對(duì)。另一個(gè)高頻問題是NameNode格式化之后DataNode 的注冊(cè)信息不一致啟動(dòng)時(shí)也會(huì)被拒絕。解決辦法非常簡(jiǎn)單但容易忘把 Hadoop 的臨時(shí)目錄和數(shù)據(jù)目錄整個(gè)刪除重新格式化后啟動(dòng)。我在實(shí)際開發(fā)中遇到過(guò)一個(gè)更隱蔽的問題虛擬機(jī)的內(nèi)存只有 2GB啟動(dòng) Hadoop 加 Spark 后內(nèi)存吃滿NameNode被系統(tǒng)殺掉日志里能看到明顯的 OOM 記錄。后來(lái)給虛擬機(jī)漲到 4GB并在hadoop-env.sh里限制每個(gè)進(jìn)程的 JVM 堆大小這個(gè)問題就再?zèng)]出現(xiàn)過(guò)。7.2 Spark 作業(yè)報(bào)錯(cuò)和性能問題PySpark 最常見的報(bào)錯(cuò)是Python in worker has different version這是PYSPARK_PYTHON環(huán)境變量沒有正確指向服務(wù)器上的 Python 解釋器導(dǎo)致的。另外Executor lost和Job aborted due to stage failure這類錯(cuò)誤很多時(shí)候不是代碼邏輯有問題而是內(nèi)存配置不足。在提交任務(wù)時(shí)加--executor-memory 4g --driver-memory 2g參數(shù)大部分情況下能解決。性能調(diào)優(yōu)方面的一個(gè)心得是盡量避免collect()拉取大數(shù)據(jù)量到本地。有同學(xué)習(xí)慣在 PySpark 里用.collect()把所有結(jié)果變成 Python 列表再做剩余處理數(shù)據(jù)量一大內(nèi)存就爆了。正確的做法是讓 Spark 完成盡可能多的計(jì)算最后只用show()或toPandas()導(dǎo)出小體量的聚合結(jié)果。7.3 可視化展示中的問題大屏頁(yè)面顯示空白百分之八十是因?yàn)?ECharts 圖表寬度和高度沒有初始化。這個(gè)問題說(shuō)大不大但調(diào)試起來(lái)很煩。還有中文亂碼問題Flask 返回 JSON 時(shí)需要確保數(shù)據(jù)源文件用 UTF-8 編碼讀取 CSV 時(shí)顯式指定encodingutf-8。前端展示中文英雄名時(shí)如果接口里已經(jīng)亂碼改前端沒有意義必須回到數(shù)據(jù)分析階段解決編碼問題。我把這些高頻問題整理成一個(gè)排查速查表方便遇到同類情況時(shí)快速對(duì)照現(xiàn)象可能原因解決辦法DataNode 啟動(dòng)后立即退出數(shù)據(jù)目錄權(quán)限不對(duì)檢查并創(chuàng)建 hdfs-site 配置的目錄權(quán)限NameNode 無(wú)法啟動(dòng)格式化元數(shù)據(jù)損壞清除臨時(shí)目錄重新格式化Spark 作業(yè) Python 環(huán)境崩潰PYSPARK_PYTHON 路徑錯(cuò)誤在 spark-env.sh 中顯式指定 Python 路徑Spark 作業(yè)內(nèi)存溢出默認(rèn)內(nèi)存配置不足提交時(shí)加內(nèi)存參數(shù)調(diào)低分區(qū)數(shù)大屏圖表不顯示前后端跨域問題Flask 添加 CORS 響應(yīng)頭中文顯示為亂碼文件編碼不一致統(tǒng)一讀寫時(shí)使用 UTF-8 編碼8. 項(xiàng)目實(shí)操的額外收獲與心得整個(gè)項(xiàng)目完整做下來(lái)我投入的時(shí)間大約是三周加一個(gè)周末的集中開發(fā)。第一周用來(lái)搭建 Hadoop 和 Spark 環(huán)境、跑通數(shù)據(jù)采集第二周集中寫 Spark 分析代碼此時(shí)是最容易焦慮的階段因?yàn)榄h(huán)境問題、版本問題會(huì)同時(shí)冒出來(lái)第三周做可視化大屏和整體調(diào)試這個(gè)階段其實(shí)成就感最強(qiáng)因?yàn)閿?shù)據(jù)開始變成看得見的圖表。我個(gè)人做這類大數(shù)據(jù)綜合項(xiàng)目最深的體會(huì)是不要試圖一步到位把環(huán)境搭完美再寫代碼而是先打通最簡(jiǎn)路徑。比如先不管 YARN用 Spark 本地模式直接讀本地 CSV 把分析代碼跑通再逐步接入 HDFS、切換到 YARN 模式。循序漸進(jìn)的好處在于整個(gè)項(xiàng)目有多個(gè) checkpoint每一次成功都會(huì)給你往前推進(jìn)的信心。數(shù)據(jù)平臺(tái)項(xiàng)目最大的敵人不是某一個(gè)復(fù)雜的技術(shù)點(diǎn)而是多組件協(xié)作時(shí)那種哪個(gè)環(huán)節(jié)都不確定哪里出了問題的失控感。如果你也準(zhǔn)備做同類型的題目建議在規(guī)劃時(shí)就把源碼、文檔、調(diào)試記錄三樣產(chǎn)物同步整理。光有能跑的代碼不夠文檔里要把每一步操作命令、每個(gè)核心算法的設(shè)計(jì)思路寫清楚調(diào)試記錄里留下真實(shí)遇到問題和解決方式的截圖或日志。這不僅是答辯時(shí)的加分項(xiàng)也是對(duì)整個(gè)項(xiàng)目過(guò)程最好的復(fù)盤。我自己做完這個(gè)項(xiàng)目后再回看最初的版本最大的改變是學(xué)會(huì)了用分層的眼光看待一個(gè)完整系統(tǒng)——采集、存儲(chǔ)、計(jì)算、展示各管一段每個(gè)模塊都可以被單獨(dú)替換和優(yōu)化這和大數(shù)據(jù)生態(tài)本身的設(shè)計(jì)哲學(xué)是一致的。