2019年(nián)7月(yuè)5日，由博聞創意和CCIA智能(néng)網聯專委會(huì)、佐智汽車舉辦的「2019中國(guó)汽車互聯與車路(lù)協同大會(huì)」在深圳舉行。南(nán)京錄信數軟研究總監徐國(guó)信先生(shēng)在會(huì)上(shàng)發表了題為(wèi)“大數據助力人車互聯”的演講。

大家好！我是來自(zì)南(nán)京錄信數軟的徐國(guó)信，感謝主辦方提供這樣一(yī)個(gè)機(jī)會(huì)讓我們在這交流一(yī)下(xià)大數據在人 車互聯方面的應用。

南(nán)京錄信數軟是研究針對大數據行業(yè)使用的數據庫産品，我們是做數據存儲的，比較常見(jiàn)的炫酷的查詢界面，比如說建立一(yī)些用戶畫(huà)像、人物(wù)畫(huà)像，我們是給他們提供快速的統計分析能(néng)力的。那麽，今天主要講的是大數據在人車互聯時代的作用。

随著(zhe)汽車的數量越來越多(duō)，汽車成為(wèi)我們生(shēng)活中越來越不可缺少的一(yī)部分，汽車保有量已經達到(dào)2億左右。過去很長(cháng)一(yī)段時間我們隻是針對大數據對人的作用，如果2億左右的汽車個(gè)體能(néng)夠主動發送一(yī)些信息，這個(gè)數據量是非常可觀的，由此所産生(shēng)的一(yī)些統計信息，也能(néng)反作用于車輛的生(shēng)産和提高(gāo)出行的質量。

随著(zhe)車聯網的迅速發展，基于OBD基礎上(shàng)的車載信息采集終端技(jì)術(shù)日益成熟，汽車大數據應運而生(shēng)。通(tōng)過T-Box采集的數據可以應用于各個(gè)行業(yè)，通(tōng)過對數據的統計和分析，可以應用于經銷商、主機(jī)廠商以及國(guó)家監管部門(mén)，最近熱門(mén)的話題是随著(zhe)國(guó)家國(guó)六标準的出台，國(guó)家要對每台汽車的尾氣排放(fàng)進行監管，這也屬于T-Box數據采集的方向。包括車主和駕駛者，車主可以了解車輛的及時狀态。

我們主要是對T-Box的數據采集進行存儲的。T-Box将數據上(shàng)傳到(dào)服務器(qì)或者雲平台，國(guó)家監管機(jī)構、車廠商、經銷商或者車主去裡(lǐ)面獲取相(xiàng)關的信息，車主可以通(tōng)過APP獲得數據，監管部門(mén)或者是廠商會(huì)通(tōng)過web界面來獲取信息。

今天讨論的是數據存儲和查詢界面使用的即席檢索。所謂即席檢索，就(jiù)是想查什麽就(jiù)查什麽，數據在入庫時不需要做預統計和預計算(suàn)，預計算(suàn)的缺點是沒有做預計算(suàn)的維度是不能(néng)查詢的，而且預統計比較消耗系統資源。我們的産品可以實現對原始一(yī)份數據即席查詢，在千億級别上(shàng)實現秒(miǎo)級響應。我們的産品定位是一(yī)款單機(jī)即可支撐500億條數據的秒(miǎo)級檢索分析響應型數據庫。特點：無限線性擴展、4台可支撐千億條、百台可支撐萬億條。

随著(zhe)汽車數量逐年(nián)增長(cháng)，車載終端所産生(shēng)的數據量是非常巨大的，我們通(tōng)過一(yī)些合作的客戶來看(kàn)，一(yī)個(gè)主機(jī)廠商一(yī)年(nián)所能(néng)達到(dào)的數據量在20萬億，數據可以達到(dào)PB級别，當前市(shì)場上(shàng)流行的大數據框架，在這個(gè)數據級别上(shàng)進行快速的統計分析是沒有完美解決方案的。如果對數據進行長(cháng)久存儲，三年(nián)就(jiù)要達到(dào)60萬億的數據量，傳統的數據庫已經吃(chī)不消了。萬億數據怎麽存儲呢(ne)？可能(néng)在數據量比較大的時候，我們會(huì)想到(dào)Hadoop生(shēng)态系統，它是開(kāi)源的，它就(jiù)是通(tōng)過整合單機(jī)資源，堆積單節點的計算(suàn)能(néng)力，達到(dào)比較好的整體算(suàn)力。它的一(yī)個(gè)缺點就(jiù)是它要對全量數據做掃描，全量掃描就(jiù)會(huì)有一(yī)個(gè)問題，需要更多(duō)的硬件(jiàn)滿足算(suàn)力的要求，所以它的硬件(jiàn)成本還(hái)是比較高(gāo)的，雖然說每台硬件(jiàn)成本是配置比較低(dī)的普通(tōng)服務器(qì)，但是整體的成本還(hái)是比較高(gāo)的。

