據(jù)分析與可視化大屏實現(xiàn))
做數(shù)據(jù)分析項目最怕的不是不會寫代碼而是沒有好數(shù)據(jù)。之前刷過很多公開數(shù)據(jù)集總感覺和真實業(yè)務隔著一層直到我把目光放到B站上。這個項目用python完成了一套針對B站青少年模式相關(guān)內(nèi)容的采集、清洗、分析和可視化展示系統(tǒng)從公開接口拿數(shù)據(jù)用pandas做處理再通過pyecharts和Flask搭成可視化大屏整體跑下來對數(shù)據(jù)分析全流程的理解比單純刷十遍教程都深。如果你是python數(shù)據(jù)分析的初學者或者正在找畢業(yè)設計、課程項目選題可以參考下面這整套設計和實現(xiàn)過程從數(shù)據(jù)獲取到圖表落地每一步我都會講清楚為什么這樣做以及實際跑的時候踩過的坑。1. 為什么選青少年模式做數(shù)據(jù)切口選題邏輯與系統(tǒng)框架1.1 數(shù)據(jù)選題的真實性判斷做可視化系統(tǒng)最怕的就是“偽需求”——拿著現(xiàn)成的csv文件畫幾張圖看起來像個項目實際上沒有解決任何真實問題。選B站青少年模式核心原因是它的數(shù)據(jù)邊界足夠清晰而且具備真實的社會關(guān)注度。青少年模式本身就是平臺面向未成年人推出的基礎(chǔ)使用功能它的內(nèi)容池有明確的篩選邏輯比如以教育學習、動畫、紀錄片、音樂等分區(qū)為主直播和私信功能受限。這意味著我們可以圍繞“青少年模式下內(nèi)容的使用情況”構(gòu)建一套完整的分析體系什么分區(qū)的內(nèi)容供給多、什么內(nèi)容互動效率高、哪些時段青少年內(nèi)容播放更活躍、評論區(qū)呈現(xiàn)出什么樣的情感傾向。數(shù)據(jù)獲取層面不需要任何私有數(shù)據(jù)。B站的公開接口提供了視頻基礎(chǔ)信息、播放點贊投幣收藏等互動指標、評論內(nèi)容、排行榜單這些數(shù)據(jù)足夠支撐分析。真正有價值的地方在于你需要把“青少年模式下的內(nèi)容生態(tài)”這個概念翻譯成可操作的字段和指標比如分區(qū)占比、互動率、發(fā)布時段分布、評論文本情感得分等。這個翻譯過程就是數(shù)據(jù)分析里最核心的能力。1.2 系統(tǒng)模塊劃分與技術(shù)選型整個系統(tǒng)按數(shù)據(jù)流向分五個模塊數(shù)據(jù)采集層、數(shù)據(jù)存儲層、數(shù)據(jù)清洗層、分析計算層、可視化展示層。采集層負責從B站公開接口拉取數(shù)據(jù)存儲層用csv和SQLite兩種方式保存清洗層用pandas做標準化分析層計算衍生指標展示層用圖表把結(jié)論呈現(xiàn)出來。技術(shù)選型上我全部基于python生態(tài)沒有引入重型組件。具體如下表模塊技術(shù)選型選擇理由數(shù)據(jù)采集requests jsonB站接口返回JSON解析成本最低數(shù)據(jù)存儲pandas SQLite數(shù)據(jù)量在萬級csv夠用SQLite方便查詢數(shù)據(jù)處理pandas numpy行業(yè)標準處理結(jié)構(gòu)化表格數(shù)據(jù)效率高文本分析SnowNLP jieba對中文評論文本友好庫輕量適合教學演示可視化pyecharts Flaskpyecharts生成ECharts配置Flask輕量部署為什么不直接用Django因為這個項目的展示端只有一個大屏頁面加幾個路由Django的admin、ORM、中間件體系都是多余負擔。Flask剛好能把Python計算能力和前端頁面粘在一起學習成本也低。pyecharts則解決了純前端ECharts需要手寫大量JS配置的問題所有圖表配置都能在Python里生成對數(shù)據(jù)分析背景的開發(fā)者非常友好。2. 數(shù)據(jù)采集模塊從B站公開接口構(gòu)建原始數(shù)據(jù)集2.1 采集目標與字段設計我把采集對象分成三個表視頻信息表、評論信息表、分區(qū)排行表。視頻信息表是分析的主表評論表用于文本情感分析排行表用于校驗分區(qū)趨勢。視頻信息表的核心字段包括bvid視頻唯一編號、標題、分區(qū)名稱、視頻時長、發(fā)布時間、播放量、點贊數(shù)、投幣數(shù)、收藏數(shù)、分享數(shù)、評論數(shù)。注意不要重復存儲冗余字段比如視頻鏈接可以通過bvid拼接得到不需要單獨建列。評論信息表包含評論ID、視頻oid、評論內(nèi)容、評論時間、點贊數(shù)。這里需要注意B站評論接口返回的層級結(jié)構(gòu)比較復雜有reply一級評論和replies二級評論采集時可以先只取一級評論二級評論數(shù)量太大且質(zhì)量參差對情感分析的影響可以在后續(xù)處理中消除。分區(qū)排行表用于觀察青少年模式內(nèi)容池中不同分區(qū)在不同時間段的供給變化主要采集分區(qū)ID、分區(qū)名稱、日期、上榜視頻數(shù)量。這張表可以作為視頻信息表的輔助驗證數(shù)據(jù)。2.2 采集代碼實現(xiàn)與解析邏輯B站視頻信息接口的調(diào)用方式很直接核心代碼如下import requests import pandas as pd import time HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.bilibili.com } def fetch_video_info(bvid: str) - dict: url fhttps://api.bilibili.com/x/web-interface/view?bvid{bvid} resp requests.get(url, headersHEADERS, timeout10) resp.raise_for_status() data resp.json().get(data, {}) if not data: return {} stat data.get(stat, {}) return { bvid: bvid, title: data.get(title, ), tname: data.get(tname, ), duration: data.get(duration, 0), pubdate: data.get(pubdate, 0), view: stat.get(view, 0), like: stat.get(like, 0), coin: stat.get(coin, 0), favorite: stat.get(favorite, 0), share: stat.get(share, 0), reply: stat.get(reply, 0) }這里有幾個容易被忽略的細節(jié)。接口返回的pubdate是Unix時間戳不是格式化時間需要后續(xù)用pd.to_datetime(df[pubdate], units)轉(zhuǎn)換。duration單位是秒要展示成“分鐘”需要在分析階段計算。stat里的鍵名和中文含義要對應清楚比如favorite是收藏數(shù)不是“喜歡”的意思命名不規(guī)范很容易把自己繞暈。評論接口的參數(shù)結(jié)構(gòu)稍復雜一些oid是視頻的數(shù)字ID不是bvid。獲取oid的方式是從視頻信息接口的返回里取aid字段這是新人最容易踩的坑。評論采集的示例代碼如下def fetch_comments(aid: int, page: int 1) - list: url https://api.bilibili.com/x/v2/reply params { type: 1, oid: aid, pn: page, sort: 1 } resp requests.get(url, headersHEADERS, paramsparams, timeout10) data resp.json().get(data, {}) replies data.get(replies) or [] result [] for r in replies: result.append({ comment_id: r.get(rpid), aid: aid, content: r.get(content, {}).get(message, ), ctime: r.get(ctime, 0), like: r.get(like, 0) }) return result2.3 采集策略與穩(wěn)定性控制采集公開接口的數(shù)據(jù)最重要的不是代碼能力而是分寸感。我在實際開發(fā)中堅持三條原則單次請求間隔不低于1秒單日采集總量控制在一萬條以內(nèi)只采集公開頁面能看到的信息。這樣既能保證數(shù)據(jù)量夠用也不會對平臺服務器造成壓力。異常處理方面普通的try-except不夠用。接口偶爾會返回code: -352這樣的風控錯誤碼或者網(wǎng)絡超時。我的處理方案是寫一個帶重試機制的裝飾器最多重試三次每次重試間隔遞增。同時把每次成功采集的數(shù)據(jù)量、失敗原因記錄到日志文件方便后續(xù)回溯。提示采集公開數(shù)據(jù)用于學習研究時請控制請求頻率并遵守平臺相關(guān)規(guī)則。本項目所有數(shù)據(jù)均來自公開頁面可見的信息不涉及任何非公開接口。數(shù)據(jù)存儲我用了簡單的df.to_csv()追加寫入文件名按日期命名比如bili_video_20250501.csv。每天采集結(jié)束后合并一次最終形成一個全量數(shù)據(jù)集。不要小看這個設計它能讓你隨時回滾到某一天的數(shù)據(jù)狀態(tài)避免一次誤操作把整個數(shù)據(jù)集搞壞。3. 數(shù)據(jù)清洗與特征構(gòu)建把播放量數(shù)字變成可解釋的指標3.1 清洗流程中的細節(jié)處理原始數(shù)據(jù)采集下來之后臟數(shù)據(jù)比你想象的多。最常見的是標題里夾雜著表情符號、特殊字符發(fā)布時間字段出現(xiàn)0值播放量個別異常大或異常小。清洗不是簡單dropna而是要逐字段判斷業(yè)務合理性。我的清洗流程分成四步。第一步是去重按照bvid和comment_id兩個維度去重保留最新記錄。第二步是處理異常值播放量超過數(shù)據(jù)集中位數(shù)100倍以上的視頻標記為異常單獨存放而不是直接刪除因為頭部爆款視頻本身就是B站內(nèi)容生態(tài)的一部分不能粗暴剔除。第三步是處理缺失值分區(qū)為空的視頻按“未知”填充互動數(shù)據(jù)為空的按0填充并加標記列。第四步是標準化格式統(tǒng)一把發(fā)布時間轉(zhuǎn)成北京時間把時長轉(zhuǎn)換成分鐘把文本中的換行符和亂碼字符去掉。這里有一條實戰(zhàn)心得清洗過程中每做一步操作都要讓數(shù)據(jù)量變化可追蹤。我習慣用一個shape和info()輸出記錄每一階段的行數(shù)列數(shù)確保清洗邏輯沒有誤傷有效數(shù)據(jù)。3.2 核心衍生指標的計算邏輯原始字段只能回答“是多少”回答不了“怎么樣”。互動率、內(nèi)容效率這類衍生指標才是分析的重點?；勇实挠嬎愎绞?點贊 投幣 收藏) / 播放量。為什么要把這三個指標相加因為點贊代表認可投幣代表強烈推薦收藏代表“以后還要看”三者共同構(gòu)成用戶對視頻內(nèi)容的真實態(tài)度。播放量只能說明“多少人點進來”互動率才能說明“多少人覺得有價值”。內(nèi)容效率我拆成兩個維度點贊率點贊/播放和收藏率收藏/播放分別反映內(nèi)容的即時吸引力和長期留存價值。時間特征上我把發(fā)布時間拆成hour小時、weekday星期幾、month月份用于分析青少年相關(guān)內(nèi)容的發(fā)布和消費時段規(guī)律。代碼實現(xiàn)如下df[pub_time] pd.to_datetime(df[pubdate], units) df[pub_time] df[pub_time].dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai) df[hour] df[pub_time].dt.hour df[weekday] df[pub_time].dt.weekday df[month] df[pub_time].dt.month df[interaction_rate] (df[like] df[coin] df[favorite]) / df[view] df[like_rate] df[like] / df[view] df[favorite_rate] df[favorite] / df[view]時間戳轉(zhuǎn)換時要特別注意時區(qū)問題。B站接口返回的時間戳是UTC時間如果你不指定時區(qū)直接轉(zhuǎn)得到的hour會偏移8小時導致后面分析時段分布時結(jié)論完全錯誤。我在這里栽過跟頭后來統(tǒng)一用. dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai)處理。3.3 評論數(shù)據(jù)的情感傾向分析情感分析是青少年內(nèi)容使用情況分析里最有洞察力的部分。想法很簡單把每個視頻的評論情緒量化看看哪些內(nèi)容被討論時情感更積極。我用的工具是SnowNLP它基于樸素貝葉斯訓練的中文情感模型使用成本極低。核心代碼from snownlp import SnowNLP df_comment[sentiment] df_comment[content].apply( lambda x: SnowNLP(str(x)).sentiments if x and len(str(x)) 2 else 0.5 )sentiments返回0到1之間的浮點數(shù)越接近1表示情感越積極0.5左右表示中性。需要注意SnowNLP的默認模型在短文本上的判斷不太穩(wěn)定特別是反諷、網(wǎng)絡梗這些表達經(jīng)常會把“這也太強了吧”評為負面。所以在用這個指標之前我對評論內(nèi)容做了一層清洗去除純表情評論、去除長度小于4個字的評論、去除包含明顯廣告關(guān)鍵詞的評論。情感得分不能只看平均數(shù)還要看分布。我把評論按視頻聚合后計算每個視頻的平均情感得分、情感得分標準差。標準差大的視頻說明評論兩極分化嚴重這種內(nèi)容往往帶有一定爭議性也值得單獨拿出來看。4. 可視化大屏實現(xiàn)從圖表到可用的分析系統(tǒng)4.1 大屏布局與分析敘事主線可視化不是把圖堆在一起而是要讓看的人按你設計的順序理解結(jié)論。我的大屏布局采用經(jīng)典的總分結(jié)構(gòu)頂部放核心指標卡中間放主圖兩側(cè)放輔助圖。頂部指標卡展示四個核心數(shù)字采集視頻總數(shù)、平均播放量、平均互動率、評論情感均值中性率。這四張卡回答“整體情況如何”。中間主圖采用分區(qū)貢獻占比的環(huán)形圖展示青少年模式內(nèi)容池中不同分區(qū)的視頻數(shù)量和播放量占比回答“內(nèi)容供給結(jié)構(gòu)性特征”。左側(cè)是播放量TOP10視頻排行條形圖和發(fā)布時段分布熱力圖右側(cè)是互動率分布散點圖和評論情感詞云。這個布局的邏輯是先看總量再看結(jié)構(gòu)然后看頭部和趨勢最后看文本內(nèi)容。每一步都在遞進追問上一個圖表引起的疑問。4.2 圖表的具體實現(xiàn)與配置細節(jié)pyecharts在0.5版本之后使用鏈式調(diào)用語法所有圖表都可以統(tǒng)一用opts模塊配置。以分區(qū)占比環(huán)形圖為例from pyecharts.charts import Pie from pyecharts import options as opts def create_zone_pie(df): zone_data df.groupby(tname)[view].sum().sort_values(ascendingFalse) data_pair [list(item) for item in zone_data.head(8).items()] c ( Pie() .add( series_name分區(qū)播放占比, data_pairdata_pair, radius[40%, 65%], center[35%, 50%], ) .set_series_opts( label_optsopts.LabelOpts(formatter: drlblxrh1%) ) .set_global_opts( legend_optsopts.LegendOpts(pos_left75%, pos_top30%) ) ) return c這里有個細節(jié)radius[40%, 65%]指的是內(nèi)半徑和外半徑形成環(huán)形效果環(huán)形圖比實心餅圖更合適因為中心區(qū)域可以放置匯總數(shù)據(jù)標簽。formatter: drlblxrh1%會把標簽格式化成“分區(qū)名: 百分比”這樣圖上不會出現(xiàn)擠成一團的數(shù)字。播放量TOP10排行用橫向條形圖因為視頻標題普遍較長橫向排列標簽才能完整顯示。時段分布用熱力圖橫軸是星期縱軸是小時顏色深淺代表播放量高低。互動率散點圖用橫軸播放量對數(shù)刻度、縱軸互動率能清楚看到“高播放不一定是高互動”這一現(xiàn)象。4.3 Flask集成與圖表渲染方式pyecharts生成的圖表對象不能直接放到HTML里需要經(jīng)過序列化。我采用的是“Python端生成圖表配置JSON前端用ECharts渲染”的方案。這里有兩種路徑一種是pyecharts直接生成HTML片段通過iframe嵌入另一種是調(diào)用.dump_options()拿到JSON傳給前端模板。我用的是后者因為它更靈活方便多個圖表共用一套前端框架。后端代碼如下from flask import Flask, render_template import json app Flask(__name__) app.route(/) def dashboard(): pie create_zone_pie(df_video) bar create_top_bar(df_video) scatter create_scatter(df_video) return render_template( dashboard.html, pie_jsonjson.dumps(pie.dump_options(), ensure_asciiFalse), bar_jsonjson.dumps(bar.dump_options(), ensure_asciiFalse), scatter_jsonjson.dumps(scatter.dump_options(), ensure_asciiFalse) )前端模板在div idchart-root/div這類容器上用echarts.init()初始化再setOption()填入后端傳來的配置。注意dump_options()返回的是字符串一定要json.dumps轉(zhuǎn)成JSON對象再傳給前端直接傳字符串會導致ECharts報“data is undefined”錯誤。提示Flask默認模板目錄是templates靜態(tài)資源目錄是static。ECharts的JS文件放到static/js/echarts.min.js在HTML底部引用引用順序必須放在自定義腳本之前。5. 實測復盤踩坑記錄與數(shù)據(jù)結(jié)論的多維校驗5.1 高頻踩坑與排查鏈路第一個坑是接口字段變化。視頻詳情接口里的tname字段時有時無單獨請求時正常批量請求時偶爾缺失。排查思路是單獨抽查一條數(shù)據(jù)的完整JSON發(fā)現(xiàn)接口在視頻被刪除時不會報錯而是返回空data。解決方案是在采集函數(shù)里判空返回不讓空數(shù)據(jù)進入主流程。第二個坑是時區(qū)問題導致時段分析誤差8小時。這是最隱蔽的坑因為錯誤結(jié)果看起來依然“合理”——播放高峰出現(xiàn)在早上9點到11點實際上應該是下午5點到晚上7點。排查方式是抽取已知發(fā)布時間的數(shù)據(jù)人工比對發(fā)現(xiàn)問題后統(tǒng)一加了時區(qū)轉(zhuǎn)換。第三個坑是pyecharts版本不兼容。pyecharts1.9.1和pyecharts2.x的API差異很大網(wǎng)上的歷史教程很多是0.5版本的寫法。我的解決方式是鎖定版本依賴在requirements.txt里固定版本號同時以官方文檔為準。這點在給畢設寫文檔時尤其重要環(huán)境的版本漂移會讓之前的分析結(jié)果失去復現(xiàn)性。第四個坑是圖表JSON序列化的中文亂碼。dump_options()返回的JSON里中文被轉(zhuǎn)成\u形式直接傳入前端模板會顯示亂碼。解決方法就是前面寫的在JSON序列化時指定ensure_asciiFalse。5.2 從數(shù)據(jù)里讀到的幾點結(jié)論清洗完三千多條視頻數(shù)據(jù)后我做了幾組交叉分析。印象比較深的幾個發(fā)現(xiàn)教育學習類和動畫類內(nèi)容占比確實高但紀錄片類的互動率明顯優(yōu)于平均值說明青少年內(nèi)容池里“高價值內(nèi)容”和“高流量內(nèi)容”并不完全重合。發(fā)布時段上周末上午的收藏率明顯上升工作日晚上8點到10點的播放量大但互動率下降這個規(guī)律和青少年群體的作息高度吻合。評論文本情感分析顯示以“經(jīng)驗分享”“知識講解”為主要內(nèi)容的視頻評論情感得分普遍在0.6以上而以“二次創(chuàng)作”“娛樂向”為主的視頻評論情感得分雖然均值不低但標準差普遍偏大。這說明知識類內(nèi)容引發(fā)的討論更一致娛樂類內(nèi)容更容易出現(xiàn)兩極分化。5.3 系統(tǒng)擴展方向與優(yōu)化思路這套系統(tǒng)要往深做可以從三個方向發(fā)力。一是引入時間序列維度每天定時采集觀察同一指標的變化趨勢形成內(nèi)容熱度的動態(tài)演化分析。二是接入更多維度數(shù)據(jù)比如彈幕內(nèi)容、UP主屬性做用戶畫像和內(nèi)容供給側(cè)的關(guān)聯(lián)分析。三是把情感分析模型換成基于預訓練的中文模型或者在當前數(shù)據(jù)標注基礎(chǔ)上做微調(diào)提升短文本情感判斷的準確率。我個人實際跑下來最大的體會是數(shù)據(jù)分析項目的重點從來不是代碼多花哨而是你能否從一堆原始字段里提煉出有解釋力的指標并且用圖表把這個解釋鏈條清晰地展示出來。這個過程沒有捷徑多跑幾遍數(shù)據(jù)多畫幾張錯的圖比對差異背后的原因成長反而比反復看教程快得多。最后說個小技巧——把所有圖表的配色統(tǒng)一成一套色板不要在每張圖里各用各的顏色。視覺大屏給人“專業(yè)感”的第一印象往往不是圖表數(shù)量而是顏色是否協(xié)調(diào)。我一般只用四種主色其中兩種用于強調(diào)這就夠用了。 基于Python的B站青少年模式數(shù)據(jù)分析與可視化大屏實現(xiàn)
做數(shù)據(jù)分析項目最怕的不是不會寫代碼而是沒有好數(shù)據(jù)。之前刷過很多公開數(shù)據(jù)集總感覺和真實業(yè)務隔著一層直到我把目光放到B站上。這個項目用python完成了一套針對B站青少年模式相關(guān)內(nèi)容的采集、清洗、分析和可視化展示系統(tǒng)從公開接口拿數(shù)據(jù)用pandas做處理再通過pyecharts和Flask搭成可視化大屏整體跑下來對數(shù)據(jù)分析全流程的理解比單純刷十遍教程都深。如果你是python數(shù)據(jù)分析的初學者或者正在找畢業(yè)設計、課程項目選題可以參考下面這整套設計和實現(xiàn)過程從數(shù)據(jù)獲取到圖表落地每一步我都會講清楚為什么這樣做以及實際跑的時候踩過的坑。1. 為什么選青少年模式做數(shù)據(jù)切口選題邏輯與系統(tǒng)框架1.1 數(shù)據(jù)選題的真實性判斷做可視化系統(tǒng)最怕的就是“偽需求”——拿著現(xiàn)成的csv文件畫幾張圖看起來像個項目實際上沒有解決任何真實問題。選B站青少年模式核心原因是它的數(shù)據(jù)邊界足夠清晰而且具備真實的社會關(guān)注度。青少年模式本身就是平臺面向未成年人推出的基礎(chǔ)使用功能它的內(nèi)容池有明確的篩選邏輯比如以教育學習、動畫、紀錄片、音樂等分區(qū)為主直播和私信功能受限。這意味著我們可以圍繞“青少年模式下內(nèi)容的使用情況”構(gòu)建一套完整的分析體系什么分區(qū)的內(nèi)容供給多、什么內(nèi)容互動效率高、哪些時段青少年內(nèi)容播放更活躍、評論區(qū)呈現(xiàn)出什么樣的情感傾向。數(shù)據(jù)獲取層面不需要任何私有數(shù)據(jù)。B站的公開接口提供了視頻基礎(chǔ)信息、播放點贊投幣收藏等互動指標、評論內(nèi)容、排行榜單這些數(shù)據(jù)足夠支撐分析。真正有價值的地方在于你需要把“青少年模式下的內(nèi)容生態(tài)”這個概念翻譯成可操作的字段和指標比如分區(qū)占比、互動率、發(fā)布時段分布、評論文本情感得分等。這個翻譯過程就是數(shù)據(jù)分析里最核心的能力。1.2 系統(tǒng)模塊劃分與技術(shù)選型整個系統(tǒng)按數(shù)據(jù)流向分五個模塊數(shù)據(jù)采集層、數(shù)據(jù)存儲層、數(shù)據(jù)清洗層、分析計算層、可視化展示層。采集層負責從B站公開接口拉取數(shù)據(jù)存儲層用csv和SQLite兩種方式保存清洗層用pandas做標準化分析層計算衍生指標展示層用圖表把結(jié)論呈現(xiàn)出來。技術(shù)選型上我全部基于python生態(tài)沒有引入重型組件。具體如下表模塊技術(shù)選型選擇理由數(shù)據(jù)采集requests jsonB站接口返回JSON解析成本最低數(shù)據(jù)存儲pandas SQLite數(shù)據(jù)量在萬級csv夠用SQLite方便查詢數(shù)據(jù)處理pandas numpy行業(yè)標準處理結(jié)構(gòu)化表格數(shù)據(jù)效率高文本分析SnowNLP jieba對中文評論文本友好庫輕量適合教學演示可視化pyecharts Flaskpyecharts生成ECharts配置Flask輕量部署為什么不直接用Django因為這個項目的展示端只有一個大屏頁面加幾個路由Django的admin、ORM、中間件體系都是多余負擔。Flask剛好能把Python計算能力和前端頁面粘在一起學習成本也低。pyecharts則解決了純前端ECharts需要手寫大量JS配置的問題所有圖表配置都能在Python里生成對數(shù)據(jù)分析背景的開發(fā)者非常友好。2. 數(shù)據(jù)采集模塊從B站公開接口構(gòu)建原始數(shù)據(jù)集2.1 采集目標與字段設計我把采集對象分成三個表視頻信息表、評論信息表、分區(qū)排行表。視頻信息表是分析的主表評論表用于文本情感分析排行表用于校驗分區(qū)趨勢。視頻信息表的核心字段包括bvid視頻唯一編號、標題、分區(qū)名稱、視頻時長、發(fā)布時間、播放量、點贊數(shù)、投幣數(shù)、收藏數(shù)、分享數(shù)、評論數(shù)。注意不要重復存儲冗余字段比如視頻鏈接可以通過bvid拼接得到不需要單獨建列。評論信息表包含評論ID、視頻oid、評論內(nèi)容、評論時間、點贊數(shù)。這里需要注意B站評論接口返回的層級結(jié)構(gòu)比較復雜有reply一級評論和replies二級評論采集時可以先只取一級評論二級評論數(shù)量太大且質(zhì)量參差對情感分析的影響可以在后續(xù)處理中消除。分區(qū)排行表用于觀察青少年模式內(nèi)容池中不同分區(qū)在不同時間段的供給變化主要采集分區(qū)ID、分區(qū)名稱、日期、上榜視頻數(shù)量。這張表可以作為視頻信息表的輔助驗證數(shù)據(jù)。2.2 采集代碼實現(xiàn)與解析邏輯B站視頻信息接口的調(diào)用方式很直接核心代碼如下import requests import pandas as pd import time HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.bilibili.com } def fetch_video_info(bvid: str) - dict: url fhttps://api.bilibili.com/x/web-interface/view?bvid{bvid} resp requests.get(url, headersHEADERS, timeout10) resp.raise_for_status() data resp.json().get(data, {}) if not data: return {} stat data.get(stat, {}) return { bvid: bvid, title: data.get(title, ), tname: data.get(tname, ), duration: data.get(duration, 0), pubdate: data.get(pubdate, 0), view: stat.get(view, 0), like: stat.get(like, 0), coin: stat.get(coin, 0), favorite: stat.get(favorite, 0), share: stat.get(share, 0), reply: stat.get(reply, 0) }這里有幾個容易被忽略的細節(jié)。接口返回的pubdate是Unix時間戳不是格式化時間需要后續(xù)用pd.to_datetime(df[pubdate], units)轉(zhuǎn)換。duration單位是秒要展示成“分鐘”需要在分析階段計算。stat里的鍵名和中文含義要對應清楚比如favorite是收藏數(shù)不是“喜歡”的意思命名不規(guī)范很容易把自己繞暈。評論接口的參數(shù)結(jié)構(gòu)稍復雜一些oid是視頻的數(shù)字ID不是bvid。獲取oid的方式是從視頻信息接口的返回里取aid字段這是新人最容易踩的坑。評論采集的示例代碼如下def fetch_comments(aid: int, page: int 1) - list: url https://api.bilibili.com/x/v2/reply params { type: 1, oid: aid, pn: page, sort: 1 } resp requests.get(url, headersHEADERS, paramsparams, timeout10) data resp.json().get(data, {}) replies data.get(replies) or [] result [] for r in replies: result.append({ comment_id: r.get(rpid), aid: aid, content: r.get(content, {}).get(message, ), ctime: r.get(ctime, 0), like: r.get(like, 0) }) return result2.3 采集策略與穩(wěn)定性控制采集公開接口的數(shù)據(jù)最重要的不是代碼能力而是分寸感。我在實際開發(fā)中堅持三條原則單次請求間隔不低于1秒單日采集總量控制在一萬條以內(nèi)只采集公開頁面能看到的信息。這樣既能保證數(shù)據(jù)量夠用也不會對平臺服務器造成壓力。異常處理方面普通的try-except不夠用。接口偶爾會返回code: -352這樣的風控錯誤碼或者網(wǎng)絡超時。我的處理方案是寫一個帶重試機制的裝飾器最多重試三次每次重試間隔遞增。同時把每次成功采集的數(shù)據(jù)量、失敗原因記錄到日志文件方便后續(xù)回溯。提示采集公開數(shù)據(jù)用于學習研究時請控制請求頻率并遵守平臺相關(guān)規(guī)則。本項目所有數(shù)據(jù)均來自公開頁面可見的信息不涉及任何非公開接口。數(shù)據(jù)存儲我用了簡單的df.to_csv()追加寫入文件名按日期命名比如bili_video_20250501.csv。每天采集結(jié)束后合并一次最終形成一個全量數(shù)據(jù)集。不要小看這個設計它能讓你隨時回滾到某一天的數(shù)據(jù)狀態(tài)避免一次誤操作把整個數(shù)據(jù)集搞壞。3. 數(shù)據(jù)清洗與特征構(gòu)建把播放量數(shù)字變成可解釋的指標3.1 清洗流程中的細節(jié)處理原始數(shù)據(jù)采集下來之后臟數(shù)據(jù)比你想象的多。最常見的是標題里夾雜著表情符號、特殊字符發(fā)布時間字段出現(xiàn)0值播放量個別異常大或異常小。清洗不是簡單dropna而是要逐字段判斷業(yè)務合理性。我的清洗流程分成四步。第一步是去重按照bvid和comment_id兩個維度去重保留最新記錄。第二步是處理異常值播放量超過數(shù)據(jù)集中位數(shù)100倍以上的視頻標記為異常單獨存放而不是直接刪除因為頭部爆款視頻本身就是B站內(nèi)容生態(tài)的一部分不能粗暴剔除。第三步是處理缺失值分區(qū)為空的視頻按“未知”填充互動數(shù)據(jù)為空的按0填充并加標記列。第四步是標準化格式統(tǒng)一把發(fā)布時間轉(zhuǎn)成北京時間把時長轉(zhuǎn)換成分鐘把文本中的換行符和亂碼字符去掉。這里有一條實戰(zhàn)心得清洗過程中每做一步操作都要讓數(shù)據(jù)量變化可追蹤。我習慣用一個shape和info()輸出記錄每一階段的行數(shù)列數(shù)確保清洗邏輯沒有誤傷有效數(shù)據(jù)。3.2 核心衍生指標的計算邏輯原始字段只能回答“是多少”回答不了“怎么樣”。互動率、內(nèi)容效率這類衍生指標才是分析的重點?；勇实挠嬎愎绞?點贊 投幣 收藏) / 播放量。為什么要把這三個指標相加因為點贊代表認可投幣代表強烈推薦收藏代表“以后還要看”三者共同構(gòu)成用戶對視頻內(nèi)容的真實態(tài)度。播放量只能說明“多少人點進來”互動率才能說明“多少人覺得有價值”。內(nèi)容效率我拆成兩個維度點贊率點贊/播放和收藏率收藏/播放分別反映內(nèi)容的即時吸引力和長期留存價值。時間特征上我把發(fā)布時間拆成hour小時、weekday星期幾、month月份用于分析青少年相關(guān)內(nèi)容的發(fā)布和消費時段規(guī)律。代碼實現(xiàn)如下df[pub_time] pd.to_datetime(df[pubdate], units) df[pub_time] df[pub_time].dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai) df[hour] df[pub_time].dt.hour df[weekday] df[pub_time].dt.weekday df[month] df[pub_time].dt.month df[interaction_rate] (df[like] df[coin] df[favorite]) / df[view] df[like_rate] df[like] / df[view] df[favorite_rate] df[favorite] / df[view]時間戳轉(zhuǎn)換時要特別注意時區(qū)問題。B站接口返回的時間戳是UTC時間如果你不指定時區(qū)直接轉(zhuǎn)得到的hour會偏移8小時導致后面分析時段分布時結(jié)論完全錯誤。我在這里栽過跟頭后來統(tǒng)一用. dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai)處理。3.3 評論數(shù)據(jù)的情感傾向分析情感分析是青少年內(nèi)容使用情況分析里最有洞察力的部分。想法很簡單把每個視頻的評論情緒量化看看哪些內(nèi)容被討論時情感更積極。我用的工具是SnowNLP它基于樸素貝葉斯訓練的中文情感模型使用成本極低。核心代碼from snownlp import SnowNLP df_comment[sentiment] df_comment[content].apply( lambda x: SnowNLP(str(x)).sentiments if x and len(str(x)) 2 else 0.5 )sentiments返回0到1之間的浮點數(shù)越接近1表示情感越積極0.5左右表示中性。需要注意SnowNLP的默認模型在短文本上的判斷不太穩(wěn)定特別是反諷、網(wǎng)絡梗這些表達經(jīng)常會把“這也太強了吧”評為負面。所以在用這個指標之前我對評論內(nèi)容做了一層清洗去除純表情評論、去除長度小于4個字的評論、去除包含明顯廣告關(guān)鍵詞的評論。情感得分不能只看平均數(shù)還要看分布。我把評論按視頻聚合后計算每個視頻的平均情感得分、情感得分標準差。標準差大的視頻說明評論兩極分化嚴重這種內(nèi)容往往帶有一定爭議性也值得單獨拿出來看。4. 可視化大屏實現(xiàn)從圖表到可用的分析系統(tǒng)4.1 大屏布局與分析敘事主線可視化不是把圖堆在一起而是要讓看的人按你設計的順序理解結(jié)論。我的大屏布局采用經(jīng)典的總分結(jié)構(gòu)頂部放核心指標卡中間放主圖兩側(cè)放輔助圖。頂部指標卡展示四個核心數(shù)字采集視頻總數(shù)、平均播放量、平均互動率、評論情感均值中性率。這四張卡回答“整體情況如何”。中間主圖采用分區(qū)貢獻占比的環(huán)形圖展示青少年模式內(nèi)容池中不同分區(qū)的視頻數(shù)量和播放量占比回答“內(nèi)容供給結(jié)構(gòu)性特征”。左側(cè)是播放量TOP10視頻排行條形圖和發(fā)布時段分布熱力圖右側(cè)是互動率分布散點圖和評論情感詞云。這個布局的邏輯是先看總量再看結(jié)構(gòu)然后看頭部和趨勢最后看文本內(nèi)容。每一步都在遞進追問上一個圖表引起的疑問。4.2 圖表的具體實現(xiàn)與配置細節(jié)pyecharts在0.5版本之后使用鏈式調(diào)用語法所有圖表都可以統(tǒng)一用opts模塊配置。以分區(qū)占比環(huán)形圖為例from pyecharts.charts import Pie from pyecharts import options as opts def create_zone_pie(df): zone_data df.groupby(tname)[view].sum().sort_values(ascendingFalse) data_pair [list(item) for item in zone_data.head(8).items()] c ( Pie() .add( series_name分區(qū)播放占比, data_pairdata_pair, radius[40%, 65%], center[35%, 50%], ) .set_series_opts( label_optsopts.LabelOpts(formatter: drlblxrh1%) ) .set_global_opts( legend_optsopts.LegendOpts(pos_left75%, pos_top30%) ) ) return c這里有個細節(jié)radius[40%, 65%]指的是內(nèi)半徑和外半徑形成環(huán)形效果環(huán)形圖比實心餅圖更合適因為中心區(qū)域可以放置匯總數(shù)據(jù)標簽。formatter: drlblxrh1%會把標簽格式化成“分區(qū)名: 百分比”這樣圖上不會出現(xiàn)擠成一團的數(shù)字。播放量TOP10排行用橫向條形圖因為視頻標題普遍較長橫向排列標簽才能完整顯示。時段分布用熱力圖橫軸是星期縱軸是小時顏色深淺代表播放量高低。互動率散點圖用橫軸播放量對數(shù)刻度、縱軸互動率能清楚看到“高播放不一定是高互動”這一現(xiàn)象。4.3 Flask集成與圖表渲染方式pyecharts生成的圖表對象不能直接放到HTML里需要經(jīng)過序列化。我采用的是“Python端生成圖表配置JSON前端用ECharts渲染”的方案。這里有兩種路徑一種是pyecharts直接生成HTML片段通過iframe嵌入另一種是調(diào)用.dump_options()拿到JSON傳給前端模板。我用的是后者因為它更靈活方便多個圖表共用一套前端框架。后端代碼如下from flask import Flask, render_template import json app Flask(__name__) app.route(/) def dashboard(): pie create_zone_pie(df_video) bar create_top_bar(df_video) scatter create_scatter(df_video) return render_template( dashboard.html, pie_jsonjson.dumps(pie.dump_options(), ensure_asciiFalse), bar_jsonjson.dumps(bar.dump_options(), ensure_asciiFalse), scatter_jsonjson.dumps(scatter.dump_options(), ensure_asciiFalse) )前端模板在div idchart-root/div這類容器上用echarts.init()初始化再setOption()填入后端傳來的配置。注意dump_options()返回的是字符串一定要json.dumps轉(zhuǎn)成JSON對象再傳給前端直接傳字符串會導致ECharts報“data is undefined”錯誤。提示Flask默認模板目錄是templates靜態(tài)資源目錄是static。ECharts的JS文件放到static/js/echarts.min.js在HTML底部引用引用順序必須放在自定義腳本之前。5. 實測復盤踩坑記錄與數(shù)據(jù)結(jié)論的多維校驗5.1 高頻踩坑與排查鏈路第一個坑是接口字段變化。視頻詳情接口里的tname字段時有時無單獨請求時正常批量請求時偶爾缺失。排查思路是單獨抽查一條數(shù)據(jù)的完整JSON發(fā)現(xiàn)接口在視頻被刪除時不會報錯而是返回空data。解決方案是在采集函數(shù)里判空返回不讓空數(shù)據(jù)進入主流程。第二個坑是時區(qū)問題導致時段分析誤差8小時。這是最隱蔽的坑因為錯誤結(jié)果看起來依然“合理”——播放高峰出現(xiàn)在早上9點到11點實際上應該是下午5點到晚上7點。排查方式是抽取已知發(fā)布時間的數(shù)據(jù)人工比對發(fā)現(xiàn)問題后統(tǒng)一加了時區(qū)轉(zhuǎn)換。第三個坑是pyecharts版本不兼容。pyecharts1.9.1和pyecharts2.x的API差異很大網(wǎng)上的歷史教程很多是0.5版本的寫法。我的解決方式是鎖定版本依賴在requirements.txt里固定版本號同時以官方文檔為準。這點在給畢設寫文檔時尤其重要環(huán)境的版本漂移會讓之前的分析結(jié)果失去復現(xiàn)性。第四個坑是圖表JSON序列化的中文亂碼。dump_options()返回的JSON里中文被轉(zhuǎn)成\u形式直接傳入前端模板會顯示亂碼。解決方法就是前面寫的在JSON序列化時指定ensure_asciiFalse。5.2 從數(shù)據(jù)里讀到的幾點結(jié)論清洗完三千多條視頻數(shù)據(jù)后我做了幾組交叉分析。印象比較深的幾個發(fā)現(xiàn)教育學習類和動畫類內(nèi)容占比確實高但紀錄片類的互動率明顯優(yōu)于平均值說明青少年內(nèi)容池里“高價值內(nèi)容”和“高流量內(nèi)容”并不完全重合。發(fā)布時段上周末上午的收藏率明顯上升工作日晚上8點到10點的播放量大但互動率下降這個規(guī)律和青少年群體的作息高度吻合。評論文本情感分析顯示以“經(jīng)驗分享”“知識講解”為主要內(nèi)容的視頻評論情感得分普遍在0.6以上而以“二次創(chuàng)作”“娛樂向”為主的視頻評論情感得分雖然均值不低但標準差普遍偏大。這說明知識類內(nèi)容引發(fā)的討論更一致娛樂類內(nèi)容更容易出現(xiàn)兩極分化。5.3 系統(tǒng)擴展方向與優(yōu)化思路這套系統(tǒng)要往深做可以從三個方向發(fā)力。一是引入時間序列維度每天定時采集觀察同一指標的變化趨勢形成內(nèi)容熱度的動態(tài)演化分析。二是接入更多維度數(shù)據(jù)比如彈幕內(nèi)容、UP主屬性做用戶畫像和內(nèi)容供給側(cè)的關(guān)聯(lián)分析。三是把情感分析模型換成基于預訓練的中文模型或者在當前數(shù)據(jù)標注基礎(chǔ)上做微調(diào)提升短文本情感判斷的準確率。我個人實際跑下來最大的體會是數(shù)據(jù)分析項目的重點從來不是代碼多花哨而是你能否從一堆原始字段里提煉出有解釋力的指標并且用圖表把這個解釋鏈條清晰地展示出來。這個過程沒有捷徑多跑幾遍數(shù)據(jù)多畫幾張錯的圖比對差異背后的原因成長反而比反復看教程快得多。最后說個小技巧——把所有圖表的配色統(tǒng)一成一套色板不要在每張圖里各用各的顏色。視覺大屏給人“專業(yè)感”的第一印象往往不是圖表數(shù)量而是顏色是否協(xié)調(diào)。我一般只用四種主色其中兩種用于強調(diào)這就夠用了。