電力全流程報修平臺的分析與設計

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

摘要：當電力故障發生時，普通用戶通常求助于供電部門的服務熱線，但其只負責戶外公共用電設備的維護，無法介入戶內進行維修，無效的報修請求造成了公共報修資源的浪費，同時普通用戶也沒有專業的渠道能及時尋找到有可靠資質的維修師傅。為了解決這一社會問題，該項目依托所屬地公司，整合具備資質的第三方維修公司、用戶報修渠道、供電公司管控等資源構建了一個以Web應用、安卓端App、微信小程序與可視化數據分析中心四方互聯的電力全流程報修平臺，同時集成云端集群，實現了電力維保的科學化、精確化與智能化。

關鍵詞：電力報修;監控平臺;云集群;可視化

中圖分類號：TP3? 文獻標識碼：A

文章編號：1009-3044（2021）29-0082-03

1引言

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

2需求分析

通過對各方的走訪調查，得出各方需求具體如下：

1）針對客戶

①專業的維修工人。

②完善的投訴監管渠道。

③迅速的訂單處理速度。

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

2）針對工人

①完善的考評機制。

②簡易的故障問題梳理。

③易操作的接單應用。

3）針對管理人員與決策高層

①分流無用報修電話。

②全流程監控業務訂單狀況。

③科學化管理報修基礎數據。

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

⑤基于歷史數據進行相應數據分析，提高決策支持能力。

3總體設計

本平臺依托所屬地供電公司，整合社會上符合資質的電力維保人員構建了一個以Web應用、安卓端、微信小程序與可視化大屏四方互聯的電力全流程報修平臺。在平臺中，用戶可通過微信小程序進行及時的故障報修與反饋評價;工人可以通過安卓端及時接收服務推送并對維修全流程進行跟蹤記錄;管理員可以通過后臺管理端對工人資質進行審核，打通95598服務和相關內部用電維修資源。同時項目集成云端集群，采用分布式存儲與并行數據分析，實現對維修資源的智能調度與全流程監管，真正實現電力維保的科學化、精確化與智能化。

3.1平臺總體架構

本平臺的總體架構如圖1所示，主要由防火墻服務，一臺 Nginx服務器，兩臺后臺服務器，一臺Redis服務器，一臺MySQL 服務器以及云服務器集群構成。下面將從實際場景切入，一一介紹每一個技術點的作用及意義。

1）防火墻：安卓端、小程序端、Web管理端以及可視化大屏向后臺服務器發送請求，請求首先會被防火墻攔截。這里的防火墻作用有兩點：一是抵擋了大部分DDos和XSS攻擊，二是避免SQL注入引發的數據庫崩潰問題。

2）負載均衡：經防火墻過濾之后的請求會通過 Nginx 服務器，即負載均衡服務器。Nginx會綜合考慮兩臺后臺服務器的各類因素（內存占用，CPU利用率等）來選擇合適的服務器將請求轉發。有效解決大部分請求涌入同一臺服務器而造成服務器內存長時間占用過高的問題[2]。

3）設置兩臺后臺服務器有兩點原因：

①如果只有一臺服務器，在程序沒有優化得足夠好的情況下，大量的請求涌入可能會出現上述內存占用過高的問題，進一步可能導致服務器的崩潰。

②使用兩臺服務器實際上采用fallback機制，當系統需要更新時，可以在服務器A上進行更新，而服務器B則繼續接收請求，當服務器A更新完后再更新服務器B，轉由服務器A接收請求，這樣的需求在一臺服務器上是不可以實現的。

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

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

3.2數據庫設計

本平臺數據庫針對決策人員所提出的數據統計分析需求，同時為滿足用戶與工人業務即時性的需要，合理設定索引，有效提升平臺的數據分析與信息檢索效率。各表屬性設定滿足范式要求，并通過相應存儲過程的設置對客戶的電話、住址等個人信息進行有效性檢測，充分加強平臺信息的真實性與可靠性，具體數據庫E-R 圖如圖2示。

4云集群設計

4.1結構設計

本平臺云集群的具體結構可以簡化為如圖3所示的三臺節點構成的完全分布式集群。

其中hadoopMaster作為云集群的主節點，其上運行 Na?meNode、ResourceMananger等控制進程，hadoopSalve與 ha? dooopSlave1作為云集群的從節點，其上運行DataNode，NodeM?ananger等進程。

4.2流程設計

本平臺云集群的工作流程可以分為存儲流程與計算流程兩類，具體見圖4所示。

存儲流程主要指平臺將大規模歷史數據或者占用空間較大的視頻文件存儲到云集群分布式文件系統中，充分減輕后臺服務器存儲壓力，同時為后續集群的計算分析打下基礎。計算流程主要指集群基于自身存儲的海量數據根據對應MR作業進行相應計算分析。

圖4云集群工作流程設計圖

4.3 MR作業設計

此處以平臺報修時段統計為例，詳細介紹本平臺MR 的作業設計流程，具體如圖5所示。原始數據的第一個數據項為訂單編號，第二個數據項為創建的時間，在進行具體MR作業之前需要將其導入HDFS文件系統。數據準備完成后，MR作業便可進行Map 階段對應操作，將各節點所存數據進行分片處理，并對各片內時間信息進行提取與分類，最后輸出對應<key，val?ue>鍵值對。接著，MR作業進入Combine 階段，對節點本地生成的鍵值對信息進行合并操作，減少數據傳輸的帶寬壓力，防止集群達到性能瓶頸。最后，作業進入Ruduce階段，對各節點的統計信息進行統一匯總，并按對應時段標簽輸出統計結果，將其寫入MySQL數據庫中。后臺通過抽取數據庫中的統計數據，將其傳遞給前端數據大屏。前端借助Datav、Echarts等插件完成統計數據的可視化展示[3-4]。

5結束語

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

參考文獻：

[1]邱賢輝.關于當前電力營銷管理的幾點思考[J].廣西電業， 2007（4）：33-34

[2]許巖峰.基于Redis 的選課系統設計與實現[D].北京：中國科學院大學（中國科學院工程管理與信息技術學院），2017.

[3]陳茂軍.基于云平臺下的數據挖掘研究[D].南昌：華東交通大學，2016.

[4]徐偉. 面向聚類分析的迭代MapReduce計算模型研究[D].天津：天津大學，2012.

【通聯編輯：朱寶貴】