關于零跑

浙(zhe)江零跑科技股份有(you)限公司(leapmotor)作為一家(jia)(jia)科技型企業，是國(guo)內極少數擁(yong)有(you)智(zhi)(zhi)能電動(dong)汽(qi)車(che)完(wan)整自(zi)主(zhu)研(yan)發能力(li)并掌握核心(xin)(xin)技術的(de)(de)新能源(yuan)汽(qi)車(che)廠(chang)家(jia)(jia)，由浙(zhe)江大華技術股份有(you)限公司及其主(zhu)要創(chuang)始(shi)人共同(tong)投(tou)資成(cheng)立，始(shi)終堅持(chi)核心(xin)(xin)技術的(de)(de)全域自(zi)研(yan)，為用戶的(de)(de)出行和(he)生活創(chuang)造最大價值(zhi)，致力(li)成(cheng)為值(zhi)得尊敬的(de)(de)世界(jie)級智(zhi)(zhi)能電動(dong)車(che)企品(pin)牌(pai)。

一(yi)直以(yi)來，在數據存(cun)儲(chu)上我們的(de)選擇都是(shi)MongoDB和HBase，但是(shi)隨著業務的(de)加(jia)速(su)擴張，寫入速(su)度太(tai)慢、支(zhi)撐成(cheng)本過高等問題也逐漸顯現(xian)，具體(ti)來說(shuo)，主要(yao)有(you)以(yi)下幾處痛點：

• MongoDB存儲數據會將數據全部存儲在內存中，過高的存儲成本導致只能存儲一段時間內的數據，且存儲的數據格式需要經過業務組織處理，不僅業務變更不靈活，可以做的業務也非常有限。
• 我們部分實時信號數據存儲在HBase中，這是一個很重的數據庫，搭建HBase需要整套HDFS做支撐，使用、運維、人力等成本都很高，需要大數據相關的人才才能保證平穩運行。而且公司的HBase環境是私有云環境，云平臺在公有云環境，跨專網業務時常會被網絡問題影響。
• 由于存儲和處理問題，只能把電動車產生的3000多個信號的二進制數據存儲在HDFS上，用的時候還需要使用Map/Reduce進行計算獲取，例如使用數據導出功能每次都需要半小時以上才能計算完畢。
• 為降低成本我們把大量的數據存儲在私有云端，但是卻降低了數據使用上的便捷度和性能，特別是在切換專網時數據服務便無法提供了。

從降本增效的角度考慮，我們決定在C11新車型上試用下其他的數據庫，在分析數據特點后，最終確定采用時序數據庫（Time-Series Database）。但市面上時(shi)序(xu)數據庫產品眾多，之所以選擇(ze)TDengine，一(yi)(yi)是由于(yu)(yu)它(ta)比較突出的性能和成本管控能力，其次(ci)也(ye)是由于(yu)(yu)我和它(ta)的一(yi)(yi)些淵源。

為什么選擇TDengine？

在接(jie)觸一個新的(de)數據庫產品(pin)時，通(tong)常大(da)家(jia)比(bi)較關注(zhu)的(de)無非就(jiu)是(shi)兩點：性能強、成本低(di)，這也(ye)是(shi)我們(men)選(xuan)擇TDengine Database的(de)主要(yao)原(yuan)因。

另(ling)外和TDengine的(de)淵源(yuan)要追溯到我的(de)上一(yi)份工作，那時(shi)我對(dui)它就有過(guo)一(yi)些比較(jiao)深入地了解，進入零跑要進行(xing)時(shi)序數據庫選(xuan)型時(shi)，發現(xian)大家(jia)都沒(mei)有接觸過(guo)，心里也(ye)都挺沒(mei)有底的(de)，我就把這段經歷講(jiang)了出來，包括對(dui)TDengine的(de)一(yi)些看法和見解。

