雲資料庫 GaussDB(for Influx) 解密第十一期：讓智能電網中時序數據處理更高效

摘要：GaussDB（for Influx）是一款基於計算存儲分離架構，完全相容 InfluxDB 生態的雲原生時序資料庫。本文分享自華為雲社區《雲資料庫 GaussDB(for Influx) 解密第十一期：讓智能電網中時序數據處理更高效》，作者：華為雲資料庫 GaussDB（for Influ ...

摘要：GaussDB（for Influx）是一款基於計算存儲分離架構，完全相容 InfluxDB 生態的雲原生時序資料庫。

本文分享自華為雲社區《雲資料庫 GaussDB(for Influx) 解密第十一期：讓智能電網中時序數據處理更高效》，作者：華為雲資料庫 GaussDB（for Influx）。

電網場景中的時序數據

今天在手機上就可以直接交電費、查看剩餘電量、電量不足還可以發出告警提醒、以及分析過去的用電情況、預估未來用電情況等等。再也不用去繳費點繳費，也不用人工去每個電錶上抄每家的使用情況，這些都基於我們國家的智能電網建設，而以上只是對消費者帶來的一些便利。智能電網在電網線路監控、電力調度、配電等方面發揮著越來越重要的作用。

智能電網是由許多部分組成，包括智能變電站，線路輸送，智能交互終端，智能電錶，智能中央系統等等。每個部分都集成了大量的感測器，這些分佈在全網各節點的感測器無時無刻不在收集各類數據。隨著中國智能電網建設的不斷完善，其測點的規模越來越大，達到數千萬級以上，並且單個測點將以分鐘級甚至秒級的頻率產生數據。將會產生海量的監控數據，而且這些數據大部分屬於時序數據。因此在針對智能電網構建集中式數據中心時，如何存儲、處理、分析海量的監控數據成為一個難點，具體包括以下麵三個方面 :

數據規模超大，分佈密集，數據存儲難

以智能電網中WAMS 系統為例，每秒需要處理的時序數據記錄數可達到一千萬，因此需要支撐每秒千萬級別的寫入。常規的數據處理方式根本無法滿足需求。

數據處理實時性需求高

針對數千萬的電錶終端，客戶在充值後要立即生效，客戶產生的電量要實時的計費，並反饋給客戶等場景，都需要實時的處理海量數據；針對數千公裡的電網線路監控，如果出現異常，要能及時告警等。

數據價值挖掘困難

電網檢測點多，檢測信息密集，在如此海量的數據中挖掘出有價值的信息也會遇到很大的挑戰。

智能電網設備中的時序數據

智能電網中的時序數據一般是指由設備／儀錶產生，由感測器進行收集，與某一設備具體相關，在時間上前後存在關聯性的一類數據。如上圖所示，對於電網中的電錶設備，其電壓、電流值就是典型的時序數據。

一條時序數據記錄一般可定義為三元組： <DevicelD, Timestamp, Value>

DeviceID : 產生該條數據的物理設備／感測器
TimeStamp為記錄產生的時間戳
Value : 為設備測點具體的值。

在智能電網設備運行中，需要存儲的數據包括狀態量和模擬量。狀態量反應設備的運行狀態和告警狀態，一般通過事件順序（Sequence of Event，SOE）記錄可滿足對數據的檢索和分析需求。電流、電壓和功率等模擬量會隨著設備運行時刻變化，具有明顯的時序特性，需要進行時序存儲。通過在選定的時間內查詢 SOE 記錄，可以將狀態量和模擬量進行關聯分析。智能電網監控系統中，已對斷路器、隔離開關，變壓器、負荷和聯絡線等電網設備進行建模，數據模型包括狀態量和模擬量，其中模擬量包括電壓、電流、有功、無功和頻率等，不同的設備類型需要採集和存儲的模擬量不同。以智能電錶為例子，智能電錶是組成智能電網的基礎設施，通常安裝在用戶樓宇，用於收集每戶產生的電力負荷數據，智能電錶至少每天將這些信息反饋給中央系統。智能電網時間序列數據主要由大量的時間戳/值對組成，且通常一次寫入，多次查詢，很少修改或刪除，但可追加，根據智能電網應用場景，一般訪問一段時間內或某一時間點的數據。下麵我們可以具體看一下不同的電網設備採集和存儲時序數據也大有不同。

各類智能電網設備時序數據測點舉例

線路輸送設備數據存儲需求

智能電網線路設備主要包括母聯，母線，變壓器，容抗器，聯絡線，負荷和發電機，這些設備採集和觀測的指標也各有不同。

智能電錶設備數據存儲需求

