HBase實踐案例：車聯網監控系統

項目背景

本項目爲車聯網監控系統，系統由車載硬件設備、雲服務端構成。車載硬件設備會定時採集車輛的各類狀態信息，並經過移動網絡上傳到服務器端。
服務器端接收到硬件設備發送的數據首先須要將數據進行解析，校驗，隨後會將該消息轉發到國家汽車監測平臺和地方汽車監測平臺，最後將解析後的明文數據和原始報文數據存儲到系統中。
車輛的數據和其餘數據須要經過web頁面或rest API接口進行查詢訪問。
要求半年內的數據查詢響應時間在毫秒級別內，超過半年的數據須要放到更加低成本的介質上，查詢延遲在3s之內，這些數據的查詢頻次比較低。
系統的主要參數有如下幾項:

• 10萬臺車輛同時在線；
• 車輛正常狀況下平均每分鐘發送兩個數據報文到監控平臺；
• 若車輛處於報警狀態，則平均一秒鐘發送一次數據報文；
• 數據狀況：（1）、車輛數據報文平均大小爲1KB;（2）、解析後的數據包大小爲7KB；（3）、平均一臺車天天會產生20MB的數據；（4）、系統天天會產生2TB的數據；（5）同時系統有2.9億行的數據須要寫入到數據庫中；
• 系統併發量：（1）、3300的持續併發量；（2）、10萬個長鏈接；（3）、每秒3.3MB的原始數據須要被解析；（4）、每秒23.1MB的解析數據須要被存儲。

系統設計

系統的技術選型對初創公司來講相當重要，因此在設計系統的時候尤其當心。通過仔細分析，咱們要求新系統必須知足如下幾個條件：

• 必須可以支持海量數據的不間斷寫入，並且可以存儲PB級別的數據，具備高擴展性、高可靠性等；
• 可以支持簡單的關鍵字查詢，響應時間在秒級別內；
• 可以兼容大數據生態產品(如Spark、Hive、Hadoop等)，同時支持離線和準實時OLAP；
• 優先選擇有雄厚實力的商業公司支持的雲平臺，最大限度減小運維成本。

爲什麼選擇HBase以及阿里雲

由於車輛的監控數據很是大，傳統關係型數據庫（如Mysql、pg等）已經沒法勝任存儲工做，因此咱們須要選用一種分佈式數據庫用於存儲車輛實時數據。
咱們在市場上可以找到分佈式數據庫有MongoDB和 HBase。

• MongoDB：MongoDB是一種咱們曾經使用使用過的數據庫，該數據庫是一種基於文檔的數據庫。
  支持分片副本集擴展，可是因爲MongoDB的分片集羣維護成本太高，另外查詢性能嚴重依賴索引，擴容時分片的遷移速度過慢。因此在這一版本的監控系統中咱們並未採用。
• 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的技術信心，同時知足了咱們的技術和業務需求。

層級系統架構

系統採用層級架構以方便後期擴展和維護，如今主要分爲如下幾層：

• 接入層：主要負責管理車輛設備的長鏈接，認證接收車輛發送的數據，下放數據和指令等操做。
• 消息隊列層：主要負責緩存接入層收到的車輛實時數據。
• 實時數據處理與解析層：主要負責解析車輛上傳的實時數據，並將其存儲到數據庫中。另外還須要負責數據轉發、指令生成等工做。
• 應用層：主要負責處理各類業務邏輯、將解析後的數據進行分析整理提供給用戶使用。

系統架構預覽

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

圖中最左端爲監控的車輛，它會實時採集車輛的各項數據，並把採集到的數據經過移動互聯網發送到平臺。
平臺驗證完數據會將其寫入到Kafka消息隊列中。流式計算服務器從Kafka消息隊列中取出車輛的原始數據，並對車輛的數據進行解析、存儲、轉發等操做。
HBase集羣負責存儲車輛實時數據，MySQL負責存儲組織關係數據。同時，咱們還會將超過必定時間（好比半年前）的數據轉存到OSS存儲介質中，以便下降存儲成本。
Spark ML會對系統中的各項數據進行分析。終端用戶會從HBase中查詢一些數據。

HBase使用難點

Row key 設計

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

• 設備ID + 時間戳：此種方式能夠快速定位單臺車輛。可是因爲設備ID前綴爲型號，一旦某批次的設備或車輛發送故障，則會形成HBase的某個Region寫入壓力過大。
• subString(MD5(設備ID),x) + 設備ID + 時間戳：此種方式能夠將全部車輛打散到每一個Region中，避免熱點數據和數據傾斜問題，式中的x通常取5左右。但對於某個型號的車輛查詢就只可以每臺車輛單獨進行查詢了。

複雜查詢問題

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

• 手動在事務產生時將索引寫入到HBase表中：使用這種方式創建索引雖然能夠不借用第三方插件，可是事務的原子性很可貴到保障，業務代碼也會由於索引的變化而難以維護。
  另外索引的管理也較爲麻煩，後期的數據遷移很難可以。
• 經過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重寫高性能組件以知足後期的併發性能需求。因爲項目初期考慮到開發時間的問題，並未採用服務拆分的方式進行開發，這限制了系統的可擴展性，後期咱們會根據實際業務需求，將系統切分紅相對獨立的模塊，加強擴展性可維護性。另外，車輛數據積累到必定程度後，咱們能夠利用這些數據進行大數據分析, 如車輛的故障診斷，車輛狀態預測等，這樣就能夠在車輛出現問題前提早發出預警，爲車主和保險公司避免更大的損失，下降運營成本。