泛能網(wǎng)能碳產(chǎn)業(yè)智能平臺作為新奧數(shù)能科技有限公司打造的一體化智能平臺，服務(wù)于公建、工廠、園區(qū)等場景，旨在通過物聯(lián)網(wǎng)、大數(shù)據(jù)與人工智能技術(shù)，實現(xiàn)能源設(shè)備的實時監(jiān)控、運(yùn)營管理與能碳分析。隨著客戶規(guī)模擴(kuò)大與數(shù)據(jù)量激增，平臺面臨海量設(shè)備數(shù)據(jù)采集、高并發(fā)查詢、長期存儲及指標(biāo)計算準(zhǔn)確性等多重挑戰(zhàn)。平臺原先基于 OpenTSDB 的架構(gòu)已無法滿足業(yè)務(wù)發(fā)展需求，尤其在數(shù)據(jù)處理及時性、準(zhǔn)確性與資源成本方面存在明顯瓶頸。通過引入 TDengine 時序數(shù)據(jù)庫，平臺實現(xiàn)了從任務(wù)調(diào)度到流式計算的架構(gòu)升級，數(shù)據(jù)處理性能顯著提升，計算時效性最高提升 100 倍，計算時長縮短 2-8 倍，客戶投訴率幾乎降為零，同時服務(wù)器資源從原先的十多臺物理機(jī)大幅縮減，整體運(yùn)維成本顯著降低。

背景和痛點(diǎn)

泛能網(wǎng)平臺自 2018 年啟動建設(shè)以來，已服務(wù)超過 5000 家客戶，每客戶平均接入約 50 臺設(shè)備，每臺設(shè)備每分鐘采集 10-20 個數(shù)據(jù)點(diǎn)，系統(tǒng)每秒數(shù)據(jù)處理量（TPS）高達(dá) 9 萬。隨著業(yè)務(wù)擴(kuò)展，以 OpenTSDB 為基礎(chǔ)的架構(gòu)平臺在數(shù)據(jù)采集、存儲、查詢和計算方面面臨嚴(yán)峻挑戰(zhàn)：

• 海量數(shù)據(jù)采集與高并發(fā)寫入：設(shè)備數(shù)量龐大，采集頻率高，部分場景要求秒級甚至毫秒級上報，數(shù)據(jù)量呈指數(shù)級增長。
• 多維度實時查詢需求：客戶需按時間維度查詢最大值、最小值、平均值等統(tǒng)計指標(biāo)，并要求查詢響應(yīng)速度快。
• 長期數(shù)據(jù)存儲壓力：部分客戶要求保留 5-10 年歷史數(shù)據(jù)，對存儲空間和索引管理帶來極大壓力。
• 指標(biāo)計算不準(zhǔn)確與延遲：原有基于任務(wù)周期調(diào)度的計算方式導(dǎo)致日、月、年指標(biāo)計算結(jié)果不一致。同時，計算延遲嚴(yán)重，影響數(shù)據(jù)及時性。

架構(gòu)升級

基于上述痛點(diǎn)，平臺在數(shù)據(jù)庫選型中設(shè)定了明確目標(biāo)：支持高并發(fā)寫入與查詢、具備高效壓縮與長期存儲能力、支持流式計算與實時處理、具備良好的擴(kuò)展性與運(yùn)維便利性。在對比了多款時序數(shù)據(jù)庫（Timeseries Database）后，項目初期我們選擇使用了 TDengine TSDB 2.x 的社區(qū)版本，社區(qū)版本在集群高可用、性能方面可以很好支撐業(yè)務(wù)平穩(wěn)運(yùn)行。但我們在使用 2.x 社區(qū)版本中遇到幾個問題：

1. 2.x 社區(qū)版本不支持?jǐn)?shù)據(jù)刪除，但是新版本 3.x 里默認(rèn)支持；
2. 2.x 社區(qū)版本 UPDATE 參數(shù)無法動態(tài)修改，新版本 3.x 默認(rèn)開啟了更新數(shù)據(jù)的功能；
3. 2.x 版本已經(jīng)停止維護(hù)更新，且社區(qū)版沒有專有的售后運(yùn)維的支持；

基于以上幾點(diǎn)，為了保障未來業(yè)務(wù)穩(wěn)定運(yùn)行，我們決定升級到 TDengine TSDB 3.3.6.x 的企業(yè)版穩(wěn)定版本。

業(yè)務(wù)架構(gòu)

平臺采用“采算分離”架構(gòu)，物聯(lián)網(wǎng)平臺負(fù)責(zé)數(shù)據(jù)采集，TDengine 時序數(shù)據(jù)庫（Timeseries Database）作為核心存儲與計算引擎，配合流式計算模塊實現(xiàn)實時數(shù)據(jù)處理。

• 數(shù)據(jù)采集層：通過物聯(lián)網(wǎng)平臺接入設(shè)備數(shù)據(jù)。
• 流式計算層：替換原有任務(wù)調(diào)度，實現(xiàn)實時指標(biāo)計算。
• 存儲層：TDengine TSDB 集群負(fù)責(zé)測點(diǎn)數(shù)據(jù)與指標(biāo)結(jié)果的存儲與查詢。

數(shù)據(jù)模型

平臺基于 TDengine TSDB 的超級表與子表模型進(jìn)行建模：

• 測點(diǎn)超級表：按設(shè)備類型分類，如電能表、流量計等，每臺設(shè)備對應(yīng)一個子表。
• 指標(biāo)超級表：按時間維度（時、分、日、月、年）分類，每個子指標(biāo)對應(yīng)一個子表，記錄指標(biāo)值。

遷移經(jīng)驗

面對千億級歷史數(shù)據(jù)、新舊數(shù)據(jù)模型差異以及在線業(yè)務(wù)零中斷的核心要求，我們設(shè)計了一套灰度遷移與數(shù)據(jù)同步方案。整個遷移過程分為三個階段：新版本測試驗證、歷史數(shù)據(jù)遷移、灰度切換與流量遷移。全程采用漸進(jìn)式灰度策略，確保業(yè)務(wù)平穩(wěn)過渡。

第一階段：新版本測試驗證

我們在 TDengine TSDB 3.x 企業(yè)版集群中測試驗證業(yè)務(wù)應(yīng)用是否正常工作，需要升級 taosjdbc driver 版本至 TDengine TSDB 3.x。其他業(yè)務(wù) SQL 無需修改，與 TDengine TSDB 2.x 版本保持一致。

第二階段：歷史數(shù)據(jù)遷移

