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