2024 年 7 月 26 日，我司（廣州燧創信息技術有限公司）派我赴北京參與了由 TDengine 官方舉辦的用戶大會，在創始人陶建輝的精彩演講中，他給觀眾們展示了時序數據對于人工智能的巨大價值，并且發布了用于時序數據預測的人工智能分析工具 TDgpt。這(zhe)次(ci)大會令我(wo)眼前一亮(liang)，作為我(wo)司(si)的(de)人工(gong)智(zhi)能部門負責人，我(wo)早已帶領團隊把 TDengine 和人工(gong)智(zhi)能結合在一起(qi)了，今(jin)天(tian)把這(zhe)些經(jing)驗分享出來供大家(jia)參考。

作者的話

內容摘要

1. 該電芯容量預測系統主要利用機器學習為電池生產廠商提供服務。
2. 該電芯容量預測系統采用了 TDengine 和自研算法代替了傳統數據庫 + 矢量數據庫。
3. 在 TDengine 的協助下，該電池容量預測系統可幫助用戶節省約超過 6000 萬 RMB 的硬件、場地、人力等成本以及大量的時間成本。

在鋰離子(zi)電(dian)池生產工藝中，電(dian)池的(de)容量（Capacity）數(shu)據，是出廠前評價單(dan)體鋰離子(zi)電(dian)池質(zhi)量好壞的(de)一個重(zhong)要指標。廠家會將鋰離子(zi)電(dian)池根據不(bu)同(tong)的(de)容量等級進行分檔(dang)，相同(tong)檔(dang)位的(de)電(dian)芯會配組成(cheng)為電(dian)池包（Pack），以獲取更好的(de)穩定性和(he)壽命。

目(mu)前(qian)常(chang)用的(de)(de)(de)(de)獲得(de)鋰離子(zi)電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)容(rong)(rong)量(liang)數據(ju)的(de)(de)(de)(de)方(fang)法是(shi)(shi)：通過(guo)(guo)(guo)(guo)充(chong)放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)設備，先對鋰離子(zi)電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)進(jin)行完(wan)全充(chong)電(dian)(dian)(dian)(dian)(dian)(dian)，然后(hou)進(jin)行多組(zu)階(jie)梯式的(de)(de)(de)(de)電(dian)(dian)(dian)(dian)(dian)(dian)流放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)，即讓電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)完(wan)全放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)，最終將每個(ge)放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)工(gong)步(bu)的(de)(de)(de)(de)總(zong)容(rong)(rong)量(liang)疊(die)加(jia)，作為(wei)電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)的(de)(de)(de)(de)出(chu)廠容(rong)(rong)量(liang)。該(gai)過(guo)(guo)(guo)(guo)程(cheng)稱為(wei)分容(rong)(rong)（Grading）。 該(gai)方(fang)法的(de)(de)(de)(de)缺(que)點(dian)是(shi)(shi)，整個(ge)充(chong)放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)過(guo)(guo)(guo)(guo)程(cheng)極(ji)度(du)耗(hao)時(shi)(shi)耗(hao)能(neng)，以(yi)標(biao)準容(rong)(rong)量(liang)為(wei) 3200 mAH 的(de)(de)(de)(de) 18650 電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)舉例，整個(ge)充(chong)放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)過(guo)(guo)(guo)(guo)程(cheng)會持續 4~5 小(xiao)時(shi)(shi)，其(qi)中每個(ge)充(chong)放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)階(jie)段都會消耗(hao)非常(chang)多的(de)(de)(de)(de)電(dian)(dian)(dian)(dian)(dian)(dian)能(neng)。此外，在分容(rong)(rong)之(zhi)前(qian)，還有(you)一(yi)(yi)個(ge)必需(xu)的(de)(de)(de)(de)化(hua)成(cheng)(cheng)（Formation）工(gong)序。鋰離子(zi)電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)在灌(guan)輸(shu)電(dian)(dian)(dian)(dian)(dian)(dian)解液并(bing)封口后(hou)，其(qi)物理(li)結構基本組(zu)裝完(wan)成(cheng)(cheng)。為(wei)使電(dian)(dian)(dian)(dian)(dian)(dian)極(ji)充(chong)分被電(dian)(dian)(dian)(dian)(dian)(dian)解液浸潤從而全面活(huo)化(hua)，需(xu)要經過(guo)(guo)(guo)(guo)一(yi)(yi)個(ge)以(yi)多個(ge)恒(heng)壓充(chong)電(dian)(dian)(dian)(dian)(dian)(dian)——放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)循環為(wei)主要步(bu)驟的(de)(de)(de)(de)激活(huo)過(guo)(guo)(guo)(guo)程(cheng)，最終使電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)具(ju)有(you)放(fang)電(dian)(dian)(dian)(dian)(dian)(dian)能(neng)力，這一(yi)(yi)電(dian)(dian)(dian)(dian)(dian)(dian)化(hua)學過(guo)(guo)(guo)(guo)程(cheng)即為(wei)化(hua)成(cheng)(cheng)工(gong)序。化(hua)成(cheng)(cheng)完(wan)成(cheng)(cheng)后(hou)，一(yi)(yi)般(ban)電(dian)(dian)(dian)(dian)(dian)(dian)池(chi)會經過(guo)(guo)(guo)(guo)至少一(yi)(yi)日的(de)(de)(de)(de)常(chang)溫(wen)(wen)靜置/高溫(wen)(wen)老化(hua)時(shi)(shi)間，待(dai)其(qi)化(hua)學性質(zhi)趨于(yu)穩定(ding)，再通過(guo)(guo)(guo)(guo)分容(rong)(rong)檢測容(rong)(rong)量(liang)，這一(yi)(yi)過(guo)(guo)(guo)(guo)程(cheng)會耗(hao)費相當大的(de)(de)(de)(de)成(cheng)(cheng)本：