歷史數(shù)據(jù)規(guī)模龐大，且需保證遷移過程中不影響線上查詢性能。我們放棄了傳統(tǒng)的數(shù)據(jù)導(dǎo)出-導(dǎo)入方式，而是采用 TDengine TSDB企業(yè)版工具 taosX 進(jìn)行在線熱遷移。該工具支持從 TDengine TSDB 2.x 集群直接向 3.x 集群同步數(shù)據(jù)，具備斷點(diǎn)續(xù)傳、增量同步和一致性校驗?zāi)芰Α?/p>

具體步驟如下：

1. 全量數(shù)據(jù)同步：首先啟動全量遷移任務(wù)，將歷史數(shù)據(jù)按照時間范圍分片同步，避免單次任務(wù)負(fù)載過高。
2. 增量數(shù)據(jù)追趕：在全量遷移期間，系統(tǒng)持續(xù)產(chǎn)生新數(shù)據(jù)，我們通過 taosX 實時捕獲 TDengine TSDB 2.x 集群的增量寫入，并同步至 TDengine TSDB 3.x 集群，保持兩者數(shù)據(jù)差距在分鐘級別。
3. 數(shù)據(jù)一致性驗證：每日選取關(guān)鍵業(yè)務(wù)時段，對比兩個集群的統(tǒng)計指標(biāo)，確保數(shù)據(jù)完整無誤。

整個遷移過程在業(yè)務(wù)低峰期執(zhí)行，并通過監(jiān)控平臺實時觀測源集群與目標(biāo)集群的負(fù)載、延遲及錯誤率，確保系統(tǒng)穩(wěn)定。

第三階段：灰度切換與流量遷移

數(shù)據(jù)同步完成后，我們通過可配置的路由開關(guān)逐步將客戶請求導(dǎo)向新集群：

1. 讀灰度策略：先選取少數(shù)非核心客戶，將其查詢請求路由至 TDengine TSDB 3.x 集群，對比返回結(jié)果與原有集群是否一致，并監(jiān)控查詢延遲。
2. 雙寫并行期：在確認(rèn)查詢無誤后，開啟雙寫機(jī)制——物聯(lián)網(wǎng)平臺同時向兩個集群寫入數(shù)據(jù)，新集群作為主查詢源，舊集群作為備份和比對基準(zhǔn)。
3. 分批切換：按照客戶分組、地域、業(yè)務(wù)線等維度，分批次將全部查詢流量切換至新集群，每批切換后觀察業(yè)務(wù)指標(biāo)與系統(tǒng)性能，如有異常立即回退。
4. 最終切換與降級：當(dāng)全部流量穩(wěn)定運(yùn)行于 TDengine TSDB 3.x 集群一周后，停止向舊集群寫入數(shù)據(jù)，并逐步歸檔舊集群數(shù)據(jù)。舊集群仍保留一段時間作為應(yīng)急回退保障。

通過上述分階段、灰度化的遷移方案，我們實現(xiàn)了千萬級測點(diǎn)、千億條數(shù)據(jù)的平滑遷移，全程業(yè)務(wù)無感知，客戶查詢零中斷。遷移過程中積累的模型映射腳本、驗證工具和監(jiān)控方案，也為后續(xù)其他業(yè)務(wù)的數(shù)據(jù)遷移提供了重要模板。

收益總結(jié)

• 性能提升：通過這次平臺升級，指標(biāo)計算的及時性得到了大幅提升。對比以往，我們的計算時效性最少提高了 4 倍，最高的時候，例如從年指標(biāo)計算頻率兩天一次提高到每分鐘一次，時效性提高了 100 倍。計算時長方面，最少也縮短了兩倍，最高提升了 8 倍。

• 準(zhǔn)確性提升：通過流式處理和層級加工的方式，我們的指標(biāo)數(shù)據(jù)能夠前后一致地匹配，解決了無序數(shù)據(jù)帶來的準(zhǔn)確性問題，客戶投訴率接近零。同時，延遲數(shù)據(jù)的處理也更加智能化，可以自動計算延遲測點(diǎn)的數(shù)據(jù)，并遞歸修正受影響的所有指標(biāo)。對于日、月、年指標(biāo)計算頻率不一致的問題，我們也做了統(tǒng)一處理，現(xiàn)在所有計算頻率統(tǒng)一為 15 分鐘，并使用統(tǒng)一的時間窗口進(jìn)行計算，確保數(shù)據(jù)的準(zhǔn)確性。
• 成本降低：原有的 OpenTSDB 架構(gòu)使用十多臺物理服務(wù)器，每臺 60+ 核心，仍無法完全滿足需求。遷移至 TDengine TSDB 后，服務(wù)器數(shù)量大幅減少，資源利用率顯著提升，整體硬件與運(yùn)維成本降低約 60%。服務(wù)器資源減少，運(yùn)維復(fù)雜度下降。

過去與未來

從最初的選擇 OpenTSDB，到我們面臨種種挑戰(zhàn)，決定進(jìn)行新一輪的數(shù)據(jù)庫選型，這一路走來充滿了思考與抉擇。2018 年到 2022 年，OpenTSDB 在我們私有化場景中的表現(xiàn)曾一度支撐著我們的系統(tǒng)，但隨著業(yè)務(wù)的不斷擴(kuò)展，問題也接踵而至——高昂的部署成本、復(fù)雜的運(yùn)維難題，讓我們不得不尋求新的解決方案。

正是在這個關(guān)鍵時刻，TDengine 走入了我們的視野。初次接觸 TDengine 時，我們帶著試探的心態(tài)，先在私有化場景中做了嘗試。出乎意料的是，它不僅幫助我們降低了部署和運(yùn)維成本，還讓我們對未來充滿了信心。于是 2023 年 6 月，我們正式啟動了平臺的全面切換，將 TDengine 應(yīng)用到核心生產(chǎn)環(huán)境。

TDengine TSDB 在泛能網(wǎng)平臺中的成功應(yīng)用，為系統(tǒng)性能與運(yùn)維效率帶來顯著提升。未來，團(tuán)隊將持續(xù)關(guān)注 TDengine TSDB 新版本功能，進(jìn)一步探索其在邊緣計算、多級存儲、實時分析等場景中的深度應(yīng)用，推動平臺向更智能、更高效的方向演進(jìn)。

公司簡介

