簡(jiǎn)介本資源是一套面向本科畢業(yè)設(shè)計(jì)與課程綜合實(shí)踐的醫(yī)療健康領(lǐng)域數(shù)據(jù)分析可視化系統(tǒng)聚焦疾病數(shù)據(jù)挖掘與大屏展示全流程適用于計(jì)算機(jī)、醫(yī)學(xué)信息工程等專業(yè)學(xué)生開展項(xiàng)目實(shí)戰(zhàn)與算法應(yīng)用學(xué)習(xí)。系統(tǒng)采用Flask構(gòu)建后端API服務(wù)Vue實(shí)現(xiàn)前端響應(yīng)式大屏集成requests網(wǎng)絡(luò)爬蟲自動(dòng)采集疾病相關(guān)公開數(shù)據(jù)并基于隨機(jī)森林算法完成疾病風(fēng)險(xiǎn)預(yù)測(cè)建模與特征重要性分析。壓縮包共67個(gè)文件含7個(gè)核心Python腳本含爬蟲、模型訓(xùn)練與接口邏輯、7個(gè)Vue組件文件、7個(gè)JavaScript交互模塊、5個(gè)JSON配置與數(shù)據(jù)文件、4個(gè)HTML頁面及配套SQL數(shù)據(jù)庫腳本、Word論文文檔、部署調(diào)試說明與3張運(yùn)行效果截圖整體僅1.32MB結(jié)構(gòu)清晰、開箱即用。目前已有43人學(xué)習(xí)下載提供從數(shù)據(jù)獲取、清洗、建模到可視化落地的完整閉環(huán)方案特別適合需要快速驗(yàn)證機(jī)器學(xué)習(xí)與前后端聯(lián)調(diào)能力的學(xué)習(xí)者。 這年頭的數(shù)據(jù)可視化項(xiàng)目單拿一個(gè)框架出來已經(jīng)不太能打了。真正能讓人眼前一亮的往往是那種“爬蟲把數(shù)據(jù)喂進(jìn)來、算法把價(jià)值算出來、前端把結(jié)果擺上桌”的完整鏈路。這套基于Python Flask Vue 隨機(jī)森林 requests搭建的醫(yī)療疾病數(shù)據(jù)分析大屏系統(tǒng)就是把這幾塊硬生生串成了一條線。很多人看到“醫(yī)療疾病”四個(gè)字覺得門檻高其實(shí)拆開看核心就三件事數(shù)據(jù)從哪來、預(yù)測(cè)怎么做、大屏怎么畫。這篇文章我就按實(shí)際落地的順序把選型邏輯、爬蟲階段的限流排坑、隨機(jī)森林從訓(xùn)練到接口、前后端對(duì)接的隱藏問題全部攤開講適合正在做數(shù)據(jù)類項(xiàng)目作品、畢業(yè)設(shè)計(jì)或者想體驗(yàn)一次全棧加機(jī)器學(xué)習(xí)全流程的開發(fā)者參考。1. 選型邏輯這套系統(tǒng)為什么鎖定FlaskVue隨機(jī)森林1.1 后端輕量化選型Python生態(tài)是出發(fā)點(diǎn)先說一個(gè)總原則當(dāng)一個(gè)項(xiàng)目里既有數(shù)據(jù)采集、又有機(jī)器學(xué)習(xí)、又有Web服務(wù)時(shí)語言統(tǒng)一帶來的收益遠(yuǎn)超所有框架層面的微優(yōu)化。爬蟲用requests、數(shù)據(jù)處理用pandas、建模用scikit-learn這些全是Python生態(tài)的東西。如果后端再選Python整條數(shù)據(jù)管道可以用一套語言推理下來不用在語言切換中反復(fù)維護(hù)上下文?？蚣軐用鍲lask、Django、FastAPI是這個(gè)生態(tài)里最常被比較的三個(gè)。從落地感受來看框架上手成本適合場(chǎng)景實(shí)際體驗(yàn)Flask低輕量API、中小型數(shù)據(jù)服務(wù)、個(gè)人項(xiàng)目靈活不強(qiáng)制路由和藍(lán)圖結(jié)構(gòu)清晰快速出活Django中高大型業(yè)務(wù)系統(tǒng)、后臺(tái)管理復(fù)雜、需要內(nèi)置Admin自帶ORM/認(rèn)證/Admin但項(xiàng)目啟動(dòng)重對(duì)大屏項(xiàng)目來說大量能力用不上FastAPI中高并發(fā)API、需要自動(dòng)生成OpenAPI文檔性能和文檔優(yōu)秀但周邊插件生態(tài)沒有Flask老牌學(xué)習(xí)曲線略陡我在這套系統(tǒng)里選Flask不是因?yàn)樗菷astAPI或Django更“先進(jìn)”而是因?yàn)樗谝粋€(gè)輕量級(jí)數(shù)據(jù)服務(wù)里恰好把靈活性和成熟度平衡得最好。數(shù)據(jù)大屏項(xiàng)目的特點(diǎn)是接口數(shù)量不多但每個(gè)接口背后都要做數(shù)據(jù)聚合、跨表查詢、模型預(yù)測(cè)調(diào)用。Flask的藍(lán)圖機(jī)制可以按業(yè)務(wù)模塊拆路由SQLAlchemy可以方便地對(duì)接數(shù)據(jù)庫全部搞下來不會(huì)覺得自己在寫一堆無意義的模板代碼。1.2 前端為什么不用React也不用純HTML大屏可視化最核心的痛點(diǎn)是圖表多、狀態(tài)多、實(shí)時(shí)刷新需求多。用純HTML加jQuery去寫一個(gè)頁面里幾十個(gè)圖表實(shí)例的狀態(tài)管理會(huì)迅速失控——你很難保證某個(gè)圖表數(shù)據(jù)更新后另一個(gè)關(guān)聯(lián)卡片也跟著變化。這時(shí)候需要一個(gè)能響應(yīng)式綁定數(shù)據(jù)的框架。選擇Vue而不是React最重要的原因是漸進(jìn)式。Vue的模板語法非常接近原生HTML對(duì)于大屏這種以展示為主、交互邏輯相對(duì)固定的頁面學(xué)習(xí)和產(chǎn)出速度都很快。一個(gè)Vue組件里模板負(fù)責(zé)結(jié)構(gòu)、script負(fù)責(zé)數(shù)據(jù)邏輯、style負(fù)責(zé)樣式三個(gè)區(qū)域分得明明白白。對(duì)個(gè)人開發(fā)者來說Vue的單文件組件模式比React“無模板、一切皆函數(shù)”的思路更容易在可視化項(xiàng)目中保持結(jié)構(gòu)清晰。另外一個(gè)實(shí)用因素是ECharts的配合度。大屏項(xiàng)目里ECharts幾乎繞不開而Vue項(xiàng)目里封裝ECharts圖表組件非常順手父組件通過props傳入數(shù)據(jù)子組件里watch數(shù)據(jù)變化再調(diào)用實(shí)例方法重繪。這套模式我在這篇文章后面會(huì)給出具體代碼它比在React useEffect里手動(dòng)管理ECharts實(shí)例的生命周期要直觀不少。1.3 隨機(jī)森林在醫(yī)療表格數(shù)據(jù)上的天然優(yōu)勢(shì)醫(yī)療疾病數(shù)據(jù)通常是表格型數(shù)據(jù)行列結(jié)構(gòu)清晰特征維度不高樣本量不算大。對(duì)這種數(shù)據(jù)結(jié)構(gòu)樹模型天然比深度學(xué)習(xí)吃香。選擇隨機(jī)森林主要是這么幾層考慮能捕捉非線性關(guān)系和特征交互。發(fā)病率不是簡(jiǎn)單的線性疊加它和地區(qū)、年份、疾病類型、人口結(jié)構(gòu)之間都存在復(fù)雜的交互影響。決策樹本身就擅長按特征逐步切分空間隨機(jī)森林把多棵樹集成起來相當(dāng)于在多個(gè)特征子空間中尋找穩(wěn)定規(guī)律。對(duì)數(shù)據(jù)縮放不敏感。神經(jīng)網(wǎng)絡(luò)和不少線性模型需要做標(biāo)準(zhǔn)化或歸一化樹模型完全不用特征是幾百還是幾千都不影響分裂點(diǎn)的選擇。這大大減少了機(jī)器學(xué)習(xí)流程里最容易出錯(cuò)的一個(gè)環(huán)節(jié)。能給出特征重要性。醫(yī)療項(xiàng)目里回答“到底什么因素對(duì)發(fā)病率影響最大”和回答“明年的發(fā)病率是多少”同樣重要。隨機(jī)森林的feature_importances_可以直接輸出各特征的重要性分?jǐn)?shù)對(duì)后續(xù)的數(shù)據(jù)解釋很有價(jià)值。訓(xùn)練成本低不用GPU。醫(yī)療數(shù)據(jù)往往是中小規(guī)模數(shù)據(jù)集隨機(jī)森林在普通CPU機(jī)器上幾分鐘內(nèi)就能完成訓(xùn)練驗(yàn)證對(duì)個(gè)人項(xiàng)目來說非常友好。當(dāng)然隨機(jī)森林不是萬能的。如果數(shù)據(jù)量非常大、特征維度很高或者要做細(xì)粒度時(shí)序預(yù)測(cè)LightGBM和XGBoost通常表現(xiàn)更好。但作為這套系統(tǒng)里的基線模型隨機(jī)森林在穩(wěn)定性和可解釋性之間做到了最穩(wěn)的平衡這也是我最后定格為隨機(jī)森林的原因。1.4 整體鏈路從爬蟲到屏幕的技術(shù)棧分工整個(gè)系統(tǒng)的運(yùn)行鏈路可以用一句話概括requests把公開數(shù)據(jù)抓下來pandas清洗入庫scikit-learn訓(xùn)練隨機(jī)森林模型Flask把庫存數(shù)據(jù)和模型預(yù)測(cè)結(jié)果包裝成APIVue前端通過axios請(qǐng)求API最后用ECharts渲染到大屏上。各層職責(zé)非常清晰分層技術(shù)核心職責(zé)數(shù)據(jù)采集requests pandas請(qǐng)求目標(biāo)站點(diǎn)、解析結(jié)構(gòu)化字段、清洗缺失值數(shù)據(jù)存儲(chǔ)SQLite / MySQL持久化原始數(shù)據(jù)與特征數(shù)據(jù)提供聚合查詢算法預(yù)測(cè)scikit-learn 隨機(jī)森林基于歷史特征預(yù)測(cè)發(fā)病率/發(fā)病數(shù)輸出特征重要性后端服務(wù)Flask SQLAlchemy提供統(tǒng)計(jì)聚合接口、模型預(yù)測(cè)接口、統(tǒng)一響應(yīng)格式前端展示Vue ECharts大屏布局、圖表渲染、定時(shí)輪詢、動(dòng)態(tài)聯(lián)動(dòng)這樣分層之后每個(gè)環(huán)節(jié)都可以獨(dú)立替換。比如不想用隨機(jī)森林了訓(xùn)練一個(gè)XGBoost模型替換掉joblib文件后端接口不用改不想用ECharts了換Chart.js同樣可以對(duì)接。數(shù)據(jù)大屏項(xiàng)目最怕的就是多層耦合按這條鏈路去解耦后續(xù)擴(kuò)展的想象空間會(huì)大很多。2. 數(shù)據(jù)從哪來requests爬蟲的采集策略與429限流完整排坑2.1 數(shù)據(jù)源評(píng)估與目標(biāo)字段設(shè)計(jì)醫(yī)療疾病數(shù)據(jù)的獲取一定要先想清楚“能合法拿到什么”。我在這套系統(tǒng)里選擇的是公開的公共衛(wèi)生統(tǒng)計(jì)網(wǎng)站發(fā)布的年度疾病監(jiān)測(cè)數(shù)據(jù)這類數(shù)據(jù)通常以表格或JSON接口的形式公開不需要登錄沒有隱私字段適合用于學(xué)習(xí)研究。明確數(shù)據(jù)源后下一步就是字段設(shè)計(jì)這一步?jīng)Q定了后續(xù)建模和可視化的上限。我針對(duì)年度疾病監(jiān)測(cè)場(chǎng)景設(shè)計(jì)了以下核心字段字段名類型說明report_yearINTEGER統(tǒng)計(jì)年份disease_nameTEXT疾病名稱provinceTEXT地區(qū)casesINTEGER發(fā)病數(shù)/報(bào)告例數(shù)deathsINTEGER死亡數(shù)incidence_rateFLOAT發(fā)病率每10萬人口mortality_rateFLOAT死亡率每10萬人口age_groupTEXT年齡組sexTEXT性別在庫表結(jié)構(gòu)上使用如下DDL會(huì)清晰很多CREATE TABLE disease_stats ( id INTEGER PRIMARY KEY AUTOINCREMENT, report_year INTEGER NOT NULL, disease_name TEXT NOT NULL, province TEXT NOT NULL, cases INTEGER DEFAULT 0, deaths INTEGER DEFAULT 0, incidence_rate REAL DEFAULT 0.0, mortality_rate REAL DEFAULT 0.0, age_group TEXT, sex TEXT, UNIQUE(report_year, disease_name, province, age_group, sex) );注意最后的UNIQUE約束這個(gè)非常關(guān)鍵。爬蟲重復(fù)執(zhí)行時(shí)很容易產(chǎn)生重復(fù)數(shù)據(jù)加上唯一約束之后后續(xù)用INSERT OR IGNORE或ON CONFLICT DO UPDATE處理就非常輕松不用每次全表去重。2.2 requests采集主流程與基礎(chǔ)代碼目標(biāo)站點(diǎn)一般有兩種數(shù)據(jù)形態(tài)要么是表格頁面要么是JSON接口。表格頁面用requests獲取HTML文本后可以用pandas.read_html快速抽取表格JSON接口則直接解析響應(yīng)內(nèi)容。大部分公共衛(wèi)生數(shù)據(jù)發(fā)布平臺(tái)都提供結(jié)構(gòu)化接口所以優(yōu)先考慮直接解析JSON。一個(gè)比較穩(wěn)妥的基礎(chǔ)采集邏輯大概是這樣的import requests import pandas as pd import sqlite3 import random import time HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: application/json, text/plain, */*, Referer: https://example-public-health-site.org/ } session requests.Session() session.headers.update(HEADERS) def fetch_data(url, params): for attempt in range(1, 6): try: resp session.get(url, paramsparams, timeout10) if resp.status_code 200: return resp.json() elif resp.status_code 429: wait_time int(resp.headers.get(Retry-After, 10)) random.uniform(0, 3) print(f觸發(fā)限流等待 {wait_time:.1f}s 后重試) time.sleep(wait_time) else: print(f請(qǐng)求失敗: {resp.status_code}) except requests.exceptions.RequestException as e: print(f網(wǎng)絡(luò)異常: {e}, 第 {attempt} 次重試) time.sleep(2 ** attempt) return None這里有幾個(gè)容易被忽略的細(xì)節(jié)必須構(gòu)建Session而不是每次直接requests.get。Session會(huì)復(fù)用底層的TCP連接對(duì)目標(biāo)服務(wù)器更友好也能維持必要的會(huì)話狀態(tài)。超時(shí)參數(shù)不能省。requests.get如果不加timeout在網(wǎng)絡(luò)異常時(shí)可能一直掛住整個(gè)爬蟲腳本就卡死了。重試要有退避策略。第1次失敗等2秒第2次失敗等4秒指數(shù)增長避免在服務(wù)端已經(jīng)限流時(shí)繼續(xù)高頻沖擊。拿到原始JSON后通過pandas進(jìn)行字段過濾和數(shù)據(jù)清洗然后寫入數(shù)據(jù)庫def parse_and_save(records, db_pathhealth_data.db): df pd.DataFrame(records) df df.rename(columns{ year: report_year, disease: disease_name, area: province }) # 只保留需要的列防止臟字段 columns [report_year, disease_name, province, cases, deaths, incidence_rate, mortality_rate, age_group, sex] df df[[c for c in columns if c in df.columns]] df df.dropna(subset[report_year, disease_name, province, cases]) conn sqlite3.connect(db_path) df.to_sql(disease_stats, conn, if_existsappend, indexFalse) conn.close() print(f本次寫入 {len(df)} 條記錄)這里要注意pandas.to_sql默認(rèn)不會(huì)做去重所以前面建的UNIQUE索引在這里就開始起作用了。如果表結(jié)構(gòu)里沒有唯一約束重復(fù)運(yùn)行腳本會(huì)導(dǎo)致數(shù)據(jù)顯示翻倍后面還得返工。2.3 429限流的完整排查鏈路標(biāo)題里出現(xiàn)了“429 too many requests”這個(gè)坑在爬蟲階段幾乎一定會(huì)遇到。我說一下我自己經(jīng)歷過的完整排查過程直接給結(jié)論沒有意義把思路寫清楚以后遇到同類問題才好舉一反三?，F(xiàn)象腳本連續(xù)爬到幾百條記錄之后突然拋錯(cuò)日志里出現(xiàn)類似“exceeded retry limit, last status: 429 too many requests”的信息腳本反復(fù)重試仍然無濟(jì)于事甚至手動(dòng)用瀏覽器訪問同一個(gè)URL有時(shí)也會(huì)看到“訪問過于頻繁”的提示。第一步確認(rèn)是本機(jī)網(wǎng)絡(luò)問題還是目標(biāo)站限流。先用curl單獨(dú)請(qǐng)求目標(biāo)接口看是否穩(wěn)定返回200。如果curl穩(wěn)定說明是腳本觸發(fā)了限流如果curl也報(bào)429說明目標(biāo)站整體在限流此時(shí)只能等待。第二步看響應(yīng)頭的限流元數(shù)據(jù)。很多限流接口會(huì)在響應(yīng)頭里反饋剩余配額Retry-After: 告訴你要等多少秒再試X-RateLimit-Limit: 單位時(shí)間窗口內(nèi)允許的最大請(qǐng)求數(shù)X-RateLimit-Remaining: 當(dāng)前剩余的請(qǐng)求額度curl -I https://example-public-health-site.org/api/data?year2024觀察返回頭如果X-RateLimit-Remaining快速下降說明限流策略是“固定窗口計(jì)數(shù)”你的請(qǐng)求頻率太高了。第三步確認(rèn)限流維度。大多數(shù)站點(diǎn)的限流是按IP維度做但也有的按User-Agent做。最簡(jiǎn)單的測(cè)試方法把腳本里的User-Agent換成瀏覽器常用UA如果限流現(xiàn)象立刻消失說明服務(wù)端過濾的是UA如果換UA仍然429說明鎖定的是IP維度。第四步檢查自己的請(qǐng)求時(shí)間間隔分布。很多人寫爬蟲時(shí)雖然加了time.sleep但寫的是固定間隔比如sleep(1)。這其實(shí)是一個(gè)很危險(xiǎn)的寫法固定間隔會(huì)讓請(qǐng)求呈現(xiàn)出明顯的周期規(guī)律服務(wù)端的限流算法很容易識(shí)別這種模式并返回429。正確做法是使用隨機(jī)間隔。我在這個(gè)項(xiàng)目里最終把請(qǐng)求策略改成了這樣def polite_request(url, paramsNone, max_retries4): interval random.uniform(2.5, 5.0) time.sleep(interval) for attempt in range(max_retries): resp session.get(url, paramsparams, timeout10) if resp.status_code 200: return resp.json() if resp.status_code 429: retry_after int(resp.headers.get(Retry-After, 15)) wait_time retry_after random.uniform(0, 5) print(f429限流: 計(jì)劃等待 {wait_time:.1f}s) time.sleep(wait_time) continue return None核心變化是兩點(diǎn)引入隨機(jī)延遲同時(shí)在收到429之后優(yōu)先尊重服務(wù)端給出的Retry-After。還有一個(gè)排查過程中的重要發(fā)現(xiàn)有時(shí)候看到429根本原因是某個(gè)請(qǐng)求的某個(gè)參數(shù)導(dǎo)致目標(biāo)后端觸發(fā)了WAF規(guī)則而不是整體限流。這種情況的特點(diǎn)是其他URL都正常只有特定URL反復(fù)429。排查時(shí)可以打印出觸發(fā)429的完整URL和參數(shù)單獨(dú)拿出來測(cè)試如果不帶某些參數(shù)就正常那大概率是WAF對(duì)這組參數(shù)組合有攔截規(guī)則需要調(diào)整傳參方式或接入源更干凈的數(shù)據(jù)。最后針對(duì)429的根治思路其實(shí)是別硬爬。很多公共衛(wèi)生數(shù)據(jù)平臺(tái)同時(shí)提供“數(shù)據(jù)導(dǎo)出”或“開放API”優(yōu)先使用官方渠道比寫任何爬蟲都穩(wěn)。requests爬蟲適合作為補(bǔ)充手段而不是唯一數(shù)據(jù)來源。我在這套系統(tǒng)里做了雙通道優(yōu)先嘗試獲取平臺(tái)導(dǎo)出的CSV文件缺失部分才用爬蟲補(bǔ)抓。2.4 醫(yī)療類數(shù)據(jù)采集的合規(guī)邊界做醫(yī)療相關(guān)項(xiàng)目合規(guī)問題值得多花兩分鐘思考。我的原則是只采集公開可訪問的數(shù)據(jù)不做逆向、不破解、不繞過任何訪問控制不采集可以與個(gè)人身份對(duì)應(yīng)的數(shù)據(jù)。公共衛(wèi)生統(tǒng)計(jì)網(wǎng)站上發(fā)布的疾病監(jiān)測(cè)數(shù)據(jù)通常是統(tǒng)計(jì)匯總口徑不涉及個(gè)人隱私。但即便如此我在項(xiàng)目里仍然做了這些事數(shù)據(jù)僅用于系統(tǒng)演示與學(xué)習(xí)不對(duì)外提供任何原始數(shù)據(jù)的下載接口爬蟲腳本設(shè)置訪問延遲不沖擊目標(biāo)服務(wù)器不給對(duì)方造成額外負(fù)載數(shù)據(jù)庫中的中間數(shù)據(jù)定期清理前端展示的也只是一定范圍內(nèi)的聚合統(tǒng)計(jì)這些措施本身不復(fù)雜但它們決定了這個(gè)項(xiàng)目能不能站得住腳。醫(yī)療類的數(shù)據(jù)項(xiàng)目技術(shù)能力是一方面數(shù)據(jù)來源的干凈程度是另一方面。3. 隨機(jī)森林模型落地從特征工程到預(yù)測(cè)接口3.1 建模目標(biāo)與訓(xùn)練樣本構(gòu)造爬下來的數(shù)據(jù)是年度維度的歷史統(tǒng)計(jì)那么模型預(yù)測(cè)什么這里定為根據(jù)過去若干年的疾病統(tǒng)計(jì)特征預(yù)測(cè)下一年的發(fā)病率或發(fā)病人數(shù)。預(yù)測(cè)問題的核心在于樣本構(gòu)造。不能把原始表的每一行直接當(dāng)作一個(gè)樣本——某一行只是某一年、某個(gè)地區(qū)、某個(gè)疾病的一個(gè)統(tǒng)計(jì)快照它本身不包含“過去信息”。為了讓模型能夠?qū)W到時(shí)間趨勢(shì)我用滑動(dòng)窗口法構(gòu)造特征取連續(xù)三年t-3、t-2、t-1的數(shù)據(jù)預(yù)測(cè)第t年的發(fā)病率。例如要預(yù)測(cè)2023年A省流感的發(fā)病率就把2020年、2021年、2022年A省流感的相關(guān)指標(biāo)作為特征2023年的發(fā)病率作為標(biāo)簽。這樣每生成一個(gè)訓(xùn)練樣本實(shí)際上就把三年歷史信息壓進(jìn)了特征矩陣。import pandas as pd def build_samples(df, window3): samples [] for (disease, province), grp in df.groupby([disease_name, province]): grp grp.sort_values(report_year) for i in range(window, len(grp)): past grp.iloc[i - window: i] target grp.iloc[i] feature { disease_name: disease, province: province, target_year: target[report_year], lag1_cases: past[cases].iloc[-1], lag2_cases: past[cases].iloc[-2], lag3_cases: past[cases].iloc[-3], lag1_incidence: past[incidence_rate].iloc[-1], lag2_incidence: past[incidence_rate].iloc[-2], lag3_incidence: past[incidence_rate].iloc[-3], avg_incidence: past[incidence_rate].mean(), target_value: target[incidence_rate] } samples.append(feature) return pd.DataFrame(samples)這里我故意保留了disease_name和province這兩個(gè)類別特征而不是直接丟掉。模型需要學(xué)到“不同疾病在不同地區(qū)的發(fā)病基線不同”這個(gè)信息類別特征處理得當(dāng)?shù)脑拰?duì)預(yù)測(cè)精度的提升非常明顯。3.2 特征工程的幾個(gè)關(guān)鍵處理構(gòu)建完原始特征矩陣后下一步是做編碼和類型轉(zhuǎn)換。醫(yī)療數(shù)據(jù)的特征處理里有以下幾個(gè)點(diǎn)需要特別關(guān)注類別特征編碼。disease_name、province這類字段沒法直接放進(jìn)隨機(jī)森林需要用LabelEncoder或OneHotEncoder。對(duì)于樹模型LabelEncoder就夠用了因?yàn)闆Q策樹本質(zhì)上做的是“按特征取值切分”LabelEncoder不會(huì)引入額外的線性假設(shè)。但要注意編碼映射一定要保存下來后面預(yù)測(cè)接口用。缺失值處理。某些地區(qū)或某些年份的數(shù)據(jù)可能缺失樹模型本身能容忍一定缺失但訓(xùn)練和預(yù)測(cè)時(shí)的處理必須一致。最穩(wěn)妥的方式是用前向填充用上一個(gè)有效值補(bǔ)最近一年的缺失值這符合時(shí)間序列的直覺。滯后特征名稱必須規(guī)范。lag1_cases、lag2_cases這類字段在訓(xùn)練和預(yù)測(cè)時(shí)必須完全一致。接口傳參的時(shí)候如果稍有偏差模型接收到的特征順序就會(huì)錯(cuò)位結(jié)果完全不可信。后面我會(huì)建議用pipeline把編碼器和模型打包避免這種問題。3.3 訓(xùn)練、評(píng)估與簡(jiǎn)單調(diào)參訓(xùn)練集和測(cè)試集的劃分必須按時(shí)間順序切不能直接隨機(jī)打亂。因?yàn)檫@是時(shí)間預(yù)測(cè)問題用未來的數(shù)據(jù)去訓(xùn)練、過去的數(shù)據(jù)去測(cè)試屬于典型的數(shù)據(jù)泄漏得到的評(píng)估指標(biāo)會(huì)虛高到?jīng)]有參考價(jià)值。from sklearn.ensemble import RandomForestRegressor from sklearn.preprocessing import LabelEncoder from sklearn.model_selection import train_test_split from sklearn.metrics import mean_absolute_error, mean_squared_error, r2_score import joblib import pandas as pd df pd.read_sql_query(SELECT * FROM disease_stats, conn) samples build_samples(df) le_disease LabelEncoder() le_province LabelEncoder() samples[disease_code] le_disease.fit_transform(samples[disease_name]) samples[province_code] le_province.fit_transform(samples[province]) feature_cols [disease_code, province_code, target_year, lag1_cases, lag2_cases, lag3_cases, lag1_incidence, lag2_incidence, lag3_incidence, avg_incidence] samples samples.sort_values(target_year) train_end int(len(samples) * 0.8) train_df samples.iloc[:train_end] test_df samples.iloc[train_end:] X_train train_df[feature_cols] y_train train_df[target_value] X_test test_df[feature_cols] y_test test_df[target_value] model RandomForestRegressor( n_estimators200, max_depth8, min_samples_leaf3, random_state42 ) model.fit(X_train, y_train) y_pred model.predict(X_test) print(R2:, r2_score(y_test, y_pred)) print(MAE:, mean_absolute_error(y_test, y_pred)) print(RMSE:, mean_squared_error(y_test, y_pred, squaredFalse))對(duì)于樹模型調(diào)參我的經(jīng)驗(yàn)是優(yōu)先控制max_depth和min_samples_leaf而不是一上來就堆n_estimators。n_estimators增大確實(shí)能降低方差但到了一定數(shù)量后收益遞減訓(xùn)練耗時(shí)卻線性增長。max_depth限制每棵樹的復(fù)雜程度min_samples_leaf限制葉子節(jié)點(diǎn)最少樣本數(shù)這兩個(gè)參數(shù)對(duì)控制過擬合的作用最直接。特征重要性也是一個(gè)很值得看的結(jié)果importance pd.Series(model.feature_importances_, indexfeature_cols) importance.sort_values(ascendingFalse).plot(kindbarh)對(duì)這個(gè)項(xiàng)目來說通常會(huì)發(fā)現(xiàn)滯后1年的發(fā)病率lag1_incidence和疾病類別disease_code重要性最高這符合直覺某種疾病最近一年發(fā)病率高下一年大概率也不會(huì)低到哪里去不同疾病的基線差異本身就非常大。3.4 模型序列化與Flask預(yù)測(cè)接口集成訓(xùn)練完成后要把模型、編碼器一起保存下來供Flask后端加載。這里一個(gè)常見的坑是只保存模型忘記保存編碼器導(dǎo)致預(yù)測(cè)接口收到disease_name時(shí)不知道往哪個(gè)編碼映射或者編碼順序不一致預(yù)測(cè)結(jié)果完全亂掉。正確的做法是把編碼器和模型一起打包joblib.dump(model, models/rf_model.pkl) joblib.dump(le_disease, models/le_disease.pkl) joblib.dump(le_province, models/le_province.pkl)Flask后端的預(yù)測(cè)接口實(shí)現(xiàn)from flask import Blueprint, request, jsonify import joblib import pandas as pd import numpy as np model_bp Blueprint(model, __name__) model joblib.load(models/rf_model.pkl) le_disease joblib.load(models/le_disease.pkl) le_province joblib.load(models/le_province.pkl) FEATURE_COLS [disease_code, province_code, target_year, lag1_cases, lag2_cases, lag3_cases, lag1_incidence, lag2_incidence, lag3_incidence, avg_incidence] model_bp.route(/api/model/predict, methods[POST]) def predict(): data request.get_json() try: disease_code le_disease.transform([data[disease_name]])[0] province_code le_province.transform([data[province]])[0] except ValueError: return jsonify({code: 1, msg: 未知的疾病或地區(qū)名稱, data: None}) row [disease_code, province_code, data[target_year], data[lag1_cases], data[lag2_cases], data[lag3_cases], data[lag1_incidence], data[lag2_incidence], data[lag3_incidence], data[avg_incidence]] features np.array([row]) pred model.predict(features)[0] return jsonify({ code: 0, msg: success, data: { pred_incidence: round(float(pred), 4) } })預(yù)測(cè)時(shí)如果傳入了訓(xùn)練數(shù)據(jù)中沒出現(xiàn)過的疾病名稱LabelEncoder的transform會(huì)直接拋ValueError這里做了一層捕獲并返回前端可讀的錯(cuò)誤信息避免一個(gè)大白話的異常堆棧刷到瀏覽器控制臺(tái)里。4. Flask后端與Vue大屏對(duì)接API設(shè)計(jì)、跨域和圖表渲染4.1 后端工程結(jié)構(gòu)與統(tǒng)一響應(yīng)格式亂亂的Flask項(xiàng)目一個(gè)app.py里塞幾百行路由這種結(jié)構(gòu)在一個(gè)綜合項(xiàng)目里完全不可維護(hù)。我在這套系統(tǒng)里用藍(lán)圖把路由拆開service-backend/ ├── app.py # 應(yīng)用入口注冊(cè)藍(lán)圖 ├── config.py # 配置項(xiàng)數(shù)據(jù)庫路徑、模型路徑 ├── models/ │ └── db.py # SQLAlchemy模型 ├── blueprints/ │ ├── stats.py # 統(tǒng)計(jì)數(shù)據(jù)接口 │ ├── disease_api.py # 疾病查詢接口 │ └── model_api.py # 模型預(yù)測(cè)接口 ├── services/ │ ├── data_aggregator.py # 聚合查詢服務(wù) │ └── model_service.py # 模型加載與預(yù)測(cè) └── data/ └── health_data.dbAPI的響應(yīng)格式必須統(tǒng)一這一步省掉前端大量if else。我用的是最經(jīng)典的{code, msg, data}結(jié)構(gòu)。code為0表示成功非0表示業(yè)務(wù)錯(cuò)誤msg是錯(cuò)誤說明data存放真正的數(shù)據(jù)。前端axios的響應(yīng)攔截器直接判斷code不需要每個(gè)請(qǐng)求單獨(dú)處理錯(cuò)誤分支。核心統(tǒng)計(jì)接口設(shè)計(jì)如下接口方法功能返回?cái)?shù)據(jù)/api/summaryGET總覽指標(biāo)病例總數(shù)、死亡總數(shù)、疾病種類數(shù)、地區(qū)數(shù)/api/trendGET歷年發(fā)病趨勢(shì)年份序列 發(fā)病率/發(fā)病數(shù)序列/api/rankingGET疾病/地區(qū)排名前10位疾病/地區(qū)的發(fā)病數(shù)/api/model/predictPOST發(fā)病率預(yù)測(cè)預(yù)測(cè)發(fā)病率4.2 聚合SQL與統(tǒng)計(jì)接口實(shí)現(xiàn)大屏首頁需要展示“總病例數(shù)”“總死亡數(shù)”“疾病種類”“覆蓋地區(qū)”這四個(gè)卡片這些指標(biāo)如果寫四條SQL雖然也能跑但沒必要。一個(gè)聚合查詢就能拿全def get_summary(): row db.session.execute( text( SELECT COUNT(CASE WHEN report_year :max_year THEN 1 END) AS disease_count_total, SUM(cases) AS total_cases, SUM(deaths) AS total_deaths, COUNT(DISTINCT province) AS province_count, MAX(report_year) AS max_year FROM disease_stats ), {max_year: max_year} ).fetchone() return { total_cases: int(row.total_cases or 0), total_deaths: int(row.total_deaths or 0), disease_count: disease_count, province_count: int(row.province_count or 0) }注意SUM(cases)在數(shù)據(jù)缺失時(shí)可能返回NULL所以查詢結(jié)果里要加or 0兜底否則jsonify遇到None值會(huì)序列化成null前端的卡片上可能顯示“undefined”。趨線接口的SQL要注意排序SELECT report_year AS year, SUM(cases) AS total_cases, SUM(deaths) AS total_deaths FROM disease_stats GROUP BY report_year ORDER BY report_year ASC前端折線圖的數(shù)據(jù)順序完全取決于這里有沒有ORDER BY report_year。如果你漏了排序MySQL或SQLite返回的順序可能按主鍵或索引排列前端圖表就會(huì)出現(xiàn)一條亂序的“波浪線”。4.3 跨域問題的兩種解法本地開發(fā)時(shí)Vue跑在8080端口Flask跑在5000端口前端直接請(qǐng)求http://localhost:5000/api/summary必然觸發(fā)跨域?yàn)g覽器會(huì)直接攔截響應(yīng)。這個(gè)項(xiàng)目里我同時(shí)使用了兩種方案開發(fā)環(huán)境用Vue proxy生產(chǎn)環(huán)境用Flask-CORS。開發(fā)環(huán)境Vue proxy配置。在vue.config.js中配置module.exports { devServer: { port: 8080, proxy: { /api: { target: http://127.0.0.1:5000, changeOrigin: true } } } }這樣前端代碼里寫axios.get(/api/summary)時(shí)Vue devServer會(huì)自動(dòng)把請(qǐng)求轉(zhuǎn)發(fā)到Flask的5000端口瀏覽器的同源策略被devServer擋在外面簡(jiǎn)單干凈。生產(chǎn)環(huán)境Flask-CORS指定放行。打包部署時(shí)前端靜態(tài)文件由Nginx托管后端單獨(dú)跑在某個(gè)端口。如果域名不一致仍然會(huì)跨域。這時(shí)可以用Flask-CORSfrom flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})注意開發(fā)時(shí)如果已經(jīng)用了Vue proxy就不要再給后端加CORS了否則會(huì)多一層無用的響應(yīng)頭。兩個(gè)方案二選一不要同時(shí)混用。4.4 Vue大屏布局與ECharts渲染要點(diǎn)大屏頁面的布局我用的是CSS Grid而不是傳統(tǒng)的flex大行。因?yàn)榇笃另撁娴暮诵脑V求是區(qū)塊化、網(wǎng)格化Grid可以非常自然地規(guī)劃出復(fù)雜的行和列。一個(gè)典型的大屏結(jié)構(gòu)是頂部一行放標(biāo)題中間主體分三列——左側(cè)放排名和指標(biāo)卡中間放核心趨勢(shì)大圖右側(cè)放疾病分布圖。我實(shí)際用的Grid定義大致這樣.dashboard { display: grid; grid-template-columns: 1fr 2fr 1fr; grid-template-rows: auto 1fr auto; gap: 16px; height: 100vh; padding: 16px; background: #0f1923; color: #e5e7eb; }左側(cè)和右側(cè)原本都是窄列所以右側(cè)放柱狀圖或餅圖中間寬列放趨勢(shì)折線圖或預(yù)測(cè)結(jié)果展示。ECharts實(shí)例在Vue組件里掛載時(shí)有一個(gè)很關(guān)鍵的坑容器寬度在初始渲染時(shí)可能還沒計(jì)算完成此時(shí)初始化ECharts實(shí)例會(huì)拿到一個(gè)0寬度的容器圖表直接不顯示。解決辦法是在mounted鉤子中使用$nextTick再初始化或者給容器設(shè)置明確的高度和寬度。每個(gè)圖表封裝成一個(gè)獨(dú)立組件比如TrendChart.vuetemplate div refchartRef classchart-container/div /template script import * as echarts from echarts export default { name: TrendChart, props: { chartData: { type: Object, required: true } }, data() { return { chart: null } }, watch: { chartData: { handler(newVal) { if (!this.chart) { this.initChart() } this.renderChart(newVal) }, deep: true } }, methods: { initChart() { if (this.chart) return this.chart echarts.init(this.$refs.chartRef) }, renderChart(data) { this.chart.setOption({ animation: false, // 大屏數(shù)據(jù)更新頻繁, 關(guān)閉動(dòng)畫避免卡頓 tooltip: { trigger: axis }, xAxis: { type: category, data: data.years }, yAxis: { type: value, name: 發(fā)病數(shù)(例) }, series: [{ name: 發(fā)病數(shù), type: line, smooth: true, data: data.cases }] }) } } } /script有一個(gè)細(xì)節(jié)值得單獨(dú)說animation: false。大屏項(xiàng)目里數(shù)據(jù)每隔十幾秒就刷新一次如果開著動(dòng)畫每次刷新圖表都要重新播放一遍過渡動(dòng)畫低配機(jī)器上所有圖表同時(shí)播放動(dòng)畫時(shí)會(huì)非常卡。實(shí)測(cè)下來大屏頁面的圖表直接關(guān)閉動(dòng)畫視覺效果并不受損流暢度提升卻非常明顯。axios請(qǐng)求的封裝也很簡(jiǎn)單import axios from axios const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.response.use( response { const res response.data if (res.code ! 0) { return Promise.reject(new Error(res.msg || 請(qǐng)求失敗)) } return res.data }, error { return Promise.reject(error) } )這樣封裝后每個(gè)業(yè)務(wù)組件里調(diào)用接口時(shí)拿到的直接就是data字段不需要再解一層response.data.data特別舒服。5. 聯(lián)調(diào)階段的數(shù)據(jù)一致性問題與優(yōu)化5.1 日期字段排序錯(cuò)亂聯(lián)調(diào)時(shí)我遇到的第一類問題是前端排序與預(yù)期不符。折線圖的X軸是年份后端返回的接口數(shù)據(jù)經(jīng)過了GROUP BY report_year ORDER BY report_year但前端顯示的年份還是錯(cuò)亂的。排查后定位到問題數(shù)據(jù)庫里report_year是以TEXT類型存儲(chǔ)的排序時(shí)用的是字符串排序。比如2020、2021、2022看起來沒問題但如果年份數(shù)據(jù)里有1999和2000字符串排序就會(huì)把1999排到2000后面嗎實(shí)際上字符串排序“1”在“2”前面1999不會(huì)排錯(cuò)但999這種不規(guī)范的字段就會(huì)出問題。更保險(xiǎn)的做法是在數(shù)據(jù)庫和接口層全部用INT類型存年份后端返回時(shí)再格式化成標(biāo)準(zhǔn)字符串。處理方案是清洗數(shù)據(jù)時(shí)強(qiáng)制做一次類型轉(zhuǎn)換df[report_year] df[report_year].astype(int)前端排序時(shí)也不要依賴字符串默認(rèn)順序盡量用數(shù)值const sortedYears data.years.sort((a, b) a - b)5.2 模型預(yù)測(cè)值與歷史值單位/量綱不一致預(yù)測(cè)接口上線后第一次調(diào)用返回的pred_incidence是一個(gè)0.5左右的值但歷史發(fā)病率在圖表上顯示的是48.6這樣的數(shù)值整整差了約100倍?；艘欢螘r(shí)間排查才發(fā)現(xiàn)問題出在數(shù)據(jù)清洗階段原始數(shù)據(jù)中發(fā)病率的單位是“每10萬人口”還是“每1萬人口”我在不同年份的數(shù)據(jù)源里沒有統(tǒng)一。這種情況在醫(yī)療數(shù)據(jù)里非常常見因?yàn)椴煌y(tǒng)計(jì)口徑、不同發(fā)布平臺(tái)可能用不同的分母。解決方式是在數(shù)據(jù)入庫時(shí)做一個(gè)規(guī)范化統(tǒng)一轉(zhuǎn)成“每10萬人口”的發(fā)病率。df[incidence_rate] df[incidence_rate].apply( lambda x: x * 10 if source_unit per_wan else x )還有就是模型訓(xùn)練時(shí)如果對(duì)特征做了標(biāo)準(zhǔn)化預(yù)測(cè)接口也要對(duì)輸入特征做相同的標(biāo)準(zhǔn)化處理。我在最終方案里把所有預(yù)處理步驟都封裝成一個(gè)transform_features函數(shù)訓(xùn)練和預(yù)測(cè)共用同一份代碼從根上消除“訓(xùn)練時(shí)做了一步處理、接口調(diào)用時(shí)漏掉”的可能性。5.3 大屏渲染卡頓大屏頁面初次加載時(shí)我一度同時(shí)發(fā)起8個(gè)接口請(qǐng)求每個(gè)請(qǐng)求返回幾百條數(shù)據(jù)然后所有圖表同步渲染。結(jié)果就是頁面加載卡頓低配機(jī)器上風(fēng)扇狂轉(zhuǎn)。優(yōu)化思路是三層接口合并。把首頁需要的指標(biāo)卡數(shù)據(jù)、趨勢(shì)數(shù)據(jù)、排名數(shù)據(jù)合并成2到3個(gè)聚合接口減少HTTP請(qǐng)求的次數(shù)。前端一次拿到整個(gè)數(shù)據(jù)包再分發(fā)到各個(gè)子組件。關(guān)閉ECharts動(dòng)畫。前面已經(jīng)提到大屏場(chǎng)景下動(dòng)畫收益極低但幀率損耗極大直接設(shè)置animation: false。數(shù)據(jù)聚合下推。排名圖前端只需要前10名就千萬不要把幾百個(gè)地區(qū)的數(shù)據(jù)全部返回而是在SQL層用LIMIT 10先過濾。大屏項(xiàng)目里網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量越小渲染壓力越小。5.4 項(xiàng)目目錄與部署建議整個(gè)項(xiàng)目最終產(chǎn)物分兩部分后端Flask服務(wù)、前端Vue構(gòu)建產(chǎn)物。本地開發(fā)時(shí)直接用python app.py啟動(dòng)Flasknpm run serve啟動(dòng)Vue devServer。生產(chǎn)部署我采用的是Nginx托管前端靜態(tài)文件加反向代理后端接口的方式server { listen 80; server_name your-server-domain; root /var/www/dashboard/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:5000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }后端用gunicorn啟動(dòng)gunicorn -w 4 -b 127.0.0.1:5000 app:app如果你更喜歡容器化用docker-compose把所有服務(wù)編排起來也行但要注意Flask容器和前端Nginx容器共享同一個(gè)網(wǎng)絡(luò)前端的API地址要配置成后端服務(wù)名稱而不是localhost。還有一個(gè)很實(shí)用的建議爬蟲腳本不要和Flask服務(wù)綁定在同一個(gè)進(jìn)程里。爬蟲偶爾會(huì)卡在網(wǎng)絡(luò)請(qǐng)求上如果把它放在Flask進(jìn)程里一個(gè)阻塞就可能拖慢所有API響應(yīng)。最好讓爬蟲作為獨(dú)立腳本或定時(shí)任務(wù)運(yùn)行數(shù)據(jù)寫庫后Flask只負(fù)責(zé)讀庫和預(yù)測(cè)兩者解耦。最后幾個(gè)實(shí)操體會(huì)如果只讓我留一句話就是先跑通最小閉環(huán)再裝飾細(xì)節(jié)。這個(gè)項(xiàng)目我最初的版本甚至沒有隨機(jī)森林只有爬蟲、數(shù)據(jù)庫和一個(gè)柱狀圖。等這條鏈路完全通了之后模型、更多圖表、更復(fù)雜的布局才逐步加進(jìn)去。先讓數(shù)據(jù)能從源端流到屏幕項(xiàng)目的信心和價(jià)值感就完全不一樣了。另外一個(gè)小技巧醫(yī)療數(shù)據(jù)的字段名很容易產(chǎn)生歧義cases、deaths、incidence這些中英文混用聯(lián)調(diào)時(shí)特別容易鬧笑話。建議在數(shù)據(jù)入庫時(shí)就統(tǒng)一字段命名規(guī)范后端API用snake_case前端展示層再轉(zhuǎn)換成中文標(biāo)題別小看這個(gè)細(xì)節(jié)它能幫你省下大量對(duì)齊時(shí)間。如果后續(xù)想往上擴(kuò)展可以試試給系統(tǒng)加上用戶登錄權(quán)限、定時(shí)爬取任務(wù)、圖表下鉆聯(lián)動(dòng)或者把隨機(jī)森林換成XGBoost做一組對(duì)比實(shí)驗(yàn)。但請(qǐng)記住一點(diǎn)在這個(gè)項(xiàng)目里算法只是其中一環(huán)數(shù)據(jù)的準(zhǔn)確性和前后端鏈路的穩(wěn)定才是真正決定成敗的部分。把最基礎(chǔ)的數(shù)據(jù)鏈路做扎實(shí)大屏才有底氣擺上臺(tái)面。本文還有配套的精品資源點(diǎn)擊獲取