博客斷更了好久了,今天提筆分享一下將IoTDB
真正應用到生產環境當中的故事。如果你也正在研究或對相關技術感興趣,歡迎一起討論學習,聯繫方式見文章末尾。
四維智聯是一家車聯網服務提供商,主要就是傳統Tsp、智能座艙、自動駕駛、導航等等,是一家ToB
性質的公司:https://www.autoai.com/
IoTDB: https://iotdb.apache.org/
在2020年3月
的時候,公司開展了針對一家大型車廠的用戶駕駛行爲數據分析的項目。因爲篇幅的關係,後面會省略很多細節,有興趣可以聯繫我或者以後有時間再單獨寫這塊。
駕駛行爲通常意義上是三急一超,即:急加速、急減速、急剎車、超速。我們在這個基礎上完善了更多維的一個評價體系,如變道、操作舒適度、擁堵等等。將車主儘可能多的操作進行一個量化,得到一個分數值,基於分數再推薦用戶進行更良好的操作行爲建議。
1. 整體架構
抽象來看,數據有三個歸屬地:
這裏值得注意的一點是:無論哪一方,其實整體的服務器及數據都是在車廠內網及DC中的,只是邏輯隔離。
- 是車廠數據中心,既數據的所有方,他爲了保證車主數據的安全會採用
項目數據申請制
來發布數據。舉例來講:假如車相關數據總共有10項,如果項目1
只用到了其中的3項(x,y,z),那麼車廠會把車中(x,y,z)這三項寫到一個文件中同步發給項目1
,這樣做的目的儘可能的保證了數據的隱私與安全
。 - 是數據計算方,數據使用Kafka的方式將數據中心加工好的數據同步過來,形式是
每車/每分鐘
1個文件。數據在接收之後會按照業務的設計,進行數據分析及加工,加工完成後的結果數據會發送給下游的數據使用方
。 - 數據使用方是依賴於分析完成的原子數據進行多樣化展示給客戶的一個項目方。這個就好比中國的路都是一樣的,但是高德、百度、四維做出來的導航就是不一樣的,那高德、百度,就相當於是數據的使用方。
2.數據接入
我們使用了6臺 * 4核16G
的Kafka機器作爲支撐。
原始的
每車/每分
文件大小大概是0.25M
左右
可以看到生產側最大每秒產生5230
個文件,也就是峯值1.2G/s
的一個入數據速度,PS:如果是購買的公網帶寬大家可以算一下成本。
根據平均值可以測算出,原始數據每天產生的數據量大概是:758/s
* 3600
* 24
= 15.6T/天
。
當然這個截圖時間比較久遠了,我特意去線上看了一下最新的數據:每天產生的數據量大概是:1.46K/s
* 3600
* 24
= 20.6T/天
。有興趣的可以自己測算一下存儲多副本、長時間總成本有多高。
3.數據處理
文件接收到之後,使用Flink
進行原始文件解析、數據清洗、原始數據入庫的工作,最開始選用Hbase
作爲原始數據存儲的數據庫。
數據落庫完成之後在一定的時間裏開始使用spark
讀取出來原始數據,開始進行業務的算法計算。
所以整體看來千斤重擔就在Hbase
上,他既要接受不斷的入數據的洗禮,又要接收來自Spark
的讀取。至少給我的感覺hbase
對於我們這種小中型的公司是不適合的,一方面是維護成本奇高,要組織更專業的人來排查線上哪裏出現了瓶頸,以及瓶頸怎麼解決;還要經常性的巡視節點狀況,隨時出現了問題都要找很久。二是機器成本奇高,可能瓶頸就是我們機器節點太少了並且有一些資源混用,但是不可能無限制增加機器。
接下來介紹一下基本情況:
Hbase
作爲基礎數據庫在線上跑了大概一年時間,資源上使用了20臺 * 8核11G
的機器,數據基於S3
,WAL
日誌基於固態磁盤,磁盤的iops
調整到了6000
,低峯時候湊湊合合支撐,高峯時候數據寫入延遲嚴重,經常ReginServer Error
,拒絕寫入
等等,而且採購的雲廠商也不能給予很及時的技術支持,如果要這部分支持就必須花費更高的價格來購買高級服務。
這塊的費用成本大概是:
上圖是線上的服務監控,綠色代表消費速度,紅色代表生產速度。可以明顯看到,綠線一直是連續的,也就是還沒有消費完一批數據,下一波數據就又來了。
綜上,從成本、性能、易維護這三個方面我們必須要做出選擇。
時序數據 & IoTDB
在遇到這個入庫問題之後我就在考慮,除了Hbase
我們還有什麼可以選擇的嗎?有沒有運維更簡單一些不用各種依賴的?
所以迴歸數據的本質來思考問題,數據特性到底是什麼?我們到底需求是什麼?
首先最原始的數據是按時間順序產生的,他們有固定的週期,這本質上就是屬於時序數據。數據在到達數據中心後,會產生亂序、丟幀或者其他問題,所以在這裏我們需要清理、規整一次數據,做好數據質量,並且把亂序的數據排好序。
所以當時想莫不如自己做一箇中間件完成排序和查詢的功能,後來就開始調研相關的存儲技術,機緣巧合下發現了IoTDB
。當然也順便學習了TsFile、存儲引擎、查詢引擎
,經過一段時間的磨合時機成熟,準備上線。
當然上線的過程也不是一帆風順的,畢竟車聯網有一定的行業特點,但是經過我們團隊
和IoTDB團隊
共同的努力之下最終完成上線。這裏細節的問題以及發現問題的過程就不在這篇文章中具體描述,有興趣的可以加我好友或者後面文章繼續寫,這裏列一下當時大的改進點:
- 支持設備模板,極大的節省了IoTDB對內存的使用量。
- 重寫了內存管理功能,使得運行過程中的性能更爲穩定,功能更健壯。
- 增加了字符串池,減少了TsFileResource對於內存的佔用。
- 重新設計了分佈式下的連接管理,讓運行更穩定。
- 還有一些bug fix。。。
以上這些
特性及bug fix
都包含在已經發布的0.12.2
版本中,我已經替大家趟過坑,請放心使用。
最後說一下 IoTDB & Hbase
對比:
- 機器資源
2021年
服務 | 類型 | 配置 | 數量 |
---|---|---|---|
hadoop | 機器 | 8vcpu, 32GiB mem | 20 |
hadoop | 磁盤 | 機械 | 3 |
hadoop | 磁盤 | 固態 | (2T * 14) + (100G * 10) |
IoTDB | 機器 | 8vcpu, 64GiB mem | 3 |
IoTDB | 磁盤 | 固態 | 500G * 6 |
2025年(測算)
服務 | 類型 | 配置 | 數量 |
---|---|---|---|
hadoop | 機器 | 8vcpu, 32GiB mem | 41 |
hadoop | 磁盤 | 機械 | 3 |
hadoop | 磁盤 | 固態 | (2T * 72) + (100G * 22) |
IoTDB | 機器 | 8vcpu, 64GiB mem | 11 |
IoTDB | 磁盤 | 固態 | 500G * 11 |
- 性能監控
Hbase
IoTDB
消費速度幾乎快了1倍,money減少了3-4倍,逢年過節再也見不到報警了。
寫在最後
整個IoTDB的上線工作大約是在8月份完成,當時興致勃勃想寫篇文章分享整個過程,但是想想還是等線上穩定一段時間再寫吧。
因爲沒有經過
10月1國慶節
洗禮的車聯網技術,就像是沒有經過雙十一的電子商城是一樣的。
整個架構跑到現在非常穩定,終於可以對外發布了。如果你也是車聯網從業者、時序數據庫愛好者、車廠從業人員,都歡迎添加好友一起學習交流。
祝玩兒的開心。
歡迎關注微信公衆號:
或添加微信好友: liutaohua001