大數(shù)據(jù)助力精準扶貧

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

隨著汽車的數(shù)量越來越多，汽車成為我們生活中越來越不可缺少的一部分，汽車保有量已經(jīng)達到2億左右。過去很長一段時間我們只是針對大數(shù)據(jù)對人的作用，如果2億左右的汽車個體能夠主動發(fā)送一些信息，這個數(shù)據(jù)量是非常可觀的，由此所產(chǎn)生的一些統(tǒng)計信息，也能反作用于車輛的生產(chǎn)和提高出行的質量。

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

我們主要是對T-Box的數(shù)據(jù)采集進行存儲的。T-Box將數(shù)據(jù)上傳到服務器或者云平臺，國家監(jiān)管機構、車廠商、經(jīng)銷商或者車主去里面獲取相關的信息，車主可以通過APP獲得數(shù)據(jù)，監(jiān)管部門或者是廠商會通過web界面來獲取信息。

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

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

有沒有這么一種可能性，在海量數(shù)據(jù)的基礎上，建立一層索引，可以減少掃描的數(shù)據(jù)量，從而降低硬件成本的要求。

如上圖，這個框架大家比較熟悉，除了紅框里面的部分，我們現(xiàn)在把它改成我們自研的索引引擎，數(shù)據(jù)篩查的時候經(jīng)過這個索引引擎，首先過濾掉一大部分數(shù)據(jù)量，是在很小的數(shù)據(jù)量中進行檢索，所需要的硬件資源已經(jīng)少了很多。我們?yōu)榱嗽黾铀趶碗s統(tǒng)計場景下的性能，我們將spark框架集成在內(nèi)，這是基于內(nèi)存的一個計算框架。我們與開源的spark框架還不同，開源的spark框架對文本文件沒有過濾，優(yōu)化過的spark框架最終是和索引引擎進行數(shù)據(jù)交換的。無論是通過索引引擎直接查，還是通過spark計算框架查，都比原生地要快很多，在某些場景上，已經(jīng)快了幾百倍。它的底層還是建立在Hadoop基礎上。對外部的數(shù)據(jù)接入，可以傳統(tǒng)的關系型數(shù)據(jù)庫MySQL、Oracle，也可以通過Kafka實時消費。數(shù)據(jù)從產(chǎn)生到可查只需2-3分鐘。

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

索引+大數(shù)據(jù)，由于在運算的時候可以減少掃描的數(shù)據(jù)量，進而可以減少機器臺數(shù)的要求，原生的架構大量的機器堆積不僅僅為了存儲，而是它的計算能力不夠，可能每臺機器存儲只用了一部分，但是每臺機器的計算能力已經(jīng)用滿了。我們從減少數(shù)據(jù)加載量的角度優(yōu)化，可以減少機器臺數(shù)。

還有一個就是數(shù)據(jù)熱點的問題，很多場景下都會對最近幾天的數(shù)據(jù)比較關注，比如說最近幾天的消費數(shù)據(jù)、新聞、網(wǎng)頁瀏覽，都屬于熱點數(shù)據(jù)，查詢頻率比較高，針對這樣的數(shù)據(jù)特點，我們采用了冷熱數(shù)據(jù)分離。冷熱數(shù)據(jù)分離可以做到什么好處呢？查詢頻率比較高的數(shù)據(jù)，我把它放到SSD固態(tài)硬盤上，可以提升數(shù)據(jù)加載的速度，過一段時間之后，這個數(shù)據(jù)查詢沒那么高了，可以把它放到機械硬盤上。這樣可以既兼顧了查詢的速度，也兼顧了成本。

還有我們針對每個數(shù)據(jù)類型，有專門的壓縮格式，可以減少硬盤的存儲。

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

我們的數(shù)據(jù)存儲還是建立在HDFS上，實時檢索相比目前主流的檢索框架來說，它繼承了很多HDFS的特點，比如說磁盤容錯，某些情況下磁盤突然壞掉了，或者速度變慢，磁盤容錯能夠自動發(fā)現(xiàn)，自動遷移到速度比較快的副本上面，然后自動讀取。還有一個是IO管控，如果某個查詢需要的資源非常高，已經(jīng)影響到服務的性能，可以隨時中斷這個任務，從而保證整個服務可查。還有比較重要的是數(shù)據(jù)快照，有時候數(shù)據(jù)不小心刪掉了，我們提供數(shù)據(jù)快照的功能，在短時間內(nèi)可以對大量的數(shù)據(jù)創(chuàng)建快照，1P數(shù)據(jù)只需要2秒鐘創(chuàng)建。