有沒有這麽一(yī)種可能(néng)性，在海量數據的基礎上(shàng)，建立一(yī)層索引，可以減少掃描的數據量，從(cóng)而降低(dī)硬件(jiàn)成本的要求。

如上(shàng)圖，這個(gè)框架大家比較熟悉，除了紅(hóng)框裡(lǐ)面的部分，我們現在把它改成我們自(zì)研的索引引擎，數據篩查的時候經過這個(gè)索引引擎，首先過濾掉一(yī)大部分數據量，是在很小(xiǎo)的數據量中進行檢索，所需要的硬件(jiàn)資源已經少了很多(duō)。我們為(wèi)了增加它在複雜(zá)統計場景下(xià)的性能(néng)，我們将spark框架集成在内，這是基于内存的一(yī)個(gè)計算(suàn)框架。我們與開(kāi)源的spark框架還(hái)不同，開(kāi)源的spark框架對文本文件(jiàn)沒有過濾，優化過的spark框架最終是和索引引擎進行數據交換的。無論是通(tōng)過索引引擎直接查，還(hái)是通(tōng)過spark計算(suàn)框架查，都比原生(shēng)地要快很多(duō)，在某些場景上(shàng)，已經快了幾百倍。它的底層還(hái)是建立在Hadoop基礎上(shàng)。對外部的數據接入，可以傳統的關系型數據庫MySQL、Oracle，也可以通(tōng)過Kafka實時消費(fèi)。數據從(cóng)産生(shēng)到(dào)可查隻需2-3分鍾。

我們對外提供的場景接口也很豐富，有HiveSQL，或者通(tōng)過JDBC，或者通(tōng)過Webservice的方式。

索引+大數據，由于在運算(suàn)的時候可以減少掃描的數據量，進而可以減少機(jī)器(qì)台數的要求，原生(shēng)的架構大量的機(jī)器(qì)堆積不僅僅為(wèi)了存儲，而是它的計算(suàn)能(néng)力不夠，可能(néng)每台機(jī)器(qì)存儲隻用了一(yī)部分，但是每台機(jī)器(qì)的計算(suàn)能(néng)力已經用滿了。我們從(cóng)減少數據加載量的角度優化，可以減少機(jī)器(qì)台數。

還(hái)有一(yī)個(gè)就(jiù)是數據熱點的問題，很多(duō)場景下(xià)都會(huì)對最近幾天的數據比較關注，比如說最近幾天的消費(fèi)數據、新聞、網頁浏覽，都屬于熱點數據，查詢頻率比較高(gāo)，針對這樣的數據特點，我們采用了冷熱數據分離。冷熱數據分離可以做到(dào)什麽好處呢(ne)？查詢頻率比較高(gāo)的數據，我把它放(fàng)到(dào)SSD固态硬盤上(shàng)，可以提升數據加載的速度，過一(yī)段時間之後，這個(gè)數據查詢沒那麽高(gāo)了，可以把它放(fàng)到(dào)機(jī)械硬盤上(shàng)。這樣可以既兼顧了查詢的速度，也兼顧了成本。

還(hái)有我們針對每個(gè)數據類型，有專門(mén)的壓縮格式，可以減少硬盤的存儲。

上(shàng)圖是我們在一(yī)個(gè)真實的項目遇到(dào)的情況，它的數據量也是達到(dào)萬億級别。這是對開(kāi)源系統和索引+大數據系統的對比。首先是硬件(jiàn)成本，很明顯機(jī)器(qì)台數已經降到(dào)之前的1/5，對硬件(jiàn)配置的要求也有很大的下(xià)降。還(hái)有就(jiù)是人力成本，之前有三套系統，有做統計分析的mapreduce集群、有做實時檢索的hbase、還(hái)有建立二級索引的ES，三套系統保存三份數據，數據膨脹率很高(gāo)，而且三套集群，4種完全不同的風格的API，對開(kāi)發的要求很高(gāo)。索引+大數據的架構，它對外是統一(yī)的SQL接口，通(tōng)過sql語句來進行交互，極大的減少人力成本。

