基于Hbase的車聯網海量數據存儲

李 星 鄔少飛

（武漢工程大學計算機科學與工程學院，湖北 武漢 430000）

1 引言

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

基于以上背景，為解決海量數據存儲在Hbase中的存儲問題，本文研究出一種基于Hbase的海量數據存儲方案?？紤]到車聯網數據的特殊性本文采用了相應的行鍵設計和預分區[7-11]。

2 數據預處理與表設計

2.1 數據預處理

研究采用的數據來自實際傳輸進來的報文，原始數據包包含每輛車采集的該車編號信息、采集時間、各個部分的埋點信息等480個信號。經過對原始數據的分析，確認了不同數據擁有不同的價值，以及不同數據的歸類不同，而大量的信息讓處理的成本更高，為了提高這些信息的利用價值和保證核心數據的不缺失，需要對數據先進行簡單的處理后再存儲進入Hbase數據庫里面，處理的具體步驟如下：

（1）剔除缺失數據，缺失數據指的是當上傳的時候有些車輛的信息沒有被錄入到系統里面，當查詢該車輛或是該種車架信息的時候，該車輛的信息不存在，這些信息將無法錄入數據庫中。

（2）區分不同狀態信息，汽車數據中有部分是屬于報警數據，在這些數據在中間件處理的時候就需要被識別出來，然后及時通過報警系統將數據上傳，關于這部分數據的存儲需要先通告報警系統后再錄入系統。

（3）剔除失效數據，當數據傳輸過程中存在數據的累計，如所處環境的網絡信號差，導致后期上傳的數據的接收時間相同，對于這種數據僅取發送時間距離當下最近的數據，對于其他數據不進行存儲，以防數據之間的沖突。

2.2 行鍵表達式及行鍵生成算法

對于數據庫的優化，不可忽略的部分就是進行預分區以及對行鍵進行優化，針對不同的數據結構需要采取的分區方式和行鍵的設計都是不同的。面對車聯網的海量數據，行鍵的設計和預分區都是十分重要。在對行鍵進行設計時，會對核心字段進行簡化并在最開始就約定實現的規則，在后期就依循著規則來生成行鍵。選取的行鍵要求能對存儲和查詢存在一定的優化效果，而在當前的大數據量存儲的系統中，核心是進行存儲的優化。面對行量數據存儲的場景，本文選擇了將核心字段處理后拼接到行鍵里面，同時對行鍵進行散列化，使行鍵能夠盡可能地散落在不同的Region 里面，避免熱點現象的出現。

為了達到這樣的存儲效果，當前系統采用的行鍵設計方案是：

第一，對車輛的vin碼的前四位進行了md5處理，將數據散列開；

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

第三，添加數據類型（15 位）再加上采集時間（18 位，前14 位為年月日時分秒，第15 位為N 表示設備上沒有上傳采集時間，由系統自動加上當前時間作為采集時間）；

第四，加隨機數（4位，解決同一時間上傳一個數據包，里頭包含兩個告警數據導致數據覆蓋的問題）。

最終的行鍵設計方案如表1所示。

表1 行鍵最終方案

2.3 表的設計和預分區

相對于其他的數據而言，車聯網的大批量數據更多是直接存儲進入Hbase中，其90%以上的操作都是寫入操作，而且數據量極其巨大，面對這樣的場景可以直接將所有的數據存儲于一個列簇里面，將核心的數據如車輛定位、定位時的詳細時間、汽車移動速度、汽車的油量、汽車的里程數等數據封裝入一條Json字符串里，當需要處理時再提取字符串進行處理，這樣就僅需要一個列，可以極大減輕存儲的壓力。

第三，好教育要有一支數量充足的高素質的校長、教師隊伍。《國家教育中長期教育改革與發展規劃綱要（2010 —2020年）》指出，有好的教師才有好的教育。高素質、專業化的校長隊伍與師德高尚、業務精湛、充滿活力的教師隊伍，是構成好教育的最重要因素，也是辦好教育的第一資源。校長要敢于擔當，有教育情懷，有辦學思路，懂管理，全心全意為學生著想、為教職工服務。好教師不僅要有較高的學歷，更要有專業精神和正確的教育觀、學生觀、質量觀。

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

3 數據處理優化

數據實時處理是車聯網海量數據存儲的核心層。車聯網數據的處理對于實時性的要求是極強的，在一定時間里面若數據沒有處理完全，那么這一幀數據就會失效，因為只有滿足實時性才能實現對車輛的實時監控，并做出及時的反饋。面對傳統平臺處理海量數據存在的高延遲、高并發問題，本文選擇了開發新的PVO 中間件擔任Kafka 到Hbase 中間的數據實時處理工作。

