在 7 月 26 日的 TDengine 用戶大會上，新奧數能 / 物聯和數據技術召集人袁文科進行了題為《基于新一代時序數據庫 TDengine 助力泛(fan)(fan)能網能碳產業(ye)智(zhi)能平(ping)臺(tai)底(di)座升級》的主題演(yan)講(jiang)。他從泛(fan)(fan)能網能碳產業(ye)智(zhi)能平(ping)臺(tai)的業(ye)務(wu)及架構痛(tong)點出發，詳(xiang)細分享了(le)在數(shu)據(ju)(ju)(ju)庫(ku)選(xuan)型、平(ping)臺(tai)架構改造、新舊(jiu)底(di)座替換(huan)以及數(shu)據(ju)(ju)(ju)遷(qian)移等(deng)多(duo)個維度的經(jing)驗，為與(yu)會(hui)者提(ti)供了(le)寶貴的參考。本文據(ju)(ju)(ju)此演(yan)講(jiang)內容(rong)整理而成。
平臺痛點及架構痛點
新奧數(shu)能科技(ji)(ji)有(you)限公(gong)司(si)成立于(yu)(yu) 2018 年(nian)，隸屬于(yu)(yu)新奧集團。公(gong)司(si)基于(yu)(yu)新奧集團過去 30 多年(nian)在能源行業(ye)的經(jing)驗積累(lei)，以及 10 多年(nian)來對(dui)泛能理(li)念的深刻理(li)解，結合物(wu)聯網、大(da)數(shu)據(ju)和人工智能技(ji)(ji)術，打(da)造(zao)了一個智能能碳產業(ye)平(ping)臺，我們稱之為“泛能網”。
泛能(neng)網的(de)(de)核心聚焦于公建(jian)、工廠(chang)、園區等應用場景。我(wo)(wo)們(men)的(de)(de)客戶，尤其是他(ta)們(men)的(de)(de)管理層以(yi)及能(neng)源部(bu)(bu)門(men)或運維部(bu)(bu)門(men)，在日常(chang)節能(neng)降本、設備運營和運維方面，經常(chang)會遇到難以(yi)解決的(de)(de)問題。而我(wo)(wo)們(men)正是圍繞這(zhe)些客戶的(de)(de)痛(tong)點，提(ti)供一體(ti)化的(de)(de)智(zhi)能(neng)平臺解決方案。
泛(fan)能(neng)(neng)網的(de)(de)(de)建設理念是從(cong)底層物聯設備中(zhong)采集客戶需(xu)要(yao)解決的(de)(de)(de)關(guan)鍵設備數據，匯總到平臺，經(jing)過大規模的(de)(de)(de)數據處理后，生成監控和運(yun)維的(de)(de)(de)指標(biao)。接(jie)著，通過智能(neng)(neng)算法和仿(fang)真(zhen)能(neng)(neng)力(li)，我們為客戶提供(gong)包括實時監控、運(yun)營管(guan)理，甚(shen)至未來的(de)(de)(de)碳(tan)交易等(deng)一系(xi)列應用(yong)產品。
自 2018 年平臺建設啟動以來，至今已經有五六年的發展歷程。在這個過程中，我們遇到了一些行業內普遍存在的痛點。第一個痛點是海量物聯設備的數據采集問題。以(yi)一個(ge)簡單的(de)例子(zi)來(lai)說明：我們(men)服務(wu)于 5000 多家(jia)客(ke)戶(hu)，每個(ge)客(ke)戶(hu)有約(yue) 50 臺設備(bei)，每臺設備(bei)每分鐘采集 10 到(dao) 20 個(ge)數(shu)(shu)據點，那么每秒的(de)數(shu)(shu)據處理量（TPS）就(jiu)達到(dao) 9 萬左(zuo)右。如(ru)果涉及到(dao)電力(li)等(deng)領域，數(shu)(shu)據采集的(de)頻率還(huan)可能更高，達到(dao)秒級(ji)甚至毫秒級(ji)，數(shu)(shu)據量會(hui)成倍增加。
第二個痛點在于數據查詢的多維度要求。客戶(hu)可能基于時間維度，需要(yao)查看最(zui)大值(zhi)(zhi)、最(zui)小(xiao)(xiao)值(zhi)(zhi)、平均值(zhi)(zhi)，甚至差值(zhi)(zhi)分析(xi)。同(tong)時，他(ta)們對查詢結果的響應(ying)速度有很高的要(yao)求。此外(wai)，數(shu)據的長期存(cun)儲也(ye)是(shi)一大挑戰(zhan)。有些客戶(hu)希望(wang)保留 5 年(nian)甚至 10 年(nian)的數(shu)據，這對存(cun)儲空間和查詢索引(yin)帶來了不小(xiao)(xiao)的壓力(li)。
除了數據采集和查詢，另一個挑戰是指標的計算。過去我們遇到的兩大問題，一是指標計算不準確：典(dian)型問題是日(ri)、月(yue)(yue)(yue)、年數據不(bu)能(neng)互(hu)(hu)相印證，日(ri)月(yue)(yue)(yue)不(bu)等用電約 7%，用水及蒸(zheng)汽(qi)約 18%，用燃氣超過 31%；月(yue)(yue)(yue)年不(bu)等超過 50%，是長期(qi)以來的全局性問題。另外測點數據延遲、互(hu)(hu)相依賴的指標(biao)執行先后不(bu)同(tong)等也會使指標(biao)計算不(bu)準(zhun)確。
二是指標計算不及時，這主要源于(yu)過(guo)去采用的(de)計算方(fang)式(shi)(shi)依賴于(yu)任務調度和公式(shi)(shi)計算。這種方(fang)式(shi)(shi)不可避(bi)免地會導致(zhi)計算延遲，因(yin)為調度過(guo)程本身就存在一定的(de)延時，尤其是當涉及大量歷(li)史數(shu)(shu)(shu)據(ju)計算時，頻繁的(de)調度會造成更顯(xian)著的(de)延時。此外(wai)，某(mou)些(xie)數(shu)(shu)(shu)據(ju)測點如果出(chu)現斷數(shu)(shu)(shu)或數(shu)(shu)(shu)據(ju)丟失，也會進(jin)一步影響數(shu)(shu)(shu)據(ju)的(de)及時性。
為了(le)解決這些問(wen)題，經(jing)過(guo)(guo)分(fen)析，我們從兩個方面進行了(le)改進。首先，原有的(de)平臺架(jia)構(gou)雖然(ran)在當時(shi)能夠(gou)滿(man)足(zu)需求，但隨著客(ke)戶數量和(he)數據(ju)量的(de)增長(chang)，現(xian)有架(jia)構(gou)已(yi)經(jing)無法(fa)支撐當前和(he)未來的(de)業務發展。其次，過(guo)(guo)去選用的(de)一(yi)些存儲方案已(yi)經(jing)逐(zhu)漸過(guo)(guo)時(shi)，不(bu)能再滿(man)足(zu)現(xian)有需求。
具(ju)體來說，我(wo)們曾基于 OpenTSDB 的存儲方式，結合任務(wu)調(diao)度來完成數(shu)(shu)據處理。這種(zhong)方式的核心(xin)問題是(shi)任務(wu)調(diao)度的不(bu)及時(shi)性和頻率不(bu)一(yi)致(zhi)，導致(zhi)了(le)(le)數(shu)(shu)據加工(gong)的延遲和不(bu)準確。此外，數(shu)(shu)據采(cai)集(ji)和處理共用(yong)同一(yi)套(tao)存儲資源(yuan)，造成了(le)(le)資源(yuan)瓶頸。下(xia)圖展(zhan)示了(le)(le)我(wo)們過去的資源(yuan)使用(yong)情況，盡管我(wo)們用(yong)了(le)(le)十(shi)多臺(tai)(tai)物理服(fu)務(wu)器，每臺(tai)(tai)服(fu)務(wu)器擁有 60 多個計(ji)算核心(xin)，依然無(wu)法(fa)滿足需求(qiu)。
數據方案選型及落地應用
基于以上所提到的痛點，我們針對性地提出了相應的解決方案。首先，我們需要考慮兩個核心問題：一是如何選擇新的基礎設施，二是未來技術架構的演進方向。
關于基礎設(she)施選型，我(wo)們首(shou)先從幾個技(ji)術維(wei)度(du)進行深入考慮，包括技(ji)術的(de)適配性(xing)、國產化(hua)程(cheng)度(du)、成(cheng)熟度(du)、社區(qu)活躍度(du)以及商業化(hua)支持等(deng)。經(jing)過對(dui)(dui) TDengine、OpenTSDB、InfluxDB、Kdb+、TimescaleDB 等(deng)多種(zhong)方(fang)案的(de)對(dui)(dui)比，綜合分(fen)析(xi)發(fa)現(xian)，TDengine 在(zai)滿足這些維(wei)度(du)需求上(shang)具有明顯優(you)勢，雖然它相對(dui)(dui)較新，但(dan)在(zai)各方(fang)面(mian)的(de)表現(xian)十分(fen)適合我(wo)們的(de)業務需求。
相較于其他解(jie)決(jue)方案，OpenTSDB 在實際使(shi)用中已經(jing)暴露(lu)出諸多問題，InfluxDB 在開(kai)源版(ban)本(ben)上(shang)缺乏(fa)集群能力，Kdb+ 并未開(kai)源，且商(shang)業化過于封閉，TimescaleDB 作為 PostgreSQL 的擴展，其開(kai)源版(ban)本(ben)功能相對單一。因(yin)此，綜(zong)合考慮開(kai)源性、商(shang)業支持及長遠發展，我們最終選擇了 TDengine 作為基礎設施。
有了底層架構的選型后，我們對技術架構進行了相應的調整。首先，我們將任務調度模式升級為流式計算模式。流式計算在互聯網應用中已十分普遍，但在工業互聯網中仍較少應用。通過引入流式計算，我們能夠將原有的任務調度方式轉變為實時流式處理，這有效解決了任務調度中的延遲問題。同時，我們還將數據采集與計算分離，構建了“采算分離”架構：即通過物聯網平(ping)臺(tai)實(shi)現數(shu)(shu)據采(cai)集，再使用流式處(chu)理(li)對采(cai)集到的測點數(shu)(shu)據進(jin)行實(shi)時加工與(yu)計算，進(jin)一(yi)步提升(sheng)了數(shu)(shu)據處(chu)理(li)的實(shi)時性與(yu)準確性。
基于新架構，我們接下來探討如何具體落地并應用。例如，針對空壓機的能耗監測和運行狀態管理場景，空壓機系統內可能包含多個空壓機組，同時配備電能表或流量計作為測點設備。我們需要對這些測點的數據進行一級和二級的指標處理。在 TDengine 中，我們充分利用了超級表和子表的功能，將不同類型的測點歸類為超級表，每臺設備的實例對應子表。每個子表中的行記錄對應設備的數據點，列則代表具體的測點。這一模型為我們提供了高效的測點數據存儲方式。
同(tong)樣(yang)地，對于(yu)指(zhi)標計(ji)(ji)(ji)算(suan)，我們(men)采(cai)用(yong)了(le)類(lei)似的(de)(de)(de)模(mo)型(xing)(xing)。常見的(de)(de)(de)指(zhi)標計(ji)(ji)(ji)算(suan)中會涉及不同(tong)的(de)(de)(de)時(shi)間維(wei)度，如時(shi)、分(fen)、秒、日、月、年等。大部(bu)分(fen)應(ying)用(yong)場景要求在(zai)界面上(shang)展示某(mou)一分(fen)鐘的(de)(de)(de)指(zhi)標曲線或某(mou)個時(shi)間段的(de)(de)(de)指(zhi)標趨勢。因此，我們(men)基于(yu)時(shi)間維(wei)度構建超級表，不同(tong)的(de)(de)(de)時(shi)間類(lei)型(xing)(xing)作為(wei)分(fen)類(lei)維(wei)度，每個子指(zhi)標作為(wei)子表，記錄具(ju)體的(de)(de)(de)指(zhi)標值(zhi)。這樣(yang)一來，我們(men)就完(wan)成(cheng)了(le)數據(ju)采(cai)集和指(zhi)標計(ji)(ji)(ji)算(suan)的(de)(de)(de)存儲模(mo)型(xing)(xing)定義。
有了存儲模型后，我們還需要解決一些數據處理中的常見問題。首先就是數據延遲問題。并非所有設備都能準時上報數據，有時會出現延遲。為了兼容這些延遲數據，我們在TDengine的流式計算中引入了 Watermark（水位線）機制，通過冗余時間疊加來處理延遲數據，確保計算的準確性。
其(qi)次(ci)，在高(gao)頻(pin)率上報的(de)場景中(zhong)，一分鐘內可能會收(shou)到大(da)量數(shu)據點，但我們并不(bu)需要每個(ge)數(shu)據點都進行(xing)計(ji)算(suan)。這時我們采用數(shu)據分桶原理，將數(shu)據匯總(zong)后集中(zhong)計(ji)算(suan)，提升了(le)效(xiao)率。
最后，針對復(fu)雜(za)的(de)(de)指標(biao)(biao)(biao)計(ji)算(suan)(suan)，如(ru)空壓機系統中的(de)(de)單耗指標(biao)(biao)(biao)，它由氣量和電量的(de)(de)比(bi)值計(ji)算(suan)(suan)得出。這種(zhong)場景下(xia)，我(wo)們通過分(fen)(fen)流每個因(yin)子的(de)(de)數據，分(fen)(fen)別計(ji)算(suan)(suan)后再(zai)匯總，解(jie)決(jue)了復(fu)雜(za)指標(biao)(biao)(biao)中多因(yin)子并行計(ji)算(suan)(suan)的(de)(de)問題。
此外，數據(ju)會(hui)延(yan)遲，那自然也會(hui)有超前的(de)境況出現，部分設備(bei)由于時(shi)(shi)間校(xiao)準不準確或設備(bei)老化，可能會(hui)導致數據(ju)超前。對(dui)于這些情況，我(wo)們通(tong)過兼容性(xing)處理(li)手(shou)段，在(zai)一(yi)定(ding)范圍內(nei)等待數據(ju)，然后再進行延(yan)遲處理(li)。對(dui)于嚴重超前的(de)數據(ju)，我(wo)們則通(tong)過程序異常判斷和(he)設備(bei)時(shi)(shi)間校(xiao)準來解決，確保數據(ju)的(de)準確性(xing)。
新舊平臺切換、架構遷移及效果
解(jie)決(jue)了前面提(ti)到(dao)的(de)(de)(de)計(ji)算過程中異(yi)常的(de)(de)(de)問題后(hou)，我(wo)們(men)(men)(men)還(huan)需要考慮(lv)如何設計(ji)我(wo)們(men)(men)(men)的(de)(de)(de)底層(ceng)模型，以及在(zai)平臺改造完成后(hou)，如何進行(xing)線上切換(huan)。畢竟，我(wo)們(men)(men)(men)的(de)(de)(de)產品已經(jing)在(zai)線上運行(xing)了好幾年，要進行(xing)如此大(da)的(de)(de)(de)底層(ceng)更(geng)換(huan)，對我(wo)們(men)(men)(men)來說也是一個巨大(da)的(de)(de)(de)挑(tiao)戰。
為了應對這個挑戰，我們設計了一種動態切換的機制。我們將所有客戶和數據源通過灰度發布或者叫做開關策略進行切換。當某(mou)個(ge)企業需要走(zou)新(xin)流程時，我們(men)通(tong)過一個(ge)開關(guan)讓它的流量路由到新(xin)的平臺上。這樣我們(men)能夠(gou)在盡(jin)量減少對客(ke)戶影響的前提下，平穩(wen)完(wan)成平臺的切換。
然而，除(chu)了平臺切換(huan)，我們還面臨著一個更大的(de)(de)挑(tiao)戰，那就是歷史數據的(de)(de)遷移。我們這里面涉及到大量的(de)(de)歷史數據，主要有以下四個方面的(de)(de)難(nan)點：
不能影響老系統的線上查詢，且遷移成本需要可控
因(yin)為(wei)遷移時需要頻繁讀取舊的(de)指標(biao)數據，這會影(ying)響線上指標(biao)查詢的(de)響應時間。
歷史指標需要按企業維度遷移
指(zhi)標歷史結果數據模型(xing)不支持一(yi)次(ci)性讀(du)取(qu)所有企業的指(zhi)標實例，需轉化獲取(qu)指(zhi)標實例的 metric 值(zhi)。
遷移數據需個性化處理
歷史指標結果數據種類多且復雜，指標配置規(gui)則也(ye)十分多樣(yang)，導致每個(ge)數據遷移(yi)任務都需要個(ge)性(xing)化處理(li)。
遷移的歷史數據量巨大
我(wo)們要(yao)遷移的(de)數據(ju)量高達千億(yi)級(ji)別，僅指標數據(ju)就有約 2000 億(yi)條，測(ce)點數據(ju)更多。遷移的(de)時間范(fan)圍長，且指標實例(li)量巨(ju)大，需要(yao)在(zai)短時間內遷移千億(yi)級(ji)數據(ju)。
為了解決這些問題，我們采用了幾種方式。首先，我們開發了自定義的數據遷移工具。其次，我們對 OpenTSDB 的歷史數據進行了備份，再從備庫中提取數據寫入 TDengine。在實際操作中，可能我們寫入的方法不是很合理，一開始還遇到了寫入速度慢的問題。后來通過與 TDengine 的技術專家溝通，我們利用了 TDengine 的高性能寫入能力，一次可以寫入 50 萬條數據，耗時僅為 100 毫秒，這極大地提升了數據遷移的效率。
完成數據遷移(yi)后，整個平臺的遷移(yi)方案就相對完整了。去年，我們順利完成了大(da)約七(qi)八(ba)千個客戶以(yi)及所(suo)有相關數據的切(qie)換(huan)工作。
通過這次平臺升級，我們看到了顯著的效果。首先，及時性得到了大幅提升。對比(bi)以(yi)往，我們(men)的計算頻率(lv)(lv)最少提高(gao)了 4 倍，最高(gao)的時候，例如(ru)從年(nian)指標計算頻率(lv)(lv)兩(liang)天一次提高(gao)到每(mei)分鐘一次，時效性提高(gao)了 100 倍。計算時長方面，最少也提高(gao)了兩(liang)倍，最高(gao)提升了 8 倍。
其次，計算準確度有了很大提升。通過流式處理和層級加工的方式，我們的指標數據能夠前后一致地匹配，解決了無序數據帶來的準確性問題。同時，延遲數據的處理也更加智能化，可以自動計算延遲測點的數據，并遞歸修正受影響的所有指標。對于日、月、年指標計算頻率不一致的問題，我們也做了統一處理，現在所有計算頻率統一為 15 分鐘，并使用統一的時間窗口進行計算，確保數據的準確性。最終，客戶投訴率幾乎降為 0。
經驗分享
最后，想(xiang)跟大家分享一(yi)些我們在這個(ge)過程中總結出(chu)的經(jing)驗和建議(yi)：
- 如果項目中需要刪除數據，而TDengine 社區版不支持直接刪除數據。如果是單獨子表，那我們可以整個進行刪除操作，如果是子表內數據，那可以通過標識數據來實現刪除。
- 如果出現未來時間數據不能寫入或寫入報錯的問題，解決辦法是在建庫時關注兩個參數：一個是數據保留天數（keep），另一個是數據存儲時間跨度（days）。根據這兩個參數，TDengine 允許寫入數據的時間范圍是：從
now-keep到now+days。因此，如果要寫入的數據超出這個范圍，就會出現超出范圍的錯誤。在創建數據庫時，建議根據具體需求合理設置這兩個參數，確保數據可以在預期的時間范圍內寫入。 - 在項目中，如果遇到無法通過時間戳主鍵更新當前記錄的問題，通常是因為在建庫時， update 參數的默認值為 0，表示不支持更新操作。為了解決這個問題，需要根據項目需求調整該參數，例如將 update參數設置為 1，以支持整行更新。在當前項目中，將 update參數設為1即可實現按時間戳主鍵更新記錄的需求。
結合(he)前(qian)面(mian)的注意事項，在日(ri)常項目中(zhong)引用或(huo)評估使用 TDengine 時，我(wo)們需要從(cong)多個維度考慮(lv)相(xiang)關參(can)數(shu)。接下來，我(wo)會(hui)為大家(jia)詳(xiang)細講(jiang)解這些維度和所需考慮(lv)的具體(ti)因素，并附上一(yi)個匯總表格供大家(jia)參(can)考。
項目基礎信息的輸入
首先，我們需要輸入(ru)與項(xiang)目相關的(de)基本(ben)信(xin)息(xi)。這些(xie)(xie)信(xin)息(xi)包括未來需要監控或管理的(de)設(she)備數(shu)(shu)量(liang)、設(she)備參數(shu)(shu)以(yi)及測點(dian)的(de)數(shu)(shu)量(liang)。如果項(xiang)目中涉及指標(biao)計(ji)算或存儲相關的(de)需求，這些(xie)(xie)也需要作為輸入(ru)項(xiang)加以(yi)考慮。
磁盤評估
在進行項目(mu)評估時，磁盤(pan)容量(liang)是(shi)我們需(xu)要優先考(kao)慮的(de)(de)因(yin)素(su)之一。根據(ju)(ju)設備(bei)數量(liang)、數據(ju)(ju)采集頻率和(he)(he)存儲時長等(deng)因(yin)素(su)，磁盤(pan)容量(liang)需(xu)求將直接(jie)影響(xiang)項目(mu)的(de)(de)實施效(xiao)果(guo)。因(yin)此，我們需(xu)要對磁盤(pan)進行合理的(de)(de)配置，以確保數據(ju)(ju)的(de)(de)存儲和(he)(he)查詢(xun)性(xing)能。
內存評估
內存方(fang)面，我(wo)們需要關(guan)注幾個關(guan)鍵因素(su)：
- 節點數量和虛擬分組（vgroups）數量：根據 TDengine 的架構原理，節點數量和 vgroups 的配置對系統的性能和穩定性起到至關重要的作用。
- 副本（Replica）：這是數據庫的備份機制，對于任何企業來說，數據的高可用性和存儲安全性至關重要。因此，副本數量的設置應與具體項目需求緊密結合。
緩存配置
緩存(cun)(cun)設置也是影響系統性能的重(zhong)要因(yin)素。在數(shu)據(ju)查詢(xun)或存(cun)(cun)儲時，我(wo)們需(xu)要為(wei)系統預留足(zu)夠的緩存(cun)(cun)空間(jian)，以提高數(shu)據(ju)查詢(xun)速度和數(shu)據(ju)讀(du)取效率。具體配置項包括 buffer、pages、pagesize、cachesize 等參(can)數(shu)。這(zhe)些(xie)參(can)數(shu)的設定應(ying)結(jie)合實際(ji)項目需(xu)求和數(shu)據(ju)量進行評(ping)估。
CPU 評估
最(zui)后(hou)，CPU 的性能評估主要涉及(ji)數據(ju)查詢(xun)和(he)計(ji)算的負(fu)載。根據(ju)數據(ju)量的大小、查詢(xun)頻(pin)率以及(ji)計(ji)算需求，合理(li)配置 CPU 資源能夠確保(bao)系統高效運行。針對不同項(xiang)目的實際情況，CPU 的需求也會有所差異，因此需要進行更(geng)詳細(xi)的思考和(he)規劃(hua)。
以上就是(shi)我們平臺(tai)改造(zao)過程中(zhong)的(de)一些重要節(jie)點和(he)解決(jue)方(fang)案，結合這些經(jing)驗和(he)注意事項，希(xi)望能為大家在類似項目中(zhong)提供一些參(can)考(kao)。
結語
回顧我(wo)(wo)(wo)們(men)使(shi)用(yong) TDengine 的(de)(de)(de)這段歷程，不(bu)禁感慨萬分(fen)。從最(zui)初的(de)(de)(de)選(xuan)擇 OpenTSDB，到(dao)我(wo)(wo)(wo)們(men)面(mian)臨種(zhong)種(zhong)挑戰(zhan)，決(jue)定進(jin)行新(xin)一(yi)輪的(de)(de)(de)數據庫選(xuan)型，這一(yi)路走來充滿了思(si)考與抉擇。2018 年到(dao) 2022 年，OpenTSDB 在我(wo)(wo)(wo)們(men)私有化場景中的(de)(de)(de)表現曾一(yi)度支撐(cheng)著我(wo)(wo)(wo)們(men)的(de)(de)(de)系統，但隨著業務的(de)(de)(de)不(bu)斷擴展(zhan)，問題(ti)也接踵而至(zhi)——高昂的(de)(de)(de)部署成本、復雜(za)的(de)(de)(de)運維難題(ti)，讓我(wo)(wo)(wo)們(men)不(bu)得(de)不(bu)尋(xun)求新(xin)的(de)(de)(de)解決(jue)方(fang)案。
正是在(zai)這個關鍵時(shi)刻，TDengine 走入(ru)了(le)我(wo)(wo)(wo)們(men)(men)的(de)(de)視野。初次接觸 TDengine 時(shi)，我(wo)(wo)(wo)們(men)(men)帶著(zhu)試探的(de)(de)心(xin)態，先(xian)在(zai)私有化場景(jing)中做了(le)嘗試。出乎意(yi)料的(de)(de)是，它不僅幫助我(wo)(wo)(wo)們(men)(men)降低了(le)部署和運維成(cheng)本，還讓(rang)我(wo)(wo)(wo)們(men)(men)對未來充滿了(le)信心(xin)。于是，2023 年 6 月，我(wo)(wo)(wo)們(men)(men)正式(shi)啟(qi)動(dong)了(le)平臺(tai)的(de)(de)全(quan)面(mian)切換，將 TDengine 應用(yong)到核心(xin)生(sheng)產(chan)環(huan)境(jing)。
當(dang)然，任何(he)技術(shu)變革(ge)的路上從不(bu)都是一帆風順。我(wo)們也曾在 TDengine 2.6 版(ban)本(ben)時遇到過(guo)一些(xie)小問題(ti)，但通過(guo)與 TDengine 的技術(shu)專家(jia)密切合作(zuo)，我(wo)們共同修(xiu)復了這些(xie) bug。隨(sui)著系統(tong)逐步升級到 3.0 版(ban)本(ben)，我(wo)們在不(bu)斷優化的過(guo)程中，也看到了 TDengine 帶給(gei)我(wo)們的穩(wen)定性(xing)和(he)效率提升。終于，在 2023 年 11 月(yue)，我(wo)們的整個(ge)平臺穩(wen)定運行，所有的努(nu)力和(he)嘗(chang)試都獲得了回報(bao)。
從 18 年初次啟程到(dao)(dao)如今(jin)，我們(men)(men)不(bu)僅(jin)見證了 TDengine 的(de)(de)發展，也(ye)見證了自己系統(tong)的(de)(de)蛻變。這一路的(de)(de)技術革新不(bu)僅(jin)僅(jin)是架構(gou)的(de)(de)演進，更是我們(men)(men)對(dui)未(wei)來(lai)的(de)(de)信心(xin)所(suo)在。正(zheng)是因為有了這些經歷和突破，我們(men)(men)相信，未(wei)來(lai)無論(lun)遇到(dao)(dao)什么樣(yang)的(de)(de)挑(tiao)戰，我們(men)(men)都有足夠的(de)(de)底氣去迎(ying)接。而 TDengine，已成為我們(men)(men)堅(jian)定的(de)(de)同行(xing)者。