• 靜置和分容均耗費了很多時間。
• 分容時的多個充放電步驟非常耗電。
• 大量分容設備體積巨大，不僅占地面積大，也為堆垛機和物流線等實施增加困難。

但實際上，截至化(hua)成(cheng)（Formation）完(wan)成(cheng)的(de)(de)時候，電池本(ben)身的(de)(de)理化(hua)性(xing)質已基本(ben)確定，且會反映(ying)在（化(hua)成(cheng)期(qi)間的(de)(de)）充放電曲線內，并(bing)與前中段(duan)線生產的(de)(de)數(shu)據記(ji)錄高度(du)相關(guan)。

由(you)此，電芯容量預測系統 kun 應運而生，在 kun 的助力下，絕大(da)多數（70%-90%）的電池容量直接通過 kun 便可以計算預測獲得，它具備(bei)如下優(you)勢：

• 分容設備被大量取締，建廠時用地、資金等成本被大幅壓縮。
• 省略分容充放電步驟，節約大量電能。
• 節省了靜置和分容時間，變相大大提高了產能。
• 整線體系簡化，降低了分容設備故障導致的停產概率和設備維修期間造成的各種費用。

經濟收益

目(mu)前，該項目(mu)于 2022 年 11 月上(shang)線，已(yi)經(jing)正常生產近兩年時間，平均每(mei)月出(chu)貨率為產能(neng)的 85%，前期調試和工藝磨(mo)合周期為 2 個月。

在我們與客戶(hu)、TDengine 團隊兩個月的(de)共同努(nu)力(li)下，產線(xian)落實了工藝和制(zhi)程一致性的(de)規范，確保容量預(yu)測介入的(de)生產整(zheng)體在較穩定的(de)環境(jing)下進行，降低了 NG 率的(de)同時提高了預(yu)測精度。

每天容(rong)量預(yu)測(ce)(ce)系(xi)統為產線完(wan)成大量電芯的容(rong)量預(yu)測(ce)(ce)結果(guo)。其平均誤差保持(chi)在 0.37%，預(yu)測(ce)(ce)判別 NG 率為 5.7%。

