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