基于GIS 的智慧供熱平臺關鍵技術設計與實現(xiàn)

李石磊，常 晟，邵嘉興，楊紅千

（1.同方節(jié)能工程技術有限公司，北京 100000）

隨著國內科學技術的進步與集中供熱的發(fā)展，集中供熱日趨供熱面積大型化、自控系統(tǒng)完善化、管理體系復雜化、新技術多樣化，同時，對信息安全與軟件安全等級的要求也越來越高。因此，解決供熱過程中管理難度大、效率低、能耗高、數(shù)據(jù)亂、維修難、預警差、數(shù)據(jù)安全等問題，以及最大化提高生產(chǎn)效率和節(jié)約能源成本，成為急需解決的難題[1]。

因此，需要一個綜合的、全面的、統(tǒng)一的、智慧型管理與調度的供熱平臺軟件，以提高供熱運行管理效率，滿足新時期節(jié)能環(huán)保、智慧供熱的新需求。鑒于以上原因，本文以成功應用在實際供熱項目中的智慧供熱平臺為例，對在平臺建設過程中的部分關鍵技術進行介紹。

1 技術路線

在智慧供熱平臺建設過程中，主要參與的主體有數(shù)據(jù)、存儲與計算、處理與分析、調度與協(xié)同。因此，分別設計了數(shù)據(jù)融合模型、分布式存儲與內存計算、邊緣計算、云邊協(xié)同，用以解決各個環(huán)節(jié)中的主要問題。具體如下：

1）建立基于GIS的多源異構數(shù)據(jù)融合模型，對結構化數(shù)據(jù)、半結構化數(shù)據(jù)和非結構化進行融合、統(tǒng)一存儲，同時采用postGIS中間件，實現(xiàn)基于開源GIS引擎的城市級供熱空間數(shù)據(jù)的集成、展示與分析；

2）采用Hadoop 中的分布式文件系統(tǒng)與MapReduce中的內存計算，建立了分布式存儲業(yè)務模型與實時數(shù)據(jù)業(yè)務處理模型，解決了海量歷史數(shù)據(jù)的存儲、實時數(shù)據(jù)的高并發(fā)傳輸問題；

3）采用邊緣計算，建立邊緣計算業(yè)務模型，將網(wǎng)絡、計算、存儲、核心應用能力等有效結合，實時對邊緣數(shù)據(jù)進行處理，對負荷進行調節(jié)，使之有更快的服務響應、穩(wěn)定的服務性能、高效的傳輸處理能力；

4）采用云邊協(xié)同，建立云邊協(xié)同業(yè)務模型，將邊緣側的服務與云端實時同步，優(yōu)化資源分布、資源配置，實現(xiàn)了資源協(xié)同、策略協(xié)同、分布式計算管理，最終實現(xiàn)在海量數(shù)據(jù)、復雜應用、多場景服務、高并發(fā)數(shù)據(jù)下穩(wěn)定、持久、安全、統(tǒng)一的云邊協(xié)作方式。

2 關鍵技術

首先，建立數(shù)據(jù)融合模型，對多源異構數(shù)據(jù)進行處理，設計出統(tǒng)一存儲多源異構數(shù)據(jù)的數(shù)據(jù)模型，用以展示與存儲約8 萬條管線、約2 000個熱力站、約45 萬個建筑物、14個熱源、約1 000 萬熱用戶、約200萬設備、每年約100 T的數(shù)據(jù)量，解決了異構數(shù)據(jù)的存儲，打通數(shù)據(jù)壁壘，對數(shù)據(jù)進行統(tǒng)一維護與調度，為后期建立數(shù)據(jù)中臺奠定了基礎；其次，本文結合大數(shù)據(jù)中的Hadoop 和MapReduce，實現(xiàn)了基于Hadoop的分布式存儲模型與基于內存計算的實時數(shù)據(jù)處理模型，并采用機器學習算法對熱源負荷進行預測與調度，解決了海量歷史數(shù)據(jù)的存儲與高并發(fā)、秒級數(shù)據(jù)的傳輸問題；再次，本文采用邊緣計算與云邊協(xié)同，建立了邊緣計算業(yè)務模型與云邊協(xié)同業(yè)務模型，解決了熱力站數(shù)據(jù)不準、負荷過大、熱效率低等問題。

2.1 數(shù)據(jù)融合模型設計