目前容量預測系統完全達到客戶要(yao)求(qiu)，第一年(nian)成功為客戶節(jie)約了超過(guo) 5600 萬(wan)(wan) RMB 的(de)經濟價值，并完成了全局驗(yan)收，第二年(nian)所(suo)節(jie)約的(de)成本將超過(guo) 6000 萬(wan)(wan) RMB。

TDengine 選型背景

在我們的項目中(zhong)，TDengine 起到了相(xiang)當(dang)大的作用。

2021 年底，我們的系統（kun）已經基本完成，后端數據庫使用了 MariaDB 作為數據持久化的方案。但當我用大量的模擬數據進行交付測試時，遭遇了一個性能瓶頸問題：由于 MariaDB 是單表存儲的模型，當數據量達到一定的規模時，按時間查詢太慢了。
盡管我們系統的(de)主要(yao)功(gong)能(neng)是利(li)用機器學習提供(gong)服務，但(dan)車(che)間(jian)現場電(dian)芯的(de)生產(chan)數據（生產(chan)時間(jian)、條碼、經轉的(de)設備號(hao)和(he)通(tong)道(dao)號(hao)等）均需要(yao)記錄在(zai)案。

這(zhe)些“流水(shui)賬”有什(shen)么用呢(ni)？我(wo)們的(de)(de)(de)甲方（電池廠）要對客戶（比如(ru)電動(dong)轎車廠）負責，質量(liang)(liang)上肯定是要精(jing)益(yi)求(qiu)精(jing)的(de)(de)(de)。因此，如(ru)果(guo)某(mou)(mou)些電芯(xin)預測(ce)(ce)出(chu)的(de)(de)(de)容(rong)量(liang)(liang)偏離了正常分布（如(ru)果(guo)只有系統誤差，一般可以看做(zuo)這(zhe)類數據符合正態(tai)分布），就需要及時(shi)回(hui)溯上述(shu)數據以便快(kuai)速定位產線上的(de)(de)(de)問題，進而(er)及時(shi)糾錯，恢復電芯(xin)容(rong)量(liang)(liang)的(de)(de)(de)精(jing)度。舉個(ge)例(li)子，某(mou)(mou)化成設備在某(mou)(mou)個(ge)位點上的(de)(de)(de)夾(jia)具溫度傳感器出(chu)了故障，測(ce)(ce)量(liang)(liang)的(de)(de)(de)溫度不準確，這(zhe)里涉(she)及到(dao)幾(ji)個(ge)問題：

1.哪(na)個設備上的夾具(ju)溫度偏離(li)了正(zheng)常分布(bu)？

2.具(ju)體是(shi)該設備上的哪個充放電位點？

3.該位點是從什么時間開始出現故障的？
為保障生產，當故(gu)障出(chu)現(xian)時，工廠都是希(xi)望第一時間定位(wei)和解決(jue)問(wen)題的(de)。一般的(de)做法是，快(kuai)速查詢出(chu)可能出(chu)現(xian)問(wen)題的(de)時段的(de)數據(ju)，再進行分析(xi)。

使(shi)用 MariaDB，當單(dan)表數據(ju)量達(da)到一(yi)定規模時(shi)，查(cha)詢性能會急劇下降，對于難以(yi)索引的(de)時(shi)間字段更(geng)加如此。如果(guo)一(yi)定要繼(ji)續使(shi)用 MariaDB 作為(wei)數據(ju)持(chi)久化的(de)方案，則需要在寫入時(shi)就在應用層代碼中建立復雜的(de)分片分區邏輯，以(yi)便未來在查(cha)詢時(shi)快速定位到具體的(de)數據(ju)。

更(geng)進一步地，我們也希望數(shu)據(ju)庫有強大的對新寫(xie)入數(shu)據(ju)的即時計算的能力，這(zhe)樣就可以(yi)及(ji)時上(shang)報錯(cuo)誤，要比人為(wei)發現問題后再去反查更(geng)為(wei)安全便捷(jie)。

