重慶博尼施科技有限公司是一家商用車全週期方案服務商，利用車聯網、雲端計算、移動網際網路技術，在物流領域 為商用車的生產、銷售、使用、售後、回收各個環節提供一站式解決方案，其中的新能源車輛監控系統就是由該公司提供的，本文是阿里雲客戶重慶博尼施科技有限公司介紹如何使用阿里雲 HBase 來實現新能源車輛監控系統。該系統主要用於東風輕卡等新能源商用車監控服務，目前該系統正在阿里雲線上穩定執行。

新能源車輛監控系統是一個車輛網服務平臺，具有高併發、資料量大、實時性要求高等特點。對車輛監控系統來說最重要的問題就是如何處理車輛產生的海量資料，我們估計，當車輛數量增長到10萬時，每天會產生大約2TB的資料，這些資料不僅需要儲存，還需要做到實時可查。本文將介紹專案的背景和系統的基本架構，隨後介紹我們在開發過程中遇到的各種問題以及解決方案。

專案背景

本專案為車聯網監控系統，系統由車載硬體裝置、雲服務端構成。車載硬體裝置會定時採集車輛的各種狀態資訊，並通過行動網路上傳到伺服器端。伺服器端接收到硬體裝置傳送的資料首先需要將資料進行解析，校驗，隨後會將該訊息轉發到國家汽車監測平臺和地方汽車監測平臺，最後將解析後的明文資料和原始報文資料儲存到系統中。車輛的資料和其他資料需要通過web頁面或rest API介面進行查詢訪問。要求半年內的資料查詢響應時間在毫秒級別內，超過半年的資料需要放到更加低成本的介質上，查詢延遲在3s以內，這些資料的查詢頻次比較低。系統的主要引數有以下幾項:

1. 10萬臺車輛同時線上；

2. 車輛正常情況下平均每分鐘傳送兩個資料報文到監控平臺；

3. 若車輛處於報警狀態，則平均一秒鐘傳送一次資料報文；

4. 資料情況：（1）、車輛資料報文平均大小為1KB;（2）、解析後的資料包大小為7KB；（3）、平均一臺車每天會產生20MB的資料；（4）、系統每天會產生2TB的資料；（5）同時系統有2.9億行的資料需要寫入到資料庫中；

5. 系統併發量：（1）、3300的持續併發量；（2）、10萬個長連線；（3）、每秒3.3MB的原始資料需要被解析；（4）、每秒23.1MB的解析資料需要被儲存。

系統設計

系統的技術選型對初創公司來說至關重要，所以在設計系統的時候尤為小心。經過仔細分析，我們要求新系統必須滿足以下幾個條件：

1. 必須能夠支援海量資料的不間斷寫入，而且能夠儲存PB級別的資料，具有高擴充套件性、高可靠性等；

2. 能夠支援簡單的關鍵字查詢，響應時間在秒級別內；

3. 能夠相容大資料生態產品(如Spark、Hive、Hadoop等)，同時支援離線和準實時OLAP；

4. 優先選擇有雄厚實力的商業公司支援的雲平臺，最大限度減少運維成本。

為何選擇HBase以及阿里雲

因為車輛的監控資料非常大，傳統關係型資料庫（如Mysql、pg等）已經無法勝任儲存工作，所以我們需要選用一種分散式資料庫用於儲存車輛實時資料。

我們在市場上能夠找到分散式資料庫有MongoDB和 HBase。

1. MongoDB：MongoDB是一種我們曾經使用使用過的資料庫，該資料庫是一種基於文件的資料庫。支援分片副本集擴充套件，但是由於MongoDB的分片叢集維護成本過高，另外查詢效能嚴重依賴索引，擴容時分片的遷移速度過慢。所以在這一版本的監控系統中我們並未採用。

2. HBase：HBase底層儲存基於HDFS的面向列資料庫，其核心思想來源於谷歌三大論文內的bigtable。在谷歌和開源界均擁有豐富的應用實踐經驗。除此之外，HBase還有以下特點：（1）、支援PB級別的資料量；（2）、壓縮效率非常高；（3）、支援億級別的QPS；（4）、在國內外很多大型網際網路公司使用；（5）、HBase新增節點及擴容比較方便，無需DBA任何干預。

經過對這幾種資料庫的分析，我們最終選用HBase，其滿足我們前面提到的四個要求，而且還提供Phoenix外掛用於SQL語句的查詢。

作為初創公司，我們的運維能力有限，我們需要業務的快速落地。所以自建機房以及運維團隊意味著前期較大的投入以及高昂的運維成本，所以我們決定使用雲方案。

經過比較國內的各大雲廠商，我們最終選用了阿里雲平臺，因為阿里雲提供SaaS化的HBase服務，同時阿里雲HBase支援很全面的多模式，支援冷資料存放在OSS之中，節約成本；支援備份恢復等特性，做到了真正的native cloud的資料庫服務。另外，HBase 在阿里內部部署超過12000臺機器，歷經7年天貓雙11的考驗，這些實際資料以及經驗增強了我們對阿里雲HBase的技術信心，同時滿足了我們的技術和業務需求。

層級系統架構