由于智慧供熱平臺包含的異構數(shù)據(jù)較多、數(shù)據(jù)量極其大、類型復雜以及要與其他業(yè)務系統(tǒng)（比如收費系統(tǒng)、客服系統(tǒng)、投訴系統(tǒng)等）進行對接，因此，高效、安全、穩(wěn)定的數(shù)據(jù)模型設計顯得尤其重要。本文結合實際應用，設計了LSM數(shù)據(jù)融合模型，很好地解決了生產(chǎn)運行中結構化數(shù)據(jù)、半結構化數(shù)據(jù)和非結構化數(shù)據(jù)。

其中，數(shù)據(jù)融合算法，采用LSM 樹，即Log-Structured Merge-Trees，數(shù)據(jù)格式如圖1所示。

圖1 數(shù)據(jù)格式

圖1中，結構化數(shù)據(jù)以Data和Meta的形式進行存儲，每個Data 塊以Key-value 鍵值的形式進行管理，每個結構塊大小約60 K，超過60 K 的Data 塊繼續(xù)以Key-value 鍵值形式進行分割，直至數(shù)據(jù)塊大小滿足60 K；Meta塊為元數(shù)據(jù)信息，記錄數(shù)據(jù)塊的大小、創(chuàng)建時間、索引、數(shù)據(jù)類型等關鍵數(shù)據(jù)塊信息；FileInfo數(shù)據(jù)塊存儲非結構化數(shù)據(jù)，每個FileInfo 數(shù)據(jù)塊均由DataIndex 與MetaIndex 組成，DataIndex 用以記錄非結構化數(shù)據(jù)塊信息，MetaIndex記錄非結構化數(shù)據(jù)塊元數(shù)據(jù)信息，包括索引、時間戳、文件類型等。通過圖4數(shù)據(jù)模型，將結構化數(shù)據(jù)、非結構化數(shù)據(jù)進行融合，方便存儲與管理、同時也為web 端高效、安全訪問提供便利。

2.2 分布式存儲與內存計算

由于智慧供熱平臺數(shù)據(jù)量龐大、數(shù)據(jù)結構復雜、數(shù)據(jù)種類多等特征，利用數(shù)據(jù)融合對多源異構數(shù)據(jù)進行融合后，需要對海量數(shù)據(jù)和實時數(shù)據(jù)進行存儲與處理。這里采用基于Hadoop 的分布式存儲對數(shù)據(jù)進行多節(jié)點存儲，利用基于內存計算的MapReduce對實時數(shù)據(jù)進行處理，解決了海量數(shù)據(jù)存儲、融合、調度的問題，同時也解決了基于海量實時數(shù)據(jù)高并發(fā)的問題[2-5]

歷史數(shù)據(jù)與基礎數(shù)據(jù)分別以數(shù)據(jù)塊的形式存儲在Hadoop 上，Hadoop 以分布式部署在不同服務器節(jié)點上，經(jīng)過集群后進行高速運算與存儲，同時采用分布式文件系統(tǒng)，增強了系統(tǒng)的容錯性，以此提供高吞吐量和超大數(shù)據(jù)集的訪問。

智慧供熱平臺歷史數(shù)據(jù)龐大，主要來自于生產(chǎn)數(shù)據(jù)與業(yè)務系統(tǒng)數(shù)據(jù)。生產(chǎn)數(shù)據(jù)主要有傳感器監(jiān)測的溫度、壓力、流量等參數(shù)，50 萬點/30 s 上傳至服務器端；業(yè)務數(shù)據(jù)主要有用戶收費數(shù)據(jù)、投訴數(shù)據(jù)、客服數(shù)據(jù)、室溫數(shù)據(jù)等，定時上傳至服務器。因此，龐大的數(shù)據(jù)量要求數(shù)據(jù)存儲和訪問采用多服務器集群、多節(jié)點訪問。首先，客戶端訪問服務節(jié)點1，如果服務節(jié)點1 不存在該數(shù)據(jù)，則繼續(xù)向下索引服務二級節(jié)點；如果服務節(jié)點1 存在客戶端想要數(shù)據(jù)，則在該節(jié)點下索引數(shù)據(jù)節(jié)點，數(shù)據(jù)節(jié)點中包含多個數(shù)據(jù)塊，數(shù)據(jù)塊以Key-value 即鍵值對的形式存放數(shù)據(jù)，最終采用LSM樹數(shù)據(jù)模型對數(shù)據(jù)單元進行索引并組織后返回給客戶端。

實時數(shù)據(jù)通過集群環(huán)境，采用內存分布數(shù)據(jù)集進行迭代工作負載，實現(xiàn)了大型、低延遲、50萬實時數(shù)據(jù)秒級的并發(fā)訪問。基于MapReduce的實時數(shù)據(jù)結構設計如圖2所示。