主要指安裝在用戶樓宇的智能電錶收集的電力負荷數據，本質上是時間序列數據。以固定的短暫的時間間隔為單位持續記錄，並實時反饋給中央監控系統。其對於客戶和電網公司非常重要，因其可被用於許多電網服務，比如跟蹤電能消耗和預測電力負荷。除此之外，電能表凍結電量值 - 電能表定時凍結，瞬時凍結，日凍結，整點凍結也是很重要的指標，用於計費用戶用電量和管理梯度用電使用情況。一般會對電能表定時凍結，瞬時凍結，日凍結，整點凍結數據存儲和查詢，方便對年度、季度、月度的電量進行計算查詢。

電網數據常用的查詢場景

智能電網數據採集及監控系統（SCADA）作為智能電力物聯網的一部分，對於時序數據處理有著多種維度查需和數據聚合需求，不僅需要實時監控，需要歷史數據分析，例如歷史 PDR 反演和事故分析。

因此智能電網行業應用場景對時序數據的訪問方式主要有三種：

折線查詢： 獲取指定設備一段時間內的相關量測值，如查詢特定用戶智能電錶在一段連續時間內的有功電能量。即測量對象為正向有功尖能量 (fd.shark.electricity)，測量屬性user= lvsejiayuan.A.unit2.603，dtype=ammeter，需查詢2014.09.01 這一天的正向有功尖電能量。

對於折線查詢，對象為監測的設備或關註的指標，特征集可標識為FSet = <(t1,v1), (t2,v2), ......, (tn,vn)>，其中 (t1, t2, t3, ......, tn) 為特定的時間序列，使用基於時間戳的偏移表示；(v1, v2, v3, ......, vn) 為與時間序列相對應的量測值。

斷面查詢 : 獲取特定時間點特定區域內所有設備的相關量測值，如查詢特定時間點某地區所有用戶智能電錶的有功電能量。及測量對象為正向有功尖能量 (fd.shark.electricity)，測量屬性 dtype=ammeter，時間戳為 1409529600 (2014.09.01 08:00:00)，需查詢某地區特定時刻所有智能電錶的正向有功尖電能量。

對於斷面查詢，對象為關註的區域/邏輯對象 (如街道/生活區/電廠)，特征集可標識為 FSet = <(d1,v1), (d2,v2), ......, (dn,vn)>，其中 (d1, d2, d3, ......, dn) 為區域/邏輯對象所包含的設備/測點，(v1, v2, v3, ......, vn) 為對應的設備/測點在指定時間戳的值。

設備最新狀態查詢 : 這種場景類似於斷面查詢，只是針對最新最近的數據。通常用於檢測設備是否正常工作。

電網時序數據存儲探索

最早的時候，智能電網相關應用系統中，一般使用 Oracle，Db2 等關係型資料庫處理時序數據。

然而，傳統的實體關係模型在應對時序數據時存在如下問題 :

數據存儲孤立分離。按照實體關係模型，一條時序數據記錄被保存為單獨的一行，因此連續時間段內的數據被孤立分離地存儲在資料庫中。
數據的訪問速度與數據量的大小成反比。隨著數據量的增加，訪問速度越來越慢。同時，大多數關係型資料庫為了提升查詢性能，針對大量數據建立索引，由此消耗大量的系統資源。
無法滿足時序數據的實時處理需求。對於海量時序數據，關係型資料庫無法高速的載入並滿足處理需求。

後來，電力系統內的普遍做法轉向使用商業時序資料庫軟體，如 OSIsoft Pi、eDNA 等作為時序數據的存儲和讀取工具。利用實時資料庫進行時序數據處理。

然而實時資料庫在應對智能電網大數據時存在如下問題：

無法支持大規模測點管理。對於國家級或省級智能電網而言，需要支持上億甚至上十億的測點規模。然而，無論 PI，eDNA，均無法為大規模測點管理提供支撐。
擴展能力不足。實時資料庫一般只支持單機部署，無法集群部署，無法支撐大規模數據應用。
高可用與數據安全性不足。實時資料庫一般不具備高可用特性，對於所存儲的數據的安全性，也完全依賴於硬體與資料庫軟體本身，不支持數據冗餘備份，無法應對大數據分析場景。

隨著大數據技術的發展，近年來也有一些基於開源的 HBase，Cassandra 等 NoSQL 資料庫處理時序數據的研究和應用。這些分散式 NoSQL 資料庫雖然解決了擴展能力，但是其通用的數據組織方式並不完全適合智能電網行業對時序數據存儲和查詢需求，用戶必鬚根據實際應用場景，進行特殊設計甚至大量數據冗餘存儲才能較好的利用資源處理請求。

大部分僅提供的單個測點的數據存儲介面，無法將設備模型數據與離散測點結合，難以支撐歷史潮流分析、故障分析和 WAMS 等智能電網高級應用。除此之外，它們的數據模型單一，對於讀取一定時間範圍內的數據記錄效率較高，但對於定位某個時間點的多條記錄，過濾，組合等一系列操作將浪費大量 I/O 資源。

