電力全流程報(bào)修平臺(tái)的分析與設(shè)計(jì)

王清永 劉沁儀 陳逸彬 陳森博

摘要：當(dāng)電力故障發(fā)生時(shí)，普通用戶通常求助于供電部門(mén)的服務(wù)熱線，但其只負(fù)責(zé)戶外公共用電設(shè)備的維護(hù)，無(wú)法介入戶內(nèi)進(jìn)行維修，無(wú)效的報(bào)修請(qǐng)求造成了公共報(bào)修資源的浪費(fèi)，同時(shí)普通用戶也沒(méi)有專(zhuān)業(yè)的渠道能及時(shí)尋找到有可靠資質(zhì)的維修師傅。為了解決這一社會(huì)問(wèn)題，該項(xiàng)目依托所屬地公司，整合具備資質(zhì)的第三方維修公司、用戶報(bào)修渠道、供電公司管控等資源構(gòu)建了一個(gè)以Web應(yīng)用、安卓端App、微信小程序與可視化數(shù)據(jù)分析中心四方互聯(lián)的電力全流程報(bào)修平臺(tái)，同時(shí)集成云端集群，實(shí)現(xiàn)了電力維保的科學(xué)化、精確化與智能化。

關(guān)鍵詞：電力報(bào)修;監(jiān)控平臺(tái);云集群;可視化

中圖分類(lèi)號(hào)：TP3? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2021）29-0082-03

1引言

近年來(lái)，隨著經(jīng)濟(jì)的高速發(fā)展，人們對(duì)電力的依賴程度不斷加大[1]。當(dāng)電力故障發(fā)生時(shí)，普通用戶通常會(huì)撥打供電公司的報(bào)修電話尋求幫助，但是供電公司維護(hù)的是戶外的公共用電設(shè)備，而非入戶的電力設(shè)備與線路，無(wú)效的報(bào)修請(qǐng)求造成用戶對(duì)供電公司不作為的誤解，也造成了公共報(bào)修資源的浪費(fèi)。面對(duì)急需解決的用電故障，普通用戶會(huì)求助于社區(qū)論壇等一些信息平臺(tái)或街邊小廣告。這些信息中往往存在著資質(zhì)可靠工人少、服務(wù)范圍窄、反饋時(shí)間長(zhǎng)等諸多問(wèn)題。另一方面，社會(huì)上對(duì)普通用戶的家庭用電故障的維修服務(wù)沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)與監(jiān)管渠道，維修過(guò)程始終處于無(wú)監(jiān)管狀態(tài)，維修質(zhì)量完全取決于各個(gè)維修師傅的態(tài)度認(rèn)真程度，其中產(chǎn)生的價(jià)格糾紛和質(zhì)量問(wèn)題往往處于不可控狀態(tài)。因此，基于供電公司整合社會(huì)上符合資質(zhì)的維修維護(hù)人員構(gòu)建一個(gè)高效、權(quán)威、全流程監(jiān)管的電力報(bào)修平臺(tái)，實(shí)現(xiàn)電力維保的科學(xué)化與精準(zhǔn)化就顯得尤為重要。

2需求分析

通過(guò)對(duì)各方的走訪調(diào)查，得出各方需求具體如下：

1）針對(duì)客戶

①專(zhuān)業(yè)的維修工人。

②完善的投訴監(jiān)管渠道。

③迅速的訂單處理速度。

④易操作的提交訂單程序。

2）針對(duì)工人

①完善的考評(píng)機(jī)制。

②簡(jiǎn)易的故障問(wèn)題梳理。

③易操作的接單應(yīng)用。

3）針對(duì)管理人員與決策高層

①分流無(wú)用報(bào)修電話。

②全流程監(jiān)控業(yè)務(wù)訂單狀況。

③科學(xué)化管理報(bào)修基礎(chǔ)數(shù)據(jù)。

④圖例化展示電力維保信息，提高工作效率。

⑤基于歷史數(shù)據(jù)進(jìn)行相應(yīng)數(shù)據(jù)分析，提高決策支持能力。