圖2 實時數(shù)據(jù)結構設計

實時數(shù)據(jù)采集過程中，首先通過實時數(shù)據(jù)驅動器將實時數(shù)據(jù)按照一定的數(shù)據(jù)類型，比如溫度、壓力、流量、一次網(wǎng)、二次網(wǎng)等參數(shù)進行分類；其次，將分類后的實時數(shù)據(jù)通過數(shù)據(jù)模型管理器對數(shù)據(jù)進行分配，即根據(jù)不同的數(shù)據(jù)類型及數(shù)據(jù)價值特征分配到不同的數(shù)據(jù)工作節(jié)點，每個數(shù)據(jù)工作節(jié)點所承擔的數(shù)據(jù)量、計算力、數(shù)據(jù)大小等參數(shù)不同，使其接受數(shù)據(jù)模型管理器的統(tǒng)一調度；最后，數(shù)據(jù)工作節(jié)點中的執(zhí)行器，將數(shù)據(jù)、參數(shù)以及所要執(zhí)行的任務進行打包執(zhí)行，將結果存儲在數(shù)據(jù)節(jié)點上，以實時返回給實時數(shù)據(jù)驅動器。如果下一時刻，有相同的數(shù)據(jù)類型，該數(shù)據(jù)類型不再受數(shù)據(jù)模型管理器統(tǒng)一調度，而是按照數(shù)據(jù)記憶參數(shù)配置直接進入相應的數(shù)據(jù)工作節(jié)點參與運算，計算完成后直接將相應結果返回給實時數(shù)據(jù)驅動器，這樣節(jié)省了數(shù)據(jù)傳輸執(zhí)行時間，最大限度提高數(shù)據(jù)的實時性與執(zhí)行效率。

2.3 邊緣計算與云邊協(xié)同

由于城市級超大規(guī)模集中供熱面積龐大，末端設備數(shù)量大、工況復雜、算法模型較多，如果將硬件、熱源、熱力站、熱用戶所有數(shù)據(jù)和模型均放到云端進行執(zhí)行和調度，勢必會導致云端架構復雜、維護難度大、出錯率高、執(zhí)行效率低等問題。因此，適當為云端“減負”，釋放部分計算力給邊緣，讓邊緣用戶有自主計算力，能及時處理相應業(yè)務，使云端與邊緣互相補充，這樣不僅不會削弱云端計算能力，還提高了整體協(xié)調、運行能力。

在供熱中熱源、熱力站、熱用戶和主要傳感器設備作為整個智慧供熱平臺的感知層，其數(shù)據(jù)的可靠性很大程度上決定了云端對整個熱網(wǎng)的熱負荷調度，進而影響用戶室溫、能耗及成本；同時邊緣數(shù)據(jù)的可靠性差與數(shù)據(jù)滯后性導致不能實時反映全網(wǎng)運行特征，成為了急需解決的問題。因此，采用邊緣計算業(yè)務模型，將邊緣側、服務層、接口層與硬件傳感器打包作為一個感知體，有效解決了設備容錯率低、通信故障、傳輸延遲、計算復雜等問題。

智慧供熱平臺云端管理多個邊緣感知體，為其提供充足的虛擬化資源，可以持久化存儲和動態(tài)調整計算力，以滿足不同業(yè)務場景和數(shù)據(jù)并發(fā)的需求。云端通過網(wǎng)絡來控制邊緣，并提供高效、安全連接，而在網(wǎng)絡發(fā)生中斷時，中心云端會嘗試重復連接邊緣，但網(wǎng)絡中斷并不影響邊緣獨立運行，當網(wǎng)絡再次恢復時將任務上傳到中心云端。如圖3所示，首先，邊緣感知體通過網(wǎng)絡進入感知體調度器，在調度器中統(tǒng)一對邊緣各個感知體進行安全策略、資源、業(yè)務注冊；其次，感知體通過調度器統(tǒng)一分發(fā)到中心云端協(xié)作模型中，在協(xié)作層，各個感知體以及感知體對應的請求服務會以注冊ID的形式被協(xié)作器按照一定的參數(shù)進行分配，統(tǒng)一匯總智慧供熱平臺云端；最后，由云端接受各邊緣感知體的服務并參與下一步的計算與結果輸出，并將計算結果通過網(wǎng)絡返回給邊緣[6-11]

3 關鍵技術實現(xiàn)與應用

3.1 關鍵技術實現(xiàn)