我有多年大數據行業的工作經驗，在了解到時序數據庫后，也對市面上一些流行產品如OpenTSDB、InfluxDB都進行了一些調研。對比之后發現TDengine是專門針對物聯網、車聯網業務場景去設計的，在解決這些行業數據問題上更有針對性，它不僅安裝包很小，對集群資源消耗也很少，并且它創新的“一個數據采集點一張表”的數據模型，特別適合物聯網這種多設備且信息量存儲非常大的數據場景。

因為有我之前(qian)的(de)實踐佐證，大(da)家一致覺(jue)得這款(kuan)數據庫(ku)相(xiang)對會更有保(bao)障，在各方(fang)的(de)大(da)力推動下，我們就開始(shi)搭載TDengine運作新業務了。

之前使用的舊(jiu)架構

搭載TDengine之后(hou)的新架構(gou)

在搭載了TDengine之后，我們收獲了以下的四點進步：

• 數據解析出來直接存儲在TDengine中，解決了使用數據重復解析問題。
• 不用再像MongoDB一樣，在查詢前需要根據業務加工出需求數據。TDengine的列式存儲，直接以SQL計算即可，大大提高了業務的靈活性。
• TDengine高壓縮的算法能提升10到20倍的壓縮性能，降低了存儲壓力的同時解決了數據存儲成本高的問題。
• 入庫性能高，解決了以前HBase入庫不及時的問題，可以用更少的服務器資源入庫更多的數據，節省更多成本。

存在的問題和優化的空間

當然問題也是不可避免會存(cun)在(zai)的，對(dui)(dui)于我們來(lai)說(shuo)TDengine是一款(kuan)很新(xin)的數(shu)據庫，相比較(jiao)而言HBase肯定(ding)會在(zai)使用上更加穩定(ding)一些。我們的業務場(chang)景數(shu)據列(lie)(lie)本身就(jiu)比較(jiao)寬，有(you)3000多(duo)列(lie)(lie)，而TDengine之前都是針(zhen)對(dui)(dui)幾十(shi)列(lie)(lie)。此外，還存(cun)在(zai)因(yin)開發集(ji)群時鐘不準導(dao)致集(ji)群頻繁重啟、因(yin)數(shu)據量太(tai)大導(dao)致查詢(xun)報錯(cuo)、連接資源超(chao)時等諸(zhu)多(duo)在(zai)實際落地時遇到的問題。

但(dan)我們(men)并不認為遇到問題(ti)就要一棍子打死，相反愿意給(gei)TDengine時間(jian)去(qu)進行優化。因為使(shi)用(yong)模式不一樣，肯(ken)定會遇到諸多問題(ti)，如果(guo)基于此就放棄使(shi)用(yong)的(de)(de)(de)話，那(nei)這(zhe)款(kuan)跟(gen)物(wu)聯網場景非常(chang)契(qi)合的(de)(de)(de)數據(ju)庫就要和(he)我們(men)擦肩而過了(le)。TDengine失(shi)去(qu)了(le)一個經典(dian)的(de)(de)(de)應(ying)用(yong)場景案例，我們(men)也會因此失(shi)去(qu)一個更好的(de)(de)(de)選(xuan)擇。

在TDengine小(xiao)伙(huo)伴的支持下，上述問題也(ye)得到了(le)很好的解決(jue)。我們(men)(men)前(qian)期使用taosdemo工具(ju)進(jin)行插入(ru)(ru)性能(neng)的測(ce)(ce)試(shi)，能(neng)達到200萬(wan)每秒的入(ru)(ru)庫性能(neng)。在查(cha)詢這(zhe)塊(kuai)，因為都是(shi)內部用戶在使用，云平臺查(cha)詢變(bian)化并不高(gao)，所以沒有進(jin)行非(fei)常深入(ru)(ru)的測(ce)(ce)試(shi)，其查(cha)詢性能(neng)也(ye)能(neng)完美匹配我們(men)(men)的需求。

此外，在副(fu)本構建上他(ta)們也從專業角度給出了(le)一(yi)些(xie)(xie)建議(yi)，我放在本文中，給有同樣(yang)問題的同學們一(yi)些(xie)(xie)參考(kao)：