3總體設(shè)計(jì)

本平臺(tái)依托所屬地供電公司，整合社會(huì)上符合資質(zhì)的電力維保人員構(gòu)建了一個(gè)以Web應(yīng)用、安卓端、微信小程序與可視化大屏四方互聯(lián)的電力全流程報(bào)修平臺(tái)。在平臺(tái)中，用戶可通過(guò)微信小程序進(jìn)行及時(shí)的故障報(bào)修與反饋評(píng)價(jià);工人可以通過(guò)安卓端及時(shí)接收服務(wù)推送并對(duì)維修全流程進(jìn)行跟蹤記錄;管理員可以通過(guò)后臺(tái)管理端對(duì)工人資質(zhì)進(jìn)行審核，打通95598服務(wù)和相關(guān)內(nèi)部用電維修資源。同時(shí)項(xiàng)目集成云端集群，采用分布式存儲(chǔ)與并行數(shù)據(jù)分析，實(shí)現(xiàn)對(duì)維修資源的智能調(diào)度與全流程監(jiān)管，真正實(shí)現(xiàn)電力維保的科學(xué)化、精確化與智能化。

3.1平臺(tái)總體架構(gòu)

本平臺(tái)的總體架構(gòu)如圖1所示，主要由防火墻服務(wù)，一臺(tái) Nginx服務(wù)器，兩臺(tái)后臺(tái)服務(wù)器，一臺(tái)Redis服務(wù)器，一臺(tái)MySQL 服務(wù)器以及云服務(wù)器集群構(gòu)成。下面將從實(shí)際場(chǎng)景切入，一一介紹每一個(gè)技術(shù)點(diǎn)的作用及意義。

1）防火墻：安卓端、小程序端、Web管理端以及可視化大屏向后臺(tái)服務(wù)器發(fā)送請(qǐng)求，請(qǐng)求首先會(huì)被防火墻攔截。這里的防火墻作用有兩點(diǎn)：一是抵擋了大部分DDos和XSS攻擊，二是避免SQL注入引發(fā)的數(shù)據(jù)庫(kù)崩潰問(wèn)題。

2）負(fù)載均衡：經(jīng)防火墻過(guò)濾之后的請(qǐng)求會(huì)通過(guò) Nginx 服務(wù)器，即負(fù)載均衡服務(wù)器。Nginx會(huì)綜合考慮兩臺(tái)后臺(tái)服務(wù)器的各類(lèi)因素（內(nèi)存占用，CPU利用率等）來(lái)選擇合適的服務(wù)器將請(qǐng)求轉(zhuǎn)發(fā)。有效解決大部分請(qǐng)求涌入同一臺(tái)服務(wù)器而造成服務(wù)器內(nèi)存長(zhǎng)時(shí)間占用過(guò)高的問(wèn)題[2]。

3）設(shè)置兩臺(tái)后臺(tái)服務(wù)器有兩點(diǎn)原因：

①如果只有一臺(tái)服務(wù)器，在程序沒(méi)有優(yōu)化得足夠好的情況下，大量的請(qǐng)求涌入可能會(huì)出現(xiàn)上述內(nèi)存占用過(guò)高的問(wèn)題，進(jìn)一步可能導(dǎo)致服務(wù)器的崩潰。

②使用兩臺(tái)服務(wù)器實(shí)際上采用fallback機(jī)制，當(dāng)系統(tǒng)需要更新時(shí)，可以在服務(wù)器A上進(jìn)行更新，而服務(wù)器B則繼續(xù)接收請(qǐng)求，當(dāng)服務(wù)器A更新完后再更新服務(wù)器B，轉(zhuǎn)由服務(wù)器A接收請(qǐng)求，這樣的需求在一臺(tái)服務(wù)器上是不可以實(shí)現(xiàn)的。