帶著(zhu)需求，我(wo)開始重新考慮數據(ju)庫選型(xing)的問題(ti)。在(zai)開源(yuan)社(she)區(qu)搜索時，偶然間(jian)發現 TDengine 這個(ge)產(chan)品(pin)，帶著(zhu)好奇心看完了(le)它的主(zhu)要(yao)特性之后，我(wo)們(men)認定，TDengine 與 kun 是天作之合：

可以看(kan)到，TDengine 的(de)(de)(de)特性與我們的(de)(de)(de)需求是非常匹配的(de)(de)(de)。而且我相(xiang)信，它解決了(le)許(xu)多工業場景(jing)的(de)(de)(de)痛(tong)點(dian)，在這一領域的(de)(de)(de)許(xu)多開發者深(shen)入(ru)了(le)解它之后，都會有(you)“相(xiang)見恨(hen)晚”的(de)(de)(de)感覺。

運行環境

作(zuo)為一款(kuan)時序數(shu)(shu)據庫產(chan)品，TDengine 對硬件(jian)的(de)要求非常友好(hao)。得益于它優異的(de)數(shu)(shu)據壓縮比率，我們在生(sheng)產(chan)環境的(de)硬件(jian)配(pei)置一降再(zai)降，完(wan)成了此前(qian)無法完(wan)成的(de)工作(zuo)——硬件(jian)成本(ben)縮減了一倍以上，做(zuo)到了真正意義的(de)“降本(ben)增效”。

三臺機架式服務器：

TDengine 版本: 3.2.3.0，三副本模式。

自研算法 + TDengine 代替矢量數據庫

為(wei)了保障(zhang)預測容量的(de)精度，我們(men)采用(yong)了持續機器學習(xi)（continuous machine learning）的(de)設計：通(tong)過(guo)這種機制，我們(men)得(de)以以全自動的(de)方式(shi)始(shi)終(zhong)保持模型的(de)行(xing)為(wei)和最(zui)新的(de)生產狀況(kuang)保持一致。

前文提及，為了節約設備(bei)(bei)和(he)空間成本，廠(chang)家往(wang)往(wang)只會采購原生(sheng)產(chan)所需的分容(rong)設備(bei)(bei)的 10%~30%。但這樣小(xiao)規模的分容(rong)設備(bei)(bei)產(chan)生(sheng)的可用于模型訓練(lian)的全(quan)流程數據非(fei)常少，這也導致在前期機器學習無(wu)法正(zheng)常工作。

但是(shi)，通過(guo)自(zi)研的曲線(xian)搜(sou)索(suo)算法，我(wo)們成(cheng)功解決了這個問(wen)題，從而保證了甲方的出(chu)(chu)貨效率(lv)，具體方案是(shi)：經過(guo)過(guo)濾的全流(liu)程(cheng)數據(ju)被收進數據(ju)庫，當(dang)有新電芯待(dai)預測容量時，通過(guo)曲線(xian)搜(sou)索(suo)算法從中檢索(suo)出(chu)(chu)相似的曲線(xian)，進而歸納得到預測容量。

相信熟(shu)悉矢量數據(ju)庫(ku)（vector database）產品的工程師(shi)都會感到非常熟(shu)悉：這不是矢量數據(ju)庫(ku)的常見功能嗎。

矢量數據庫往(wang)往(wang)原生(sheng)支持一些基(ji)于聚類（比如(ru)根據距離）的搜索算法，常見(jian)的有 k-NN (k-nearest Neighbor)、HNSW (Hierarchical Navigable Small World)或者 IVF (Inverted File Index)等。

但如果(guo)在我(wo)們的系統中額(e)外集成(cheng)一(yi)種矢量數據庫(ku)，不僅運(yun)維成(cheng)本(ben)提(ti)升了(le)(le)，也為程序員們引入(ru)了(le)(le)額(e)外的心智負擔。