新奧數(shù)能科技有限公司成立于 2018 年，隸屬于新奧集團(tuán)，專注于能源行業(yè)智能化平臺研發(fā)與運(yùn)營，致力于通過物聯(lián)網(wǎng)、大數(shù)據(jù)與人工智能技術(shù)，為客戶提供一體化的能碳管理與運(yùn)維解決方案。泛能網(wǎng)依托新奧集團(tuán)深厚的產(chǎn)業(yè)實踐，以泛能理念為牽引，聚焦能源數(shù)智化，圍繞 3100 萬家庭用戶、27 萬工商業(yè)客戶、260 個城市燃?xì)忭椖糠e累了豐富的應(yīng)用場景。

作者

龔恒星

項目背景

在寧夏新能源集控項目中，華東院為電建新能源集團(tuán)打造的區(qū)域集控中心，圍繞集中監(jiān)控、場站協(xié)管、資源共享、維檢支持及電力交易等方面進(jìn)行建設(shè)。該中心依托集控平臺匯聚運(yùn)維資源，開展專業(yè)化能力建設(shè)，通過集約化、標(biāo)準(zhǔn)化、共享化與專業(yè)化的運(yùn)營模式，實現(xiàn)降本增效，助力下屬新能源場站安全生產(chǎn)與高效運(yùn)維。

目前，寧夏集控中心共接入 9 個新能源場站，涵蓋風(fēng)電、光伏、儲能等多種類型，總發(fā)電裝機(jī)達(dá) 1039.8MW，儲能總裝機(jī)達(dá) 100MW。數(shù)據(jù)測點(diǎn)經(jīng)場站側(cè)篩選與邊緣處理后，約有 80 萬測點(diǎn)進(jìn)入集控中心數(shù)據(jù)庫。

對集控中心數(shù)據(jù)庫而言，需要解決以下三大技術(shù)問題：

1. 持續(xù)寫入問題：當(dāng)前有 80 萬測點(diǎn)持續(xù)寫入，考慮后續(xù)擴(kuò)容需求，中心數(shù)據(jù)庫需要承接 ≥100萬點(diǎn)的持續(xù)寫入壓力；
2. 長期存儲問題：歷史數(shù)據(jù)存儲時間 ≥ 6 年；
3. 實時性問題：畫面數(shù)據(jù)實時刷新周期 1s～3s。

也就是說，我們面臨的并不是單一性能問題，而是持續(xù)寫入、長期存儲、實時應(yīng)用三者并存的綜合性挑戰(zhàn)，這對數(shù)據(jù)庫提出了很高的要求。

選型 TDengine 的原因

集控中心的數(shù)據(jù)庫需要滿足持續(xù)寫入、長期存儲和查詢實時性的技術(shù)要求，同時還要綜合考慮成本、國產(chǎn)化以及技術(shù)服務(wù)支持能力。我們調(diào)研了多家數(shù)據(jù)庫競品，經(jīng)過綜合對比后選擇了 TDengine TSDB。主要考慮因素有以下幾點(diǎn)：

1. TDengine TSDB 的讀寫性能十分優(yōu)異，能夠滿足集控中心對數(shù)據(jù)持續(xù)寫入以及實時、歷史數(shù)據(jù)快速查詢的業(yè)務(wù)需求；
2. TDengine TSDB 作為一款開源產(chǎn)品，能夠免費(fèi)下載和試用，選型初期我們在社區(qū)版上進(jìn)行了基礎(chǔ)功能和性能的測試驗證，為后續(xù)的溝通交流打下了良好基礎(chǔ)；
3. TDengine TSDB 作為一款開源產(chǎn)品，能夠免費(fèi)下載和試用，選型初期我們在社區(qū)版上進(jìn)行了基礎(chǔ)功能和性能的測試驗證，為后續(xù)的溝通交流打下了良好基礎(chǔ)；
4. TDengine TSDB 企業(yè)版帶有完善的售后服務(wù)支持，對于追求業(yè)務(wù)穩(wěn)定性的我們而言，能夠得到原廠快速、專業(yè)支持十分重要。

TDengine 實施策略

整體架構(gòu)

寧夏新能源集控中心需要接入 9 個新能源場站超過 80 萬測點(diǎn)的數(shù)據(jù)，數(shù)據(jù)寫入 TDengine TSDB 集群的壓力約為 20 萬條/秒。結(jié)合業(yè)務(wù)分區(qū)要求，我們將集控中心安全一區(qū)與三區(qū)的數(shù)據(jù)分別存儲，同時實現(xiàn)一區(qū)數(shù)據(jù)向三區(qū)的實時同步。其中，一區(qū)主要支撐遠(yuǎn)程控制系統(tǒng)，三區(qū)主要支撐集中監(jiān)視系統(tǒng)以及高階分析系統(tǒng)。

一三區(qū)整體架構(gòu)示意

數(shù)據(jù)建模

時序數(shù)據(jù)庫與傳統(tǒng)關(guān)系型數(shù)據(jù)庫的建模理念與方法完全不同，好的數(shù)據(jù)建模能夠使將來的業(yè)務(wù)應(yīng)用做到事半功倍。

建庫策略

我們考慮了多種數(shù)據(jù)組織方式，優(yōu)劣分析如下：

經(jīng)過與濤思數(shù)據(jù)專家討論，我們最終確定采用按場站組織數(shù)據(jù)存儲的方式，即 1 個場站對應(yīng) 1 個數(shù)據(jù)庫實例。每個數(shù)據(jù)庫默認(rèn)包含 104 和 modbus 兩類數(shù)據(jù)，其他數(shù)據(jù)后期按需增加。9 個站的數(shù)據(jù)庫名稱如下：

建表策略

我們的業(yè)務(wù)要求之一，是能夠根據(jù)通道 ID、公共地址（從機(jī)地址）和信息體地址快速定位到測點(diǎn)，或者能夠通過這些字段實現(xiàn)高效表過濾。

在 TDengine TSDB 的設(shè)念中，我們業(yè)務(wù)上所說的 “測點(diǎn)” ，實際上對應(yīng) TDengine TSDB 中的 “子表” 概念，TDengine TSDB 將數(shù)據(jù)字段分為數(shù)據(jù)列與標(biāo)簽列，并為標(biāo)簽列過濾進(jìn)行了特殊優(yōu)化，我們只需把上述篩選字段作為超級表的標(biāo)簽列，即可很方便地對測點(diǎn)進(jìn)行條件篩選。

例如對于 st_telemetry_short_float 超級表，將常用的測點(diǎn)（子表）篩選條件 channel_id、 common_address、 object_address 作為 tag（標(biāo)簽） 列，就能通過超級表快速篩選涉及的一張或一批子表，并執(zhí)行數(shù)據(jù)查詢。

TDengine TSDB 這種針對物聯(lián)網(wǎng)設(shè)備的特殊建模方式，對我們進(jìn)行數(shù)據(jù)建模以及后續(xù)應(yīng)用提供了很多便利。