4）冷熱數(shù)據(jù)切換：在設(shè)計(jì)本平臺(tái)的過(guò)程中，發(fā)現(xiàn)有多類(lèi)數(shù)據(jù)需要被頻繁訪問(wèn)（如：訂單，客戶評(píng)價(jià)等數(shù)據(jù)），考慮到平臺(tái)將來(lái)的落地背景，在使用的用戶有一定規(guī)模的情況下，如此頻繁地向數(shù)據(jù)庫(kù)訪問(wèn)這些熱點(diǎn)數(shù)據(jù)會(huì)造成MySQL性能的下降。所以考慮使用Redis來(lái)和MySQL進(jìn)行冷熱數(shù)據(jù)的切換，當(dāng)用戶上線時(shí)，把一些用戶可能需要頻繁訪問(wèn)的熱點(diǎn)數(shù)據(jù)從MySQL轉(zhuǎn)移到Redis 中。這樣，當(dāng)用戶訪問(wèn)這些熱點(diǎn)數(shù)據(jù)時(shí)，直接可以從 Redis服務(wù)器中抽取數(shù)據(jù)，獲取數(shù)據(jù)的速度有較大提升。在每天凌晨，或是用戶很久不上線的時(shí)候再把這些熱點(diǎn)數(shù)據(jù)回傳到 MySQL服務(wù)器中變成冷數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)的持久化。

5）云服務(wù)器集群：本平臺(tái)為方便管理員與決策高層清晰地觀察系統(tǒng)的運(yùn)行狀況及用戶、工人的使用情況，集成了可視化展示功能。考慮到平臺(tái)未來(lái)落地的背景，且對(duì)數(shù)據(jù)分析算法性能的高度要求，本平臺(tái)進(jìn)一步引進(jìn)基于 Hadoop 的云服務(wù)器集群，實(shí)現(xiàn)聯(lián)機(jī)并行的統(tǒng)計(jì)分析。同時(shí)，一些圖片、視頻、json等存儲(chǔ)占用率高的數(shù)據(jù)也存儲(chǔ)在云端，充分減輕后臺(tái)數(shù)據(jù)庫(kù)的存儲(chǔ)壓力。

3.2數(shù)據(jù)庫(kù)設(shè)計(jì)

本平臺(tái)數(shù)據(jù)庫(kù)針對(duì)決策人員所提出的數(shù)據(jù)統(tǒng)計(jì)分析需求，同時(shí)為滿足用戶與工人業(yè)務(wù)即時(shí)性的需要，合理設(shè)定索引，有效提升平臺(tái)的數(shù)據(jù)分析與信息檢索效率。各表屬性設(shè)定滿足范式要求，并通過(guò)相應(yīng)存儲(chǔ)過(guò)程的設(shè)置對(duì)客戶的電話、住址等個(gè)人信息進(jìn)行有效性檢測(cè)，充分加強(qiáng)平臺(tái)信息的真實(shí)性與可靠性，具體數(shù)據(jù)庫(kù)E-R 圖如圖2示。

4云集群設(shè)計(jì)

4.1結(jié)構(gòu)設(shè)計(jì)

本平臺(tái)云集群的具體結(jié)構(gòu)可以簡(jiǎn)化為如圖3所示的三臺(tái)節(jié)點(diǎn)構(gòu)成的完全分布式集群。

其中hadoopMaster作為云集群的主節(jié)點(diǎn)，其上運(yùn)行 Na?meNode、ResourceMananger等控制進(jìn)程，hadoopSalve與 ha? dooopSlave1作為云集群的從節(jié)點(diǎn)，其上運(yùn)行DataNode，NodeM?ananger等進(jìn)程。

4.2流程設(shè)計(jì)

本平臺(tái)云集群的工作流程可以分為存儲(chǔ)流程與計(jì)算流程兩類(lèi)，具體見(jiàn)圖4所示。

存儲(chǔ)流程主要指平臺(tái)將大規(guī)模歷史數(shù)據(jù)或者占用空間較大的視頻文件存儲(chǔ)到云集群分布式文件系統(tǒng)中，充分減輕后臺(tái)服務(wù)器存儲(chǔ)壓力，同時(shí)為后續(xù)集群的計(jì)算分析打下基礎(chǔ)。計(jì)算流程主要指集群基于自身存儲(chǔ)的海量數(shù)據(jù)根據(jù)對(duì)應(yīng)MR作業(yè)進(jìn)行相應(yīng)計(jì)算分析。

