建生態(tài)監(jiān)測大屏：從數(shù)據(jù)治理到ECharts可視化的完整實(shí)踐)
做了這么多年Java后端也經(jīng)手過不少數(shù)據(jù)可視化項(xiàng)目我發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象一提到可視化大家的第一反應(yīng)往往是Python或者是前端那一套高交互的方案。但真正落到城市生態(tài)環(huán)境監(jiān)測這種場景純Java技術(shù)棧反而是一條非常務(wù)實(shí)、非常穩(wěn)的路線。這篇內(nèi)容主要圍繞一個(gè)我實(shí)際參與過的生態(tài)監(jiān)測大屏項(xiàng)目來聊講清楚為什么選Java整體的架構(gòu)怎么搭核心的數(shù)據(jù)、指標(biāo)、圖表怎么設(shè)計(jì)以及開發(fā)過程中那些文檔里不會(huì)寫的坑。如果你正準(zhǔn)備做智慧環(huán)保、城市監(jiān)測或者類似的政企類大屏項(xiàng)目或者你是一個(gè)想從純后端往數(shù)據(jù)可視化方向擴(kuò)展的Java工程師這篇文章應(yīng)該能讓你少走不少彎路。1. 從需求到架構(gòu)為什么是Java而不是Python1.1 城市生態(tài)環(huán)境監(jiān)測到底要解決什么問題生態(tài)環(huán)境監(jiān)測這個(gè)領(lǐng)域表面看是接數(shù)據(jù)、畫圖表但深入了解之后你會(huì)發(fā)現(xiàn)它的核心難點(diǎn)在于數(shù)據(jù)太雜、指標(biāo)太多、時(shí)效要求又很高。一個(gè)中型城市的監(jiān)測體系通常包括空氣質(zhì)量監(jiān)測站、水質(zhì)監(jiān)測斷面、噪聲自動(dòng)監(jiān)測點(diǎn)位、氣象觀測站甚至還有重點(diǎn)污染源企業(yè)的在線監(jiān)控設(shè)備。這些設(shè)備的品牌不同、協(xié)議不同、上報(bào)頻率不同有的五分鐘傳一條有的一小時(shí)才傳一條中間還夾雜著延遲、斷檔、異常值。如果只是把這些數(shù)據(jù)原樣展示出來那叫數(shù)據(jù)大屏不叫決策系統(tǒng)。管理部門真正需要的是今天某個(gè)區(qū)域的PM2.5濃度為什么突然飆升是哪個(gè)方向的污染源影響的某條河的氨氮指標(biāo)連續(xù)三天超標(biāo)上游是哪個(gè)排污口嫌疑最大未來兩小時(shí)重污染天氣會(huì)不會(huì)形成是否要啟動(dòng)應(yīng)急預(yù)案。這些問題決定了可視化系統(tǒng)的核心任務(wù)不止是畫圖而是把原始監(jiān)測數(shù)據(jù)轉(zhuǎn)換成可判斷、可追蹤、可預(yù)警的信息。1.2 可視化項(xiàng)目為什么選用Java技術(shù)棧先說結(jié)論城市生態(tài)環(huán)境監(jiān)測這類項(xiàng)目后端主技術(shù)棧用Java前端可視化用ECharts是目前工程化成熟度最高、團(tuán)隊(duì)最穩(wěn)妥的組合之一。我并不是說Python不行。Python在數(shù)據(jù)分析上確實(shí)方便pandas、matplotlib用起來很順手但如果是一個(gè)要長期運(yùn)行、多人協(xié)作、與各種政務(wù)系統(tǒng)對接的省級或市級平臺Java的優(yōu)勢非常明顯。首先是工程化體系成熟Spring Boot提供了完整的依賴管理、配置管理、日志監(jiān)控、單元測試方案團(tuán)隊(duì)新成員上手成本低。其次是并發(fā)處理和事務(wù)控制能力扎實(shí)生態(tài)環(huán)境監(jiān)測數(shù)據(jù)往往是多路并發(fā)寫入同時(shí)還有前端大屏實(shí)時(shí)輪詢或推流Java的線程模型和數(shù)據(jù)庫連接池管理在這種高并發(fā)場景下非?？煽?。第三是大數(shù)據(jù)生態(tài)銜接順暢后面如果要接Hadoop、Spark、ClickHouse這些組件它們對Java的支持是最到位的后續(xù)擴(kuò)展不用推倒重來。至于可視化本身我的習(xí)慣是Java負(fù)責(zé)數(shù)據(jù)加工和API輸出前端用ECharts做渲染展示。這個(gè)分工的原因也很簡單可視化真正的門檻不在圖層怎么畫而在數(shù)據(jù)怎么算、怎么聚合、怎么保證在不同時(shí)間粒度和不同區(qū)域范圍下都有合適的呈現(xiàn)方式這部分是Java后端的主場。1.3 一次典型的生態(tài)監(jiān)測大屏架構(gòu)這類項(xiàng)目我通常會(huì)分成四層來設(shè)計(jì)。第一層是數(shù)據(jù)采集層。小型項(xiàng)目可以直接寫定時(shí)任務(wù)去拉取監(jiān)測站的上報(bào)數(shù)據(jù)數(shù)據(jù)量大或者設(shè)備主動(dòng)推送時(shí)就引入Kafka這樣的消息隊(duì)列把采集和存儲(chǔ)解耦。第二層是存儲(chǔ)與計(jì)算層。實(shí)時(shí)監(jiān)測數(shù)據(jù)落MySQL或者PostgreSQL如果有海量歷史數(shù)據(jù)要長期保存分析可以引入ClickHouse或者時(shí)序數(shù)據(jù)庫指標(biāo)計(jì)算、聚合統(tǒng)計(jì)在后端服務(wù)里完成。第三層是應(yīng)用服務(wù)層也就是Spring Boot提供的REST API和WebSocket推送服務(wù)。第四層是展示層大屏頁面通過ECharts渲染地圖、折線、熱力圖、儀表盤數(shù)據(jù)來自后端的實(shí)時(shí)接口。這里要注意一個(gè)常見誤區(qū)有人會(huì)把整個(gè)架構(gòu)設(shè)計(jì)得很重一上來就上Flink、上數(shù)據(jù)中臺結(jié)果項(xiàng)目周期拖長運(yùn)維復(fù)雜。對于絕大多數(shù)市級生態(tài)環(huán)境監(jiān)測平臺數(shù)據(jù)量還沒有大到非實(shí)時(shí)流式計(jì)算不可的程度先用定時(shí)采集加批量聚合就能滿足秒級甚至分鐘級的更新需求把架構(gòu)做輕反而能讓項(xiàng)目快速落地、穩(wěn)定運(yùn)行。2. 核心細(xì)節(jié)拆解數(shù)據(jù)、指標(biāo)與可視化模型的落地邏輯2.1 多源監(jiān)測數(shù)據(jù)的標(biāo)準(zhǔn)化處理生態(tài)環(huán)境監(jiān)測的數(shù)據(jù)源非常雜這里舉幾個(gè)實(shí)際的例子。空氣站上報(bào)的數(shù)據(jù)字段可能是PM2.5、PM10、SO2、NO2、O3、CO水質(zhì)站則是pH、溶解氧、高錳酸鹽指數(shù)、氨氮、總磷噪聲站上報(bào)的是等效聲級Leq氣象站還有溫度、濕度、風(fēng)速、風(fēng)向、氣壓。不同的設(shè)備廠商字段命名不一樣單位也不一樣有的用μg/m3有的用mg/m3時(shí)間格式更是五花八門。所以在數(shù)據(jù)入庫之前必須有一個(gè)標(biāo)準(zhǔn)化的過程。我的經(jīng)驗(yàn)是在采集層就把數(shù)據(jù)統(tǒng)一轉(zhuǎn)換成標(biāo)準(zhǔn)格式而不是等存入數(shù)據(jù)庫之后再做二次清洗。具體做法是建一張monitor_data表用station_code indicator_code data_time作為邏輯主鍵所有數(shù)據(jù)不管來自什么設(shè)備最終都進(jìn)入這一張表。這樣下游的查詢邏輯就非常簡單不需要針對每個(gè)數(shù)據(jù)源寫不同的SQL。時(shí)間戳的標(biāo)準(zhǔn)化尤其重要。有的設(shè)備上報(bào)的是本地時(shí)間有的帶時(shí)區(qū)有的干脆沒有時(shí)區(qū)。我的建議是全部統(tǒng)一成UTC時(shí)間存儲(chǔ)展示時(shí)再換算成北京時(shí)間。否則一旦某個(gè)站點(diǎn)上報(bào)的是UTC時(shí)間另一個(gè)站點(diǎn)上報(bào)的是東八區(qū)時(shí)間兩張圖標(biāo)畫出來之后曲線會(huì)出現(xiàn)一個(gè)小時(shí)的錯(cuò)位排查起來極其痛苦。2.2 關(guān)鍵監(jiān)測指標(biāo)的計(jì)算邏輯生態(tài)環(huán)境監(jiān)測里有一批經(jīng)典指標(biāo)不是直接從設(shè)備讀數(shù)就能用的需要二次計(jì)算其中最典型的就是AQI空氣質(zhì)量指數(shù)。AQI的計(jì)算核心思路是先算單個(gè)污染物的IAQI分指數(shù)再取所有分指數(shù)中的最大值。IAQI的計(jì)算采用分段線性插值法相當(dāng)于在污染物濃度范圍內(nèi)找對應(yīng)的指數(shù)區(qū)間做比例換算。PM2.5的分段是0-35、35-75、75-115、115-150、150-250、250-350、350-500對應(yīng)的IAQI區(qū)間是0-50、50-100、100-150、150-200、200-300、300-400、400-500。插值公式是IAQI (IAQI_Hi - IAQI_Lo) / (BP_Hi - BP_Lo) * (C - BP_Lo) IAQI_Lo其中C是實(shí)測濃度。用Java實(shí)現(xiàn)這個(gè)邏輯時(shí)不需要寫一堆if-else用二維數(shù)組存分段表再寫一個(gè)通用插值方法即可。水質(zhì)方面也有綜合指數(shù)。比如何為地表水環(huán)境質(zhì)量綜合指數(shù)需要把溶解氧、COD、氨氮等多個(gè)指標(biāo)分別對照國家標(biāo)準(zhǔn)水質(zhì)類別得到一個(gè)單指標(biāo)指數(shù)再加權(quán)匯總。這個(gè)邏輯看起來簡單但邊界條件很多比如溶解氧越大水質(zhì)越好它和其他污染物是反向的關(guān)系計(jì)算時(shí)要做倒數(shù)或者反向映射處理。算錯(cuò)一個(gè)符號整個(gè)評價(jià)結(jié)果就反了這種問題在代碼評審中很容易漏掉。2.3 可視化圖表的場景化選型ECharts功能強(qiáng)大但它不是所有圖表都適合所有場景。我的選型經(jīng)驗(yàn)是這樣的城市地圖上展示各監(jiān)測站點(diǎn)的實(shí)時(shí)數(shù)據(jù)用散點(diǎn)圖加漣漪特效點(diǎn)的顏色根據(jù)AQI等級動(dòng)態(tài)切換綠色代表優(yōu)、黃色代表良、橙色代表輕度污染、紅色代表中度及以上污染這樣管理部門一眼就能看出城市哪里空氣質(zhì)量差。如果要展示污染物濃度的連續(xù)空間分布用熱力圖它能把離散站點(diǎn)數(shù)據(jù)通過插值擬合成一片連續(xù)的色塊適合展示區(qū)域污染擴(kuò)散趨勢。時(shí)間維度上24小時(shí)或7天的趨勢變化用折線圖多站點(diǎn)對比時(shí)用多條折線加圖例切換。綜合評分或者排名評價(jià)用儀表盤和雷達(dá)圖。比如某個(gè)區(qū)的六項(xiàng)污染物濃度雷達(dá)圖能直觀看出哪項(xiàng)指標(biāo)拖了后腿。圖表選型的一個(gè)關(guān)鍵點(diǎn)是不要為了視覺效果犧牲數(shù)據(jù)可讀性。有的項(xiàng)目把站點(diǎn)數(shù)據(jù)做成3D柱狀圖懸掛在地圖上方交互確實(shí)炫酷但是數(shù)據(jù)標(biāo)簽擁擠、視角傾斜后很難準(zhǔn)確讀出數(shù)值。決策場景下圖表的準(zhǔn)確性遠(yuǎn)比形式重要這個(gè)理念我建議你從一開始就傳遞給產(chǎn)品方。3. 實(shí)操過程一個(gè)監(jiān)測大屏的完整落地路徑3.1 數(shù)據(jù)表設(shè)計(jì)從站點(diǎn)到指標(biāo)一張大寬表還是分表生態(tài)監(jiān)測數(shù)據(jù)表設(shè)計(jì)上很多人第一反應(yīng)是建一張大寬表把所有指標(biāo)都作為字段存進(jìn)去類似station_code, pm25, pm10, so2, no2, o3, co, temp, humidity, data_time。這個(gè)方式在業(yè)務(wù)邏輯簡單時(shí)沒問題但我強(qiáng)烈不建議在復(fù)雜的場景里這么干。原因很簡單不同的監(jiān)測點(diǎn)位監(jiān)測的指標(biāo)集合并不一致空氣站沒有氨氮這個(gè)指標(biāo)水質(zhì)站沒有PM2.5這個(gè)指標(biāo)。如果用大寬表很多字段經(jīng)常是NULL索引利用率低表結(jié)構(gòu)變更成本也高。我更推薦站點(diǎn)表指標(biāo)字典表監(jiān)測數(shù)據(jù)表的三表結(jié)構(gòu)。站點(diǎn)表存的是固定信息比如站點(diǎn)編碼、名稱、經(jīng)緯度、類型、所屬區(qū)域。指標(biāo)字典表存指標(biāo)編碼、名稱、單位、數(shù)據(jù)類型、國家標(biāo)準(zhǔn)限值。監(jiān)測數(shù)據(jù)表存的是具體的監(jiān)測值每行就是一個(gè)站點(diǎn)在某時(shí)間點(diǎn)的一個(gè)指標(biāo)值。這個(gè)結(jié)構(gòu)是典型的實(shí)體-屬性-值模式看起來多了一張表但擴(kuò)展性和查詢效率反而更好。下面是核心建表語句可以直接參考-- 站點(diǎn)信息表 CREATE TABLE monitor_station ( id BIGINT PRIMARY KEY AUTO_INCREMENT, station_code VARCHAR(32) NOT NULL UNIQUE COMMENT 站點(diǎn)編碼, station_name VARCHAR(128) NOT NULL COMMENT 站點(diǎn)名稱, station_type TINYINT NOT NULL COMMENT 站點(diǎn)類型: 1空氣, 2水質(zhì), 3噪聲, 4氣象, longitude DECIMAL(10, 6) COMMENT 經(jīng)度, latitude DECIMAL(10, 6) COMMENT 緯度, region_code VARCHAR(16) COMMENT 行政區(qū)劃編碼, status TINYINT DEFAULT 1 COMMENT 狀態(tài): 1啟用, 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_region_type (region_code, station_type) ) COMMENT 監(jiān)測站點(diǎn)信息表; -- 指標(biāo)字典表 CREATE TABLE indicator_dict ( id BIGINT PRIMARY KEY AUTO_INCREMENT, indicator_code VARCHAR(32) NOT NULL UNIQUE COMMENT 指標(biāo)編碼, 如PM25, AQI, NH3N, indicator_name VARCHAR(64) NOT NULL COMMENT 指標(biāo)名稱, unit VARCHAR(16) COMMENT 單位, data_type TINYINT COMMENT 數(shù)據(jù)類型: 1數(shù)值, 2等級, standard_limit DECIMAL(10, 2) COMMENT 國家/地方標(biāo)準(zhǔn)限值 ) COMMENT 監(jiān)測指標(biāo)字典表; -- 監(jiān)測數(shù)據(jù)表 CREATE TABLE monitor_data ( id BIGINT PRIMARY KEY AUTO_INCREMENT, station_code VARCHAR(32) NOT NULL, indicator_code VARCHAR(32) NOT NULL, indicator_value DECIMAL(10, 2) NOT NULL, data_time DATETIME NOT NULL COMMENT 監(jiān)測時(shí)間, source_flag TINYINT DEFAULT 1 COMMENT 數(shù)據(jù)來源標(biāo)識, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_station_indicator_time (station_code, indicator_code, data_time), KEY idx_indicator_time (indicator_code, data_time), KEY idx_station_time (station_code, data_time) ) COMMENT 監(jiān)測數(shù)據(jù)表;再說一個(gè)細(xì)節(jié)監(jiān)測數(shù)據(jù)表的唯一索引一定不能省。很多設(shè)備會(huì)重復(fù)推送同一時(shí)間點(diǎn)的數(shù)據(jù)如果接口不做冪等校驗(yàn)數(shù)據(jù)庫里就會(huì)插入臟數(shù)據(jù)圖表上出現(xiàn)毛刺。加了uk_station_indicator_time這個(gè)唯一索引之后通過INSERT ... ON DUPLICATE KEY UPDATE實(shí)現(xiàn)已存在則更新不存在則插入從源頭保證同一時(shí)間點(diǎn)上一條監(jiān)測值只保留最新版本。3.2 數(shù)據(jù)采集與計(jì)算定時(shí)任務(wù)還是消息隊(duì)列對于中小規(guī)模項(xiàng)目我建議直接從最簡單的方案開始Spring Boot的定時(shí)任務(wù)調(diào)度器定時(shí)調(diào)用各數(shù)據(jù)源的采集接口拉取增量數(shù)據(jù)后做標(biāo)準(zhǔn)化轉(zhuǎn)換再寫庫。這個(gè)方案的好處是代碼簡單、部署簡單、排查問題方便。等站點(diǎn)數(shù)量增長到幾十個(gè)甚至上百個(gè)采集頻率又高的時(shí)候再平滑遷移到Kafka加采集服務(wù)的架構(gòu)。采集任務(wù)的執(zhí)行邏輯里面有個(gè)非常容易被忽視的問題監(jiān)控采集任務(wù)的執(zhí)行時(shí)間。很多定時(shí)任務(wù)寫著每五分鐘執(zhí)行一次但如果上一次執(zhí)行因?yàn)榫W(wǎng)絡(luò)超時(shí)花了五分鐘以上下一次任務(wù)又到時(shí)間了就會(huì)出現(xiàn)任務(wù)重疊。我的做法是使用Spring的Scheduled加分布式鎖或者在任務(wù)入口加一個(gè)原子性的執(zhí)行中標(biāo)志確保同一時(shí)間只有一個(gè)采集任務(wù)在跑。AQI計(jì)算這類邏輯我建議做成獨(dú)立的服務(wù)方法放在數(shù)據(jù)入庫之后。盡量不在采集任務(wù)內(nèi)部計(jì)算而是等數(shù)據(jù)落庫之后用另一個(gè)定時(shí)任務(wù)統(tǒng)一計(jì)算最近一小時(shí)的AQI數(shù)據(jù)。這樣做的好處是如果計(jì)算邏輯有bug需要修只需要重新跑一遍計(jì)算任務(wù)不用重新采集原始數(shù)據(jù)。我吃過這個(gè)虧最初把AQI計(jì)算放在了采集線程里后來發(fā)現(xiàn)分段表參數(shù)要調(diào)整結(jié)果只能把當(dāng)天的原始數(shù)據(jù)重新拉取一遍非常浪費(fèi)時(shí)間。3.3 后端API設(shè)計(jì)聚合查詢的思路與實(shí)現(xiàn)大屏展示區(qū)和業(yè)務(wù)管理端的查詢接口設(shè)計(jì)思路完全不同。管理端往往需要查明細(xì)、導(dǎo)出報(bào)表、做復(fù)雜條件篩選但大屏端需要的是當(dāng)前城市整體情況各站點(diǎn)實(shí)時(shí)等級24小時(shí)變化趨勢這類聚合信息。所以我給大屏端設(shè)計(jì)接口時(shí)會(huì)專門做輕量化的聚合返回。實(shí)時(shí)地圖接口只需要stationCode, stationName, longitude, latitude, aqi, level, color字段不需要返回整表所有監(jiān)測值。趨勢圖接口只需要返回指定時(shí)間段內(nèi)的時(shí)間點(diǎn)數(shù)組和數(shù)值數(shù)組。前端拿到的數(shù)據(jù)越瘦渲染就越流暢。這里給出一個(gè)實(shí)時(shí)站點(diǎn)數(shù)據(jù)接口的Controller示例RestController RequestMapping(/api/eco) public class EcoMonitorController { Autowired private MonitorDataService monitorDataService; /** * 大屏實(shí)時(shí)地圖接口 */ GetMapping(/realtime/stations) public ResultListStationRealtimeVO realtimeStations( RequestParam(required false) String regionCode, RequestParam(required false) Integer stationType) { ListStationRealtimeVO list monitorDataService.queryRealtimeStations(regionCode, stationType); return Result.ok(list); } /** * 24小時(shí)趨勢接口 */ GetMapping(/trend/24h) public ResultTrendVO trend24h( RequestParam String stationCode, RequestParam(defaultValue AQI) String indicatorCode) { TrendVO trend monitorDataService.queryTrend(stationCode, indicatorCode, 24); return Result.ok(trend); } }聚合查詢的實(shí)現(xiàn)上結(jié)合前面提到的表結(jié)構(gòu)SQL里最常用的模式就是按站點(diǎn)和小時(shí)做GROUP BY。如果歷史數(shù)據(jù)量很大比如超過幾千萬行直接查原始表做聚合會(huì)越來越慢。這時(shí)候可以建立小時(shí)聚合表定時(shí)任務(wù)把原始表的數(shù)據(jù)匯總進(jìn)去大屏趨勢查詢走聚合表原始數(shù)據(jù)表只承擔(dān)寫入和明細(xì)下載的職責(zé)。我自己實(shí)測下來同樣的24小時(shí)趨勢查詢原始表上執(zhí)行可能要兩三秒走聚合表之后基本穩(wěn)定在幾十毫秒。后端還有一個(gè)重要但容易被忽視的優(yōu)化是緩存。對于當(dāng)前城市實(shí)時(shí)空氣質(zhì)量等級分布這種變化頻率低、查詢頻率高的數(shù)據(jù)直接用Redis緩存五到十秒完全沒有問題。大屏頁面本身就有輪詢機(jī)制緩存策略不會(huì)影響實(shí)時(shí)性但能明顯降低數(shù)據(jù)庫的壓力。3.4 前端大屏渲染ECharts地圖與實(shí)時(shí)推送大屏頁面我一般選用ECharts配合Vue或純HTML頁面都能跑。ECharts在生態(tài)環(huán)境可視化領(lǐng)域幾乎是標(biāo)配地圖、散點(diǎn)、熱力、折線、儀表盤這些常用圖都有成熟方案而且支持WebSocket實(shí)時(shí)推送更新。最核心的實(shí)時(shí)地圖效果配置項(xiàng)大致是這樣的思路const chart echarts.init(document.getElementById(mainMap)); chart.setOption({ geo: { map: china, roam: true, itemStyle: { areaColor: #1b2b4a, borderColor: #4a6c9c } }, series: [{ type: effectScatter, coordinateSystem: geo, data: stationData, // [{name: 站點(diǎn)A, value: [116.4, 39.9, 85]}] symbolSize: 12, rippleEffect: { scale: 3 }, itemStyle: { color: function(params) { // 根據(jù)AQI等級返回對應(yīng)顏色 return aqiColorMap[params.value[2]] || #ccc; } } }] });這里有個(gè)很細(xì)節(jié)的點(diǎn)ECharts地圖的多邊形邊界數(shù)據(jù)在地圖縮放級別高的時(shí)候邊界會(huì)顯得比較粗建議把geo的itemStyle里的borderWidth調(diào)小到0.5左右視覺上會(huì)更精致。實(shí)時(shí)推送這塊我強(qiáng)烈建議用WebSocket而不是前端定時(shí)輪詢REST接口。原因有兩個(gè)一是省資源幾十個(gè)頁面同時(shí)打開每隔幾秒就發(fā)起一次HTTP請求服務(wù)器壓力非常大二是即時(shí)性好后端拿到監(jiān)測站的最新數(shù)據(jù)可以主動(dòng)推送給所有在線客戶端免去了輪詢的延遲。如果條件允許推送的消息不要發(fā)完整數(shù)據(jù)而是發(fā)一個(gè)數(shù)據(jù)版本號或者增量更新記錄前端收到后再去請求需要更新的接口數(shù)據(jù)這樣能顯著減少無效的網(wǎng)絡(luò)傳輸。4. 常見問題與排查技巧實(shí)錄4.1 圖表數(shù)據(jù)不更新或者更新延遲這個(gè)問題的表象是大屏上的數(shù)據(jù)一直沒有變化但數(shù)據(jù)庫里明明有新數(shù)據(jù)。我遇到過的原因有三種。第一種是前端瀏覽器緩存了GET請求。大屏頁面通過Axios或者fetch請求接口瀏覽器對GET請求會(huì)做緩存導(dǎo)致頁面刷新后拿到的還是舊數(shù)據(jù)。解決辦法很簡單在請求URL上追加一個(gè)時(shí)間戳參數(shù)或者統(tǒng)一把接口請求頭設(shè)置為Cache-Control: no-cache。第二種是后端SQL性能太差數(shù)據(jù)量一大聚合查詢超過了輪詢的間隔時(shí)間。一個(gè)四千萬行的監(jiān)測數(shù)據(jù)表如果不走聚合表直接查時(shí)間范圍跨一周的站點(diǎn)趨勢查詢很容易超過五秒。排查方法是在MySQL里開啟慢查詢?nèi)罩菊页龀^一秒鐘的SQL然后針對性優(yōu)化索引或者改造為聚合表查詢。第三種是WebSocket根本沒有建立成功但前端代碼沒有做好降級處理。頁面在WebSocket連接失敗時(shí)應(yīng)該自動(dòng)回退到HTTP輪詢模式避免整個(gè)大屏變成死屏。這個(gè)降級邏輯一定要提前做不要等上線后在現(xiàn)場才發(fā)現(xiàn)問題。4.2 ECharts站點(diǎn)散點(diǎn)太多導(dǎo)致頁面卡頓城市空氣質(zhì)量監(jiān)測站點(diǎn)通常不會(huì)特別多幾十一百個(gè)散點(diǎn)問題不大。但有些項(xiàng)目會(huì)疊加噪聲監(jiān)測點(diǎn)、污染源企業(yè)點(diǎn)位、積水監(jiān)測點(diǎn)等所有圖層的點(diǎn)加在一起可能有幾百上千個(gè)加上漣漪特效頁面的幀率會(huì)明顯下降大屏拖起來卡頓甚至CPU占用過高。我的經(jīng)驗(yàn)是分層處理地圖默認(rèn)展示的氣站、水站這類核心站點(diǎn)用effectScatter體現(xiàn)活躍態(tài)而附屬點(diǎn)位用普通的scatter不加漣漪特效。還有個(gè)更高效的做法是把點(diǎn)位數(shù)據(jù)按照地圖的zoom級別做縮放聚合地圖放大到一定程度才展示詳細(xì)點(diǎn)位縮小視野時(shí)只展示區(qū)域聚合后的點(diǎn)。雖然ECharts自身沒有內(nèi)置這個(gè)能力但通過監(jiān)聽georoam事件自己維護(hù)一個(gè)LOD數(shù)據(jù)源實(shí)現(xiàn)起來也不算復(fù)雜效果卻非常明顯。另外站點(diǎn)名稱的Label不要全量顯示否則文字會(huì)互相遮擋。只在縮放達(dá)到一定級別后顯示站名或者讓用戶點(diǎn)擊氣泡后再彈出詳情都是合理的交互方式。4.3 AQI計(jì)算和應(yīng)用中最容易出錯(cuò)的三個(gè)地方AQI計(jì)算邏輯本身不復(fù)雜但在工程落地時(shí)很容易出錯(cuò)。第一個(gè)錯(cuò)誤是不同污染物濃度單位混用。PM2.5的濃度從設(shè)備采集來的單位是μg/m3但是SO2、NO2的標(biāo)準(zhǔn)分段表中有些單位是mg/m3。如果換算系數(shù)漏了算出來的IAQI值會(huì)完全離譜。我的建議是在指標(biāo)字典表里明確存儲(chǔ)單位在計(jì)算前統(tǒng)一轉(zhuǎn)換為標(biāo)準(zhǔn)單位。第二個(gè)錯(cuò)誤是四舍五入的時(shí)機(jī)不對?？諝赓|(zhì)量指數(shù)的國標(biāo)要求先對各污染物IAQI取整然后再比較大小取最大值。如果計(jì)算過程中過早取整或者對AQI最終值重復(fù)取整結(jié)果會(huì)和標(biāo)準(zhǔn)算法有細(xì)微偏差。第三個(gè)錯(cuò)誤是無效值的處理。設(shè)備故障、標(biāo)定維護(hù)期間監(jiān)測值可能是負(fù)數(shù)、零值或者超出合理物理范圍。如果把這些臟數(shù)據(jù)帶入AQI計(jì)算會(huì)造成異常突變。我的做法是維護(hù)一個(gè)有效值范圍表每種指標(biāo)限定合理的最小值和最大值數(shù)據(jù)入庫前做過濾計(jì)算時(shí)不至于被臟數(shù)據(jù)干擾。4.4 多站點(diǎn)時(shí)間軸對齊問題為什么有的曲線圖上站點(diǎn)A的零點(diǎn)數(shù)據(jù)顯示在整點(diǎn)10:00站點(diǎn)B卻在10:02因?yàn)椴煌O(shè)備的采集周期、上報(bào)延遲完全不同。有五分鐘粒度的有十分鐘粒度的還有無規(guī)律延遲的。做時(shí)間序列曲線時(shí)直接拿原始時(shí)間點(diǎn)來畫圖多站點(diǎn)對比就會(huì)參差不齊視覺上很難看。我要做的第一步是把所有數(shù)據(jù)按照統(tǒng)一的分鐘窗口對齊比如取data_time四舍五入到最近整點(diǎn)或最近五分鐘的槽位。第二步是處理缺失時(shí)間點(diǎn)的補(bǔ)值問題最簡化的方案是向上填充或線性插值但插值結(jié)果和真實(shí)監(jiān)測值有偏差所以圖上最好用虛線標(biāo)記插值區(qū)間或者直接空出來的點(diǎn)位交給前端ECharts用connectNulls屬性控制。時(shí)間對齊還有一個(gè)容易踩的坑就是數(shù)據(jù)庫data_time字段存儲(chǔ)的是字符串還是DATETIME類型。雖然字符串也能查到數(shù)據(jù)但當(dāng)你要做BETWEEN時(shí)間范圍的查詢并且想走索引時(shí)字符串比較的效率遠(yuǎn)不如原生DATETIME。設(shè)計(jì)表結(jié)構(gòu)時(shí)直接選DATETIME類型后面能省很多事。4.5 大屏現(xiàn)場部署時(shí)的兼容性問題政企類項(xiàng)目的現(xiàn)場大屏經(jīng)常用一些老舊的Windows主機(jī)或者定制版瀏覽器。ECharts 5對瀏覽器有最低版本要求如果現(xiàn)場瀏覽器版本太低圖表可能直接白屏或者報(bào)錯(cuò)。我建議在開發(fā)階段就確定目標(biāo)瀏覽器并且用BrowserStack或者本地虛擬機(jī)做兼容性測試。部署時(shí)最好把ECharts的JS文件直接放在服務(wù)器上作為靜態(tài)資源加載不要依賴公共CDN。很多政務(wù)內(nèi)網(wǎng)環(huán)境訪問不了外網(wǎng)CDN如果代碼里引用的還是公網(wǎng)CDN地址到了現(xiàn)場圖表就全部加載不出來。這類問題一旦在現(xiàn)場發(fā)生排查起來是非常尷尬的所以我一般從第一天起就要求前端資源全部本地化。最后說點(diǎn)我的實(shí)際體會(huì)整個(gè)項(xiàng)目做完我最大的感受是生態(tài)監(jiān)測大屏這類可視化系統(tǒng)真正的技術(shù)難點(diǎn)并不在圖表畫得有多炫而在后端能不能把雜亂的多源數(shù)據(jù)治理成干凈、標(biāo)準(zhǔn)、可計(jì)算的信息。Java在整個(gè)鏈路里承擔(dān)的恰恰是最扎實(shí)、最不可省略的那部分工作。從數(shù)據(jù)標(biāo)準(zhǔn)化到AQI計(jì)算從聚合查詢到實(shí)時(shí)推送每一步都考驗(yàn)著后端工程師對業(yè)務(wù)的理解深度。如果你正在做或者準(zhǔn)備做類似的項(xiàng)目我建議把精力重點(diǎn)放在數(shù)據(jù)模型設(shè)計(jì)和指標(biāo)計(jì)算的準(zhǔn)確性上圖表反而不用過度糾結(jié)樣式先把數(shù)據(jù)搞清楚大屏自然就有了靈魂。 Java構(gòu)建生態(tài)監(jiān)測大屏：從數(shù)據(jù)治理到ECharts可視化的完整實(shí)踐
做了這么多年Java后端也經(jīng)手過不少數(shù)據(jù)可視化項(xiàng)目我發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象一提到可視化大家的第一反應(yīng)往往是Python或者是前端那一套高交互的方案。但真正落到城市生態(tài)環(huán)境監(jiān)測這種場景純Java技術(shù)棧反而是一條非常務(wù)實(shí)、非常穩(wěn)的路線。這篇內(nèi)容主要圍繞一個(gè)我實(shí)際參與過的生態(tài)監(jiān)測大屏項(xiàng)目來聊講清楚為什么選Java整體的架構(gòu)怎么搭核心的數(shù)據(jù)、指標(biāo)、圖表怎么設(shè)計(jì)以及開發(fā)過程中那些文檔里不會(huì)寫的坑。如果你正準(zhǔn)備做智慧環(huán)保、城市監(jiān)測或者類似的政企類大屏項(xiàng)目或者你是一個(gè)想從純后端往數(shù)據(jù)可視化方向擴(kuò)展的Java工程師這篇文章應(yīng)該能讓你少走不少彎路。1. 從需求到架構(gòu)為什么是Java而不是Python1.1 城市生態(tài)環(huán)境監(jiān)測到底要解決什么問題生態(tài)環(huán)境監(jiān)測這個(gè)領(lǐng)域表面看是接數(shù)據(jù)、畫圖表但深入了解之后你會(huì)發(fā)現(xiàn)它的核心難點(diǎn)在于數(shù)據(jù)太雜、指標(biāo)太多、時(shí)效要求又很高。一個(gè)中型城市的監(jiān)測體系通常包括空氣質(zhì)量監(jiān)測站、水質(zhì)監(jiān)測斷面、噪聲自動(dòng)監(jiān)測點(diǎn)位、氣象觀測站甚至還有重點(diǎn)污染源企業(yè)的在線監(jiān)控設(shè)備。這些設(shè)備的品牌不同、協(xié)議不同、上報(bào)頻率不同有的五分鐘傳一條有的一小時(shí)才傳一條中間還夾雜著延遲、斷檔、異常值。如果只是把這些數(shù)據(jù)原樣展示出來那叫數(shù)據(jù)大屏不叫決策系統(tǒng)。管理部門真正需要的是今天某個(gè)區(qū)域的PM2.5濃度為什么突然飆升是哪個(gè)方向的污染源影響的某條河的氨氮指標(biāo)連續(xù)三天超標(biāo)上游是哪個(gè)排污口嫌疑最大未來兩小時(shí)重污染天氣會(huì)不會(huì)形成是否要啟動(dòng)應(yīng)急預(yù)案。這些問題決定了可視化系統(tǒng)的核心任務(wù)不止是畫圖而是把原始監(jiān)測數(shù)據(jù)轉(zhuǎn)換成可判斷、可追蹤、可預(yù)警的信息。1.2 可視化項(xiàng)目為什么選用Java技術(shù)棧先說結(jié)論城市生態(tài)環(huán)境監(jiān)測這類項(xiàng)目后端主技術(shù)棧用Java前端可視化用ECharts是目前工程化成熟度最高、團(tuán)隊(duì)最穩(wěn)妥的組合之一。我并不是說Python不行。Python在數(shù)據(jù)分析上確實(shí)方便pandas、matplotlib用起來很順手但如果是一個(gè)要長期運(yùn)行、多人協(xié)作、與各種政務(wù)系統(tǒng)對接的省級或市級平臺Java的優(yōu)勢非常明顯。首先是工程化體系成熟Spring Boot提供了完整的依賴管理、配置管理、日志監(jiān)控、單元測試方案團(tuán)隊(duì)新成員上手成本低。其次是并發(fā)處理和事務(wù)控制能力扎實(shí)生態(tài)環(huán)境監(jiān)測數(shù)據(jù)往往是多路并發(fā)寫入同時(shí)還有前端大屏實(shí)時(shí)輪詢或推流Java的線程模型和數(shù)據(jù)庫連接池管理在這種高并發(fā)場景下非?？煽?。第三是大數(shù)據(jù)生態(tài)銜接順暢后面如果要接Hadoop、Spark、ClickHouse這些組件它們對Java的支持是最到位的后續(xù)擴(kuò)展不用推倒重來。至于可視化本身我的習(xí)慣是Java負(fù)責(zé)數(shù)據(jù)加工和API輸出前端用ECharts做渲染展示。這個(gè)分工的原因也很簡單可視化真正的門檻不在圖層怎么畫而在數(shù)據(jù)怎么算、怎么聚合、怎么保證在不同時(shí)間粒度和不同區(qū)域范圍下都有合適的呈現(xiàn)方式這部分是Java后端的主場。1.3 一次典型的生態(tài)監(jiān)測大屏架構(gòu)這類項(xiàng)目我通常會(huì)分成四層來設(shè)計(jì)。第一層是數(shù)據(jù)采集層。小型項(xiàng)目可以直接寫定時(shí)任務(wù)去拉取監(jiān)測站的上報(bào)數(shù)據(jù)數(shù)據(jù)量大或者設(shè)備主動(dòng)推送時(shí)就引入Kafka這樣的消息隊(duì)列把采集和存儲(chǔ)解耦。第二層是存儲(chǔ)與計(jì)算層。實(shí)時(shí)監(jiān)測數(shù)據(jù)落MySQL或者PostgreSQL如果有海量歷史數(shù)據(jù)要長期保存分析可以引入ClickHouse或者時(shí)序數(shù)據(jù)庫指標(biāo)計(jì)算、聚合統(tǒng)計(jì)在后端服務(wù)里完成。第三層是應(yīng)用服務(wù)層也就是Spring Boot提供的REST API和WebSocket推送服務(wù)。第四層是展示層大屏頁面通過ECharts渲染地圖、折線、熱力圖、儀表盤數(shù)據(jù)來自后端的實(shí)時(shí)接口。這里要注意一個(gè)常見誤區(qū)有人會(huì)把整個(gè)架構(gòu)設(shè)計(jì)得很重一上來就上Flink、上數(shù)據(jù)中臺結(jié)果項(xiàng)目周期拖長運(yùn)維復(fù)雜。對于絕大多數(shù)市級生態(tài)環(huán)境監(jiān)測平臺數(shù)據(jù)量還沒有大到非實(shí)時(shí)流式計(jì)算不可的程度先用定時(shí)采集加批量聚合就能滿足秒級甚至分鐘級的更新需求把架構(gòu)做輕反而能讓項(xiàng)目快速落地、穩(wěn)定運(yùn)行。2. 核心細(xì)節(jié)拆解數(shù)據(jù)、指標(biāo)與可視化模型的落地邏輯2.1 多源監(jiān)測數(shù)據(jù)的標(biāo)準(zhǔn)化處理生態(tài)環(huán)境監(jiān)測的數(shù)據(jù)源非常雜這里舉幾個(gè)實(shí)際的例子。空氣站上報(bào)的數(shù)據(jù)字段可能是PM2.5、PM10、SO2、NO2、O3、CO水質(zhì)站則是pH、溶解氧、高錳酸鹽指數(shù)、氨氮、總磷噪聲站上報(bào)的是等效聲級Leq氣象站還有溫度、濕度、風(fēng)速、風(fēng)向、氣壓。不同的設(shè)備廠商字段命名不一樣單位也不一樣有的用μg/m3有的用mg/m3時(shí)間格式更是五花八門。所以在數(shù)據(jù)入庫之前必須有一個(gè)標(biāo)準(zhǔn)化的過程。我的經(jīng)驗(yàn)是在采集層就把數(shù)據(jù)統(tǒng)一轉(zhuǎn)換成標(biāo)準(zhǔn)格式而不是等存入數(shù)據(jù)庫之后再做二次清洗。具體做法是建一張monitor_data表用station_code indicator_code data_time作為邏輯主鍵所有數(shù)據(jù)不管來自什么設(shè)備最終都進(jìn)入這一張表。這樣下游的查詢邏輯就非常簡單不需要針對每個(gè)數(shù)據(jù)源寫不同的SQL。時(shí)間戳的標(biāo)準(zhǔn)化尤其重要。有的設(shè)備上報(bào)的是本地時(shí)間有的帶時(shí)區(qū)有的干脆沒有時(shí)區(qū)。我的建議是全部統(tǒng)一成UTC時(shí)間存儲(chǔ)展示時(shí)再換算成北京時(shí)間。否則一旦某個(gè)站點(diǎn)上報(bào)的是UTC時(shí)間另一個(gè)站點(diǎn)上報(bào)的是東八區(qū)時(shí)間兩張圖標(biāo)畫出來之后曲線會(huì)出現(xiàn)一個(gè)小時(shí)的錯(cuò)位排查起來極其痛苦。2.2 關(guān)鍵監(jiān)測指標(biāo)的計(jì)算邏輯生態(tài)環(huán)境監(jiān)測里有一批經(jīng)典指標(biāo)不是直接從設(shè)備讀數(shù)就能用的需要二次計(jì)算其中最典型的就是AQI空氣質(zhì)量指數(shù)。AQI的計(jì)算核心思路是先算單個(gè)污染物的IAQI分指數(shù)再取所有分指數(shù)中的最大值。IAQI的計(jì)算采用分段線性插值法相當(dāng)于在污染物濃度范圍內(nèi)找對應(yīng)的指數(shù)區(qū)間做比例換算。PM2.5的分段是0-35、35-75、75-115、115-150、150-250、250-350、350-500對應(yīng)的IAQI區(qū)間是0-50、50-100、100-150、150-200、200-300、300-400、400-500。插值公式是IAQI (IAQI_Hi - IAQI_Lo) / (BP_Hi - BP_Lo) * (C - BP_Lo) IAQI_Lo其中C是實(shí)測濃度。用Java實(shí)現(xiàn)這個(gè)邏輯時(shí)不需要寫一堆if-else用二維數(shù)組存分段表再寫一個(gè)通用插值方法即可。水質(zhì)方面也有綜合指數(shù)。比如何為地表水環(huán)境質(zhì)量綜合指數(shù)需要把溶解氧、COD、氨氮等多個(gè)指標(biāo)分別對照國家標(biāo)準(zhǔn)水質(zhì)類別得到一個(gè)單指標(biāo)指數(shù)再加權(quán)匯總。這個(gè)邏輯看起來簡單但邊界條件很多比如溶解氧越大水質(zhì)越好它和其他污染物是反向的關(guān)系計(jì)算時(shí)要做倒數(shù)或者反向映射處理。算錯(cuò)一個(gè)符號整個(gè)評價(jià)結(jié)果就反了這種問題在代碼評審中很容易漏掉。2.3 可視化圖表的場景化選型ECharts功能強(qiáng)大但它不是所有圖表都適合所有場景。我的選型經(jīng)驗(yàn)是這樣的城市地圖上展示各監(jiān)測站點(diǎn)的實(shí)時(shí)數(shù)據(jù)用散點(diǎn)圖加漣漪特效點(diǎn)的顏色根據(jù)AQI等級動(dòng)態(tài)切換綠色代表優(yōu)、黃色代表良、橙色代表輕度污染、紅色代表中度及以上污染這樣管理部門一眼就能看出城市哪里空氣質(zhì)量差。如果要展示污染物濃度的連續(xù)空間分布用熱力圖它能把離散站點(diǎn)數(shù)據(jù)通過插值擬合成一片連續(xù)的色塊適合展示區(qū)域污染擴(kuò)散趨勢。時(shí)間維度上24小時(shí)或7天的趨勢變化用折線圖多站點(diǎn)對比時(shí)用多條折線加圖例切換。綜合評分或者排名評價(jià)用儀表盤和雷達(dá)圖。比如某個(gè)區(qū)的六項(xiàng)污染物濃度雷達(dá)圖能直觀看出哪項(xiàng)指標(biāo)拖了后腿。圖表選型的一個(gè)關(guān)鍵點(diǎn)是不要為了視覺效果犧牲數(shù)據(jù)可讀性。有的項(xiàng)目把站點(diǎn)數(shù)據(jù)做成3D柱狀圖懸掛在地圖上方交互確實(shí)炫酷但是數(shù)據(jù)標(biāo)簽擁擠、視角傾斜后很難準(zhǔn)確讀出數(shù)值。決策場景下圖表的準(zhǔn)確性遠(yuǎn)比形式重要這個(gè)理念我建議你從一開始就傳遞給產(chǎn)品方。3. 實(shí)操過程一個(gè)監(jiān)測大屏的完整落地路徑3.1 數(shù)據(jù)表設(shè)計(jì)從站點(diǎn)到指標(biāo)一張大寬表還是分表生態(tài)監(jiān)測數(shù)據(jù)表設(shè)計(jì)上很多人第一反應(yīng)是建一張大寬表把所有指標(biāo)都作為字段存進(jìn)去類似station_code, pm25, pm10, so2, no2, o3, co, temp, humidity, data_time。這個(gè)方式在業(yè)務(wù)邏輯簡單時(shí)沒問題但我強(qiáng)烈不建議在復(fù)雜的場景里這么干。原因很簡單不同的監(jiān)測點(diǎn)位監(jiān)測的指標(biāo)集合并不一致空氣站沒有氨氮這個(gè)指標(biāo)水質(zhì)站沒有PM2.5這個(gè)指標(biāo)。如果用大寬表很多字段經(jīng)常是NULL索引利用率低表結(jié)構(gòu)變更成本也高。我更推薦站點(diǎn)表指標(biāo)字典表監(jiān)測數(shù)據(jù)表的三表結(jié)構(gòu)。站點(diǎn)表存的是固定信息比如站點(diǎn)編碼、名稱、經(jīng)緯度、類型、所屬區(qū)域。指標(biāo)字典表存指標(biāo)編碼、名稱、單位、數(shù)據(jù)類型、國家標(biāo)準(zhǔn)限值。監(jiān)測數(shù)據(jù)表存的是具體的監(jiān)測值每行就是一個(gè)站點(diǎn)在某時(shí)間點(diǎn)的一個(gè)指標(biāo)值。這個(gè)結(jié)構(gòu)是典型的實(shí)體-屬性-值模式看起來多了一張表但擴(kuò)展性和查詢效率反而更好。下面是核心建表語句可以直接參考-- 站點(diǎn)信息表 CREATE TABLE monitor_station ( id BIGINT PRIMARY KEY AUTO_INCREMENT, station_code VARCHAR(32) NOT NULL UNIQUE COMMENT 站點(diǎn)編碼, station_name VARCHAR(128) NOT NULL COMMENT 站點(diǎn)名稱, station_type TINYINT NOT NULL COMMENT 站點(diǎn)類型: 1空氣, 2水質(zhì), 3噪聲, 4氣象, longitude DECIMAL(10, 6) COMMENT 經(jīng)度, latitude DECIMAL(10, 6) COMMENT 緯度, region_code VARCHAR(16) COMMENT 行政區(qū)劃編碼, status TINYINT DEFAULT 1 COMMENT 狀態(tài): 1啟用, 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_region_type (region_code, station_type) ) COMMENT 監(jiān)測站點(diǎn)信息表; -- 指標(biāo)字典表 CREATE TABLE indicator_dict ( id BIGINT PRIMARY KEY AUTO_INCREMENT, indicator_code VARCHAR(32) NOT NULL UNIQUE COMMENT 指標(biāo)編碼, 如PM25, AQI, NH3N, indicator_name VARCHAR(64) NOT NULL COMMENT 指標(biāo)名稱, unit VARCHAR(16) COMMENT 單位, data_type TINYINT COMMENT 數(shù)據(jù)類型: 1數(shù)值, 2等級, standard_limit DECIMAL(10, 2) COMMENT 國家/地方標(biāo)準(zhǔn)限值 ) COMMENT 監(jiān)測指標(biāo)字典表; -- 監(jiān)測數(shù)據(jù)表 CREATE TABLE monitor_data ( id BIGINT PRIMARY KEY AUTO_INCREMENT, station_code VARCHAR(32) NOT NULL, indicator_code VARCHAR(32) NOT NULL, indicator_value DECIMAL(10, 2) NOT NULL, data_time DATETIME NOT NULL COMMENT 監(jiān)測時(shí)間, source_flag TINYINT DEFAULT 1 COMMENT 數(shù)據(jù)來源標(biāo)識, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_station_indicator_time (station_code, indicator_code, data_time), KEY idx_indicator_time (indicator_code, data_time), KEY idx_station_time (station_code, data_time) ) COMMENT 監(jiān)測數(shù)據(jù)表;再說一個(gè)細(xì)節(jié)監(jiān)測數(shù)據(jù)表的唯一索引一定不能省。很多設(shè)備會(huì)重復(fù)推送同一時(shí)間點(diǎn)的數(shù)據(jù)如果接口不做冪等校驗(yàn)數(shù)據(jù)庫里就會(huì)插入臟數(shù)據(jù)圖表上出現(xiàn)毛刺。加了uk_station_indicator_time這個(gè)唯一索引之后通過INSERT ... ON DUPLICATE KEY UPDATE實(shí)現(xiàn)已存在則更新不存在則插入從源頭保證同一時(shí)間點(diǎn)上一條監(jiān)測值只保留最新版本。3.2 數(shù)據(jù)采集與計(jì)算定時(shí)任務(wù)還是消息隊(duì)列對于中小規(guī)模項(xiàng)目我建議直接從最簡單的方案開始Spring Boot的定時(shí)任務(wù)調(diào)度器定時(shí)調(diào)用各數(shù)據(jù)源的采集接口拉取增量數(shù)據(jù)后做標(biāo)準(zhǔn)化轉(zhuǎn)換再寫庫。這個(gè)方案的好處是代碼簡單、部署簡單、排查問題方便。等站點(diǎn)數(shù)量增長到幾十個(gè)甚至上百個(gè)采集頻率又高的時(shí)候再平滑遷移到Kafka加采集服務(wù)的架構(gòu)。采集任務(wù)的執(zhí)行邏輯里面有個(gè)非常容易被忽視的問題監(jiān)控采集任務(wù)的執(zhí)行時(shí)間。很多定時(shí)任務(wù)寫著每五分鐘執(zhí)行一次但如果上一次執(zhí)行因?yàn)榫W(wǎng)絡(luò)超時(shí)花了五分鐘以上下一次任務(wù)又到時(shí)間了就會(huì)出現(xiàn)任務(wù)重疊。我的做法是使用Spring的Scheduled加分布式鎖或者在任務(wù)入口加一個(gè)原子性的執(zhí)行中標(biāo)志確保同一時(shí)間只有一個(gè)采集任務(wù)在跑。AQI計(jì)算這類邏輯我建議做成獨(dú)立的服務(wù)方法放在數(shù)據(jù)入庫之后。盡量不在采集任務(wù)內(nèi)部計(jì)算而是等數(shù)據(jù)落庫之后用另一個(gè)定時(shí)任務(wù)統(tǒng)一計(jì)算最近一小時(shí)的AQI數(shù)據(jù)。這樣做的好處是如果計(jì)算邏輯有bug需要修只需要重新跑一遍計(jì)算任務(wù)不用重新采集原始數(shù)據(jù)。我吃過這個(gè)虧最初把AQI計(jì)算放在了采集線程里后來發(fā)現(xiàn)分段表參數(shù)要調(diào)整結(jié)果只能把當(dāng)天的原始數(shù)據(jù)重新拉取一遍非常浪費(fèi)時(shí)間。3.3 后端API設(shè)計(jì)聚合查詢的思路與實(shí)現(xiàn)大屏展示區(qū)和業(yè)務(wù)管理端的查詢接口設(shè)計(jì)思路完全不同。管理端往往需要查明細(xì)、導(dǎo)出報(bào)表、做復(fù)雜條件篩選但大屏端需要的是當(dāng)前城市整體情況各站點(diǎn)實(shí)時(shí)等級24小時(shí)變化趨勢這類聚合信息。所以我給大屏端設(shè)計(jì)接口時(shí)會(huì)專門做輕量化的聚合返回。實(shí)時(shí)地圖接口只需要stationCode, stationName, longitude, latitude, aqi, level, color字段不需要返回整表所有監(jiān)測值。趨勢圖接口只需要返回指定時(shí)間段內(nèi)的時(shí)間點(diǎn)數(shù)組和數(shù)值數(shù)組。前端拿到的數(shù)據(jù)越瘦渲染就越流暢。這里給出一個(gè)實(shí)時(shí)站點(diǎn)數(shù)據(jù)接口的Controller示例RestController RequestMapping(/api/eco) public class EcoMonitorController { Autowired private MonitorDataService monitorDataService; /** * 大屏實(shí)時(shí)地圖接口 */ GetMapping(/realtime/stations) public ResultListStationRealtimeVO realtimeStations( RequestParam(required false) String regionCode, RequestParam(required false) Integer stationType) { ListStationRealtimeVO list monitorDataService.queryRealtimeStations(regionCode, stationType); return Result.ok(list); } /** * 24小時(shí)趨勢接口 */ GetMapping(/trend/24h) public ResultTrendVO trend24h( RequestParam String stationCode, RequestParam(defaultValue AQI) String indicatorCode) { TrendVO trend monitorDataService.queryTrend(stationCode, indicatorCode, 24); return Result.ok(trend); } }聚合查詢的實(shí)現(xiàn)上結(jié)合前面提到的表結(jié)構(gòu)SQL里最常用的模式就是按站點(diǎn)和小時(shí)做GROUP BY。如果歷史數(shù)據(jù)量很大比如超過幾千萬行直接查原始表做聚合會(huì)越來越慢。這時(shí)候可以建立小時(shí)聚合表定時(shí)任務(wù)把原始表的數(shù)據(jù)匯總進(jìn)去大屏趨勢查詢走聚合表原始數(shù)據(jù)表只承擔(dān)寫入和明細(xì)下載的職責(zé)。我自己實(shí)測下來同樣的24小時(shí)趨勢查詢原始表上執(zhí)行可能要兩三秒走聚合表之后基本穩(wěn)定在幾十毫秒。后端還有一個(gè)重要但容易被忽視的優(yōu)化是緩存。對于當(dāng)前城市實(shí)時(shí)空氣質(zhì)量等級分布這種變化頻率低、查詢頻率高的數(shù)據(jù)直接用Redis緩存五到十秒完全沒有問題。大屏頁面本身就有輪詢機(jī)制緩存策略不會(huì)影響實(shí)時(shí)性但能明顯降低數(shù)據(jù)庫的壓力。3.4 前端大屏渲染ECharts地圖與實(shí)時(shí)推送大屏頁面我一般選用ECharts配合Vue或純HTML頁面都能跑。ECharts在生態(tài)環(huán)境可視化領(lǐng)域幾乎是標(biāo)配地圖、散點(diǎn)、熱力、折線、儀表盤這些常用圖都有成熟方案而且支持WebSocket實(shí)時(shí)推送更新。最核心的實(shí)時(shí)地圖效果配置項(xiàng)大致是這樣的思路const chart echarts.init(document.getElementById(mainMap)); chart.setOption({ geo: { map: china, roam: true, itemStyle: { areaColor: #1b2b4a, borderColor: #4a6c9c } }, series: [{ type: effectScatter, coordinateSystem: geo, data: stationData, // [{name: 站點(diǎn)A, value: [116.4, 39.9, 85]}] symbolSize: 12, rippleEffect: { scale: 3 }, itemStyle: { color: function(params) { // 根據(jù)AQI等級返回對應(yīng)顏色 return aqiColorMap[params.value[2]] || #ccc; } } }] });這里有個(gè)很細(xì)節(jié)的點(diǎn)ECharts地圖的多邊形邊界數(shù)據(jù)在地圖縮放級別高的時(shí)候邊界會(huì)顯得比較粗建議把geo的itemStyle里的borderWidth調(diào)小到0.5左右視覺上會(huì)更精致。實(shí)時(shí)推送這塊我強(qiáng)烈建議用WebSocket而不是前端定時(shí)輪詢REST接口。原因有兩個(gè)一是省資源幾十個(gè)頁面同時(shí)打開每隔幾秒就發(fā)起一次HTTP請求服務(wù)器壓力非常大二是即時(shí)性好后端拿到監(jiān)測站的最新數(shù)據(jù)可以主動(dòng)推送給所有在線客戶端免去了輪詢的延遲。如果條件允許推送的消息不要發(fā)完整數(shù)據(jù)而是發(fā)一個(gè)數(shù)據(jù)版本號或者增量更新記錄前端收到后再去請求需要更新的接口數(shù)據(jù)這樣能顯著減少無效的網(wǎng)絡(luò)傳輸。4. 常見問題與排查技巧實(shí)錄4.1 圖表數(shù)據(jù)不更新或者更新延遲這個(gè)問題的表象是大屏上的數(shù)據(jù)一直沒有變化但數(shù)據(jù)庫里明明有新數(shù)據(jù)。我遇到過的原因有三種。第一種是前端瀏覽器緩存了GET請求。大屏頁面通過Axios或者fetch請求接口瀏覽器對GET請求會(huì)做緩存導(dǎo)致頁面刷新后拿到的還是舊數(shù)據(jù)。解決辦法很簡單在請求URL上追加一個(gè)時(shí)間戳參數(shù)或者統(tǒng)一把接口請求頭設(shè)置為Cache-Control: no-cache。第二種是后端SQL性能太差數(shù)據(jù)量一大聚合查詢超過了輪詢的間隔時(shí)間。一個(gè)四千萬行的監(jiān)測數(shù)據(jù)表如果不走聚合表直接查時(shí)間范圍跨一周的站點(diǎn)趨勢查詢很容易超過五秒。排查方法是在MySQL里開啟慢查詢?nèi)罩菊页龀^一秒鐘的SQL然后針對性優(yōu)化索引或者改造為聚合表查詢。第三種是WebSocket根本沒有建立成功但前端代碼沒有做好降級處理。頁面在WebSocket連接失敗時(shí)應(yīng)該自動(dòng)回退到HTTP輪詢模式避免整個(gè)大屏變成死屏。這個(gè)降級邏輯一定要提前做不要等上線后在現(xiàn)場才發(fā)現(xiàn)問題。4.2 ECharts站點(diǎn)散點(diǎn)太多導(dǎo)致頁面卡頓城市空氣質(zhì)量監(jiān)測站點(diǎn)通常不會(huì)特別多幾十一百個(gè)散點(diǎn)問題不大。但有些項(xiàng)目會(huì)疊加噪聲監(jiān)測點(diǎn)、污染源企業(yè)點(diǎn)位、積水監(jiān)測點(diǎn)等所有圖層的點(diǎn)加在一起可能有幾百上千個(gè)加上漣漪特效頁面的幀率會(huì)明顯下降大屏拖起來卡頓甚至CPU占用過高。我的經(jīng)驗(yàn)是分層處理地圖默認(rèn)展示的氣站、水站這類核心站點(diǎn)用effectScatter體現(xiàn)活躍態(tài)而附屬點(diǎn)位用普通的scatter不加漣漪特效。還有個(gè)更高效的做法是把點(diǎn)位數(shù)據(jù)按照地圖的zoom級別做縮放聚合地圖放大到一定程度才展示詳細(xì)點(diǎn)位縮小視野時(shí)只展示區(qū)域聚合后的點(diǎn)。雖然ECharts自身沒有內(nèi)置這個(gè)能力但通過監(jiān)聽georoam事件自己維護(hù)一個(gè)LOD數(shù)據(jù)源實(shí)現(xiàn)起來也不算復(fù)雜效果卻非常明顯。另外站點(diǎn)名稱的Label不要全量顯示否則文字會(huì)互相遮擋。只在縮放達(dá)到一定級別后顯示站名或者讓用戶點(diǎn)擊氣泡后再彈出詳情都是合理的交互方式。4.3 AQI計(jì)算和應(yīng)用中最容易出錯(cuò)的三個(gè)地方AQI計(jì)算邏輯本身不復(fù)雜但在工程落地時(shí)很容易出錯(cuò)。第一個(gè)錯(cuò)誤是不同污染物濃度單位混用。PM2.5的濃度從設(shè)備采集來的單位是μg/m3但是SO2、NO2的標(biāo)準(zhǔn)分段表中有些單位是mg/m3。如果換算系數(shù)漏了算出來的IAQI值會(huì)完全離譜。我的建議是在指標(biāo)字典表里明確存儲(chǔ)單位在計(jì)算前統(tǒng)一轉(zhuǎn)換為標(biāo)準(zhǔn)單位。第二個(gè)錯(cuò)誤是四舍五入的時(shí)機(jī)不對?？諝赓|(zhì)量指數(shù)的國標(biāo)要求先對各污染物IAQI取整然后再比較大小取最大值。如果計(jì)算過程中過早取整或者對AQI最終值重復(fù)取整結(jié)果會(huì)和標(biāo)準(zhǔn)算法有細(xì)微偏差。第三個(gè)錯(cuò)誤是無效值的處理。設(shè)備故障、標(biāo)定維護(hù)期間監(jiān)測值可能是負(fù)數(shù)、零值或者超出合理物理范圍。如果把這些臟數(shù)據(jù)帶入AQI計(jì)算會(huì)造成異常突變。我的做法是維護(hù)一個(gè)有效值范圍表每種指標(biāo)限定合理的最小值和最大值數(shù)據(jù)入庫前做過濾計(jì)算時(shí)不至于被臟數(shù)據(jù)干擾。4.4 多站點(diǎn)時(shí)間軸對齊問題為什么有的曲線圖上站點(diǎn)A的零點(diǎn)數(shù)據(jù)顯示在整點(diǎn)10:00站點(diǎn)B卻在10:02因?yàn)椴煌O(shè)備的采集周期、上報(bào)延遲完全不同。有五分鐘粒度的有十分鐘粒度的還有無規(guī)律延遲的。做時(shí)間序列曲線時(shí)直接拿原始時(shí)間點(diǎn)來畫圖多站點(diǎn)對比就會(huì)參差不齊視覺上很難看。我要做的第一步是把所有數(shù)據(jù)按照統(tǒng)一的分鐘窗口對齊比如取data_time四舍五入到最近整點(diǎn)或最近五分鐘的槽位。第二步是處理缺失時(shí)間點(diǎn)的補(bǔ)值問題最簡化的方案是向上填充或線性插值但插值結(jié)果和真實(shí)監(jiān)測值有偏差所以圖上最好用虛線標(biāo)記插值區(qū)間或者直接空出來的點(diǎn)位交給前端ECharts用connectNulls屬性控制。時(shí)間對齊還有一個(gè)容易踩的坑就是數(shù)據(jù)庫data_time字段存儲(chǔ)的是字符串還是DATETIME類型。雖然字符串也能查到數(shù)據(jù)但當(dāng)你要做BETWEEN時(shí)間范圍的查詢并且想走索引時(shí)字符串比較的效率遠(yuǎn)不如原生DATETIME。設(shè)計(jì)表結(jié)構(gòu)時(shí)直接選DATETIME類型后面能省很多事。4.5 大屏現(xiàn)場部署時(shí)的兼容性問題政企類項(xiàng)目的現(xiàn)場大屏經(jīng)常用一些老舊的Windows主機(jī)或者定制版瀏覽器。ECharts 5對瀏覽器有最低版本要求如果現(xiàn)場瀏覽器版本太低圖表可能直接白屏或者報(bào)錯(cuò)。我建議在開發(fā)階段就確定目標(biāo)瀏覽器并且用BrowserStack或者本地虛擬機(jī)做兼容性測試。部署時(shí)最好把ECharts的JS文件直接放在服務(wù)器上作為靜態(tài)資源加載不要依賴公共CDN。很多政務(wù)內(nèi)網(wǎng)環(huán)境訪問不了外網(wǎng)CDN如果代碼里引用的還是公網(wǎng)CDN地址到了現(xiàn)場圖表就全部加載不出來。這類問題一旦在現(xiàn)場發(fā)生排查起來是非常尷尬的所以我一般從第一天起就要求前端資源全部本地化。最后說點(diǎn)我的實(shí)際體會(huì)整個(gè)項(xiàng)目做完我最大的感受是生態(tài)監(jiān)測大屏這類可視化系統(tǒng)真正的技術(shù)難點(diǎn)并不在圖表畫得有多炫而在后端能不能把雜亂的多源數(shù)據(jù)治理成干凈、標(biāo)準(zhǔn)、可計(jì)算的信息。Java在整個(gè)鏈路里承擔(dān)的恰恰是最扎實(shí)、最不可省略的那部分工作。從數(shù)據(jù)標(biāo)準(zhǔn)化到AQI計(jì)算從聚合查詢到實(shí)時(shí)推送每一步都考驗(yàn)著后端工程師對業(yè)務(wù)的理解深度。如果你正在做或者準(zhǔn)備做類似的項(xiàng)目我建議把精力重點(diǎn)放在數(shù)據(jù)模型設(shè)計(jì)和指標(biāo)計(jì)算的準(zhǔn)確性上圖表反而不用過度糾結(jié)樣式先把數(shù)據(jù)搞清楚大屏自然就有了靈魂。