作者：曲春輝，負責工業數字化平(ping)臺(tai)架構
小T導讀：作為全球性的(de)(de)電氣產品和服務(wu)經銷(xiao)商(shang)，藍(lan)格賽于(yu)2000年(nian)進(jin)駐中(zhong)國(guo)(guo)市場(chang)，一(yi)直致力于(yu)幫(bang)助中(zhong)國(guo)(guo)更(geng)有效地使用能源。經過(guo)20年(nian)的(de)(de)不斷壯(zhuang)大，如今(jin)藍(lan)格賽在中(zhong)國(guo)(guo)國(guo)(guo)內電氣產品和服務(wu)經銷(xiao)商(shang)中(zhong)已經成為重要(yao)的(de)(de)市場(chang)參與者之一(yi)，通過(guo)6家(jia)業務(wu)實體、全國(guo)(guo)53個銷(xiao)售網點服務(wu)工(gong)業、商(shang)業及(ji)樓宇客(ke)戶，為它(ta)們提供多樣化(hua)的(de)(de)工(gong)業自動化(hua)產品及(ji)解決方(fang)案。
本(ben)次項目(mu)為(wei)某(mou)市政供(gong)水(shui)(shui)水(shui)(shui)廠的(de)(de)(de)數(shu)字化項目(mu)，數(shu)據來源于包括水(shui)(shui)泵、閥門、電表、液(ye)位(wei)計、流(liu)量計等(deng)多種設備近(jin)6000測點。該平(ping)臺需要實(shi)現(xian)(xian)以下(xia)功能：數(shu)據秒級采集，歷史數(shu)據留存3年，為(wei)上層(ceng)應用(yong)提供(gong)數(shu)據支(zhi)撐，包括所有(you)測點的(de)(de)(de)瞬時數(shu)據、聚(ju)合(he)(he)分析、數(shu)據報表等(deng)。值得注意的(de)(de)(de)是(shi)，在本(ben)項目(mu)中(zhong)聚(ju)合(he)(he)查(cha)詢的(de)(de)(de)使用(yong)場景非常的(de)(de)(de)多，頁面上圖表不(bu)論(lun)大(da)小(xiao)有(you)上百張之多，因此聚(ju)合(he)(he)查(cha)詢的(de)(de)(de)實(shi)現(xian)(xian)也是(shi)本(ben)項目(mu)的(de)(de)(de)關(guan)鍵之處。
根據本(ben)項目(mu)特點，從(cong)整(zheng)體(ti)架構(gou)的(de)(de)具體(ti)實現效果出(chu)發，我們對(dui)(dui)存儲技術提出(chu)了(le)很(hen)高的(de)(de)要求，甚至可以說，存儲技術的(de)(de)選(xuan)(xuan)擇會直接影響項目(mu)后(hou)續的(de)(de)推進乃至成敗，這是一個決定(ding)平(ping)臺“脊梁”硬不硬的(de)(de)組(zu)件。考慮到(dao)這一問題，團隊在技術選(xuan)(xuan)型上著實花費(fei)了(le)一些功夫，本(ben)次(ci)選(xuan)(xuan)型也相(xiang)對(dui)(dui)更加慎(shen)重。
在選型過程中我們共調研了20多個開源存儲技術，從開源組織、授權協議、數據模型、社區成熟度、開發語言、組件依賴、性能、穩定性、聚合友好、操作系統、集群支撐、副本策略等多個角度進行了對比，最終選擇了TDengine Database作為海量數據存儲引擎。
從7個優點看選擇TDengine Database的原因
事實上，我(wo)們(men)最初選擇的是單純以(yi)InfluxDB作為本次項目的核心存(cun)儲(chu)組(zu)件，不過這一設想在(zai)進(jin)行技(ji)術(shu)驗證時(shi)卻(que)發現難以(yi)繼(ji)續(xu)推進(jin)。 主要原因(yin)是在(zai)技(ji)術(shu)驗證的過程中(zhong)，我(wo)們(men)發現了InfluxDB存(cun)在(zai)的幾個(ge)問題，其中(zhong)最重要的兩個(ge)是：
- 首先，社區版本僅支持單節點。這個可以說是InfluxDB非常不友好的一個點了，多數項目采用的都是集群設計方案，如果數據只能在其中一個節點上存儲，浪費其他節點存儲空間不說，一旦所在節點出現故障，對整個項目的影響是災難級的。
- 其次，隨著數據量及存儲時長的提升，InfluxDB的聚合性能出現了巨大的瓶頸，我們在實際測試的時候，模擬了百萬測點近1年的數據，當聚合請求比較多的時候，基本上就很慢了，這點也對本項目影響很大。
由于以上兩個問題的存在，從架構實現的角度來講，我們必須對存儲技術進行重新選擇。恰好此時TDengine也開放了集群版本，偶然的契機下又聽到了陶老師對于時序數據的特點總結，感覺研究的非常深入，總結的也很全面。 后經與團隊溝通，在技術選型調研時就一并把TDengine包含在了調研范圍之內。簡單嘗試之后，我們發現TDengine的數據模型真(zhen)的(de)非(fei)常適合工業場景(jing)，總(zong)結來說有以下(xia)幾個優點。
優點：
- 社區版本支持集群：可以比較好的利用集群的存儲空間，數據也可以分散開來。
- 聚合性能優越：由于TDengine的數據模型特定及對集群的支撐，在模擬測試過程中，基本上沒有遇到聚合瓶頸。隨著數據量的增加及存儲時長的延長，聚合性能也非常穩定。
- 簡單易用：在工業場景中，組件低耦合是很必要的，TDengine開箱即用的特性很“香”，學習成本低，上手快速。
- 數據模型優秀：在工業場景中，設備及測點的增減非常的普遍，TDengine的超級表及子表的概念很好地解決了這個問題，單列模式的場景對本項目來說非常友好。
- 查詢語義具有普適性：TDengine的查詢語句與InfluxDB非常接近，這點也非常好。
- 版本升級簡單：卸載原有版本，安裝新版本即可，無需數據遷移。
- 社區支持：普通的問題基本上都可以在issue上得到答復，遇到緊急問題的時候，濤思數據的同事甚至可以親自遠程解決，為他們點贊，在使用的時候放心不少。
10個看板頁面，近百個聚合請求
選型確(que)定之后(hou)，我(wo)們(men)就正式開始了(le)搭建。搭載TDengine之后(hou)的架(jia)構圖如(ru)下所示：
采用(yong)該方(fang)案的(de)(de)很大一部分原因是InfluxDB和TDengine在(zai)(zai)查詢(xun)語義上(shang)的(de)(de)天然一致性(xing)。我們為(wei)TDengine外層(ceng)包裝了一層(ceng)SDK，對應用(yong)層(ceng)開放SDK，使(shi)應用(yong)層(ceng)對存儲技術(shu)無(wu)感，在(zai)(zai)SDK內部通過查詢(xun)的(de)(de)時間跨度、組件健康程度等多個因素自(zi)動選(xuan)擇查詢(xun)引擎，這樣可以保障其中一個技術(shu)在(zai)(zai)出現問題的(de)(de)時候，另(ling)一個技術(shu)隨時頂上(shang)來(lai)，大大降低了由于技術(shu)穩(wen)定性(xing)所帶來(lai)的(de)(de)風險。
在數據處理的具體分工上，當前我們主要使用TDengine支持數據聚合的場景。在本次項目中，數據看板是功能的核心，同時也是用戶最看中的地方，而這部分的數據聚合基本上都依賴于TDengine——目前其共支持應用端約10個看板頁面，合計近百個聚合請求，是本項項目落地的關鍵。
TDengine Database在(zai)本項目中運行(xing)穩(wen)定，為(wei)項目的(de)具體功能(neng)實現提供了(le)關鍵助力(li)。未來，隨(sui)著(zhu)TDengine技術的(de)不斷(duan)成熟穩(wen)定，團隊(dui)準備將(jiang)其作(zuo)為(wei)工業(ye)數據庫的(de)存儲(chu)引擎運用在(zai)其他項目中。在(zai)接下來的(de)產品線(xian)規劃上，TDengine也(ye)將(jiang)作(zuo)為(wei)首選(xuan)的(de)重要技術組件。