其次，二維數據模型中的每個存儲單元由主鍵和列限定符唯一表示，因而大部分磁碟都浪費在存儲重覆的主鍵，存在大量冗餘信息，存儲效率低。同時，由於智能電網場景對於時序數據處理有著多種維度查需和數據聚合需求，通用KV 資料庫往往需要結合 ElasticSearch / Solr 等搜索引擎進行加速或者需要開發巧妙設計 KV 結構才能達到很好的效果，但是這樣大幅度提升了開發員人的學習和運維成本。

針對電網場景中時序數據，專業的分散式時序資料庫是最好的選擇，因為他們具備以下重要的特性 :

靈活多變的數據模型 : 用戶根據業務需求，通過標簽組合的方式自由定義數據模型，同時也可以根據業務變化和演進進行變更。

高寫入吞吐量 : 分散式時序資料庫解決大規模集群的橫向擴展問題，保證高性能平穩寫入的需求。

在一些大規模的應用性能監控、物聯網場景，海量的設備持續產生時序數據，例如省域級別的電網用電測量數據，9000萬數量級的電錶設備，原來每個月採集一次，後續業務升級後15分鐘採集一次，每秒需要處理的時序數據點數達到數百萬甚至千萬數據點，需要龐大且可以橫向水平擴展的集群來支撐全量的業務寫入。

高效的時序數據查詢與分析 : 時序資料庫支持多維時間線檢索、並具備流式處理、預計算等能力，滿足大規模 APM、物聯網，工業物聯網等業務場景的典型查詢需求。

在典型的監控場景，通常需要對長周期的數據進行查詢分析，比如針對某些指標最近1天、3天、7天、1個月的趨勢分析、報表等；而在物聯網場景，有一類比較典型的斷面查詢需求，例如查詢某個省指定時間所有電錶的用電量量明細數據，查詢某個品牌空調的某個時間的平均運行溫度；這些查詢要掃描大量的集群數據才能拿到結果，同時查詢的結果集也可能非常大。

低成本的時序數據存儲 : 時序資料庫充分利用好時序數據量大、冷熱訪問特征明顯，進行計算、存儲資源的解耦，通過低成本存儲介質、壓縮編碼、冷熱分離、高效 TTL等技術將數據存儲成本降低到極致。

在車聯網場景，20000輛車每小時就產生近百 GB 的車輛指標數據。如果要保存一年的運行數據就需要PB級的數據存儲規模。由於數據規模巨大，對存儲的低成本要求很高，另外時序數據的冷熱特征明顯。

豐富的生態協同 : 時序資料庫與數據可視化平臺、大數據處理、流式分析系統等對接，與周邊生態形成協同來創造業務價值。

在物聯網、工業互聯網等場景，時序數據通常有進一步做運營分析處理的需求，在很多情況下時序數據只是業務數據的一部分，需要與其他類型的數據組合來完成查詢分析。

智能電網數據模型

下麵我們具體看一下智能電網中的數據模型，從而進一步體現為什麼時序資料庫是智能電網場景中數據處理的最佳選擇。

統一標準 SG-CIM

針對現在電力行業各企業業務數據模型多樣化，非統一，交互困難等問題，國家電網公司通過分析整合，提出了一個新型的企業公共數據模型（SG-CIM），形成了統一的信息視圖，實現多企業多業務應用系統間的數據交互共用。SG-CIM 和時序資料庫模型非常匹配。

在智能電網管理平臺中，SG-CIM數據模型中的每個葉子節點稱為測量對象，葉子節點標簽稱為測量屬性，它由一個或多個鍵值對組成，用於進一步刻畫補充測量對象的屬性信息，根至葉子節點的全路徑稱為用戶屬性，作為一個特殊屬性處理。

測量對象+時間戳+測量屬性+測量值的組合稱為一條時間序列數據記錄，也稱電力負荷數據測點。以某樓宇中某居民用戶安裝的智能電錶為例，描述 SG-CIM 數據模型在海量數據管理平臺中的應用，如下圖所示。

根據 SG-CIM 數據模型，一條時間序列數據記錄由如下幾部分組成 :

測量對象 (obj) : 一個被定量測量對象的名稱，比如電能量，吞吐量等。
時間戳 (timestamp) : 以 UNIX 時間表示（秒或毫秒），用於標識這條時間序列被記錄/存儲的時間。
測量屬性 (tag) : 鍵值對，用於區分或組組織測量對象相同，但來自不同源或相關實體的相似數據點，增加靈活性。
測量值 (value) : 該測量對象在當前時刻的實際測量值，整型或浮點型。

測量對象 (obj) 以 SG-CIM 數據模型中的每個葉子節點來刻畫，例如正向有功尖能量(fd.shark.electricity)。