車載終端采集的數據是實時、不間斷的，要求實時處理層穩定可靠、不宕機。而PVO層的處理能力是有限的，如果不進行獲取消費數據的限制可能會導致數據出現延時，當前數據還未處理完全，后面的數據又進來了，當完全堆積在PVO 的內存后會導致程序壓力過大，降低程序的運行速度，嚴重情況下甚至會導致宕機。為了處理這個問題，選擇在中間件添加計數器進行數據消費的控制。

詳細處理流程如圖1。這里首先對PVO 的性能進行壓力測試，待內存消耗完，測試出其最大的承受數據量為DEFAULT_MAX_BLOCKING_SIZE。PVO 會在對Kafka 數 據進行消費的同時用Scheduled 算法對消費數據進行監控，當大流量涌入并超過最大承受量的時候就會進入等待期同時進行警告，等待期滿發現內存釋放出來后會立刻繼續進行消費。此外，當出現網絡波動等問題時也會導致數據處理延遲，導致數據的堆積，針對這樣的問題，在處理數據前還會調取Hbase的數據存入耗時，當前面的數據存儲時間過長時，會先讓進程等待，同時進行警報處理，方便后期對問題進行排查和維護，直到等待期滿后再重復進行判斷，判斷通過后再進行數據處理。

圖1 數據處理流程圖

4 實驗與結果分析

為了驗證上述Hbase表設計和數據處理優化的性能，通過實驗對其進行評測。實驗使用的操作系統均為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 集群的詳細配置如表2所示。

表2 集群配置

4.1 行鍵設計方案的性能驗證

為確認當前設計的Hbase行鍵方案是有效的且能夠提升存儲的性能，這里采取了相同的數據集進行輸入測試，控制數據集是相同的，數量也相同，唯一變化的就是行鍵是否進行設計，詳細的測試流程如下：

（2）每組對比實驗采用隨機模擬的報文數據；

（3）每組實驗重復三次，取最終存儲效率的平均值繪圖。

按照以上的策略測試有行鍵設計的方案和沒有行鍵的設計方案，以Cloudera Manager 中對Hbase 寫數據的監控數據作為對比，通過對比兩者的差異來比較兩種設計方案的優劣。實驗結果如圖2所示，橫軸為數據開始輸入的時間，縱軸為一分鐘內平均的數據請求數量。

圖2 存儲效率對比

由圖2可知，在前兩分鐘里面數據的寫入會快速達到最大峰值，然后就在該峰值處波動，直到數據存儲完畢沒有數據錄入的最后兩分鐘數據寫入才會大幅降低。同樣是寫入100w數據，兩者的時間消耗不同，但是兩種方案都呈現了性能達到峰值后的穩定性，這顯示了Hbase對于海量數據存儲的適用性，符合長期高性能穩定的運行要求。同時，圖2中也可以看見無行鍵設計的方案每秒請求數在3w左右就達到了峰值，而有行鍵設計的方案直到6w 才到達數據存儲的峰值。實驗說明，在Hbase的表設計中，是否針對存儲做合理的行鍵設計，對數據的存儲性能影響較大。

4.2 中間件優化性能驗證

在所搭建的平臺上對上述的優化進行測試，實驗數據來自于內部的報文模擬器。為驗證優化后的中間件擁有更好的性能，采用如下方法進行測試：

（1）啟動報文模擬器穩定向Kafka發送報文；

（2）開啟PVO中間件拉取Kafka的報文并對報文進行處理；

（3）將數據存儲到Hbase里面；

（4）通過Cloudera Manager的讀請求監控觀測數據處理的穩定性；

（5）關閉報文模擬器后切換PVO 中間件為優化后的PVO中間件；

（6）重復步驟一到步驟四。

PVO優化前后的監控結果如圖3，可以很清晰地看到相比起優化前的數據存儲，優化后的數據存儲的穩定性更強。

圖3 請求數目對比

5 結語

車聯網在未來的交通出行扮演的角色越來越重要，對車聯網數據的處理也有著更大的需求。本文針對采集自海量汽車的詳細數據，提出了一種基于Hbase對數據存儲性能進行優化的中間件控制方案。該方案對原生的PVO中間件添加計數器限流的功能，該方法在實驗中展現出了更為優越的穩定性。該方案通過對Rowkey和表結構的設計使得存儲性能得到極大的提升。在Hbase的集群上進行測試，相對于未進行設計的Rowkey方案，優化后的Rowkey方案展現了在存儲效率上的優越性。