1）數(shù)據(jù)融合模型。以智慧供熱平臺中的換熱站為例，采用LSM樹，對結構化數(shù)據(jù)和非結構化進行融合。實現(xiàn)過程如下：

步驟1：將換熱站的空間數(shù)據(jù)和其他結構化數(shù)據(jù)轉成Json格式；創(chuàng)建非結構化數(shù)據(jù)索引表并以base64二進制形式進行編碼；

步驟2：將步驟1中的數(shù)據(jù)按照圖4數(shù)據(jù)結構進行處理；

步驟3：將步驟2 中數(shù)據(jù)作為一條新記錄。首先，日志文件會以append形式增加一條記錄，這樣方便以后恢復使用；其次，將該記錄的索引插入C0中，這里在內存中完成，不涉及磁盤IO 操作；當C0達到一定閾值或一定時間間隔后，C0中的記錄會滾動合并到磁盤C1 中，當C1 中的容量達到一定閾值后會向C2 合并，依次類推，直至合并至Ck，至此，完成了數(shù)據(jù)的融合與存儲。

通過LSM樹將不同類型的數(shù)據(jù)進行融合，降低了不同類型數(shù)據(jù)存儲、讀寫的難度，也方便對數(shù)據(jù)的維護和管理。

2）分布式存儲與內存計算。智慧供熱平臺采用分布式文件系統(tǒng)HDFS 和基于內存計算的MapReduce對數(shù)據(jù)進行存儲和處理。其中，HDFS 對大量數(shù)據(jù)進行存儲，而MapReduce對大量數(shù)據(jù)進行計算。根據(jù)實際應用中數(shù)據(jù)量，智慧供熱平臺采用40臺服務器作為數(shù)據(jù)節(jié)點，每個節(jié)點服務器主要參數(shù)配置為：內存256 G，硬盤10 T，Linux 操作系統(tǒng)；具體設計過程參考2.2章節(jié)。實現(xiàn)過程如下：

步驟1：對供熱中結構化數(shù)據(jù)、半結構化數(shù)據(jù)、非結構化數(shù)據(jù)進行清洗，去除掉錯誤、冗余數(shù)據(jù)；

步驟2：將步驟1 中數(shù)據(jù)存儲在大數(shù)據(jù)倉庫中，并利用Hadoop平臺實現(xiàn)數(shù)據(jù)在不同業(yè)務場景下進行轉存的需要；同時利用ETL 計算框架對數(shù)據(jù)進行處理，再利用Hive 組件，通過HiveQL 將數(shù)據(jù)倉庫中的數(shù)據(jù)提交到MapReduce任務中；

步驟3：MapReduce 將步驟2 中的數(shù)據(jù)按照20 M（這個可以根據(jù)實際需要進行修改）劃分為一個數(shù)據(jù)單元，分叉復制到集群環(huán)境內其他數(shù)據(jù)服務器上；在ETL 程序分布的服務器上，用Master 服務器調度Worker服務器，并給Worker服務器分配相應的Map任務或Reduce任務；

步驟4：對于步驟3 中分配了Map 任務的Worker，用以實現(xiàn)對數(shù)據(jù)的讀取，當Map 任務接受到數(shù)據(jù)輸入時，會以鍵值對作為參數(shù)傳遞給Map 函數(shù)，Map函數(shù)會返回中間鍵值對，并以緩存的形式將其儲存在內存上；當中間鍵值對達到一定數(shù)量時，會被寫入到本地磁盤，本地磁盤會以多個分區(qū)對其進行存儲，每個分區(qū)對應一個Reduce任務；Master會把中間鍵值對位置轉發(fā)給Reduce Worker；

步驟5：Master 服務器會對Worker 服務器上的任務性質進行判斷，如果是Reduce任務，Master會通知Worker 當前所處具體區(qū)域位置，并由Reduce Worker把相同的鍵值對匯集起來；Reduce Worker遍歷完所有中間鍵值對后，向Reduce 函數(shù)提交查詢，Reduce 函數(shù)將輸出結果存儲在對應的磁盤分區(qū)上；

步驟6：當全部Map 任務和Reduce 任務執(zhí)行完畢后，Master 服務器會再次執(zhí)行ETL 計算框架對數(shù)據(jù)進行處理，執(zhí)行過程重復上述操作。

通過HDFS 分布式存儲與MapReduce 內存計算，有效解決了數(shù)據(jù)在高并發(fā)場景下存儲空間不足、讀寫速度慢、數(shù)據(jù)丟失等問題。

