每年畢業(yè)設(shè)計(jì)定題季總能在各種群里看到類(lèi)似提問(wèn)“有沒(méi)有不卷、能落地、答辯還不拉胯的題目”最后我定了“基于大數(shù)據(jù)的游戲數(shù)據(jù)分析可視化系統(tǒng)”。做完回頭看這個(gè)題目的適配度確實(shí)很高——有業(yè)務(wù)場(chǎng)景、有數(shù)據(jù)體量、有完整鏈路最關(guān)鍵的是做出來(lái)能直接呈現(xiàn)在大屏上答辯時(shí)不愁沒(méi)東西講。這篇文章就不繞圈子了直接把這個(gè)項(xiàng)目的完整思路和關(guān)鍵實(shí)現(xiàn)整理出來(lái)選題怎么定、技術(shù)棧怎么取舍、數(shù)據(jù)管道怎么搭、可視化大屏做了哪些核心圖表、代碼里最值得看的部分在哪里。如果你現(xiàn)在正在糾結(jié)畢設(shè)題目或者想快速上手一套可復(fù)現(xiàn)的大數(shù)據(jù)可視化項(xiàng)目這篇就當(dāng)一份簡(jiǎn)化版項(xiàng)目文檔來(lái)讀。1. 項(xiàng)目緣起為什么“游戲數(shù)據(jù)”是我最終定下的畢設(shè)方向1.1 選題時(shí)給自己定的三條標(biāo)準(zhǔn)開(kāi)始選題之前我先給自己列了一個(gè)清單避免在幾十個(gè)候選方向里來(lái)回?fù)u擺。第一要有業(yè)務(wù)感。評(píng)委坐在下面不用聽(tīng)你講三分鐘背景就能明白“這套系統(tǒng)到底是拿來(lái)干什么的”。第二技術(shù)棧要有展示面。不能只是一個(gè)增刪改查最好能把數(shù)據(jù)采集、清洗、計(jì)算、存儲(chǔ)、可視化這條鏈路串起來(lái)答辯時(shí)才有足夠多的技術(shù)點(diǎn)可以講。第三成果要可感知。最終交付的應(yīng)是一個(gè)能打開(kāi)頁(yè)面就能看的效果而不是一堆命令行輸出。拿這三條標(biāo)準(zhǔn)去篩選項(xiàng)電商用戶(hù)行為分析太多人做了答辯撞車(chē)嚴(yán)重環(huán)境監(jiān)測(cè)類(lèi)數(shù)據(jù)不好拿容易顯得項(xiàng)目是“編”的社交網(wǎng)絡(luò)分析又偏算法工作量不好控制。而游戲數(shù)據(jù)分析是少有的、能把這三條全部滿(mǎn)足的方向。1.2 游戲日志為什么自帶“大數(shù)據(jù)”氣質(zhì)真正動(dòng)手之后我才有一種實(shí)感游戲日志太適合用來(lái)體現(xiàn)大數(shù)據(jù)場(chǎng)景了。一個(gè)玩家在線(xiàn)一小時(shí)可能產(chǎn)生幾十條甚至上百條事件記錄。登錄、退出、進(jìn)入關(guān)卡、通關(guān)、失敗、購(gòu)買(mǎi)道具、點(diǎn)開(kāi)活動(dòng)頁(yè)面、與NPC交互每一種行為都是一條日志而且每條日志自帶時(shí)間戳、設(shè)備類(lèi)型、渠道來(lái)源、關(guān)卡編號(hào)等信息。游戲日志天然是高密度的用戶(hù)行為流數(shù)據(jù)量膨脹速度遠(yuǎn)超普通業(yè)務(wù)表。這個(gè)特點(diǎn)帶來(lái)的直接好處是你不需要編造幾千萬(wàn)條假數(shù)據(jù)來(lái)?yè)螆?chǎng)面按真實(shí)玩家行為規(guī)律生成幾百萬(wàn)條模擬日志就已經(jīng)能讓Spark出現(xiàn)可感知的計(jì)算過(guò)程。同時(shí)日志里的字段豐富后續(xù)想從哪個(gè)維度分析都有原料可查。提示做同類(lèi)項(xiàng)目時(shí)不必追求所謂“海量”數(shù)據(jù)。只要數(shù)據(jù)量能讓Spark跑出幾秒到十幾秒的計(jì)算過(guò)程再配合一套貼近真實(shí)世界規(guī)律的模擬數(shù)據(jù)答辯效果就已經(jīng)足夠。模擬數(shù)據(jù)生成腳本我也放在源碼包里面了。1.3 先做減法這個(gè)系統(tǒng)不做什么畢設(shè)最大的坑是前期想得太大。我當(dāng)時(shí)列過(guò)很多“宏偉計(jì)劃”實(shí)時(shí)流計(jì)算、用戶(hù)畫(huà)像、排行榜、個(gè)性化推薦。但冷靜下來(lái)之后我給自己做了一個(gè)邊界收縮只保留三件事離線(xiàn)數(shù)據(jù)采集與清洗核心指標(biāo)聚合計(jì)算可視化大屏展示三條鏈路串起來(lái)每一件事都有明確交付物。實(shí)時(shí)計(jì)算和推薦算法不是不能做而是它們會(huì)大幅拉長(zhǎng)調(diào)試周期。尤其是實(shí)時(shí)計(jì)算環(huán)境配置和前端聯(lián)調(diào)的成本不比離線(xiàn)鏈路低。畢設(shè)的核心邏輯是“主鏈路穩(wěn)定交付加分為輔”這一點(diǎn)大家一定要想清楚。2. 系統(tǒng)架構(gòu)與技術(shù)選型每個(gè)組件背后的一次取舍2.1 整條數(shù)據(jù)流鏈路是什么樣系統(tǒng)的整體流程是這樣的游戲服務(wù)器產(chǎn)出半結(jié)構(gòu)化日志文件由模擬腳本或采集程序?qū)懭隒SV文本Spark離線(xiàn)任務(wù)讀取日志完成清洗、去重、聚合計(jì)算結(jié)果寫(xiě)回MySQL后端層提供JSON查詢(xún)接口前端頁(yè)面調(diào)用接口并交給ECharts渲染成大屏。這條鏈路沒(méi)有引入Kafka沒(méi)有搞HDFSHive核心大數(shù)據(jù)處理就是Spark。原因很簡(jiǎn)單畢設(shè)展示求穩(wěn)集群復(fù)雜度越高現(xiàn)場(chǎng)出問(wèn)題的概率就越大。把Spark這條主線(xiàn)做扎實(shí)足夠體現(xiàn)大數(shù)據(jù)處理能力。2.2 技術(shù)選型對(duì)照表環(huán)節(jié)最終選用方案?jìng)溥x方案選型理由日志采集Python腳本模擬生成Flume / Filebeat畢設(shè)重心在后續(xù)分析采集環(huán)節(jié)能自圓其說(shuō)即可離線(xiàn)計(jì)算PySpark本地模式pandas / Hadoop MRSpark能體現(xiàn)大數(shù)據(jù)主題且PySpark語(yǔ)法貼近pandas數(shù)據(jù)倉(cāng)庫(kù)MySQL 8.0HBase / ClickHouse運(yùn)維成本低、答辯現(xiàn)場(chǎng)穩(wěn)定百萬(wàn)級(jí)數(shù)據(jù)完全扛得住接口層FlaskDjango / FastAPIFlask輕量單文件即可把接口寫(xiě)清楚前端可視化ECharts大屏Vue全家桶 / 阿里DataV上手成本低圖表類(lèi)型全配色自定義能力強(qiáng)這一整套選型背后的核心邏輯可以濃縮成一句話(huà)在技術(shù)展示效果與工作量可控之間取一個(gè)平衡點(diǎn)。每個(gè)組件都回答一個(gè)問(wèn)題——它是不是當(dāng)前鏈路里最合適的那一個(gè)。2.3 Spark在項(xiàng)目里到底承擔(dān)了哪些計(jì)算很多人一聽(tīng)“大數(shù)據(jù)”就想到Hadoop或Flink但對(duì)本科階段來(lái)說(shuō)PySpark已經(jīng)是一個(gè)很合適的切入點(diǎn)。Spark支持直接在Python環(huán)境里寫(xiě)DataFrame操作熟悉pandas的人遷移成本很低且本地模式部署幾乎零額外開(kāi)銷(xiāo)。我在項(xiàng)目里讓Spark完成三類(lèi)計(jì)算明細(xì)日志的清洗與去重輸出規(guī)范化的中間數(shù)據(jù)按天、按渠道、按設(shè)備的多維聚合產(chǎn)出DAU、新增、充值金額等指標(biāo)留存率、通關(guān)率等需要跨天計(jì)算的指標(biāo)配置上直接使用spark-submit在本地模式運(yùn)行不需要部署YARN集群。數(shù)據(jù)量級(jí)在百萬(wàn)級(jí)時(shí)計(jì)算耗時(shí)大概幾秒到十幾秒演示的時(shí)候節(jié)奏剛好。2.4 為什么最終沒(méi)有把組件堆滿(mǎn)偶爾也會(huì)看到同學(xué)把項(xiàng)目的技術(shù)點(diǎn)寫(xiě)得像一份“中間件博覽會(huì)”Redis緩存、Kafka實(shí)時(shí)層、ElasticSearch檢索、ClickHouse查詢(xún)引擎……但導(dǎo)師給過(guò)我一句很實(shí)在的建議畢設(shè)展示的是“你有沒(méi)有把一個(gè)課題完整做完”而不是“你聽(tīng)說(shuō)過(guò)多少框架”。每多一個(gè)組件就多一圈可能出錯(cuò)的地方也多一輪需要準(zhǔn)備的解釋成本。我在做技術(shù)評(píng)審的時(shí)候最常被問(wèn)到的反而是“為什么不用XX”。只要你能把這套選型邏輯講通評(píng)委反而會(huì)覺(jué)得你有判斷力而不是盲目堆技術(shù)。最終我只在接口層加了一層進(jìn)程內(nèi)緩存用很小的成本避免了重復(fù)SQL查詢(xún)其余沒(méi)有額外引入組件。3. 數(shù)據(jù)管道的構(gòu)建從游戲日志到結(jié)構(gòu)化業(yè)務(wù)表3.1 日志事件與字段模型設(shè)計(jì)日志是數(shù)據(jù)分析的原料字段設(shè)計(jì)直接決定后面能算哪些指標(biāo)所以這一步值得多花時(shí)間。我采用的是豎線(xiàn)分隔的純文本CSV格式一行一條事件記錄字段結(jié)構(gòu)如下user_id玩家唯一標(biāo)識(shí)event_type行為類(lèi)型login、logout、level_start、level_win、level_fail、recharge 等event_ts事件時(shí)間戳精確到秒device設(shè)備類(lèi)型iOS / Android / PCchannel渠道來(lái)源應(yīng)用商店、官網(wǎng)、效果廣告等level_id關(guān)卡編號(hào)非關(guān)卡事件為空duration_sec行為耗時(shí)主要用于登錄會(huì)話(huà)recharge_amount充值金額僅在充值事件中賦值extra_json預(yù)留擴(kuò)展字段這種寬表式日志設(shè)計(jì)的好處是模擬生成和后續(xù)分析都很方便不需要多次join多張明細(xì)表。3.2 模擬數(shù)據(jù)生成的關(guān)鍵思路我最初想直接用現(xiàn)成公開(kāi)數(shù)據(jù)集但發(fā)現(xiàn)要么跟游戲業(yè)務(wù)無(wú)關(guān)要么字段不夠用無(wú)法支撐自己想分析的指標(biāo)。最后自己寫(xiě)了一個(gè)生成腳本按照現(xiàn)實(shí)中游戲的運(yùn)營(yíng)規(guī)律去造數(shù)日活躍用戶(hù)呈“工作日低、周末高”的周期性波動(dòng)每日活躍量在基準(zhǔn)值上下加隨機(jī)噪聲充值金額呈長(zhǎng)尾分布少數(shù)高付費(fèi)玩家貢獻(xiàn)大部分流水晚上8點(diǎn)到11點(diǎn)是一天中的活躍高峰這樣生成的數(shù)據(jù)有兩個(gè)好處一方面帶隨機(jī)性能驗(yàn)證清洗邏輯是不是真的生效另一方面大屏上的趨勢(shì)線(xiàn)有自然的起伏不會(huì)像均勻隨機(jī)數(shù)據(jù)那樣平淡無(wú)奇。3.3 Spark離線(xiàn)清洗的完整規(guī)則拿到原始日志后我先做數(shù)據(jù)清洗整理出四條硬性規(guī)則按“user_id event_type event_ts”三重維度去重防止上游重復(fù)發(fā)送剔除用戶(hù)ID、事件類(lèi)型、時(shí)間戳為空的記錄用白名單機(jī)制校驗(yàn)事件類(lèi)型非法事件直接丟棄對(duì)時(shí)長(zhǎng)、金額、關(guān)卡號(hào)等數(shù)值字段做邊界檢查超出合理區(qū)間的視為臟數(shù)據(jù)清洗完的數(shù)據(jù)再進(jìn)入聚合階段。聚合維度包括日期、渠道、設(shè)備產(chǎn)出DAU、平均在線(xiàn)時(shí)長(zhǎng)、各關(guān)卡通過(guò)率等關(guān)鍵指標(biāo)。我按日分區(qū)輸出成parquet格式的中間數(shù)據(jù)后面再寫(xiě)一個(gè)獨(dú)立任務(wù)把結(jié)果刷進(jìn)MySQL。這種“中間層”設(shè)計(jì)更接近真實(shí)生產(chǎn)環(huán)境但又不會(huì)把復(fù)雜度拉到失控。核心清洗代碼大致長(zhǎng)這樣from pyspark.sql import SparkSession from pyspark.sql.functions import col, to_date, countDistinct, sum spark SparkSession.builder \ .appName(GameLogETL) \ .config(spark.sql.shuffle.partitions, 4) \ .getOrCreate() # 讀取原始日志 raw spark.read \ .option(header, True) \ .option(inferSchema, True) \ .csv(data/game_logs/*.csv) # 第一步去重 dedup raw.dropDuplicates([user_id, event_type, event_ts]) # 第二步基礎(chǔ)過(guò)濾 clean dedup.filter( col(user_id).isNotNull() (col(user_id) ! ) col(event_ts).isNotNull() col(event_type).isin([login, logout, level_start, level_win, level_fail, recharge]) ) # 第三步歸一化數(shù)值字段 clean clean.filter( (col(duration_sec).isNull() | (col(duration_sec).cast(int) 0)) (col(recharge_amount).isNull() | (col(recharge_amount).cast(double) 0)) ) # 第四步生成日期分區(qū)鍵并輸出中間結(jié)果 clean clean.withColumn(dt, to_date(col(event_ts))) clean.write.mode(overwrite) \ .partitionBy(dt) \ .parquet(data/clean_logs)這段代碼基本就是整套ETL的骨架。后續(xù)從parquet讀回?cái)?shù)據(jù)后再做聚合整體邏輯更清晰排查問(wèn)題也容易定位。3.4 MySQL表結(jié)構(gòu)設(shè)計(jì)作為最終存儲(chǔ)MySQL采用“明細(xì)表 聚合表”雙層設(shè)計(jì)。明細(xì)表主要用于回查和異常校驗(yàn)大屏主要查詢(xún)聚合表響應(yīng)速度快。核心的日聚合表建表語(yǔ)句如下CREATE TABLE daily_agg ( dt VARCHAR(10) NOT NULL COMMENT 日期, dau INT NOT NULL COMMENT 日活躍用戶(hù)數(shù), new_users INT NOT NULL DEFAULT 0 COMMENT 新增用戶(hù), avg_online_sec INT NOT NULL DEFAULT 0 COMMENT 平均在線(xiàn)時(shí)長(zhǎng)(秒), recharge_amount DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT 充值總金額, recharge_orders INT NOT NULL DEFAULT 0 COMMENT 充值訂單數(shù), PRIMARY KEY (dt) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT按日聚合指標(biāo)表;業(yè)務(wù)維度表則針對(duì)渠道、設(shè)備、關(guān)卡這些分析維度單獨(dú)建表并建好索引。在我的測(cè)試數(shù)據(jù)量級(jí)下大屏接口查詢(xún)基本都在幾十毫秒內(nèi)返回完全不需要上更重的組件。4. 可視化大屏現(xiàn)場(chǎng)“展示力”最強(qiáng)的部分4.1 核心指標(biāo)體系怎么定可視化絕對(duì)不能只堆圖表背后一定要有指標(biāo)邏輯。大屏最終圍繞“用戶(hù)生命周期”這條主線(xiàn)來(lái)組織覆蓋拉新、活躍、留存、付費(fèi)、闖關(guān)五個(gè)環(huán)節(jié)拉新新增用戶(hù)數(shù)、各渠道新增占比活躍DAU、MAU、平均在線(xiàn)時(shí)長(zhǎng)留存次日留存率、7日留存率付費(fèi)充值總金額、充值訂單數(shù)、ARPPU闖關(guān)關(guān)卡通過(guò)率排行、平均闖關(guān)次數(shù)每一個(gè)指標(biāo)都不是隨便加的都是在回答“游戲運(yùn)營(yíng)關(guān)心的核心問(wèn)題”。4.2 大屏布局與圖表選型大屏頁(yè)面采用1350×768比例從上到下分三個(gè)區(qū)域。頂部是標(biāo)題欄和四個(gè)KPI卡片把DAU、累計(jì)充值金額、平均在線(xiàn)時(shí)長(zhǎng)、新增用戶(hù)這四個(gè)最核心的數(shù)字放在頁(yè)面第一屏。中間區(qū)域放日活躍趨勢(shì)折線(xiàn)圖和充值金額柱狀圖共用同一橫軸方便對(duì)比活躍人數(shù)和充值收入的時(shí)間對(duì)應(yīng)關(guān)系。底部左側(cè)是渠道占比玫瑰圖底部中間是省份熱力地圖底部右側(cè)放關(guān)卡通過(guò)率排行榜。為什么選這些圖表類(lèi)型因?yàn)槊恳环N圖都有不可替代的場(chǎng)景屬性趨勢(shì)圖看變化餅圖看占比地圖看地域分布排行榜看結(jié)構(gòu)化對(duì)比。答辯時(shí)不建議用花哨的3D圖或雷達(dá)圖強(qiáng)行加戲信息能否被一眼看懂是第一位。4.3 圖表聯(lián)動(dòng)是怎么實(shí)現(xiàn)的為了讓大屏不是靜態(tài)演示我加了兩個(gè)輕量級(jí)聯(lián)動(dòng)效果。第一個(gè)聯(lián)動(dòng)來(lái)自KPI卡片。點(diǎn)擊“充值金額”卡片中間趨勢(shì)圖立即切換為充值趨勢(shì)點(diǎn)擊“DAU”卡片圖表切換為活躍趨勢(shì)。實(shí)現(xiàn)原理很簡(jiǎn)單給每個(gè)卡片綁上click事件修改一個(gè)全局變量再調(diào)用ECharts實(shí)例的setOption覆蓋series數(shù)據(jù)。第二個(gè)聯(lián)動(dòng)在渠道餅圖和地圖之間。點(diǎn)擊餅圖中的某個(gè)渠道地圖立即過(guò)濾出該渠道用戶(hù)所在省份的熱力分布。實(shí)現(xiàn)方式是監(jiān)聽(tīng)餅圖的click事件拿到渠道名后向后端請(qǐng)求一次帶條件的過(guò)濾接口拿到新數(shù)據(jù)后更新地圖series即可。這兩個(gè)聯(lián)動(dòng)并不復(fù)雜但現(xiàn)場(chǎng)展示時(shí)非常加“交互分”。4.4 答辯演示的講故事節(jié)奏答辯的時(shí)候建議不要從頭到尾念指標(biāo)而是按這個(gè)節(jié)奏來(lái)先花40秒介紹KPI卡片講“這個(gè)系統(tǒng)能看到每一天的新增、活躍、付費(fèi)基本面”然后打開(kāi)趨勢(shì)圖指出某一段時(shí)間的明顯波動(dòng)接著點(diǎn)開(kāi)渠道餅圖聯(lián)動(dòng)地圖講一講地域投放差異最后落到關(guān)卡通過(guò)率排行榜引出運(yùn)營(yíng)結(jié)論比如“選擇某個(gè)特定關(guān)卡通關(guān)率突然下降說(shuō)明難度曲線(xiàn)需要調(diào)整”。這套講法會(huì)讓評(píng)委覺(jué)得你做的不是靜態(tài)報(bào)告而是一個(gè)輔助決策工具。5. 關(guān)鍵代碼解析清洗、接口、圖表三端貫通以下代碼是從最終源碼里原樣截取的核心片段對(duì)應(yīng)離線(xiàn)清洗、服務(wù)端接口、前端渲染三端。5.1 Spark清理已完成數(shù)據(jù)并寫(xiě)回MySQL上一章的清洗代碼已經(jīng)解決了“從原始日志到中間parquet”這一小段負(fù)責(zé)把聚合結(jié)果寫(xiě)入MySQL。from pyspark.sql import SparkSession from pyspark.sql.functions import col, countDistinct, sum spark SparkSession.builder \ .appName(GameLogAgg) \ .config(spark.sql.shuffle.partitions, 4) \ .getOrCreate() df spark.read.parquet(data/clean_logs) daily df.groupBy(dt).agg( countDistinct(user_id).alias(dau), sum(col(recharge_amount).cast(double)).alias(recharge_amount) ) daily.write \ .format(jdbc) \ .option(url, jdbc:mysql://localhost:3306/game_analysis) .option(dbtable, daily_agg) .option(user, root) .option(password, 123456) .option(driver, com.mysql.cj.jdbc.Driver) \ .mode(overwrite) \ .save()寫(xiě)回時(shí)我用的overwrite模式因?yàn)槿站酆媳硎谴笃翑?shù)據(jù)源直接整體覆蓋避免處理增量問(wèn)題簡(jiǎn)單可靠。5.2 Flask接口返回JSON后端接口我用Flask寫(xiě)關(guān)鍵點(diǎn)在于數(shù)據(jù)庫(kù)連接統(tǒng)一封裝、返回結(jié)構(gòu)統(tǒng)一、查詢(xún)結(jié)果轉(zhuǎn)字典。from flask import Flask, jsonify import pymysql app Flask(__name__) DB_CONFIG { host: localhost, user: root, password: 123456, database: game_analysis, charset: utf8mb4 } def query_db(sql): conn pymysql.connect(**DB_CONFIG) cur conn.cursor() cur.execute(sql) cols [desc[0] for desc in cur.description] rows [dict(zip(cols, row)) for row in cur.fetchall()] cur.close() conn.close() return rows app.route(/api/trend) def api_trend(): sql SELECT dt, dau, recharge_amount FROM daily_agg ORDER BY dt return jsonify(code0, dataquery_db(sql)) app.route(/api/channel) def api_channel(): sql SELECT channel, SUM(recharge_amount) AS amount FROM daily_agg_detail GROUP BY channel return jsonify(code0, dataquery_db(sql)) if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse)數(shù)據(jù)量小不用擔(dān)心性能瓶頸。接口層我只做了最必要的封裝盡量讓每段代碼都容易讀懂。5.3 ECharts大屏關(guān)鍵配置前端大屏使用原生HTML ECharts沒(méi)有引入Vue或React避免增加額外構(gòu)建環(huán)節(jié)。下面是趨勢(shì)圖的核心配置fetch(/api/trend) .then(res res.json()) .then(res { const dates res.data.map(d d.dt); const dauList res.data.map(d d.dau); const amountList res.data.map(d d.recharge_amount); const chart echarts.init(document.getElementById(trendChart)); chart.setOption({ tooltip: { trigger: axis }, legend: { data: [日活躍用戶(hù), 充值金額] }, grid: { left: 60, right: 60, top: 50, bottom: 40 }, xAxis: { type: category, data: dates }, yAxis: [ { type: value, name: DAU }, { type: value, name: 充值金額 } ], series: [ { name: 日活躍用戶(hù), type: line, smooth: true, data: dauList }, { name: 充值金額, type: line, smooth: true, yAxisIndex: 1, data: amountList } ] }); });雙Y軸配置是這個(gè)圖的核心。DAU的數(shù)值和充值金額的數(shù)值量級(jí)差異可能很大不分開(kāi)Y軸就會(huì)導(dǎo)致其中一個(gè)曲線(xiàn)幾乎變成一根直線(xiàn)。6. 項(xiàng)目結(jié)構(gòu)與部署運(yùn)行6.1 源碼目錄說(shuō)明完整項(xiàng)目目錄結(jié)構(gòu)如下game-data-visualization/ ├── generator/ │ ├── generate_logs.py # 模擬游戲日志生成腳本 │ └── config.py # 生成規(guī)則配置 ├── etl/ │ ├── clean_job.py # Spark離線(xiàn)清洗 │ ├── agg_job.py # Spark指標(biāo)聚合 │ └── write_mysql.py # 聚合結(jié)果寫(xiě)庫(kù) ├── web/ │ ├── api.py # Flask后端接口 │ ├── static/ │ │ ├── index.html # 大屏主頁(yè)面 │ │ ├── css/ │ │ └── js/ │ │ ├── charts/ │ │ └── app.js ├── sql/ │ ├── schema.sql # 建庫(kù)建表語(yǔ)句 │ └── init_data.sql # 初始化數(shù)據(jù) ├── docs/ │ ├── 部署文檔.md │ └── 答辯PPT大綱.md └── README.md6.2 運(yùn)行環(huán)境與啟動(dòng)步驟推薦環(huán)境Python 3.8、PySpark 3.x、Flask 2.x、MySQL 8.0前端使用ECharts 5.x的CDN文件。整個(gè)過(guò)程按四步走# 第一步創(chuàng)建并初始化數(shù)據(jù)庫(kù) mysql -u root -p sql/schema.sql # 第二步生成模擬游戲日志 python generator/generate_logs.py # 第三步執(zhí)行Spark清洗與聚合 spark-submit etl/clean_job.py spark-submit etl/agg_job.py spark-submit etl/write_mysql.py # 第四步啟動(dòng)后端服務(wù) cd web python api.py # 瀏覽器訪問(wèn) http://localhost:50006.3 部署時(shí)最容易遇到的三個(gè)報(bào)錯(cuò)第一個(gè)是Spark本地運(yùn)行內(nèi)存不足。任務(wù)支持不了大批量數(shù)據(jù)。可以在spark-submit時(shí)加上執(zhí)行參數(shù)spark-submit --driver-memory 2g --executor-memory 2g etl/clean_job.py第二個(gè)是MySQL中文亂碼。建庫(kù)時(shí)一定要指定utf8mb4字符集同時(shí)jdbc連接串的characterEncoding不要漏掉jdbc:mysql://localhost:3306/game_analysis?useUnicodetruecharacterEncodingutf8mb4第三個(gè)是ECharts的省份地圖組件加載不出來(lái)。ECharts從5.0開(kāi)始默認(rèn)不打包地圖數(shù)據(jù)需要在頁(yè)面里單獨(dú)引入中國(guó)地圖的GeoJSON或者在本地放一份china.js文件。這個(gè)很多同學(xué)會(huì)踩到我特意寫(xiě)在部署文檔里了。6.4 源碼獲取方式項(xiàng)目包括模擬數(shù)據(jù)生成腳本、Spark離線(xiàn)清洗與聚合代碼、Flask接口、前端大屏頁(yè)面、建表SQL和詳細(xì)部署文檔還有我整理的答辯PPT大綱。需要源碼的同學(xué)直接評(píng)論區(qū)留言或者私信發(fā)我“游戲數(shù)據(jù)”我看到了就把網(wǎng)盤(pán)鏈接發(fā)給你。換成你自己的數(shù)據(jù)源和頁(yè)面標(biāo)題就是一份可以直接上會(huì)的畢業(yè)設(shè)計(jì)作品。7. 復(fù)盤(pán)做完這個(gè)項(xiàng)目我最大的一個(gè)感受做完這個(gè)項(xiàng)目最反直覺(jué)的一點(diǎn)是一個(gè)“大數(shù)據(jù)可視化系統(tǒng)”最難的部分根本不在算法也不在框架而在數(shù)據(jù)治理和指標(biāo)定義。我復(fù)盤(pán)時(shí)發(fā)現(xiàn)整個(gè)開(kāi)發(fā)周期里最耗時(shí)間的三個(gè)環(huán)節(jié)其實(shí)是設(shè)計(jì)日志字段、定義指標(biāo)口徑、調(diào)ECharts布局。Spark清洗的代碼寫(xiě)起來(lái)很快但確認(rèn)“每一列拿到的是什么含義”“這個(gè)指標(biāo)在業(yè)務(wù)上到底怎么算”才是最燒腦的部分。這也解釋了為什么很多實(shí)際項(xiàng)目中數(shù)據(jù)分析師和數(shù)倉(cāng)工程師的時(shí)間大量花在對(duì)齊口徑上。這個(gè)項(xiàng)目后續(xù)可擴(kuò)展的方向非常明確。想往實(shí)時(shí)走可以在采集端接入Kafka把清洗任務(wù)換成Flink或Spark Streaming大屏的日粒度數(shù)據(jù)就能變成分鐘級(jí)。想往用戶(hù)畫(huà)像深挖可以基于明細(xì)數(shù)據(jù)計(jì)算用戶(hù)生命周期價(jià)值、付費(fèi)偏好、流失預(yù)警增加一個(gè)“用戶(hù)分群”頁(yè)面。想往算法方向走還能拿關(guān)卡通過(guò)率數(shù)據(jù)做難易度預(yù)測(cè)反哺策劃調(diào)參。但這些都是后話(huà)。對(duì)現(xiàn)階段來(lái)說(shuō)把“采集-清洗-計(jì)算-展示”這條主線(xiàn)穩(wěn)穩(wěn)拿下來(lái)把每個(gè)環(huán)節(jié)為什么這么做講清楚答辯就已經(jīng)很能打了。之后要擴(kuò)什么都是順?biāo)浦鄣氖隆?