基于Hbase的車聯(lián)網(wǎng)海量數(shù)據(jù)存儲(chǔ)

李 星 鄔少飛

（武漢工程大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，湖北 武漢 430000）

1 引言

在當(dāng)前的交通運(yùn)輸領(lǐng)域中，車聯(lián)網(wǎng)(IoV) 屬于物聯(lián)網(wǎng)(IoT)內(nèi)最典型的應(yīng)用，但因汽車的使用存在周期性，使得數(shù)據(jù)的產(chǎn)生也存在周期性，汽車數(shù)據(jù)的海量產(chǎn)生會(huì)固定出現(xiàn)在早高峰和晚高峰期間。每天汽車產(chǎn)生的海量大數(shù)據(jù)存儲(chǔ)達(dá)到了日增數(shù)據(jù)15TB，而如此巨量的數(shù)據(jù)在每日的產(chǎn)生并不是均勻分布而是周期性的產(chǎn)生，在短時(shí)時(shí)間里面會(huì)產(chǎn)生大量的數(shù)據(jù)。為了應(yīng)對(duì)數(shù)據(jù)波動(dòng)性產(chǎn)生對(duì)集群存儲(chǔ)性能的影響，部分研究者從算法上希望能夠解決Hbase 數(shù)據(jù)不平衡的問(wèn)題，比如通過(guò)對(duì)預(yù)先對(duì)數(shù)據(jù)進(jìn)行采集分析后再進(jìn)行數(shù)據(jù)的分配[1,2]，還有對(duì)Hbase的原有算法進(jìn)行優(yōu)化，這些方法很好地解決了數(shù)據(jù)的不均衡問(wèn)題，實(shí)現(xiàn)了Hbase的最大化利用，但是面對(duì)TB級(jí)別的數(shù)據(jù)其對(duì)cpu和集群性能的損耗是巨大的。部分研究者對(duì)數(shù)據(jù)進(jìn)行了預(yù)處理[3-5]，通過(guò)對(duì)數(shù)據(jù)的特征進(jìn)行提取，預(yù)估不同分區(qū)的負(fù)載情況，然后提前對(duì)region 進(jìn)行拆分或是保證熱點(diǎn)數(shù)據(jù)分布在不同的分區(qū)，保證Hbase的負(fù)載平衡，同樣面對(duì)TB 級(jí)別的數(shù)據(jù)，其cpu 的消耗成為了新的瓶頸。近些年來(lái)，面對(duì)大數(shù)據(jù)量的存儲(chǔ)，高并發(fā)的場(chǎng)景，普遍會(huì)采用Kafka 作為中間件，因?yàn)镵afka 作為消息中間件所采取的消息消費(fèi)模式是發(fā)布-訂閱的消息模式，面對(duì)不同的消費(fèi)者，Kafka的分布式消息讀取可以很好地支持到它們，相對(duì)于以往的消息隊(duì)列，Kafka 單點(diǎn)的生產(chǎn)者和消費(fèi)者擁有顯著的優(yōu)越性，能夠做到百萬(wàn)級(jí)的讀寫(xiě)速率，其吞吐量更高，性能更加優(yōu)越，同時(shí)它能將數(shù)據(jù)寫(xiě)入磁盤的同時(shí)將數(shù)據(jù)復(fù)制到集群里面，這些處理不僅保證了數(shù)據(jù)的持久化更使數(shù)據(jù)的容錯(cuò)性得到了保障[6]。

基于以上背景，為解決海量數(shù)據(jù)存儲(chǔ)在Hbase中的存儲(chǔ)問(wèn)題，本文研究出一種基于Hbase的海量數(shù)據(jù)存儲(chǔ)方案?？紤]到車聯(lián)網(wǎng)數(shù)據(jù)的特殊性本文采用了相應(yīng)的行鍵設(shè)計(jì)和預(yù)分區(qū)[7-11]。

2 數(shù)據(jù)預(yù)處理與表設(shè)計(jì)

2.1 數(shù)據(jù)預(yù)處理