3）邊緣計算與云邊協(xié)同。智慧供熱平臺的邊緣側承擔了中心云端部分計算力。其物理組成包括1臺小型硬件服務器，主要參數(shù)配置：內存4 G、硬盤10 G、顯示器1個、Linux操作系統(tǒng)；通過物理設備將終端采集器PLC連接起來，形成小型局域網(wǎng)，該小型服務器被稱為“決策機”。在決策機上部署數(shù)據(jù)處理算法用來解決數(shù)據(jù)不準、容錯率低的問題，然后將處理后的數(shù)據(jù)上報云端；中心云端將部分計算力下放到邊緣的決策機上，讓決策機承擔底層業(yè)務工作，并定期將處理后的結果上報到云端；云端對決策機的處理結果按照一定規(guī)則進行檢驗與審核，最終將確認記錄歸檔。由于邊緣具有部分自主決策能力并與云端錯峰交互、數(shù)據(jù)同步與共享，使得在協(xié)同過程中減少由下層業(yè)務系統(tǒng)同時到達云端等待分配計算力、計算資源的時間，提高了云端與邊緣的協(xié)同效率，解決了在實際供熱中由于城市規(guī)模較大、供熱面積較廣導致調節(jié)滯后的問題。

3.2 應 用

智慧供熱平臺是基于GIS、物聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能于一體，集供熱生產(chǎn)“總數(shù)據(jù)中心、總展示中心、總指揮中心、總調度中心和總管理中心”五位一體的城市級綜合管控平臺。目前平臺完成了供熱數(shù)據(jù)統(tǒng)一與共享交換體系，實現(xiàn)供熱生產(chǎn)經(jīng)營等各類數(shù)據(jù)的整條鏈路透視化管理；通過機器學習為供熱管理人員提供科學、精準的一體化運營解決方案，也為生產(chǎn)人員提供調度和調控的數(shù)據(jù)指標，最終提高供熱管理的精細化程度，實現(xiàn)供熱生產(chǎn)的高效管理、精準調控、節(jié)能降耗和暖民服務[12-15]。

智慧供熱平臺由設備感知層、數(shù)據(jù)存儲層、模型調度層、中間應用層與頂層應用層組成。設備感知層由硬件PLC 采集器組成，組態(tài)通過modbus 協(xié)議對PLC設備進行數(shù)據(jù)采集，其采集的數(shù)據(jù)為秒級實時數(shù)據(jù)，另一部分則是從其他業(yè)務系統(tǒng)通過TCP/IP 協(xié)議集成的收費、客服與室溫數(shù)據(jù)；通過OPC 協(xié)議或socket 即時通訊協(xié)議將組態(tài)數(shù)據(jù)存到內存庫中，歷史數(shù)據(jù)則存入到大數(shù)據(jù)平臺的分布式文件庫中；GIS 數(shù)據(jù)、實時數(shù)據(jù)、歷史數(shù)據(jù)通過大數(shù)據(jù)分析模型、GIS空間處理模型、數(shù)據(jù)安全模型、機器學習算法等，計算輸出到基于微服務架構的中間應用層中，例如地理信息系統(tǒng)、生產(chǎn)調度系統(tǒng)、能耗管理系統(tǒng)等，最終由基于微服務架構的應用系統(tǒng)按需輸出到智慧供熱平臺中。

4 結語

本文介紹了基于GIS 的智慧供熱平臺在超大規(guī)模城市集中供熱中的部分關鍵技術，結合多源數(shù)據(jù)融合算法，采用LSM 樹建立了數(shù)據(jù)融合模型，解決了供熱過程中的結構化數(shù)據(jù)、非結構化數(shù)據(jù)等多源異構數(shù)據(jù)格式不統(tǒng)一、來源不統(tǒng)一、無法統(tǒng)一存儲、索引低效等問題；介紹了大數(shù)據(jù)技術中的Hadoop 與MapReduce，并采用分布式存儲與內存計算，解決了在實際應用中遇到的海量數(shù)據(jù)存儲、高并發(fā)、高密度、實時性要求高的問題；通過邊緣計算與云邊協(xié)同，解決了在實際應用中熱源、熱力站、熱用戶邊緣數(shù)據(jù)不準、容錯率低、云端協(xié)同效率低、調節(jié)滯后等問題。

最后，基于以上技術的智慧供熱平臺在實際項目中平穩(wěn)運行3 a 有余，目前平臺還處于繼續(xù)建設階段，接下來將重點對平臺的人工智能方面進行建設，為城市級的智慧供熱大腦，為智慧城市建設添磚加瓦。