幸運(yun)的(de)是(shi)，TDengine 本(ben)身提供的(de)聚合函數、流(liu)式計(ji)算(suan)等(deng)特性，配合其靈(ling)活的(de)自定(ding)義(yi)函數（User-defined Function, UDF），使(shi)得我們有(you)機會(hui)在(zai)寫入(ru)全(quan)流(liu)程數據的(de)同時就高(gao)效地進行一系列(lie)復雜(za)的(de)預處理，為快速(su)搜索近似曲線(xian)提供了可能。

使(shi)用(yong)矢量數據(ju)庫還有(you)一個不便之處，就是電芯(xin)復雜的(de)(de)(de)(de)元數據(ju)（metadata）無(wu)法(fa)直接與計算用(yong)的(de)(de)(de)(de)特征值（features）建立(li)綁定關(guan)系(xi)。在調研選型階(jie)段(duan)，我們(men)就留意到(dao)，除了(le)(le)上文(wen)提到(dao)的(de)(de)(de)(de)優(you)秀特性，TDengine 還提供了(le)(le)標準的(de)(de)(de)(de) SQL 語(yu)法(fa)，也有(you)和關(guan)系(xi)型數據(ju)庫相似(si)的(de)(de)(de)(de)關(guan)聯查(cha)詢(xun)用(yong)法(fa)，使(shi)程序(xu)員(yuan)可以(yi)以(yi)很(hen)小的(de)(de)(de)(de)學習代價(jia)來(lai)(lai)記錄和利用(yong)字(zi)段(duan)間(jian)的(de)(de)(de)(de)關(guan)聯性，開發(fa)更簡單；TDengine 的(de)(de)(de)(de) Rust 連(lian)接器(qi)還提供了(le)(le)參數綁定這(zhe)種更高效的(de)(de)(de)(de)寫入方式，當客(ke)戶端(duan)有(you)數據(ju)發(fa)送過(guo)來(lai)(lai)時(shi)，我們(men)可以(yi)處理(li)后(hou)快(kuai)速寫入；后(hou)續如果用(yong)戶需要將計算結果與元數據(ju)結合在一起分析（詳見生產異(yi)常預警小節），一次查(cha)詢(xun)就可以(yi)獲取(qu)所需的(de)(de)(de)(de)全(quan)部信息，這(zhe)樣的(de)(de)(de)(de)數據(ju)建模極(ji)大地提升了(le)(le)運行時(shi)效率。

可以看出，TDengine 在一整條數據鏈路的(de)各個環(huan)節都為開發(fa)者提供了相當大的(de)便利(li)。

TDengine Rust 連接器錦上添花

熟悉深度(du)學習的朋友們都知道，為了使模型(xing)的參數得到盡量利用以提高其泛化性，理應(ying)在每個 epoch 中將(jiang)整個數據集按批次（batch）喂給模型(xing)學習。

上文提到(dao)，經過(guo)預(yu)處理的 features 也通過(guo) TDengine 持(chi)久化。但數據量達到(dao)一定規模后，簡單地將整個(ge)數據集(ji)從數據庫(ku)中一次(ci)取(qu)出(chu)用于訓練是不可取(qu)的，會有(you)嚴重的性能問題甚至引起 OOM（Out Of Memory，內存(cun)不足）中斷。

由于要(yao)將當前 batch 的數據(ju)實時從數據(ju)庫取出加(jia)入訓(xun)練，直觀上(shang)可(ke)能操作起來會有一(yi)些技(ji)術問題。

所幸，TDengine 的開發團隊對社區的支持非常友好。kun 是完全基于 Rust 語言開發的，我們早期在調研時就注意到，TDengine 也為 Rust 實現了連接器，其中有兩個亮點：
1.同(tong)(tong)時支持同(tong)(tong)步/異步上下(xia)文(wen)。2.借由 FFI（Foreign Function Interface，外部語(yu)言接(jie)口）實現了 Rust 與 C 語(yu)言的 primitive 數據類型的無縫對(dui)接(jie)。