測量屬性 (tag) 以 SG-CIM 數據模型中葉子節點的屬性：用戶 (user) 和設備類型 (dtype) 等屬性來描述，例如 user= lvsejiayuan.A.unit2.603，dtype=ammeter，user 是一個特殊的屬性，用根至葉子節點的全路徑刻畫。

根據 SG-CIM 模型進行時序數據模型設計 - 多值模型和單值模型

單值模型 : 即對測點建模，以單個測點對測點定義時序採樣。

按設備將每個設備的測量值屬性分別定義到時序資料庫中。
這種存儲方式數據定義、變化值提交和歷史值查詢都相對簡單。
缺點同樣明顯，存儲在時序資料庫中數據沒有關聯性，如需同時查詢線路的有功和電流，則需要分兩次查詢，查詢性能較低，同時也不利於做關聯性分析。
OpenTSDB 和 Prometheus時序資料庫採用的是單值模型。

多值模型 : 即對設備/數據源進行建模，例如基於智能電網設備建模。

在時序資料庫中，將同一個設備採集的不同測點屬性存儲在一張表的不同域。這要只需要一次查詢，即可得到一個設備的所有量測，查詢效率和數據同步行都相對較高。
線路設別在時序資料庫中的記錄可定義為八元組：<oid,timestamp, i_value, i_status, p_value, p_status, q_value, q_status>。
GaussDB（for Influx） , InfluxDB，TimeScaleDB 等時序資料庫採用的是多值模型。

雲資料庫 GaussDB(for Influx)

如何支撐龐大的智能電網數據

雲原生分散式時序資料庫GaussDB（for Influx）採用存儲計算分離架構。

集群能力方面 : 具備非常平滑快速的彈性擴縮容能力。集群可以輕鬆擴展至每秒千萬點寫入吞吐量，PB界別的存儲支持。
服務和數據高可用方面 : 數據三副本存儲確保數據可用性；集群跨 AZ 可用區容災部署，集群最大支持N - 1 節點故障，同時數據自動負載均衡避免熱點。
時序數據存儲方面 : 深度優化存儲引擎，確保穩定的高吞吐量寫入；同時時序數據的自適應壓縮能力，讓時序數據壓縮比達到20 : 1；自動的數據冷熱分層存儲，進一步降低數據存儲成本。
時序數據計算方面 : 集成了豐富的數據聚合，降採樣，插值，預算，異常檢測等運算元。同時支持邊雲同步能力，實現數據邊雲一體化。
在生態和開源相容方面 : 支持多種開源時序資料庫協議，例如 Prometheus，Graphite 和 OpenTSDB，同時完全相容InfluxDB 生態。

基於 GaussDB（for Influx）的電網數據模型設計

GaussDB（for Influx）在生態和協議方面完美相容 InfluxDB。InfluxDB 靈活多變的 Schema-Free 行協議可以完美匹配 SG-CIM 模型。

數據寫入時候，不需要提前創建 Schema 定義，同時支持 Tags 和 Fields 欄位自由擴展，未來有需要新增維度的時候，可以動態進行增加。

可以參考下麵簡單的例子 :

我們以智能電網中線路設備數據為例子，根據行協議如何將 SG-CIM 模型轉化成 GaussDB（for Influx）數據模型 :

Measurement : stbl_line，相當於關係型資料庫中的表概念。
Fields : SG-CIM 模型中的多個測量對象 (Obj)，即線路設備採集和上報的指標項，後期可以動態擴展。

i_value, i_status : 電流相關指標 p_value, p_status : 電壓相關指標 q_value, q_status : 功率相關指標其中各個指標項採集的值是測量值 (value)

Tags : SG-CIM 模型中的測量屬性 (Tag)，表示線路設備靜態屬性標簽，可以根據系統需要自定義和擴展

deviceId : 設備標識 ID

deviceType : 設備類型標識

line : 線路標識 ID

Timestamp : SG-CIM 模型中時間戳項。

以上模型在資料庫中存儲格式如下：

stbl_line,line=XXX線路,deviceType=XXX,deviceId=E08995 i_value=X,i_status=X,p_value=X,p_status=X,q_value=X,q_status=X 1663121437010000000

總結

GaussDB（for Influx）是一款基於計算存儲分離架構，完全相容 InfluxDB 生態的雲原生時序資料庫。依托於華為雲計算平臺高性能，高可靠，高安全，可彈性伸縮的基礎上，GaussDB（for Influx）提供時序數據高效存儲、分析、展示功能，同時具有高寫入性能、靈活擴容、高壓縮率和高查詢性能等特點。GaussDB（for Influx）可以廣泛應用於各種時序數據處理場景，例如工業物聯網，車聯網，物聯網，運維監控，銀行金融等。