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

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

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

打一波廣告，歡迎大家訪問 IoTDB 倉庫，求一波 Star 。

這一章主要想聊一聊：

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

車聯網

因為本人是在做車聯網行業，所以對這個行業的信息了解更深入一些，能夠拿到一些更具體的數字來說明這個行業的具體情況。在上一篇文中的數據是出於自己的理解，為了讓大家容易明白而編造的數據，但實際情況要復雜的多。

1. 系統架構

1.1 系統簡介

以上示意圖可能非常簡單，但我覺得足夠表明一個整體架構。 當一台設備、一輛車連接到協議網關后，便開始了真正的收發數據。一般通信的方式都是基於 tcp，搞一段二進制協議，所以協議網關基本要做的工作就是完成對連接的管理、完成對數據的收發及編解碼。

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

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

1. 需要將原始數據保存入庫，這里的原始數據包含二進制數據和解碼后的二進制數據。
2. 流處理或批處理數據，在數據落到硬盤之前將能夠提前計算的數據全部預先計算出來，這樣做的好處是將來查詢的時候如果和預計算的模型匹配，那就能非常快的得到結果。
3. 離線處理，這里的應用就太廣泛了，一般來講都是將耗時比較大的放置離線計算來做。但是這里要聲明一點，離線計算依然是越快越好，不能因為他叫離線計算所以在設計或開發階段就不關注時效。

1.2 數據質量

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

1. 數據丟失，不管是在采集，上報，數據流轉環節，都可能會帶來一定的數據丟失比例。
2. 數據亂序，數據在打包、上報、流轉等環節均可能出現亂序，尤其是在補傳數據中。
3. 數據重復，數據重復發送，尤其是在網絡不好時。
4. 數據本身不准確，這個最突出的地方就是在 GPS 數據中，經常出現飄點、噪點等等。

2. 數據庫的挑戰

2.1 數據項多

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

如果按照傳統的 Mysql 存儲，那么由於行式存儲，所以在取回數據時候就會非常影響效率，之后介紹到 IoTDB 的文件格式的時候再聊。

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 大數據分析需求

現有時序數據庫都無法支持大數據分析框架，都需要通過數據庫的 Api 把數據從數據庫往數據倉庫導出后再存一份，數據量直接翻倍。 舉個例子，我如果需要對 Mysql 中的數據進行 MapReduce 計算，那么只能是將數據通過 JDBC 接口導出到 Hbase 或 Hdfs 上，然后執行計算，可能你覺得這很正常，但按照上面提到的數據量，數據復制之后你公司里可能就需要每天支撐 500T 數據。

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 又是什么？歡迎繼續關注。。。