研究采用的數(shù)據(jù)來(lái)自實(shí)際傳輸進(jìn)來(lái)的報(bào)文，原始數(shù)據(jù)包包含每輛車采集的該車編號(hào)信息、采集時(shí)間、各個(gè)部分的埋點(diǎn)信息等480個(gè)信號(hào)。經(jīng)過(guò)對(duì)原始數(shù)據(jù)的分析，確認(rèn)了不同數(shù)據(jù)擁有不同的價(jià)值，以及不同數(shù)據(jù)的歸類不同，而大量的信息讓處理的成本更高，為了提高這些信息的利用價(jià)值和保證核心數(shù)據(jù)的不缺失，需要對(duì)數(shù)據(jù)先進(jìn)行簡(jiǎn)單的處理后再存儲(chǔ)進(jìn)入Hbase數(shù)據(jù)庫(kù)里面，處理的具體步驟如下：

（1）剔除缺失數(shù)據(jù)，缺失數(shù)據(jù)指的是當(dāng)上傳的時(shí)候有些車輛的信息沒(méi)有被錄入到系統(tǒng)里面，當(dāng)查詢?cè)撥囕v或是該種車架信息的時(shí)候，該車輛的信息不存在，這些信息將無(wú)法錄入數(shù)據(jù)庫(kù)中。

（2）區(qū)分不同狀態(tài)信息，汽車數(shù)據(jù)中有部分是屬于報(bào)警數(shù)據(jù)，在這些數(shù)據(jù)在中間件處理的時(shí)候就需要被識(shí)別出來(lái)，然后及時(shí)通過(guò)報(bào)警系統(tǒng)將數(shù)據(jù)上傳，關(guān)于這部分?jǐn)?shù)據(jù)的存儲(chǔ)需要先通告報(bào)警系統(tǒng)后再錄入系統(tǒng)。

（3）剔除失效數(shù)據(jù)，當(dāng)數(shù)據(jù)傳輸過(guò)程中存在數(shù)據(jù)的累計(jì)，如所處環(huán)境的網(wǎng)絡(luò)信號(hào)差，導(dǎo)致后期上傳的數(shù)據(jù)的接收時(shí)間相同，對(duì)于這種數(shù)據(jù)僅取發(fā)送時(shí)間距離當(dāng)下最近的數(shù)據(jù)，對(duì)于其他數(shù)據(jù)不進(jìn)行存儲(chǔ)，以防數(shù)據(jù)之間的沖突。

2.2 行鍵表達(dá)式及行鍵生成算法

對(duì)于數(shù)據(jù)庫(kù)的優(yōu)化，不可忽略的部分就是進(jìn)行預(yù)分區(qū)以及對(duì)行鍵進(jìn)行優(yōu)化，針對(duì)不同的數(shù)據(jù)結(jié)構(gòu)需要采取的分區(qū)方式和行鍵的設(shè)計(jì)都是不同的。面對(duì)車聯(lián)網(wǎng)的海量數(shù)據(jù)，行鍵的設(shè)計(jì)和預(yù)分區(qū)都是十分重要。在對(duì)行鍵進(jìn)行設(shè)計(jì)時(shí)，會(huì)對(duì)核心字段進(jìn)行簡(jiǎn)化并在最開(kāi)始就約定實(shí)現(xiàn)的規(guī)則，在后期就依循著規(guī)則來(lái)生成行鍵。選取的行鍵要求能對(duì)存儲(chǔ)和查詢存在一定的優(yōu)化效果，而在當(dāng)前的大數(shù)據(jù)量存儲(chǔ)的系統(tǒng)中，核心是進(jìn)行存儲(chǔ)的優(yōu)化。面對(duì)行量數(shù)據(jù)存儲(chǔ)的場(chǎng)景，本文選擇了將核心字段處理后拼接到行鍵里面，同時(shí)對(duì)行鍵進(jìn)行散列化，使行鍵能夠盡可能地散落在不同的Region 里面，避免熱點(diǎn)現(xiàn)象的出現(xiàn)。

為了達(dá)到這樣的存儲(chǔ)效果，當(dāng)前系統(tǒng)采用的行鍵設(shè)計(jì)方案是：

第一，對(duì)車輛的vin碼的前四位進(jìn)行了md5處理，將數(shù)據(jù)散列開(kāi)；

第二，在后面添加車輛的vin碼（20位）；

第三，添加數(shù)據(jù)類型（15 位）再加上采集時(shí)間（18 位，前14 位為年月日時(shí)分秒，第15 位為N 表示設(shè)備上沒(méi)有上傳采集時(shí)間，由系統(tǒng)自動(dòng)加上當(dāng)前時(shí)間作為采集時(shí)間）；