具體選擇幾(ji)個副(fu)本(ben)還(huan)是(shi)要看讀(du)寫比，從現有(you)架構出發的(de)話，寫入性(xing)(xing)能(neng)要求(qiu)(qiu)(qiu)更高，兩副(fu)本(ben)加一個冷備會(hui)相對更穩妥一些；之后如果查詢性(xing)(xing)能(neng)要求(qiu)(qiu)(qiu)提(ti)上來(lai)了，可以考慮擴充成三個副(fu)本(ben)，三副(fu)本(ben)下讀(du)的(de)性(xing)(xing)能(neng)以及并發能(neng)力會(hui)比兩副(fu)本(ben)更強(qiang)，因為最終的(de)需求(qiu)(qiu)(qiu)還(huan)是(shi)滿足(zu)在線(xian)的(de)實時業務，而不是(shi)數倉型業務。所以此時雙(shuang)副(fu)本(ben)和(he)三副(fu)本(ben)的(de)體驗差別不大。

零跑+TDengine的未來展望

早在2018年我(wo)就開始關(guan)注(zhu)TDengine Database了(le)，到2021年它已經發(fa)展了(le)三年時(shi)間，相對來說也變得更加(jia)成熟(shu)和穩定了(le)，也因此我(wo)們選擇(ze)了(le)它，而它也真的在幫(bang)助我(wo)們節(jie)省成本、提高(gao)速(su)度。

當然如果我們選擇市面上其他的數據庫產品的話，可能也能勝任，但是卻很難達到這樣一種性能和成本的最優化。尤(you)其我們做的是汽車(che)這樣(yang)一(yi)(yi)種產品，數(shu)(shu)據(ju)量之(zhi)大難以想象，如果沒有(you)一(yi)(yi)款能夠實現高效存儲的數(shu)(shu)據(ju)庫(ku)，服務器(qi)成本會非常(chang)的高。這從運(yun)行節(jie)點的數(shu)(shu)量上就(jiu)可窺一(yi)(yi)二，如果使用HBase，估計需要建立十多個(ge)節(jie)點，而搭載TDengine的情(qing)況下三個(ge)節(jie)點就(jiu)能搞定，節(jie)點少了運(yun)維起來自然也會變得更加輕松一(yi)(yi)些。

目前我(wo)們(men)的數(shu)據會(hui)在TDengine上(shang)(shang)存半(ban)年，另(ling)外(wai)每(mei)天都會(hui)同步到(dao)數(shu)倉進行為時兩年的存儲(chu)。大部(bu)分涉及(ji)到(dao)APP、云平臺的業(ye)務，像車速、溫度、充電使用(yong)情況、電池健康(kang)度等信號(hao)值(zhi)現在都是存儲(chu)在TDengine上(shang)(shang)。此(ci)前使用(yong)MongoDB進行業(ye)務處理時，需要先(xian)將數(shu)據存到(dao)MongoDB文(wen)檔中(zhong)，稍顯復雜，現在使用(yong)TDengine可以直(zhi)接進行提取展示(shi)。對比(bi)來(lai)看，TDengine在達到(dao)我(wo)們(men)預期的前提下，在使用(yong)上(shang)(shang)也更加方便(bian)。

在未來(lai)的(de)(de)(de)規劃中，我們希望能(neng)(neng)夠(gou)引入TDengine的(de)(de)(de)使用特(te)性到更(geng)(geng)多的(de)(de)(de)業務中去(qu)，比如說熱更(geng)(geng)新(xin)、溫度曲(qu)線、測速(su)曲(qu)線、電極轉速(su)等(deng)，用更(geng)(geng)多新(xin)的(de)(de)(de)特(te)性減(jian)少客戶(hu)端CPU的(de)(de)(de)消耗，也期待TDengine有(you)更(geng)(geng)多更(geng)(geng)好的(de)(de)(de)功能(neng)(neng)加(jia)入。