一(yi)般來講，由于網絡(luo)傳輸及數據(ju)(ju)查(cha)詢均需要一(yi)定的(de)(de)時間，因此(ci)建議在異步上下文中與(yu)(yu)數據(ju)(ju)庫(ku)進(jin)行(xing)交(jiao)互(hu)。但(dan)考慮(lv)到(dao)訓練模(mo)型是(shi) CPU 密集型的(de)(de)計算任務，我們將其(qi)置于 rayon 開(kai)啟的(de)(de)線程池中運行(xing)。此(ci)時如(ru)果有(you)數據(ju)(ju)需要與(yu)(yu)數據(ju)(ju)庫(ku)交(jiao)互(hu)，理(li)論上可以通(tong)過(guo)消息通(tong)道機制將消息傳出實時寫(xie)入數據(ju)(ju)庫(ku)，但(dan)也有(you)些(xie)場(chang)景不要求(qiu)并發（比(bi)如(ru)一(yi)次性地(di)查(cha)詢某些(xie)數據(ju)(ju)），此(ci)時連接(jie)器(qi)支持(chi)同步上下文就顯得(de)尤為方便。

高效的數據可視化

電芯分(fen)檔的(de)(de)“金(jin)標準”是容量值。因此，生產監督人員往往非常關注預測得到的(de)(de)容量值的(de)(de)分(fen)布。隨(sui)著產量的(de)(de)累(lei)積，單個批次可能在(zai)一(yi)段(duan)時間(jian)內生產的(de)(de)電芯數(shu)(shu)目非常多，如(ru)果(guo)按照傳統做法從數(shu)(shu)據庫查出(chu)全部的(de)(de)數(shu)(shu)據，再在(zai)應用層匯總計算，如(ru)此大量的(de)(de)數(shu)(shu)據傳輸(shu)會(hui)使前端(duan)經(jing)歷相(xiang)當(dang)久的(de)(de)延遲才能繪制出(chu)統計圖表(biao)，破壞了用戶(hu)體驗。

好(hao)消息是，通(tong)過 TDengine 的(de)窗口切分查詢(xun)和(he)聚合函數可(ke)以很(hen)方便實現(xian)這種直方圖(tu)匯總，在(zai)數據庫層直接完成計算后返回結果：

let capacity_histogram_data: Vec<CapacityIntervalHistogram> = taos
    .query(format!(
        "SELECT histogram(capacity,'linear_bin','{}',0) as capacity_rang
    FROM inference.`{}`  WHERE ts > (NOW - {}d)   ;",
        serde_json::json!({
            "start":    min_capacity as i32,
            "width":    (max_capacity as i32 / total_capacity_intervals),
            "count":    total_capacity_intervals,
            "infinity": false
        }),
        table_name,
        ts_n_days
    ))
    .await?
    .deserialize()
    .try_collect()
    .await?;

 在前端就(jiu)可以直接利用返回值繪(hui)圖了：

生產異常預警

現(xian)(xian)代(dai)電池(chi)廠多(duo)采用全自(zi)動產(chan)線(xian)，但受制(zhi)(zhi)于(yu)設備(bei)和軟件等因(yin)素(su)，產(chan)線(xian)往(wang)往(wang)缺乏即時的(de)反饋能(neng)力。因(yin)此，為了(le)保障出貨速度(du)和質量，廠家的(de)生產(chan)監督人(ren)員（比(bi)如工(gong)藝員和技(ji)術員等）有一(yi)項重要而(er)繁瑣的(de)工(gong)作：以一(yi)定間隔（比(bi)如 4~6 小時）收集數(shu)據(ju)并(bing)制(zhi)(zhi)作報表分(fen)析，以便(bian)及(ji)時發現(xian)(xian)異常數(shu)據(ju)，再定位到(dao)異常的(de)工(gong)序甚至(zhi)設備(bei)，進而(er)糾錯或修(xiu)理。