TDengine TSDB 針對這種查詢專門進(jìn)行了優(yōu)化，可以配置最新值緩存策略，將所有子表的最新一條非空值或最新一行記錄緩存到 cache 中，從而在查詢時獲得更快的響應(yīng)速度和更好的并發(fā)支持能力。

具體來說，我們通過建庫參數(shù) cachemodel 和 cachesize 來設(shè)置緩存策略以及緩存占用空間大小。

由于我們的業(yè)務(wù)對 last 和 last_row 都有需求，因此所有場站數(shù)據(jù)庫都開啟了緩存策略，并將 cachemodel 統(tǒng)一設(shè)置為 both，也就是同時緩存 last 與 last_row。

不過，緩存并不是越大越好。由于每個數(shù)據(jù)庫的子表數(shù)量和表結(jié)構(gòu)都不完全相同，緩存空間需要結(jié)合實際情況進(jìn)行配置：設(shè)置過大會浪費(fèi)內(nèi)存，設(shè)置過小則會導(dǎo)致緩存頻繁刷新，反而影響寫入效率并浪費(fèi)系統(tǒng)資源。

經(jīng)過持續(xù)調(diào)整，目前三區(qū)的緩存配置如下圖所示：

數(shù)據(jù)訂閱

為了實現(xiàn)大屏組態(tài)的實現(xiàn)數(shù)據(jù)刷新，我們通過訂閱方式實時獲取所關(guān)注子表數(shù)據(jù)的最新記錄。

在 TDengine TSDB 中，我們可以直接通過 SQL 語句創(chuàng)建帶篩選條件的 topic。業(yè)務(wù)程序只需要訂閱對應(yīng) topic，就能夠持續(xù)獲取符合條件的最新數(shù)據(jù)。

例如，我們創(chuàng)建 topic 的 SQL 如下：

create topic prod_djnx_zwdwse_lg_st_telemetry_short_float as select ts,`channel_id`,`object_address`, `r32` from db_solar_wz52.st_telemetry_short_float;

TDengine TSDB 的數(shù)據(jù)訂閱依賴 WAL 文件。由于數(shù)據(jù)寫入后會第一時間進(jìn)入 WAL，數(shù)據(jù)訂閱能夠保障訂閱程序第一時間獲取更新的數(shù)據(jù)內(nèi)容，這對于需要實時刷新的監(jiān)視類應(yīng)用非常關(guān)鍵。

目前，三區(qū)正在使用的 topic 一共有 29 個：

多級存儲節(jié)省存儲成本

為了節(jié)省存儲成本，我們采購了 NAS 來存儲長期歷史數(shù)據(jù)，結(jié)合 TDengine TSDB 的多級存儲功能，利用不同的存儲介質(zhì)存儲不同時間段、不同訪問頻率的數(shù)據(jù)，有效降低了數(shù)據(jù)存儲成本。

NAS（Network Attached Storage，網(wǎng)絡(luò)附加存儲）是一種專門用于數(shù)據(jù)存儲和共享的網(wǎng)絡(luò)設(shè)備，它通過局域網(wǎng)（LAN）為多用戶或其他設(shè)備提供集中化的存儲空間。TDengine TSDB 只能支持 iSCSI 掛載方式，不支持 NFS、CIFS 等掛載方式。

在濤思服務(wù)中心專家的支持下，通過增加 NAS 設(shè)備掛載點(diǎn)、修改數(shù)據(jù)庫的 KEEP 參數(shù)以及 taos.cfg 配置文件操作，實現(xiàn)了數(shù)據(jù)的多級存儲。具體操作步驟如下：

1. 在服務(wù)器上增加 NAS 掛載點(diǎn) data1；

2. 修改 KEEP 參數(shù)，修改策略為：8 個月 （240 天）之內(nèi)的數(shù)據(jù)存儲在本機(jī)磁盤上，超過 240 天的數(shù)據(jù)會存儲到 NAS 上；

3. 修改 taos.cfg配置文件，指定 0 級存儲與 1 級存儲路徑。

通過上述配置，即可實現(xiàn)數(shù)據(jù)按照時間范圍的多級存儲。

TDengine 業(yè)務(wù)應(yīng)用

全局監(jiān)視系統(tǒng)

依托 TDengine TSDB ，全局監(jiān)視系統(tǒng)實現(xiàn)了監(jiān)視頁面數(shù)據(jù)實時刷新以及歷史數(shù)據(jù)查詢快速響應(yīng)。

如下圖所示，在場站監(jiān)視頁面，通過實時數(shù)據(jù)訂閱，監(jiān)視畫面就能夠?qū)崟r獲取所有場站當(dāng)前的狀態(tài)信息以及關(guān)鍵的統(tǒng)計信息、告警內(nèi)容等。

數(shù)據(jù)分析系統(tǒng)

依托 TDengine TSDB 的高性能查詢能力，數(shù)據(jù)分析系統(tǒng)實現(xiàn)了大量統(tǒng)計指標(biāo)的定期更新。

如圖所示，數(shù)據(jù)分析系統(tǒng)主要用于定時統(tǒng)計任務(wù)，會按照固定時間周期從 TDengine TSDB 中進(jìn)行大量數(shù)據(jù)查詢。例如在電廠生產(chǎn)對標(biāo)應(yīng)用場景中，將各種關(guān)鍵指標(biāo)與去年同期進(jìn)行對比分析，計算同比，為經(jīng)營分析與生產(chǎn)優(yōu)化提供支撐。

未來展望

寧夏新能源集控中心自投入運(yùn)行以來，TDengine TSDB 集群整體保持穩(wěn)定運(yùn)行。在集控中心成功應(yīng)用 TDengine TSDB 的經(jīng)驗，進(jìn)一步堅定了電建新能源集團(tuán)深耕新能源數(shù)字化領(lǐng)域的信心。后續(xù)，集團(tuán)計劃將 TDengine TSDB 的應(yīng)用范圍拓展至電力交易等更多業(yè)務(wù)環(huán)節(jié)，與 TDengine 攜手為新能源領(lǐng)域客戶創(chuàng)造更大價值。

關(guān)于華東院