第四，加隨機(jī)數(shù)（4位，解決同一時(shí)間上傳一個(gè)數(shù)據(jù)包，里頭包含兩個(gè)告警數(shù)據(jù)導(dǎo)致數(shù)據(jù)覆蓋的問(wèn)題）。

最終的行鍵設(shè)計(jì)方案如表1所示。

表1 行鍵最終方案

2.3 表的設(shè)計(jì)和預(yù)分區(qū)

相對(duì)于其他的數(shù)據(jù)而言，車聯(lián)網(wǎng)的大批量數(shù)據(jù)更多是直接存儲(chǔ)進(jìn)入Hbase中，其90%以上的操作都是寫(xiě)入操作，而且數(shù)據(jù)量極其巨大，面對(duì)這樣的場(chǎng)景可以直接將所有的數(shù)據(jù)存儲(chǔ)于一個(gè)列簇里面，將核心的數(shù)據(jù)如車輛定位、定位時(shí)的詳細(xì)時(shí)間、汽車移動(dòng)速度、汽車的油量、汽車的里程數(shù)等數(shù)據(jù)封裝入一條Json字符串里，當(dāng)需要處理時(shí)再提取字符串進(jìn)行處理，這樣就僅需要一個(gè)列，可以極大減輕存儲(chǔ)的壓力。

第三，好教育要有一支數(shù)量充足的高素質(zhì)的校長(zhǎng)、教師隊(duì)伍?！秶?guó)家教育中長(zhǎng)期教育改革與發(fā)展規(guī)劃綱要（2010 —2020年）》指出，有好的教師才有好的教育。高素質(zhì)、專業(yè)化的校長(zhǎng)隊(duì)伍與師德高尚、業(yè)務(wù)精湛、充滿活力的教師隊(duì)伍，是構(gòu)成好教育的最重要因素，也是辦好教育的第一資源。校長(zhǎng)要敢于擔(dān)當(dāng)，有教育情懷，有辦學(xué)思路，懂管理，全心全意為學(xué)生著想、為教職工服務(wù)。好教師不僅要有較高的學(xué)歷，更要有專業(yè)精神和正確的教育觀、學(xué)生觀、質(zhì)量觀。

當(dāng)創(chuàng)建一個(gè)Hbase表的時(shí)候，如果不指定預(yù)分區(qū)Region，默認(rèn)是只會(huì)創(chuàng)建一個(gè)Region。當(dāng)海量數(shù)據(jù)寫(xiě)入Hbase 的時(shí)候，所有的數(shù)據(jù)都會(huì)寫(xiě)入默認(rèn)的Region里面，直至Region的空間消耗完，然后進(jìn)行拆分操作，將一個(gè)Region 劃分為兩個(gè)小的Region。這樣處理將會(huì)造成兩個(gè)問(wèn)題：一是數(shù)據(jù)存儲(chǔ)在單一的Region 中，更容易出現(xiàn)單節(jié)點(diǎn)故障，這會(huì)影響到入庫(kù)的性能；二是該行為會(huì)導(dǎo)致磁盤的拆分，而拆分操作將使大量的集群I/O 資源被消耗掉。為了解決這些問(wèn)題，本文結(jié)合Rowkey的設(shè)計(jì)確定預(yù)分區(qū)的方案。選擇在全表創(chuàng)建10個(gè)分區(qū)，分區(qū)的劃分使用HexStringSplit算法實(shí)現(xiàn)。

3 數(shù)據(jù)處理優(yōu)化

數(shù)據(jù)實(shí)時(shí)處理是車聯(lián)網(wǎng)海量數(shù)據(jù)存儲(chǔ)的核心層。車聯(lián)網(wǎng)數(shù)據(jù)的處理對(duì)于實(shí)時(shí)性的要求是極強(qiáng)的，在一定時(shí)間里面若數(shù)據(jù)沒(méi)有處理完全，那么這一幀數(shù)據(jù)就會(huì)失效，因?yàn)橹挥袧M足實(shí)時(shí)性才能實(shí)現(xiàn)對(duì)車輛的實(shí)時(shí)監(jiān)控，并做出及時(shí)的反饋。面對(duì)傳統(tǒng)平臺(tái)處理海量數(shù)據(jù)存在的高延遲、高并發(fā)問(wèn)題，本文選擇了開(kāi)發(fā)新的PVO 中間件擔(dān)任Kafka 到Hbase 中間的數(shù)據(jù)實(shí)時(shí)處理工作。

