小T導讀：在內蒙古某新能源集控項目中(zhong)，三區需接入(ru)并(bing)分(fen)析大量風電、光伏逆變器及儲能設(she)備的監測(ce)數據。隨著數據規模不斷擴大，原有(you)的 Hadoop 系統逐漸難以(yi)支撐，查詢緩(huan)慢、存儲低(di)效、數據丟失等(deng)問題頻頻出現。
為突破(po)瓶頸，積成電子果斷引(yin)入TDengine。經過一年多的驗證和實際運行，TDengine 展現出顯(xian)著(zhu)優勢：查詢效(xiao)率大(da)幅提升，存儲空間(jian)顯(xian)著(zhu)壓縮，徹(che)底解(jie)決了(le) Hadoop 的數據(ju)丟失難題(ti)。目前，TDengine 已全面(mian)替代 Hadoop，成為積成電子的核心數據(ju)支撐平(ping)臺。在良好合作基礎上，未來(lai)將共(gong)同為電力行業客戶提供更高(gao)效(xiao)、更可靠的數據(ju)服務。
項目背景
電力系統分區簡介
電(dian)力系統根據功能和(he)安全等級劃分為一(yi)區、二區、三區，主(zhu)要(yao)用(yong)于電(dian)力監(jian)控和(he)數據管理。其中
- 一區：直接控制電力生產設備，如發電機組、變電站等，負責實時監控和控制，確保系統安全運行。
- 二區：位于一區和三區之間，負責數據采集和預處理，但不直接控制設備，主要進行數據分析和監控。
- 三區：用于高級數據分析和決策支持，如負荷預測、故障分析等，不直接參與實時控制，數據經過嚴格隔離以確保安全。
簡(jian)單來說，一(yi)區(qu)直接控(kong)制設備，二區(qu)處(chu)理數據，三(san)區(qu)進行高(gao)級分析和決策。
設備數量
在(zai)內蒙某新(xin)能源集控項(xiang)目中，三區需要接入(ru)大量風機、光伏逆變器(qi)、儲能設(she)備以及(ji)其他系(xi)統(tong)設(she)備的(de)監測數據(ju)，并對(dui)這些(xie)數據(ju)進行應用分析(xi)。
設備主要包括：
- 風力發電機約 5000 臺
- 光伏逆變器約 2000 臺
- 各類儲能設備，共計超過 100 萬臺
- 少量水電、火電系統的監測數據
業務支撐能力要求
由于每臺設備(bei)都有幾個(ge)到(dao)幾百(bai)個(ge)測點(dian)不等，所有設備(bei)共計約近 700 萬測點(dian)，數(shu)(shu)據采集頻率涵(han)蓋秒級、分鐘級、小(xiao)時級。這就要(yao)求三區的數(shu)(shu)據平臺能夠承擔巨大的數(shu)(shu)據寫入(ru)壓力(li)，并且存儲(chu)眾(zhong)多設備(bei)產生(sheng)的海量歷史(shi)數(shu)(shu)據。
對數(shu)據的(de)查(cha)詢(xun)應(ying)用主要有：
- 定時統計服務，每個小時統計一次，并將指標上報
- 設備數據每日統計，每個設備每天（ 24 小時）都要進行一次統計
- 用戶隨機查詢，根據業務需要，用戶對設備實時或歷史數據進行不定期的查詢應用
由于設備(bei)數量超過百萬，且定時(shi)統計需(xu)覆蓋全部(bu)設備(bei)，這(zhe)就要求三(san)區數據平臺必須具備(bei)強大的并發查(cha)詢能力，同(tong)時(shi)確(que)保查(cha)詢時(shi)效(xiao)性(xing)滿足(zu)業務需(xu)求。
技術痛點
我們(men)最(zui)初采(cai)用 CDH （ Cloudera Distribution including Hadoop）搭建底(di)層(ceng)數(shu)據(ju)平臺(tai)對(dui)海量(liang)時(shi)(shi)序數(shu)據(ju)進行管理，這是一個基于 Hadoop 的(de)集成式(shi)大(da)(da)數(shu)據(ju)平臺(tai)。隨著(zhu)使用時(shi)(shi)間越來越長，接入的(de)設備與數(shu)據(ju)越來越多，它的(de)寫入效率遇到瓶頸，出現丟(diu)數(shu)現象(xiang)，穩定(ding)性也難以保(bao)障，而且(qie)每次掉線后(hou)恢復速(su)度很(hen)慢，導致我們(men)的(de)運維難度非常大(da)(da)。
當時我們迫切地需要(yao)(yao)一個(ge)新的大數據平臺，它不(bu)僅要(yao)(yao)替(ti)代 Hadoop，還要(yao)(yao)能(neng)突破(po)性能(neng)瓶頸，保障整個(ge)系(xi)統的穩定(ding)運行。
在(zai)了解(jie)到 TDengine 后，我們主動邀請其(qi)技術(shu)專(zhuan)(zhuan)家(jia)來訪(fang)交流(liu)。令人欣喜的是(shi)，雙(shuang)方(fang)迅速達成共識(shi)——TDengine 是(shi)一款專(zhuan)(zhuan)為(wei)物(wu)聯網、工業互(hu)聯網等場(chang)景設(she)計與優化的大數據平臺，正好契(qi)合我們在(zai)海量設(she)備(bei)監(jian)測數據存儲、管理與應用方(fang)面的核心需(xu)求。基于(yu)此，我們決定在(zai)三區率先部署 TDengine 集群，探索新技術(shu)的落地實踐。
初期(qi)，我們采(cai)取雙系(xi)統并行(xing)方案，數據(ju)同(tong)步寫入 Hadoop 和(he) TDengine，以確(que)保系(xi)統平穩過(guo)渡。經過(guo)約半(ban)年的(de)測試運行(xing)，TDengine 在業務正確(que)性(xing)、系(xi)統穩定性(xing)方面表現出色(se)，不僅徹底解(jie)決了(le)長期(qi)困擾的(de)丟數問(wen)題，在查詢性(xing)能和(he)存儲(chu)效率(lv)上更是(shi)帶來了(le)令(ling)人驚艷的(de)優化效果。
自 2024 年 10 月起，我們已將全(quan)部業(ye)務切換(huan)至 TDengine 集群，并持續穩定(ding)運行(xing)至今。
TDengine 建模方案
建表方案
TDengine 的基(ji)本數(shu)據結構(gou)是(shi) “一個采(cai)集(ji)點(dian)一張表(biao)(biao)(biao)”，并采(cai)用 “超(chao)級(ji)表(biao)(biao)(biao)” 來(lai)管理相同類(lei)型(xing)設(she)(she)備(bei)(bei)的所有(you)子表(biao)(biao)(biao)。最初我們計(ji)劃仿照官(guan)網文(wen)檔中智能電表(biao)(biao)(biao)的案例，為每(mei)類(lei)設(she)(she)備(bei)(bei)創建一個超(chao)級(ji)表(biao)(biao)(biao)，所有(you)該類(lei)設(she)(she)備(bei)(bei)的數(shu)據都由(you)這個超(chao)級(ji)表(biao)(biao)(biao)下的子表(biao)(biao)(biao)來(lai)管理，但是(shi) TDengine 技術專(zhuan)家在調(diao)研現場數(shu)據采(cai)集(ji)情(qing)況(kuang)后，給出了另一種(zhong)方案。
由于我們的設備采集(ji)頻率從(cong)秒級(ji)(ji)到(dao)分(fen)鐘級(ji)(ji)、小(xiao)時級(ji)(ji)不等，同一設備的不同測點之間(jian)差異明(ming)顯，無(wu)法適配統(tong)一的采樣周(zhou)期。如果將(jiang)這些(xie)測點強行(xing)(xing)放入同一張子表，不僅無(wu)法整(zheng)行(xing)(xing)寫(xie)入，必須逐列指定，影響寫(xie)入性能；還(huan)會(hui)因(yin)為大量空值（null）影響壓縮(suo)效率，造成存(cun)儲(chu)空間(jian)浪費，并(bing)需(xu)依(yi)賴后續的 compact 操作進行(xing)(xing)空間(jian)回(hui)收(shou)。
因此(ci)，TDengine 專(zhuan)家建(jian)議，采用(yong) “單列(lie)模型” 的設計，即為同一(yi)數(shu)據類型的測點(dian)(dian)（通(tong)道(dao)）創(chuang)建(jian)一(yi)張(zhang)(zhang)超級表，為每個測點(dian)(dian)（通(tong)道(dao)）創(chuang)建(jian)一(yi)張(zhang)(zhang)子(zi)表，每張(zhang)(zhang)子(zi)表只有一(yi)個數(shu)據列(lie)，依賴(lai)子(zi)表的 tag 列(lie)的信息(xi)來(lai)區分不(bu)同的測點(dian)(dian)（通(tong)道(dao)）。
下面是單列模型示意圖：
具(ju)體建(jian)表(biao)(biao)時，超級表(biao)(biao)命(ming)名規則為 “s+aaaa+bbbb”，s 意(yi)為超級表(biao)(biao)，“aaaa” 是設(she)備類(lei)型(xing)，例(li)如風機、逆變器等(deng)，“bbbb” 是參數類(lei)型(xing)，例(li)如有功功率等(deng)。
例(li)如(ru)，創建(jian)超(chao)級表 s001f002f ，設備類型為 001f ，參數類型為 002f，示(shi)例(li)如(ru)下：
CREATE STABLE s001f002f (ts TIMESTAMP ENCODE 'delta-i' COMPRESS 'lz4' LEVEL 'medium', data DOUBLE ENCODE 'delta-d' COMPRESS 'lz4' LEVEL 'medium', quality BIGINT UNSIGNED ENCODE 'simple8b' COMPRESS 'lz4' LEVEL 'medium') TAGS (tab_desc VARCHAR(64), changzhanid INT, dianyadengjiid INT) 建庫方案
根據 TDengine 的最佳實踐，建議將更新頻率相近的子表歸入同一個 database。這樣可以確保子表在落盤時生成的數據塊大小相近，便于合理配置如 STT_TRIGGER、MINROWS 等落盤相關參數，使更多數據(ju)聚(ju)合寫入同一 data 文件(jian)，減少文件(jian)碎片，提高(gao)查詢響應效(xiao)率(lv)。
在 TDengine 專家的指導下，我們最終按數據更新頻率劃分，創建了四個業務數據庫：secondiesdb_official、minuteiesdb_official、houriesdb_official 和 dayiesdb_official，分(fen)(fen)別對應秒級、分(fen)(fen)鐘(zhong)級、小時級和日級采(cai)集數據，有效支撐了(le)上層業務的多頻率分(fen)(fen)析需(xu)求。
主要建庫(ku)參數(shu)和(he)超級表、子表數(shu)統計(ji)如(ru)下：
以(yi)上四個業務 database ，共計創建了 6983262 張子表，管理三區所有接入設備的時序數據。
TDengine 應用效果
數據一致性測試
我們對(dui)(dui)存(cun)儲在 HBase（構(gou)建在 Hadoop 之上(shang)的(de)分布式 NoSQL 數據庫）和(he)(he) TDengine 中相同(tong)時間段的(de)數據進(jin)(jin)行(xing)了查(cha)詢(xun)(xun)，并(bing)對(dui)(dui)查(cha)詢(xun)(xun)結果進(jin)(jin)行(xing)了一(yi)致性(xing)比對(dui)(dui)。結果顯示(shi)，兩者(zhe)在各(ge)項指標上(shang)的(de)查(cha)詢(xun)(xun)結果保持一(yi)致，驗證了 TDengine 在數據存(cun)儲過程(cheng)中的(de)正確性(xing)和(he)(he)準確性(xing)。如下(xia)圖所示(shi)：
查詢效率提升
在對 TDengine 與原有 Hadoop 系統的查詢性能進行對比后發現，TDengine 在查詢效率上有顯著提升。例如，在對單個設備進行定時統計時，查詢耗時由原來的數秒縮短至百毫秒級，整體速度提升約 10 倍，極大(da)提高(gao)了系統的響應(ying)能(neng)力(li)和使用體驗(yan)。
存儲空間減少
TDengine 通過(guo)支持二(er)級壓(ya)縮(suo)、每個子表的數據(ju)按(an)塊(kuai)存(cun)儲(chu)、數據(ju)塊(kuai)內按(an)列存(cun)儲(chu)等機(ji)制，對(dui)不同(tong)類型的數據(ju)列采用(yong)差(cha)異化壓(ya)縮(suo)算法，極大提升(sheng)了存(cun)儲(chu)效(xiao)率。實際(ji)對(dui)比結果顯示(shi)，使用(yong) TDengine 后，磁盤空間(jian)占用(yong)僅為原(yuan)來的約十(shi)分之一，大大超(chao)出了我們的預期。
掉點（寫入數據缺失）問題解決
在(zai)采(cai)用(yong) TDengine 之前，受限于(yu) HBase 的(de)寫(xie)(xie)入性能(neng)以(yi)及多列模(mo)型的(de)結構設計，我們在(zai)高并發寫(xie)(xie)入場景中長期面臨(lin)數(shu)據掉(diao)點（寫(xie)(xie)入缺失(shi)）的(de)問題，始終難以(yi)徹(che)底解決。TDengine 憑借(jie)其高并發寫(xie)(xie)入能(neng)力，有效承載了大規模(mo)數(shu)據同(tong)(tong)時寫(xie)(xie)入的(de)壓力，徹(che)底消除(chu)了這一問題。從下圖對比(bi)可以(yi)明(ming)顯看出，在(zai)相(xiang)同(tong)(tong)時間段內，HBase 的(de)數(shu)據曲(qu)線存(cun)在(zai)缺口，而 TDengine 的(de)數(shu)據曲(qu)線則連續完整，驗證了其穩定可靠的(de)寫(xie)(xie)入能(neng)力。
曲線和圖表支持
在歷史數據(ju)(ju)查(cha)詢業務中，我們主(zhu)要通過 TDengine 獲取(qu)所需數據(ju)(ju)，并以圖(tu)表形式(shi)進行可視化(hua)展(zhan)示，便于(yu)用戶(hu)直(zhi)觀理解設備運行狀態與趨(qu)勢。如(ru)下圖(tu)所示：
其它使用問題
時間窗口前開后閉問題
TDengine 提供了時間窗口功能，用戶可以通過 interval 子(zi)句輕松劃(hua)分(fen)指定時間長度的(de)窗口，并(bing)在(zai)每個窗口內執行聚(ju)合(he)操作。
但在使用過程中我們發現，系統默認的窗口區間為前閉后開，即 interval 按時間段取值為 [0,10)、[10,20)、[20,30)。但在我們的業務場景中，更希望將時間窗口設為前開后閉，即 (0,10]、(10,20]、(20,30]。
起初我們認為這需要增加額外的配置參數才能實現，后來發現 interval 子句實際上支持窗口偏移設置。通過 offset 參數，我們可以靈活地調整時間窗口的位置。只需配置一個合適的偏移值，就能實現前開后閉的效果。 例如，下面的 SQL 語句通過 offset 1a（表示偏移 1 毫秒），即(ji)實現了(le)我們期望的(de)窗口劃(hua)分方式：
select _wstart-1a, _wend-1a, count(*) from ftb interval(10s, 1a);新增節點與 vnode 遷移
由于設備(bei)規劃(hua)調整，原有(you)的 5 節點(dian) TDengine 集群擴容為 6 節點(dian)。然而，TDengine 在(zai)新增節點(dian)后，歷史數據并不會自動遷移，新寫(xie)入(ru)的數據也(ye)仍然分布(bu)在(zai)原有(you)的 5 個節點(dian)上。這是因為數據庫和數據表已提前創建完畢，所有(you) vnode 的分配仍集中在(zai)原集群中，新增節點(dian)無法自動分擔讀寫(xie)和存(cun)儲(chu)壓力。
為充分利用新加入的 dnode 節點，需手動執行 vnode 的遷移操作。TDengine 提供了 vnode redistribute 功能(neng)，用于(yu)(yu)靈活調整 vnode 的(de)分布。例(li)如，編號(hao)為(wei) 679 的(de) vgroup，其所在數據庫設置了副本數為(wei) 3，對應的(de) 3 個 vnode 分別位于(yu)(yu) 1、4、6 號(hao) dnode 上(shang)。若希望(wang)將其中 1 號(hao)節點上(shang)的(de) vnode 遷(qian)移至 7 號(hao)節點，只需執(zhi)行以下命令：
redistribute vgroup 679 dnode 4 dnode 6 dnode 7;實際(ji)上(shang)就(jiu)是將原來的 [1 ，4， 6 ] 分布(bu)修改為 [4，6，7] 。
從 ID 為 1 的 dnode 上遷移了 5 個 vnode 到 ID 為 7 的新節點上，語句如(ru)下：
redistribute vgroup 679 dnode 4 dnode 6 dnode 7;
redistribute vgroup 684 dnode 4 dnode 6 dnode 7;
redistribute vgroup 686 dnode 4 dnode 6 dnode 7;
redistribute vgroup 689 dnode 4 dnode 6 dnode 7;
redistribute vgroup 690 dnode 2 dnode 3 dnode 7;整(zheng)個集群共包含 392 個 vnode。我們在遷(qian)(qian)移過程中(zhong)制定了(le)周密的(de)(de)規劃(hua)方案，并盡(jin)量避免遷(qian)(qian)移 vgroup leader 所在的(de)(de) vnode（leader 節點負(fu)責處(chu)理(li)讀(du)寫(xie)請(qing)求(qiu)，遷(qian)(qian)移會(hui)影響性能）。最終從原有的(de)(de)前(qian)五個 dnode 中(zhong)各遷(qian)(qian)移了(le) 5 至 7 個 vnode，總計(ji) 62 個 vnode 被平(ping)滑遷(qian)(qian)移至新加入的(de)(de)節點（dnode ID 為 7），如下圖所示：
如此(ci)一(yi)來不僅充分利用了集群中所有節點(dian)(dian)的資源，同時也(ye)達到了我(wo)們(men)增加節點(dian)(dian)的目的。
leader 再平衡
新增(zeng)節點后，由于多數遷(qian)移過來的 vnode 并非 Leader，導(dao)致新節點上(shang)的 vnode 多為 Follower，無法直接處理讀寫請求，資源(yuan)利(li)用(yong)率偏低。為了實現(xian)各(ge)個 dnode 之間的負載(zai)均衡(heng)，有必要進行(xing) Leader 再平衡(heng)操作。
說明(ming)：TDengine 通過多副(fu)本(ben)(ben)(ben)機制實現高可(ke)用，即每(mei)個(ge)(ge) vnode 有(you)若干(gan)個(ge)(ge)副(fu)本(ben)(ben)(ben)，vnode 的(de)全部(bu)副(fu)本(ben)(ben)(ben)共同(tong)構成了(le)一個(ge)(ge)虛擬(ni)節(jie)點組(vgroup)，vgroup 里 vnode 個(ge)(ge)數就是(shi)數據的(de)副(fu)本(ben)(ben)(ben)數。vgroup 采用 RAFT 一致性(xing)協議，保證系統的(de)高可(ke)用與(yu)高可(ke)靠(kao)，vnode 可(ke)以是(shi) Leader、Follower、Candidate 或 Offline 狀態。寫操作只能(neng)在 Leader 上(shang)(shang)進行，系統采用異步(bu)復制的(de)方式(shi)將數據同(tong)步(bu)到 Follower 上(shang)(shang)，這樣確保了(le)一份數據在多個(ge)(ge)物(wu)理節(jie)點上(shang)(shang)有(you)拷貝。
leader 再平衡(heng)命令如(ru)下：
BALANCE VGROUP LEADER;由(you)于(yu) RAFT 一致性協議(yi)選主過(guo)程(cheng)是隨機的，因此有時需要(yao)單獨對一個 database 或(huo) 一個 vgroup 進行專門 balance。
balance vgroup leader; # 再平衡所有 vgroup 的 leader
balance vgroup leader on <vgroup_id>; # 再平衡一個 vgroup 的 leader
balance vgroup leader database <database_name>; # 再平衡一個 database 內所有 vgroup 的 leader平衡后使用如(ru)下語(yu)句(ju)查看 leader 分布情況：
select dnode_id,count(*) as leader_num from information_schema.ins_vnodes where status = 'leader' and db_name = 'test' group by dnode_id;leader 分布情況如(ru)下：
經(jing)過以上操(cao)作，可以看到 6 個節點的 leader 個數(shu)大致平衡。
結語
近年來，隨著(zhu)新能(neng)源項目的規模化(hua)推進和(he)電(dian)網智能(neng)化(hua)進程加快，底層數(shu)據處理能(neng)力(li)的重要(yao)性日益突出(chu)。特別是(shi)在新能(neng)源發電(dian)集控平(ping)臺(tai)建(jian)設及(ji)南方電(dian)網邊緣(yuan)集群等場(chang)景中，對高(gao)效、穩定的時序(xu)數(shu)據庫產(chan)品(pin)提出(chu)了(le)更高(gao)要(yao)求。
在(zai)大(da)唐(tang)蒙(meng)西新(xin)能源集控項(xiang)目中，TDengine 展(zhan)(zhan)現(xian)出的(de)卓越產品力給(gei)我(wo)們留下了深(shen)刻印(yin)象。基于良(liang)好的(de)合作基礎，以及對(dui)行業趨勢和自身發展(zhan)(zhan)規劃的(de)深(shen)入判斷，未(wei)來，雙方(fang)將(jiang)攜(xie)手深(shen)化合作，共同為電力行業客戶提(ti)供(gong)更高效(xiao)、更優(you)質的(de)服務(wu)。
本(ben)文作者(zhe)：積成電(dian)子(zi)，張(zhang)濤
關于積成電子：
積成電(dian)(dian)(dian)(dian)子(zi)股份有(you)(you)限公司(si)是國內領(ling)先的智能(neng)電(dian)(dian)(dian)(dian)網與(yu)公用(yong)事(shi)業(ye)(ye)自(zi)動(dong)化(hua)(hua)(hua)整體解決方案供應商，核心(xin)業(ye)(ye)務(wu)(wu)涵蓋電(dian)(dian)(dian)(dian)力(li)系統(tong)(tong)全鏈條(tiao)的自(zi)動(dong)化(hua)(hua)(hua)與(yu)信息化(hua)(hua)(hua)，產品覆蓋電(dian)(dian)(dian)(dian)力(li)系統(tong)(tong)“發、輸、變、配、用(yong)、調(diao)(diao)度”各環(huan)節，此外，公司(si)在新(xin)能(neng)源領(ling)域為風電(dian)(dian)(dian)(dian)場(chang)和光伏電(dian)(dian)(dian)(dian)站提供自(zi)動(dong)化(hua)(hua)(hua)控制(zhi)方案，并布局智慧(hui)水(shui)務(wu)(wu)、智慧(hui)燃氣等公用(yong)事(shi)業(ye)(ye)自(zi)動(dong)化(hua)(hua)(hua)業(ye)(ye)務(wu)(wu)，形(xing)成了(le)“電(dian)(dian)(dian)(dian)、水(shui)、氣、熱”多(duo)領(ling)域協同發展(zhan)的格局。作為國家高(gao)新(xin)技術企業(ye)(ye)和行(xing)業(ye)(ye)標(biao)(biao)準(zhun)制(zhi)定者，積成電(dian)(dian)(dian)(dian)子(zi)主(zhu)持或(huo)參與(yu)了(le) 50 余(yu)(yu)項(xiang)國家標(biao)(biao)準(zhun)及行(xing)業(ye)(ye)標(biao)(biao)準(zhun)，擁有(you)(you)千余(yu)(yu)項(xiang)技術專利(li)與(yu)軟件著作權，電(dian)(dian)(dian)(dian)網調(diao)(diao)度自(zi)動(dong)化(hua)(hua)(hua)系統(tong)(tong)在國內地(di)調(diao)(diao)市場(chang)占(zhan)有(you)(you)率高(gao)達(da) 30%，技術實力(li)位(wei)居行(xing)業(ye)(ye)前列。