中國電建集團(tuán)華東勘測設(shè)計研究院有限公司（簡稱華東院）成立于 1954 年，具有工程設(shè)計綜合甲級、工程勘察綜合甲級、工程咨詢綜合甲級、工程總承包與設(shè)備成套等十多個國家最高等級的資質(zhì)證書。全院新能源從業(yè)人員達(dá) 1000 余人，業(yè)務(wù)涉及海上風(fēng)電、陸上風(fēng)電、光伏、儲能、微電網(wǎng)、地?zé)崮?、海洋能等。憑借著工程 + IT 的優(yōu)勢，自 2012 年啟動海上風(fēng)電三維數(shù)字化設(shè)計以來，持續(xù)深耕風(fēng)電、光伏、綜合能源領(lǐng)域的數(shù)字化，具備頂層規(guī)劃、方案設(shè)計、產(chǎn)品研發(fā)、工程交付、實施運(yùn)維等全鏈路的服務(wù)能力。

作者：林子義，劉藝博（濤思數(shù)據(jù)）

為何選擇 TDengine TSDB

作為全球領(lǐng)先的光伏智慧能源整體解決方案提供商，自 2018 年至 2022 年間，我們的光伏系統(tǒng)每日數(shù)據(jù)量從百萬級躍升至千萬級。隨著數(shù)據(jù)規(guī)模的指數(shù)式增長，對存儲與實時計算能力提出了更高要求，原有基于 MongoDB 的架構(gòu)已難以支撐業(yè)務(wù)發(fā)展。

MongoDB 作為一種文檔型 NoSQL 數(shù)據(jù)庫，在處理多樣化數(shù)據(jù)格式的大數(shù)據(jù)場景中具備很強(qiáng)的靈活性，尤其在 IoT 數(shù)據(jù)采集與分析領(lǐng)域應(yīng)用廣泛。然而，對于我們這樣的場景，MongoDB 的特性卻與需求存在一定錯位，主要體現(xiàn)在以下三方面：

• 傳感器上傳的數(shù)據(jù)均為結(jié)構(gòu)化數(shù)據(jù)，結(jié)構(gòu)基本不變，若缺乏嚴(yán)格的數(shù)據(jù)校驗機(jī)制，MongoDB 的非結(jié)構(gòu)化特性反而容易造成數(shù)據(jù)污染；
• 查詢性能不足，即便建立索引，也難以在 TB 級數(shù)據(jù)量中實現(xiàn)快速檢索；
• 采用文檔方式存儲，壓縮率較低，存儲成本升高。

在這種背景下，TDengine TSDB 作為新一代時序數(shù)據(jù)庫，憑借以下優(yōu)勢吸引了我們的關(guān)注：

• 采用“超級表 + 子表”的建模方式，大幅提升時序數(shù)據(jù)壓縮率；
• 結(jié)合預(yù)計算與緩存機(jī)制，實現(xiàn)億級數(shù)據(jù)的毫秒級查詢響應(yīng)；
• 支持多級存儲，可將歷史數(shù)據(jù)遷移至低速磁盤，顯著降低存儲成本；
• 兼容標(biāo)準(zhǔn) SQL，極大簡化了應(yīng)用開發(fā)與系統(tǒng)集成工作。

綜合考量存儲成本、讀寫性能及實施難度等多方面因素，我們最終選擇將數(shù)據(jù)庫替換為 TDengine TSDB。

時序數(shù)據(jù)處理技術(shù)架構(gòu)

光伏時序數(shù)據(jù)的主要應(yīng)用場景集中在我司的能源管理系統(tǒng)中，涵蓋數(shù)據(jù)采集、接入、存儲、處理與應(yīng)用等模塊，為企業(yè)提供從實時監(jiān)控、數(shù)據(jù)分析、運(yùn)維管理到能源優(yōu)化與安全管理的全流程數(shù)字化支撐。

采集端通過 TCP 協(xié)議上報光伏組件、逆變器、電池等設(shè)備的運(yùn)行數(shù)據(jù)，經(jīng)過數(shù)據(jù)清洗后，以結(jié)構(gòu)化格式暫存于 Kafka（僅保留近期時間數(shù)據(jù)）。數(shù)據(jù)寫入應(yīng)用從 Kafka 消費(fèi)后，將其寫入 TDengine TSDB 進(jìn)行持久化存儲。隨后，系統(tǒng)對數(shù)據(jù)進(jìn)行計算（如當(dāng)日發(fā)電量、實時功率等），并將降采樣結(jié)果存入結(jié)果庫，以支持后續(xù)的統(tǒng)計分析與可視化展示。

雖然采集端的數(shù)據(jù)可以直接寫入 TDengine TSDB，但是考慮到整體架構(gòu)的穩(wěn)定性，我們?nèi)匀槐Ａ袅?Kafka。這樣的設(shè)計為系統(tǒng)提供了一個實時數(shù)據(jù)的冗余緩沖區(qū)，不僅在一定周期內(nèi)實現(xiàn)了數(shù)據(jù)的高可用存儲，也為后續(xù)處理環(huán)節(jié)預(yù)留了維護(hù)窗口，從而顯著提升整體架構(gòu)的可靠性與可用性。

項目實施初期采用的是 TDengine TSDB 2.6 版本，部署了 3 個數(shù)據(jù)庫節(jié)點(diǎn)。數(shù)據(jù)采集與處理應(yīng)用通過 RESTful 連接到 TDengine TSDB 集群，集群采用高效云盤與普通云盤相結(jié)合的多級存儲架構(gòu)，在兼顧性能的同時有效控制了整體存儲成本。

TDengine 應(yīng)用效果

經(jīng)過半年的項目實施（包括采集設(shè)備改造、應(yīng)用開發(fā)及數(shù)據(jù)庫適配），能源管理系統(tǒng)順利上線運(yùn)行。系統(tǒng)實現(xiàn)了千萬級數(shù)據(jù)（每日）的零延遲入庫，數(shù)據(jù)分析（如設(shè)備日發(fā)電量統(tǒng)計）響應(yīng)時間控制在秒級以內(nèi)。與此同時，通過高效云盤與普通云盤的分層存儲方案，整體存儲成本降低了約 50%。該系統(tǒng)的成功投產(chǎn)為我司業(yè)務(wù)發(fā)展提供了有力的支撐。

TDengine 3.0 升級經(jīng)驗分享

隨著業(yè)務(wù)的持續(xù)擴(kuò)張，系統(tǒng)面臨兩大挑戰(zhàn)：一是接入設(shè)備數(shù)量不斷增長，導(dǎo)致子表數(shù)量的創(chuàng)建達(dá)到千萬級別；二是元數(shù)據(jù)體量激增，造成數(shù)據(jù)庫啟動緩慢，維護(hù)窗口不斷延長。

為解決這些問題，我們于 2024 年決定將 TDengine TSDB 升級至 3.3 企業(yè)版。該版本擁有快速的啟動速度及更為海量的數(shù)據(jù)管理能力：

