光伏儲能資料難題很棘手?架構升級很迷茫?來看三大真實案例
近年來,隨著光伏儲能裝置的增加,裝置數量和測點數量也在相應增加,資料採集頻率也在不斷提高,由此產生的時序資料量越來越龐大,對資料處理和實時分析的要求也越來越高。同時光伏儲能系統需要長期儲存大量的歷史資料,以便進行回溯分析和趨勢預測,海量歷史資料的儲存和管理也成為一個挑戰,亟需高效的儲存解決方案。在此背景下,為了更精準地監測和控制光伏儲能系統,光伏儲能領域的部分企業開始嘗試採用更先進的資料管理和分析技術,進行資料架構的全面升級。
在本篇文章中,我們彙總了一批較為典型的光伏儲能專案的資料架構改造真實案例,給到大家參考。
國軒高科海外儲能專案:資料壓縮率輕鬆達到 10% 以內
“對我們這個體量相對較小的場景來說,TDengine Cloud 按量計費加全託管的企業級服務讓我們用非常小的成本便運轉了這個專案,並且極大地增加了產品的效率並保留了隨時擴張的靈活性。此外,資料分享、流式計算這些有趣的特性也等待我們進行更深一步地挖掘。”
改造方案
國軒高科在“海外某儲能專案”中,需要實時監測電池安全,採集記錄每次使用的充放電過程、電流/電壓等值,而此類資料都帶有時間戳,是典型的時序資料。為了應對未來海量的使用者使用資料,其決定選擇一款專業的時序資料庫(Time Series Database,TSDB),並於去年在海外本地化成功部署了時序資料庫 TDengine 2.x 版本。為了更便捷地進行該資料庫的應用,國軒高科在今年選擇將業務部署在物聯網、工業大資料雲服務平臺 TDengine Cloud 上,其帶來的最直觀幫助就是全託管。
據瞭解,由於 TDengine Cloud 附帶和 TDengine Enterprise(企業版)同級別的服務,因此國軒高科不再需要擔心部署、最佳化、擴容、備份、異地容災等事務,減少了開發人員的負擔,可全心關注核心業務。在雲服務版本選擇上,由於該專案裝置量暫時不多,根據官方現有的定價規則,基礎版本便可滿足。在經過計費方案估算器計算後,最終國軒高科選擇了 1200 元/月的基礎版規格。
改造效果
該專案的資料處理流程如下圖所示,某類儲能裝置產生的時序資料會以 MQTT 方式上傳,其中業務資料轉發給 PostgreSQL,裝置產生的時序資料以及裝置執行日誌、裝置狀態資料轉給 TDengine。中臺各系統則會統一規劃使用這些資料庫中的資料,來用於分析計算,也可以直接控制裝置下發指令。最終,藉助 PC Web、APP 以及其他管理平臺等軟體方式在前端體現。
在測試階段,TDengine 的資料壓縮率可以輕鬆達到 10% 以內,每秒可以寫入數百萬行資料,在具體實踐中也很好地達到了這一壓縮及寫入效果;在查詢方面,完美地支援了該專案中的各類查詢,比如監測用電產品的健康狀態、分析裝置用電量趨勢、使用壽命等等。值得一提的是,該應用與 TDengine Cloud 所屬同一個 AWS region,因此透過使用 Private Link 功能,其應用網路就能夠與雲服務進行私密通訊,而無需將資料透過公網傳輸,大大降低了寫入方面的延遲,同時也進一步節約了由網路流量產生的費用。
日增 40 億條資料的光伏日電系統:讀寫效能提升 10 倍
“目前我們根據不同的測點型別建立了不同的超級表,按照不同的測點 ID 以及測點號作為 tag 建立了不同的子表。這樣我們針對於測點可以直接進行單表分析,處理效能高、速度快;也可以針對多測點進行分析,直接操作超級表,業務實現簡單,同時兼顧了查詢效能。”
改造方案
八五資訊在新能源電力物聯網平臺上,需要對物聯網裝置的實時資料以及光伏裝置感測器的遙測資料進行儲存和查詢分析,規劃設計資料儲存規模大概在 16TB 左右,目前資料日增量為 1 億多條,全部測點接入後預計日增量為 40 多億條左右;系統需支撐至少 50000 臺裝置總計 400 萬測點(訊號量和模擬量)的實時資料接入、處理及儲存。在查詢上,應用系統的常規查詢在 50QPS 左右,高併發在 100QPS 左右。一次歷史資料查詢分析最大跨度為一年且支撐多測點多模式分析方式。
此前該平臺使用 TimescaleDB 進行這些資料的處理,無論在讀寫效能,還是硬體資源上,都遇到了瓶頸,且沒有叢集功能。為了破解這一困境,八五資訊選擇接入 TDengine,主要用於光伏裝置遙測實時資料的儲存、查詢和分析。
改造效果
改造完成後,讀寫效能較原 TimescaleDB 資料庫提高 10 倍左右,在資料接入層不用再擔心資料庫的寫入效能瓶頸;資料分析查詢應用層也較原系統有較大提升,尤其是在面對時間跨度大的聚合類分析時幾乎瞬間響應;在叢集功能方面,TimescaleDB 雖支援流複製方式的主備庫但沒有叢集功能,TDengine 在這點上更有優勢,其叢集容易搭建且無主從節點區分,對應用改造和支撐較友好,叢集版讀寫效能提升較大。
在計算及儲存資源上,應用 TDengine 後,降低了大約 4 倍左右的儲存成本。在未使用 TDengine 之前,TimescaleDB 開啟壓縮後對 70 億資料量佔用磁碟為 165GB,且一分鐘內無法查詢出一個月的歷史資料;而在使用 TDengine 之後磁碟佔用空間為 40GB 左右,且能夠毫秒級返回針對一個月的歷史資料的聚合查詢。此外,透過亂序插入功能,TDengine 還解決了邊緣側由於網路問題導致的資料傳輸不及時造成的亂序寫入問題,保證了資料的完整性。
上海電氣儲能系統:毫秒級響應電站執行資訊監視
“此次方案改造非常成功,我們還將在後續專案中,繼續擴充其分散式叢集應用,構建儲能電站執行情況的數字化檔案,結合開發的分析演算法、預測演算法、資料探勘技術,實現電站穩定性分析、效率和損耗分析、故障預測、壽命預測、效能短板定位以及熱管理分析等高/級分析和診斷功能。”
改造方案
為幫助客戶實現儲能裝置的最優配置和高效利用,上海電氣打造“SmartOPS 儲能智慧運維繫統”,支援雲端部署和本地部署兩種方式,其中,本地部署需要重點考慮本地硬體資源的限制,如站端系統的記憶體、CPU 以及讀寫效能等,為此上海電氣開始進行技術選型,以挑選適合在站端系統中部署的時序資料庫。
待選資料庫方案包括 OpenTSDB、InfluxDB、Apache IoTDB、TDengine、ClickHouse。基於站端本地化部署需要輕量級資源佔用出發,上海電氣首先排除 OpenTSDB、Apache IoTDB 以及 ClickHouse,OpenTSDB 是由於其基於 HBase 進行設計,架構比較重,而 Apache IoTDB 在資源佔用方面對邊緣輕量級裝置也不算友好;ClickHouse 的優勢是單錶快,但其他方面偏弱,包括 join、管理運維都比較複雜。研發團隊最終圈定在 InfluxDB 和 TDengine 中進行測試選擇。在經過一系列測試對比後,TDengine 成功勝出。
改造效果
目前該專案技術團隊已採用 TDengine 作為 SCU(Station Control Unit) 架構的核心時序資料庫,實現儲能系統綜合資訊感知、就地執行控制與協調保護功能;同時支援儲能電站及裝置的遠端運維,實現高/級資料分析與執行最佳化,全方面守護儲能電站的安全。
TDengine 高效能的寫入和聚合查詢功能,能夠毫秒級響應電站執行資訊監視。在壓縮方面,對比此前使用 InfluxDB 時 1 天 200 多 MB 的資料儲存,在採集點數量相同的情況下,使用 TDengine 後,1 天的資料儲存低於 70 MB,是 InfluxDB 的 1/3。在查詢上,對比使用 InfluxDB 一個月時間後執行查詢,記憶體使用率達到 80%,並且過了十分鐘也沒出來結果,在應用 TDengine 近1個月後,使用相同的 SQL 語句,查詢只需要 0.2 秒。
結語
術業有專攻,從上述實踐中我們也能看到,專業的資料庫做專業的事情,在面對光伏儲能裝置產生的海量時序資料的處理上,時序資料庫效果更為顯著。TDengine 具備 10 倍以上的效能提升、簡單易用的時序資料平臺、完全實時的資料共享能力以及頂/級的開源軟體四大核心競爭力,這也讓 TDengine 成為國內外數十萬使用者的選擇,成為光儲使用者的不二之選。如果你也面臨著資料難題,可以新增 小T vx:tdengine,與 TDengine 專業的解決方案架構師直接溝通,尋找架構改造最優解。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70014783/viewspace-2999786/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- eMarketer:收穫大資料的果實很難大資料
- 蘋果MacBook Pro 配置升級 這項很實用?蘋果Mac
- 領導希望由測試組來澄清需求,很迷茫
- 資料分析很難學?60天就夠了!
- Web前端很難學?html、css t、JavaScrip知識架構圖分享Web前端HTMLCSSJava架構
- python很難嗎Python
- 四個典型的車聯網案例,給你資料架構升級思路架構
- 超級高鐵Hyperloop暫不在美國建設 技術很難實現OOP
- “機器學習還是很難用!機器學習
- 面試真的很難嗎?面試
- DC/OS很難理解嗎?
- 學習java很難嗎?Java
- 工作容易,賺錢很難
- 學習3D建模很難嗎,是不是很辛苦?3D
- 為什麼對gRPC做負載均衡會很棘手?RPC負載
- android資料庫如何進行版本升級?架構之資料庫框架升級Android資料庫架構框架
- 為什麼學習效率如此低,我很迷茫?
- JS中的類很難嗎?JS
- 傳統應用系統架構向微服務應用架構升級的實戰案例微服務應用架構
- 笑話3篇:一個程式設計師對自己的未來很迷茫程式設計師
- MySQL 如何儲存長度很長的資料欄位MySql
- 建立微服務很容易,但是有幾點很難 - James Hickey微服務
- 最佳實踐:騰訊HTAP資料庫TBase助力某省核心IT架構升級資料庫架構
- 嵌入式方向的畢業生,找工作很迷茫
- 智慧手錶的應用機會:現實很骨感 未來很豐滿
- 大資料很難?職場老鳥告訴你,會用EXCEL就行大資料Excel
- javaweb速查資料,很給力!JavaWeb
- 服務網格仍然很難 - cncf
- 都說很簡單的Hogan,還是得看案例才能懂啊HOG
- 三種很難學到的Java踩坑教訓 - MilošJava
- 不懂專案管理三角,你的專案很難成功專案管理
- 很全!淺談幾種常用負載均衡架構負載架構
- AMDZen架構雙路處理器曝光很強大架構
- XView 架構升級之路View架構
- 【雙層模型】分散式光伏儲能系統的最佳化配置方法模型分散式
- -----清高手指點。。 我已經迷茫很長時間了。。。。
- UML建模實踐——選“對”企業架構建模視角很關鍵架構
- 很抱歉,我回來了!