車載終端采集的數(shù)據(jù)是實(shí)時(shí)、不間斷的，要求實(shí)時(shí)處理層穩(wěn)定可靠、不宕機(jī)。而PVO層的處理能力是有限的，如果不進(jìn)行獲取消費(fèi)數(shù)據(jù)的限制可能會(huì)導(dǎo)致數(shù)據(jù)出現(xiàn)延時(shí)，當(dāng)前數(shù)據(jù)還未處理完全，后面的數(shù)據(jù)又進(jìn)來(lái)了，當(dāng)完全堆積在PVO 的內(nèi)存后會(huì)導(dǎo)致程序壓力過(guò)大，降低程序的運(yùn)行速度，嚴(yán)重情況下甚至?xí)?dǎo)致宕機(jī)。為了處理這個(gè)問(wèn)題，選擇在中間件添加計(jì)數(shù)器進(jìn)行數(shù)據(jù)消費(fèi)的控制。

詳細(xì)處理流程如圖1。這里首先對(duì)PVO 的性能進(jìn)行壓力測(cè)試，待內(nèi)存消耗完，測(cè)試出其最大的承受數(shù)據(jù)量為DEFAULT_MAX_BLOCKING_SIZE。PVO 會(huì)在對(duì)Kafka 數(shù) 據(jù)進(jìn)行消費(fèi)的同時(shí)用Scheduled 算法對(duì)消費(fèi)數(shù)據(jù)進(jìn)行監(jiān)控，當(dāng)大流量涌入并超過(guò)最大承受量的時(shí)候就會(huì)進(jìn)入等待期同時(shí)進(jìn)行警告，等待期滿發(fā)現(xiàn)內(nèi)存釋放出來(lái)后會(huì)立刻繼續(xù)進(jìn)行消費(fèi)。此外，當(dāng)出現(xiàn)網(wǎng)絡(luò)波動(dòng)等問(wèn)題時(shí)也會(huì)導(dǎo)致數(shù)據(jù)處理延遲，導(dǎo)致數(shù)據(jù)的堆積，針對(duì)這樣的問(wèn)題，在處理數(shù)據(jù)前還會(huì)調(diào)取Hbase的數(shù)據(jù)存入耗時(shí)，當(dāng)前面的數(shù)據(jù)存儲(chǔ)時(shí)間過(guò)長(zhǎng)時(shí)，會(huì)先讓進(jìn)程等待，同時(shí)進(jìn)行警報(bào)處理，方便后期對(duì)問(wèn)題進(jìn)行排查和維護(hù)，直到等待期滿后再重復(fù)進(jìn)行判斷，判斷通過(guò)后再進(jìn)行數(shù)據(jù)處理。

圖1 數(shù)據(jù)處理流程圖

4 實(shí)驗(yàn)與結(jié)果分析

為了驗(yàn)證上述Hbase表設(shè)計(jì)和數(shù)據(jù)處理優(yōu)化的性能，通過(guò)實(shí)驗(yàn)對(duì)其進(jìn)行評(píng)測(cè)。實(shí)驗(yàn)使用的操作系統(tǒng)均為centos 6.10，所搭建的Hbase 集群部署在Cloudera Manager 上面，版本為5.13.1。CDH 版本為5.13.1，hadoop 版本為2.6.0，HDFS版本為2.6.0，Hbase 版本為1.2.0。Hbase 集群的詳細(xì)配置如表2所示。

表2 集群配置

4.1 行鍵設(shè)計(jì)方案的性能驗(yàn)證

為確認(rèn)當(dāng)前設(shè)計(jì)的Hbase行鍵方案是有效的且能夠提升存儲(chǔ)的性能，這里采取了相同的數(shù)據(jù)集進(jìn)行輸入測(cè)試，控制數(shù)據(jù)集是相同的，數(shù)量也相同，唯一變化的就是行鍵是否進(jìn)行設(shè)計(jì)，詳細(xì)的測(cè)試流程如下：

（2）每組對(duì)比實(shí)驗(yàn)采用隨機(jī)模擬的報(bào)文數(shù)據(jù)；

（3）每組實(shí)驗(yàn)重復(fù)三次，取最終存儲(chǔ)效率的平均值繪圖。