圖4云集群工作流程設(shè)計(jì)圖

4.3 MR作業(yè)設(shè)計(jì)

此處以平臺(tái)報(bào)修時(shí)段統(tǒng)計(jì)為例，詳細(xì)介紹本平臺(tái)MR 的作業(yè)設(shè)計(jì)流程，具體如圖5所示。原始數(shù)據(jù)的第一個(gè)數(shù)據(jù)項(xiàng)為訂單編號(hào)，第二個(gè)數(shù)據(jù)項(xiàng)為創(chuàng)建的時(shí)間，在進(jìn)行具體MR作業(yè)之前需要將其導(dǎo)入HDFS文件系統(tǒng)。數(shù)據(jù)準(zhǔn)備完成后，MR作業(yè)便可進(jìn)行Map 階段對(duì)應(yīng)操作，將各節(jié)點(diǎn)所存數(shù)據(jù)進(jìn)行分片處理，并對(duì)各片內(nèi)時(shí)間信息進(jìn)行提取與分類(lèi)，最后輸出對(duì)應(yīng)<key，val?ue>鍵值對(duì)。接著，MR作業(yè)進(jìn)入Combine 階段，對(duì)節(jié)點(diǎn)本地生成的鍵值對(duì)信息進(jìn)行合并操作，減少數(shù)據(jù)傳輸?shù)膸拤毫Γ乐辜哼_(dá)到性能瓶頸。最后，作業(yè)進(jìn)入Ruduce階段，對(duì)各節(jié)點(diǎn)的統(tǒng)計(jì)信息進(jìn)行統(tǒng)一匯總，并按對(duì)應(yīng)時(shí)段標(biāo)簽輸出統(tǒng)計(jì)結(jié)果，將其寫(xiě)入MySQL數(shù)據(jù)庫(kù)中。后臺(tái)通過(guò)抽取數(shù)據(jù)庫(kù)中的統(tǒng)計(jì)數(shù)據(jù)，將其傳遞給前端數(shù)據(jù)大屏。前端借助Datav、Echarts等插件完成統(tǒng)計(jì)數(shù)據(jù)的可視化展示[3-4]。

5結(jié)束語(yǔ)

本平臺(tái)依托所屬地供電公司，在實(shí)現(xiàn)了傳統(tǒng)報(bào)修功能的基礎(chǔ)上，充分審核維修人員的資質(zhì)，有效地幫助供電公司分流客戶報(bào)修電話，充分提高其工作效率，為用電維修行業(yè)提供一個(gè)規(guī)范和監(jiān)督渠道。同時(shí)平臺(tái)基于云集群，構(gòu)建了一套電力故障全流程數(shù)據(jù)分析與可視化方案，充分提高平臺(tái)的決策支持能力。平臺(tái)未來(lái)一方面將延伸設(shè)計(jì)iOS端的應(yīng)用程序，滿足用戶的個(gè)性化需求;另一方面，將加強(qiáng)與智慧城市等綜合服務(wù)平臺(tái)的對(duì)接，全面推廣用電安全知識(shí)，不斷增進(jìn)民生福祉。

參考文獻(xiàn)：

[1]邱賢輝.關(guān)于當(dāng)前電力營(yíng)銷(xiāo)管理的幾點(diǎn)思考[J].廣西電業(yè)， 2007（4）：33-34

[2]許巖峰.基于Redis 的選課系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].北京：中國(guó)科學(xué)院大學(xué)（中國(guó)科學(xué)院工程管理與信息技術(shù)學(xué)院），2017.

[3]陳茂軍.基于云平臺(tái)下的數(shù)據(jù)挖掘研究[D].南昌：華東交通大學(xué)，2016.

[4]徐偉. 面向聚類(lèi)分析的迭代MapReduce計(jì)算模型研究[D].天津：天津大學(xué)，2012.

【通聯(lián)編輯：朱寶貴】