這樣的工作方式主要有兩個弊端：
1.間隔太(tai)久，生(sheng)產異常難以第一時間被發現和處理。2.工(gong)作內容(rong)重(zhong)復(fu)、工(gong)作量太(tai)大。

那么有(you)(you)沒有(you)(you)一種全(quan)自動(dong)的(de)(de)方式(shi)來(lai)糾錯和(he)(he)預警呢？當然有(you)(you)。我們可以部(bu)署一個計(ji)劃(hua)任務，每隔一段(duan)時間就(jiu)查詢所(suo)有(you)(you)的(de)(de)關鍵數據（比如上柜電壓(ya)、某(mou)時刻(ke)的(de)(de)夾具溫度等）的(de)(de)數值特征（比如均值相對于總體的(de)(de)偏離程度等），再在(zai)應用(yong)層進行分析。同樣地，這種做法有(you)(you)和(he)(he)上文(wen)類(lei)似的(de)(de)問題，數據庫(ku)發送回(hui)查詢結(jie)果時大量的(de)(de)數據傳輸和(he)(he)應用(yong)層做計(ji)算時的(de)(de)高 CPU 負(fu)載可能使生產環境苦(ku)不堪言(yan)。這樣的(de)(de)性(xing)能開銷(xiao)也意味(wei)著(zhu)這類(lei)型的(de)(de)任務無(wu)法經常(chang)執行。

在(zai)工業 4.0 的(de)概念(nian)中(zhong)，其中(zhong)一部分(fen)目標就是建立(li)具(ju)有(you)自(zi)適(shi)應性的(de)智能制造(zao)工廠。為向這一驚艷(yan)的(de)概念(nian)致敬(jing)，我(wo)們計(ji)(ji)劃(hua)在(zai)下個(ge)版本中(zhong)通(tong)過(guo) TDengine 的(de)流(liu)式(shi)計(ji)(ji)算特性來實時對上述關鍵數據進行分(fen)析。

由于這些數值特征在數據寫入時就(jiu)已(yi)經(jing)以(yi)極小(xiao)的(de)代(dai)價計算(suan)完畢(bi)，需要匯總(zong)時按需查(cha)詢、呈現結果就(jiu)變得異常容易和高(gao)效。這樣的(de)做法(fa)將計算(suan)的(de)負載均勻分(fen)攤在程序運(yun)行(xing)的(de)整個生(sheng)命周期中，是極佳的(de)“削峰填谷(gu)”思想(xiang)的(de)實踐。

以上，便(bian)是(shi)我們使(shi)用 TDengine 前(qian)前(qian)后(hou)后(hou)的(de)一(yi)切，特此整理(li)分享出來。（耐心讀到最后(hou)的(de)讀者，有可(ke)能會對 kun 這個單詞感到一(yi)絲(si)熟悉——沒錯，這個系統的(de)負(fu)責人/這篇文章(zhang)的(de)核心作者正是(shi)一(yi)個 xiao hei zi，如(ru)果你想結識“志同道合”的(de)他(ta)，歡迎留言）

關于廣州燧創信息技術有限公司

自 2016 年起，燧(sui)創(chuang)就站在工業(ye)自動(dong)化(hua)的(de)(de)前沿。通過與跨行業(ye)精(jing)英(ying)的(de)(de)緊(jin)密合作，將互聯(lian)網(wang)的(de)(de)靈活性、工業(ye)控制(zhi)的(de)(de)精(jing)確(que)性和信(xin)息(xi)化(hua)的(de)(de)深度(du)知識融為(wei)一體。伴隨多個海內(nei)外大型項(xiang)目陸續落地，燧(sui)創(chuang)信(xin)息(xi)更加堅定了為(wei)全(quan)球客戶帶來高(gao)質量自動(dong)化(hua)軟件服務(wu)的(de)(de)承諾（）