系統採用層級架構以方便後期擴充套件和維護，現在主要分為以下幾層：

1. 接入層：主要負責管理車輛裝置的長連線，認證接收車輛傳送的資料，下放資料和指令等操作。

2. 訊息佇列層：主要負責快取接入層收到的車輛實時資料。

3. 實時資料處理與解析層：主要負責解析車輛上傳的實時資料，並將其儲存到資料庫中。另外還需要負責資料轉發、指令生成等工作。

4. 應用層：主要負責處理各種業務邏輯、將解析後的資料進行分析整理提供給使用者使用。

系統架構預覽

最終新能源監控系統的系統架構設計如下

圖中最左端為監控的車輛，它會實時採集車輛的各項資料，並把採集到的資料通過移動網際網路傳送到平臺。平臺驗證完資料會將其寫入到Kafka訊息佇列中。流式計算伺服器從Kafka訊息佇列中取出車輛的原始資料，並對車輛的資料進行解析、儲存、轉發等操作。HBase叢集負責儲存車輛實時資料，MySQL負責儲存組織關係資料。同時，我們還會將超過一定時間（比如半年前）的資料轉存到OSS儲存介質中，以便降低儲存成本。Spark ML會對系統中的各項資料進行分析。終端使用者會從HBase中查詢一些資料。

HBase使用難點

 Row key 設計

團隊在使用HBase之前一直使用MySQL關係型資料庫，在系統設計之初並沒有考慮HBase的特性，而是按照關係型資料庫的設計原則設計。經過一段時間的瞭解後才知道HBase主要使用Row key進行資料查詢。Row key的設計至關重要。 目前系統中設計的Row key如下

1. 裝置ID + 時間戳：此種方式可以快速定位單臺車輛。但是由於裝置ID字首為型號，一旦某批次的裝置或車輛傳送故障，則會造成HBase的某個Region寫入壓力過大。

2. subString(MD5(裝置ID),x) + 裝置ID + 時間戳：此種方式可以將所有車輛打散到每個Region中，避免熱點資料和資料傾斜問題，式中的x一般取5左右。但對於某個型號的車輛查詢就只能夠每臺車輛單獨進行查詢了。

複雜查詢問題

雖然通過Row key的設計可以解決部分資料查詢的需求，但是在面對複雜需求時難以通過Row key 直接索引到資料，若索引無法命中，則只能進行大範圍或全表掃描才能夠定位資料。所以我們在使用HBase時儘量避免複雜的查詢需求。但業務方面仍然會有部分較為複雜的查詢需求。針對這些需求，我們主要使用兩種方式來建立二級索引。

1. 手動在事務產生時將索引寫入到HBase表中：使用這種方式建立索引雖然可以不借用第三方外掛，但是事務的原子性很難得到保障，業務程式碼也會因為索引的變化而難以維護。另外索引的管理也較為麻煩，後期的資料遷移很難能夠。

2. 通過Phoenix構建索引：通過Phoenix構建索引可以避免事務原子性問題，另外也可以通過重建索引來進行資料遷移。因為使用的SQL語句，開發人員更能夠利用之前關係型資料庫的設計經驗建立資料索引。

目前新能源監控系統中主要使用Phoenix實現二級索引，大大增加了資料的查詢使用場景。

雖然Phoenix能夠通過二級索引實現較為複雜的資料查詢，但對於更為複雜的查詢與分析需求就顯得捉襟見肘。所以我們選用了Spark等其他資料分析元件對資料進行離線分析，分析後對結果通過介面提供給使用者。

多語言連線問題

團隊使用Python語言構建系統，但HBase使用Java語言編寫，原生提供了Java API，並未對Python語言提供直接的API。我們使用happybase連線HBase，因為它提供了更為Pythonic的介面服務。另外我們也是用QueryServer 作為Python元件和Phoenix連線的紐帶。

HBase冷資料儲存

系統中車輛資料分為熱資料和冷資料，熱資料需要HBase中實時可查，冷資料雖不需要實時可查，但卻需要一直儲存在磁碟中。阿里雲HBase支援將冷資料直接儲存在OSS中，而這些資料的轉存只需要簡單的設定表相關屬性，操作非常簡單。將冷資料儲存在OSS之中大大減少了資料的儲存成本。

總結

首先，本文介紹了新能源車輛監控系統的專案背景，隨後分析了本專案的專案難點，並介紹了我們團隊的各種解決方案。針對專案需求，介紹了我們選擇HBase的原因，及在HBase資料庫使用過程中的經驗和痛點。

展望

未來，我們會在系統接入大量車輛後，使用golang重寫高效能元件以滿足後期的併發效能需求。由於專案初期考慮到開發時間的問題，並未採用服務拆分的方式進行開發，這限制了系統的可擴充套件性，後期我們會根據實際業務需求，將系統切分成相對獨立的模組，增強擴充套件性可維護性。

另外，車輛資料積累到一定程度後，我們可以利用這些資料進行大資料分析, 如車輛的故障診斷，車輛狀態預測等，這樣就可以在車輛出現問題前提前發出預警，為車主和保險公司避免更大的損失，降低運營成本。