時序數據庫 Apache-IoTDB 源碼解析之系統架構（二）

上一章聊到時序數據是什麼樣，物聯網行業中的時序數據的特色：存量數據大、新增數據多（採集頻率高、設備量多）。詳情請見：

時序數據庫 Apache-IoTDB 源碼解析以前言（一）

這一章主要想聊一聊：

1. 物聯網行業的基本系統架構，及使用數據庫遇到的需求與挑戰
2. IoTDB 的功能特色及系統架構

車聯網

由於本人是在作車聯網行業，因此對這個行業的信息瞭解更深刻一些，可以拿到一些更具體的數字來講明這個行業的具體狀況。在上一篇文中的數據是出於本身的理解，爲了讓你們容易明白而編造的數據，但實際狀況要複雜的多。

1. 系統架構

1.1 系統簡介

以上示意圖可能很是簡單，但我以爲足夠代表一個總體架構。 當一臺設備、一輛車鏈接到協議網關後，便開始了真正的收發數據。通常通訊的方式都是基於 tcp，搞一段二進制協議，因此協議網關基本要作的工做就是完成對鏈接對管理、完成對數據的收發及編解碼。

當數據完成編解碼以後通常會發往 消息隊列當中，通常都是 Kafka 之中。用來解耦生產和消費兩端，提供一層緩衝，不管消費服務是死是活仍是速度慢，包治百病，甚至還能治未病。

數據發往消息隊列的過程當中，或以後花活兒就多起來了。但主要的我認爲無非仍是三種處理方式：

1. 須要將原始數據保存入庫，這裏的原始數據包含二進制數據和解碼後的二進制數據。
2. 流處理或批處理數據，在數據落到硬盤以前將可以提早計算的數據所有預先計算出來，這樣作的好處是未來查詢的時候若是和預計算的模型匹配，那就能很是快的獲得結果。
3. 離線處理，這裏的應用就太普遍了，通常來說都是將耗時比較大的放置離線計算來作。可是這裏要聲明一點，離線計算依然是越快越好，不能由於他叫離線計算因此在設計或開發階段就不關注時效。

1.2 數據質量

上一章提到了基本的數據質量，但實際工做中，每每質量會出現各類意想不到但數據，下面是工程中影響數據質量的幾個比較大的問題：

1. 數據丟失，不論是在採集，上報，數據流轉環節，均可能會帶來必定的數據丟失比例。
2. 數據亂序，數據在打包、上報、流轉等環節都可能出現亂序，尤爲是在補傳數據中。
3. 數據重複，數據重複發送，尤爲是在網絡很差時。
4. 數據自己不許確，這個最突出的地方就是在 GPS 數據中，常常出現飄點、噪點等等。

2. 數據庫的挑戰

2.1 數據項多

汽車裏具備很是複雜的電路系統和傳感器設備，我印象當中的粗略估算應該是有 120 項左右，而且這些數據項並非車內數據的所有。隨着自動駕駛的到來，汽車的傳感器會愈來愈多，數據項就會更多。

若是按照傳統的 Mysql 存儲，那麼因爲行式存儲，因此在取回數據時候就會很是影響效率，這個介紹到 TsFile 模塊時候再聊。

2.2 存量數據大

咱們按照寶馬汽車 2019 銷售量估計，252 萬量，咱們假定 4 年前就已經具有了聯網模塊那就是 1000 萬量汽車。按照每條數據 1K，天天採樣上傳 1 次，應該是 天天 9G 數據。但由於車不可能一直都點火開，因此要假設一個 30% 的在線率，那就是 3G 數據。

3 年大約就會存儲 3TB 數據，可能你以爲 3T 數據對於時下最熱的大數據來說並非一個很是龐大的數字，但若是整個數據裏面不包含任何圖片、音視頻甚至都沒有文字，所有是由整數、浮點數堆積起來的，那你能夠試想一下這個數據庫裏面到底有多少數據，若是你一個不當心執行了 count(*) 你以爲會卡死不？

2.3 採集頻率高

汽車不一樣於其餘傳感器的地方是，他是一個處在時刻運動當中的物體，若是須要作一些高階的計算模型，好比說：碰撞檢測、行駛軌跡糾偏等，那麼相應的數據採集頻率有可能要達到秒級。

固然我說完這句話，可能你感觸並非很深，可是結合前面說到的兩點：120項數據、1000萬量車，將採集頻率提升到 1 秒一採集，那麼這個頻率下，一天產生的數據大小就是 259T。這時候你找 DBA 說，哥們咱們的需求要 1 天寫入 259T 數據，我以爲反正我是沒臉找人家，讓產品去跟 DBA 聊吧。

2.4 不一樣數據庫遇到的問題

咱們公司也採用了多種嘗試，從開始的 MySql 到 MongoDB 再到 Hbase 等等，它們總存在這一點或多點的讓你以爲就是不知足的地方，以下圖：

IoTDB

到此爲止，總體需求基本明確，做爲一款物聯網的時序數據庫須要處理的問題:

1. 高速寫入
2. 高效壓縮
3. 多維度查詢，降採樣、時序分割查詢等
4. 查詢低延遲高效
5. 提升數據質量，亂序、空值等
6. 對接現有大數據生態

IoTDB 功能特色

IoTDB 完成了上述問題中的幾乎全部功能，並且能夠靈活對接多生態，高性能優點等。那麼 IoTDB 是如何完成這些優點項，如何作到？

IoTDB 架構描述

對照上面的圖，大體瞭解一下 IoTDB 的結構，邏輯上被分爲 3 個大部分，其中：

1. Engine 是完整的數據庫進程，負責 sql 語句的解析，數據寫入、查詢、元數據管理等功能。
2. Storage 是底層存儲結構，相似於Mysql 的 idb 文件
3. Analyzing Layer 是各類鏈接器，暫不涉及細節。

Engine 和 Storage 中主要包含：

1. IoTDB Engine，也就是代碼中的 Server 模塊.
2. Native API，他是高效寫入的基石，代碼中的 Session 模塊
3. JDBC，傳統的 JDBC 鏈接調用方式，代碼中的 JDBC 模塊
4. TsFile，這是整個數據庫的一個特點所在，傳統的數據庫若是使用 Spark 作離線分析，或者 ETL 都須要經過數據庫進程對外讀取，而 IoTDB 能夠直接遷移文件，省去了來回轉換類型的開銷。TsFile 提供了兩種讀寫模式，一種基於 HDFS，一種基於本地文件。

聊到這裏，咱們基本介紹了行業內的特色，做爲數據庫須要解決的痛點，以及 IoTDB 在完成功能的同時所具備的自身的優點。同時還簡單介紹了 IoTDB 的基礎架構，樸實無華且枯燥。那麼 TsFile 到底是什麼樣的結構才能完成以上所介紹的高速寫入、高壓縮比、高速查詢呢？Native API 又是什麼？歡迎繼續關注。。。