我們的數據存儲還(hái)是建立在HDFS上(shàng)，實時檢索相(xiàng)比目前主流的檢索框架來說，它繼承了很多(duō)HDFS的特點，比如說磁盤容錯(cuò)，某些情況下(xià)磁盤突然壞掉了，或者速度變慢(màn)，磁盤容錯(cuò)能(néng)夠自(zì)動發現，自(zì)動遷移到(dào)速度比較快的副本上(shàng)面，然後自(zì)動讀(dú)取。還(hái)有一(yī)個(gè)是IO管控，如果某個(gè)查詢需要的資源非常高(gāo)，已經影響到(dào)服務的性能(néng)，可以随時中斷這個(gè)任務，從(cóng)而保證整個(gè)服務可查。還(hái)有比較重要的是數據快照(zhào)，有時候數據不小(xiǎo)心删掉了，我們提供數據快照(zhào)的功能(néng)，在短時間内可以對大量的數據創建快照(zhào)，1P數據隻需要2秒(miǎo)鍾創建。

檢索分析場景，基于車載T-Box産生(shēng)的數據，對各個(gè)行業(yè)的統計是非常複雜(zá)的。國(guó)家監管機(jī)構可能(néng)要對尾氣排放(fàng)進行監控，對車輛實時軌迹、位置進行監管，還(hái)有通(tōng)過駕駛員(yuán)的駕駛習慣，比如說急刹車、急轉彎，對駕駛員(yuán)進行教導。對車廠商來說市(shì)場上(shàng)車輛各組件(jiàn)性能(néng)損耗的多(duō)維分析，比如說汽車的每個(gè)功能(néng)組件(jiàn)損耗到(dào)什麽程度，然後用于改善生(shēng)産。經銷商可以建立用戶畫(huà)像，某一(yī)型号車輛在全國(guó)各個(gè)省的分布情況，可以用于精準營銷。對車主來說，需要掌握車輛的整體狀态。

對各個(gè)行業(yè)來說，數據的統計分析是非常複雜(zá)的，在大量的數據基礎上(shàng)進行這麽複雜(zá)的分析，是一(yī)個(gè)很大的挑戰。在索引+大數據的框架下(xià)，無論是檢索還(hái)是統計分析，查詢性相(xiàng)比較開(kāi)源都有很大幅度的提升，但是在某些具體場景，我們也是有一(yī)些特定的優化的。比如說一(yī)些軌迹類的查詢，像軌迹回放(fàng)，要求是在過去的某一(yī)段時間，對某一(yī)個(gè)車輛進行軌迹的檢索，将軌迹信息實時展示在地圖上(shàng)面，用于一(yī)些軌迹監控之類的。

這個(gè)數據其實就(jiù)是經緯度字段在界面上(shàng)展示，至于這個(gè)界面做到(dào)多(duō)炫酷，那是界面的事(shì)情，我們是提供數據快速查詢的能(néng)力。還(hái)有就(jiù)是區域查車，在地圖上(shàng)可以人為(wèi)圈定一(yī)個(gè)規則的圓形或者矩形，或者不規則的多(duō)邊形，可以監控這個(gè)圖形範圍内的車輛信息，出來的也是經緯度的信息。值得一(yī)提的是目前開(kāi)源解決方案對不規則的多(duō)邊形支持并不友(yǒu)好，有些并不支持，我們通(tōng)過改善空間地圖位置索引的結構，就(jiù)能(néng)很好地支持這種不規則多(duō)邊形的索引。

其實這兩種軌迹類的查詢，隻是對經緯度字段的查詢度比較高(gāo)，其它的字段不查詢。針對一(yī)個(gè)表中某幾個(gè)字段查詢比較高(gāo)的情況，是不是有其它的方案呢(ne)？列簇和異構是比較好的解決方法。列簇是說，一(yī)張表裡(lǐ)面有幾個(gè)列，它的保存周期、存儲格式不同，就(jiù)可以把相(xiàng)同生(shēng)命周期的數據或者是相(xiàng)同存儲格式的數據保存在一(yī)個(gè)目錄裡(lǐ)面，後期進行數據淘汰或者增加壓縮比。然後是異構，根據數據的重要程度，選擇在保存在不同的存儲介質上(shàng)，如果使用頻率不高(gāo)的，可以保存在機(jī)械硬盤上(shàng)。那麽軌迹類的查詢，就(jiù)可以把經緯度字段放(fàng)在比較好的硬盤上(shàng)，獲得好的數據加載性能(néng)。等過了一(yī)段時間，數據會(huì)自(zì)動遷移到(dào)一(yī)些廉價的硬盤上(shàng)。