檢索分析場景，基于車載T-Box產(chǎn)生的數(shù)據(jù)，對各個行業(yè)的統(tǒng)計是非常復雜的。國家監(jiān)管機構可能要對尾氣排放進行監(jiān)控，對車輛實時軌跡、位置進行監(jiān)管，還有通過駕駛員的駕駛習慣，比如說急剎車、急轉彎，對駕駛員進行教導。對車廠商來說市場上車輛各組件性能損耗的多維分析，比如說汽車的每個功能組件損耗到什么程度，然后用于改善生產(chǎn)。經(jīng)銷商可以建立用戶畫像，某一型號車輛在全國各個省的分布情況，可以用于精準營銷。對車主來說，需要掌握車輛的整體狀態(tài)。

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

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

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

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

在海量數(shù)據(jù)上進行多維的數(shù)據(jù)統(tǒng)計和分析，進而建立用戶畫像也是一個常用的業(yè)務場景，比如說可以根據(jù)車輛的報警信息，做出一個報警的分布圖，也可以根據(jù)用戶的急加速、急減速行為做出一個統(tǒng)計結果，根據(jù)用戶的屬性分類，建立一個用戶畫像。包括某個車輛在全國的銷售情況，后期用于精準營銷，提供一些判斷的依據(jù)，對各個維度的信息進行多維的統(tǒng)計分析，本來不是一件特別難的事情，當數(shù)據(jù)量小的時候，在Oracle、MySQL里面就可以做，如果放到千億級別、萬億級別就很頭疼。目前開源是怎么解決這個問題的呢？

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

在這種統(tǒng)計分析場景下，如果某一個時刻，入庫壓力比較大，而且查詢的頻率又比較高，這個時候一個進程既承擔讀也承擔寫就成為整個系統(tǒng)的瓶頸。那么一主多從可以實現(xiàn)讀寫分離，提高效率。

主節(jié)點負責數(shù)據(jù)寫入，多個從節(jié)點承擔讀的壓力，它和我們熟知的My SQL主動復制有區(qū)別，MySQL主動復制是每個節(jié)點各保存一份數(shù)據(jù)，比如說一主三從，它有4份數(shù)據(jù)，而且主和從之間有數(shù)據(jù)同步的過程，也是存在延時的。上面的一主多從架構只保留一份數(shù)據(jù)，它沒有數(shù)據(jù)冗余，減少磁盤存儲。在大量的數(shù)據(jù)更新、新增時主節(jié)點和從節(jié)點沒有任何的延時。

上表是開源系統(tǒng)和索引+大數(shù)據(jù)系統(tǒng)的在查詢方面一個直觀的對比圖。開源方案如果要實現(xiàn)多維統(tǒng)計，多個表的表關聯(lián)，或者一個表的多列的復雜的分組統(tǒng)計，需要使用離線集群跑MR任務，它的一份數(shù)據(jù)要存在三套系統(tǒng)里面，數(shù)據(jù)膨脹是很大的。索引+大數(shù)據(jù)的框架僅需要維護一套系統(tǒng)，這一套系統(tǒng)既可以用于檢索，也可以用于統(tǒng)計。體驗對比，Hbase只能查預計算維度，時效性差、數(shù)據(jù)膨脹率高。系統(tǒng)各自獨立，無法實現(xiàn)協(xié)同查詢，如果想要玩轉這三套系統(tǒng)，技術要求是比較高的，數(shù)據(jù)量過億后，無法實現(xiàn)統(tǒng)計分析。對比下來索引+大數(shù)據(jù)，數(shù)據(jù)從產(chǎn)生到可查只需要2到3分鐘，而且多種數(shù)據(jù)可以相互引用，相互組合過濾，并且支持任意維度的快速分析統(tǒng)計。

下面介紹一下錄信數(shù)軟的產(chǎn)品。我們的產(chǎn)品就是想解決當前大數(shù)據(jù)行業(yè)所存在的一些痛點。

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

第二是時效性的問題，目前的行業(yè)現(xiàn)狀是進行大數(shù)據(jù)分析統(tǒng)計，數(shù)據(jù)量是T+1天可查，它有時間間隔，復雜業(yè)務可能要達到一到兩個小時甚至更長時間。索引+大數(shù)據(jù)從產(chǎn)生到可查詢只需要幾分鐘，多維多表的統(tǒng)計分析可以達到秒級。

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

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