在車(che)聯網場(chang)(chang)景(jing)(jing)中(zhong)，智(zhi)能車(che)輛(liang)(liang)會(hui)通(tong)過各(ge)類傳(chuan)感器(qi)定(ding)時采集車(che)身狀(zhuang)態(tai)信息，比如(ru)行駛(shi)速度(du)、發動機轉速、輪(lun)胎(tai)壓力(li)值、里程數(shu)等(deng)，此外，還會(hui)由(you)某個事件觸(chu)發產生(sheng)車(che)輛(liang)(liang)事件數(shu)據，比如(ru)門鎖上防(fang)、撤防(fang)、車(che)輛(liang)(liang)碰(peng)撞、異(yi)常移(yi)動等(deng)，在每次上報數(shu)據時都會(hui)帶有時間(jian)戳，這(zhe)是(shi)非(fei)常典(dian)型的時序(xu)數(shu)據場(chang)(chang)景(jing)(jing)。在這(zhe)類場(chang)(chang)景(jing)(jing)下，高寫入、高壓縮(suo)率、快(kuai)速查詢是(shi)對于數(shu)據處理最基本的要(yao)求。
但一(yi)直以來，在應對車(che)聯(lian)網(wang)場(chang)景下時序數(shu)(shu)據的(de)存儲時，企業(ye)大(da)多選(xuan)擇的(de)都是 MongoDB 或 Apache HBase，這兩大(da)數(shu)(shu)據庫技術相對更(geng)加成(cheng)熟，在業(ye)務規模尚未擴(kuo)張(zhang)之前，因為設備不(bu)多、數(shu)(shu)據量不(bu)大(da)，加上查詢(xun)場(chang)景單一(yi)，尚且可(ke)以滿足(zu)業(ye)務需求。隨著業(ye)務的(de)加速擴(kuo)張(zhang)，寫入速度太慢、支(zhi)撐成(cheng)本(ben)過(guo)高等問(wen)題也逐漸(jian)顯現。本(ben)文將會從四個典型的(de)車(che)聯(lian)網(wang)案例出發，給到(dao)你數(shu)(shu)據架構升(sheng)級思路(lu)。
TDengine x 大疆車載
“在(zai)大疆車載當前(qian)的(de)(de)云端平(ping)臺中，TDengine 的(de)(de)應用(yong)不僅節約了(le)存儲(chu)成本和(he)開發學習(xi)成本，同時也表現出了(le)很好的(de)(de)寫入讀取性能(neng)，滿足了(le)智(zhi)能(neng)駕駛(shi)云端平(ping)臺海量時序數據的(de)(de)處理需求。在(zai)查詢方面，不管(guan)是選擇特定數據的(de)(de)查詢還是輕量的(de)(de)查詢，都是毫秒級返回數據。”
業務背景
由于當前的(de)(de)(de)(de)智能(neng)駕駛業(ye)務(wu)(wu)還(huan)是新(xin)的(de)(de)(de)(de)業(ye)務(wu)(wu)場(chang)(chang)景，所(suo)以大疆車(che)載在(zai)(zai)選型(xing)(xing)上(shang)(shang)的(de)(de)(de)(de)歷史負擔相對(dui)較輕。在(zai)(zai)數(shu)(shu)據庫選型(xing)(xing)要(yao)(yao)求(qiu)上(shang)(shang)，從業(ye)務(wu)(wu)需(xu)求(qiu)出發(fa)，主要(yao)(yao)聚焦在(zai)(zai)兩點：首先，結(jie)合當下的(de)(de)(de)(de)業(ye)務(wu)(wu)場(chang)(chang)景，需(xu)要(yao)(yao)滿(man)足單臺車(che)輛的(de)(de)(de)(de)高(gao)頻(pin)消息上(shang)(shang)報(bao)頻(pin)率(lv)；其次，支持(chi)在(zai)(zai)數(shu)(shu)據量大的(de)(de)(de)(de)時候，通過聚合函數(shu)(shu)，或選擇函數(shu)(shu)來快速篩選出需(xu)要(yao)(yao)的(de)(de)(de)(de)數(shu)(shu)據。此外，對(dui)數(shu)(shu)據庫要(yao)(yao)求(qiu)支持(chi)集(ji)群部署的(de)(de)(de)(de)同時，也(ye)要(yao)(yao)求(qiu)更低(di)的(de)(de)(de)(de)查詢語(yu)句編寫上(shang)(shang)手難(nan)度；而(er)且需(xu)支持(chi)單表(biao)千萬量級，在(zai)(zai)海量數(shu)(shu)據并發(fa)場(chang)(chang)景下，需(xu)要(yao)(yao)有較高(gao)的(de)(de)(de)(de)統計報(bao)表(biao)能(neng)力和較好的(de)(de)(de)(de)查詢 SQL 效率(lv)。
架構圖
點擊案例查看更多技術細節
TDengine x 蔚來汽車能源
“在(zai)實(shi)際效果(guo)上，改(gai)造完成(cheng)后，查(cha)詢(xun)(xun)速度提(ti)升明顯，從使(shi)用 HBase 查(cha)詢(xun)(xun)單設(she)備 24 小(xiao)時數(shu)(shu)據(ju)(ju)的秒級返(fan)(fan)回，到使(shi)用 TDengine 查(cha)詢(xun)(xun)查(cha)詢(xun)(xun)相同數(shu)(shu)據(ju)(ju)的毫秒級返(fan)(fan)回；每天增量(liang)數(shu)(shu)據(ju)(ju)占用的存儲空間相當于原來使(shi)用 HBase 時的 50%；集群計算資源成(cheng)本相比使(shi)用 HBase 節省超過 60%。”
業務背景
為了給用(yong)戶提供(gong)更(geng)好(hao)的(de)補能(neng)體驗，蔚(yu)來(lai)能(neng)源在(zai)(zai)加電基礎設施(shi)上(shang)進(jin)行了大量(liang)的(de)投入(ru)，需(xu)要對(dui)設備(bei)進(jin)行更(geng)高效的(de)管(guan)理(li)——將設備(bei)采集數(shu)(shu)據上(shang)報至云(yun)端(duan)進(jin)行存(cun)(cun)(cun)(cun)儲，并提供(gong)實(shi)時(shi)數(shu)(shu)據查(cha)詢(xun)、歷(li)史數(shu)(shu)據查(cha)詢(xun)等業務(wu)服務(wu)，用(yong)來(lai)做設備(bei)監控(kong)和(he)分析(xi)。在(zai)(zai)業務(wu)誕生之初，其用(yong)作數(shu)(shu)據存(cun)(cun)(cun)(cun)儲的(de)選(xuan)型是 MySQL + HBase，MySQL 存(cun)(cun)(cun)(cun)儲設備(bei)最新實(shi)時(shi)數(shu)(shu)據，HBase 存(cun)(cun)(cun)(cun)儲設備(bei)原始數(shu)(shu)據。隨著換電站(zhan)和(he)超(chao)充(chong)站(zhan)等設備(bei)在(zai)(zai)全國的(de)快速布局，設備(bei)數(shu)(shu)量(liang)持(chi)續增長，積累的(de)數(shu)(shu)據量(liang)越(yue)來(lai)越(yue)多，長時(shi)間跨度數(shu)(shu)據查(cha)詢(xun)效率出現瓶(ping)頸(jing)，再加上(shang)查(cha)詢(xun)場景不斷豐富，HBase 已經無法滿足當前業務(wu)需(xu)要（具體痛點問題(ti)見(jian)下方案(an)例鏈接）。
測試結論
采用批量寫入(ru)數據(ju)(ju)方(fang)式(shi)，調整合(he)適的(de)單(dan)(dan)批次數據(ju)(ju)量大小，使用單(dan)(dan)機(ji)部署（8 核 32 GB，500 GB 存儲）默認配置的(de) TDengine 服務，RESTful API寫入(ru)方(fang)式(shi)，在(zai) 4k 并發(fa)流(liu)量下(xia)寫入(ru)沒有問題，同(tong)時(shi)消費(fei)積(ji)壓數據(ju)(ju)時(shi)峰值達(da)到 7 k/s，因為(wei)單(dan)(dan)條消息包含信息量太大，實際處理(li)中會拆分為(wei) 30 條寫入(ru) TDengine，所以實際寫入(ru) QPS 為(wei) 210 k/s，比滿足同(tong)樣(yang)數據(ju)(ju)流(liu)量的(de) HBase 集(ji)群規模要小不少，可(ke)(ke)以節省(sheng)成本(ben)(ben)，再(zai)加上 TDengine 本(ben)(ben)身部署不依賴其他(ta)三方(fang)軟件，也(ye)可(ke)(ke)以同(tong)時(shi)節省(sheng)運維成本(ben)(ben)。
架構圖
點擊案例查看更多技術細節
TDengine x 零跑汽車
“在應用(yong) TDengine 后，不用(yong)再像 MongoDB 一樣，在查詢前需要根(gen)據(ju)(ju)業(ye)務加工出需求數據(ju)(ju)；入(ru)庫性能(neng)高，解決了以(yi)前HBase入(ru)庫不及時的問(wen)題(ti)，可以(yi)用(yong)更(geng)少的服務器資源入(ru)庫更(geng)多(duo)的數據(ju)(ju)，節省更(geng)多(duo)成(cheng)本。同時，TDengine高壓縮(suo)的算法能(neng)提升(sheng) 10 到(dao) 20 倍的壓縮(suo)性能(neng)，降低(di)了存儲壓力和成(cheng)本。”
業務背景
一直以來，在數據存儲上零跑汽車的選擇都是 MongoDB 和 HBase，但是隨著業務的加速擴張，寫入速度太慢、支撐成本過高等問題也逐漸顯現（具體痛點問題見下方案例鏈接）。從降本增效的角度考慮，零跑決定在 C11 新車型上試用下其他的數據庫，在分析數據特點后，最終確定采用時序數據庫（Time Series Database）。
架構圖
點擊案例查看更多技術細節
TDengine x 理想汽車
“通過跟濤(tao)思官(guan)方人員(yuan)進(jin)行深入業(ye)(ye)務封閉式(shi)測試，TDengine 的(de)功能超出預期(qi)，性能比 InfluxDB 要強出許多(duo)，兩級存儲架構設(she)計（行存與列存）很棒，TTL 和標(biao)簽機(ji)制對業(ye)(ye)務透明(ming)，具備(bei)極其優秀的(de)高并發寫入和數(shu)據壓(ya)縮能力(li)，極大降低了業(ye)(ye)務成(cheng)本和業(ye)(ye)務壓(ya)力(li)。因此(ci)我們(men)決(jue)定從 TiDB 遷移至 TDengine。”
業務背景
在(zai)理想汽車的(de)(de)信(xin)號上報業(ye)務(wu)中，需要(yao)將標(biao)記時間戳和采集點的(de)(de)信(xin)息，通過(guo)云端(duan)(duan)寫入(ru)(ru)到(dao)后端(duan)(duan)數(shu)據庫中，有一定(ding)的(de)(de)聚合查詢需求。這是典型(xing)的(de)(de)高并發(fa)插入(ru)(ru)場景(jing)，寫多讀少，之(zhi)前(qian)的(de)(de)系(xi)統用的(de)(de)是 MongoDB，后來因為 MongoDB 的(de)(de)局限性(xing)，其將業(ye)務(wu)遷(qian)移到(dao)了 TiDB，方便進行(xing)擴(kuo)縮(suo)容。但在(zai)遷(qian)移到(dao) TiDB 之(zhi)后，在(zai)目前(qian)使用百(bai)度(du)云 SSD 虛擬機的(de)(de)情(qing)況下，TiDB 集群純寫入(ru)(ru)性(xing)能(neng)并不能(neng)達到(dao)業(ye)務(wu)期(qi)望預期(qi)（HTAP 場景(jing)數(shu)據庫對(dui)純高并發(fa)寫入(ru)(ru)支持不好，與該業(ye)務(wu)場景(jing)的(de)(de)適配性(xing)不高），需要(yao)不斷的(de)(de)資源擴(kuo)容（具(ju)體(ti)痛點問題見下方案例鏈接）。
使用成本對照表
點擊案例查看更多技術細節
寫在最后
隨著(zhu)業(ye)務(wu)的(de)(de)(de)不(bu)斷發展(zhan)，車聯網場景下(xia)數(shu)據(ju)(ju)量之大難(nan)以想象，如(ru)果沒有一款能(neng)夠實現高效存儲的(de)(de)(de)數(shu)據(ju)(ju)庫(ku)，服務(wu)器成本會非常的(de)(de)(de)高。術業(ye)有專攻，在合(he)適(shi)的(de)(de)(de)時候選(xuan)擇合(he)適(shi)的(de)(de)(de)數(shu)據(ju)(ju)庫(ku)是(shi)支持(chi)業(ye)務(wu)發展(zhan)的(de)(de)(de)關鍵，從數(shu)據(ju)(ju)處理需求和特點(dian)出發，時序(xu)數(shu)據(ju)(ju)庫(ku)無(wu)疑是(shi)最佳選(xuan)擇。
添加 TDengine 小(xiao)助(zhu)手(shou)小(xiao)T，找專業的解決方案架構(gou)師聊一聊