按照以上的策略測(cè)試有行鍵設(shè)計(jì)的方案和沒(méi)有行鍵的設(shè)計(jì)方案，以Cloudera Manager 中對(duì)Hbase 寫(xiě)數(shù)據(jù)的監(jiān)控?cái)?shù)據(jù)作為對(duì)比，通過(guò)對(duì)比兩者的差異來(lái)比較兩種設(shè)計(jì)方案的優(yōu)劣。實(shí)驗(yàn)結(jié)果如圖2所示，橫軸為數(shù)據(jù)開(kāi)始輸入的時(shí)間，縱軸為一分鐘內(nèi)平均的數(shù)據(jù)請(qǐng)求數(shù)量。

圖2 存儲(chǔ)效率對(duì)比

由圖2可知，在前兩分鐘里面數(shù)據(jù)的寫(xiě)入會(huì)快速達(dá)到最大峰值，然后就在該峰值處波動(dòng)，直到數(shù)據(jù)存儲(chǔ)完畢沒(méi)有數(shù)據(jù)錄入的最后兩分鐘數(shù)據(jù)寫(xiě)入才會(huì)大幅降低。同樣是寫(xiě)入100w數(shù)據(jù)，兩者的時(shí)間消耗不同，但是兩種方案都呈現(xiàn)了性能達(dá)到峰值后的穩(wěn)定性，這顯示了Hbase對(duì)于海量數(shù)據(jù)存儲(chǔ)的適用性，符合長(zhǎng)期高性能穩(wěn)定的運(yùn)行要求。同時(shí)，圖2中也可以看見(jiàn)無(wú)行鍵設(shè)計(jì)的方案每秒請(qǐng)求數(shù)在3w左右就達(dá)到了峰值，而有行鍵設(shè)計(jì)的方案直到6w 才到達(dá)數(shù)據(jù)存儲(chǔ)的峰值。實(shí)驗(yàn)說(shuō)明，在Hbase的表設(shè)計(jì)中，是否針對(duì)存儲(chǔ)做合理的行鍵設(shè)計(jì)，對(duì)數(shù)據(jù)的存儲(chǔ)性能影響較大。

4.2 中間件優(yōu)化性能驗(yàn)證

在所搭建的平臺(tái)上對(duì)上述的優(yōu)化進(jìn)行測(cè)試，實(shí)驗(yàn)數(shù)據(jù)來(lái)自于內(nèi)部的報(bào)文模擬器。為驗(yàn)證優(yōu)化后的中間件擁有更好的性能，采用如下方法進(jìn)行測(cè)試：

（1）啟動(dòng)報(bào)文模擬器穩(wěn)定向Kafka發(fā)送報(bào)文；

（2）開(kāi)啟PVO中間件拉取Kafka的報(bào)文并對(duì)報(bào)文進(jìn)行處理；

（3）將數(shù)據(jù)存儲(chǔ)到Hbase里面；

（4）通過(guò)Cloudera Manager的讀請(qǐng)求監(jiān)控觀測(cè)數(shù)據(jù)處理的穩(wěn)定性；

（5）關(guān)閉報(bào)文模擬器后切換PVO 中間件為優(yōu)化后的PVO中間件；

（6）重復(fù)步驟一到步驟四。

PVO優(yōu)化前后的監(jiān)控結(jié)果如圖3，可以很清晰地看到相比起優(yōu)化前的數(shù)據(jù)存儲(chǔ)，優(yōu)化后的數(shù)據(jù)存儲(chǔ)的穩(wěn)定性更強(qiáng)。

圖3 請(qǐng)求數(shù)目對(duì)比

5 結(jié)語(yǔ)

車聯(lián)網(wǎng)在未來(lái)的交通出行扮演的角色越來(lái)越重要，對(duì)車聯(lián)網(wǎng)數(shù)據(jù)的處理也有著更大的需求。本文針對(duì)采集自海量汽車的詳細(xì)數(shù)據(jù)，提出了一種基于Hbase對(duì)數(shù)據(jù)存儲(chǔ)性能進(jìn)行優(yōu)化的中間件控制方案。該方案對(duì)原生的PVO中間件添加計(jì)數(shù)器限流的功能，該方法在實(shí)驗(yàn)中展現(xiàn)出了更為優(yōu)越的穩(wěn)定性。該方案通過(guò)對(duì)Rowkey和表結(jié)構(gòu)的設(shè)計(jì)使得存儲(chǔ)性能得到極大的提升。在Hbase的集群上進(jìn)行測(cè)試，相對(duì)于未進(jìn)行設(shè)計(jì)的Rowkey方案，優(yōu)化后的Rowkey方案展現(xiàn)了在存儲(chǔ)效率上的優(yōu)越性。