1. 支持億級時間線；
2. 數(shù)據(jù)庫“秒級”啟動；
3. 多級存儲支持對象存儲，進(jìn)一步降低存儲成本。

由于系統(tǒng)需在不停機(jī)的情況下完成版本升級，我們與 TDengine 專業(yè)服務(wù)團(tuán)隊進(jìn)行了深入溝通，最終確定采用 taosX 數(shù)據(jù)同步遷移工具，并結(jié)合 鏡像集群 + 程序雙寫 的方案完成升級。具體步驟如下：

• 通過云服務(wù)工具，將現(xiàn)有的 2.6 集群鏡像復(fù)制，創(chuàng)建一個新集群；
• 修改寫入應(yīng)用，實現(xiàn)對 2.6 集群與 3.3 集群的雙寫，以確保最新數(shù)據(jù)的一致性；
• 使用 taosX 遷移工具，將歷史數(shù)據(jù)從鏡像集群無縫遷移至 3.3 集群。

在數(shù)據(jù)庫升級的同時，我們也同步進(jìn)行了應(yīng)用層的升級與適配工作。由于 TDengine TSDB 3.0 及以上版本功能更為豐富，我們主要完成了以下優(yōu)化：

• 根據(jù) 3.3 版本的語法特性，對原有查詢語句進(jìn)行了優(yōu)化與改寫；
• 調(diào)整查詢條件，適配 OSS（對象存儲服務(wù)）訪問場景；
• 優(yōu)化數(shù)據(jù)訪問方式，升級至新的 JDBC 連接器與通信協(xié)議。

OSS 全稱 Object Storage Service（對象存儲服務(wù)），是云服務(wù)商提供的海量、可擴(kuò)展、高可靠性存儲服務(wù)，主要用于存儲圖片、視頻、文檔等非結(jié)構(gòu)化數(shù)據(jù)。相比于高效云盤，OSS 的價格降低至少 60%。

升級后的運(yùn)行表現(xiàn)

經(jīng)過數(shù)據(jù)遷移與嚴(yán)格校驗，我們成功將近 20TB 的數(shù)據(jù)零誤差遷移至新集群，全程業(yè)務(wù)無中斷。借助應(yīng)用層的優(yōu)化與適配，系統(tǒng)在新集群上實現(xiàn)了高效、穩(wěn)定運(yùn)行。

為進(jìn)一步提升數(shù)據(jù)庫集群的高可用性，我們在集群前端部署了負(fù)載均衡服務(wù)器，并通過合理的負(fù)載均衡策略，精細(xì)化控制不同應(yīng)用的資源占用。在確保系統(tǒng)高可用的同時，也實現(xiàn)了各應(yīng)用間的有效隔離與性能優(yōu)化。

通過使用多級存儲的對象存儲功能，我們將大量的歷史數(shù)據(jù)遷移到了對象存儲上，本地磁盤占用量降低了約 50%，進(jìn)一步壓縮了整體存儲成本。

自 2022 年合作至今，伴隨 TDengine TSDB 從 2.6 版本迭代至 3.3 版本，我們始終認(rèn)為，這款時序數(shù)據(jù)庫雖非完美無缺，卻憑借對能源行業(yè)業(yè)務(wù)場景的深度適配，已成為與天合富家需求高度契合的技術(shù)工具。

作為一家致力于“提供智能清潔能源解決方案，構(gòu)建零碳生活與零碳生產(chǎn)新生態(tài)”的企業(yè)，天合富家在邁向零碳目標(biāo)的過程中，依托 TDengine TSDB 穩(wěn)定的時序數(shù)據(jù)存儲能力與高效的分析性能，為能源管理、設(shè)備監(jiān)控等核心業(yè)務(wù)提供了堅實的數(shù)據(jù)底座，也為公司實現(xiàn)零碳生態(tài)落地注入了持續(xù)的技術(shù)動力。

關(guān)于天合富家

天合富家能源股份有限公司成立于 2016 年 10 月，是一家專注于分布式能源市場的系統(tǒng)解決方案提供商。作為分布式光伏行業(yè)領(lǐng)軍企業(yè)，天合富家圍繞品牌、產(chǎn)品、服務(wù)三大核心戰(zhàn)略建立了以產(chǎn)品研發(fā)、市場銷售、安裝售后、智能運(yùn)維為一體的完整體系，構(gòu)建了數(shù)字化、全渠道的生態(tài)網(wǎng)絡(luò)。天合富家以原裝為基本戰(zhàn)略，持續(xù)創(chuàng)新，不斷提升產(chǎn)品與服務(wù)體驗，致力于打造智慧分布式能源第一品牌，為客戶提供最佳的清潔能源體驗。

隨著光伏、電池等技術(shù)的不斷進(jìn)步，家庭儲能、戶外儲能市場蓬勃發(fā)展，廣州疆?？萍加邢薰酒煜碌?“Zendure（征拓）” 致力于家庭儲能和能源管理系統(tǒng)的研發(fā)與銷售，用戶遍布全球。

對儲能設(shè)備進(jìn)行能量分析是 Zendure 的關(guān)鍵業(yè)務(wù)之一。這一動作能夠幫助用戶實時掌握儲能設(shè)備的運(yùn)行狀態(tài)，通過對功率、電能以及輸入輸出數(shù)據(jù)此類典型的時序數(shù)據(jù)進(jìn)行精準(zhǔn)統(tǒng)計與分析，用戶可清晰了解設(shè)備的能效表現(xiàn)與能源使用情況，輕松實現(xiàn)精細(xì)化管理和優(yōu)化決策。

最初，我們采用關(guān)系型數(shù)據(jù)庫管理儲能設(shè)備的時序數(shù)據(jù)，但隨著數(shù)據(jù)規(guī)模的迅猛增長，很快遇到了性能瓶頸，不得不尋找更高效的解決方案。在數(shù)據(jù)庫選型過程中，我們了解到時序數(shù)據(jù)庫 TDengine，其獨(dú)特的“一設(shè)備一張表”數(shù)據(jù)模型、“超級表-子表”架構(gòu)，以及卓越的性能表現(xiàn)，與我們的儲能設(shè)備數(shù)據(jù)管理需求高度契合。

