簡介本資源是一套面向本科畢業(yè)設(shè)計與課程綜合實踐的醫(yī)療健康領(lǐng)域數(shù)據(jù)分析可視化系統(tǒng)聚焦疾病數(shù)據(jù)挖掘與大屏展示全流程適用于計算機、醫(yī)學(xué)信息工程等專業(yè)學(xué)生開展項目實戰(zhàn)與算法應(yīng)用學(xué)習(xí)。系統(tǒng)采用Flask構(gòu)建后端API服務(wù)Vue實現(xiàn)前端響應(yīng)式大屏集成requests網(wǎng)絡(luò)爬蟲自動采集疾病相關(guān)公開數(shù)據(jù)并基于隨機森林算法完成疾病風(fēng)險預(yù)測建模與特征重要性分析。壓縮包共67個文件含7個核心Python腳本含爬蟲、模型訓(xùn)練與接口邏輯、7個Vue組件文件、7個JavaScript交互模塊、5個JSON配置與數(shù)據(jù)文件、4個HTML頁面及配套SQL數(shù)據(jù)庫腳本、Word論文文檔、部署調(diào)試說明與3張運行效果截圖整體僅1.32MB結(jié)構(gòu)清晰、開箱即用。目前已有43人學(xué)習(xí)下載提供從數(shù)據(jù)獲取、清洗、建模到可視化落地的完整閉環(huán)方案特別適合需要快速驗證機器學(xué)習(xí)與前后端聯(lián)調(diào)能力的學(xué)習(xí)者。 這年頭的數(shù)據(jù)可視化項目單拿一個框架出來已經(jīng)不太能打了。真正能讓人眼前一亮的往往是那種“爬蟲把數(shù)據(jù)喂進來、算法把價值算出來、前端把結(jié)果擺上桌”的完整鏈路。這套基于Python Flask Vue 隨機森林 requests搭建的醫(yī)療疾病數(shù)據(jù)分析大屏系統(tǒng)就是把這幾塊硬生生串成了一條線。很多人看到“醫(yī)療疾病”四個字覺得門檻高其實拆開看核心就三件事數(shù)據(jù)從哪來、預(yù)測怎么做、大屏怎么畫。這篇文章我就按實際落地的順序把選型邏輯、爬蟲階段的限流排坑、隨機森林從訓(xùn)練到接口、前后端對接的隱藏問題全部攤開講適合正在做數(shù)據(jù)類項目作品、畢業(yè)設(shè)計或者想體驗一次全棧加機器學(xué)習(xí)全流程的開發(fā)者參考。1. 選型邏輯這套系統(tǒng)為什么鎖定FlaskVue隨機森林1.1 后端輕量化選型Python生態(tài)是出發(fā)點先說一個總原則當(dāng)一個項目里既有數(shù)據(jù)采集、又有機器學(xué)習(xí)、又有Web服務(wù)時語言統(tǒng)一帶來的收益遠超所有框架層面的微優(yōu)化。爬蟲用requests、數(shù)據(jù)處理用pandas、建模用scikit-learn這些全是Python生態(tài)的東西。如果后端再選Python整條數(shù)據(jù)管道可以用一套語言推理下來不用在語言切換中反復(fù)維護上下文?？蚣軐用鍲lask、Django、FastAPI是這個生態(tài)里最常被比較的三個。從落地感受來看框架上手成本適合場景實際體驗Flask低輕量API、中小型數(shù)據(jù)服務(wù)、個人項目靈活不強制路由和藍圖結(jié)構(gòu)清晰快速出活Django中高大型業(yè)務(wù)系統(tǒng)、后臺管理復(fù)雜、需要內(nèi)置Admin自帶ORM/認證/Admin但項目啟動重對大屏項目來說大量能力用不上FastAPI中高并發(fā)API、需要自動生成OpenAPI文檔性能和文檔優(yōu)秀但周邊插件生態(tài)沒有Flask老牌學(xué)習(xí)曲線略陡我在這套系統(tǒng)里選Flask不是因為它比FastAPI或Django更“先進”而是因為它在一個輕量級數(shù)據(jù)服務(wù)里恰好把靈活性和成熟度平衡得最好。數(shù)據(jù)大屏項目的特點是接口數(shù)量不多但每個接口背后都要做數(shù)據(jù)聚合、跨表查詢、模型預(yù)測調(diào)用。Flask的藍圖機制可以按業(yè)務(wù)模塊拆路由SQLAlchemy可以方便地對接數(shù)據(jù)庫全部搞下來不會覺得自己在寫一堆無意義的模板代碼。1.2 前端為什么不用React也不用純HTML大屏可視化最核心的痛點是圖表多、狀態(tài)多、實時刷新需求多。用純HTML加jQuery去寫一個頁面里幾十個圖表實例的狀態(tài)管理會迅速失控——你很難保證某個圖表數(shù)據(jù)更新后另一個關(guān)聯(lián)卡片也跟著變化。這時候需要一個能響應(yīng)式綁定數(shù)據(jù)的框架。選擇Vue而不是React最重要的原因是漸進式。Vue的模板語法非常接近原生HTML對于大屏這種以展示為主、交互邏輯相對固定的頁面學(xué)習(xí)和產(chǎn)出速度都很快。一個Vue組件里模板負責(zé)結(jié)構(gòu)、script負責(zé)數(shù)據(jù)邏輯、style負責(zé)樣式三個區(qū)域分得明明白白。對個人開發(fā)者來說Vue的單文件組件模式比React“無模板、一切皆函數(shù)”的思路更容易在可視化項目中保持結(jié)構(gòu)清晰。另外一個實用因素是ECharts的配合度。大屏項目里ECharts幾乎繞不開而Vue項目里封裝ECharts圖表組件非常順手父組件通過props傳入數(shù)據(jù)子組件里watch數(shù)據(jù)變化再調(diào)用實例方法重繪。這套模式我在這篇文章后面會給出具體代碼它比在React useEffect里手動管理ECharts實例的生命周期要直觀不少。1.3 隨機森林在醫(yī)療表格數(shù)據(jù)上的天然優(yōu)勢醫(yī)療疾病數(shù)據(jù)通常是表格型數(shù)據(jù)行列結(jié)構(gòu)清晰特征維度不高樣本量不算大。對這種數(shù)據(jù)結(jié)構(gòu)樹模型天然比深度學(xué)習(xí)吃香。選擇隨機森林主要是這么幾層考慮能捕捉非線性關(guān)系和特征交互。發(fā)病率不是簡單的線性疊加它和地區(qū)、年份、疾病類型、人口結(jié)構(gòu)之間都存在復(fù)雜的交互影響。決策樹本身就擅長按特征逐步切分空間隨機森林把多棵樹集成起來相當(dāng)于在多個特征子空間中尋找穩(wěn)定規(guī)律。對數(shù)據(jù)縮放不敏感。神經(jīng)網(wǎng)絡(luò)和不少線性模型需要做標(biāo)準(zhǔn)化或歸一化樹模型完全不用特征是幾百還是幾千都不影響分裂點的選擇。這大大減少了機器學(xué)習(xí)流程里最容易出錯的一個環(huán)節(jié)。能給出特征重要性。醫(yī)療項目里回答“到底什么因素對發(fā)病率影響最大”和回答“明年的發(fā)病率是多少”同樣重要。隨機森林的feature_importances_可以直接輸出各特征的重要性分?jǐn)?shù)對后續(xù)的數(shù)據(jù)解釋很有價值。訓(xùn)練成本低不用GPU。醫(yī)療數(shù)據(jù)往往是中小規(guī)模數(shù)據(jù)集隨機森林在普通CPU機器上幾分鐘內(nèi)就能完成訓(xùn)練驗證對個人項目來說非常友好。當(dāng)然隨機森林不是萬能的。如果數(shù)據(jù)量非常大、特征維度很高或者要做細粒度時序預(yù)測LightGBM和XGBoost通常表現(xiàn)更好。但作為這套系統(tǒng)里的基線模型隨機森林在穩(wěn)定性和可解釋性之間做到了最穩(wěn)的平衡這也是我最后定格為隨機森林的原因。1.4 整體鏈路從爬蟲到屏幕的技術(shù)棧分工整個系統(tǒng)的運行鏈路可以用一句話概括requests把公開數(shù)據(jù)抓下來pandas清洗入庫scikit-learn訓(xùn)練隨機森林模型Flask把庫存數(shù)據(jù)和模型預(yù)測結(jié)果包裝成APIVue前端通過axios請求API最后用ECharts渲染到大屏上。各層職責(zé)非常清晰分層技術(shù)核心職責(zé)數(shù)據(jù)采集requests pandas請求目標(biāo)站點、解析結(jié)構(gòu)化字段、清洗缺失值數(shù)據(jù)存儲SQLite / MySQL持久化原始數(shù)據(jù)與特征數(shù)據(jù)提供聚合查詢算法預(yù)測scikit-learn 隨機森林基于歷史特征預(yù)測發(fā)病率/發(fā)病數(shù)輸出特征重要性后端服務(wù)Flask SQLAlchemy提供統(tǒng)計聚合接口、模型預(yù)測接口、統(tǒng)一響應(yīng)格式前端展示Vue ECharts大屏布局、圖表渲染、定時輪詢、動態(tài)聯(lián)動這樣分層之后每個環(huán)節(jié)都可以獨立替換。比如不想用隨機森林了訓(xùn)練一個XGBoost模型替換掉joblib文件后端接口不用改不想用ECharts了換Chart.js同樣可以對接。數(shù)據(jù)大屏項目最怕的就是多層耦合按這條鏈路去解耦后續(xù)擴展的想象空間會大很多。2. 數(shù)據(jù)從哪來requests爬蟲的采集策略與429限流完整排坑2.1 數(shù)據(jù)源評估與目標(biāo)字段設(shè)計醫(yī)療疾病數(shù)據(jù)的獲取一定要先想清楚“能合法拿到什么”。我在這套系統(tǒng)里選擇的是公開的公共衛(wèi)生統(tǒng)計網(wǎng)站發(fā)布的年度疾病監(jiān)測數(shù)據(jù)這類數(shù)據(jù)通常以表格或JSON接口的形式公開不需要登錄沒有隱私字段適合用于學(xué)習(xí)研究。明確數(shù)據(jù)源后下一步就是字段設(shè)計這一步?jīng)Q定了后續(xù)建模和可視化的上限。我針對年度疾病監(jiān)測場景設(shè)計了以下核心字段字段名類型說明report_yearINTEGER統(tǒng)計年份disease_nameTEXT疾病名稱provinceTEXT地區(qū)casesINTEGER發(fā)病數(shù)/報告例數(shù)deathsINTEGER死亡數(shù)incidence_rateFLOAT發(fā)病率每10萬人口mortality_rateFLOAT死亡率每10萬人口age_groupTEXT年齡組sexTEXT性別在庫表結(jié)構(gòu)上使用如下DDL會清晰很多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約束這個非常關(guān)鍵。爬蟲重復(fù)執(zhí)行時很容易產(chǎn)生重復(fù)數(shù)據(jù)加上唯一約束之后后續(xù)用INSERT OR IGNORE或ON CONFLICT DO UPDATE處理就非常輕松不用每次全表去重。2.2 requests采集主流程與基礎(chǔ)代碼目標(biāo)站點一般有兩種數(shù)據(jù)形態(tài)要么是表格頁面要么是JSON接口。表格頁面用requests獲取HTML文本后可以用pandas.read_html快速抽取表格JSON接口則直接解析響應(yīng)內(nèi)容。大部分公共衛(wèi)生數(shù)據(jù)發(fā)布平臺都提供結(jié)構(gòu)化接口所以優(yōu)先考慮直接解析JSON。一個比較穩(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請求失敗: {resp.status_code}) except requests.exceptions.RequestException as e: print(f網(wǎng)絡(luò)異常: {e}, 第 {attempt} 次重試) time.sleep(2 ** attempt) return None這里有幾個容易被忽略的細節(jié)必須構(gòu)建Session而不是每次直接requests.get。Session會復(fù)用底層的TCP連接對目標(biāo)服務(wù)器更友好也能維持必要的會話狀態(tài)。超時參數(shù)不能省。requests.get如果不加timeout在網(wǎng)絡(luò)異常時可能一直掛住整個爬蟲腳本就卡死了。重試要有退避策略。第1次失敗等2秒第2次失敗等4秒指數(shù)增長避免在服務(wù)端已經(jīng)限流時繼續(xù)高頻沖擊。拿到原始JSON后通過pandas進行字段過濾和數(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默認不會做去重所以前面建的UNIQUE索引在這里就開始起作用了。如果表結(jié)構(gòu)里沒有唯一約束重復(fù)運行腳本會導(dǎo)致數(shù)據(jù)顯示翻倍后面還得返工。2.3 429限流的完整排查鏈路標(biāo)題里出現(xiàn)了“429 too many requests”這個坑在爬蟲階段幾乎一定會遇到。我說一下我自己經(jīng)歷過的完整排查過程直接給結(jié)論沒有意義把思路寫清楚以后遇到同類問題才好舉一反三?，F(xiàn)象腳本連續(xù)爬到幾百條記錄之后突然拋錯日志里出現(xiàn)類似“exceeded retry limit, last status: 429 too many requests”的信息腳本反復(fù)重試仍然無濟于事甚至手動用瀏覽器訪問同一個URL有時也會看到“訪問過于頻繁”的提示。第一步確認是本機網(wǎng)絡(luò)問題還是目標(biāo)站限流。先用curl單獨請求目標(biāo)接口看是否穩(wěn)定返回200。如果curl穩(wěn)定說明是腳本觸發(fā)了限流如果curl也報429說明目標(biāo)站整體在限流此時只能等待。第二步看響應(yīng)頭的限流元數(shù)據(jù)。很多限流接口會在響應(yīng)頭里反饋剩余配額Retry-After: 告訴你要等多少秒再試X-RateLimit-Limit: 單位時間窗口內(nèi)允許的最大請求數(shù)X-RateLimit-Remaining: 當(dāng)前剩余的請求額度curl -I https://example-public-health-site.org/api/data?year2024觀察返回頭如果X-RateLimit-Remaining快速下降說明限流策略是“固定窗口計數(shù)”你的請求頻率太高了。第三步確認限流維度。大多數(shù)站點的限流是按IP維度做但也有的按User-Agent做。最簡單的測試方法把腳本里的User-Agent換成瀏覽器常用UA如果限流現(xiàn)象立刻消失說明服務(wù)端過濾的是UA如果換UA仍然429說明鎖定的是IP維度。第四步檢查自己的請求時間間隔分布。很多人寫爬蟲時雖然加了time.sleep但寫的是固定間隔比如sleep(1)。這其實是一個很危險的寫法固定間隔會讓請求呈現(xiàn)出明顯的周期規(guī)律服務(wù)端的限流算法很容易識別這種模式并返回429。正確做法是使用隨機間隔。我在這個項目里最終把請求策略改成了這樣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限流: 計劃等待 {wait_time:.1f}s) time.sleep(wait_time) continue return None核心變化是兩點引入隨機延遲同時在收到429之后優(yōu)先尊重服務(wù)端給出的Retry-After。還有一個排查過程中的重要發(fā)現(xiàn)有時候看到429根本原因是某個請求的某個參數(shù)導(dǎo)致目標(biāo)后端觸發(fā)了WAF規(guī)則而不是整體限流。這種情況的特點是其他URL都正常只有特定URL反復(fù)429。排查時可以打印出觸發(fā)429的完整URL和參數(shù)單獨拿出來測試如果不帶某些參數(shù)就正常那大概率是WAF對這組參數(shù)組合有攔截規(guī)則需要調(diào)整傳參方式或接入源更干凈的數(shù)據(jù)。最后針對429的根治思路其實是別硬爬。很多公共衛(wèi)生數(shù)據(jù)平臺同時提供“數(shù)據(jù)導(dǎo)出”或“開放API”優(yōu)先使用官方渠道比寫任何爬蟲都穩(wěn)。requests爬蟲適合作為補充手段而不是唯一數(shù)據(jù)來源。我在這套系統(tǒng)里做了雙通道優(yōu)先嘗試獲取平臺導(dǎo)出的CSV文件缺失部分才用爬蟲補抓。2.4 醫(yī)療類數(shù)據(jù)采集的合規(guī)邊界做醫(yī)療相關(guān)項目合規(guī)問題值得多花兩分鐘思考。我的原則是只采集公開可訪問的數(shù)據(jù)不做逆向、不破解、不繞過任何訪問控制不采集可以與個人身份對應(yīng)的數(shù)據(jù)。公共衛(wèi)生統(tǒng)計網(wǎng)站上發(fā)布的疾病監(jiān)測數(shù)據(jù)通常是統(tǒng)計匯總口徑不涉及個人隱私。但即便如此我在項目里仍然做了這些事數(shù)據(jù)僅用于系統(tǒng)演示與學(xué)習(xí)不對外提供任何原始數(shù)據(jù)的下載接口爬蟲腳本設(shè)置訪問延遲不沖擊目標(biāo)服務(wù)器不給對方造成額外負載數(shù)據(jù)庫中的中間數(shù)據(jù)定期清理前端展示的也只是一定范圍內(nèi)的聚合統(tǒng)計這些措施本身不復(fù)雜但它們決定了這個項目能不能站得住腳。醫(yī)療類的數(shù)據(jù)項目技術(shù)能力是一方面數(shù)據(jù)來源的干凈程度是另一方面。3. 隨機森林模型落地從特征工程到預(yù)測接口3.1 建模目標(biāo)與訓(xùn)練樣本構(gòu)造爬下來的數(shù)據(jù)是年度維度的歷史統(tǒng)計那么模型預(yù)測什么這里定為根據(jù)過去若干年的疾病統(tǒng)計特征預(yù)測下一年的發(fā)病率或發(fā)病人數(shù)。預(yù)測問題的核心在于樣本構(gòu)造。不能把原始表的每一行直接當(dāng)作一個樣本——某一行只是某一年、某個地區(qū)、某個疾病的一個統(tǒng)計快照它本身不包含“過去信息”。為了讓模型能夠?qū)W到時間趨勢我用滑動窗口法構(gòu)造特征取連續(xù)三年t-3、t-2、t-1的數(shù)據(jù)預(yù)測第t年的發(fā)病率。例如要預(yù)測2023年A省流感的發(fā)病率就把2020年、2021年、2022年A省流感的相關(guān)指標(biāo)作為特征2023年的發(fā)病率作為標(biāo)簽。這樣每生成一個訓(xù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這兩個類別特征而不是直接丟掉。模型需要學(xué)到“不同疾病在不同地區(qū)的發(fā)病基線不同”這個信息類別特征處理得當(dāng)?shù)脑拰︻A(yù)測精度的提升非常明顯。3.2 特征工程的幾個關(guān)鍵處理構(gòu)建完原始特征矩陣后下一步是做編碼和類型轉(zhuǎn)換。醫(yī)療數(shù)據(jù)的特征處理里有以下幾個點需要特別關(guān)注類別特征編碼。disease_name、province這類字段沒法直接放進隨機森林需要用LabelEncoder或OneHotEncoder。對于樹模型LabelEncoder就夠用了因為決策樹本質(zhì)上做的是“按特征取值切分”LabelEncoder不會引入額外的線性假設(shè)。但要注意編碼映射一定要保存下來后面預(yù)測接口用。缺失值處理。某些地區(qū)或某些年份的數(shù)據(jù)可能缺失樹模型本身能容忍一定缺失但訓(xùn)練和預(yù)測時的處理必須一致。最穩(wěn)妥的方式是用前向填充用上一個有效值補最近一年的缺失值這符合時間序列的直覺。滯后特征名稱必須規(guī)范。lag1_cases、lag2_cases這類字段在訓(xùn)練和預(yù)測時必須完全一致。接口傳參的時候如果稍有偏差模型接收到的特征順序就會錯位結(jié)果完全不可信。后面我會建議用pipeline把編碼器和模型打包避免這種問題。3.3 訓(xùn)練、評估與簡單調(diào)參訓(xùn)練集和測試集的劃分必須按時間順序切不能直接隨機打亂。因為這是時間預(yù)測問題用未來的數(shù)據(jù)去訓(xùn)練、過去的數(shù)據(jù)去測試屬于典型的數(shù)據(jù)泄漏得到的評估指標(biāo)會虛高到?jīng)]有參考價值。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))對于樹模型調(diào)參我的經(jīng)驗是優(yōu)先控制max_depth和min_samples_leaf而不是一上來就堆n_estimators。n_estimators增大確實能降低方差但到了一定數(shù)量后收益遞減訓(xùn)練耗時卻線性增長。max_depth限制每棵樹的復(fù)雜程度min_samples_leaf限制葉子節(jié)點最少樣本數(shù)這兩個參數(shù)對控制過擬合的作用最直接。特征重要性也是一個很值得看的結(jié)果importance pd.Series(model.feature_importances_, indexfeature_cols) importance.sort_values(ascendingFalse).plot(kindbarh)對這個項目來說通常會發(fā)現(xiàn)滯后1年的發(fā)病率lag1_incidence和疾病類別disease_code重要性最高這符合直覺某種疾病最近一年發(fā)病率高下一年大概率也不會低到哪里去不同疾病的基線差異本身就非常大。3.4 模型序列化與Flask預(yù)測接口集成訓(xùn)練完成后要把模型、編碼器一起保存下來供Flask后端加載。這里一個常見的坑是只保存模型忘記保存編碼器導(dǎo)致預(yù)測接口收到disease_name時不知道往哪個編碼映射或者編碼順序不一致預(yù)測結(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ù)測接口實現(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ù)測時如果傳入了訓(xùn)練數(shù)據(jù)中沒出現(xiàn)過的疾病名稱LabelEncoder的transform會直接拋ValueError這里做了一層捕獲并返回前端可讀的錯誤信息避免一個大白話的異常堆棧刷到瀏覽器控制臺里。4. Flask后端與Vue大屏對接API設(shè)計、跨域和圖表渲染4.1 后端工程結(jié)構(gòu)與統(tǒng)一響應(yīng)格式亂亂的Flask項目一個app.py里塞幾百行路由這種結(jié)構(gòu)在一個綜合項目里完全不可維護。我在這套系統(tǒng)里用藍圖把路由拆開service-backend/ ├── app.py # 應(yīng)用入口注冊藍圖 ├── config.py # 配置項數(shù)據(jù)庫路徑、模型路徑 ├── models/ │ └── db.py # SQLAlchemy模型 ├── blueprints/ │ ├── stats.py # 統(tǒng)計數(shù)據(jù)接口 │ ├── disease_api.py # 疾病查詢接口 │ └── model_api.py # 模型預(yù)測接口 ├── services/ │ ├── data_aggregator.py # 聚合查詢服務(wù) │ └── model_service.py # 模型加載與預(yù)測 └── data/ └── health_data.dbAPI的響應(yīng)格式必須統(tǒng)一這一步省掉前端大量if else。我用的是最經(jīng)典的{code, msg, data}結(jié)構(gòu)。code為0表示成功非0表示業(yè)務(wù)錯誤msg是錯誤說明data存放真正的數(shù)據(jù)。前端axios的響應(yīng)攔截器直接判斷code不需要每個請求單獨處理錯誤分支。核心統(tǒng)計接口設(shè)計如下接口方法功能返回數(shù)據(jù)/api/summaryGET總覽指標(biāo)病例總數(shù)、死亡總數(shù)、疾病種類數(shù)、地區(qū)數(shù)/api/trendGET歷年發(fā)病趨勢年份序列 發(fā)病率/發(fā)病數(shù)序列/api/rankingGET疾病/地區(qū)排名前10位疾病/地區(qū)的發(fā)病數(shù)/api/model/predictPOST發(fā)病率預(yù)測預(yù)測發(fā)病率4.2 聚合SQL與統(tǒng)計接口實現(xiàn)大屏首頁需要展示“總病例數(shù)”“總死亡數(shù)”“疾病種類”“覆蓋地區(qū)”這四個卡片這些指標(biāo)如果寫四條SQL雖然也能跑但沒必要。一個聚合查詢就能拿全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ù)缺失時可能返回NULL所以查詢結(jié)果里要加or 0兜底否則jsonify遇到None值會序列化成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返回的順序可能按主鍵或索引排列前端圖表就會出現(xiàn)一條亂序的“波浪線”。4.3 跨域問題的兩種解法本地開發(fā)時Vue跑在8080端口Flask跑在5000端口前端直接請求http://localhost:5000/api/summary必然觸發(fā)跨域瀏覽器會直接攔截響應(yīng)。這個項目里我同時使用了兩種方案開發(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)時Vue devServer會自動把請求轉(zhuǎn)發(fā)到Flask的5000端口瀏覽器的同源策略被devServer擋在外面簡單干凈。生產(chǎn)環(huán)境Flask-CORS指定放行。打包部署時前端靜態(tài)文件由Nginx托管后端單獨跑在某個端口。如果域名不一致仍然會跨域。這時可以用Flask-CORSfrom flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})注意開發(fā)時如果已經(jīng)用了Vue proxy就不要再給后端加CORS了否則會多一層無用的響應(yīng)頭。兩個方案二選一不要同時混用。4.4 Vue大屏布局與ECharts渲染要點大屏頁面的布局我用的是CSS Grid而不是傳統(tǒng)的flex大行。因為大屏頁面的核心訴求是區(qū)塊化、網(wǎng)格化Grid可以非常自然地規(guī)劃出復(fù)雜的行和列。一個典型的大屏結(jié)構(gòu)是頂部一行放標(biāo)題中間主體分三列——左側(cè)放排名和指標(biāo)卡中間放核心趨勢大圖右側(cè)放疾病分布圖。我實際用的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è)放柱狀圖或餅圖中間寬列放趨勢折線圖或預(yù)測結(jié)果展示。ECharts實例在Vue組件里掛載時有一個很關(guān)鍵的坑容器寬度在初始渲染時可能還沒計算完成此時初始化ECharts實例會拿到一個0寬度的容器圖表直接不顯示。解決辦法是在mounted鉤子中使用$nextTick再初始化或者給容器設(shè)置明確的高度和寬度。每個圖表封裝成一個獨立組件比如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)閉動畫避免卡頓 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有一個細節(jié)值得單獨說animation: false。大屏項目里數(shù)據(jù)每隔十幾秒就刷新一次如果開著動畫每次刷新圖表都要重新播放一遍過渡動畫低配機器上所有圖表同時播放動畫時會非?？ā崪y下來大屏頁面的圖表直接關(guān)閉動畫視覺效果并不受損流暢度提升卻非常明顯。axios請求的封裝也很簡單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 || 請求失敗)) } return res.data }, error { return Promise.reject(error) } )這樣封裝后每個業(yè)務(wù)組件里調(diào)用接口時拿到的直接就是data字段不需要再解一層response.data.data特別舒服。5. 聯(lián)調(diào)階段的數(shù)據(jù)一致性問題與優(yōu)化5.1 日期字段排序錯亂聯(lián)調(diào)時我遇到的第一類問題是前端排序與預(yù)期不符。折線圖的X軸是年份后端返回的接口數(shù)據(jù)經(jīng)過了GROUP BY report_year ORDER BY report_year但前端顯示的年份還是錯亂的。排查后定位到問題數(shù)據(jù)庫里report_year是以TEXT類型存儲的排序時用的是字符串排序。比如2020、2021、2022看起來沒問題但如果年份數(shù)據(jù)里有1999和2000字符串排序就會把1999排到2000后面嗎實際上字符串排序“1”在“2”前面1999不會排錯但999這種不規(guī)范的字段就會出問題。更保險的做法是在數(shù)據(jù)庫和接口層全部用INT類型存年份后端返回時再格式化成標(biāo)準(zhǔn)字符串。處理方案是清洗數(shù)據(jù)時強制做一次類型轉(zhuǎn)換df[report_year] df[report_year].astype(int)前端排序時也不要依賴字符串默認順序盡量用數(shù)值const sortedYears data.years.sort((a, b) a - b)5.2 模型預(yù)測值與歷史值單位/量綱不一致預(yù)測接口上線后第一次調(diào)用返回的pred_incidence是一個0.5左右的值但歷史發(fā)病率在圖表上顯示的是48.6這樣的數(shù)值整整差了約100倍。花了一段時間排查才發(fā)現(xiàn)問題出在數(shù)據(jù)清洗階段原始數(shù)據(jù)中發(fā)病率的單位是“每10萬人口”還是“每1萬人口”我在不同年份的數(shù)據(jù)源里沒有統(tǒng)一。這種情況在醫(yī)療數(shù)據(jù)里非常常見因為不同統(tǒng)計口徑、不同發(fā)布平臺可能用不同的分母。解決方式是在數(shù)據(jù)入庫時做一個規(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)練時如果對特征做了標(biāo)準(zhǔn)化預(yù)測接口也要對輸入特征做相同的標(biāo)準(zhǔn)化處理。我在最終方案里把所有預(yù)處理步驟都封裝成一個transform_features函數(shù)訓(xùn)練和預(yù)測共用同一份代碼從根上消除“訓(xùn)練時做了一步處理、接口調(diào)用時漏掉”的可能性。5.3 大屏渲染卡頓大屏頁面初次加載時我一度同時發(fā)起8個接口請求每個請求返回幾百條數(shù)據(jù)然后所有圖表同步渲染。結(jié)果就是頁面加載卡頓低配機器上風(fēng)扇狂轉(zhuǎn)。優(yōu)化思路是三層接口合并。把首頁需要的指標(biāo)卡數(shù)據(jù)、趨勢數(shù)據(jù)、排名數(shù)據(jù)合并成2到3個聚合接口減少HTTP請求的次數(shù)。前端一次拿到整個數(shù)據(jù)包再分發(fā)到各個子組件。關(guān)閉ECharts動畫。前面已經(jīng)提到大屏場景下動畫收益極低但幀率損耗極大直接設(shè)置animation: false。數(shù)據(jù)聚合下推。排名圖前端只需要前10名就千萬不要把幾百個地區(qū)的數(shù)據(jù)全部返回而是在SQL層用LIMIT 10先過濾。大屏項目里網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量越小渲染壓力越小。5.4 項目目錄與部署建議整個項目最終產(chǎn)物分兩部分后端Flask服務(wù)、前端Vue構(gòu)建產(chǎn)物。本地開發(fā)時直接用python app.py啟動Flasknpm run serve啟動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啟動gunicorn -w 4 -b 127.0.0.1:5000 app:app如果你更喜歡容器化用docker-compose把所有服務(wù)編排起來也行但要注意Flask容器和前端Nginx容器共享同一個網(wǎng)絡(luò)前端的API地址要配置成后端服務(wù)名稱而不是localhost。還有一個很實用的建議爬蟲腳本不要和Flask服務(wù)綁定在同一個進程里。爬蟲偶爾會卡在網(wǎng)絡(luò)請求上如果把它放在Flask進程里一個阻塞就可能拖慢所有API響應(yīng)。最好讓爬蟲作為獨立腳本或定時任務(wù)運行數(shù)據(jù)寫庫后Flask只負責(zé)讀庫和預(yù)測兩者解耦。最后幾個實操體會如果只讓我留一句話就是先跑通最小閉環(huán)再裝飾細節(jié)。這個項目我最初的版本甚至沒有隨機森林只有爬蟲、數(shù)據(jù)庫和一個柱狀圖。等這條鏈路完全通了之后模型、更多圖表、更復(fù)雜的布局才逐步加進去。先讓數(shù)據(jù)能從源端流到屏幕項目的信心和價值感就完全不一樣了。另外一個小技巧醫(yī)療數(shù)據(jù)的字段名很容易產(chǎn)生歧義cases、deaths、incidence這些中英文混用聯(lián)調(diào)時特別容易鬧笑話。建議在數(shù)據(jù)入庫時就統(tǒng)一字段命名規(guī)范后端API用snake_case前端展示層再轉(zhuǎn)換成中文標(biāo)題別小看這個細節(jié)它能幫你省下大量對齊時間。如果后續(xù)想往上擴展可以試試給系統(tǒng)加上用戶登錄權(quán)限、定時爬取任務(wù)、圖表下鉆聯(lián)動或者把隨機森林換成XGBoost做一組對比實驗。但請記住一點在這個項目里算法只是其中一環(huán)數(shù)據(jù)的準(zhǔn)確性和前后端鏈路的穩(wěn)定才是真正決定成敗的部分。把最基礎(chǔ)的數(shù)據(jù)鏈路做扎實大屏才有底氣擺上臺面。本文還有配套的精品資源點擊獲取