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