我們最初使用 TDengine OSS 開源版本進(jìn)行業(yè)務(wù)數(shù)據(jù)存儲，隨著業(yè)務(wù)規(guī)模擴(kuò)大和功能需求增加，2024 年正式升級至 TDengine 企業(yè)版。借助 taosX 強(qiáng)大的數(shù)據(jù)接入與遷移能力，在濤思技術(shù)團(tuán)隊的支持下，我們不僅高效遷移了開源版的歷史數(shù)據(jù)，還完成了 MySQL 存儲數(shù)據(jù)的 transform 結(jié)構(gòu)優(yōu)化，并順利導(dǎo)入 TDengine 企業(yè)版集群，實現(xiàn)了歷史數(shù)據(jù)遷移、業(yè)務(wù)切換及表結(jié)構(gòu)優(yōu)化，確保系統(tǒng)平穩(wěn)過渡，為儲能業(yè)務(wù)的進(jìn)一步發(fā)展奠定了堅實基礎(chǔ)。

能量分析業(yè)務(wù)

問題描述

能量分析業(yè)務(wù)既需要從業(yè)務(wù)維度將數(shù)據(jù)分為功率、電能、輸入輸出這 3 類，分類別進(jìn)行統(tǒng)計查詢，又需要從設(shè)備維度，按每個設(shè)備的 device 信息進(jìn)行統(tǒng)計查詢。過去使用關(guān)系型數(shù)據(jù)庫，無論是按照業(yè)務(wù)建表還是按照設(shè)備建表均無法很好地滿足業(yè)務(wù)需求。

TDengine 解決方案

• 超級表設(shè)計

結(jié)合業(yè)務(wù)需求以及 TDengine “一個設(shè)備一張表”  數(shù)據(jù)模型，“超級表-子表” 組織結(jié)構(gòu)，我們對設(shè)備儲能數(shù)據(jù)的組織方式如下：

創(chuàng)建了 3 張超級表，分別對應(yīng)設(shè)備的功率數(shù)據(jù)、電能數(shù)據(jù)以及輸入輸出數(shù)據(jù)。而每個設(shè)備的數(shù)據(jù)分別記錄在超級表下的對應(yīng)子表中，同時兼顧了業(yè)務(wù)維度與設(shè)備維度對數(shù)據(jù)組織的需求，如下圖所示。

經(jīng)過測試驗證以及實際業(yè)務(wù)檢驗，TDengine 能夠很好地支持儲能設(shè)備能量分析業(yè)務(wù)，查詢速度和數(shù)據(jù)壓縮率表現(xiàn)都很優(yōu)異。

• 高速查詢

查詢案例 1 ：統(tǒng)計 2024 年 9 月以來，每個設(shè)備每天的 energy 總和，查詢語句和耗時記錄如下，我們可以看到返回 100 余萬筆統(tǒng)計結(jié)果，僅耗時 1 秒多。

查詢案例 2：查詢設(shè)備 id 為 100048，在 2024-11-09 當(dāng)天，全天的電力輸入輸出數(shù)據(jù)，返回 258 條數(shù)據(jù)耗時 0.513 秒。

• 高效壓縮

使用 TDengine 的另一個優(yōu)勢，在于數(shù)據(jù)壓縮率高。我們的數(shù)據(jù)服務(wù)部署在亞馬遜云上，高壓縮率給我們節(jié)省了很多成本。對于功率、電能、輸入輸這 3 張超級表，數(shù)據(jù)壓縮率分別達(dá)到了 5.34 %、5.95 %、8.63 % 。（數(shù)據(jù)壓縮率指 data 文件中 實際占用的空間 / 無壓縮狀態(tài)下數(shù)據(jù)占用的空間 * 100%）。

• 應(yīng)用界面展示

目前該項目運(yùn)行中的儲能設(shè)備數(shù)量已經(jīng)超過 3 萬臺/套，系統(tǒng)運(yùn)行穩(wěn)定高效。部分?jǐn)?shù)據(jù)查詢頁面如下圖所示：

TDengine – TDengine 歷史數(shù)據(jù)遷移

問題描述

采購企業(yè)版后，在濤思技術(shù)團(tuán)隊的協(xié)助下，我們在亞馬遜云上成功部署了 3 節(jié)點(diǎn)集群。隨之而來的挑戰(zhàn)是如何在不中斷原有業(yè)務(wù)的情況下，將開源版集群中一年的歷史數(shù)據(jù)平穩(wěn)遷移至新集群，并在大部分?jǐn)?shù)據(jù)同步完成后再執(zhí)行業(yè)務(wù)切換。歷史數(shù)據(jù)的大規(guī)模遷移一向是數(shù)據(jù)運(yùn)維的難題，但幸運(yùn)的是，TDengine 企業(yè)版內(nèi)置了 taosX 組件，提供零代碼數(shù)據(jù)接入能力，使得遷移過程更加高效便捷。

TDengine 解決方案

為盡快同步歷史數(shù)據(jù)，同時保留對基礎(chǔ)性能參數(shù)的調(diào)整靈活性，濤思技術(shù)團(tuán)隊采用 taosX 命令行模式，通過原生連接方式進(jìn)行數(shù)據(jù)遷移操作。

taosx run -f "taos://root:XXXX@node1:6030/zendure_db?schema=none&unit=2d&start=2024-08-01T00:00:00Z&end=2024-09-01T00:00:00Z&libraryPath=/data/taos/soft/libtaos.so.3.0.7.1" -t 'taos://root:XXXX@tdengine-enterprise-eu-1:6030/zendure_db?fails-to=/data/error_db_sync_M08.log' -j 10

上述命令行（密碼用 XXXX 替換），能夠從源端（-t），TDengine 版本號為 3.0.7.1，hostsname 為 tdengine-enterprise-eu-1 的節(jié)點(diǎn)，以原生連接（6030）的方式將 dbname 為 zendure_db ，時間段為 2024-08-01 到 2024-09-01 的歷史數(shù)據(jù)遷移到目標(biāo)端（-f）。通過控制 -j 參數(shù)限制并發(fā)線程數(shù)，避免數(shù)據(jù)遷移操作對源端產(chǎn)生過大的影響。

在業(yè)務(wù)低谷期，按時間段倒序遷移，每天遷移 3-4 個月的歷史數(shù)據(jù)，最終我們成功在國慶假期之前完成了歷史數(shù)據(jù)的遷移。

超級表 schema 變更

問題描述

在最初使用 TDengine OSS 管理數(shù)據(jù)時，由于對其特性尚不熟悉，業(yè)務(wù)模式未完全梳理清晰，導(dǎo)致部分超級表的設(shè)計不夠合理。例如，一些原本適合作為 tag 列的字段被誤設(shè)為數(shù)據(jù)列，造成了不必要的磁盤空間浪費(fèi)；部分超級表則需要新增 tag 列，以優(yōu)化數(shù)據(jù)管理和查詢效率。