在軌迹類查詢方面，比如說想查詢某個(gè)車牌号或者某個(gè)手機(jī)号今天的軌迹信息，一(yī)般的做法就(jiù)是針對時間字段做排序，然後取最新的幾條，在萬億數據基礎上(shàng)做排序，是一(yī)件(jiàn)很頭疼的事(shì)情，我們針對大數據量的TOP N的排序也做了優化，目前業(yè)界主要做的是一(yī)條一(yī)條暴力掃描，将數據加載之後再獲取TOPN。我們所做的針對排序的數據結構是叫tired tree，它是針對數值類型的排序，比如整型int是四個(gè)字節，那麽，先根據第一(yī)個(gè)字節建立索引，然後再根據第一(yī)、二個(gè)字節建立索引，之後再根據第一(yī)、二、三個(gè)字節建立索引，最後對全量數據建立索引，通(tōng)過對相(xiàng)同前綴建立索引，可以獲得較好的性能(néng)。比如要查詢423這個(gè)值，首先去查4，定位到(dào)4，之後5、6就(jiù)不查了。然後定位42，44就(jiù)不需要查詢了，之後再直接找到(dào)423，經過幾次的查詢，和全量掃描最底層所有的記錄來說，已經高(gāo)效了不少，當然這裡(lǐ)的數據量比較少，我們看(kàn)不出來有多(duō)麽高(gāo)效。如果我要找TOP N，我可以直接定位到(dào)這個(gè)數值前面最大的前綴，這裡(lǐ)是6，找到(dào)6之後，我可以找到(dào)64下(xià)面的，直接返回了。它可以通(tōng)過索引直接定位到(dào)TOPN個(gè)結果，無序額外計算(suàn)，隻需作TOP N排序，避免讀(dú)取全量數據。通(tōng)過這種高(gāo)效排序和異構+索引在軌迹類的查詢，可以做到(dào)很好的性能(néng)提升。

在海量數據上(shàng)進行多(duō)維的數據統計和分析，進而建立用戶畫(huà)像也是一(yī)個(gè)常用的業(yè)務場景，比如說可以根據車輛的報(bào)警信息，做出一(yī)個(gè)報(bào)警的分布圖，也可以根據用戶的急加速、急減速行為(wèi)做出一(yī)個(gè)統計結果，根據用戶的屬性分類，建立一(yī)個(gè)用戶畫(huà)像。包括某個(gè)車輛在全國(guó)的銷售情況，後期用于精準營銷，提供一(yī)些判斷的依據，對各個(gè)維度的信息進行多(duō)維的統計分析，本來不是一(yī)件(jiàn)特别難的事(shì)情，當數據量小(xiǎo)的時候，在Oracle、MySQL裡(lǐ)面就(jiù)可以做，如果放(fàng)到(dào)千億級别、萬億級别就(jiù)很頭疼。目前開(kāi)源是怎麽解決這個(gè)問題的呢(ne)？

它把過濾之後的數據全部加載到(dào)内存，通(tōng)過拼I/O資源和CPU資源，人為(wèi)地做一(yī)些聚合、分組統計，這個(gè)性能(néng)還(hái)是依賴硬件(jiàn)。我們對這個(gè)業(yè)務場景做的一(yī)個(gè)調優是我們在入庫的時候，就(jiù)對我們所要統計的某些字段進行預排序，幹預它的排序規則，比如要對一(yī)個(gè)表裡(lǐ)面有三個(gè)字段city_id、age、score進行統計分析，數據存儲的時候，就(jiù)是按照(zhào)這種group by 的順序來存儲，那麽遇到(dào)這種查詢的時候，就(jiù)可以直接獲取到(dào)後面的數據，就(jiù)不需要重新計算(suàn)。如果某個(gè)統計分析後面加上(shàng)檢索條件(jiàn)，也不需要做全列掃描，通(tōng)過在真實數據基礎上(shàng)創建一(yī)個(gè)二級的跳躍表結構，每一(yī)個(gè)節點上(shàng)會(huì)記錄當前區域裡(lǐ)面的最大值和最小(xiǎo)值。通(tōng)過第一(yī)層可以找到(dào)第二層，第二層縮小(xiǎo)到(dào)更小(xiǎo)的區間，在千億甚至萬億的數據裡(lǐ)面，最後篩選的數據量就(jiù)很少，可以極大地過濾掉數據，加載數據的内容很小(xiǎo)，釋放(fàng)很多(duō)的I/O資源。用戶可以根據需求自(zì)定義任意維度，快速統計。當然它和預計算(suàn)、預統計是有區别的，預計算(suàn)的容量更重，它需要占用的CPU資源更高(gāo)。

