關于零跑

浙江零跑科技股份有限公司(leapmotor)作為一家科技型企業(yè)，是國內(nèi)極少數(shù)擁有智能電動汽車完整自主研發(fā)能力并掌握核心技術的新能源汽車廠家，由浙江大華技術股份有限公司及其主要創(chuàng)始人共同投資成立，始終堅持核心技術的全域自研，為用戶的出行和生活創(chuàng)造最大價值，致力成為值得尊敬的世界級智能電動車企品牌。

一直以來，在數(shù)據(jù)存儲上我們的選擇都是MongoDB和HBase，但是隨著業(yè)務的加速擴張，寫入速度太慢、支撐成本過高等問題也逐漸顯現(xiàn)，具體來說，主要有以下幾處痛點：

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

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

為什么選擇TDengine？

在接觸一個新的數(shù)據(jù)庫產(chǎn)品時，通常大家比較關注的無非就是兩點：性能強、成本低，這也是我們選擇TDengine Database的主要原因。

另外和TDengine的淵源要追溯到我的上一份工作，那時我對它就有過一些比較深入地了解，進入零跑要進行時序數(shù)據(jù)庫選型時，發(fā)現(xiàn)大家都沒有接觸過，心里也都挺沒有底的，我就把這段經(jīng)歷講了出來，包括對TDengine的一些看法和見解。

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

因為有我之前的實踐佐證，大家一致覺得這款數(shù)據(jù)庫相對會更有保障，在各方的大力推動下，我們就開始搭載TDengine運作新業(yè)務了。

之前使用的舊架構

搭載TDengine之后的新架構

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

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

存在的問題和優(yōu)化的空間

當然問題也是不可避免會存在的，對于我們來說TDengine是一款很新的數(shù)據(jù)庫，相比較而言HBase肯定會在使用上更加穩(wěn)定一些。我們的業(yè)務場景數(shù)據(jù)列本身就比較寬，有3000多列，而TDengine之前都是針對幾十列。此外，還存在因開發(fā)集群時鐘不準導致集群頻繁重啟、因數(shù)據(jù)量太大導致查詢報錯、連接資源超時等諸多在實際落地時遇到的問題。

但我們并不認為遇到問題就要一棍子打死，相反愿意給TDengine時間去進行優(yōu)化。因為使用模式不一樣，肯定會遇到諸多問題，如果基于此就放棄使用的話，那這款跟物聯(lián)網(wǎng)場景非常契合的數(shù)據(jù)庫就要和我們擦肩而過了。TDengine失去了一個經(jīng)典的應用場景案例，我們也會因此失去一個更好的選擇。

在TDengine小伙伴的支持下，上述問題也得到了很好的解決。我們前期使用taosdemo工具進行插入性能的測試，能達到200萬每秒的入庫性能。在查詢這塊，因為都是內(nèi)部用戶在使用，云平臺查詢變化并不高，所以沒有進行非常深入的測試，其查詢性能也能完美匹配我們的需求。

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

具體選擇幾個副本還是要看讀寫比，從現(xiàn)有架構出發(fā)的話，寫入性能要求更高，兩副本加一個冷備會相對更穩(wěn)妥一些；之后如果查詢性能要求提上來了，可以考慮擴充成三個副本，三副本下讀的性能以及并發(fā)能力會比兩副本更強，因為最終的需求還是滿足在線的實時業(yè)務，而不是數(shù)倉型業(yè)務。所以此時雙副本和三副本的體驗差別不大。

零跑+TDengine的未來展望

早在2018年我就開始關注TDengine Database了，到2021年它已經(jīng)發(fā)展了三年時間，相對來說也變得更加成熟和穩(wěn)定了，也因此我們選擇了它，而它也真的在幫助我們節(jié)省成本、提高速度。

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

目前我們的數(shù)據(jù)會在TDengine上存半年，另外每天都會同步到數(shù)倉進行為時兩年的存儲。大部分涉及到APP、云平臺的業(yè)務，像車速、溫度、充電使用情況、電池健康度等信號值現(xiàn)在都是存儲在TDengine上。此前使用MongoDB進行業(yè)務處理時，需要先將數(shù)據(jù)存到MongoDB文檔中，稍顯復雜，現(xiàn)在使用TDengine可以直接進行提取展示。對比來看，TDengine在達到我們預期的前提下，在使用上也更加方便。

在未來的規(guī)劃中，我們希望能夠引入TDengine的使用特性到更多的業(yè)務中去，比如說熱更新、溫度曲線、測速曲線、電極轉速等，用更多新的特性減少客戶端CPU的消耗，也期待TDengine有更多更好的功能加入。