由于這些表結(jié)構(gòu)變更較為復(fù)雜，無法直接通過簡單的增刪數(shù)據(jù)列或 tag 列完成調(diào)整。為此，濤思技術(shù)團(tuán)隊協(xié)助設(shè)計了一套基于 CSV 文件的數(shù)據(jù)中轉(zhuǎn)方案，并結(jié)合 taosX 與 taosExplorer 高效完成數(shù)據(jù)遷移，確保數(shù)據(jù)結(jié)構(gòu)優(yōu)化的同時，平穩(wěn)過渡至新的存儲架構(gòu)。TDengine 解決方案

• 實施思路

1. 以 csv 文件作為數(shù)據(jù)中轉(zhuǎn)形態(tài)
2. 通過 taos shell 執(zhí)行 SQL 語句，將原超級表數(shù)據(jù)批量導(dǎo)出到 csv 文件中
3. 利用 TDengine 自帶工具 taosX、taosExplore所具備的批量 csv 文件解析寫入功能，將導(dǎo)出到 csv 文件中的原始數(shù)據(jù)按照新的表結(jié)構(gòu)寫入到新超級表中。

• 操作步驟

1. 創(chuàng)建新數(shù)據(jù)庫與新表
2. 將原表數(shù)據(jù)分批次導(dǎo)出到 csv 文件中
3. 創(chuàng)建 csv 寫入任務(wù)
4. 字段映射
5. 執(zhí)行數(shù)據(jù)寫入并監(jiān)測任務(wù)運(yùn)行情況
6. 數(shù)據(jù)正確性檢驗
7. 業(yè)務(wù)遷移
8. 遺留數(shù)據(jù)遷移
9. tag 賦值

• 關(guān)鍵步驟介紹

數(shù)據(jù)導(dǎo)出到 csv 文件與數(shù)據(jù)重新映射并寫入 TDengine 是兩個關(guān)鍵步驟。首先，通過 taos shell 執(zhí)行 SQL 語句，即可按指定時間范圍導(dǎo)出歷史數(shù)據(jù)至 CSV 文件。例如，使用以下 SQL 語句即可導(dǎo)出特定時間段的數(shù)據(jù)：

select tbname, * from test.meters where ts >='2017-07-14 10:00:00' and ts <'2017-07-14 11:00:00'>> /root/test/1.csv; 
select tbname, * from test.meters where ts >='2017-07-14 11:00:00' and ts <'2017-07-14 11:30:00'>> /root/test/2.csv; 
select tbname, * from test.meters where ts >='2017-07-14 11:30:00' and ts <'2017-07-14 12:00:00'>> /root/test/3.csv; 

在 taosExplorer 中配置數(shù)據(jù)源，以及數(shù)據(jù)在新建超級表中的映射關(guān)系，即可實現(xiàn)變更表結(jié)構(gòu)的需求。我們可按照如下步驟配置數(shù)據(jù)源：

解析成功后，在“映射”選項卡中，配置新舊超級表之間的映射關(guān)系，在這一步將原始數(shù)據(jù)映射到新的表結(jié)構(gòu)中。

在濤思技術(shù)團(tuán)隊的協(xié)助下，最終我們成功實現(xiàn)了表結(jié)構(gòu)的變更與數(shù)據(jù)的遷移。

從 MySQL 遷移數(shù)據(jù)到 TDengine

問題描述

過去，一些歷史數(shù)據(jù)存儲在 MySQL 中，隨著企業(yè)版 TDengine 的部署，我們希望將這些數(shù)據(jù)遷移至 TDengine 集群進(jìn)行統(tǒng)一管理。然而，由于 MySQL 與 TDengine 的建表方式存在較大差異，我們需要對字段進(jìn)行映射，并篩選出符合需求的部分?jǐn)?shù)據(jù)進(jìn)行導(dǎo)入。在濤思技術(shù)團(tuán)隊的支持下，我們借助 taosX 高效完成了數(shù)據(jù)篩選、結(jié)構(gòu)映射及遷移，實現(xiàn)了 MySQL 歷史數(shù)據(jù)的順利接入。

TDengine 解決方案

taosX 可通過配置 SQL 語句從 MySQL 數(shù)據(jù)源查詢所需數(shù)據(jù)，并將其映射至 TDengine 已創(chuàng)建的超級表或子表，實現(xiàn)數(shù)據(jù)的高效接入與遷移。SQL 配置界面如下圖所示：

在遷移過程中，我們遇到了 taosX 無法識別 MySQL 時間戳字段的問題。通過使用 UNIX_TIMESTAMP 函數(shù)將 MySQL 的時間戳轉(zhuǎn)換為 UNIX 時間戳，成功解決了該問題。

此外，MySQL 可存儲所有時間戳相同的數(shù)據(jù)，而 TDengine 僅保留相同時間戳的最后一條記錄。為滿足業(yè)務(wù)需求，我們將 type 數(shù)據(jù)列的信息疊加到毫秒級時間戳中，在不使用復(fù)合主鍵的情況下，實現(xiàn)了類似的效果。

最終采用的 SQL 語句如下：

SELECT t.consumer_id,device_id,UNIX_TIMESTAMP(t.create_time)*1000+type as ts,power,type
        FROM
        t_device_inout_power_record t,t_device d,t_product pt 
        where 
        t.device_id=d.id and 
        d.product_id=pt.id and 
        pt.product_type_id in (3,4) and
         create_zone_time>'2023-1-1';

對從 MySQL 查詢出來的數(shù)據(jù)進(jìn)行映射處理：

任務(wù)執(zhí)行完成后的指標(biāo)如下，可以看到總計導(dǎo)入了四千多萬行數(shù)據(jù)，完成了數(shù)據(jù)從 MySQL 向 TDengine 的遷移。

結(jié)語

時序數(shù)據(jù)的迅猛增長曾給我們帶來查詢效率和存儲成本的挑戰(zhàn)，而 TDengine 的引入成功解決了這些問題。尤其值得一提的是 taosX 組件，其零代碼數(shù)據(jù)遷移能力大幅降低了開發(fā)時間和成本，讓數(shù)據(jù)管理更加高效便捷。

家庭儲能與戶外儲能市場仍在快速發(fā)展，對時序數(shù)據(jù)的高效管理需求也將持續(xù)增長。未來，我們期待與 TDengine 攜手，共同助力中國企業(yè)揚(yáng)帆出海，為全球能源管理貢獻(xiàn)更多力量。

本文作者：疆?？萍?馬老師

關(guān)于疆?？萍?/strong>