在這種統計分析場景下(xià)，如果某一(yī)個(gè)時刻，入庫壓力比較大，而且查詢的頻率又(yòu)比較高(gāo)，這個(gè)時候一(yī)個(gè)進程既承擔讀(dú)也承擔寫就(jiù)成為(wèi)整個(gè)系統的瓶頸。那麽一(yī)主多(duō)從(cóng)可以實現讀(dú)寫分離，提高(gāo)效率。

主節點負責數據寫入，多(duō)個(gè)從(cóng)節點承擔讀(dú)的壓力，它和我們熟知的My SQL主動複制有區别，MySQL主動複制是每個(gè)節點各保存一(yī)份數據，比如說一(yī)主三從(cóng)，它有4份數據，而且主和從(cóng)之間有數據同步的過程，也是存在延時的。上(shàng)面的一(yī)主多(duō)從(cóng)架構隻保留一(yī)份數據，它沒有數據冗餘，減少磁盤存儲。在大量的數據更新、新增時主節點和從(cóng)節點沒有任何的延時。

上(shàng)表是開(kāi)源系統和索引+大數據系統的在查詢方面一(yī)個(gè)直觀的對比圖。開(kāi)源方案如果要實現多(duō)維統計，多(duō)個(gè)表的表關聯，或者一(yī)個(gè)表的多(duō)列的複雜(zá)的分組統計，需要使用離線集群跑MR任務，它的一(yī)份數據要存在三套系統裡(lǐ)面，數據膨脹是很大的。索引+大數據的框架僅需要維護一(yī)套系統，這一(yī)套系統既可以用于檢索，也可以用于統計。體驗對比，Hbase隻能(néng)查預計算(suàn)維度，時效性差、數據膨脹率高(gāo)。系統各自(zì)獨立，無法實現協同查詢，如果想要玩轉這三套系統，技(jì)術(shù)要求是比較高(gāo)的，數據量過億後，無法實現統計分析。對比下(xià)來索引+大數據，數據從(cóng)産生(shēng)到(dào)可查隻需要2到(dào)3分鍾，而且多(duō)種數據可以相(xiàng)互引用，相(xiàng)互組合過濾，并且支持任意維度的快速分析統計。

下(xià)面介紹一(yī)下(xià)錄信數軟的産品。我們的産品就(jiù)是想解決當前大數據行業(yè)所存在的一(yī)些痛點。

第一(yī)是成本高(gāo)。目前想要在純檢索的情況下(xià)，實現千億量級的統計分析，需要100台SSD機(jī)器(qì)，在這種情況下(xià)，索引+大數據的框架可以節省60%-70%的硬件(jiàn)成本，包括機(jī)器(qì)台數和硬件(jiàn)配置。

第二是時效性的問題，目前的行業(yè)現狀是進行大數據分析統計，數據量是T+1天可查，它有時間間隔，複雜(zá)業(yè)務可能(néng)要達到(dào)一(yī)到(dào)兩個(gè)小(xiǎo)時甚至更長(cháng)時間。索引+大數據從(cóng)産生(shēng)到(dào)可查詢隻需要幾分鍾，多(duō)維多(duō)表的統計分析可以達到(dào)秒(miǎo)級。

第三是易用性比較差，目前大數據的框架一(yī)般Hadoop+hbase+ES，它需要多(duō)份數據、多(duō)種業(yè)務接口，上(shàng)手複雜(zá)。索引+大數據是多(duō)種業(yè)務一(yī)套數據庫一(yī)站(zhàn)式解決。

我們不是提供通(tōng)用的解決方案，我們是根據用戶的需求，解決具體的問題。今天介紹的是車聯網領域的應用，其實大數據是無處不在的，數據的價值也越來越被重視，尤其在當今的國(guó)際背景下(xià)，國(guó)産數據庫任重而道遠(yuǎn)，感謝大家！